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 domain. If my primary email is, Office 365 lets me use 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, Identity

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>

Update December 4, 2014 Per a couple of comments, the identity string should be enclosed in quotation marks:

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.


  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


  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 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:

    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, but it is still authenticating using local Exchange SBS 2008.

    I removed virtual directory, added cname internally to point to 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–don’t know if that needs to stay there after verification, but I left mine in:

    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 doesn’t resolve, at least not in the public DNS. You need to set up a CNAME for that.

    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: (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 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, 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 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 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 addresses in order to easily get them over to Office 365. However, the 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] address still works. But you can always copy messages to a PST and re-copy them to another account.

Leave a Reply

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