Notes on IT (mainly Microsoft)

Windows Server 2003 ADAM to Windows Server 2008 AD LDS replication fails when using NTLM (negotiate)

with 11 comments

AD LDS can use “negotiated” as the replication security level within a configuration set
( This may happen on AD LDS
servers that are domain-joined if there is a problem with Kerberos (e.g. a service principal
name issue) but will also happen for ADAM or AD LDS instances that are only members of a workgroup.

There is a known issue with mixed configuration sets, that is configuration sets containing
both Windows Server 2003 ADAM instances and Windows Server 2008 AD LDS instances, on attempting
to form a configuration set when the replication security level is Negotiate replication may
fail to complete.

The signature of the problem is seen when using repadmin to try and force a replication
of a naming context hosted on the (originating) Windows Server 2003 ADAM instance so e.g.
for a naming context “dc=mycompany,dc=com”

repadmin /syncall “dc=mycompany,dc=com”

results in the following errors

To :
Error issuing replication: –2146893008 (0x80090330):
The specified data could not be decrypted.

If the servers are domain-joined then diagnosing the reason that kerberos is not being
used for replication security is the thing to do and will circumvent this issue. In pure
workgroup configurations there is currently no workaround for this problem.

Update 12 August 2010:

Microsoft have now released a fix for this problem:


as ever test this in a non-production environment and note that in existing configurations sets of ADAM instances on Windows Server 2003  replication will fail between instances that are mixed (where some do and some do not have the patch applied).


Written by adamsync

April 2, 2010 at 01:06

Posted in AD LDS, ADAM, adam-lds, Microsoft

Tagged with , , ,

11 Responses

Subscribe to comments with RSS.

  1. Hi there,

    I’m having the same problems replication ADAM to ADLDS. I’ve selected negotiated pass through as the replication authentication method, but I’m still getting the “Could not decrypt data.” error message.

    I have to get the replication running in a workgroup, but I’m currently not able to make it work.

    Do you have any ideas?



    April 8, 2010 at 12:46

    • Unfortunately I think you are blocked in a workgroup because of this issue. As far as I know Microsoft have not decided whether to fix this or not, I’m hoping that gathering evidence here will help. However even a fix might not arrive in your project timescales, perhaps there are other approaches you could use rather than replication it depends on what you need to achieve?


      April 8, 2010 at 19:33

  2. The goal is to use replication from ADAM to ADLDS as a migration path from Win2k3 to Win2k8 without performing an OS upgrade (which is considered very risky). As Microsoft does not provide a tool to migrate ADAM directly to ADLDS, the migration option looked like the only way out.

    Maybe there is some way to convert an ADAM instance to ADLDS using a tool that I’m overlooking here?


    April 8, 2010 at 22:26

    • The use of replication as migration path when in a workgroup is exactly what is blocked by this issue. The only “workaround” is to domain join the machines but that may not be an option. There is no supported way to pick up the database from an ADAM instance and present it to an AD LDS instance however perhaps you could consider the following:

      take a backup [1] of your ADAM instance (hopefully you backup anyway).
      Note to have a portable backup (for restore to another server) it’s usually a good idea to add the Windows Builtin Administrators group to the Administrators role in the ADAM instance if not already present (you can remove it again after taking the backup if required)

      install a Win2k3 server on some machine (physical or virtual) and install ADAM and then restore your ADAM backup to that server

      upgrade that Win2k3 server just created to Win2k8 and upgrade the ADAM instance to AD LDS [2] for testing

      backup [3] that AD LDS instance and restore [4] to a clean install of Win2k8 running AD LDS in your production environment allowing you to leave your Win2k3 ADAM instance untouched



      April 9, 2010 at 14:05

  3. Thank you very much for the response. I’ll suggest this as a possibility for the migration. It’s a rather lengthy operation though 🙂



    April 10, 2010 at 13:53

  4. I’m also having the same problem, do you know if MS make a decision on this matter?



    June 14, 2010 at 21:34

    • The best information that I have is that a hotfix is now expected in August (updated in the post above).


      July 1, 2010 at 10:25

  5. Has anyone tried it yet with the patch installed? I’ve set it up here in the lab, but I’m getting the same results i.e. Data could not be decrypted.


    August 18, 2010 at 10:13

  6. Ok everyone, replication is working here. It seems that there was a registry key missing in order to get it going.

    Just add Reg Value = “HKLM\System\CurrentControlSet\Services\\Parameters\NTLMSessionKey”
    Type = DWORD
    Value = 0x1

    Sit back, relax and watch the whole thing replicate.


    August 19, 2010 at 16:22

    • I have not had a chance to try the patch yet. The registry path above does not look complete is there an element missing? Also how did you figure out that this key was required? Thanks.


      August 20, 2010 at 17:31

  7. The space between the two dashes has to be filled up with the name of your ADAM instance.

    I’ve had contact with Microsoft Support and they provided me with this registry key.


    August 25, 2010 at 17:57

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: