New Set-AutodiscoverSCP v2 script is on the TechNet Gallery

Friday, July 22, 2016
Set-AutodiscoverSCP.ps1
I just published version 2.0 of my Set-Autodiscover.ps1 script to the TechNet Gallery. This is a complete rewrite of the old script and includes the following new features:
  • Made setting the new values easier by cloning an existing server
  • Now also configures Outlook Anywhere and all Exchange virtual directory internal and external URLs
  • Revised verbiage and use *-ClientAccessService cmdlets for Exchange 2016
  • Added -Verbose output to display the values we're configuring
  • Improved overall display output
These changes are intended to make the script more powerful and easier to use.



How many times have you installed a new Exchange 2010-2016 server only to hear users complain about a security pop-up in Outlook referencing the new server?

This happens because Exchange setup uses the FQDN of the server as the service connection point (SCP) that Outlook clients use for autodiscover requests (for example, https://exch03.contoso.local/autodiscover/autodiscover.xml). This new SCP is configured in Active Directory when the Front-End Client Access role is installed during setup. In most load balanced environments the valid SCP should be something like https://autodiscover.contoso.com/autodiscover/autodiscover.xml. Outlook will prompt users with a security warning because the self-signed Exchange certificate installed by setup is not trusted. If the new server is Internet-facing, ActiveSync clients can also get security warnings on their mobile device.


Read Exchange Active Directory Deployment Site for more information about this behavior.

I wrote a script, Set-AutodiscoverSCP.ps1 (available on the TechNet Gallery), that automatically updates the SCP, Outlook Anywhere FQDNs, and all the virtual directory internal/external URLs for the server your specify to match the values currently configured on another server you specify as soon as the new server is detected in AD. It continually polls Active Directory until it finds the new SCP value and sets the new values. A progress bar indicates that the script is polling AD.

The script is intended to run on another Exchange server in the org running the same version of Exchange as the new server. This is because Exchange 2010 cannot update SCP values for Exchange 2013 or 2016, and vice versa. You can also have the script target a particular domain controller. This is useful when the new server you are installing is in a different AD site.

The syntax for Set-AutodiscoverSCP.ps1 is:
Set-AutodiscoverSCP.ps1 [-Server] <String> [-ServerToClone] <String> [[-DomainController] <String>] [<CommonParameters>]
Two examples of usage:
PS C:\>Set-AutodiscoverSCP.ps1 -Server exch02 -ServerToClone exch01
Example #1 continually queries the current configuration domain controller until it finds an SCP for server EXCH02 and then sets it to match the SCP of EXCH01. It also configures Outlook Anywhere and the internal/external virtual directory URLs to match those found on EXCH01.

PS C:\>Set-AutodiscoverSCP.ps1 -Server exch02 -ServerToClone exch01 -DomainController dc03
Example #2 is almost the same as the command in the previous example, except it continually queries DC03 for the SCP record and configures it on that domain controller. This is useful when configuring a new Exchange server in a different Active Directory site.

The script is designed to be run during installation. Normally, you would run this script from an existing Exchange server of the same version while the new server is being installed.

You can also run the script directly from the server that is being installed. This is useful when you're installing the first Exchange 2013/2016 server in a 2010 environment. You can start running the script on the new server when the Client Access Front End Service is being installed. The caveat is that setup restarts IIS and web services several times during setup, causing the script to possibly stall during configuration of the virtual directories. If that happens, simply CTRL-C to quit the script and run it again.

I've included error handling for the following conditions:

  1. The script notifies you what version of Exchange is running the script and warns you to make sure the new server is running the same version. Note that Exchange 2013/2016 servers can update each other. This warning really only applies to Exchange 2010 and Exchange 2013/2016 coexistence. 
  2. The script checks that the server, server to clone, and the domain controller (if specified) are pingable. If the servers cannot be pinged, the script will terminate.
  3. If a domain controller is specified, it validates that the DC specified is actually a domain controller

Set-AutodiscoverSCP.ps1 is a useful addition to your Exchange toolbox. Please let me know if you have any questions or feature requests. I'll update the script again on the TechNet Gallery as needed.

Read more ...

Cannot Create Frontend Receive Connector using Exchange 2016 CU2 Admin Center

Wednesday, July 13, 2016
I've heard a few people complaining about this on Twitter and social media, so I figured I document it here.

You may find when you create a new Receive Connector using the Exchange Admin Center from an Exchange 2016 CU2 server that you cannot create the new connector as a Frontend Hub Transport role. The option to select the Frontend Transport role is grayed out and defaults to the Hub Transport role.

New receive connector role is grayed out

I've been able to reproduce this bug when the admin account used to create the new receive connector has a mailbox hosted on an Exchange 2016 CU server. If the admin account's mailbox is hosted on Exchange 2013 you can select the Frontend Transport role as expected.

This smells very much like a mailbox anchoring issue, which was supposed to have been reversed in Exchange 2016 CU2.

There are three workaround for this:
  • Create the new receive connector using the Exchange Management Shell (EMS)
  • Create the new receive connector from the Exchange 2013 Admin Center. Note you will need to connect directly to the Exchange 2013 EAC using the Exchange 2013 server's FQDN. For example, https://EX2013.contoso.com/ecp/?exchclientver=15
  • Move the admin account's mailbox to an Exchange 2013 server. Note that this bug will still occur if the admin mailbox is hosted on an Exchange 2010 server.
You can create a new frontend transport receive connector via the Exchange Management Shell using a cmdlet similar to this example:
New-ReceiveConnector -Name 'New Receive Connector' -RemoteIPRanges @('10.0.1.0-10.0.1.255') -Bindings @('0.0.0.0:25') -Usage 'Custom' -Server 'EX16B.contoso.com' -TransportRole 'FrontendTransport' 
I've created a bug for this on Microsoft Connect. Hopefully it will be corrected in Exchange 2016 CU3.

Irritating Side Note:
Why, oh why, does the Exchange Admin Center default to creating a Hub Transport role receive connector in the first place?? 99.99% of all receive connectors created by admins should be Frontend Transport role connectors. This causes much wailing and gnashing of teeth because the new receive connector doesn't function as expected.

In order to change the role to Frontend Transport, run the following cmdlet:
Set-ReceiveConnector "Receive Connector" -TransportRole "FrontendTransport"
FYI - I have an Exchange design change request logged to make the default transport role Frontend Transport, too. <holding breath>

Read more ...