Outlook 2010 reconfiguration after BPOS transition not working completely

Tüm Yanıtlar

• 30 Ocak 2012 Pazartesi 22:03

   

   
  

  0

  we had the same problem with some users. Sometimes it helps trying to repair the Outlook account. For one customer there was a problem with autodiscover: I had to delete old dns records and also some rests of a former Exchange installation with adsiedit. A local autodiscover record (poiting to autodiscover.outlook.com) also helps. If a nslookup to autodiscover.companyname.com is successfull there is a good chance that you can automatically change the Outlook configuration from BPOS to Office 365 after installing the desktop config.

  Ralf

  ---

  Ralf Rosenberg
   
• 31 Ocak 2012 Salı 06:53

   

   
  

  0

  Thanks Ralf.

  Do you think I can do this:

  On sunday, when the transition is complete I can remove the BPOS Sign In Client, and remove registry keys/XML files, and when customers meet on monday, they can open Outlook and it finds out of the new settings by the new autodiscover DNS lookup

  ?

   
• 01 Şubat 2012 Çarşamba 07:53

   

   
  

  0

  good luck Kim! I think it will work if you execute the desktop preparation before starting Outlook....

  Ralf

   

  ---

  Ralf Rosenberg
   
• 01 Şubat 2012 Çarşamba 08:11

   

   
  

  0

  I will try the next weekend, and get back.

  I don't think the Desktop tool does anything about the Outlook config.

  We haven't run it at other customers on Office 365.

   
• 01 Şubat 2012 Çarşamba 09:14

   

   
  

  0
  the Office 365 desktop setup prepares also Outlook and does a system check. For example it installs a patch for Outlook 2010...It is neccessary and useful. Surely you can manually configure Outlook if all updates and patches are installed.

  ---

  Ralf Rosenberg
   
• 02 Şubat 2012 Perşembe 04:14

   

   
  

  0

  Hi FreeSoftDK, I would wait until after the user signs in for the 1st time AFTER Transitions, so the SIC can programmatically remove the PreferLocalXML and other Autodiscover registry settings.  once that is done, Outlook should be exited and restarted, at which point it will query for the AutoD DNS record, find it pointing to autodiscover.outlook.com and properly connect.

  If this is NOT happening, maybe a cached DNS entry in memory (ipconfig /flushdns), incorrect DNS record.  Many times customers have on-premise Exchange and when sharing the SMTP namespace internally and in EXO365, it gets much more complicated.  In this situation, I have always either moved the MBX into the cloud using Exchange 2010 Hybrid server OR is went in and set the targetAddress of the on-premise user to user@domain.onmicrosoft.com, which is the user's Microsoft Online Default Routing Domain (MODRD), which WILL get Outlook to connect to EXO365.  It will use this *.onmicrosoft.com namespace to connect, but once connected and the connection settings are stamped on the Outlook profile, the user will use whatever their Primary SMTP address is.  So don't worry about using the *.onmicrosoft.com namespace for initial connection, unless you are using that for email, either way you are good!

   

  HTH

  ---

  Transitions Community Lead ...Ryan J. Phillips

  • Yanıt Olarak İşaretleyen FreeSoftDK 08 Şubat 2012 Çarşamba 15:13
  •  
   
• 02 Şubat 2012 Perşembe 04:18

   

   
  

  0

  Right, the Desktop Setup will NOT configure Outlook like the BPOS SIC did, which is causing confusion.  it is now the responsibility of the admin to create the DNS CNAME Autodiscover record to get Outlook to conect!

  Desktop Setup DOES configure the following:

  • Lync Client:  When you first run the Desktop Setup, it will ask for you to login.  That login is used to stamp your SIP Login name in the Lync client IF you decide to configure the Lync client
  • Creates a desktop shortcut I believe that points to your Microsoft Online Portal (MOP)

  HTH

   

  ---

  Transitions Community Lead ...Ryan J. Phillips
   
• 02 Şubat 2012 Perşembe 07:09

   

   
  

  0

  Hi FreeSoftDK, I would wait until after the user signs in for the 1st time AFTER Transitions, so the SIC can programmatically remove the PreferLocalXML and other Autodiscover registry settings.  once that is done, Outlook should be exited and restarted, at which point it will query for the AutoD DNS record, find it pointing to autodiscover.outlook.com and properly connect.

  Hi Ryan

  I have created a GPO that removes the XML files (the Sign In folder) and the registry keys, when the users logs in, and then I will remove BPOS SIC in the weekend.

  So I hope when they open Outlook the first time it query for the AutoDiscovery DNS record and connect.

  /Kim

   
• 08 Şubat 2012 Çarşamba 15:13

   

   
  

  0
  After a test with a few users over the weekend I did see that the BPOS Sign In client detected that mailbox was moved, so I decided not to remove the client before most of the users have been logged in, after the weekend.
  
  In most cases it worked fine, Outlook did automatic update it's configuration. Some not, but it was fast to put in the new server name, and get it working.

  • Yanıt Olarak Öneren Daniel Trautman 08 Şubat 2012 Çarşamba 20:36
  • Yanıt Olarak İşaretleyen FreeSoftDK 09 Şubat 2012 Perşembe 06:47
  •  
   
• 12 Şubat 2012 Pazar 04:09

   

   
  

  0

  Thanks Free, was looking forward to your update to see how your script performed.  Since the SIC uses the Service Object Model (SOM) to detect whether the user has Transitioned, I'm not sure if you can intercept this, as this is an internal AD attribute that holds this flag and is not publicly exposed.  I know it is a hassel to manage the SIC, in terms of when to uninstall, but our documentation states to wait until AFTER ~3 days, to allow clients to login, pickup the "USER HAS MOVED" flag and decomission the Outlook AutoD registry settings and allow Outlook to pick up the AutoD.[Domain].com DNS record.  HOWEVER this is the #1 issue we see right now, where Admins don't realize that they MUST create a DNS AutoD record, as they never had to do this before in BPOS.  So many clients login on Monday and have their AutoD registry settings removed BUT since there is no public DNS AutoD record, Outlook doesn't know where to go.  In this situation users could create a new Outlook profile and use their user@[domain].onmicrosoft.com, as Microsoft has Global AutoD CNAME records for all the different data centers and would allow Outlook to connect.  because they use the *.onmicrosoft.com namespace doesn't mean that is the Send From email address theyw ill use.  They will continue to use their Primary, this approach just gets them connected using a different namespace....until the admin can get the AutoD DNS CNAME record created, so outlook can properly connect!

  HTH

  ---

  Transitions Community Lead ...Ryan J. Phillips

  • Yanıt Olarak Öneren Ryanph [MSFT] 12 Şubat 2012 Pazar 04:09
  •