The customer wants to upgrade to a new server platform. The current platform is Unity 3.0 and they want to migrate to Unity 4.0. I have done this several times from 2.46 to 3.x. I just want to be clear on the best tools to use.
Should I use the DIRT Utility to export all related information from the 3.0 server, Uninstall the Unity 3.0 application and then use DIRT to restore onto the new server. If so does NETbios name have anything to do with this?
Or should I be using the traditional import/export utilities.
DiRT doesn't work on systems older then 3.1(2) (issues with the SQLSyncSvr in older versions cause all kinds of goofy problems).
So what you'd want to do here is to upgrade from 3.0 to 4.0 then use DiRT to backup the system and restore it onto a 4.0 system in your new directory/server.
The import/export tools only work for migrating 2.x data to 3.x/4.x machines - it's a "brick level" backup and restore process which doesn't get nearly as much information as DiRT and works much slower. It had to be done this way in 2.x since we didn't have a snappy SQL database with all our info in it that I can grab whole-hog and cart around.
Be sure to get the latest DiRT utility off www.CiscoUnityTools.com and check out the training video and help file out there. It should answer most of your questions about how this works.
Just so I am clear:
If I upgrade the exisitng server to 4.0 and run DIRT to export. Before I would run the DIRT utility on the new server, I would need to un-install unity on the first server first. Correct?
One more thing...
If I already licensed the Unity 4.0 license based on MAC address of the new server, how can I upgrade the existing one so I can perform the DIRT functions. My guess is that It won't accept the license created for the new server and If I am correct, the demo mode only supports up to 10 users?????
Ok one last question.
TAC has informed me that if I upgrade the old 3.0 server to 4.0, the server will be in demo mode with a 2 port license and the database will be read only so that I will be able to export information using DIRT.
I just want to ask one final question. In regards to upgrading the 3.0 server to 4.0 using DIRT to export and uninstalling Unity on the old server before I run DIRT to import information on the new server. Do I really need to uninstall Unity 4.0 on the old server before importing on the new server? Is the DIRT utility smart enough to resynch exchange mailboxes and unity attributes without having to uninstall the old Unity 4.0 software.
Thanks for the help....
Well, you asked that on an earlier post in this thread so I take it you didn't like the answer...
I'm sticking to my guns - you want to uninstall the old Unity 4.0(x) since if you don't it'll leave objects such as locations, DLs and system subscribers (example admin/subscriber) hanging out in your directory and removing them later is tricky business to get right - the documented procedure here is to uninstall the old one and then install the new one. But yes... it will be smart enough to over write subscriber's information in the directory when you do the import on the new one (i.e. if the old system crashed and you couldn't uninstall it this is necessary). However given a situation where you can, we really strongly advise you uninstall it cleanly (i.e. follow the directions at the end of the uninstall and remove the objects listed from AD/E55 entirely).
And you thought this was going to be my last question.....
There are import/export for 2.x and DIRT for 3.1 and above. How come their isn't anything for 3.0(4). I as going to take one more level of caution and run DIRT at 3.0(4), upgrade to 4.0 and Run DIRT again. This was incase the upgrade didn't go to swell, I could revert back to 3.04.
You can't run DiRT on 3.0(4) - it only works with 3.1(2) and later because of fixes/updates to the SQLSyncSvr that it needs to work properly.
There is no fullDBImport/Export for later versions of Unity because it's a nightmare of a "brick level" backup and restore - I spent the better part of 6 months banging heads with those during the 3.0 development cycles and they've been my special crabby little children ever since - they only just recently settled down in early 3.1 releases. I'm not going through that again... the ability to grag the entire DB whole hog is light years faster and more stable (and resilient to all those little db changes that come out each release). The over all support load on DiRT is a small fraction of what the dbImport/Export tools were but I had to do those since the 2.x DBs were in Exchange, not in a local SQL table so I had no choice.