×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Creating ODBC for wallboard or external database in UCCX

Document

Wed, 12/16/2009 - 10:39
Nov 27th, 2009
User Badges:
  • Cisco Employee,

There are two scenarios in which we create ODBC connection



-->In case we use wallboard we create the ODBC connection from the wallboard server towards the IPCC server and in this case the authentication type has to be windows authentication and NOT the sql authentication



-->In case we have the database on the external server and we create ODBC connection from the IPCC server to the external datasource server then we can use either sql or windows NT authentication.


We can create a user on the external Server and give it local admin rights if we want to use Windows authentication or give admin rights on the sql database if we want to use sql authentication and then create the ODBC connection from CRS towards the external database.




Note


One common issue in case of HA is that sometimes customers use Database lookup steps in script and there they don’t get the System DSN in the dropdown.


In this scenario make sure that the ODBC connection is created on both the servers and then refresh the database and after that System DSN should populate in the dropdown in the script.



Steps to create ODBC connection for wallboard (ODBC connection from the PC running wallboard towards CRS server)




=== On the CRS Database Server ===


Create a user/password that matches the account to be used on the server where the reporting client will be running.  Grant the account administrative privileges.




=== On the Server running the reporting client ===


From the Windows Control Panel:


- Create a system DSN on your Windows 2000 Professional or Windows 2000 Server by choosing Start> Programs > Administrative Tools > Data Sources (ODBC).




The OBDC Data Source Administrator window opens.



- Click the System DSN tab and click Add. The Create New Data Source window opens.



- In the Create New Data Source window, choose a SQL Server driver and click Finish.




The first Create a New Data Source to SQL Server window opens.


  - In the Name field, specify a name for this DSN (for example, CRS-HRDB.)


  - In the Description field, enter a descriptive name\.


  - In the Which SQL Server field, enter the CRS server IP address or system name followed by \CRSSQL  For example, MyCRS\CRSSQL.


  - Click Next.




The second Create a New Data Source to SQL Server window opens.




- In the second Create a New Data Source to SQL Server window, click the Windows NT server authentication radio button.


- Click Next.




The third Create a New Data Source to SQL Server window opens.


- In the third Create a New Data Source to SQL Server window, change the default database to db_cra and click Next.




The fourth Create a New Data Source to SQL Server window opens.


- In the fourth Create a New Data Source to SQL Server window, click Finish.




The ODBC Microsoft SQL Server window opens.


- In the ODBC Microsoft SQL Server window, click Test Data Source.



If the phrase Test completed successfully is returned, click OK. This should allow you Wallboard system to access CRS database as required.

Loading.
vladimirbanker_2 Sat, 11/28/2009 - 23:17
User Badges:

In case of HA, how determine which SQL server currently active and writing real-time information?

Rajiv Lal Sun, 11/29/2009 - 04:54
User Badges:
  • Cisco Employee,

Hi,


The HA deployment works in publisher subscriber model.

Please go through the below note and it will help you:


Database Redundancy



When deploying with High Availability, for Historical Data store, Agent Data store, and Repository Data store, the two servers running the Database components are set up with one being the Publisher and one being the Subscriber. These roles do not change in the event of a failure. If both the Publisher and the Subscriber are up and running, then the server running the Publisher Database component is given DB mastership, where data is written to and read from. If the server running the Publisher Database component is down (or any of the SQL Services such as MSSQL$CRSSQL, Distributed Transaction Coordinator or SQL Agent$CRSSQL on the server with the Publisher Database is down) then the Subscriber is given the DB mastership, where data is written to and read from. SQL Merge Replication replicates the data between the Publisher and Subscriber. If the Subscriber or Publisher is down for less than the retention period (default is 4 days for Hardware with more than 18GB Hard Drive, and it is 2 days for Hardware with smaller 18GB Hard Drive), replication will automatically kick-in to sync data from the Publisher when the Subscriber comes back in service and vice versa. If the Subscriber is down for more than the retention period, the Subscriber has to be reinitialized at off-peak hours from the CRS Administration Datastore Control Center page.


Under normal call load volume, a latency of 1 to 3 minutes for SQL Merge Replication is expected; this could be higher for higher call load. The impact could be more when Historical Reports are running as it impacts the SQL processing. Due to replication latency, the Historical Reports which get generated from a Subscriber, might not have the latest call records; the Historical Reports will be generated up to the last replicated time.
SQL Server “linked server” technique is used to replicate configuration data store data in High Availability deployments. The way it works is that when both servers with Databases components are operational, configuration data store changes, such as skills and resource groups, are written to both the servers with Database components. If one server with a Database component is down, then configuration data store changes are not possible. However, configurations can be read in CRS Administration; that is, no configuration data store data writes are possible, but data reads are possible when one server with a Database component is down. However, call processing, historical data writing, and call activity reporting can continue even when one Database component is down.
In the case when one of the Database servers is not operational and configuration data store changes are required, you can temporarily "deactivate" the configuration data store component on the off-line Database component server using CRS Administration. After that, you can make configuration data store changes on the active Database server. Once the off-line Database server is back in service, you can "activate" the configuration data store component on that Database server during off-peak hours as the whole active database configuration data store data will get synchronized.



HTH

wplantier Wed, 12/16/2009 - 10:39
User Badges:

I have connected to the db and have the wallboard installed in IIS. I get a 403 error when I try and access the webpage. Has anyone else run into this?

Actions

This Document

Related Content