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.