Server side synchronizations

Hello,

What DVLS version are you using?

Is the Scheduler properly configured and running on the machine where DVLS is hosted?
https://kb.devolutions.net/dvls_scheduler_service_general_information.html

Best regards,

We are using DVLS version 2022.3.13.0.

As far as I can tell the Scheduler is properly setup as it works fine. We do not have domain authentication configured though, since we only want to use Azure - Is the domain authentication configuration a requirement for the server-side AD synchronizers to work?

Hello,

Thank you for the information.

The Domain authentication configuration isn't required to get the AD synchronizer to work.

Sadly I cannot reproduce this behaviour internally.

Could you please try to restart the Scheduler service?

Is the AD Synchronizer entry working when you run it manually?

Best regards,

So, some small progress. I setup another test sync this morning, but created a new destination folder for the results this time. This mostly worked, in the sense that it was able to actually create the sessions I expected. What I found strange was the difference in how the server side sync created folders based on discovered OUs vs the folder structure created when running the sync from my workstation.

The server side created this structure:

Top Level Sync Folder
--> Empty folder (name is ADSiteSubOUSubOU)
--> Empty folder (name is ADSiteSubOUSubOU)
--> Folder with no name
--> Folder named ADSiteSubOUSubOU
--> RDP connections
--> Folder named ADSitesubOUSubOU
--> RDP connections

What I expected to see based on how the sync behaves when run from my workstation:

Top Level Sync Folder
--> AD Site Name
--> Servers Sub OU
--> Sub OU
--> RDP connections
--> Sub OU
--> RDP connections

The only differences between the test sync and my regular sync are the schedule, selected OUs, and destination folder.

Hello,

Thank you for your reply and glad you made some progress with the AD Synchronizers.

The behaviour your are experiencing in a known issue. Because the folders doesn't exist yet, the process creates those kind of folders.

For your information, the fix is already available in the latest DVLS Beta version 2023.1 as stated in the Release Notes. And the official release is planned for mid-March.

Best regards,

Follow up - I have identified one part of the issue, which may be a bug or at least something that is not obvious. Apparently the server side sync will only work if you select one container OU at a time to sync. My client side sync was configured entirely through RDM, which let me populate the OU/Container DN field something like this:

OU 1 | OU 2 | OU3 | OU 4 | etc...

So I assumed the server side sync would work the same way. As a test, I updated my test sync from this morning to check two OUs instead of one and it is now 'broken' as well. It deleted all of the existing connections and did nothing else. If I switch it back to a single OU again it syncs connections again, but still with the weird folder structure.

I applied the beta version of DVLS yesterday and I have the AD synchronizer working for the various OUs I need to sync now.

Side note - I had issues with the VMware synchronizer as well. If you are setting up a server side VMware sync through RDM it won't use linked credentials. I had to manually specify my vCenter credentials in each synchronizer. This seems like a regression since linked credentials in the VMware synchronizer worked fine for the client side syncs.

Hello,

Thank you for your feedback and glad the AD synchronizer is working as expected in the beta version.

Regarding the VMWare synchronizer entry, we will try to reproduce this issue and we will keep you updated.

Thank you for your patience.

Best regards,

Hello,

It seems that even from the DVLS web UI, I cannot set a linked credential. It's maybe related.

And I was able to reproduce your issue.

I have submitted 2 tickets to the engineering team. Once an update will be available, we will update this thread.

Thank you for your patience.

Best regards,

I am beginning to wonder if something is just wrong with our implementation somewhere... This morning I have noticed the following:

1. The VMware synchronizations are working with custom credentials, but the duplicate entry check is hit or miss. I now have quadruplicate entries for everything I am syncing from VMware.
2. The entry templates I created in DVLS are not visible in RDM. This is confusing because the data displayed is not consistent between interfaces now. E.g. the VMware syncs correctly show the selected template in DVLS, but viewing the same sync in RDM shows no template selected and in fact shows no available entry templates at all.

Is there perhaps a beta version of RDM I need to install to match the beta version of DVLS?

Hello,

Thank you for your feedback.

1- We will verify if we can reproduce this behaviour.
2- It would be preferable to verify if you can reproduce this problem with the latest RDM beta version. If you can reproduce again this, then we will investigate further.

Best regards,

Hello,

About the Duplicate check parameter, what parameter have you selected?



And do you modify any server information on VMWare before running again the synchronizer?

Best regards,

All VMware synchronizations are configured the same:


The destination folder is specifically for entries created by the synchronizations and contains only other folders and VMRC connections.
I am syncing ~700 connections so it's certainly reasonable that some of those could be changing, but all connections were duplicated. Does the duplicate check examine any VMware custom attributes?

Follow up from this after installing the beta version of RDM -

Templates created in DVLS are now visible in RDM and viewing the VMware synchronizations matches between them as expected.

The server side VMware synchronizations are still creating duplicate connections (and just the VMRC connections, it is not duplicating the folders it sees in our vCenters). I changed the sync schedule three times times this morning and ended up with three VMRC connections for every VM.

Thanks again for looking in to these issues.

Hello,

That's a good news the RDM beta version has helped.

About the VMRC duplicate entries created by the VMWare synchronizer, I still cannot reproduce your behaviour. I will ask our QA team to try to reproduce this problem.

In your tests, have you tried to delete all VMRC entries and start over from scratch?

Best regards,

For my testing I deleted everything inside the destination folder first, but I have not tried recreating the destination folder itself yet. I will give that a try and report back.

As far as I can tell the duplicate check for the server side VMware synchronization simply doesn't work for me. I completely deleted all entries and folders this morning and tested again, with the same results as far as duplicates go. It also did not make a difference if I changed the duplicate check from Destination folder to Root

Hello,

Thank you for your feedback and I'm sorry this issue still occurs on your end.

We will try to reproduce it internally and we will keep you posted.

Thank you for your patience.

Best regards,

Hello Grant,

I got a case open in order to schedule a remote session with you to gather more information. The case number is 00023650.

Best Regards,

Hello,

For your information, the issue related to the Credentials configuration in a VMWare Synchronizer is fixed in the latest DVLS version 2023.1.3.

Let us know once you will test it if it's working properly in your environment.

Best regards,

I am running the latest available versions of RDM and DVLS, with no change in the behavior of the VMware synchronizations. The server side sync only works for me if I use the custom credential option. If I try to use linked credentials from our vault nothing happens, or at least no connections are created.

Hello,

Thank you for your feedback.

I have been able to reproduce your issue using the latest DVLS version 2023.1.4. A ticket has been sent to our engineering team. Once a fix will be available, we will update this thread.

For your information, at least the synchronizer is working when launched manually.

Thank you for your patience.

Best regards,