Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Tiger reporting after upgrade to CallManager version 4.0.2sr2b

Hi,

We have a Tiger 2020 call reporting system which is linked into our CallManager publisher.

When Tiger was installed we were running version 4.0.1 of CallManager and the database on the CallManager was CCM0300.

Having upgraded to CallManager version 4.0.2sr2b a new database on the CallManager (CCM0301) has been created.

Needless to say, Tiger has now stopped picking up call logs. Does anyone know how to edit the Tiger configuration to work with the new CallManager database ?

cheers

Chris

1 ACCEPTED SOLUTION

Accepted Solutions
Gold

Re: Tiger reporting after upgrade to CallManager version 4.0.2sr

I'm not familiar with that package, and Tiger's website is pretty light on content. However, pretty much any CDR package that talks to the CallManager CDR database is going to use ODBC to do so. ODBC is a standard database interface used by programs like Tiger to access any kind of database. Drivers for specific databases like Microsoft SQL Server (used on CallManager) are layered under that.

On your machine running the Tiger call reporting system, go to Administrative Tools, Data Sources (ODBC) and then go to the System DSN tab. In here you'll probably see one or more sources related to Tiger. Edit those, and on one of the configuration screens you'll have the opportunity to change the default database.

Please note that after CallManager version upgrades, the CDR database itself does NOT move. Only the CallManager configuration database does. If Tiger truly needs access to CallManager config info, you may have to adjust that DSN but you shouldn't have to change the one you have configured for the CDR database.

The upgrade may also have disabled the type of authentication you use to talk to SQL Server. SQL Server supports Windows authentication or its own embedded list of usernames and passwords (SQL authentication). The CallManager installer now sets SQL Server to use only Windows authentication, and may have done so on your upgrade. If your ODBC DSN on your Tiger call processing machine tries to use anything other than Windows authentication, it might be failing on that basis. You can undo this change on CallManager with the SQL Enterprise Manager tool in the Microsoft SQL Server program group, on the CallManager publisher server. Right-click on your publisher SQL server (either "local" or the hostname of your publisher), get Properties, and on the Security tab change Authentication to "SQL Server and Windows" if it's not there already. Do this during a maintenance window, as you may need to restart SQL Server to have the change take effect and it's probably best to just reboot.

1 REPLY
Gold

Re: Tiger reporting after upgrade to CallManager version 4.0.2sr

I'm not familiar with that package, and Tiger's website is pretty light on content. However, pretty much any CDR package that talks to the CallManager CDR database is going to use ODBC to do so. ODBC is a standard database interface used by programs like Tiger to access any kind of database. Drivers for specific databases like Microsoft SQL Server (used on CallManager) are layered under that.

On your machine running the Tiger call reporting system, go to Administrative Tools, Data Sources (ODBC) and then go to the System DSN tab. In here you'll probably see one or more sources related to Tiger. Edit those, and on one of the configuration screens you'll have the opportunity to change the default database.

Please note that after CallManager version upgrades, the CDR database itself does NOT move. Only the CallManager configuration database does. If Tiger truly needs access to CallManager config info, you may have to adjust that DSN but you shouldn't have to change the one you have configured for the CDR database.

The upgrade may also have disabled the type of authentication you use to talk to SQL Server. SQL Server supports Windows authentication or its own embedded list of usernames and passwords (SQL authentication). The CallManager installer now sets SQL Server to use only Windows authentication, and may have done so on your upgrade. If your ODBC DSN on your Tiger call processing machine tries to use anything other than Windows authentication, it might be failing on that basis. You can undo this change on CallManager with the SQL Enterprise Manager tool in the Microsoft SQL Server program group, on the CallManager publisher server. Right-click on your publisher SQL server (either "local" or the hostname of your publisher), get Properties, and on the Security tab change Authentication to "SQL Server and Windows" if it's not there already. Do this during a maintenance window, as you may need to restart SQL Server to have the change take effect and it's probably best to just reboot.

398
Views
0
Helpful
1
Replies
CreatePlease login to create content