I found another thread on the forum that discussed inherited permissions. I modified the USER01 AD account to enable that property. During the next import, that account did sync, so I'm not concerned about the USER accounts. I am, however, concerned about the Unity system objects:
Looking further, the above objects cannot be found in AD. The system was installed step-by-step by the installation guide, including the Permissions Wizard. I think it is a rights issue, but I'm not sure which accounts need which rights.
it'll be on the directory facing account (the one associated with AvDSAD to be specific) - now that you have the inherited thing cleared you can force the synch to try and create those folks again - if you run \commserver\ConfigSetup\setup /sync it'll just do the syncronization from SQL into the directory again and it should try to create those system objects again - give that a whirl and see if you have better luck with it now.
I had to import another group of users, so after I changed the inherited property to the users, the issues I had with the subscriber accounts went away. I still have the issue with the 6 Unity objects.
Should I be able to run the d:\commserver\ConfigurationSetup\setup /sync utility as UnityAdmin? That account, as per the installation docs, does not have Domain Admin rights. It is just a domain user, plus whatever else the Permissions Wizard did to it.
I ran the sync logged in as UnityInstall. Is there an error log when you run it that way?
I also found several event viewer messages like the following. It definitely looks like the directory-facing account. What can I do here?
Event Type: Error
Event Source: CiscoUnity_DSAD
Event Category: Error
Event ID: 1049
Time: 2:54:18 PM
The AvDSAD service failed to create object.
Reason: ERROR_ACCESS_DENIED: Access is denied.
Domain Controller: fram-dc2.NE.GTC-BIO.NET
Possible causes include: 1) Network connectivity to the Domain Controller. 2) Insufficient rights for the AvDSAD sevice account.
Ensure that the AvDSAD service can contact the Domain Controller and has sufficient rights to create objects. If the problem persists, enable all the micro traces for the AvDSAD service in the Unity Diagnostic Tool. Report the problem to Cisco TAC and include the diagnostic log. For more information, click: http://www.CiscoUnitySupport.com/find.php
The account you run it as doesn't matter in this case - the synch is done through the account associated with the AvCsMgr account which, according to that error message, looks like it doesn't have the juice to create these objects in the container selected.
Yes, a log is created in commserver\logs - it'll start with SQLSync I blelieve and it'll be time stamped for around the time you started the synch.
The best I can suggest is to follow the advice in the error message - make sure the DC/GC being pointed at in the registry (HKLM\Software\Active Voice\Directory Connectors\DirSyncAD and DirSynchGlobalCatalog branches) are correct and up and that the account you have assigned to the AvCsMgr service has the rights it needs to create those objects in the containers - the Permissions Wizard should do this for you...
I just (painstakingly) went through Appendix D - Permissions set by the Permissions Wizard. I think I found my problem. I think the container that the Permissions Wizard was told to use for new objects is different from the container that was selected during the installation of Unity. I thought I had set all of the permissions to a certain OU, but I think I only set the Locations to that OU. The user creation container is still the Users container in the Directory.
Is there an easy way to point Unity to the container set with the Permission Wizard, or do I need to set the correct permissions on the container that Unity currently points to???
this is kind of confusing... when you run Permissions Wizard is collects information about what containers you will be creating locations, dls and users in and all that good stuff. This info is prepopulated in the service config wizard later in the install and you shouldn't have had to do anything "manual" here at all.
If you went around the permissions wizard and did your stuff manually all bets are off. I guess at this point you should probably contact TAC for assistance since this will require you fiddle around in DOHPropTest/registry settings to get the containers where you want. If this is a new install and it were me, I'd uninstall and start again from scratch and make sure to use the permissions wizard up front and specify the right containers/accounts and take another run at it.
In a nutshell, I picked a different (wrong) container for new object creation during the Unity installation. I didn't realize that the install program knew about the containers based on the Permission Wizard process, and, since I'm not creating new users from the Unity Admin (just imports), I didn't give it much thought. I know...I was wrong.
Knowing what I did, I manually set every permission that the Permission Wizard needed to set for the Directory Account onto the container that I specified in the install. I restarted Unity and all is well. The synker is clean, imports are good, all services are happy, and the 6 objects are now in the AD.
Thanks for pointing me in the right direction. This will NOT happen again!!!
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...