Using Office 365 in an SBS 2008 Environment, Take 2

Posted on by

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 [email protected], Office 365 lets me use [email protected] 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.

46 thoughts on “Using Office 365 in an SBS 2008 Environment, Take 2”

  1. Pingback: Using Office 365 in an SBS 2008 Environment | MCB Systems

  2. Tim Carney

    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)”

  4. David Ringwald

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

  5. Stewart Newfeld

    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 Post author

    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

    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

    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.

  10. Pingback: Enable Office 365 Auto-discover for Outlook in SBS 2011 Exchange Environments | Kirb.IT

  11. Bora

    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.

  13. Bora

    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

    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 Post author

    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.

  17. Steve b

    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

    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 Post author

    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

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

  21. Jason

    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

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

  23. Randall

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

  25. David Moen

    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 Post author

    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

    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 Post author

    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

    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

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

    Very simple and complete.

  31. James

    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 Post author

    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

    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 Post author

    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

    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

    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

    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 Post author

    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

    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. Pingback: Office 365 migrations | PowerBiz Solutions

  41. Edgar

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

  42. Ian

    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 Post author

    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

    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.

  45. ian

    Brilliant article – one extra step i had to complete was to restart IIS after removing the virtual directory/identity.

    it was only after i’d run ‘iisreset’ via elevate cmd prompt that the client outlook would work.

Leave a Reply

Your email address will not be published. Required fields are marked *

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