what should I extra configure DiRT restore ?

[cjrchoi11]

what extra configuration task required when DiRT restore into re-built Unity box?

I successfully restored DiRT backup into re-built Unity box and found no information for digital networking. I think CCM integration and digital networking is only thing manually after DiRT restore. Anything else ?

Thanks in advance.

[lindborg]

yes, you have to configure your switch when you install the new box - this is not pulled over from the backup (you may, after all, be using a different switch configuration on the newly restored box).

As for digital networking - most of that information (i.e. about other Unity boxes) is pulled from the directory itself - DiRT does not bring this over, obviously, so if you don't have other Unity servers in the network, none are going to show up in your list of other servers. If there are, it will take a while for the replication to complete onto the new Unity server before they'll show up.

From the DiRT help file there are a few other things not carted over with the restore:

Raw diagnostic and report logs. Optionally report data in SQL is saved.

If you’ve changed your logging location for diagnostics and/or data files, this will be forced back to the default location under the install directory. You will need to make this change again if you wish this directory to be moved again.

Any mappings made with the GrantUnityAccess tool. Any non subscriber accounts you had configured to have SA access to the Unity server will need to be remapped using GrantUnityAccess after the restore is complete.

If you’ve moved the UnityMTA directory share, this will be put back to the default folder under the installation directory. You will need to make this change again if desired.

If you’ve setup the use of a custom codec (i.e. G729a) this information is not saved, you will need to configure that again using the SetRecordFormat tool.

[Ginger Dillon]

Hi -

I had the same problem with digital networking when I rebuilt a Unity server on new hardware last year. However, it is easy to fix on your own if you are comfortable/familiar with the Unity database tables. The symptom I observed was that my Unity servers were not listed in the same Dialing Domain using tool Global Subscriber Manager. That was because the other Unity databases had the old locationobjectid information from the removed server. Here's how I fixed:

1. I obtained the locationobjectid of the new server from its own Unity Db table Global Location. I copied this into a txt file.

2. On the other Unity servers, I copy/pasted the locationobjectid field into the following database tables - Global Location and Global Subscriber.

3. On the Unity SA I had to reenter the remote access number of the rebuilt server.

4. Revalidated by going into Global Subscriber Manager and looking at the dialing domain. You should see the + sign and when you expand it, all of your networked servers are listed underneath.

Another problem I had, which was very minor - I unplugged the old server from the network after the DiRT backup. When I DiRT restored Unity to the new server, the public distribution lists were recreated, so I ended up with two of each. I mistakenly deleted the wrong set (the Exchange alias is the same with a number added to the end). To clean this up, I deleted the other set and used the Unity utility Public Distribution List builder to build a brand new one (much easier and cleaner). You didn't mention licensing so I'll assume you already have new license files for the updated MAC. On our server, we have NIC teaming configured in adaptive/fault tolerant mode. I did have to configure the team NIC address to match the MAC in my new license files.

Sincerely,

Ginger

[lindborg]

hmmm - none of this should be necessary. It'll take some time to replicate around but the local directory monitor should pick up the other Unity servers and vice versa.

The dialing domain is merely a string match on the location objects pulled in from the directory - so unless your system was having problems pulling that information in, this should have corrected itself on its own given time.

[Ginger Dillon]

Hi Jeff -

Thanks for your note! The three Unity servers were at 4.0(4) with a few engineering specials applied at the time. Each Unity server was in its own domain; Exchange admin group; and AD replication site - so I knew timing would be an issue. This was performed on a Saturday. I logged a TAC request after waiting for some time, and then ended up fixing on my own using the procedures in my earlier post. Since I fixed it, I closed the TAC case. Perhaps working with TAC would have disclosed the replication issue or delay.

Thanks always for your expertise! Ginger