What version of the manager are you running?
Older version, pre 2.12 used the CN for these groups and users. So if you moved a user from 1 OU to another it would not recognize the user anymore because it's CN did not exist anymore. Could this be the case?
Running 2.1.21 the newest version.
Users have not been moved. I just brought up a whole new App Volumes manager that was installed fresh to a new SQL DB and I am getting the exact same behavior.
I can search for a user/group and assign it just fine and it works. Then as soon as a directory sync occurs they become disabled.
Do your APV client machines use the same DNS servers as the APV Manager machines? , also do you have AD subnet objects created (in AD Sites & Services) for the IP subnets that your client machines reside on? Also have you added the IP Addresses of the DC's during APV setup?
I have seen strange issues with a number of large APV installations where changes are made on the APV Manager using one DNS / AD Domain controller, and that change has not replicated to the domain controllers used by the client machines. This is often due to subnet / Site associations not having been created and the client attaches to a DC from the completely wrong site
Any updates on this? I am having the same issue.
We also see this issue, it occurred after upgrading from 2.9 to 2.12.1 as a resync of objects is initiated after the upgrade. The user object gets re-enabled after their first login, but you can't modify direct assignments to the user until this first login.
Additional resync operations mark all users as disabled again.
We had a lot of issues with the database after upgrading from 2.9 to 2.12.1. Apparently they was a new way of storing the datastores within the database and we ended up with every user having multiple writable volumes because it would see 2 datastores that were tight to 1 physical datastore.
At the end we decided to just recreate the database which in our case was a lot easier than dealing with the issues that arose with the upgrade.
Ray we also had issues during the schema upgrade, ours was related to transferring the 'trusted domain' settings in 2.9 to the new domains settings in 2.12.x. We had to remove the trusted domain settings prior to running the upgrade.
Nope, not anymore. As said, we decided to recreate the database. Is the best option, No. Did it do the trick, Yes.
GSS have reproduced our issue where an AD Sync causes all users to be 'disabled' until next login. This only seems to occur when more than one domain is added to the manager.
No timeframe on a fix from engineering as yet.
FYI, support have provided a workaround for the Disabled users issue that we see when multiple AD domains are specified in AppVol 2.12+. (This is still an issue in 2.13.1 I believe)
Setting the LDAP Base on all domains allows the AD sync to find the users in the correct domain. Working well for us, all users appear enabled after changing the settings.
Navigate to Appvolumes Manager console go to Configuration-> Select AD domains> set Base for all domain controllers:
For example if the Parent domain name is : corp.com and child domain name is child1.corp.com and child2.corp.com then below is the format that has to be set in LDAP Base
For Parent domain : DC=corp,DC=com
For child domain1 : DC=child1,DC=corp,DC=com
For child domain2 : DC=child2,DC=corp,DC=com