Wednesday, January 21, 2015

Cisco ACS Migration, 4.2.x to 5.6

So it's been a while since I've written anything, and that's mostly because the majority of things I work on are now considered classified, internal, or confidential. It makes it difficult to write topics on concepts when you're not 100% certain the public can know anything about it.

This however, I'm relatively certain I'm good to work with.

So the company that I'm working with now is in the process of migrating some of their ACS servers from 4.2.x appliances to 5.6 appliances. Cisco has a pretty comprehensive guide on the process here.  One of the major issues that comes from 4.2.x on an appliance versus a Windows server comes from the fact that you need an NT Agent on a Domain Member server so that it can connect to Active Directory accordingly. On a Windows Server, the NT Agent is local, so it's not a worry. Well, Secure ACS 5.6 no longer needs that Windows NT Agent, it can just point directly at the LDAP server--great!

Except that we also have another major issue by having appliances. In order to migrate the database from 4.2.x to 5.6, you must first export the database from the appliance to a Windows Server, so that you can run the migration tool against it.

Which means that to migrate, you'll need:

  • Your source ACS Appliance
  • Your Windows Server to host the ACS Application
  • A Windows version of ACS
  • Your 5.x Appliance or Virtual Machine
  • A series of helpful web links

Which is one of the reasons we have this blog post, is to provide a series of helpful web links, and share some of my infuriating issues.

Most of everything comes from this link, the Migration guide from ACS 4.x to 5.6. You'll also want to know how to re-image the appliance in the event that you blow it up.

Now, Cisco offers a full version of ACS 4.2 that's a trial to download, so as long as you have a support contract you'll be fine there.

This leaves you needing a Windows Host to run the software on. And...according to our documentation, ACS 4.2 runs on Windows Server 2008 x64. Note: Not R2. This was a huge problem in our environment, because their bare minimum standard for Windows Servers was Server 2k8R2. And because it's larger corporate politics, that meant lots of paperwork, lots of documentation, lots of justification, and someone's time to spin off a new Virtual Machine for me.

While waiting on the Virtual Machine spin-up, it's a good time to bring online the ACS Appliance for 5.6. Important note that I discovered during installation: the NTP server (or it was the gateway) must be reachable while loading the IP settings, or else you'll have to re-image it from scratch. Not sure why, but that's what I had to end up doing.

Once you have your ACS 5.6 appliance or virtual machine running, complete with remote accessibility, you can begin your migration. After waiting for your Windows Server to be built, loaded with Java, and imported from a backup, you're ready to begin.

First, download the migration utility from the ACS Appliance and load it on your Windows Server.

Next, when connecting, specify a username and password and connect accordingly.

Then, after troubleshooting the connections and available configuration settings, spend several hours tearing your hair out trying to further troubleshoot why the connection continues to fail for no reason. Then you find an obscure post on a German Cisco forum that leads you to this link. The point of reference that made me nearly scream was this:

Remote Desktop Support
The Migration Utility does not support Remote Desktop Connection. You must run the Migration Utility on the migration machine; or, use VNC to connect to the migration machine.

 So make sure when trying to run the migration utility, you don't RDP into your Virtual Machine. You have to VNC into it, or get some local hardware to run it off of.

Edit: On to the next issue....(You'll want to read that post if you haven't already)