PSRemoting for Office 365 AD FS Configuration

When configuring AD FS for Office 365, one of the final steps is to link Azure AD with the on-premises AD FS deployment.  This should occur only after AD FS and WAP servers have been fully deployed, verified and tested.

When linking the AD FS infrastructure with Office 365, we must use the Azure AD PowerShell module.  We need to point the module at the primary AD FS server using the Set-MsolADFSContext cmdlet, if the module is not executed locally on the primary AD FS server.

If everything just works, then there would be no need for this blog post and life would be far less interesting.  One of the requirements is that the AD FS server has PSRemoting enabled.  If PSRemoting is not enabled, a firewall blocks it or the WinRM service is not running you will not be able to complete the required configuration.

The below screenshots illustrate the observed behaviour if we run into PSRemoting issues.

Note that the AD FS servers require Internet access on TCP 80 and 443 to connect to Azure AD and complete the configuration.  TCP 80 is required for Certificate Revocation List checks and TCP 443 is for the actual service communication.

Lab Configuration

In this lab we have AD FS 2016 deployed.  All of these machines are part of the same AD Domain in the same forest.  We are logged on as a domain admin account so we do not have to worry about security assignment issues in this post.  We can focus on the PSRemoting aspect.

On the primary AD FS server, the WinRM service was deliberately stopped.  This is shown in the PowerShell window below.

WinRM Service Stopped - Status Shown In PowerShell

To prove that the server is not listening on the regular PSRemoting ports, we check using netstat.  Note that no services are listening on TCP 5985 or TCP 5986.

Primary AD FS Server Hostname Shown - Netstat Unable to Enumerate PSRemoting Ports


Authentication Prompt Due to PSRemoting Denied

What happens if we now go to a remote machine and try to point the Azure AD module to this AD FS server using the Set-MsolADFSContext cmdlet.  In the below example note that the server name is the same hostname which was displayed above:

Set-MsolADFSContext –Computer

Set-MsolADFSContext - Unexpected Password Prompt

Oh – that did not end well.  We got an authentication prompt.  How come?  We are logged on as a domain administrator account, and you can see that the PowerShell instance is running as administrator.

Even if you correctly enter the credentials into the prompt, the command still fails.  This is most likely due to PowerShell remoting NOT being enabled on the server that the –Computer parameter specifies.  In our case the server:

To troubleshoot the issue, we can review the Azure AD Module’s log file.  This is located in:


The below is an excerpt from the log file.  The highlighted line indicates that we are unable to connect to the primary AD FS server on TCP 5985.

5/14/2017 4:05:26 PM    Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default AppName:wsman, Shell:
5/14/2017 4:05:26 PM    Connection Uri:
5/14/2017 4:05:26 PM    Opening runspace to ‘’
5/14/2017 4:05:47 PM    System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server failed with the following error message : WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. For more information, see the about_Remote_Troubleshooting Help topic.
at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()

Authentication Prompt Due to Incorrect AD FS Server Name

Another cause for unexpected authentication prompts when using the Set-MsolADFSContext cmdlet is a typo in the specified AD FS server name.

AD FS Service Running On Primary AD FS Server -

Note that the WinRM service is running on the primary AD FS server.  The server’s FQDN is also displayed: ADFS-2016-1  – note though that in the below command an incorrect name will be used.

The “AD” in the server name was transposed.  This is to demonstrate what will happen if the wrong name is used.

Set-MsolADFSContext –Computer

Unexpected Authentication Prompt When Configuring AD FS With Office 365 - OOPS Type In Server Name

 Note that the big red arrow indicates that the authentication request specifies the wrong server name AFDS-2016-1.  The characters are transposed.

Enabling or Disabling PSRemoting Access Denied

In current versions of Windows we have the Disable-PSRemoting and Enable-PSRemoting cmdlets.  On one AD FS 2016 lab system, I was not able to run these commands.  They would both generate an access denied error.

Disable-PSRemoting and Enable-PSRemoting Cmdlets - Access Denied

For the search engines:

Disable-PSRemoting -Force
WARNING: Disabling the session configurations does not undo all the changes made by the Enable-PSRemoting or
Enable-PSSessionConfiguration cmdlet. You might have to manually undo the changes by following these steps:
1. Stop and disable the WinRM service.
2. Delete the listener that accepts requests on any IP address.
3. Disable the firewall exceptions for WS-Management communications.
4. Restore the value of the LocalAccountTokenFilterPolicy to 0, which restricts remote access to members of the
Administrators group on the computer.
remove-item : Access is denied.
At line:69 char:21
+ …                   remove-item -path “$securityIDPath” -recurse -force
+                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Remove-Item], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.RemoveItemCommand

new-item : Access is denied.
At line:74 char:21
+                     new-item -path “$securityPath” -Sddl $sddl -force
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [New-Item], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.NewItemCommand

PS C:\>
PS C:\> Enable-PSRemoting -Force
remove-item : Access is denied.
At line:69 char:21
+ …                   remove-item -path “$securityIDPath” -recurse -force
+                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Remove-Item], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.RemoveItemCommand

Looking at access denied errors in Sysinternal’s Process Monitor we can see that there were issues writing to the registry.

Sysinternal Process Monitor - Filter to Show Access Denied Only

Specifically this was under the key:


PSRemoting should be enabled by  default on current Windows builds.  This should be verified prior to installing AD FS.



Comments (2)

  1. turbomcp says:


  2. robin says:

    Nice article

Skip to main content