In-Depth

Charting a New Course

Converting this college campus to a Windows 2000 network has definitely been a learning experience.


It has taken Windows 2000 well over a year to arrive in the Office of Information Technologies' (OIT) Personal Computing Classroom Operations' (PCCO) computing classrooms and labs here at University of Massachusetts at Amherst. The delay didn't exist because we didn't think Win2K was neat or that we were blissfully contented with the features of Windows NT 4.0-far from it. Until this summer, we just had a lot of legacy applications and hardware to contend with that made Win2K Professional and Server's chances of being implemented in our public areas prior to now about equal to a snowball's chance in hell.

PCCO has been using Win2K Professional on our staff machines since the early summer of 2000 and so far, we've generally been impressed by its overall stability and compatibility with the myriad applications we're using. From the day of its release, however, it was apparent that experimenting with Win2K Server live (on the network) in any of our labs would be out of the question due to the Unix-based Kerberos, DHCP, and DNS infrastructure we had on campus. Until all the bugs were worked out and an Active Directory infrastructure set up to co-exist with existing Unix-based services, no group on campus would be able to randomly test a Win2K domain controller. Despite our enthusiasm, that also included PCCO. Other groups within OIT were working closely to integrate an ADS domain structure with the preexisting Unix DNS system. PCCO and I would have to wait until that was in place before we could begin to even consider migrating our Windows NT 4.0 network to Win2K.

By January 2001, OIT's LAN Support division had finally installed and configured a Compaq Proliant 8000 server as the ADS root server for the campus' ADS infrastructure. It now runs a new zone called ads.umass.edu, separate from the campus' Unix DNS-served umass.edu. This was done so the Win2K dynamic DNS wouldn't interfere with the preexisting and long-stable Unix DNS. LAN Support migrated the OIT Windows NT 4.0 domain to Win2K shortly thereafter and it became a child domain off ads, now called oit.ads.umass.edu. Once this was all in place, we were finally able to begin to think about Win2K in a more concrete and realistic environment.

The PCCO Win2K team is made up of Electronics Technician Benjamin Gagnon, PC Support Specialist Michael Friedman, and me. We started to work towards implementing Win2K in our classrooms and labs in earnest on May 14, 2001. It was only when the majority of the students went home for the summer and we were able to stop doing our usual firefighting that we finally had enough time to focus solely on our endeavor.

I installed Win2K Server on a DHCP-networked Pentium II/233 desktop machine before the semester officially ended. I updated it to SP1 and applied the necessary patches from windowsupdate.com. Once it was up to snuff, I disconnected the server from the network and gave the machine the static IP address 192.168.1.2. I proceeded to run Dcpromo, install and configure DNS and DHCP and configure RIS with Win2K Professional (in case we wanted to experiment with IntelliMirror later on). We've isolated our little test domain from the rest of the world so there's no worry about affecting the live campus AD infrastructure. The server is currently disconnected from the campus network and connected to a Pentium/166 desktop system via a 10 Mbps hub.

Week One, May 14-18
I began the application-testing phase this week by installing vanilla, plain-Jane copies of Win2K Professional and all our applications to test for compatibility with Win2K on the desktop connected to the server. It's not exactly a perfect setup: I'm using one of our old legacy Pentium/166 Compaq Deskpro 4000s. The idea here is to see if the applications run at all, not determine how well they run. That's for later in the summer when the new equipment comes in.

I've run into some small snags along the way, namely WordPerfect Office 2000. The product's Web site says there are service packs to remedy some of the issues, but it didn't take long once I discovered its problems for PCCO to decide to upgrade to WordPerfect Office 2002 for the fall so we wouldn't have to mess with service packs and patching issues. I'll be the last one to complain. AI Squared's ZoomText Xtra 7.06 also has one particular hang up: it takes out the system's video driver once any of the upgrade patches for 7.0 are applied and renders the system unbootable. That's always a nice feature to have in an application. These two packages notwithstanding, it appears as though the rest of our applications, including some critical legacy DOS-based apps, will work under Win2K. Whew.

Week Two, May 21-25
When our users log into our current NT 4.0 classrooms and labs, their user accounts authenticate against a Unix-based MIT Kerberos realm maintained by OIT's Network Support Services division (OIT has a lot of divisions) via an in-house add-on login program called UMAccess. We use UMAccess to overlap the Windows login dialog box. Once they're authenticated, the system then logs them in using a default Windows account with a roaming mandatory profile. (In other words, all users in a lab physically use one account to access our resources once authenticated by Kerberos with their own personal usernames and passwords.) This summer we're hoping to implement true roaming profiles for all 30,000 users on campus. To do this, we must try to get our Win2K AD to coexist comfortably with our campus Kerberos realm. This week we're trying to follow Microsoft's Step-by-Step Interoperability Guide on our little test network. We've set up a FreeBSD system running Kerberos v5 on another Compaq Deskpro 4000 and have begun our attempts at setting up a trust between the Kerberos realm and our Win2K AD domain.

By the end of the week, despite following the interoperability guide, we haven't been able to get it working yet. One possible problem is that our domain and realm aren't of the same domain name structure (the AD domain is called ferrettech.edu and the realm is called pcco.umass.edu). We've got calls into Microsoft and newsgroup posts to microsoft.public.win2000.security. So far, it feels like we're chasing our tails.

Week Three, May 28-June 1
We have yet to get the Kerberos interoperability working yet, despite renaming the Kerberos realm kerberos.ferrettech.edu. We have a call into Microsoft Premier Support and even they are stumped as to why we can't get it all working. According to the logs, the encryption type being used isn't supported. We've sent them our krb5.conf and kdc.conf and everything looks fine to them. We've attempted to set the default encryption type to DES-CDC-MD5 as suggested, but somewhere DES-CDC-CRC is slipping in through the cracks and the Win2K Server keeps spitting it back at us saying the encryption type isn't supported. We're chalking it up to unreliable installations of FreeBSD and Kerberos v5 since we've fiddled with several of the settings, renamed the realm (twice), and none of us are Kerberos experts. The situation is almost akin to the three of us driving to Bradley International Airport, hopping into the cockpit of a Boeing 747, and trying to fly it to Redmond after flying around in Microsoft Flight Simulator for a few hours. I'm sure we could figure out how to get the bird into the air, but landing it might be a little tricky. A little information may get you started on something, but it by no means certifies you as an expert.

We've figured out a workaround to our Kerberos dilemma. We'll import all the campus usernames from our Oracle database into our AD. From there, UMAccess will do as it's always done (authenticate the user's username and password against the Kerberos realm). Now, instead of logging in as one specific user for the whole lab (via the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName registry key), it will pass into that registry key the username entered by the user. The program will then create a password based on the username, using a hash algorithm. Once it has both, the user will log into the Win2K domain and we'll have what we hope will be fully functional roaming profiles. Essentially, the users will never know their Win2K domain passwords. Michael is taking on the task of getting this to work. (I wish him luck; my idea of hash has corned beef in it.)

Week Four, June 4-8
Now that we've stopped playing around with Kerberos, the main focus of our attention has been forcibly wrenched from Win2K to deal with another mini-project: building images for student staff machines. No matter how big or important the summer project, there's usually a smaller one that needed to be finished yesterday waiting in the wings to pounce on you. We've taken this opportunity to explore some of Norton Ghost's remote capabilities to see if it might be of use to us in our computer labs this fall. We like what we see so far with the use of the Ghost remote boot partition. The term Cushy Chair Administration flows freely...

Week Five, June 11-15
I've been out sick most of this week. Mike and Ben devoted most of their time to other ongoing projects within PCCO while I was out, most notably dealing with the imaging of the student staff machines and firefighting other miscellaneous problems as they cropped up.

Week Six, June 18—22
Yet another week out sick again for me. Once again, Mike and Ben devoted most of their time to other ongoing projects within PCCO. It always seems like you get sick at the least convenient time. I don't get sick all winter and now I have to get sick in the middle of summer when we have probably our biggest project of the year on our hands.

Additionally, the enterprise admins are all in Atlanta at a tech conference this week, so we have to wait for them to return to discuss our plans for our AD setup. For the most part, weeks five and six are a wash.

Week Seven, June 25-29
This week Mike, Ben, and I are in a weeklong Win2K course sponsored by Microsoft University Relations. We've been able to throw a lot of questions at the instructor in regards to our plans for our labs and how to implement certain features of Win2K. Although we haven't gotten any hands-on work done in our labs, this week has been wonderfully beneficial in cramming our little heads with lots of information about group policies and domain replication.

We were finally able to pin down LAN Support to discuss our plans for AD. Initially, their plan was to have us exist in the OIT Win2K domain within our own OU called PCCO. However, that was before they knew we were considering having 30,000 user accounts in that OU. It's been agreed that we'll have our own domain, a child domain of OIT. Mike, Ben, and I are hoping we can really make this work. Other groups on campus are watching our lead to see if we can implement roaming profiles for all of our users. No pressure.

Week Eight, July 2-6
Week eight has been spent mainly hashing out our plans down to the finest detail. By the end of week eight, we're now the proud administrators of four bouncing Compaq Proliant ML370s running Win2K Server. We saved ourselves a HUGE chunk of time by looking into unattended installations using Setup Manager. This was the first hands-on work any of us have had on unattended installations outside a Microsoft class environment. None of the servers are DCs yet; although we've hashed out our plans with the enterprise admins, we need to schedule a time for them to come over and add our domain to the campus AD. In the meantime, we'll keep planning and making sure we have something concrete to go on before we dive into the wonderful world of AD.

Week Nine, July 9-13
One of the enterprise admins from LAN Support joined us at the beginning of the week and added one of our servers as the first DC for a new domain called classrooms.oit.ads.umass.edu (thank you, Microsoft, for adopting the FQDN naming scheme for domains. Really.) The campus AD is currently only using one DNS server running on umaadsroot.ads.umass.edu. The guys from LAN Support discovered at the conference that this wasn't the most optimal setup for the campus, so eventually each domain will be running its own instance of DNS Server for its individual domain. Right now, however, we'll continue to use the single DNS server on umaadsroot.

Now that our domain is in place, we have started to install Win2K Professional on three flavors on Compaq Deskpro minitowers we have in our fleet. Each one has slightly different hardware. We have the DeskPro EP 450+ Pentium II/450 with 128 Megs of RAM and a six GB HDD, the DeskPro EP 600 Pentium III/600, also with 128 Megs of RAM and an eight GB HDD, and finally our newest DeskPro EN 733 Pentium III/733 with 256 Megs of RAM and a 10 GB HDD. We've used unattended installation scripts to install Win2K on each type of machine. Then I took a sysdiff snapshot of each machine and created a Ghost image for each machine. (Over the years, we've learned to cover all bases when it comes to building images. The one time you think everything's working is the one time everything blows up and you didn't make an image, so you have to start again from scratch.) We're planning to install most of our applications on only one machine and then sysdiff the changes to the other two machine types. Some applications won't sysdiff properly so we'll have to install them separately three times, but that's ok. If we can get the biggest packages out of the way, like Adobe Photoshop 6, SAS 8.2, and Microsoft Office 2000 in this manner, we'll have saved ourselves a lot of time.

Week 10, July 16-20
Most of the morning of Monday, July 16th was spent catering to the needs of our departmental NT 4.0 servers. Apparently over the course of the weekend, the SunOS/BoxPoison worm hit several of them. This, of course, sent us into a flurry of virus scanning and file deletion to solve the problem. It turned out to be a campus-wide issue. No rest for the weary.

By the end of the week, we'd managed to install 13 application packages onto the Deskpro K450+ imaging machine. We only have a mere 35 to go. We've installed most of them to a Dfs share called \\classrooms\apps. I sure hope sysdiff works properly because I don't want to have to spend another week reinstalling those 13 applications twice (one for each additional system type). At least the biggest applications are now out of the way.

Where We Are Now
As of this writing, we're about to start week 11. We still have a ways to go. We have plenty more applications to install and we haven't even finalized how we're going to implement our Group Policy Objects. Assuming nothing catastrophic happens (the campus fiber network goes down, UMass/Amherst gets mistaken for NORAD as a primary missile target by some agitated Third-World country, junk food gets outlawed by the Commonwealth of Massachusetts,) we're hoping to have all the applications done by mid-week. Mike has started working on implementing the hash algorithm into our login program so it will be ready to test soon. Our servers seem to be running smoothly, even if the 10BaseT connection between most of them (they're all in one lab connected together via a switch) is frustrating at some times. (Note to the misguided: don't change file permissions on a 2 GB Dfs share while you're installing applications. If you're replicating out to six servers all at the same time, you might as well call it a day.)

With any luck, everything will go smoothly and all the labs will open on time, all the computers will work, and Microsoft won't release a service pack that will render a large portion of our computers paperweights. This fall we're looking into playing with Systems Management Server 2.0. We've got more projects to keep us busy than we know what to do with.

Hopefully, the three of us won't go batty in the process. Wish us luck.

Featured

comments powered by Disqus

Subscribe on YouTube