Moving Cisco CSA Management Center


The following assumptions are being made

  1. The database is MS SQL Server 2005 Express Ediation and is housed on the same server as the CSA MC
  2. CSA version 6.0
  3. Screenshots show the old CSA MC with name “CSA” and the new CSA MC with name “CSA2”

Creating the New CSA MC
The first step is to install the exact same version of CSA MC application on the new server. The license does not need to be installed on the new CSA MC because the license will be moved over from the old CSA MC as part of the database move.

The next step is to move the database from the old CSA MC to the new CSA MC. This will allow all the registered agents, groups, rule modules, rules, etc to be moved to the new CSA MC. The detailed steps are listed below.

Note: It is important to note that doing this fully replaces the existing database. This means that any SSL certificate, Agent, policy, group,etc information on the existing database will be removed. We will see how this affects the Agent registration for the new CSA MC later.

First, on the new and old CSA MCs, stop the CSA MC service and the Agent, running on the CSA MC, using the following commands

Open Start->Run… and type “services.msc”. Stop the Management Console, MSSQL, and Agent services. The services should look similar to the names below.

On the new CSA MC, rename the c:Program FilesCiscoCSAMCCSAMC60db directory to a new name, such as db-backup. Next, copy the c:Program FilesCiscoCSAMCCSAMC60db directory from the old CSA MC to the new CSA MC. At this point you have fork lifted the database from the old CSA MC into the new CSA MC. Reboot the new CSA MC.

Updating Agent Kits
As mentioned earlier, the old CSA MC database has been fork lifted into the new CSA MC and fully replaced the existing database on the new CSA MC. This means that any existing agent kits and any new agent kits generated on the new CSA MC still reference the old CSA MC. To correct this, we need to dig into the database and modify some entries.

Note: The database changes are based on my own research. Use at your own risk

The CSA MC installation did not include the Management console to view the SQL Server 2005 database. Microsoft offers the Microsoft SQL Server Management Studio Express to manage the database. Download this application to the CSA MC and install it. After it has been installed, launch it. Take the default login settings as shown below

Navigate down the database tree to the following section

Within this tree scroll down and look for “dbo.mc_config”. Right click on the name and click “Open Table” as shown below

The table shows the entries that get sent as part of the Agent Kit. We will modify the parameters to reflect the new CSA MC instead of the old CSA MC.

This screenshot shows the database before any changes were made. The name CSA references the old CSA MC as does the IP

This screenshot shows the database after the changes were made. The name CSA2 references the new CSA MC as does the IP

In addition to the changes listed above, you should probably modify the sslca.crt, sslca.ns, sslca.key, sslhost.crt, sslhost.csr, and sslhost.key files in the database. In my testing, everything seemed to work fine without modifying the values, but for completeness sake, I would recommend modifying both the names and the data to reflect the information on the new CSA MC server. The data can be retrieved from the c:Program FilesciscoCSAMCCSAMC60cfg directory. Right click on each file and open with notepad. Then copy the entire contents and paste it into the value portion of the database.

After the database has been changed, the agent kits need to be refreshed to incorporate the new values. This can be done by running the following command

C:Program FilesCiscoCSAMCCSAMC60in>webmgr makekits_refresh
Generating rule programs…
Regenerating agent kits…

Once this is complete, the agent kits will have the correct information referencing the new CSA MC.

Fixing the Agent on the New CSA MC
Now, access the web GUI and navigate to Systems > Hosts. You’ll notice that the new CSA MC server is not listed. This is because we are using the database from the old server. This is shown below.

The old CSA MC does not need to be listed here, so you can move the server named “” to the recycling bin.

The Agent running on the new CSA MC,, is not showing up because we are using the database from the old CSA MC. The new CSA MC was registered in the original database on the new CSA MC. This was the database that we renamed “db-backup”. Confirmation of the problem is shown in the agent logs on the new CSA MC

1504: CSA2: Feb 06 2009 21:58:10.773 -0600: %CSA-4-REGISTRATION_FAILED_INVALID_REGID: %[Component=Csamanager][PID=1076]: No deployment host exists on server with registration ID={90A55B27-4F2B-490A-A27E-081D8747E3F5}.

We need to get a new registration that is recognized by the current database on the new CSA MC. In order to do this, the following steps should be followed:

  1. Remove the Agent on the new CSA MC
  2. Reboot
  3. Download and install the “Servers CSA Management Center V6.0.0.201” Agent Kit from the new CSA MC.
  4. Reboot
  5. Verify that the new CSA MC shows up in the CSA MC web GUI in “Systems > Hosts”.

Following these steps will allow the Agent, running on the new CSA MC, to be properly registered and displayed.

Handling Existing Agents
The registration IDs for the existing Agents have been ported to the new CSA MC with the database move. There are just two steps that need to occur, on the computers with the Agent installed, to complete the migration of the already deployed Agents from the old CSA MC to the new CSA MC

  1. Modify the c:Program FilesCiscoCSAgentcfgagent.bundle file to reference the new CSA MC
  2. Replace the c:Program FilesCiscoCSAgentcfgsslca.crt file to reference the new CSA MC

To complete step 1, you will first need to stop the Agent with the “net stop csagent” command. After that, open the agent.bundle file and make the modifications as shown in the screenshots below. In the screenshots, CSA and reference the old CSA MC and CSA2 and reference the new CSA MC. The original file is shown on the left and the new file is shown on the right

The second step was to replace the sslca.crt file. The CSA MC creates its own root certificate and distributes it in the CSA Agent Kit. The Agents then trust the SSL certificate provided by the CSA MC because it is signed with the root certificate. When the CSA MC is changed, the root certificate also needs to be changed to reference the new CSA MC. The new sslca.crt can be obtained from the new CSA MC in the c:Program FilesCiscoCSAMCCSAMC60cfg directory. It needs to replace the c:Program FilesCiscoCSAgentcfgsslca.crt file on each computer with the Agent.

The two steps above can normally be accomplished with a central application used to push out applications. Some examples of these applications would be Microsoft SMS or Altiris.

Once the two step above are completed, you should see the following screen on the Agent status page


Posted by Rob Chee

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.