Some of this may be theoretically possible, though the implementation could get interesting:
- In general, CUCM receives data from AD one-way only. If you need to make changes in AD (e.g. based on something that happens in CUCM) you will need to investigate APIs and access available from AD (i.e. some kind of LDAP API/library) in order to automate that
- In general, you can monitor changes that occur in the CUCM database (e.g. a change in a user's 'Phone Number' field when CUCM syncs with AD) via the AXL 'Data Change Notification' mechanism: Cisco DevNet: Administrative XML (AXL) -
- I'm not 100% sure that CUCM database field updates due to AD sync are reflected via Data Change Notification, but this should be fairly easy to test. Note that in general DCN only indicates that 'user X was updated' and doesn't provide the details of the change. You would need to use various separate AXL requests to retrieve the details about the changed object to determine if something you cared about (such as device/line associations, or the Phone Number field) actually changed.
So , the high-level approach might be:
* Admin changes a user's Phone Number in AD:
- CUCM syncs with AD periodically (I think this is configurable, but might be once per day, or might be on-change or on-demand)
- Use AXL DCN to watch for updates to user objects (triggered by the AD sync)
- If a user is updated, use AXL to retrieve the list of associated devices (<getUser>) and the lines associated to those devices (<getPhone>) to determine if the user's Phone Number field matches.
- If the Phone Number field doesn't match, use AXL operations to either associate an existing line to a user's device, or create a new line and then associate it: <addLine>, <updatePhone>
* Admin changes the DN on a device associated to a user in CUCM:
- Use AXL DCN to watch for updates to device/phone objects
- If a phone is updated, use AXL to check that the associated devices/lines match the user's Phone Number field. If not, use some sort of LDAP API to get AD updated to reflect the current value
Some caveats:
- All kinds of admin-initiated or automatic operations can trigger database changes for DCN-monitored objects. Potentially some or most of these updates may not be related to phone number changes. However, a great deal of processing may need to occur on CUCM and the application side to examine the full details of every potential change to decide if your particular set of conditions are met. This could result in what are sometimes called 'update storms' as CUCM and your application react (via fairly heavyweight AXL request sequences) to individual updates. For example, if the admin performs a batch configuration change that updates many/all users in CUCM in some way (unrelated to phones/DNS), your application may suddenly be challenged to examine in detail (via several/many AXL requests) each and every user and never make an update
- If you could decouple from 'automatically triggered', and encapsulate the AXL/LDAP change operations in some sort of script (or other automation) launched on-demand by the admin, that might work better (and be simpler in the short term.) E.g.: create a set of scripts like 'update user's phone number' or 'add new user' which can be launched by the admin (or triggered by some other process, like a HR app) that use the AXL and LDAP APIs as described above to affect single-user updates only when needed
