Another way to approach Autodiscover during migration: change DNS server settings on the WS

Any mailbox migration these days should include some way of addressing Autodiscover to ensure seamless user’s transition from one AD / Exchange organization to another. The issues with Autodiscover arise because 2 mailboxes exist – one in Source and one in Target, and depending on how the environment is configured, Outlook can resolve to one of them. And of course having user to go and connect to Target mailbox before D-Day can be consider a big migration failure. Here I would like to summarize all Autodiscover workaround methods we have and in particular talk about less often used one – managing access via DNS.

So again, what options do we have?

1. Depending on the Autodiscover resolution path described in my previous article Exchange Autodiscover logic and SCPs, one can control end user’s Read permission to the SCP object in a Domain/Forest where user’s workstation belong (!) and either let the resolution process succeed or not. By removing “Authenticated Users” group from the Security on SCP AD object and adding “Migrated Users” group with Read permission, we can then control who can read SCP settings and be redirected to the corresponding Exchange entry point. For example:

-Source is Ex 2003 and clients do not resolve any Autodiscover. Once Target Exchange 2007/2010/2013 is introduced and mailboxes pre-created, SCP from Target forest can be exported into the source and permissions set as described above. Then in Exchange first migration while WS remains in Source, once mailboxes are migrated and added to “Migrated Users” group, Autodiscover resolution path starts properly working to the Target mailbox.

-Source is Exchange 2007/2010/2013 and Target also has Exchange later that Ex 2003. Autodiscover here needs to be dealt with on both sides. We can leverage the fact that SCP exported from Target to Source takes precedence over the other SCP objects residing underneath each CAS server object deeper in Configuration container. Those user accounts who get opened up to Read that exported Autodiscover SCP from Target can now be redirected to the target mailbox.

There are more scenarios but these 2 are very common and provide good idea how we can leverage this SCP method. Implementation itself looks as follows:

Export-AutoDiscoverConfig -DomainController <FQDN> -TargetForestDomainController <String> -TargetForestCredentials $a -MultipleExchangeDeployments $true

2015-03-13_19-50-08

2015-03-13_19-52-43

To get the user immediately re-build the Kerberos ticket without logging out / rebooting, the following command can be utilized (can make it part of CPUU wrapper script): klist purge

2. Leveraging local XML. This is very well described by Michael Gastright in his earlier blog here: Controlling AutoDiscover during an Exchange Migration. Essentially local XML with certain Autodiscover settings is either put in place or removed, directing Outlook to the proper Exchange environment.

3. And finally DNS. It’s not very common and honestly not the best method because you need to know which machine migrated user’s logging into, but it works and may be very convenient for some smaller scale projects. The idea here – since part of Autodiscover logic is re-trying a certain combination of addresses as in the example below, we can have them resolvable in a different fashion depending on what DNS server is utilized by client’s machine.

-https://contoso.com/autodiscover/autodiscover.svc

-https://autodiscover.contoso.com/autodiscover/autodiscover.svc

Plus go for the DNS Autodiscover SRV record

So during mailbox migration we can re-point user’s workstation to the new Target AD DNS environment that has these above URLs properly resolvable, or have the corresponding SRV record in-place. Here are couple batch files that I found on the Web, which can be pushed via QMM RUM (Resource Updating Manager) or using psexec:

2015-03-13_12-14-40

2015-03-13_12-15-42

Most OS-es except XP:

************************************************************************************************************

:: Set primary and alternate DNS for IPv4 on Windows Server 2000/2003/2008 &
:: Windows Vista/7
@ECHO OFF
SETLOCAL EnableDelayedExpansion

SET adapterName=

FOR /F “tokens=* delims=:” %%a IN (‘IPCONFIG ^| FIND /I “ETHERNET ADAPTER”‘) DO (
SET adapterName=%%a

REM Removes “Ethernet adapter” from the front of the adapter name
SET adapterName=!adapterName:~17!

REM Removes the colon from the end of the adapter name
SET adapterName=!adapterName:~0,-1!

netsh interface ipv4 set dns name=”!adapterName!” static x.x.x.x primary
netsh interface ipv4 add dns name=”!adapterName!” x.x.x.x index=2
)

ipconfig /flushdns

:EOF

************************************************************************************************************

XP:

************************************************************************************************************

:: Set primary and alternate DNS for IPv4 on Windows XP
@ECHO OFF
SETLOCAL EnableDelayedExpansion
SET adapterName=

FOR /F “tokens=* delims=:” %%a IN (‘IPCONFIG ^| FIND /I “ETHERNET ADAPTER”‘) DO (
SET adapterName=%%a

REM Removes “Ethernet adapter” from the front of the adapter name
SET adapterName=!adapterName:~17!

REM WinXP Remove some weird trailing chars (don’t know what they are)
FOR /l %%a IN (1,1,255) DO IF NOT “!adapterName:~-1!”==”:” SET adapterName=!adapterName:~0,-1!

REM Removes the colon from the end of the adapter name
SET adapterName=!adapterName:~0,-1!
echo !adapterName!

netsh interface ip set dns name=”!adapterName!” static x.x.x.x primary
netsh interface ip add dns name=”!adapterName!” x.x.x.x index=2
)

ipconfig /flushdns
:EOF

************************************************************************************************************

Tags:

Leave a Reply