cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
529
Views
0
Helpful
7
Replies

DiRT Restore Taking A LONG time

davidpatton
Level 4
Level 4

I am currently running a DiRT restore on a new MCS-7845-H1 using v 3.1(5) of Unity. I am only restoring the DB as the Exchange is off box (UM Config). The restore process has been running for over 1.5 hours which seems a bit long for 150 users. Is that normal? I have done restores in labs that have taken a lot less time... like a half hour if that.

7 Replies 7

lindborg
Cisco Employee
Cisco Employee

I'm guessing it's taking that long doing the directory sycn - is that where it's at during the restore? Issues with the DC/GC connectivity and other factors can take a long time at that point in the restore for both creating and binding to existing users in the directory.

If it's not there in the restore then something sounds like it's gone wrong along the way.

Question:

I am doing a restore of over 4000 users..Exchange is off box so no messages...this is the first time doing so many subscribers...is it normal to take a long time at the directory synch portion..that is where I am at and it says like 203 of 17000...

IS this to be expected..im not getting any errors yet.

Yes, this is expected - the time it takes will vary wildly depending on network configuration issues - DiRT is actually finished at this point - it's just waiting for the directory sync to complete to get all the users represented in the directory - not much that can be done to speed it up so it just sits there and shows you progress...

ok very good...its pushing along...it is creating the ad accounts..im almost at 1000 now...

thanks...

I am currently doing a DIRT restore on a Domino environment and it has passed the area where it showd the pop up window and counting the users. The pop up window has closed and it is just sitting there. The next step says it is to make sure the current account has SA access, but it doesn't pass this point. I have tried the restore twice rebuilding the server before the second try and it still hangs up at the same point. Anyone know what might be going on?

Thanks,

Robert

So was the system not working after this? Or did you just blow it up and do it over because you were worried something might be wrong? The account mapping is a pretty minor step and is about the very end of the process on a Domino restore (there is no directory synch for domino - it can't create new users in the directory as you can with Exchange).

The mapping thing is just using the command line tool to map the current Windows account to get access to the SA - this isn't critical, just a nice thing to do. Not real sure why that would hang right off hand but either way, it's not going to break anything.

No, after it hung at this step on both attempts we eventually rebooted the server and Unity would not start up. I opened a TAC case last night to see if they could help, but so far they have not been able to find out what the problem is. They said that the log files look like everything completed successfully, but Unity still will not start. I did find that there is an error that shows up when you open the license manager application but I don't have access to the system right now and can't remember what it was, but it is something like it cannot connect to the license manager service or something. One thing the TAC engineer found is that in the SQL tables the global location id was different from the location id and they changed one to match the other.

I have to work remotely on this server and I have a technician onsite that is the hands on for it because it's several states away, but I want to ask you about DIRT. Since this is a Domino integration, is there a specific version of DIRT that we need to use for this? I really appreciate any info you can provide, you have helped me before and I really appreciate it!!

I did find that there is a avdsdomino log file that keeps incrementing with what appears to be the same section of log information while it is hanging up. I would attach a copy of it, but the TAC engineer ran the message store wizard as well as a configmgr application and it replaced the log files.

Thanks!

Robert