Score:0

adamsync moving objects to LostAndFound on user object delete on Server 2022 replica in mixed OS environment

cn flag

We are in the process of migrating our ADLDS instance from Server 2012 to Server 2022. We have brought up the two new replicas and they are replicating and functioning as expected. We run a daily health check and replication report. Everything looks good.

Our ADLDS is an authentication proxy for our main AD Domain. We run adamsync every four hours to pull in changes. The adamsync job alternates between nodes. We migrated the jobs to the two new Server 2022 nodes. They ran fine until the first user object deletion. Instead of (just) deleting the object it began moving hundreds of objects to LostAndFound: user objects; group objects; OU objects. Eventually the job failed when it moved an OU and then tried to move and object in that same OU.

We have been able to repeat the issue twice. Running adamsync with the /fs option on one of the old Server 2012 replicas has this far been the only way we've found to resolve the issue. Once we resolve the issue, adamsync works as expected on the Server 2022 replicas as long as there are no user object deletions.

We've got a ticket open with MS but I'm curious if anyone else might have some insight or suggestions. Bug in adamsync in Server 2022? Unexpected behavior due to ADLDS being on two different OSes? Other?

Thanks in advance.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.