I have been working with a customer for the last few months now on their Migration in to Office 365 and come across some very strange issues with their environment. Some of these issues are down to their environment being so locked down and the latest one was just that.
When converting a domain from standard to federated I would typically run the Convert-Msoldomaintofederated CMDLet and jobs a good’un however with the likes of Hybrid AD you can convert the domain to federated through the Azure AD connect service. This way also adds all the additional Claim Rules in place for Hybrid AD. In fact, the Azure AD Connect service now offers a lot of extra features for user sign in and ADFS.
You can change the users sign-in from password sync, pass-thru, ADFS to which ever authentication method you want to.
Anyway, for this domain I wanted to change to ADFS.
It will ask you for global admin credentials to connect to the tenant and then domain admin credentials to then connect to the ADFS farm (this can also go and setup ADFS for you if you like but I’d always prefer to set that up outwith this).
It then goes away and creates a new Remote PS Session to the ADFS server, however, at this point it kept failing. After some digging it turned out I could not remote PowerShell to the ADFS server. Running the command
New-PSSession –ComputerName ADFSServer.domain.local would fail. However running
New-PSSession –ComputerName –ADCOnnectServer.domain.local worked. Strange, Right?!
Now I knew this customer had some weird and wonderful settings especially when it came to internet connectivity, everything went out through a proxy and there was no direct internet access for the servers. With that in mind, the AD Connect server had been configured with a proxy as it needed to talk to the internet, so this got me thinking that it was a proxy issue.
I did a NetSh WinHTTP show proxy and it displayed the proxy settings, I noticed that there was no bypass set. so my thought was that when you run the New-PSSession CMDLet was it was using the proxy to try and access the server even though it was on the LAN? I then set the proxy to bypass the local domain: by running:
netsh winhttp set proxy “proxy.domain.local:8081” “10.*,*.domain.local”
This then mean anything trying to access *.domain.local (dom01.local in this case) bypassed the proxy, I then tried
New-PSSession –ComputerName ADFSServer.domain.local and it connected.
So it appeared that PowerShell was trying to use the local proxy settings for connectivity. I knew that Exchange could be very picky about the proxy settings especially for the local system account when it came to certificates, but didn’t think it would be the case with PowerShell.
There are various ways of setting the proxy for the Local System account, one being NetSH and another is by using the PSExec tool from the old Windows Sysinternals (now run by Microsoft) to run Internet Explorer as the local system account and set the proxy from there.