DiRT restore to existing AD

[mmcgille]

I attempted to do a DiRT backup from an Unity Server in one domain, then a restore of Unity onto a new server into a new domain.

The trouble is, the new domain already had “contacts” in one of the OUs (unbeknown to me) - there was a contact for every single user. So when I did the DiRT restore, DiRT failed to create new users in the directory, it just bound the unity subscribers to the existing AD contacts (which of course have no actual mailboxes in exchange). So the restore failed.

My question is – how can I restore from DiRT and have it create new users automatically, rather than try to attach to the contacts? The notes on the utility seem to indicate this isn’t possible, so I’m looking for suggestions. I know that I could delete all the contacts in AD, but the AD folks are not going for that.

Second question - there were a few users who actually did import correctly, but when I looked at their subscriber properties, it showed that their mailstore was the old Exchange server, not the new one. What causes that/how can that be changed?

Thanks,

Matt

[lindborg · Accepted solution]

First, I'm not sure what version of DiRT you're using here or which version of Unity you're testing with - this is alway handy info.

second, no - you can't force DiRT to somehow dynamically create a new Alias (mail nickname) for you on the fly such that you can get new users in the directory instead of binding to existing objects (or attempting to) in the directory. At least not at the moment. Doing that would require that I run out and check to see if an object already conflicts with a directory ID/RND/Nickname and if the user indicated to me that they didn't want to bind to existing users dynamically change one or all such properties such that new users were created in AD. This is more than a tad complex.

It gets worse if a site wants to do this for some objects and not others (i.e. that would necessitate some sort of editable table - this has been asked for). And of course sites also want to tell me to ONLY bind to existing objects and not create new users if they don't exist (I get this one from time to time). Anything's possible but it's a lot of work and adds complexity to an already mind-numblingly complex tool (this is by far and away the most updated tool on my site as it has to be touched and tested with each and every rev of Unity).

So currently you have to live with the fact that it'll search for objects according to the help file and if a match is made, a synch is attempted. If no match is made a new object is created. There's no work around for this.

As for your second question, I'm not sure where you're looking - if you're looking in SQL under the subscriber properties then it was probably not updated by the syncher yet (or at all) - DiRT doesn't touch any of that stuff, it relies on the SQLSyncSvr to pull that mailstore information in from the directory for the user and populate SQL with it - if the user didn't get synched properly (you can find this in the SQLSyncSvr logs in commserver\logs\) then the old mailstore data that we had in the backed up UnityDB database will just sit there as it was. This is a read only property for us (i.e. we'd never attempt to push that information out to the directory, only the other way around).

[mmcgille]

Thanks Jeff, that's what I needed to know!