One Example of an ADAM Migration from a DMZ to a Microsoft AD Domain

I was recently involved in a project which required a replicated ADAM instance to move from a DMZ environment to an internal network. The internal network is a Microsoft AD domain. The DMZ setup included two unique servers. The first server was the master instance of ADAM and the second server contained the replicated instance. Both servers also had Microsoft Network Load balancing set up to improve availability of ADAM to a customer facing application.

(We’ll use the example names of “ExtServer01” which had the master instance of ADAM and server “ExtServer02” had the replica instance of ADAM.)

Our team discussed the different options and came up with an initial plan. To save expenses of purchasing new hardware and, because we are not yet ready to deploy virtual machines for our production environment, we decided to break the replication and use the “ExtServer02” hardware. Our initial plan of trying to retain the replica copy of ADAM and seize roles was very time consuming and messy.

I revised the entire plan and this blog posting will outline the steps involved which made this migration less time consuming and successful.

A note of recognition is due: Discussions with Lee Flight on the Microsoft news forums (you still gotta love NNTP) were immensely beneficial. Thank you, Lee, for answering several questions and pointing me in the right direction.

The first steps of the migration involved uninstalling network load balancing on the secondary server, stopping inbound/outbound ADAM replication on both instances, “moving” the cables to the internal network, renaming the server to comply with our network naming standards and, joining the server to the 2003 AD domain.

My first attempts at carrying out our initial plan just didn’t come together and were very messy. This is the point at which I turned to the Microsoft news forums and had a few discussions with Lee Flight. In the end, I backed up the production ADAM instance, restored it to my “new” server, and performed a few fix up procedures and voila…worked like a charm. There are several procedures for recovering ADAM that I had to inject into the standard Microsoft documentation to pull this all together.

When you migrate from a non-AD environment to an AD environment there are several things which you should be aware. You’ll need to change your service account, replication authentication mode, know how to fix SCP security issues if they show up in your event log, and understand how to clean up ADAM to make it all nice and neat.

The following steps outline a procedure for both a migration process, disaster recovery, or establishing a copy in a test environment. These steps are based on the existing documentation which can be found at Microsoft:

  • Make sure you have a backup of your current ADAM master instance. For a migration, I just found it easier and quicker to use the Windows backup utility. What we’ll be doing is creating a COPY of the master instance on a new server. This will allow you to bypass any need to seize the naming and schema master.
  • For my example I already had an installed instance. At this step, I stopped the “replica” instance service. If you are restoring into a test environment or a “clean” server, set up an ADAM instance but do NOT create any partitions during in the setup wizard. Refer to the Microsoft TechNet documentation.
    1. When you restore, make sure to change the restore settings in the Windows Backup utility to always overwrite files.

      Leave the ADAM instance service in the stopped state.

  • Change the service user for the ADAM instance to an AD service account. Nagivate to this link, and use it as a reference for your security context. In my example, we need to use a domain user or network service as the service account.
    1. execute ADAM Tool: dsdbutil

      change service account [enter]

  • Restart the ADAM instance service. Check for SCP errors in the event log.
    1. If experiencing SCP errors, follow the procedures outlined in this link:

  • If migrating from a replica environment, clean up all “old” servers. In my scenario, I had two servers, “ExtServer01” and “ExtServer02”.  “ExtServer02”, at this point, would now be an orphaned server. Perform metadata cleanup on the orphaned server objects using dsmgmt. You can find information on how to do this at the following location:
  • Run ADSIEdit on the master instance, open the configuration context and remove the server(s) cleaned with metadata cleanup. Remove the object: CN=,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={GUID} Note: servername is the equal to the orphaned objected you cleaned up with the metadata cleanup procedure.
  • Since we are in ADSIEdit, let’s make sure ADAM is set up to replicate properly since we’ve changed security contexts. More than likely, your replication authentication mode in the workgroup was set for passthrough authentication (value of 0). We can’t replicate when the server hosting ADAM is now a member of the domain using this setting. Using ADSIEdit, open the configuration naming context. Right click on the configuration container and select properties. Set the “msDS-ReplAuthenticationMode” attribute to a value of 1. As we did to establish our service account requirements for our security context, we reference the chart at this link,, and see that we need a negotiated authentication method.
  • [OPTIONAL] To clean up the CN name of the server object in ADAM, navigate to the server (CN=ExtServer01$Extranet,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={GUID} right click on the object and select rename. Rename the server name portion of the CN. In my example, the new server name was “IntServer110”. So, the change was from CN=ExtServer01$Extranet to CN=IntServer110$Extranet.
    1. While this change is not absolutely necessary, it definitely would be worthwhile to do this to avoid any confusion in the future. So many times I’ve run into situations where someone new has worked on a system where changes were previously made that lead to complications when a new person took the reins. Clean it up, make it logical, and document, document…document. Always remember the “Hansel and Gretel” tenet for life in IT.

  • If you wish to create a new replica of the restored instance, make sure inbound/outbound replication is enabled:
    1. repadmin /options localhost:389 -DISABLE_OUTBOUND_REPL

      repadmin /options localhost:389 -DISABLE_INBOUND_REPL

  • If a replica is required, you can now set up your new replica
  • I did this in a test scenario many times in a row to establish the documentation. After you’ve done it a few times, it only takes a few minutes of your time. Make sure to do your own research and perform everything in a test environment. Your mileage may vary.

    It is also worth to note something about password policies. If your ADAM instance has a conflicting password policy to the one implemented in your MS AD domain, you’ll need to make sure you change the “msDS-Other-Settings” attribute. If a value of “ADAMDisablePasswordPolicies=0” exists, you’ll need to change this to “ADAMDisablePasswordPolicies=1”. If you do not, and an ADAM user’s password does not comply with your internal password policy, the user cannot be authenticated.