Using Office 365 in an SBS 2008 Environment, Take 2

Mark Berry August 26, 2011

After working with a very helpful Microsoft Support manager, here are some updated suggestions to the problems identified in the first version of this article.

Getting Mail to Leave SBS

The support manager reminded me that Office 365 offers an email alias in the mydomain.onmicrosoft.com domain. If my primary email is myuser@mydomain.com, Office 365 lets me use myuser@mydomain.onmicrosoft.com as well. I had removed that alias but was able to re-add it through the Online Exchange mailbox configuration screen, under E-Mail Options.

So the solution is still to send the email to an account outside your domain, but you can use your custom subdomain on Office 365:

O365 and SBS Update 1

Getting Outlook to Autodiscover Office 365

While editing the Service Connection Point in Active Directory Sites and Services does work, it’s probably not the “approved” way to do things.

The support manager recommended that I instead use the Exchange Management Shell to entirely remove the Autodiscover Virtual Directory using Remove-AutodiscoverVirtualDirectory. Here’s how I did that:

1. Open an elevated command prompt and back up the IIS configuration (explained here):

%windir%\system32\inetsrv\appcmd.exe add backup "Before Removing Autodiscover"

2. Open an elevated Exchange Management Shell and retrieve the current autodiscover virtual directory:

Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, ExternalUrl, Identity

Save the results to a text file in case you need them to re-set the virtual directory later (see Schyler Jones’ comment below on December 2, 2015). Copy the Identity value to the clipboard.

3. In the Exchange Management Shell, remove the autodiscover virtual directory:

Remove-AutodiscoverVirtualDirectory –Identity "<identity value retrieved above>"

You will have to confirm by typing a “Y”.

4. Check that the autodiscover virtual directory is gone:

Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity

This should now return nothing.

5. Now, with Outlook running on a desktop, hold the Ctrl button, right-click on the Outlook icon in the system tray, and select Test E-mail AutoConfiguration. Enter your email address and password and click the Test button. The results should come from the Office 365 server.



44 Comments

  1. Using Office 365 in an SBS 2008 Environment | MCB Systems   |  August 26, 2011 at 10:54 am

    […] August 26, 2011 There is now an updated version of this […]

  2. Tim Carney   |  July 22, 2012 at 1:35 pm

    At least on my server, I needed to add quotes around the to get the command to work, so for your step #3 I used:

    Remove-AutodiscoverVirtualDirectory -Identity “”

    so, if your SBS server was named SBS the command would likely be:

    Remove-AutodiscoverVirtualDirectory -Identity “SBSAutodiscover (SBS Web Applications)”

  3. Mark Berry   |  July 22, 2012 at 2:34 pm

    Thanks Tim!

  4. David Ringwald   |  October 08, 2012 at 6:53 am

    You are awesome!
    Thank you so much for publishing this post. Microsoft has not been much help with this problem.

  5. Stewart Newfeld   |  November 16, 2012 at 6:29 am

    This post was very helpful and I used the technique to move try Office 365 for my client’s 6-users SBS2008 network. But they found office 365 too slow and decided they didn’t want it. Are there commands or a procedure to restore the AutodiscoverVirtualDirectory? Help would be greatly appreciated.

  6. Mark Berry   |  November 16, 2012 at 6:48 am

    Stewart, there is a New-AutodiscoverVirtualDirectory command but I’ve never used it.

    I can’t remember for sure why I included an IIS backup as the first step, but I have to think that it was to provide a way to reverse the procedure. The link in step 1 includes instructions on restore. It even says there are automatic backups before a change it made. Again, I haven’t had to do that.

  7. Stephan   |  December 31, 2012 at 8:39 am

    You sir are a genius! Microsofts best suggestion was to add a local autodiscover DNS entry which really doesnt help (although this is probably required for the final solution if the server is resolving the autodiscover locally as ours was) and their seccond suggestion was to add registry changes to every machine on the domain to disable local autodiscover – far from ideal!

    I did the above changes on an SBS 2011 so it would appear its fine for an Exchange 2010 environment. Worked instantly & the Outlook autodiscover test came straight back with the correct Office 365 details.

    Thanks again

    Stephan

  8. Bruce Berls   |  January 28, 2013 at 10:33 am

    Aargh! I just went through a migration and wrestled with this problem – and wound up with a registry entry on every machine to disable local autodiscover. (Which is a per-user setting, and requires a restart to be effective.) I wish I had known this 90 days ago! Thanks for the tip.

  9. Danny   |  April 13, 2013 at 9:24 am

    Thanks you saved my weekend !!!

  10. Enable Office 365 Auto-discover for Outlook in SBS 2011 Exchange Environments | Kirb.IT   |  April 29, 2013 at 2:20 pm

    […] Tip to mcbsys.com for pointing me in the right […]

  11. Bora   |  May 27, 2013 at 3:20 pm

    I followed the instructions and got autodiscover to show up correctly, but Outlook continues to keep prompting for the password for o365. The password works when I test externally? Outlook is installed on RDS or Terminal server.

  12. Mark Berry   |  May 27, 2013 at 10:58 pm

    Bora, of course it’s hard to say without fully understanding your environment, but offhand that doesn’t sound like an autodiscover issue. I blogged about one possible cause for repeated logon prompts back when I was using local Exchange:

    http://www.mcbsys.com/blog/2011/03/outlook-2010-repeated-logon-prompts/

    Maybe something similar applies for O365.

  13. Bora   |  May 28, 2013 at 12:49 am

    Mark, thanks for the reply. What I noticed is autodiscover on o365 seems to correct (nslookup is pointing correct to autodiscover.outlook.com), but it is still authenticating using local Exchange SBS 2008.

    I removed virtual directory, added cname internally to point to autodiscover.outlook.com and changed reply to email address to something different than o365, but all failed.

  14. Bora   |  May 28, 2013 at 8:32 am

    Mark, I noticed that it’s attempting to authenticate with the internal Exchange 2007 instead of going to o365 server. Even if I changed the DNS to use external, it keeps attempting to connect to local Exchange? Any ideas?

  15. Mark Berry   |  May 28, 2013 at 9:20 am

    Bora, the log tab of the Test E-mail Autoconfiguration tool described in the post might help you to follow what’s going on. For personalized support, you may need to contact O365 support and/or post in their forums. Also I don’t see the domain verification code in the public DNS records for employees.org–don’t know if that needs to stay there after verification, but I left mine in:

    http://onlinehelp.microsoft.com/en-us/office365-enterprises/gg584188.aspx

    You’ll also want to update your SPF record once you get things working.

  16. Mark Berry   |  May 28, 2013 at 9:32 am

    Bora, also just noticed that autodiscover.employees.org doesn’t resolve, at least not in the public DNS. You need to set up a CNAME for that. http://help.outlook.com/en-us/140/cc950655.aspx.

    I seem to remember some step-by-step process for all the domain changes needed to get O365 working…

  17. Steve b   |  May 28, 2013 at 7:33 pm

    Thanks for this post. The PS script to remove the auto discover virtual directory worked perfect. Outlook now resolves the correct information from o365.

  18. Bora   |  May 28, 2013 at 9:11 pm

    Quick update… There is setup for the desktop from o365 to download and install. They call it a hotfix for Outlook 2010. Now it resolve and correctly authentication with o365.

  19. Mark Berry   |  May 28, 2013 at 9:44 pm

    Bora, thank you for the update. Glad you got it working. What is the KB number for the hotfix? Do you have Service Pack 1 for Office 2010 installed? It would be good to know if the hotfix is necessary if the program is fully patched by automatic updates.

  20. Chad   |  November 06, 2013 at 5:43 pm

    Thanks so much. Been fighting this for a few days and this seems to have resolved the issue

  21. Jason   |  February 05, 2014 at 10:40 am

    This works! Shame on Microsoft for not better documenting how to disable Autodiscover on their Exchange servers. This issue has haunted my team for a year. We played all kinds of stupid games with DNS that only marginally worked and wasted huge amounts of time. We’re Microsoft partners ourselves and Partner support told us this was not possible.

    As a side note there was residual damage to the Out of Office feature in Outlook caused by this. Even after this fix we still got the error “Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later”. To correct this visit this URL from the client machine: https://outlook.office365.com/EWS/Exchange.asmx (it’s the OOF URL). Then enter the users Office 365 credentials. You are directed to a page telling you how to further test the “service you enabled”. Ignore the provided instructions and simply close the browser and try OOF from Outlook again.

  22. Brian   |  September 05, 2014 at 8:37 am

    My solution was to rename the autodiscover folder on the SBS Server (Stop IIS first).

  23. Randall   |  December 04, 2014 at 1:47 pm

    Worked perfect,. Like the other guy said put the identify in quotes to properly format it.

  24. Mark Berry   |  December 04, 2014 at 5:27 pm

    Thanks Randall. I’ve updated the post re. the quotation marks.

  25. David Moen   |  February 05, 2015 at 12:12 pm

    I’m having this issue on my SBS network right now, I have deleted the virtual directory as per the instructions here, confirmed that it has been remove, and even created a CNAME record pointing autodiscover to autodiscover.outlook.com. I have flushed DNS caches at my workstation, and on the server. Outlook still insists on connection to my SBS box. Any further ideas?

  26. Mark Berry   |  February 05, 2015 at 12:56 pm

    David, sounds like you’ll have to track the DNS queries. I’d remove that CNAME to get back to a standard config. On the workstation, use “ipconfig /all” to confirm that it is using the SBS server as its only DNS server (and not, for example, the router). Use “nslookup” to check for how it resolves autodiscover.yourdomain.com, again making sure that the SBS server is the DNS source. If it’s the server returning incorrect info, check its DNS config, both in the NIC and in the DNS service. What are the forwarding servers? If the router is in the list, what are ITS servers? Does nslookup autodiscover.yourdomain.com work on those servers? If not, is your public DNS configured correctly for Office 365?

  27. Paul   |  March 02, 2015 at 5:02 pm

    Do you know if this change will affect OWA on the SBS Exchange? We still need to access it for Public Folder data temporarily, but want to fix this Autodiscover issue immediately.

  28. Mark Berry   |  March 02, 2015 at 6:11 pm

    Paul, as far as I know, Autodiscover is only used by actual mail client programs (Outlook, phone apps, etc.). OWA just uses the URL to find your server, and that won’t change.

  29. Ashraf   |  May 23, 2015 at 7:05 pm

    Thanks for your help. I would like to add..After applying this post run Office tools from the office365 portal even if you run the latest version of MS Office>Create new outlook profile and it works fine.

  30. Frederick Pageau   |  September 05, 2015 at 2:22 pm

    THANKS very much for this great solution! It’s work now … since 2 hours to search this post.

    Very simple and complete.

  31. James   |  September 11, 2015 at 6:41 pm

    Hi Mark,

    I just ran into this today. I removed the virtual directory successfully but I still ran into issues when I tried to move clients to Office 365. I even flushed dns on computers & server. I used the tool built into Outlook (test email auto configiguration) and could see that the computers saw it pulling the XML file through SCP. It was a smaller job so I ended up modifying the registry settings on the computer to avoid the SCP connection, but I’m still here wondering what the deal is? Shouldn’t removing the virtual directory solve the issue? I’m sure if I went into SCP and changed it to point to autodiscover-s.outlook.com I could have solved it but I decided it wasn’t worth the time . Thoughts? Thanks!

  32. Mark Berry   |  September 12, 2015 at 8:31 am

    James, I guess you could run nslookup and maybe Wireshark on a workstation to trace where the DNS lookups are resolving. Maybe something cached in the router? An issue with the autodiscover definition in public DNS? See also 2/15/2015 comments above.

  33. Schyler Jones   |  September 18, 2015 at 9:11 am

    I used the steps to delete the Autodiscover virtual directory and then verified that Autodiscover was working, by right-clicking on the Outlook icon to run the test. However, When starting Outlook, it prompts for credentials for the SBS server and after a couple of tries you get to the mailbox – on the SBS server. I also noticed that the Outlook profile is still pointing to the SBS server and there’s no way to change it. However, I created a new profile, added an Exchange account, and Outlook found the Office 365 account and set itself up just fine. I was under the impression from the article that no changes would be needed to the Outlook profile but apparently you have to create a whole new one, and its surprising that isn’t mentioned anywhere (not just here), so makes me wonder if I did something wrong. Unfortunately there are still a few emails in the old outboxes that I hoped to forward to the onmicrosoft.com addresses in order to easily get them over to Office 365. However, the onmicrosoft.com addresses apparently are no longer used. I know they used to be – my own Office 365 account and others I have setup, all had them, but this new account I setup this week does not.

  34. Mark Berry   |  September 18, 2015 at 12:16 pm

    Schyler – things certainly could have changed since I wrote this four years ago. It may have to do with how you reference the mail server in your Outlook profile–whether using the local DNS name or the public DNS name.

    My [domain].onmicrosoft.com address still works. But you can always copy messages to a PST and re-copy them to another account.

  35. Schyler Jones   |  December 02, 2015 at 4:27 am

    I wanted to post back to update my initial comment – my issue was about Outlook profiles and after a lot of reading I concluded what is apparently obvious, but somehow is a glaring omission from all of the Office 365 migration information published on the web – even Microsoft’s own documentation. They all fail to even mention this despite their otherwise mostly detailed and very useful migration guides. There are two highly important pieces of information that are lacking:

    1. For Outlook users, a new Outlook profile must be created.
    2. For mobile device users, the existing account for the source Exchange server must be removed, and a new one added for Office 365.

    I struggled with trying figure out how to ease the pain of having to perform the above steps manually – I understand that there are 3rd-party tools that can help, and I may consider trying them in the future. https://www.bittitan.com/ is one source. In our latest migration we tried out, with success, a free tool at http://config365.com/, which simplified the process of creating new Outlook profiles, but it still requires that each PC/User Profile be touched and there are multiple steps that still must be performed – because users are getting a new Outlook profile, any associated settings are lost such as Views and Signature settings (Signatures themselves are not lost, just the settings for New Messages and Replies).

    I found nothing to facilitate the required changes on mobile devices.

  36. Schyler Jones   |  December 02, 2015 at 5:21 am

    Related to our latest migration effort, I wanted to post about a situation we encountered and what we did to resolve it.

    The evening before our scheduled visit to the client to begin the process of switching over their Outlook and mobile device users from their on-premise Exchange (SBS 2011), we took the final steps on the “back end” – we ran a final batch migration, and after it reported success on all 46 mailboxes with NO ERRORS, we changed the MX record, added the autodiscover record, and removed the autodiscover virtual directory as discussed here. Having autodiscover up & running facilitated getting email working on mobile devices as most users were able to perform the required changes using our relatively simple procedure we had circulated a few days before. Without autodiscover, the process would have been more complicated. I’m not sure if autodiscover was needed for the Config365 tool mentioned in my previous post or not. In any case, things looked well and we were way ahead of schedule on the migration, then it happened…

    Users began reporting they were missing messages! Now, I’m fairly sure that this was most likely a result of not giving the new MX record time to float around the Internet since the migration report showed NO ERRORS. I figured the fix was easy, just run another migration batch sync – NOT! The Office 365 batch migration relies on Autodiscover to find the source Exchange server and it could no longer communicate with the Exchange server because we had changed the autodiscover record – UGH! I spent a couple of hours trialing MigrationWiz in hopes it could sync mailboxes despite the autodiscover situation and after I finally got it working, bought a single mailbox license and ran a migration on a test user… it worked, but it resulted in duplicate messages since MigrationWiz apparently doesn’t have the capability to deal with emails that may already exist in the target mailbox.

    I was left with no choice other than to restore the original autodiscover CNAME record (I thought that was all I had to do), but then I realized I was also going to have to restore the autodiscover virtual directory that had been deleted already, and I didn’t run a backup command. HOWEVER, more Googling led me to what turned out to be a relatively easy solution – there is an Exchange Shell command that will recreate the autodiscover virtual directory, and it worked beautifully!

    First, I would modify step 2 above to include the External URL:

    Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, ExternalUrl, Identity

    Note the values returned for possible use later – I hadn’t, but we have other customers running SBS 2011 and we were able to examine the output of the Get command on another customer’s server in order to determine what we need to supply for these parameters. The recreate command was:

    New-AutodiscoverVirtualDirectory -WebsiteName "Default Web Site" -WindowsAuthentication $true -BasicAuthentication $true

    Note: The WebsiteName in the example worked fine in this instance, even though it didn’t exactly match the the value for “Name” that was shown by the Get command, which was “Autodiscover (Default Web Site)”.

    Then you need to re-add the URLs with this command:

    Set-AutodiscoverVirtualDirectory -Identity "<Identity>" -ExternalUrl "<ExternalUrl>" -InternalUrl "<InternalUrl>"

    In our case the URLs were the same:

    https://remote.bugsbunny.com/Autodiscover/Autodiscover.xml

    After doing this, the Office 365 migration batch was able to execute, and bring over the missing email. Of course I then had to repeat the steps that the original post provided to re-remove the virtual directory (and switch the CNAME record back to autodiscover.outlook.com.

    Thanks to Yuval Sinay for his post at:

    http://blogs.microsoft.co.il/yuval14/2011/07/08/how-to-reset-exchange-2010-autodiscover-virtual-directory/

    His guidance made our efforts successful!

    Also, thanks to Mark for having started this whole thread with your VERY helpful information!

    This experience raises another concern – if you wait to make the autodiscover changes, which Microsoft’s guidance suggests, you cannot rely on it to facilitate client device migration as they will all require manual configuration. Phooey, what a pain! Perhaps it is my feeble mind’s inability to see another way of doing this? I will say that I might rely on MigrationWiz for the next migration since it does not rely on the Autodiscover record, you have to pay for it, but in the grand scheme it would have paid for itself in my case with all of the time I spent on the issues described. They also have a tool to automate changes to Outlook, but I haven’t tried that one out yet.

  37. Schyler Jones   |  December 02, 2015 at 5:33 am

    I noticed that the server removed some key details on the Set URL command, it apparently doesn’t like the use of brackets to represent a variable… also, watch out for the quotes around my commands, I copied and pasted out of Notepad so hopefully they’ll work. Anyway, here’s the set command with brackets removed:

    Set-AutodiscoverVirtualDirectory -Identity "Identity" -ExternalUrl "ExternalUrl" -InternalUrl "InternalUrl"

  38. Mark Berry   |  December 02, 2015 at 9:57 am

    Schyler, thanks for those follow-ups. I’ve updated step 2 in the original post per your suggestion. I think I managed to get the formatting of your comment back the way you intended:

    – Use <code> and </code> tags to force "straight" quotation marks to display properly. Alternatively, you can use the HTML entity &quot; if you don’t want the "text" to appear in code font.

    – Use HTML entities for less-than (&lt;) and greater-than (&gt;) <brackets>, which also preserves the text within the brackets.

  39. Bob Cymbalski   |  December 25, 2015 at 7:07 am

    Merry Christmas all. In the middle of an Office 365 migration… of course over Christmas so it doesn’t impact the business :) And, of course, ran into the horrible issue where after I manually configured all of the office 365 settings SBS 2008 autodiscover took over and undid all of my work. Luckily, I stopped for the day, came back in this Christmas Morning, and found this set of instructions that worked perfectly. Thank you to everyone who contributed and documented this solution… as you saved me months of headaches (this also explains why a hosted exchange project we had two years ago failed).

  40. Office 365 migrations | PowerBiz Solutions   |  March 20, 2016 at 5:11 am

    […] For SBS 2008 – http://www.mcbsys.com/blog/2011/08/using-office-365-in-an-sbs-2008-environment-take-2/ […]

  41. Edgar   |  March 29, 2016 at 10:50 am

    It’s amazing in support of mee to have a website, which is useful inn favor of my experience.
    thanks admin

  42. Ian   |  May 10, 2016 at 9:08 am

    Looking at moving someone to O365 from SBS, would not changing the SBS email domain not be a easy option. eg joebloggs.com to joebloggsretire.com

    it leaves data on server for archive and changes/removes old auto-discover records. then just recreate new Outlook profiles?
    Yes you lose RWW but if you going O365 you wont need that anymore.

  43. Mark Berry   |  May 10, 2016 at 11:10 am

    Ian, haven’t looked at this in some time so I can’t say whether that would work. I would think you could set up joebloggsretire.com as a completely new O365 domain and not touch SBS. Then use Outlook to connect to both the SBS domain and the O365 domain. That’s not a migration; it’s a new domain on a cloud server only. Then each users has two mailboxes though. You can use Outlook rules to copy incoming messages on the old domain to the new mailbox until you finally decide to kill off the old domain.

  44. Michael   |  July 10, 2016 at 2:43 pm

    I simply deleted the forwarder for remote.%domainname%.com from the local DNS server (running on the SBS). Once that was completed, Outlook client setups ran smoothly.

    This seems to be the early iteration of AutoDiscover and is hardcoded on the AD information for the user. It was only a problem when their domain login information matched their O365 login into (i.e. their email address)

    Great information on a slightly obscure problem. Shame on MS for not having more information available up front on the symptoms.

Leave a Reply





*

Notify me of followup comments via e-mail. You can also subscribe without commenting.