Link to home
Start Free TrialLog in
Avatar of Nick Daniels
Nick DanielsFlag for United States of America

asked on

Migrating to Office 365, need help with a potential roll-back solution

We currently have an one on premises Exchange 2013 server and are moving to Office 365.  We are not going to maintain a hybrid scenario and are performing a cut-over type of migration. So once we complete the DNS changes and final passes of the migration we will decommission the on-prem Exchange server.

I was instructed to make the following changes to our Active Directory SCP so internal Outlook clients will look at the Office 365 servers when autodiscovering instead of trying to find our internal server:

 Command 2: Set-ClientAccessServer -Identity "CAS1****" -AutoDiscoverServiceInternalUri $NULL

Open in new window

(Where CAS1 is my Client Access Server)
Also the internal DNS changes will be performed for the autodiscover CNAME.

That seems pretty straight forward, but as a conservative planner who has been burned enough times I want a solid bailout plan.

I want to allow a way to roll back if there is a problem after I run the above command.
In other words, I want to know how to undo that command.

Thank you in advance!
I was provided by support with this command as an answer to that question:

First run this before changing the CAS:

Get-ClientAccessServer | Select-Object AutoDiscoverServiceInternalUri

Open in new window

Take note of the result and then run this command:
Set-ClientAccessServer -Identity “CAS1” -AutoDiscoverServiceInternalUri "https://cas1.cumulus-apps.com/Autodiscover/Autodiscover.xml"

Open in new window

Replacing https://cas1.cumulus-apps.com/Autodiscover/Autodiscover.xml with the output I made note of from Step 1, as well as replacing CAS1 with my actual server's name.

The problem I am having is that when I run:
Get-ClientAccessServer | Select-Object AutoDiscoverServiceInternalUri

Open in new window

I get a blank result as seen in the first command in the screenshot below.

Can you you please provide me a way to "roll back" if something goes bad.
I want to cover all my bases before we go-live if possible.

More details:

User generated image
Thanks in advance!
Avatar of Amit
Amit
Flag of India image

In cut-over migration, I don't see the reason to roll back. As far as SCP connection update, you can update it via adsiedit tool also.
Avatar of Nick Daniels

ASKER

Just as a safety practice, if I am given a command to run on a critical server that I have never run before, I want to make sure I know how to undo it before proceeding. Murphy's Law reigns here...

When I look in ADSI in this section:
CN=Services, CN=Microsoft Exchange,CN=First Organization (your org name),CN=Administrative Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Servers,CN=YourServer,CN=Protocols,CN=Autodiscover

In the properties of the record I see three fields that contain my current Exchange Server Name.
cn, name, serviceDNSName
After I run that command to change my SCP to null, what fields would I update in this record to put it back to it's current state?

Also, if my AutoDiscoverServiceInternalUri is currently blank, is that a symptom of a problem?
If rollback is your part of plan, better you go do hybrid migration.
I see your point...

I just figure that making sure I have a way to undo this SCP record change for internal autodiscover is a good practice if something unforeseen happens. Or, what if the initial command to set the AutoDiscoverServiceInternalUri to NULL doesn't execute correctly, and messes up my internal ability to connect using autodiscover.

I wouldn't think that would warrant a change in the migration style to hybrid.

I am hoping someone can guide me through a way to undo this command? I am not that savvy with Exchange (hence the reason we are moving to off site email.)
This article (example 1) suggests that the Internal URL is the same as the AutoDiscoverServiceInternalUri:
https://technet.microsoft.com/en-us/library/bb125157%28v=exchg.160%29.aspx?f=255&MSPPError=-2147217396

If that's true, then I have the address of what is needed for that Set-ClientAccessServer command, but that still doesn't explain why it's currently blank...

Any thoughts?
ASKER CERTIFIED SOLUTION
Avatar of Deepin
Deepin
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks for the extra Information. We went live this past weekend and you were correct. The SPF to NULL and the internal DNS change were all that was necessary. Thanks for the help!

For posterity I will add that Office for Mac (2011 and 2016) wants to reset the connection back to the old on-prem exchange server randomly on the days following the migration.  There is a pesky autoconfigure feature that needs to be put to death.  Here are some links that will help you kill it.

Info: https://technet.microsoft.com/en-us/library/jj984202(v=office.16).aspx

outlook for mac 2011: http://www.officeformachelp.com/2011/01/exchange-autodiscover-workaround-for-advanced-settings/

outlook for mac 2016:  https://support.microsoft.com/en-us/help/3206915/how-to-suppress-the-office-365-autodiscover-redirect-warning-in-outlook-2016-for-mac