Nick Daniels
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:
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:
The problem I am having is that when I run:
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:
Thanks in advance!
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
(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
Take note of the result and then run this command:Set-ClientAccessServer -Identity “CAS1” -AutoDiscoverServiceInternalUri "https://cas1.cumulus-apps.com/Autodiscover/Autodiscover.xml"
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
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:
Thanks in advance!
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.
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=Serve rs,CN=Your Server,CN= Protocols, CN=Autodis cover
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 AutoDiscoverServiceInterna lUri is currently blank, is that a symptom of a problem?
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=Serve
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 AutoDiscoverServiceInterna
If rollback is your part of plan, better you go do hybrid migration.
ASKER
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 AutoDiscoverServiceInterna lUri 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.)
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 AutoDiscoverServiceInterna
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.)
ASKER
This article (example 1) suggests that the Internal URL is the same as the AutoDiscoverServiceInterna lUri:
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?
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
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