Maintenance

Started all the lab machines up, and tested login on Lab C 1; no problem. Deleted yesterday's file from Squash, as requested by Dan to Greg.

Lab C station 1, although apparently "in" the domain, was unable to log on through the domain. I removed it and added it back in, and after that it was fine. This may be caused by another machine having the same machine name (C1 was the model for the image), but I checked all of lab B and couldn't find any problems. I couldn't check lab C itself because of a class. I'll check tomorrow morning.

Booting up the labs this morning, discovered that B 24 was in an endless reboot cycle, with a brief BSOD just after the Windows boot screen. Rebuilt it using the BartPE disk and the Lacie USB drive, renamed it, regrunnered it, and then added it back into the domain. All went smoothly, as far as I can tell; it now boots OK and logs in.

Greg took me through the process so that I'm happy I know what I'm doing in case we have to rebuild machines while he's away.

In advance of Greg's absence next week, tested the new lab builds in lab B. All OK, except:

• Stations 4 and 22 in Lab B need to be built. I'll observe while Greg does a BartPE-based build, so I know how to do this.
• Stations 23 and 24 in Lab C are not built, and there won't be time for Greg to do those before he goes. They're new and different hardware, so they need a new build from scratch.
• Everything works well in the labs except that the student mics are a bit quiet; that will need a little tweaking later, but it's not bad enough to be a problem, and the volume control in the Sanako player helps.

Went through all of the common features in Lab B with Eoin and Martin (group conversation, pushing files/CDs/cassettes, telephone calls etc).
Found a few bugs with the teacher station user profiles, which will be a task for me in a minute, but generally everything worked well.

OK, all the machines seem to be functional. However, on several machines the admin profile is corrupted and when you log in as admininstrator you get a new profile based on "Default User" and it's called something like "administrator.Lab-B-02". This is similar to what happens when a machine's power is pulled while someone is logged in. The profile is not released and when they log back in a new profile is created and named "<username>.<machinename>".

Discussed this with Martin. His suggestion is to rebuild a handfull of machines and try rebooting them before logging in to see if it just needs another boot cycle to release the profile. It's easy to try and just might work, so I'll try this sometime, just not right away.

This morning I checked the machines I left ghosting last night and 13 were fine, profile-wise, but 9 were flaky. Two weren't entered in to the domain for some reason. I also rebuilt all of Lab C without renaming them or putting them in to the domain in order to test a theory regarding the profile problem. It had no effect other than making me manually rename and enter each machine in to the domain. About 12 machine had flaky admin profiles, and 8 were perfectly fine.

This is hard to explain in writing, but...

After discovering the various problems with the original XP build I completed a fresh build and rolled it out to Lab B, but the build had various problems. They mostly appear to surround the corruption or mismatching of stored SIDs. Target machines, created from a perfectly functional master, boot to a blank screen with a cursor and nothing else (but only when login is a user that once existed on the master). Ctrl+Alt+Del does nothing, you need to do a hard reboot. Logging in as admin creates a new profile from Default User instead of from admin, and calls it, for example, "admin.Lab-B-02".

I'm sure there's an answer, but I've spent all day on this and have not been successful. So I gave up.

My "solution" is to take the original XP build (the one that first exhibited the USB thumbdrive issue) and update it with the new driver and various other needed adjustments - mostly to do with the general user setup and temp directories. I came in at 5:30 tonight and finished the adjustments, pulled an image, and pushed it out to the machine at my bench (good speed achieved at this hour - 205MB/min).

Greg needs to be able to merge a specific reg file into the registry on the lab client machines after they've been built; the file is named for the machine name, so I wrote a little console app that finds the name of the machine it's running on, then uses that to find and merge the reg file silently. Simple for Delphi, but apparently impossible in Ghost.