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).
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?
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.
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.
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?
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.
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.
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.)