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?

It is true.  Auditing of administrative tasks was added in CUCM 7.1(2) and later.  I did a write up on how to configure and use the audit logs here:

http://www.netcraftsmen.net/resources/blogs/audit-logs-on-cucm.html

Hopefully it will answer your question and give you some ideas.

HTH.

Regards,
Bill

Please remember to rate helpful posts.

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

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 :192.168.1.4 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 :192.168.1.4 Severity :5 EventType :GeneralConfigurationUpdate ResourceAccessed:CUCMAdmin EventStatus :Success AuditDetails : record in table device with key field name = 10.3.6.21 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 d.name,dt.name as devicetype from device as d inner join typeModel as dt on d.tkModel=dt.enum where d.name = "10.3.6.21"

name devicetype

========= ==========

10.3.6.21 Trunk

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

04/06/2010 13:38:13.958 |LogMessage UserID :ccmadministrator ClientAddress :192.168.1.4 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 :192.168.1.4 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.

HTH.

Regards,

Bill

Please remember to rate helpful posts.

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

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 ???

Thanks,

Bill

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?

Mark,

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.

Regards,
Bill

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.

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:

user_css:

- phone_pt

- ict_pt

- pstn_pt

pstn-in_css

- phone_pt

ict-in_css

- 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.

Example

Cluster_A Servers in the cluster:

- node1: 10.1.1.10

- node2: 10.2.2.10

Cluster_A CUCM GroupA:

- node2

- node1

Cluster_B ICT Trunk Remote node list:

- 10.2.2.10

- 10.1.1.10

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:

- 10.1.1.10

- 10.2.2.10

HTH.

Regards,

Bill

*Please remember to rate helpful posts!!