Yes, SBS 2008 is no longer supported. But I still have one remaining customer using it. This weekend I moved their email over to Office 365. I figured if I still have one site, there may be others in the same boat.
For this customer, after making a backup PST file for each user, I went into Services from the SBS 2008 server and disabled of the Exchange services from running.
The other thing that needs to be done is to prevent Outlook from looking to the SBS server for its AutoDiscover information. The process is very easy using two Exchange Powershell commands. Mark Berry’s excellent blog post from August 2011 provides the detail steps, including doing a quick backup of IIS, before removing the AutoDiscover Virtual Directory.
Here are the basic steps involved, all done from the SBS 2008 console:
- Open up an elevated Exchange Management Shell
- Display the current AutoDiscover virtual directory settings using this command
Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, ExternalUrl, Identity
- Make note of the value of the Identity field.
In my case it was: SERVER01\Autodiscover (SBS Web Applications)
- Remove the AutoDiscover virtual directory with this command:
Remove-AutodiscoverVirtualDirectory –Identity "<identity value retrieved above>"
In my case I entered:
Remove-AutodiscoverVirtualDirectory –Identity “SERVER01\Autodiscover (SBS Web Applications)”
You will be prompted to respond with “Y” to proceed
- Then verify that the AutoDiscover virtual directory is no longer there
Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity
Note: no rebooting of the server is required. At this point after installing Office 2016, click to start up Outlook. My understanding is that these steps will also work with SBS 2011.
Microsoft announced yesterday (June 30, 2015) the availability of the PowerShell for Office 365 for IT administrators.
I would suggest that you first read their blog post on Getting Started with PowerShell for O365.
PowerShell for O365 is not intended to replace the O365 Admin Center, but rather it provides complementary tools for such scenarios as:
- Adding or editing a large number of users
- Using multiple filters when sorting data
- Exporting data such as user lists and groups
- And more …
The web site includes sample scripts, scenarios, and community interaction. Check it out!
Here are some useful web sites to check on the current status and outages for O365 —
Office 365 Down Detector: https://downdetector.com/status/office-365
Office 365 Service Health Status: http://status.office365.com/
Office 365 Twitter Status: https://twitter.com/office365status
Earlier I posted about a situation where the O365 Integration Wizard that is built into the 2012 R2 Essentials Server would fail when trying to set it up the first time.
Today, the Windows Essentials and SBS support team posted a revised blog saying that the problem with the PCNS.zip file had been resolved.
The revision eliminates the need to download the correct PCNS.zip file. Apparently there’s no hotfix or update to be downloaded. They fixed it on their end so that when you run the O365 wizard it will download the correct zip file.
I have an existing client with a Windows 2012 R2 Essential server. I was migrating their email from a GoDaddy POP3/IMAP host over to Office 365. This was going to be my first opportunity to try out the O365 Integration Wizard that comes with the 2012 R2 Essentials dashboard.
On May 23rd I set up their Office 365 accounts, setup the DNS records on GoDaddy, and then migrated their email to Office 365, all which went smoothly.
On May 26th I attempted to run the O365 Integration Wizard. After entering the O365 admin account and login info, it errors with this message: “There was an issue configuring the integration. Make sure the computer is connected to the internet and then try again.”
I did a lot of web searches, and finally located several posts from people indicating that the error may be related to a corrupt or invalid PCNS.zip file:
What’s PCNS? It stands for Microsoft’s Password Change Notification Service which synchronizes user passwords in an enterprise environment.
I confirmed that this was the error by looking at the SharedServiceHost-EmailProvider Config.log file located at C:\Program Data\Microsoft\Windows Server\Logs folder.
The suggested fix was to rename the existing PCNS folder and PCNS.zip file, then download a different PCNS.zip file, and then rerun the wizard. Initially it did not work for me, because I was manually unzipping the corrected PCNS.zip file before running the O365 Wizard. Finally it dawned on me to just download the zip file, and sure enough, the O365 Wizard unzipped it, and we finally had success!