Applies to

This article applies to Windows 2008R2, FIM2010R2, and Exchange 2010 running WinRM 2.0 and PowerShell 2.0.



The first consideration in a cross-forest GalSync solution is the configuration of the Forest trusts.



The basis of the RemotePowershell connection in the FIM GalSync solution comes from WinRM.

Network ports

AD Domain

  • At a minumum for your MA to connect to the target forest, you must have TCP port 389 open to the Domain Controller your MA is configured to use.
  • Port 636 is required if you have selected an encrypted LDAP connection.

Remote Powershell

Domain controllers

For the Remote Powershell/WinRM session to successfully function, the following ports must also be open to all Domain Controllers in the target forest which are returned by a login request as any of them could be queried for a Kerberos ticket:

  • TCP and UDP 88 – Kerberos ticket request and response
    • Without this port open you will get “Access denied” errors in the event log when the MA runs an Export operation.
  • TCP and UDP 53 – DNS
    • Without this port open, authentication requests take approximately 3 to 4 minutes to complete and may result in time-outs on Export operations.
  • TCP 3268 and 3269 (optional SSL) – Global Catalog/LDAP
    • The Remote PowerShell session first queries the GC then tries LDAP over 389 if 3268/9 are not open.

FIM to Exchange CAS

Additionally, WinRM and Remote PowerShell require ports to be open between your FIM Server and the Exchange CAS

  • WinRM 2.0 requires ports 5985 and/or 5986 to be open from the FIM Sync server running your Management Agents to the Exchange CAS your MA is using in the target forest.
  • The PowerShell URI runs under IIS on port 80 or 443. The appropriate port for your solution must be open for connections from the FIM Server to the Exchange CAS your MA is using in the target forest.
  • Add the Exchange Server to the list of trusted hosts on the FIM Server
    • FIM Server: winrm set winrm/config/client @{TrustedHosts="RemoteComputerFQDN"}
  • WinRM must have Kerberos authentication enabled
    • Kerberos requires TCP and UDP port 88 to be opened from the FIM server to ALL Domain Controllers in the target Forest.
    • FIM Server: winrm set winrm/config/client/Auth @{Kerberos=”true”}
    • Exchange CAS: winrm set winrm/config/service/Auth @{Kerberos= true”}
  • If you wish to enable SSL over WinRM
    • WinRM HTTPS requires a local computer "Server Authentication" certificate with a CN matching the hostname, that is not expired, revoked, or self-signed to be installed
    • Exchange CAS only: winrm quickconfig –transport:https
  • If you are not using SSL:
    • FIM Server: winrm set winrm/config/client @{AllowUnencrypted="true"}
    • Exchange CAS: winrm set winrm/config/service @{AllowUnencrypted="true"}


Testing the RemotePowerShell connection outside of FIM

To quickly test the functionality of the RemotePowershell URI your Management Agent requires, the following PowerShell commands will simulate the connection exactly as FIM uses it.

From a 64-bit PowerShell command prompt:

  • Get-ExecutionPolicy
  • If it does not allow scripts then run:
    • Set-ExecutionPolicy RemoteSigned
  • $User = Get-Credential
    • Enter the Domain\Username of your service account which resides in the target forest.
      • ie: TargetForest\svc_ForestB_galsync
    • Enter the password for the service account
  • $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<CASSERVER>.<domain>.<root>/PowerShell/ -Credential $User -Authentication kerberos
    • This command is from a working system. Capitalization counts.
    • If it works, it simply returns you to the prompt.
  • Import-PSSession $Session
    • This imports the Exchange commandlets from the remote system
    • This should generate some Powershell dialogs at the top of your command window while it imports the commandlets.
    • If the estimated time for import exceeds a few minutes it’s likely port 53 is not properly opened between your FIM Server and the Exchange box.
  • Get-ExchangeServer
    • This should return information about the Exchange CAS to which your are now connected.
  • Remove-PSSession $Session
    • Disconnects from the Exchange CAS.


If this works without errors then your GalSync MA will connect to Exchange when it attempts to Export.


Troubleshooting this manual connection:

You can skip certificate checking with the following options in the $Session command:

  • - SkipCACheck -SkipCNCheck -SkipRevocationCheck

You can try Basic authentication by changing –Authentication kerberos to –Authentication basic

  • basic and kerberos must be lower-case
  • basic authentication works without port 88 open

Try with the IP address of your Exchange CAS and Basic Authentication if your connection takes minutes to connect or error out.

  • Long connection times likely indicate an issue with port 53 on your target forest Domain Controllers.
  • Kerberos won’t accept an IP address so you have to switch to basic for this test.


Testing the basic WinRM connection

Create the $User credential as with the PowerShell test above

  • Enter-PSSession –ComputerName –credentials $User

For –ComputerName you can use the FQDN or the IP of your Exchange CAS.

If this connection works then you have WinRM working over port 5985 or 5986.



Below you'll find a sample error message if the remote PowerShell fails (for search & reference)

Windows PowerShell

Copyright (C) 2013 Microsoft Corporation. All rights reserved.


PS C:\Users\administrator> $User = Get-Credential


cmdlet Get-Credential at command pipeline position 1

Supply values for the following parameters:


PS C:\Users\administrator> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://EXCHCASSERVER.

domain.root/PowerShell/ -Credential $User -Authentication kerberos

New-PSSession : [EXCHCASSERVER.domain.root] Connecting to remote server EXCHCASSERVER.domain.root failed

with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311

occurred while using Kerberos authentication: There are currently no logon servers available to service the logon


Possible causes are:

-The user name or password specified are invalid.

-Kerberos is used when no authentication method and no user name are specified.

-Kerberos accepts domain user names, but not local user names.

-The Service Principal Name (SPN) for the remote computer name and port does not exist.

-The client and remote computers are in different domains and there is no trust between the two domains.

After checking for the above issues, try the following:

-Check the Event Viewer for events related to authentication.

-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or

use HTTPS transport.

Note that computers in the TrustedHosts list might not be authenticated.

-For more information about WinRM configuration, run the following command: winrm help config. For more

information, see the about_Remote_Troubleshooting Help topic.

At line:1 char:12

+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri ht ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin





See also