cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
993
Views
0
Helpful
11
Replies

Upgrading the new hardware, data migration

bilalghayad
Level 1
Level 1

Dear Forum;

I need to upgrade the hardware for the IPCC solution we have without changing the versions, the following servers need to have the new hardware:

1) Call Managers (Publisher + Subscribers).

2) RGRs

3) PGs

4) HDS + ICM + Admin + Web view

As versions will not be changed for all the above, what is the best method to migrate the configurations and scripts in a safe fast way? Can someone advise?

Regards

Bilal

6 Accepted Solutions

Accepted Solutions

geoff
Level 10
Level 10

I won't speak about the Call Manager - others may be able to, or you could ask your question on the Voice forum.

I am in the process of migrating the Central Controller and two AW/HDS from one continent to another continent without an upgrade, and I therefore have inside knowledge of what you are facing. I'm not going to provide details here on this forum, but just give you some general advice.

If you follow up and ask a detailed question I may answer it in detail. You need to do the hard yards on this one.

The first thing you need to overcome is any desire to do this in a "fast" way. "Safe" yes - but not "fast". The actual move of the CC can be done in a day, but the preparation should be intensive over a month or so.

You need to prepare an extremely detailed plan - a step by step process - and work through it many times to make sure you have covered everything.

Then you need to test things in a lab.

The basics are outlined in the Cisco Upgrade Guide - but of course, you are not upgrading so you will not be using the EDMT. But much of what is there is extremely relevant.

However, you will find differences in the order you must do things on the Central Controller and a migration of 7.2.x will be different to the migration of a 7.5 system. Don't take anyone's word for granted - even Cisco TAC. There is only one way to know how to do this - and that is to do it yourself in your lab.

You must be absolutely confident you have covered everything - and having made a few mistakes in the sequence and adjusting the sequence in the lab will give you confidence. When the time comes to do the migration, you will be armed with your detailed step by step process document and there will be no surprises.

Like an upgrade, TAC are ready to help. A couple of days before the migration you want to open a TAC case to prepare. You should give the case number to your Cisco AM so that he can raise the profile with the TAC operations manager and you will be assigned the right person(s) - and the flow from TAC region to region as the day goes by will be smooth. This is very important.

Finally, if you can open a maintenance window of 12 hours or so the migration will be far easier (in my opinion) than if you have to keep the Call Center running (running on the B side while you migrate the A side etc.)

Regards,

Geoff

View solution in original post

Exactly - it's like the Tech Refresh Upgrade in the document - but without the upgrade. You won't be doing anything "manual".

1. You don't need any active directory stuff if you are keeping the DCs. Even if you are not, put your new machines in now, promote them to ADs, allow replication and move the GC and the FSMO roles. Let it settle down over a week or so, and then remove the old servers.

So Registry and DB only.

2. Bring on the new AWs now. Add to domain, make into AWs, not HDS. Use SQL backup and restore to build the xxx_hds database on each HDS (A side to A side, B side to B side) and then promote to be an HDS. Check replication. You are allowed to have 4 x HDS.

3. Restore the WV database from SQL backup and restore and point your current WV server at the new HDS and WV DB. Now you can drop the two HDS and remove the hardware.

The central controller is where you need to focus your efforts and develop your plan, and test it in the lab. You need a detailed step by step plan. Use the upgrade guide to get some ideas, but you must verify it in a lab. Preferably in the customer's lab.

Regards,

Geoff

View solution in original post

1) In the DC storey, I did not understand the meaning of: promote them to ADs? By the way: Do u mean to install the Domain Controller and AD first and then to promote them to ADs?

You did not say if you wanted a tech refresh on the Domain Controllers or not. In fact you did not say if ICM has a dedicated domain or is using the corporate domain.

If you do have to add new hardware for the Domain Controllers, then I gave you the method:

1. Add the servers to the existing domain.

2. Promote them to DCs (using dcpromo) - now your domain has 4 DCs.

3. Move the FSMO roles from the machine they are now on (probably DC2) to DC4

4. Move the GC (global catalog) from the machine it is now on (probably DC1) to DC2. Wait a few days for replication of AD and DNS to settle down.

5. Use dcpromo to demote DC1 and DC2 to become ordinary servers.

6. Change these machines to be out of the domain (workgroup)

7. Remove servers. Clean up DNS.

2)  About the AWs, why to "Add to domain, make into AWs, not HDS"? I mean, why not the HDS? Also what do u mean by promote them to be HDS?

You should always make your AW/HDS in two phases. First, run setup from the media and make a real-time distributor - primary, no secondary. Install the SR. Make sure the real-time feed to your CCs is working. Set it to manual. Now run ICMSetup.exe from the ICM bin and "promote" to an HDS - check the HDS box. It will complain that you have not finished the install because you have not created the HDS DB with ICMDBA. Ignore this but don't start the Distributor. Use SQL backup/restore to build the HDS. Now start the Distributor and check that Replication is all working - increase the trace on rpl to 0xfff so you can see the msgs - check on the logger side with similar trace mask.

3) About the Central Controller: there are the Logger DB, will this DB has some missing as there is not method to recover this for the last moments (before moving live)?

If you do it correctly using SQL backup/restore you will not lose data. If you have to keep the contact center running on side B while you do side A, things will be a bit more complicated - read the Upgrade Guide to see how logger synchronization solves this.

As I said, if you can have a 12 hour maintenance window for the migration of the CC and bring the whole contact center down to migrate, life will be easier.

As I see the most critical part in this upgrade is not loosing the configuration and it is not the need to build every thing manual (as the moving for registry is easy, and the restore for the database is easy) but the system to become up and running is also easy, but the hard part is the avoid loosing the data. Correct? All the need to have the training is to be around how to avoid loosing the data? But no worry that service will be up and running by having the restore for the database and moving the registry.

I don't follow that paragraph. Backup and restore and import of the registry solves this. Nothing will be lost. Read the Upgrade Guide again.

Do you have a lab system you can practice the migration on? Without this, the risk is huge. You must get a step by step plan written down, and trial this on the lab system.

Regards,

Geoff

View solution in original post

You need the installation CDs and, of course, the service release. You do not copy anything from the old machines but the registry and (as appropriate) a SQL backup.

How's that lab system going? By the way, what version of UCCE are we talking about?

Regards,

Geoff

View solution in original post

I think the document says to back up the c:\icm directory - but it's just for a restore. Read it again - you won't use  that on your target servers.

Regards,

Geoff

View solution in original post

You are a bit confused.

I asked you about this before. My strong preference is a 12 hour maintenance window wherein your contact center is off the air and you have some sort of default routing applied by the carrier. If you want to keep the contact center running on the B side, you need to be very careful and read the upgrade guide in depth.

You can do this until the moment you are about to start items on the new side A machines.

At this point, shutdown side B - now your contact center is off the air. B must stay down for quite some time. Bring up the CC on the new side A in simplex and point your key AW at it and bring it up. Point your PGs at the new side A and bring them up. Now the contact center is all running on the new side A.

Execute your test plan. Execute the "go/no go" decision. If favourable, do side B and then bring up a duplex system on new hardware.

Regards,

Geoff

View solution in original post

11 Replies 11

geoff
Level 10
Level 10

I won't speak about the Call Manager - others may be able to, or you could ask your question on the Voice forum.

I am in the process of migrating the Central Controller and two AW/HDS from one continent to another continent without an upgrade, and I therefore have inside knowledge of what you are facing. I'm not going to provide details here on this forum, but just give you some general advice.

If you follow up and ask a detailed question I may answer it in detail. You need to do the hard yards on this one.

The first thing you need to overcome is any desire to do this in a "fast" way. "Safe" yes - but not "fast". The actual move of the CC can be done in a day, but the preparation should be intensive over a month or so.

You need to prepare an extremely detailed plan - a step by step process - and work through it many times to make sure you have covered everything.

Then you need to test things in a lab.

The basics are outlined in the Cisco Upgrade Guide - but of course, you are not upgrading so you will not be using the EDMT. But much of what is there is extremely relevant.

However, you will find differences in the order you must do things on the Central Controller and a migration of 7.2.x will be different to the migration of a 7.5 system. Don't take anyone's word for granted - even Cisco TAC. There is only one way to know how to do this - and that is to do it yourself in your lab.

You must be absolutely confident you have covered everything - and having made a few mistakes in the sequence and adjusting the sequence in the lab will give you confidence. When the time comes to do the migration, you will be armed with your detailed step by step process document and there will be no surprises.

Like an upgrade, TAC are ready to help. A couple of days before the migration you want to open a TAC case to prepare. You should give the case number to your Cisco AM so that he can raise the profile with the TAC operations manager and you will be assigned the right person(s) - and the flow from TAC region to region as the day goes by will be smooth. This is very important.

Finally, if you can open a maintenance window of 12 hours or so the migration will be far easier (in my opinion) than if you have to keep the Call Center running (running on the B side while you migrate the A side etc.)

Regards,

Geoff

Thanks a lot for your kindly help and advise, your kindly help is highly appreciated.

OK, I need to be sure that my understanding is enough good and I need to be sure that I covered all the points in this kind of hardware upgrade (while software will stay same version), so please confirm me:

The main data that I have to take care that it is moved successfully are:

Registry, Active Directory Contents, Database (RGR + HDS + Admin + WebView)

Is there any thing I forgot it and I have to move it for the new servers?

Now if we assumed that the Backup/Copy/Restore was not done fine and it is failed, so in that case I can do the things manual (do the configuration from scratch, and re build it to be same as the current live one), but at least if I used this method then I need at least to protect my reporting, and the question here is:

If I did my configuration manual, at least I will be able to do backup/restore for the WebView & HDS & Logger Databases? Or for whom I can do backup/restore? To avoid loosing information (specially to avoid loosing the reporting).

Last point: in case I need to update any changes happened on the live, and I need to update the database with the latest informations, the best method is to take backup/copy/restore? So, before moving live, that means there should be a cut off for some hours (no changes are allowed), am correct?

By the way, my case is close for Technology Refresh and not for Common Ground as the hardware is will be new (but ofcourse, I am not going to do upgrade for the software).

Appreciate your advise and the kindly help from your experience in such task.

Regards

Bilal

Exactly - it's like the Tech Refresh Upgrade in the document - but without the upgrade. You won't be doing anything "manual".

1. You don't need any active directory stuff if you are keeping the DCs. Even if you are not, put your new machines in now, promote them to ADs, allow replication and move the GC and the FSMO roles. Let it settle down over a week or so, and then remove the old servers.

So Registry and DB only.

2. Bring on the new AWs now. Add to domain, make into AWs, not HDS. Use SQL backup and restore to build the xxx_hds database on each HDS (A side to A side, B side to B side) and then promote to be an HDS. Check replication. You are allowed to have 4 x HDS.

3. Restore the WV database from SQL backup and restore and point your current WV server at the new HDS and WV DB. Now you can drop the two HDS and remove the hardware.

The central controller is where you need to focus your efforts and develop your plan, and test it in the lab. You need a detailed step by step plan. Use the upgrade guide to get some ideas, but you must verify it in a lab. Preferably in the customer's lab.

Regards,

Geoff

Things are becoming more clear and we are closing for more specific

1) In the DC storey, I did not understand the meaning of: promote them to ADs? By the way: Do u mean to install the Domain Controller and AD first and then to promote them to ADs?

2)  About the AWs, why to "Add to domain, make into AWs, not HDS"? I mean, why not the HDS? Also what do u mean by promote them to be HDS?

3) About the Central Controller: there are the Logger DB, will this DB has some missing as there is not method to recover this for the last moments (before moving live)?

As I see the most critical part in this upgrade is not loosing the configuration and it is not the need to build every thing manual (as the moving for registry is easy, and the restore for the database is easy) but the system to become up and running is also easy, but the hard part is the avoid loosing the data. Correct? All the need to have the training is to be around how to avoid loosing the data? But no worry that service will be up and running by having the restore for the database and moving the registry.

Please correct me.

Like what tricks I might face it in this upgrade? Is it related to loosing data or to having the system running stable with the service?

Regards

Bilal

1) In the DC storey, I did not understand the meaning of: promote them to ADs? By the way: Do u mean to install the Domain Controller and AD first and then to promote them to ADs?

You did not say if you wanted a tech refresh on the Domain Controllers or not. In fact you did not say if ICM has a dedicated domain or is using the corporate domain.

If you do have to add new hardware for the Domain Controllers, then I gave you the method:

1. Add the servers to the existing domain.

2. Promote them to DCs (using dcpromo) - now your domain has 4 DCs.

3. Move the FSMO roles from the machine they are now on (probably DC2) to DC4

4. Move the GC (global catalog) from the machine it is now on (probably DC1) to DC2. Wait a few days for replication of AD and DNS to settle down.

5. Use dcpromo to demote DC1 and DC2 to become ordinary servers.

6. Change these machines to be out of the domain (workgroup)

7. Remove servers. Clean up DNS.

2)  About the AWs, why to "Add to domain, make into AWs, not HDS"? I mean, why not the HDS? Also what do u mean by promote them to be HDS?

You should always make your AW/HDS in two phases. First, run setup from the media and make a real-time distributor - primary, no secondary. Install the SR. Make sure the real-time feed to your CCs is working. Set it to manual. Now run ICMSetup.exe from the ICM bin and "promote" to an HDS - check the HDS box. It will complain that you have not finished the install because you have not created the HDS DB with ICMDBA. Ignore this but don't start the Distributor. Use SQL backup/restore to build the HDS. Now start the Distributor and check that Replication is all working - increase the trace on rpl to 0xfff so you can see the msgs - check on the logger side with similar trace mask.

3) About the Central Controller: there are the Logger DB, will this DB has some missing as there is not method to recover this for the last moments (before moving live)?

If you do it correctly using SQL backup/restore you will not lose data. If you have to keep the contact center running on side B while you do side A, things will be a bit more complicated - read the Upgrade Guide to see how logger synchronization solves this.

As I said, if you can have a 12 hour maintenance window for the migration of the CC and bring the whole contact center down to migrate, life will be easier.

As I see the most critical part in this upgrade is not loosing the configuration and it is not the need to build every thing manual (as the moving for registry is easy, and the restore for the database is easy) but the system to become up and running is also easy, but the hard part is the avoid loosing the data. Correct? All the need to have the training is to be around how to avoid loosing the data? But no worry that service will be up and running by having the restore for the database and moving the registry.

I don't follow that paragraph. Backup and restore and import of the registry solves this. Nothing will be lost. Read the Upgrade Guide again.

Do you have a lab system you can practice the migration on? Without this, the risk is huge. You must get a step by step plan written down, and trial this on the lab system.

Regards,

Geoff

Again, thanks for the help. Actually I am going to read all ur below paragraph carefully and take care for things, but I have a question to confirm my understanding:

In my case (which is Refresh Technology, as I am going to have a new hardware), do I need the Cisco CDs for the IPCC to install the AW/HDS/WebView, RGRs, and PGs? Or it is enough to copy the ICM/bin directory? What about the patches?

Special thanks.

Regards

Bilal

You need the installation CDs and, of course, the service release. You do not copy anything from the old machines but the registry and (as appropriate) a SQL backup.

How's that lab system going? By the way, what version of UCCE are we talking about?

Regards,

Geoff

As I will need the installation CD, so in the document always mentionning that I have to copy the ICM/bin directory? I was expect that it is going to be used to do installation on the new hardware to build the baseline (which for me will be the latest version).

About the LAB, we are waiting the hardware to reach to start do the LABing.

Thanks for your kindly help and appreciate ur advise.

Regards

Bilal

I think the document says to back up the c:\icm directory - but it's just for a restore. Read it again - you won't use  that on your target servers.

Regards,

Geoff

Thanks a lot for the help and advises you gave us.

Coming to the complex point which until now not able what to do in it, which is related to the testing  with the current environment without effect the live. Actually there is also CVP deployed, so I beleive it is very important to connect the upgraded hardware IPCC to the network and do a testing while keeping the current live IPCC running. This is very important to be done before disconnect the current live IPCC and depend totally on the upgraded one.

The question is: what is the idea to route some calls for this upgraded IPCC while the current live is staying running?

Is it possible to have two IPCCs with the CVP, so for testing, we can press a specific digit when IVR respond (for example pressing 9) and then it should route us to the upgraded IPCC and not the live one, can this be acheived?

The idea, is it possible to have two IPCC systems connected and dealing with the CVP and the Voice Gateway?

Regards

Bilal

You are a bit confused.

I asked you about this before. My strong preference is a 12 hour maintenance window wherein your contact center is off the air and you have some sort of default routing applied by the carrier. If you want to keep the contact center running on the B side, you need to be very careful and read the upgrade guide in depth.

You can do this until the moment you are about to start items on the new side A machines.

At this point, shutdown side B - now your contact center is off the air. B must stay down for quite some time. Bring up the CC on the new side A in simplex and point your key AW at it and bring it up. Point your PGs at the new side A and bring them up. Now the contact center is all running on the new side A.

Execute your test plan. Execute the "go/no go" decision. If favourable, do side B and then bring up a duplex system on new hardware.

Regards,

Geoff

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: