OK, here's our basic setup.
We're using Microsoft Active Directory to manage all users for the domain.
We're using CUCM 11.5 for the VOIP system and Unity 11.5 for Voice Mail.
Users regularly join and leave the company (around 200 users) and each time they join or leave we need to provide them an AD account sometimes a phone. We have a user interface for HR to put in the employee's information/position and it generates the user's account in AD. The phones are manually setup. A tech create the user profile, assigns a phone,an extension and logs into Unity to create a VM.
I know CUCM could integrate with AD and thought this could automate the process and put more of the user setup to HR. They could check a box for users who need phone and IT doesn't have to guess if we need to create a phone for the new user or not. When a new user is created in AD, it's auto created in CUCM and the user or tech can simply self provision at a phone with their auto generated extension. I was even able to create a device/extension template on the auto-registered phone that hot dialed the self-provision CTI port. They just need to pick up the handset and BOOM they are directed to put in their extension to have the phone setup.
Great Right? Nobody has to access AD or CUCM, just setup and go . . . . except, there's not way to know what the auto assigned self provision extension is. When CUCM assigns and extension from the preset pool to the self provisioned user, it doesn't send it back to AD. I thought the user/tech might be able to see what the extension field for the new user is in the phone's directory as the new user will show up in it, but it doesn't. The user's name shows but not their extension. That's because the field (Telephone Number) in the CUCM user profile is now managed via AD, which doesn't know what that extension is. CUCM can't apply it's own auto generated extension to it's own user call directory. This means that a tech still has to manually log into CUCM to find out what the user's ext is AND access their AD account to update extension.
No problem I thought, I'll just have CUCM run an scheduled report to a CSV file with the username and ext. We can use that file to auto update AD every night and we're good. But CUCM has no such report let alone a way to auto generate them. I've scoured the administration reports, the serviceability reports and the CDR reports. None will work for this purpose. I seemed to be stuck, till I though I had a bright idea.
What about Unity? Yeah, maybe Unity has a report that show's the user's account and primary extension. If I can get that report, then when Unity updates from CUCM, it'll generate the report and AD can use that to update the user profile. They will show up in the phone directory and then the tech can easily see what extension to use when auto provisioning a user. I looked through every part of Unity and no luck, but I did find a Unity tool that will export user data to a CSV. It can also be scheduled to run every night. It's a roundabout way to do it, but it's work.
So now I just need to sync Unity with CUCM. There are two ways, LDAP or AXL. I don't want to use LDAP because AD doesn't know what the user's extension is. I want LDAP to find the extension from Unity. So that leaves AXL, directly from CUCM. I set it up and then I found another issue. It doesn't auto sync. I have to manually go in and tell it to grab the user info from CUCM. Why the heck does it have a way to grab user info from CUCM, but not regularly update?
Now I'm back to where I was before. I've arguably shorted some steps, but the issue is basically the same. A tech has to manually log into CUCM, Unity and now AD to add a user to the system. I haven't even mentioned the logistical issues with what happens when a user leaves the system, but again it requires manual account manipulation.
I can't help but feel like the LDAP feature is only half way capable. Maybe it's because it relies on me to create and API and leverage the AXL access that CUCM allows in order to fully automate the whole thing. Just relying on the build in features of the system doesn't get the job done.
I'm I missing something or I am trying to make the system perform a function it is not meant to. We only have a couple hundred users. How do major organizations with thousands of phone users address the regular on-boarding and off-boarding of employees?
