call manager logging / auditing

Unanswered Question
Anonymous (not verified) Tue, 05/22/2007 - 13:08
User Badges:

logging feature not supported by Call manager.

But for alternative option :

If you have installed Call manger on Windows, set up a new NT user and made this user a member of the Administrators

group. As our CCM's are not part of a domain I had to define this user on each CCM server or the ASP scripts would not run with appropriate permissions on the other servers.

Security logging is disabled by default. This is enabled in Programs ->Administrative tools -> Local Security Settings -> Local Policies -> Audit Policies.

I would enable the bare minimum of auditing here just to capture user logon and logoff. (The security log is viewed via the

Event Viewer).

IIS logging however appears to be enabled by default. The logs are probably in winnt/system32/log files/w3svc1 and appear to be quite extensive.

mmendonca Tue, 04/06/2010 - 05:19
User Badges:

I've been told that Auditing is a new feature in releases

7.x and up.  I've searched but can't find any info regarding it is true?

mmendonca Tue, 04/06/2010 - 10:32
User Badges:

Very cool, very detailed thank you very much.  You wouldn't happen to do have done something like that on non-gatekeeper Intercluster trunks? 

William Bell Tue, 04/06/2010 - 10:51
User Badges:
  • Purple, 4500 points or more

Glad it was helpful. I am not sure I understand the follow up question. The Audit Log would capture changes to route patterns, route groups, route lists, and ICTs just like it would anything else. The following is a sample from my lab using an existing ICT I have from a CUCM 7.1 system to a CUCM 6.1 system:

I access the CCMAdmin page

04/06/2010 13:36:53.961 |LogMessage UserID :ccmadministrator ClientAddress : Severity :3 EventType :UserLogging ResourceAccessed:Cisco CallManager Administration EventStatus :Success AuditDetails :Successfully Logged into Cisco CCM Webpages ComponentID :Cisco CCM Application App ID:Cisco Tomcat Cluster ID: Node ID:iecucm01|

I modify the ICT device:

04/06/2010 13:37:36.507 |LogMessage UserID :ccmadministrator ClientAddress : Severity :5 EventType :GeneralConfigurationUpdate ResourceAccessed:CUCMAdmin EventStatus :Success AuditDetails : record in table device with key field name = updated ComponentID :Cisco CUCM Administration App ID:Cisco Tomcat Cluster ID: Node ID:iecucm01|

Notice that there is nothing that indicates this is an ICT. You would have to do something like this to figure that out:

admin:run sql select, as devicetype from device as d inner join typeModel as dt on d.tkModel=dt.enum where = ""

name devicetype

========= ========== Trunk

Here I add the existing trunk to a new Route Group:

04/06/2010 13:38:13.958 |LogMessage UserID :ccmadministrator ClientAddress : Severity :5 EventType :GeneralConfigurationUpdate ResourceAccessed:CUCMAdmin EventStatus :Success AuditDetails : record in table routegroup with key field name = TestICTAddRG added ComponentID :Cisco CUCM Administration App ID:Cisco Tomcat Cluster ID: Node ID:iecucm01|

Here is an example log for adding a new Route List for ICT trunk

04/06/2010 13:38:40.774 |LogMessage UserID :ccmadministrator ClientAddress : Severity :5 EventType :GeneralConfigurationUpdate ResourceAccessed:CUCMAdmin EventStatus :Success AuditDetails : record in table device with key field name = TestICTAddRL added ComponentID :Cisco CUCM Administration App ID:Cisco Tomcat Cluster ID: Node ID:iecucm01|

So, as you can see you would need to have some knowledge on what is in place to piece changes recorded in the audit log together.

Not sure I answered your question or not. I was taking a stab for sake of time.




Please remember to rate helpful posts.

mmendonca Tue, 04/06/2010 - 11:01
User Badges:

Sorry for the confusion.  What I meant was have you done another paper like this one for configuring non-gatekeeper intercluster trunks?

William Bell Tue, 04/06/2010 - 11:13
User Badges:
  • Purple, 4500 points or more

Ahhh, gotcha. No I have not covered that topic yet. I am working on one related to ICT, using SAF and CUCM 8.x. I have to free up some space on my vmware server to load a few instances of 8.x and then plan on diving in. Will take a few weeks, so I guess I should say: stay posted ???



mmendonca Tue, 04/06/2010 - 11:30
User Badges:

Sounds very interesting thanks.  I've searched far and wide on ICT.  Can't seem to find the detail that I'm looking for.  Do you have any other source that you could recommend in the mean time?

William Bell Thu, 04/08/2010 - 18:50
User Badges:
  • Purple, 4500 points or more


Saw your comment on my blog site.  Just wanted to let you know don't worry about it.  I don't have many cycles to do the ICT/SAF thing right now but I will get to it when I can.  If I remember, I will post a follow up here.


mmendonca Fri, 04/09/2010 - 05:49
User Badges:

Thanks Bill.   I think I've searched through every piece of info on NG ICT on the interenet.  Couple of quick question should I put the ICT in the same device pool and CSS that the phones are in or create a separatae DP and CSS that contains the partition of the phones?  The route patterns I would put in the same partition as the phones and point them to the ICT? 

I know I should have created a separate thread for this I know DOH!   With all due respect to Bill if anyone else would like to answer or provide the method they use please do.

William Bell Fri, 04/09/2010 - 06:19
User Badges:
  • Purple, 4500 points or more

You can still start another thread if you wish. Not a bad idea as others who troll the forum may not know you need ICT help based on the tagline/subject line. Anyway, it seems to me you need more background on basics of a dial-plan.

From an architecture point of view I would use a different partition/css arrangement for ICT and phones. But this is my personal preference. I have a hang up on modularity, so at a high level I would do something like this:

1. Partition Categories:

-Phones (e.g. phones_pt)

-PSTN route patterns (e.g. pstn_pt)

-intercluster route patterns (e.g. ict_pt)

2. CSS:

- phones: (e.g. user_css)

- gateways (pstn): pstn-in_css

- interclust trunks (ict): ict-in_css

The CSS/partition assignment could look like the following. I am keeping it simple for this thread. I have a slightly different approach in my design but that would be a really long presentation. Anyway:


- phone_pt

- ict_pt

- pstn_pt


- phone_pt


- phone_pt

You have to pay attention to overlap and all of the obvious dial plan rules. But this is simple and effective. I know that the pstn-in_css and ict-in_css look the same and they could be the same css if you choose. I don't do this myself because (a) I have other partitions in my standard DP design and (b) I like the ability of being able to modify the ict configuration without worrying about the pstn config.

As far as device pools. It really doesn't matter a whole lot. With ICT, the only thing you want to make sure is applied is that the IP address list for the remote CUCM nodes in your local ICT trunk lines up with the CUCM group config on the remote CUCM cluster. People have a hard time with this one and they don't believe me but I have encountered issues when this simple rule wasn't followed.


Cluster_A Servers in the cluster:

- node1:

- node2:

Cluster_A CUCM GroupA:

- node2

- node1

Cluster_B ICT Trunk Remote node list:



The above "CUCM Cluster_B ICT Trunk" remote node list is OK. However the following would be WRONG:

(wrong) CUCM Cluster_B ICT Trunk Remote node list:






*Please remember to rate helpful posts!!


This Discussion