A guide for BPOS to O365 transition by someone who has been through it RRS feed

  • Question

  • A guide for BPOS to O365 transition:

    I would like to provide a guide of exactly what my experience was transitioning from BPOS to Office 365. I found a lot of good information in this forum, however many things I read either did not answer my questions or turned out to be wrong. In fact many answers proposed by Microsoft reps in the forum we incorrect as well. I would like to note that our email is completely hosted by Microsoft and we have no on premise exchange or ADFS services. All our client PC’s are Windows 7 Professional x86 and x64 and Office 2010 professional fully patched. We have 80 email clients in total.

    My transition experience in order:

    1. Received email from Microsoft we were slated to transition in 60 days
    2. Downloaded the administrators transition check list guide which is a great document and worked on performing all items except item 4 as this should not be done until the transition weekend no matter what Microsoft says you should do. http://www.microsoft.com/online/help/en-us/helphowto/8939e90a-59dc-4f0f-aec0-19a899c0af75.htm
    3. Had all users change their BPOS password as this is required and very important as it synchronizes the password with BPOS and the O365 portal and Lync log in areas.
    4. Added all Lync DNS records to internal and external DNS servers then installed Lync on all my clients and ran the O365 configuration tool on all client machines as this is also extremely imporatant. Lync takes over and disables office communicator during the process. All my end users were easily able to connect and use Lync right away while still having their email on the BPOS side of the house. This is your first step into the O365 world.
    5. Then we received a t-30 day transition email. At that point I wanted to double check and ensure all users had changed their passwords since the first transition notice. I Launched the Online migration Poweshell application and ran the following commands. My goal was to ensure user passwords were changed by all users within a given time frame.

    $Cred=get-credential (to log in as admin)

    Get-MSOnlineUser  -Credential $Cred -enabled | where {$_.PasswordLastSetDate –lt “05/15/2012”}  | FL Identity

    1. During the final two weeks before the transition I ensured my users could log in the O365 portal so that I was sure their password would work and they could sign in right after the transition.
    2. I made sure that all my client machines were up to date via Microsoft updates. WSUS is what I used to update all my client PC’s
    3. Our transition was scheduled for Friday 6/29/12. We received an email on Thursday 6/28/12 stating our transition had begun. This was a little worrisome as it left us wondering what was going to happen for that next Business day on Friday. Plus the fact that we had not performed the Autodisocver DNS and SPF record changes as of yet. We knew we could change them on the fly if need be and that they would work quickly if changed so we stayed the course and waited until that Friday night at 5 Pm to make those DNS Autodiscover and SPF record changes. All worked fine that Friday and we had no issues. At 5 PM we created the autodiscover records in our internal and external DNS servers and we waited until Sunday to let the migration take place.
    4. Early Sunday 7/01/12 we received an email stating the transition is complete. Logged into the portal and had the Admin option. I checked the DNS records for our domains that were listed in management and domains. This is where things first get interesting. In all Microsoft documentation and in several areas in this forum they either have no mention of changing MX records or state that you do not need to change them when migrating from BPOS to O365. As I found out this is incorrect information. When I looked at our domain DNS records they had new MX records. I called O365 transition support and asked them why customers are not told to change their MX records. They could not answer that but insisted they must be changed ASAP. So we proceeded to change them as directed by Microsoft support.
    5. On Sunday 7/01/12 out IT team came into the office and started to log into all end user machines and configure access to Office 365. Now according to Microsoft and many items in this forum the Single Sign In Client (SIC) is supposed to be transition aware and must remain on the client PC until it connects to Office 365 Outlook client at least once. The SIC is supposed to uninstall several registry items it put in place during the initial set up and it is supposed to tell the client PC to no longer use the local XML record to connect to email and allow Outlook to perform a DNS lookup to find the new Autodiscover settings that allow it to communicate and run with Office 365. Here is what actually happened in our experience. In about 59% of our client PC’s the SIC performed its job correctly and we launched Outlook and it would show a message stating that “the administrator has made some changes please restart Outlook”. Close Outlook and re-launch it and then it will prompt for the user credentials. Add the proper credentials in and Outlook comes up and connects and runs perfectly. At this point the SIC and be closed and removed on these clients. However on the other 40% of the client PC’s with the same build and updates and in many cases the same hardware Outlook would not recognize a change and would constantly prompt for the user password and fail in an endless loop. These clients for some reason had to be fixed or they would never work or connect to Office 365. The problem was the SIC itself as it was not removing the items it was supposed to on the client PC therefore the client PC was always looking to the local XML entries and the old BPOS information.
    6. The fix that is required to perform the work that the SIC was supposed to is outlined below. Once these items were performed all clients that would not previously connect to Office 365 Outlook were able to and all our users could then work in Outlook as expected in O365.

    Fix to set up O365 when account won’t just work by automatically configuring itself:

    1.             Remove the Single Sign in client via add remove programs (SIC)
    2.             Run the Microsoft fix it at http://support.microsoft.com/kb/2644437
    3.             Go into IE and click tools and security, intranet sites , advanced and delete any microsoftonline entries
    4.             Add new email account in control panel mail icon area and call it O365 user@contoso.com  and go through the set up. Used contoso.com as an example here.
    5.             During the Outlook set up on the first page, change the email address to user@contoso.onmicrosoft.com  and enter the user password and click next
    6.             You will get a prompt for user credentials and you change the email address in that prompt to user@contoso.com  and click remember password. Then launch Outlook and it should it should start to launch. If it does and logs in properly and doesn’t prompt for a password then go to step 8 and you are done.
    7.             If Outlook fails to launch without prompting for a password after step 6 then you must edit the registry at the following location. HKEY Current User->Software->Microsoft and delete the MOCHA folder
    8.             Launch Outlook again and perform step 6 if prompted. Outlook should then connect. Then you have to go into the file tab in Outlook and account settings, click on the email user name and click change. Then click more settings and change the email address to user@contoso.com  and click next and finish. The email account is now properly set up for O365. Note however this has created a new OST file for the user.
    9. On Monday our IT staff went around to end users and ensured they launched Outlook properly now via the Outlook client icon. All users logged in without issue and email worked perfectly for all users.
    10. On Tuesday our IT staff went around to the end users and removed the SIC client for their PC’s permanently.

    All is running well since the transition and we have no other issues. Overall Microsoft did a great job. However, they could not explain why we had to run manual fixes on 41% of our clients to get them to connect to O365. I hope this information helps future companies that transfer from BPOS to O365. Thank you.

    Tuesday, July 3, 2012 6:02 PM

All replies

  • Thanks for the feedback Gator, this is great information that I hope others will use for their Transition.  Looks like there are a few questions in the post, hopefully I can help answer them.

    1. MX Records - BPOS uses mail.global.frontbridge.com and Office 365 ALSO uses this FOPE ingress point for incoming mail.  However Office 365 can also leverage the domain-com.mail.eo.outlook.com MX record.  Our documentation can be better on this, and I'll make sure we get better clarification on this.  Using either MX record will have all mail delivered into FOPE, which will find your custom domain and forward the mail to the EXO365 MBX server where your users reside.
    2. SIC & Outlook Profile Redirection - You have it exactly right.  The SIC is needed so it can have the BPOS creds in CredMan AND the online user's certificate, which is used to connect to BPOS EXO's Availability service, which then tells Outlook "your MBX has moved" along with a directive that the Profile needs to be updated.  Outlook is then sent to EXO365 due to the BPOS user now have a targetAddress of user@domain.onmicrosoft.com.  Outlook connects and asks "Where is my MBX" and the return value is used to update the profile and complete the profile redirect process.  NOTE - Once the Outlook profile uses a different configuration than what BPOS uses, the registry settings that point to the autodiscover.xml are no longer used.  After 5 days these registry settings are removed and after 7 days the SIC is disabled and will no longer automatically run at sign-in, if this is configured in the SIC client.  NOW why did some clients work while others did not, that is the question.  I cannot say with certainty, but each client should work in exactly the same way.  I have seen the "multiple prompts" issue several times and each issue was around having either an Outbound Internet Proxy that did NOT allow the user to get redirected from BPOS EXO to EXO365, thus Outlook could never finalize the profile redirect.  The other time I saw this was due to a Personal Firewall, where the session starts with mail.domain.microsoftonline.com and is sent to EXO365 and the firewall saw this as a security risk and did NOT allow that to happen.

    Your FIX - Doing a removal of the Outlook Profile and recreation will cause all mail to be downloaded again, into the .ost.  For small MBX's this may be ok, but for larger seats or MBX's this WILL impact your network. I would recommend simply going into the Outlook BPOS Profile and going into the Profiles section and clicking Repair, which forces Outlook to issue an Autodiscover lookup, which should point to autodiscover.outlook.com, prompt for creds and get reconfigured.  This of course requires that the DNS CNAME  autodiscover.customDomain.com record has been created and points to autodiscover.outlook.com

    thanks again for the feedback, this is great info and I'm sure others can use your Lessons learned in their Transition Weekend!

    Transitions Community Lead ...Ryan J. Phillips

    Friday, August 3, 2012 6:37 PM
  • Thanks again for all your help. Extremely informative posts for someone like me who is about to undertake the transition with 300 users.
    Friday, September 14, 2012 12:56 AM