We would like to rebuild our Unity 4.X Servers into a remote place/LAB (with identically hardware MCS servers) were we can mimic the production network , and load manually over 2000 Subscribers and then take the HDD's and swap it over the weekend and then do the rest of the work into production network. So my question to you is if is possible to do this way and what impact/risks we might encounter?
The only supported way to move Unity data between servers is DiRT backup and restore onto a newly installed Unity running the same version. Very early on when I was first learning Unity, I had a test Unity running in our lab. I unplugged the server and moved it to our production network. Unity would not function. I actually had to place the server back in the test lab and run the Unity uninstall there. Then I rebuilt the server from the ground up in production and installed Unity on it. You will not be able to move the hard drives from one Unity server between your lab and production.
Hmm...it is strange because in the past( about two yesrs ago) we did it as well we did use it for CCM 4.x rebuild/migrations . I remember that we found identicaly MCS 7845 H1-ECS2 servers with identicaly SCSI controller and use Cisco facility to do it.
That is different. CCM 4.x is a Microsoft "Workgroup" and not in a domain, nor does it rely on Exchange. The problem with Unity is that it is in a Microsoft domain. So you can not simply rename machines, move them around, IP addresses, DNS,SQL Database names, etc. All these pieces can easily break a Windows Server.
Sure, you could build a new Windows box, new name IP address, attach it to your existing domain, install Unity 4.x to match the existing version, Exchange, etc. DIRT Export old server, bring down the old Unity server, DIRT IMPORT to new server.
There really is no LAB piece of this because of the Domain piece. Maybe, if you had VM-only setup, with one server (Exchange, Unity, Domain controller, SQL all on one box) You might be able to do this.
Honestly though, if your Unity DB is clean, you create backups, pull drives, you should be able to upgrade fairly easy with a good fallback plan.
are there certain concerns about the upgrade is why you are going to the lab or?
-the reason I am trying to build this way is that because the existent Unity Cluster(Pri, Sec, Echange ) VM only has DB compromize (not clean) and we cannot use anything from it (no DIRT Export/Import).
-We have to setup manualy 2400 Subscribers and our network down time is only in weekends.
-we would like to be able to prepare it remotely (onto mimic production LAB)
Ahh.. I gotcha. Well, here is what I would do then.
Build the NEW unity servers and digitally network the old and new servers together.
Using the Global Subscriber Tool, migrate users from one server to another. (assuming you are using the same Exchange server)
You will then have to rebuild all your CallHandlers, System parameters, etc.
Basically, you are not using DIRT at all. The users Presonal Greetings, recorded name and settings migrated from one Unity server to the next. I would limit the migrations to batches of 100 or so. Wait about 30 minutes for everything to sync up in the Unity DBs.
Assuming your Unity servers are still running now, just are not in good shape, this method may work for you.
Another one, it's in beta is CORBRAs found on the ciscounitytools.com. Its not supported by TAC yet, but will export and import a ton of stuff.
I like having (2) sets of Unity servers up that Im migrating. That way, I can click back and forth to get all the settings i need on the new server.
Anything you do before running any of the tools, pull a drive so you have a copy. That way it's easy to rollback.
I also recommend purchasing a copy of Variphy. Variphy will document your whole Unity setup, subscribers, everything in a report. You can use this help rebuild items you may have not documented. It's really slick tool and can do a report in about 10 minutes or less.
Just to clarify, are you using new servers or re-using the old servers?
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...