LegacyDN to the rescue

Continuing with the swing migration from the last post, all continued to go exceptionally well with the process. We kicked off an Exchange backup remotly prior to heading to site so there was less waiting around. (I use RDP to manage servers just about everyday and I am still extremely impressed with how it has made my job so much easier).

The data transfer went a treat, in fact it was all going very well until it came time to mount the Exchange databases. The databases and log files were all in the right location but when mounting the databases we got error “ID No: c1041724” which I’d seen before.

Due to not seeing this error everyday I had to rummage through my notes and do some searching online, plus referred to Jeff’s swing migration notes. The usual checks against file system permissions, database integrity etc didn’t yield any change.

It was getting late and the client wanted to go home so I said I would keep working on this remotely for them to get it going (there’s that wonderful RDP again).

One of the things about this site is the DNS domain name is VERY long such that the NETBIOS name has been truncated. Add to this the fact the original IT support person/people hadn’t done things the SBS way and we have a rather interesting environment to move from. I figured there were some naming issues at play here and looked into using LegacyDN to resolve things.

Fortunately I’d brought their old server home with me just in case (Dell 400SC with 512Mb RAM and 2 IDE hard drives!) and so fired it up to use LegacyDN to check the Exchange organisation name details. Cross checking this against the new server showed there was a mismatch.

You should refer to http://support.microsoft.com/?id=324606 for details on how to use LegacyDN and the tool itself can be downloaded from http://www.microsoft.com/downloads/details.aspx?familyid=5ef7786b-a699-4aad-b104-bf9de3f473e5&displaylang=en.

Once it’s downloaded you need to run it from a command prompt as “legacydn /forcewrite” which runs it in edit mode. Be aware that this is a powerful tool and using it incorrectly can render your Exchange environment completely unusable – you’ve been warned.

I updated the organisation name and saved the settings….now for the big test.

I went to mount the private information store database and got another error message. Dang, what was it now? Ahhh yes – I’d not checked the box to say “this database can be overwritten by a restore”. Checked the box and tried mounting again – this time it was successful. Same for the public information store.

We’ve had migrations where the database just mounted seamlessly but there are the odd times where we have to resort to additional steps. Next week we swing from SBS2000 to SBS2003 so I’m sure there will be some other issues to work with but in the case it was simply the organisation name that required massaging.

So there are several lessons here.

Firstly – the server should have been setup using the wizards in the first place. Get with the program folks – don’t go playing with building servers if you don’t know what you’re doing!

Secondly – in future I’m going to run LegacyDN as a matter of course to at least document the organisation name settings. If nothing else this saves me from having to take away the old server for reference.

Thirdly – make sure you set the right perception for the client when performing work. I always make sure I let the client know there can be issues and problems that have to be worked out with anything involving server changes. Don’t over promise or set false expectations.

Fourth – make sure you adjust the mailbox quotas to what they were before (or as agreed with the client) before you start the SMTP service. I missed doing this and they had some mail bounce before I worked out what was happening [:O]

Fifth – always, always, always make sure when making a server changeover that you have a way of connecting to the Internet for searching, IMing for help, downloading additional tools etc. SBS can be the gateway for the whole network and if it’s not fully operational such that Internet access if not available then you can get very stuck. I fortunately had my 3G card with me so my notebook had a connection, plus I tend to carry a heap of resources with me but it’s worth noting this anyway.

Perhaps it’s time I starting writing a Tips & Tricks book?

Is your SWING not being TRUSTED?

We all know that SBS cannot have a trust relationship with another domain – that’s a given. But SBS sometimes doesn’t seem to know this.

We encountered this just now in performing a swing migration for a client.

The FSMO roles had been seized over and all was looking fine, afterall we’ve done plenty of swing migrations.

Anyway upon kicking off the SBS setup process we got an error message telling us we had a trust relationship that this was a show stopper.

We double checked the FSMO role assignments, ensured there were no phantom domain controllers or other funny things lurking around. A restart didn’t yield any improvement either so it was off to search the ‘net for an answer (since Jeff seemed to be sleeping too).

I found a newsgroup thread where someone else had received a similar message and had resorted to calling Microsoft PSS. I figured it was worth a try giving his posted solution a go.

So if you encounter this error here’s what you do:

Click Start/Run and enter %temp% then hit OK. This opens up the temporary files folder for the account. In there you’ll most likely find a folder called something like “SIT17477.tmp”. In there is a file called SETUP.SDB.

Edit this file in notepad and look for the line that under the [GUID to Friendly Name Mapping] section that ends with “TrustCheck”.

Delete this line and save the file.

If you have any other SITXXXXX temp folders remove them to be safe then re-run the SBS setup process.

When we did this the process ran fine.

I’m not sure what caused this to be borked up – I guess if someone knows they’ll post a comment back but for now we’ll keep swinging with this server and get another happy customer.

BTW – please don’t try this “hack” to get around the ‘no domain trust’ block in SBS. This is only for the setup process and there’s no telling what mess you’ll be in if you try to do things outside the way SBS is supposed to operate.