Reader Comments

I was recently involved in the migration of a mid-sized network (~2000) from NT4 to Server 2003. The biggest headache for me was that they employed HP's NT(SE) encrypted authenication software throughout the network so it sat on all the servers, Terminal Servers & clients. Normaly something like this wouldn't bother me but like most enterprises there were multiple builds and configurations, and the deployment plan was a phased one which meant I had to ensure that everything was leveled out before I begin the upgrade. This meant that, without any sort of management tools in place, I had to deploy SP6a to everything, patch NT(SE) because the service pack defaults back to the Microsoft GINA and apply a 'compatibility' kit to allow AD translation between the clients & the PDC. There were a few other tweaks as well but that was the bulk of it.. and I managed to do it all remotely without any patch systems or management servers as well! The one big problem I had was with WTS, Terminal Server. After applying all the relivant updates etc none of the TS clients could authenicate to the domain so after a few hours of poking about I had discovered that the updates hadn't written a registry key to allow the clients to use the encrypted GINA values. Lessons learnt; make sure to bring all clients and servers level with one another, this will hours if not days of screaming and swearing when you're trying to track down an application fault. Also, look to see what is being modified if any application patches or updates are needed. You have the luxuary that NT4 applications are generally not as complex as their AD-aware counterparts so looking to see what it's doing, comparing it with whats supposed to happen helps address the problems quickly when the updates don't work ie. missing registry keys!

It sounds like this wasn't W2K3's fault, but either the service pack or the NT(SE) updates. So after "bring all clients...level with one another", I'd add "and make sure they're all working again". In a similar vein, doing a pre-upgrade reboot is a good idea. It will clear any transient issues, and if you do have regular startup errors (we all know they're pretty common), you'll have it documented in the system log. If you then see errors in the log after the upgrade, you'll know it's a pre-existing condition, not the upgrade.

Yeah it was but it addresses the point that AD preparation tools for various applications are never something to rely on so if (and when) things were to go wrong you need to ensure that as part of the migration planning you take time out to resolve anything that's going to hamper troubleshooting down the line ie. bring everything level, ensure applications are working, understand how applications interact with domain services, what changes are being made/going to be made when you introduce AD into the fold, eliminate as many outstanding/known issues pre-upgrade. The whole migration process it's self is, I think most will agree, relatively simple; it's when there hasn't been enough thought or care put into the planning of the process that invites the problems.