A tale of two forests…

… and FIM … and PCNS

I recently had a colleague ask if I remembered how to configure FIM with PCNS between 2 forests, so that when a password was reset in forest A it triggered an update to the password in forest B but didn’t cause a trigger back to forest A and then create a loop.

I figured it was worthwhile to blog about this, just in case I do happen to forget someday…

The diagram above illustrates the problem. The user in Forest A on the left, resets his password. The domain controller is running the PCNS service and detects the password change, and sends that change to MIM. MIM sends the password change to Forest B. However, because Forest B is also configured for PCNS, it will detect the password change and send that change to MIM. MIM will send the change to Forest A, and a loop ensues.

The solution to this problem requires 3 distinct configuration changes to the environment.

  1. At least one Domain Controller in each forest needs to have the PCNS service either REMOVED or NOT INSTALLED
  2. The MIM management agent for each forest should be configured to point ONLY at the domain controller without PCNS installed
  3. The Domain Controller in question (ie. no PCNS) in each forest should be separated from the other DCs so that it will not process any password change updates from regular users in that forest.

More detail about each of these changes are as follows:

Step 1 – omit PCNS from one DC in each forest

When installing the PCNS service on each domain controller in the forest, either select 1 DC that can be excluded from the installation, or build a new VM that will act as a DC dedicated to the MIM server.

This DC will not participate in PCNS, which means that the service will not be installed, and therefore any password changes applied will not trigger PCNS to send that change to it’s configured target (ie. MIM).

Step 2 – Configure the MIM management agent for each forest to target the DC that is NOT running PCNS

It is important that the MIM server is configured to use the domain controller discussed in Step 1 above. If not, MIM will use DNS / ADS&S to find the closest available domain controller and may use a DC with PCNS enabled, which will cause the loop described in the problem description above. Worse yet, MIM may use the DC without PCNS for some legitimate password change events, resulting in some user passwords not syncing cross-forest.

Configuring MIM is a simple matter of selecting the Management Agent properties for each Forest, selecting Configure Directory Partitions, and checking the box Only use preferred domain controllers

When you check the box Only use preferred domain controllers, you will be presented with a dialog that you will need to use to enter the name of the domain controller that is NOT running PCNS.

Clicking Add will move the server name to the Preferred Domain Controllers list. Click OK.

It goes without saying that only providing 1 server, in any environment, regardless of size, introduces a single point of failure.

If you wish to provide redundancy you will need to create a second dedicated DC, also without PCNS, possibly in another data center and with a different patching GPO to avoid simultaneous downtime.

In that case, enter both server names here.

Step 3 – Configure the dedicated DC to be excluded from user processing (ie. no password changes)

It is important that in addition to NOT having the PCNS service installed on this DC, and the DC being dedicated to MIM, the DC in question must also be excluded from user processing.

You do not want users authenticating against this domain controller, nor do you want them issuing password change requests against this DC.

Normally, Active Directory Sites and Services is used to identify the optimal DC that a user will use for authentication etc.. as a result, this new dedicated non-PCNS DC will need to be configured in it’s own Site in Active Directory.

You can find detail on creating an active directory site here:


In addition, you’ll want to set Domain Controller Priority and Weight settings to ensure the DC is not used, you can find detail on DC priority and weight configuration here:



Once you’ve completed the steps above, be sure to test extensively to ensure that password changes cross-forest via MIM work as expected, without looping, and user login processing avoids the use of the 2 dedicated servers.

Oh, and 1 more thing..

Everything outlined here, although it works, and works well, but ….

Per this article, bi-directional password sync is 100% UNSUPPORTED by Microsoft, despite having been deployed successfully at a number of customers.

So test, and be prepared to troubleshoot, but don’t bother calling for help 🙂