Overall objective: to "copy" a server running an older version of Unity using DiRT and a second server with a fresh clean install of the latest version of Unity.<br><br>Requirements (this is starting to look like a MCSE question!):<br>1. Keep server downtime to a minimum<br>2. Maintain the same server name (so Subscribers don't have to change their ViewMail settings)<br>3. Maintain the same server IP address (so we don't have to change DNS settings)<br>4. Do not lose any subscriber settings<br>5. As little pain as possible...<br><br>We have a Unity server running an older version of Unity with several hundred subscribers. We upgrade the server to the latest version of Unity, and perform a DiRT backup of the system. For certain reasons (not ours I tell you!), we need to build another machine from scratch with the latest version of Unity (no upgrade process) and throw the DiRT on here to have a (theoretically) perfect Unity system.<br><br>How should be proceed from here? Do we have to shutdown the currently running server and delete the server object from Active Directory before building a new server with the same name and IP address? Can we build another server with another name and IP until it is ready for Unity, shutdown the current server, delete the AD object, then rename the new server to the old server name and IP? Or...?<br><br>We have tried the second method (only once) and AvCsMgr wouldn't start.<br><br>Please let me know if you have suggestions on the best way to proceed and/or opinions.<br><br>Thanks!<br>Loong<br><br>
Yeah, changing your server name address post install is going to give you headaches with Exchange (if it's on box) and SQL... theoretically it's doable but I've had problems testing this type of thing in the past. Also, if you're using Exchange 5.5 it uses the NetBIOS name for the MTA attachments to other servers so you can't even use a DNS sitch-er-roo and get away with it.
Before you do the restore you need to have uninstalled the other Unity server and cleaned the subscribers off (use the latest version of Uninstall from AnswerMonkey.net... version 3.0.50). Definitely fit that into your plans.
I think the only way you'll get no client impact here safely is to uninstall the old Unity server after doing a DiRT backup and then install a clean server (presumably on new hardware) with the same server name and IP, install Unity and then do the DiRT restore. More downtime but a safer approach you know will work.
Technically with Ex2K you should be able to install on a different server name and then add a DNS entry for your old box name to point at that guy. The SA/AA/SM and TRAP connections all go through DNS to resolve the name so this should work but be aware your in untested territory so you shoulder some amount of risk there.
Thanks for the answers. We do have Exchange 2000, and Unity is an off-box installation. I agree with your ideas on the safest way to perform this move, we'll probably have to take the system down for an entire day to kill the old server and rebuild a new one (on new hardware).
By cleaning subscribers, you also mean cleaning their AD/Exchange attributes = they are not Unity subscribers anymore. With your methodology, it looks like DiRT will change these properties back during a restore?
Since we will be killing the old server, it looks like there is little room for a backup strategy during the move. i.e. having the older machine in a ready state in case the move is unsuccessful or having a third machine ready to throw on an DiRT of the older Unity. Any ideas on a backup strategy while maintaining the discussed procedure?
Technically you don't need to clean the subscriber properties off, although I generally reccomend it just to be complete. The DiRT restore will lookup users in AD first by directory id, then by UID then by alias (mail nickname). If a match is found it'll plow right over the data that's there regardless of if there's something in the custom properties (the AD extensions to be exact) or not. As such you COULD just pull the old Unity server off the network when you're ready and keep it on a shelf so if something goes really bad you can stick it back on and run the SQLSyncher to synch up SQL data with the directory (you can use the part 2 setup with the "/sync" command line option for this).
the SQLSynchSvr is built into Unity and it's run by part 2 of setup automatically (it's the guy that pushes the default objects into the directory- example admin, all subscribers DL etc...). You can envoke it by running the part two setup on the desktop with the command line option "/sync". It'll just run the syncher then instead of running through the entire part 2 setup.
OK, some progress on this issue. In summary, we have performed the following procedure: 1. Upgrade our Unity 220.127.116.11 to 18.104.22.168. 2. Upgrade from 22.214.171.124 to 126.96.36.199. 3. Take a DiRT backup. 4. Turn off the power to the server (nothing else). 5. Build another machine from scratch straight to 188.8.131.52 (no upgrade). 6. Perform a DiRT restore with data from step 3.
So far, everything we've tested looks fine, no errors. My question: is there no problem with NOT performing a Unity Uninstall? E.g. we have 4 entries in our AD/Unity/Locations object (2 per installation?), 2 sets of users and dist. lists created in AD. Can we live forever with this method of migration?
The only duplicate objects in the directory will be those created by the setup (i.e. the new install of Unity). Your regular subscriber database backedup and restored by DiRT should bind to existing users in the directory fine with or without an uninstall. From your description that sounds like it's the case, just wanting to be sure.
Yes, you can live with this, it wont hurt anything just a little extra clutter in AD for the old Unity server object left lying around. I normally reccomend the uninstall just to be clean but it's not absolutely necessary.
Be aware if you just fire up your old Unity server later (i.e. after the import) it wont "see" any of those subscribers in your directory since they're tagged with to the new Unity server by the SQLSyncher kicked off by the DiRT restore. Just so you don't expect there's a "hot failover" possibility here...
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...