Unity DIRT Restore

[mwadam]

I attempted a DIRT restore from a 4.03 VM system to a 4.03 VM system. Basically replacing the very old server with a new one. I built the new server identical to the old one. When I ran the DIRT restore all accounts except for one had exmerge errors creating the accounts. Don't understand why one worked and the rest didn't. I created an account UnityDirt for the restore process and put it in the administrators group, and the Exchange Domain Servers group. Should I have used the UnityInstall or UnityAdmin account instead? The new Unity server was functioning perfectly. Could create new accounts, worked with CCM etc. Where did I go wrong? Attempting again as I write this, unfortunately it takes a while to rebuild the box again. Sure would like to get it correct this time. I read all documents and my interpretation was that I was doing it right. Apparently not. Also, the old server had a botched failover config on it. It never worked. When the restore finished there was a message about this restore having failover, so more configuration changes needed to be made. We do not want to use failover now, so by doing nothing else am I ok?

Thanks!!

Adam

[lindborg]

First, ExMerge doesn't create the mailboxes, diRT does so I assume you mean the accounts got created in AD but ExMerge threw errors when trying to restore the messages? If not, can you be more specific?

Also, what version of DiRt are you using? Be sure to get the latest from its home page here:

http://www.ciscounitytools.com/App_DisasterRecoveryTools.htm

the help file for the latest DiRt contains some updated information about rights needed to run ExMerge to get messages restored properly - be sure to check that section for details. Also, if the accounts have been created in AD and the rest of the DiRT restore completes, there's no need to start over for just messages - you can run ExMerge (this is an MS tool) seperately on your own to restore messages. All the PST files for the mailboxes are in the directory where you're doing your restore from.

[mwadam]

Jeff,

My misunderstanding. The accounts were created in Unity/AD, but the mailboxes were not created, hence the exmerge errors while trying to restore the messages. I downloaded the latest version of both the backup and restore utilites yesterday prior to starting. I even read the help guide and thought I was right. I will read thru it again before my next attempt tomorrow. The restore hung for well over an hour on the Directory Synchronization stage, and there are only 150 users on the system. I wound up having to stop one of the processes in order for the restore to continue. It did and said it was successfull with 2 errors (eadmin and esubscriber) which I think is expected. However, when I looked at the exmerge log that is where I see all of the message transfers failing. The one that succeeded is what confuses me. It was the first mailbox and did not have any messages. Maybe that is why.

Adam

[lindborg]

Ah, ok - well this sounds like a RUS issue, not anything to do with DiRt. All DiRT does is add the users to SQL and then call the directory synch to create the AD accounts with mailboxes. AD creates the users and then the RUS (Recipient Update Service) should come along later and create the mailboxes (we have no control over this). So if the mailboxes are never being created, the problem is upstream from Unity/DiRT here.

If you create a new user in ADUC in the same container these users were added, does that AD account get a mailbox assigned to it in a few minutes?

[mwadam]

Jeff,

I have nuked the box and have a clean Unity 4.03 install integrated with CCM. Press the VM button Unity answers. Create an account for a new phone the mailbox is immediately created. I can setup the VM account from the phone. So,this tells me I am where I need to be to begin the restore. I am going to create a UnityDirt userid for the restore and give it permissions based on the help document. I did this before, but maybe I missed something? Guess we will see. I will let you know.

Thanks!!!

Adam

[mwadam]

Jeff,

Well, setting here watching the restore again. Everything clicked off really fast until it got to the Directory Synchronization step again. The display says "Progress 1 of 288" and has not moved. If I look at the processes with Task Manager both the VbCpTest and Restore applications are Not Responding. This is where I wound up yesterday. After an hour I terminated the VbCpTest and the restore completed, but only 1 mailbox was created. I will let it run I guess until I hear back from you and see what happens.

Adam

[lindborg]

Well, the directory syncher (process running under the AvCsMgr service) is clearly having trouble here - most likely it's a rights thing with the directory facing account (has nothing to do with the account you're running DiRT under). You can look at the SQLSyncSvrxxx logs under \commserver\logs that are created by the syncher process and see if any errors are coming up in there (I'll bet there are) to get a clue as to what's going on.

DiRT doesn't directly access AD or the mailstore or the like - it does so through proxies (in this case the SQLSyncSvr process).

[mwadam]

Jeff,

I agree that it looks like a permissions issue. However, I have verified several times that I have everything the help file stipulates. Here is what makes it weird though. The dir synch does create some accounts but then stops. If I run a dirtrestore, each time it creates two more accounts that the last time, but then stops responding again. I have been all over the place with permissions and nothing changes the results. Anytime it stops responding the SQLSynch log always has:

GC could not find by AVP_EMAIL_ADDRESS

GC could not find by Alias/MailNickname (username)

GC could not find by UID = samAccountName (username)

Exiting GCFindDirObject

Entering CreateDirObject

Exiting CreateDirObject

Entering AssociateDirObject

This is where is dies. If I run a dirtyrestore again it will be successfull on this record and then give the exact errors after creating two more.

Attached is the last SqlSynch log file.

Adam

[mwadam]

Jeff,

This server apparently has a botched Failover config on it. There was not a second server in the network and Exchange is on box. Could this be causing an issue when creating the mailboxes? See my previous message with log attached.

Adam

[mwadam]

Jeff,

What do you think of this log?

Adam

[lindborg]

At this point, I'm not sure - but I do know it's not a DiRT issue - you can force the synch to kick off without running diRT restore again, by the way - you can just run the configuration setup exe with the /sync command line and it'll do the same thing (it'll run through the subscriber table and look for unsynched users and send requests for them to be created).

I'm not sure what the failover server would have to do with this and I don't really know why the syncher would just quit like that - something up stream is going badly hay-wire but I don't know what it would be.

[mwadam]

Jeff,

Opened a ticket with TAC and FTP'd the backup to them. They were able to do a full restore on a vmware box running 4.03. So, the only thing I could think of that was different was their vmware server is running full SQL, and my new VM server is running MSDE because of the number of VM ports. So, I am rebuiling it again....5th time. This time I will lie and get SQL to install. Maybe this is the issue? Will soon see.......

Adam

[mwadam]

Jeff,

Well, got SQL on the box but still have the same problem. I get the same results running the /sync command. The program just goes not responding. Any ideas?

Adam

[mwadam]

Jeff,

TAC found two bugs causing the problem. csced53002 and cscee01448. To fix these I had to install 4.03SR1 and ES72. Apparently the subscriber creation could run too fast and cause the process to hang. The theory is that TAC running it on vmware slowed things down enough that the problem did not show up. Oh well, took a week, but the system is up now.

Adam

[lindborg]

Interesting - I hadn't even thought about a scenario like that and I didn't come across those bugs on a search.

Sorry you had to bleed on it, but thanks for posting back with the solution.