ACS 4.2 to 5.8 migration

[bijbalaktn]

Team -  I have a customer who wants to  migrate his ACS from 4.2 to 5.8.  They currently  have a primary and a back up server. 

1) Can anyone suggest a migration plan to avoid  any downtime during the migration.

2) Wouldn't it require a config change in all the network devices , can this be done centrally ?

I don't have any previous experience doing this. Any help on this is appreciated.

Bijbalak

[Nadav]

See my reply:  https://supportforums.cisco.com/discussion/12693916/acs-migration-4x-57

There is no downtime during migration if you have a distributed existing topology. No config changes for devices as NDG and devices are migrated. 

[Marvin Rhoads]

@hod.nandav

Did you actually get the 4.x-5.x Migration Utility tool to work?

I tried it and eventually gave up as it was a very vexsome tool. Some Cisco SEs I talked to had the same experience.

[bijbalaktn]

Hi Marvin - Do we have a plan B if the utility doesn't work.

BijBalak

[Nadav · Accepted solution]

You shouldn't need a plan B, I got it working in a few environments. But if you decide not to use the migration tool, you can use CSUtil and parse the dump to a CSV that ACS 5.x can import

http://www.cisco.com/c/en/us/td/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4-2/trouble/guide/ACSTrbG42/Ch1.html#wp1041501

I haven't encountered any issues with the migration tool on a working ACS 4.2 Windows server. 

[bijbalaktn]

Thanks Hod.. So in all we have 3 machines.

 1) The current ACS 4.2 server which would be the source.

 2) The Migration server ( Windows server ) to which we would backup the database from the source.

 3) The Target which would be the new CSACS 3495 appliance.

Correct ?

Also wanted to know -  Customer currently has 2 ACS 4.2. Primary ACS which is in City A and Se ondary ACS  which is in city B.  Which one should be migrated first.  Also when you said no changes in the network devices.. How do we do that. Keeping the IP address the same ? But we cant have 2 machines with the same IP address in the network ... Am i getting it wrong ?

Please advise.

[Nadav]

You could use a dedicated migration server, but from my experience you can just run the tool off a working ACS server. I don't recall any disruptions due to running the migration tool off my second ACS whilst migrating the database to the new primary ACS.

As for migration, if this is a single cluster then all you need to do is migrate from a secondary ACS to the new primary ACS (your CSACS 3495). After this you need to configure certain things on the new ACS, including ADE-OS configurations, access policies, AD/LDAP integrations, certificates and so on. Make sure to have a separate license file per ACS server in the cluster.

The secondary ACSes during this time can continue to serve your clients whilst the primary is down and being configured. Once the primary ACS is ready, allow traffic to and from it and create secondary ACSes as needed. Add the secondary ACSes to the primary as part of a cluster and they will receive all the configuration. 

Keep in mind that you'll need to upload the certificates to your secondary ACSes separately. This is necessary for LDAP integration and Trusted communications, among other things. After the secondaries are in the cluster, you can also configure the cluster to work as a distributed solution for LDAP so that bind requests have fallback LDAP servers.

[bijbalaktn]

So you mean. Take the old secondary ACS and migrate it to the New  3495.   While this migration is taking place the requests are being served by the Old Primary server.  After migration,the new secondary ACS server will be up and running.   Once done, we start with the primary server migration. During this time the client request would be handled by the new Secondary 3495.   So we are just swapping the IP address from Old Secondary to the new secondary . Similar with the primary ACS server.  Am I correct ?

[Nadav]

Not quite. This is what's worked for me:

old primary ACS => ACS_O1

old secondary ACS => ACS_O2

new primary ACS => ACS_N1

new secondary ACS => ACS_N2

1. Deny traffic from NASes to ACS_O1 so that only ACS_O2 can serve them.
2. Turn off ACS_O1. Then install ACS_N1. Make sure that ACS_O2 is up to date before doing so.
3. Migrate from ACS_O2 to ACS_N1 with the migration tool on ACS_O2. During this time radius/tacacs requests can still be received by ACS_O2 from NASes.
4. Once ACS_N1 has the migrated database, configure ACS_N1 as needed whilst ACS_O2 deals with the requests.
5. Once ACS_N1 is configured as you see fit, permit traffic from NASes to ACS_N1 and deny traffic from NASes to ACS_O2. This will allow your clients to work with ACS_N1 and allow you to test that your configuration is correct. You can do this in gradual steps so that not all the NASes work with ACS_N1 at once.
6. Shutdown ACS_O2 and install ACS_N2. Add certificates and licenses as needed.
7. Add ACS_N2 to your primary ACS (ACS_N1). Confirm the request on ACS_N1. After the services go back up on ACS_N2, it will now be part of the cluster.
8. Remove rules which denied traffic from earlier, or better yet first block ACS_N1 and prove that your NASes work correctly with ACS_N2. 

[Nadav]

Hi,

It worked just fine. Ran it on Windows Server 2003. Just run it from command line on one of your existing ACS 4.2 servers. You'll need to allow TCP 443 traffic from migration server to new ACS 5.x server and allow the migration interface on the new server via ADE-OS.