Auto-delete IP phone user accounts in CUCM 6.1(2) ?

Answered Question
Mar 4th, 2010
User Badges:

Hi all,


Is it possible to auto-delete a Device Profile (ext mobility) and a User Account in CUCM 6.1(2)?

Currently I use Provisioing Manager v1.3 to create and delete users - this semi-automates the creation of both the CUCM Device Profile and User Account, and also the Unty account.


A request has been made to assess the viability of auto-deleting IP phone users based on a period of inactivity.  Is this possible?  My fear is that if it is, it will leave an ophaned account on Unity, and might also cause sync errors on Provisioning Manager where parts of the users account (such as Unity) are left behind, thus the PM Subscriber doesn't get deleted.


First step is to try the auto-deletion from CUCM GUI. If i can get this working for accounts not accessed in over 6 months, i can at least test the PM/Unity issues out.


We use Ext Mobilty, but dont force a logout. So i cant auto-delete based on last login 



Thoughts appreciated.

Correct Answer by William Bell about 7 years 3 months ago

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

Correct Answer by Jaime Valencia about 7 years 3 months ago

Unfortunately the only automatic removal mechanism is the removal from LDAP users after they're inactive, that is handled by the garbage disposal mechanism.

There is no automated mechanism to delete anything else based on time criteria.


HTH


java


If this helps, please rate


www.cisco.com/go/pdihelpdesk

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Jaime Valencia Thu, 03/04/2010 - 06:09
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    2011

Unfortunately the only automatic removal mechanism is the removal from LDAP users after they're inactive, that is handled by the garbage disposal mechanism.

There is no automated mechanism to delete anything else based on time criteria.


HTH


java


If this helps, please rate


www.cisco.com/go/pdihelpdesk

Correct Answer
William Bell Thu, 03/04/2010 - 06:12
User Badges:
  • Purple, 4500 points or more

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

andy_vvc2 Mon, 03/08/2010 - 03:05
User Badges:

Thanks for the updates guys. Bill - a most detailed post! We have limited SOAP/AXL resources, so i dont think we can pursue any of your ideas. However, it would be nice to see Cisco themselves reading your post and perhaps trying to incorporate somekind of feature into future CUCM releases. A pre-made 'Tool' for automated user deletion would be very useful i suspect - even if all it does is (12 months-or-so after an 'inactive' date is first flagged) simply delete a user and associated ID's if the user was missed by a manual user deletion process.

Actions

This Discussion