Help the Outlooks are down

So I was contacted by a panicking client. It seemed that all of his Outlook clients could not connect to Office 365 anymore. That meant investigating what was wrong. Upon inquiring he admitted that he changed some DNS settings the day before. But only the SPF record. That didn’t explain connection issues with their Outlook clients. Naturally the first thing I checked where there public DNS settings. There did not seem to be anything out of the ordinary there, apart from a tiny mistake in the SPF record they created. That did not present any insight in what might was causing this problem.

A couple of days earlier we did renew the Exchange certificate on the on premise Hybrid server. But since the auto-discover DNS records where pointing at Office 365 this should not be a problem.

So I turned to my trusty connection testing toolset provided by our friends at Microsoft:
There on the Office 365 tab I ran the Outlook connectivity test. The following picture is a screenshot of a part of the test outcome. Funny thing that HTTP 503 error for the Office 365 auto-discover service.

Connectivity Test

A little web research suggested to recreate the federation link with Office 365. I felt that would be a little bit of exaggeration. What else could be responsible for an Office 365 service being unavailable? Needless to say, I tested another tenant. That one seemed to have no problem what so ever. Then it hit me. A quick question to their administrator if anything had changed at the Federation servers of domain controllers confirmed this. Yes, updates where installed, zero reboots given. Great, go reboot those machines….
5 minutes later I got a very happy and relieved sysadmin on the phone confirming that everything was working again. He also informed me they where able to log into on premise servers again. He forgot to mention that fact in an earlier conversation…..*sigh*


If you cannot log into your federated Office 365 environment, check your Domain Controllers and Federation servers. Something might be out of order there.

SkyDrive crashes on my domain machine

I while ago I wrote about restoring your Win-X menu when this did not show up after migrating from a Windows 7 member client to a Windows 8 member client. And by member client I mean active directory member.

It turns out this problem still exists in Windows 8.1. Also in Windows 8.1 there seems to be a problem with your SkyDrive (OneDrive) integration. As in some cases it turns out that your SkyDrive will crash and not sync.

So here is a nice script to fix your Win-X menu and Skydrive:


reg add

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{8E74D236-7F35-4720-B138-1FED0B85EA75}\ShellFolder /v Attributes /t reg_dword /d 0x00100000 /f

reg delete "HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\WinX-fix-%COMPUTERNAME%" /f >NUL 2>NUL

reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\WinX-fix-%COMPUTERNAME%" /v Version /t REG_SZ /d "1" /f

reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\WinX-fix-%COMPUTERNAME%" /v StubPath /t REG_SZ /d "\"%ProgramFiles%\windows-8-fixes\fixWinX.cmd\"" /f

Reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v DisablePersonalDirChange /t REG_DWORD /d 0 /f

xcopy /S /C /I /Q /H /R /Y "%PUBLIC%\..\Default\AppData\Local\Microsoft\Windows\WinX\**" "%LocalAppData%\Microsoft\Windows\WinX"


If for any reason the service formally known as SkyDrive is not working after the script above, try the following

Reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v DisablePersonalDirChange /t REG_DWORD /d 0 /f

Also, this script can be incorporated into your deployment image, but also be deployed through active directory. Remember that this is a CMD script, and this can also be done trough PowerShell cmd-lets.

Just remember you need to run this with administrative privileges.

Convert-MSOLDomainToFederated: Service not available

AAAAAAH….this is not a typical reaction I have when setting up things, but this one was driving me nuts. Let me explain…

Story so far…

I was asked to help a company with the implementation of Single Sign-on (SSO) between their on-premises environment and Office 365. During the installation and configuration phase of the ADFS 2.0 servers we ran into an error that drove me nuts. This process should be fairly easy. To help you through this process of deploying SSO, there are tons of guides to be found on the interwebs to set up SSO for your Office 365 services. Just check it out. I like this one in particular.In short: to create a federated connection with Office 365 in the cloud you have to do a couple of things:

  • Get an Enterprise CA Certificate
  • Configure Office 365
  • Install and configure ADFS 2.0
  • Install and configure DirSync

After the setup of ADFS 2.0 you will come across the Microsoft Online Services and connecting to them and then converting your registered Office 365 domain to a federated domain;

Keep in mind:I’m doing this from the ADFS server itself, so no need for the Set-MsolADFSContext –Computer cmdlet.Note:I’m using another DNS domain name in the commands below to protect the innocent. Winking smile

First Connecting:

Then the update cmdlet:
Update-MSOLFederatedDomain -DomainName -SupportMultipleDomain

The Problem

When everything goes well, no output will be generated. But in this case it gave me the following output:
Convert-MsolDomainToFederated -DomainName -SupportMultipleDomain

Convert-MsolDomainToFederated : Service not available

At line:1 char:30+ Convert-MsolDomainToFederated <<<<  -DomainName -supportMultipleDomain

+ CategoryInfo          : InvalidOperation: (:) [Convert-MsolDomainToFederated], FederationException

+ FullyQualifiedErrorId : InternalError,Microsoft.Online.Identity.Federation.Powershell.ConvertDomainToFederated

Since I was not the one who configured the Office 365 domain and there seemed to be a problem with the Office 365 authentication service, I assumed there was a problem with the services. I tried again after the weekend and was surprised to get the same result. So I guess it’s true what they say about assuming things.

Note:You can check the status of Office 365 services when you log into the Office 365 admin center

After checking everything, and I mean going over the entire installation up until the error, I still could not find any reason for this not to work. So I called Microsoft. The technician went over the process and after consulting with his colleagues a couple of times, came up with the suggestion of checking the account settings of the account we used to login into Office 365 with the Connect-MSOLService cmdlet. Explicitly we needed to check the password expiration policy.


After the suggestion to set the value for Days before passwords expire: to 90 instead of 730 running the Update-MSOLFederatedDomain cmdlet gave no trouble whatsoever. Setting up DirSync went like a breeze and Single Sign On is actually quite sexy…

Keep in mind:I was not the one who configured Office 365 for this scenario or thought these settings were a good idea 


It’s strange the password expiration policy affects converting a domain and the PowerShell output is cryptic. I hope this helps in case you run into the same situation I did. This is how I did it…