Upgrading a school or college network to Windows 2000/XP pt. 3

Case Study - Luton Sixth Form College's current NT 4 based network

Remember what we've discussed already: The two most important things to keep in mind when considering possible active directory designs are the 5 "P"s (Proper Planning Prevents Poor Performance) and that designing active directory domains isn't like adding two numbers together in a maths problem; there may be several correct answers and its up to you to pick the best one.

Currently, LSFC has 5 domains on its NT based network, all of which are to be migrated to Windows 2000 as part of the upgrade process. Those domains are:

• LUTONSFC - "teaching" network domain. (Holds student and teacher accounts and resources that are used in lecture rooms).
• LSFCADMIN - "admin" network domain. Holds administrative user accounts used in offices.
• LSFCSERVICES - Holds servers that provide a "service" of some kind to users of both the admin and learning networks.
• LSFCWEB - Holds external web and DNS servers (separate from services etc for security).
• RMNETMM - RM Advanced Multimedia server. Should really have been part of services domain from day one but what's done is done.

Design considerations

• Due to the size of the overall network, and the fact that learning network downtime during term time is unacceptable and admin network downtime at any time should be kept to a minimum, a two stage migration with learning and services in stage one, and admin in stage two, is planned.
• Services need to be shared between / available for all users.
• Servers that are facing the internet and/or holding confidential or personal information need to have a strict account and password security policy in place.
• Strict password policies have been tried out with staff and students for general day to day use and the results have not been very good; therefore despite needing strict password policies for services, users should not be forced to endure the same strict policy.
• Currently, each member of staff has two accounts - one on the LSFCADMIN domain for administration network use and one on LUTONSFC for use in classrooms. This causes some confusion for the staff, and a considerable administration overhead for the IT Support department who are struggling to cope. Because of this, reducing the amount of accounts each user needs for the whole network to just one account is a major objective.

One of your objectives when designing AD is to minimise the amount of domains needed - ideally down to just one. There are several reasons here to combine account domains:

• We've already decided to make the migration a two step process - if we were to have three domains during the migration of the administration network we'd have to purchase extra hardware and administration would be a nightmare for an IT department already rushed off their feet.
• Reducing the amount of accounts a user needs to just one has been highlighted as a major desired objective by the users themselves and the support department.
• There is no security benefit from having the teaching and admin domains separate - the greater flexibility and control GPOs and OUs provide negates this advantage of splitting NT 4 domains.

To take this into account, we proposed a Windows 2000 active directory design with the following characteristics:

• One single forest with a root domain (ad.lutonsfc.ac.uk) containing the "services" servers, and a child domain (users.ad.lutonsfc.ac.uk) containing the users, and their data.
• Separating the staff and students in this domain using OU for each group.
• Collapsing the NT 4 domains named 'lsfcservices', 'lsfcweb', and 'rmnetnt' into the new services domain by doing an upgrade in place on the 'lsfcservices' domain, and creating a new domain for the user accounts and files, and migrating user info across from the 'lutonsfc' domain initially and then ultimately the 'lsfcadmin' domain.

One of the reasons I've made a point of writing this "as I go along" rather than as a post-mortem of how it went afterwards is that its easier for me to remember to show you where we went wrong along the way. After the event it is easy to focus on the destination and forget or gloss over the bumps on the journey. At the time of writing I can be sure I won't forget the problems - I can still feel the pain. It reminds me of my first job, before they invented the "crash test dummy". Boy did I use a lot of Tylenol.

Anyway, at this point we are part way through our upgrade process. It might be easiest for us all right now if I describe the current active directory design so you can all see how it differs from what's above. Actually, the overall concepts and ideas hold strong, but the devil is in the details.

We currently have:

• Our root domain - "internal.lutonsfc.ac.uk" which contains users and user data. We also have a child domain - "services.internal.lutonsfc.ac.uk" which contains our various application servers. As you can see, we've kept our overall concept but turned it upside down. This was a basic requirement of RM Connect 3 that we were not initially advised about.
• "internal.lutonsfc.ac.uk" is a clean windows 2000 AD domain installation, with our learning domain users and files migrated across. This went fairly painlessly, despite some problems with the scripts we used to setup user home and shared areas, application areas and the like.
• "services.internal.lutonsfc.ac.uk" has also been created and is working well. This was, as proposed, an upgrade in place from the Windows NT 4.0 domain named "lsfcservices". We performed this upgrade by adding a new server as a backup domain controller in the NT4 domain, promoting it to primary domain controller, and running a server upgrade. This worked fairly well but we did have some issues with replication between the parent and child domain which we solved with time, patience, and TechNet.
• The reason for this approach was that due to some poor design decisions in the creation of the NT 4 domain all our servers were running their various apps AND functioning as domain controllers as well. Yeah I know what you are thinking but its too late now. We could not risk one of these servers failing on us (the reason we chose to upgrade the domain in the first place was because these apps servers were so critical to us) so we had to add another server just to be a domain controller that we could afford to lose if the upgrade died on us.
• I won't name names here but we've found that a few suppliers were, err, mistaken about their server apps being compatible with windows 2000. So while the servers hosting these apps are upgraded ok, we're talking to suppliers about some applications issues. None of these apps are core to the college so it's not halting our upgrade plan (important, yes, core, no!). Of course in the "commercial" world we'd have had a budget to setup a test network full of servers mirroring our live setup and find this out before starting the upgrade but we just didn't have the time, space, or budget for that.

There isn't much to say really. We have a few more member servers to build for each domain but that's largely routine work just kicking off our now debugged scripts and watching the logs fill up.

We had planned to do an upgrade from NT4 / proxy server 2.0 with WebSense to W2K/ISA with WebSense server on our proxy server but in the end we decided on a clean install. The amount of information that would usefully migrate over was outweighed by the weird issues we expected to find, and in the end we are very pleased with our clean install.

One amusing matter was the WebSense installation took longer than expected because I couldn't get it to contact its database update server. We spent about 3 hours assuming I had set up the various packet filters it needs incorrectly because I didn't know ISA server well enough, only to ring WebSense support for help with doing that to be told "Oh, that download server is down, try using another one" upon which it worked first time with the new server address and the very first packet filter I had created. Oh well.

This probably says something profound about the fine line between being over confident and not confident enough in your own abilities when doing something like this but right now it's been a long day, and I'm going to go take a break instead of trying to find a snappy moral.

Our next major project is going to be the Exchange migration. I daresay that will be worth at least one article of its own. Before we start that however I plan to spend some time checking the Active Directory and DNS information for our two domains and tidying up anything that looks "odd".

For now, I'll sign off with three hot tips for working with AD and AD integrated DNS:

1. There is no such thing as "too careful" when considering major changes.
2. Speaking of major changes to AD, "One Thing at a Time". Lets leave it at that.
3. Patience is a virtue. At least 70% of problems with newly created AD domains and weird DNS problems can be solved by leaving the systems in question on and going home for the night. This is what I'm going to do right now.

   1.  

Top