AD Synchronizer doesn't pick up Changes to existing sessions
0 vote
Well, I consider this a bug since it's an existing feature that doesn't work quite right. But, if you consider this a New Feature Request, feel free to move it there.
I use an AD Synchronizer to populate my sessions in RDM. This includes creating folders in RDM to correspond with the OUs in AD. This all works fine. However, I recently noticed that if I move a server from one OU to another, RDM doesn't pick up on that change and leaves the server in the original OU. I'm assuming this is because RDM just looks at the name, sees it already has one, and ignores everything else.
If an synchronizer is set to create folders from OUs, the sync should look at the OU info for every server and make sure they are in the right one each time the sync runs. We are reorganizing our servers and created some new OUs. We moved servers into them and ran a sync. RDM picked up on the new OUs, and created folders for them, but did not move the sessions into those new folders. So now I have a bunch of empty folders in RDM. Now I'm left with manually comparing AD with RDM and trying to manually move things around to get them matched back up.
If this could be fixed in the near future, that would be great.
Thanks.
Hello,
I've moved your topic to the feature request section. This is the expected behavior, and it's as you say: the reason it acts this way is because RDM compares with a set of specific values (name, folder, host) rather than any unique identifier. This has a few effects like not letting us update the entries, and instead we need to rely on the "mismatch action" feature to recreate the entries, or move them elsewhere.
We recently opened a ticket to improve the synchronizers to sync a unique identifier as well, which will allow us to actually update the entries more effectively, and overall give the synchronizers a much needed improvement. It was mentioned in the discussion here.
I'm hoping we will be able to schedule these improvements for our next roadmap, but I can't make any promises at the current time. Still, I've noted your interest in this and it looks like it would be a big benefit to our community, so this will weigh into our decisions.
Regards,
Hubert Mireault
How does the Mismatch feature work? Will it see these items as a Mismatch if the name is the same but the Folder/OU is different? Can I use that to do what I need to do? I'm fine if RDM sees the existing entry as missing, and deletes it, and then creates a new version in the correct folder. Can that be done? I guess I'm not sure what happens if I delete an item from AD. Does RDM remove it the next time it syncs?
Since RDM creates folders for each OU and puts the machines in the right one during the initial sync, I would think the OU should be one of the specific values that you check for.
The mismatch feature is exactly how you describe.
If you configure the mismatch mode to "Delete", if there is a mismatch in the synchronized entry for the name/folder/host, it will perform the mismatch action, delete in this case. If you sync the OUs and the synchronizer puts the entries in those folders, then if you move those entries in your AD, they should be deleted and recreated in RDM, as in this case the folder will not match anymore. In the same vein, if you completely delete the entry from your AD, it should also be deleted in RDM as there will be no match for a name/folder/host any longer.
As a note, RDM will only perform the mismatch action on entries that were created by the synchronizer.
If it's at all possible for you, I would suggest trying out the mismatch feature in a different vault or a local datasource so you don't risk anything happening to your current synchronized entries. It could let you see it in action without any risk.
Hopefully my explanation is clear enough but if you need any more details, let me know.
Regards,
Hubert Mireault
Hello,
With version 2024.1 of RDM, we have improved the Active Directory synchronizers to match by unique identifier.
What does this mean? This means that RDM is now able to update the synchronized entries rather than having to recreate them, which makes the synchronization process more intuitive and changes a lot of behaviors users found weird. Please note that on your first synchronization on 2024.1, RDM will update all the missing identifiers, and on subsequent synchronizations, it should update the entries provided the identifier is still found within Active Directory.
I would encourage you to try out version 2024.1 and see if the behavior works for your scenario. If it doesn't, let us know and we will see if there is a specific configuration that might work better, or if there are still more things we could add to the synchronizer to support what you require.
Regards,
Hubert Mireault