Moving Unity to new hardware

[angel-moon]

Hello,

I need to get Unity 4.0(2) moved to another server runing Unity. Is there a way to build out a new 4.0(2) Unity installation and migrate everything to the new server without actually moving the entire database? A failed upgrade attempt seems to indicate there is a problem with the existing database. I would like to just be able to throw the old info (subscribers, Callhandlers, etc) into a new install if that is possible

Thanks in advance!

All replies will be rated

[Brandon Buffin]

Did you run dbwalker? It can be used to check the consistency of and fix errors in the Unity database. You can download the latest version here:

http://ciscounitytools.com/App_DirectoryWalker4.htm

Brandon

[Ginger Dillon]

Hi -

If you can validate your database, as advised by Brandon, then you should be able to run a DiRT backup on the current system, which includes all Unity related subscribers, call handlers, etc. Then run a DiRT restore onto the new Unity server. You will need to have a clean Unity install, same version, running on the new server, and you can use a demonstration license for this purpose - unity40.lic. You will, however, need to acquire updated license file(s) from Cisco Licensing that match the MAC address of the new server's NIC. If you have, for example, five license files on your current server, you will need five updated license files on your new one. I have done this before. You can even send your license files as attachments to Cisco Licensing, which helps validate what you have currently on the server.

Ginger

[angel-moon]

Thanks,

I have run dbwalker and did have some errors and was hoping that by just moving the info and not the entire database I could get around the database issue. There are some design issues for the database that I don't think are addressable by dbwalker. 2 of the more prevelant error messages are

1203:(error) The primary call handler for this subscriber has it's AdministratorObjectID value set to point to a different subscriber.

You can fix this in DOHPropTest by copying the ObjectID of the subscriber into the AVP_ADMINISTRATOR_OBJECT_ID value for the primary call handler.

This can also, however, mean a there is a 'cross linked' call handler problem where a single primary call handler is being 'shared' by more than one subscriber.

and the other error is

1233:(error) the extension number for this object conflicts with one or more objects in the directory

All objects found to be using extension #100:

Call Handler with a display name=CorporateAfterMsgGrtg

Call Handler with a display name=Corporate Autoattendent

Call Handler with a display name=CorporateBusinessHours

Call Handler with a display name=CorporateOperator

I am not sure I can fix these issues without breaking something.

Any thoughts? Thanks for the replies thus far!

[thisisshanky]

Most times you see a lot of errors if a subscriber was deleted and he was the owner of a Callhandler which is still existing in the system. You can set an owner for thse Chandlers manually. That should fix those problems.

If you dont have a lot of callhandlers, and you just want to import users from one server to another, you may use SubscriberInfoDump to get the first,last, alias and DNIS information and then use Bulk subscriber import to import the user information to the new server. You may be able to recreate the callhandlers really easy.