There isn't an "auto-delete" feature built into the CUCM software. You would need a tool to accomplish this task. The tool will need the following features/capabilities:
1. Have a method to expire an account and provide admin with method to control expiration policy
The tool could pull the end user data into its own database and then provide a method for admins to control expiration from the tool itself. This is useful for things like creating a user and assigning an auto-delete timer to the user. But I gather from your post that you may be looking for something that will trigger on some state of events in the CUCM. Specifically, (and I am guessing here) you want something that will say the user hasn't interacted with the system in X days. This could be tough since you aren't forcing people to logout. But things you can check are:
End User Activity
The CUCM database tracks end user logon events in the credential and credentialdynamic tables in the database. The attribute that you may want to look at is actually in credentialdynamic. This attribute stores the "last login time" for the user ID. You can see this by executing the following query from the command shell: (NOTE: the following is just so you can get a feel for data in your environment and for how it changes using test accounts. Your tool would actually need to leverage AXL/SOAP API to accomplish these transactions)
admin:run sql select eu.userid,cd.lastsuccessfullogintime from enduser as eu inner join credential as c on c.fkenduser=eu.pkid inner join credentialdynamic as cd on cd.fkcredential=c.pkid order by eu.userid
What the above query gets you is a list of end user IDs with a timestamp in epoch format that records the last time the user account has logged on. A zero (0) value means they have never logged on.
There is also a credential parameter that allows you to deactivate an account that hasn't logged on in X number of days. That may be something to keep in mind, though with your EM config (see below) I would say be careful with making assumptions on credential policies.
EM Profile Timers
When a user logs into a phone with an EM profile the timestamp is recorded in the database. You may be able to use this but I don't know if that is valid because it sounds like your deployment doesn't enforce auto-logout which may mean that it is perfectly allowed to have a user logged into a phone for days/weeks/months and still be considered "active".
Anyway, if you wanted to poke around the EM login time stamps to see if that helps. You could start by looking at the following: (NOTE: the following is just so you can get a feel for data in your environment and for how it changes using test accounts. Your tool would actually need to leverage AXL/SOAP API to accomplish these transactions)
admin:run sql select eu.userid, d.name, emd.logintime from enduser as eu inner join extensionmobilitydynamic as emd on emd.fkenduser=eu.pkid inner join device as d on emd.fkdevice=d.pkid order by eu.userid
This will give you a list of user id's, the devices they are logged into, and the time (epoch) that they logged on to said device. If you allow multiple logins for EM profiles you may see more than one entry.
Again, I don't think this will help you based on the "no logout" requirement you have.
CDR Activity
Now, if by "activity" you are thinking placing and/or receiving calls then the only way you can be sure that the phone a user happens to be logged into is not being used is to parse the CDR records. While there is a database table that you can query on the CUCM, it is a CAR table and is only available if you have CAR enabled in the cluster. Even then, it isn't where I would recommend you go. You would probably need your tool to support being provisioned as a CDR billing server (which means it gets a SFTP feed of the CDR records). The tool would then need to be pretty smart and have the ability to associate a specific line (or set of lines) on a specific device that has a specific user logged on. You have to be specific if you are sharing lines in any way because you don't want usage on a line by user_A to skew your "activity report" for user_B that may have a EM profile/device with a shared line appearance.
Yeah, ugly. But I am just going off of your original post here and speculating that using the user ID login times and device profile connection times may not meet your needs given the stipulation that you don't force EM logout. This implies that you have no way of identifying durations that are valid/invalid.
2. Deleting users/profiles/etc. in CUCM after you identify that you should delete them
Item #1 is going to be the trickiest part of your solution. Deleting the users and EM profiles isn't exactly easy but there are less variables to contend with. Based on your original post I would think that your tool would have to do something like this:
a. Once triggered to a delete for a user, identify the userid as configured in CUCM (using AXL/SOAP API)
b. Identify device profiles associated to the user id (using AXL/SOAP API)
c. Identify if said user id is logged into a phone (using something similar to the second query I provided above)
d. If a user is logged into a phone, log them out (your tool would need to use the Extension Mobility API to accomplish this task)
e. Confirm logout (repeat C, just to be sure)
f. Delete user object (using AXL/SOAP API)
g. Delete profiles stored from B (using AXL/SOAP API)
h. Confirm (repeat A and check B) (using AXL/SOAP API)
3. Unity
This is tough and I don't know how you would go about doing this. I play around with the CUCM APIs all of the time but haven't messed with Unity. I know Unity has plenty of tools that you can use and that CUC 7.x incorporates a standard API using REST but that is it (and CUC 7x/REST doesn't apply in your case). I would think that whatever tool you use would need to have a Unity mailbox associated to the user ID. This association should either be established in the tool before provisioning (like the way PM does it) or your tool would need to be able to use a reverse lookup method to take the Unity subscriber extensions and figure out which DN it is used for. Of course if the Unity subscriber alias matches the CUCM user ID 100% of the time, that may be a better route.
OK. So I used the term "your tool" throughout this reply. I am just being generic here. I don't know if PM can do these things or not. I suspect it does some, but not all and that you may need to figure out what the gaps are and how to fill them. Someone else on netpro with PM experience may be able to do that for you or even say that there is a better way.
HTH.
Regards,
Bill
