Sign up for Office 365
Learn more about Office 365
I currently doing a cutover migration from on-prem Exchange 2010 to O365. The migration to the cloud is complete, but i still havent removed the batch migration or changed MX records, we are just syncing changes at this point. I have two questions, because i have an on-prem Exchange 2010 sp1 server, how should i change the current autodiscover record that is pointing to the SCP in AD? And am i required to create a new outlook profile so users can connect to there O365 mailbox? if so this is going to be a problem because users have alot of customized settings in the current Outlook profile.
I have already created the external CNAME Autodiscover record, and i have confirmed it works correctly, but if the client is in premise they will see the SCP autodiscover record thats in AD, and will use this record.
You will need to convert the users to the mail enabled users and set the autodiscover CNAME record point to outlook.com in internal DNS. It need to create the new Outlook profile so that users can connect to their Office 365 account.
Thanks for your reply.
In your situation, generally we would suggest you firstly backup your Outlook date files (.pst), and then create a new profile for use, you may import the original .pst file to your new profile if necessary.
If you want to use the original profile, you may be able to do this by manually configure your Outlook client, for more details, you may refer to this KB article:(please refer to the Method 3)
If you have other questions, please feel free to post on the forum.
I'm a little bit confused on the requirement to turn an on premise 2010 mailbox to an MEU, when doing a cutover migration. Please see the post below where i ask the questions is it required to turn on premise mailboxes to MEU's when doing a cutover migration. What i want to avoid is having to change the users outlook profile. Because we are running Exhcange 2010 on-prem i need to do modify or remove the SCP record in AD. Should i modify the SCP record in AD so it point to autodiscover.outlook.com? I understand i have to create an internal CNAME record, but the on prem outlook client is going to look at the SCP in AD first
I have the same question regarding Outlook profiles and do not understand your response. If the autodiscover cname is pointed at outlook.com, a user is enabled for Office 365, and we have migrated the appropriate exchange mailbox, will they need to create new Outlook 2010 profiles locally, or will it use their curent profile?
If the SCP record you mean is autodiscover CNAME record, it should be pointed to autodiscover.outlook.com.
The users can either create new Outlook profile or use their current profile. The autodiscover will update their current profile automatically.
I dont think its possible, autodiscover is not able to change the "servername" settings in the Outlook client. Autodiscover is capable of changing the proxy settings in the outlook client, but cant change the "servername" the outlook client points to in-order to connect to Exchange. We have an on premise 2010 sp1 server, we migrated all mailboxes to the cloud using the "cutover" migration approach. The cutover migration was able to create all the mailboxes, DL's contacts, and sync data between the onprem mailbox and the cloud mailbox, but there appears to be NO solution to update the users onprem outlook profile to point to the mailbox thats in the cloud. The onprem outlook client will always look to the onprem Exchange server, *first* and it will make a tcp\ip connection to the onprem exchange server. We all know that in order to connect to the O365 mailbox you *must* use Autodiscover, and you also have to use HTTPS. The internal DNS CNAME record works, but it only works if you create a new outlook profile. Outlook will never look\use the CNAME record in DNS if its able to make a tcp\ip connection to onprem Exchange! So how do we get around this? we cant expect users will be happy having to change there outlook profiles??? thats like asking users to change there desktop profiles.... The post from Josephine below is correct if the outlook client is using HTTP and is not on the same network (remote) as the on prem exchange server. The solution will not work, if the outlook client is using tcp\ip (thats the default setting in outlook) or is using http but is on the same network as the onprem exchange server.
Any advice is greatly appreciated.
I tried pointing the outlook client directly to the O365 mailbox, but i received the error below. The only way to fix this error was to create a new .ost file. Again there doesn’t appear to be a way using a cutover migration method to automatically update the outlook client to point to the O365 mailbox, and i find it interesting that Microsoft suggests that a cutover migration method is suitable for 1000 mailboxes or less. You really can’t expect admins to manually go around and touch every client?? I hate to have to tell the client that we are going to have to either create new .ost files or create new outlook profiles for every client. Microsoft shouldn’t recommend a cutover migration as a viable option to use, unless there is a way to automatically update the outlook client.
"A temporary mailbox exists, but might not have all of your data. You can connect to the temporary mailbox or work offline with all of your old data. If you choose to work with your old data, you cannot send or receive e-mail messages."
Thanks for your information.
As we would not be able to automatically or manually update the outlook client to point the old .ost file to the Office 365 mailbox, you are required to create a new profile for use, and this can also avoid the occurrence of any unknown errors.
Just checking in to see whether the previous information provided by Evan was helpful. Please let us know if you need further assistance.
This seems to be very confusing and I'm having a hard time finding the right answer. The question is simple. Do you require a new profile for Outlook when you use a Cutover migration and why. Tks