Active Directory and separate organizational units
I have been asked to write in with a question about pre-existing users and importation into Unity.<br><br>We have set up some hunt groups through Call Manager and the Web Attendant, which involves creating some 'dummy' users with mailboxes accessible by several people. We also wanted to have a group voice mailbox for these users. <br><br>To accomplish this, I created a separate OU within Active Directory to place these dummy users. I also created a separate group to add each dummy user to, so that I could remove them from the Domain Users group. At this point, we have a separate OU under the main domain tree (OU=VM Groups,DC=domain,DC=com). <br><br>My coworker then went to import each dummy user into Unity. Unity was not able to find the new dummy users or the organizational unit I created for them. Moving each user back to the default Users group (CN=Users,DC=domain,DC=com) allowed us to add the the users to Unity. At this point, all the dummy users have been moved and the hunt groups do work as intended. <br><br>Is this by design, or are we overlooking something important? While we have not done so yet (just moved to Win2k and AD), our shop plans on reorganizing existing users and groups into separate organizational units for policy application, software installation, delegation, etc. Is Unity going to prevent us from accomplishing this? It seems like this behavior would kill most of the benefits we were expecting to get from Active Directory. <br><br>
Re: Active Directory and separate organizational units
This is something you can do... the issue is when you installed Unity you indicated in part 2 setup that you wanted to create users in the Users container and this is the top of the tree (by default) that the monitor is looking at for objects we care about. I think if you ran the permissions wizard (available off AnswerMonkey.net, will be shipping with 4.0) and selected the root of the domain as the guy to apply rights to this would have helped this situation... it would apply rights needed to update users in the root container on down and changed the default monitor search scope to the root which would, of course, also pick up both your users and VM Groups containers.
You are not supposed to have to use the permisisons wizard to make this work... the monitor should allow you to import users from any container in the domain or, in fact, another domain. I've done this myself and I know it can work but using the permissions wizard does jump start the process.
I'd be interested if you guys could run the permissions wizard and give this a try... if after that you still can't see users in other containers than the default creation container (users) there's another problem at play that needs to be run down.
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...