XP spews on profile, AGAIN...

A few weeks ago I wrote about some strange things we had seen occurring with mandatory profiles. We had twice witnessed the scenario of an improperly configured mandatory profile causing user policies to fail or terminate prematurely. Naturally, I concluded this must be a scenario specific to man profiles. Well, I was wrong. Today I had it happen with just an ordinary user with their own roaming profile on the server. There's a chain of events, which goes like this:

• A user leaves the employ of our enterprise, and her computer is taken over by another staff member who doesn't have their own login account.
• Logically, the departing user's account is simply renamed to be the new user. But this causes folder redirection policy to fail. Microsoft claims this was first fixed in SP2 - the version the computer is running.
• To cut a long story short, I decide to drop the user account and create a new one. Windows then refuses to load their profile from the existing folder, despite having full control, because the ownership is set wrongly.
• I reset the ownership of the profile folder and all subfolders and files from "Account unknown" to "Administrators".
• At next logon, Windows pretends to load the profile, but user policies are incomplete - as shown by the apparent non execution of the login script resulting in no drive letter mappings. The user's start menu also has no program shortcuts on the left hand side, including Internet and Email.
• Eventually I dropped the profile and created a new one, result: problem solved.

Is there a pattern to this? You bet there is. One of the most annoying repetitive problems we have had is with our existing users that we migrated from our Samba system to Active Directory at the beginning of this year. We had Windows create new profiles for them, and then some of the data from their previous profile was merged into the new one (e.g. My Documents). The most consistent problem that these users have experienced is, you guessed it - incomplete user policy application - often expressed through login scripts not running or not finishing.

Another nasty little surprise to watch out for when you rename a user is, even though you can change the name of their profile folder on the server, Outlook keeps using the old local path for its data files. This is because Outlook's file paths are hardcoded rather than using a variable name as the Registry does.

Vista looms on the horizon

Many NZ schools get major software through the deals done by the Ministry of Education with suppliers like Microsoft, Apple and Novell. This year, the agreements were up for renewal. MOE has now announced that the packages available to schools have been finalised. The major change in the Microsoft licensing is the introduction of Windows Vista Business Edition. It means that TELA laptops will now start coming out in a month or two with Vista installed instead of XP.

What does this mean? It means we have to start getting to grip with the new technologies needed for deployment, particularly in larger schools. With 100 PCs in my situation, transitioning to the new Windows Deployment Services technologies for image creation is one of the first steps, and one I'm already working on. The Service Pack 2 for WS2003 installs WDS. In my previous articles I referred to using it with existing RIS installations, because I installed SP2 a few weeks ago on our existing RIS server.

Although I had not planned to look at Vista on the desktop in any part of the school, it's now clear this would be highly desirable. We will start to get laptops in with Vista soon and have to work with it. Not all of the school's desktops will run it; the main limitation being 256MB of memory on the oldest ones. The biggest advantage of Vista is having only one deployment image. Gone are the days of multiple images for different hardware configs.

The deal also includes MS Office. At this stage it's not clarified whether this is Office 2007. I'd want to look at the possibility of deploying both 2007 and 2003 in the same image, due to the changes in 2007.

I guess that having developed this RIS image for XP on our older machines (most of the ones that don't have enough memory for Vista), the next image of any sort will be a Vista WDS image for the machines that can run it. These are mostly Intel motherboards with the onboard ATI Radeon Xpress 200 chipset with 512MB and should have the graphics capabilities as well as memory to run Vista quite well. This image should then be able to be deployed to any of our PCs that has 512MB or more, including those with other onboard hardware, such as laptops.

Part of Vista is Windows PE 2.0, the preinstallation environment that can also be used as a recovery tool. Formerly the only way you could get this for general use was as Bart's PE, which has licensing issues. WinPE is now, however, part of all Vista installs. I'm buying a 512MB pen drive just to set up as a bootable WinPE drive for machine recovery. 

Prestaging computer accounts for RIS / Conclusion

One of the great things that RIS does much better than Ghost for image installations is that it allows the computer account to be prestaged in Active Directory. Basically, the PXE specification provides for each computer to have its own unique GUID. This is transmitted in the DHCP Discover packet and is used to identity the machine account in AD. The result is that the machine itself can be given its proper name automatically, and joined to the domain automatically using the prestaged account. Yet another manual step, changing the machine and domain account name, is eliminated.

Both RIPREP and RISETUP images will handle this automatically if their respective SIF images contain the magical lines to automatically join the domain. The only real effort for a sysadmin is to create the machine account with the GUID field filled in properly. There are two ways of extracting this information:

• The GUID or UUID value may be found in the BIOS in many cases, and then manually copied to be put into the account properties.
• A Visual Basic script can be run against the machine's network name to extract the information using WMI. The target computer must be up and running Windows to do this, with remote administration enabled in Windows Firewall.

A script for doing this is as follows:

Dim strComputer, objComputer, objWMIService, colSettings
strComputer = "<computername>"
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" _
& strComputer & "\root\cimv2")
Set colSettings = objWMIService.ExecQuery _
("Select * from Win32_ComputerSystemProduct")
For Each objComputer in colSettings
Wscript.Echo "Caption: " & objComputer.Caption
Wscript.Echo "Name: " & objComputer.Name
Wscript.Echo "UUID: " & objComputer.UUID
Next

Put the actual computer name into the strComputer variable in the second line e.g. "ADMIN13".

Then you need to input the information into the account. This can only be done if you ticked a box in the account creation wizard that says "This is a managed computer" at which point you would have been prompted for the GUID. The data can't be added to existing accounts that weren't created as managed computers.

Another way to get the GUID is to let an RISETUP installation create an account with a default name, and then copy the GUID that RIS automatically stores for you in the default named account it creates when it joins the domain. You could even try renaming the PC, not something I've had a lot of success with.

In conclusion. RIS is a very powerful tool and well worth the effort. It has taken a lot of work to get to this point of creating our RIS image, and it is locked to a group consisting of only half of our desktops. Since I have managed to document the process so well, another time it will be much more straightforward and less time consuming. Of course, now that we have WDS, the next challenge will be to turn my RIS image into a WDS installation. That is a big task in itself, and sometime in the future I will write another series of articles about that.

I trust someone finds this journey and process useful in some form. Have a great day!

Testing the RIPREP machine image

For the first test, I simply used the image that I created, as-is, on another, identical machine. The following issues have occurred:

• Mini-setup asked me for the name (not the organisation) to register under.
• Mini-setup asked me for the PID key.
• The setup formatted the entire HDD for C:, not a 20GB partition as the source computer had.
• On first Windows startup, the screen resolution is not set to that of the source (although this could be a detection problem with the KVM I use).

On the other hand, the image appears to have installed correctly with all configuration steps taken and all applications ready for use.

Customisation of the RIPREP.SIF file should address these issues. RIPREP is annoying enough to not copy anything from the source image's SIF file, but its default settings get some of the work done. 

According to the RIPREP image creation article in Windows 2003 -Software Deployment - Remote Installation Services, the riprep.sif file is stored in a Templates folder in the image that was previously created. I am going to create another image from the source machine first and then edit the SIF on that image. I'd also like to remove the first image but WDS doesn't seem to provide a way of doing that. The new image creation goes off without a hitch.

Editing my SIF file, I copy the following chnages from my RISTDND.SIF file that was used to create the original Windows base installation:

• [data] section: remove line DisableAdminAccountOnDomainJoin = 1 . This line will disable the built in administrator account on the target PC. Disabling is not a good idea because if something goes wrong with domain login you have no local account to log in with.
• [Userdata] section: add a ProductID = line which contains the license key. Change the Fullname and Orgname value strings to hardcoded constants rather than variable names.
• [GuiUnattended] section: change the AdminPassword= value to the encrypted form of our local Administrator password and add the line EncryptedAdminPassword=Yes .
• [Display] section: change the values to the ones I want it to use rather than the defaults.
• [RemoteInstall] section: include these lines - Repartition=No and UseWholeDisk=No to have the partition size of the original image copied and automatically created.

Starting the image load on the target machine, it is great to see the fully automated process. An interesting difference from Ghost is that RIS appears to run the normal Windows setup process and then customise it and copy the extra files. Ghost just copies the files exactly from the source image. [UPDATE: The Riprep setup runs in three stages: (a) initialise setup and partition the disk (b) copy all files in the image (c) Mini setup applying specific customisations and settings from the SIF file]

The target installation went off with only a tiny glitch. Mini-Setup put a message saying that the administrator password could not be changed. However, while displaying the dialog asking for the password to be entered, Mini-Setup continued automatically without waiting or pausing and the password was found later to be correctly set as per the SIF file. The screen resolution was correctly set... in short, the installation of this image went just as hoped for and completely automatically. [UPDATE: Changing the password to non-encrypted form works perfectly, without the error]

The last post in this series will discuss prestaging machine accounts in Active Directory.

Creating the RIPREP machine image

Last time I discussed some background to RIS and preparation for imaging a machine. Now it's time to take a look at the process of RIPREPping itself. We require custom network and other drivers loaded in the image, so I need to follow the process described in http://support.microsoft.com/kb/314479 to enable these to be included in my image. My RISETUP image for base Windows automatically creates a Drivers folder in C:\ which contains those drivers. Looking into this article, I need to perform these steps on my source machine:

1. Create a SYSPREP folder in C:\
2. Create a SYSPREP.INF file in this folder and add the following text to it:

[Unattended]
OemPnPDriversPath = Drivers\Network;Drivers\Display\i915;Drivers\Sound

Then, I can go into the Create a Remote Installation Preparation Wizard image article and run RIPREP.EXE as documented there. For best results I should be logged on locally as Administrator and have removed any roaming profiles stored in C:\Documents and Settings.

When I run RIPREP it will ask me for some information about the image. It then presents me with a list of services that it will stop on the client before imaging proceeds. It may then also ask me to stop certain services and terminate certain applications manually.

RIPREP will then begin creating my image. This takes a while. I use some of the time to read Wes Miller's article on Windows Automated Installation. This is the WDS based technology that supersedes RIS. You may ask why I didn't just use WDS to create this image, since our RIS server has upgraded to WDS with the installation of WS2003SP2. The answer is that it is a new learning curve that will take time to migrate to. WDS can do RIS stuff a lot better, so I just plan to use RIS far enough to get this one machine image available and then migrate to WDS for any future imaging requirement. Meanwhile, back at image creation, I've just noticed that my image is about 30% too big; I'll have to do another creation after I remove redundant data from the HDD.

The process completes without any further user input, and the source computer shuts down automatically. While it restarts, I check the final step in 314479, restarting BINLSVC. This only seems to be related to changes in the RISETUP image, which I already followed, so I skip this step.

The most annoying part of RIPREP is that the mini-setup wizard has to be run on the source computer at the end of the image create process. After this is complete, the source computer is ready for use and we can look at customising the image's unattended answer file (riprep.sif) before deploying it.

Article 314479 has one step that I've ignored:

If the device has already been recognized by the operating system as a known or unknown device, you must remove the device through Device Manager before you run Sysprep, or the updated drivers will not be installed at startup during mini-setup.

Firstly, I'm not using Sysprep, and secondly, if I removed the network card driver, RIPREP would not be able to run.

Creating RIPREP Images

Remote Install Services is a great replacement for Ghost, which is something we grew up with from our non-AD environment. RIS, like everything, has a learning curve, but it is easier to set up machines and you don't need to buy extra software and licenses as it is built into Windows Server.

RIPREP is the RIS version of Sysprep: a way of cloning machines to produce an installable image that can be replicated, yet that also permits some hardware variation and handles uniqueness requirements. Both have certain procedures to follow if the drivers for your particular hardware are not included with Windows. This procedure is documented in the articles referred to in yesterday's posting. A RIPREP image is installed using PXE. I'm setting up my first RIPREP image out of necessity: one of our desktops has had to have the HDD replaced and requires a complete reload. Most of the work for imaging is actually installing the operating system and software. Running RIPREP itself requires only a small number of steps, and if you already have experience of unattended setup answer files, you are partway there.

So here we go. I've tried one RIPREP imaging cycle already, but it couldn't load without the proper network drivers. That will be part of the challenge this time around. Starting with a bare PC, I've installed Windows from my RISETUP image that I customised on Tuesday. I've configured and updated the Bios, installed the latest drivers, installed applications and configured settings. Here is some of Microsoft's technical documentation for RIPREP that I'll refer to for the image creation process:

• How to Add OEM Plug and Play Drivers to Windows XP
• Remote Installation Services (Windows 2003 Software Deployment)

I'll describe the RIPREP process in more detail in my next posting.

Background

A bit more information about the environmental background to this blog being set up and written will help you to understand why the blog exists and the subject material that it will cover.

I have extensive computing experience and vocational qualifications specifically related to programming. However in recent years my work focus has shifted to desktop software and hardware support in the Windows environment. In the last 12 months this has been extended to network servers (mainly Windows) with additional training, including MOC Windows Server.

The workplace has also transitioned, firstly to modern desktops running modern versions of Windows, and latterly from a Linux Samba server environment to Windows Server 2003. The first two WS domain controllers were brought on-line in January of this year. The school has two distinct sites which are linked by a 10Mbps wireless connection. There are leased laptops in use by some of the staff in addition to about 80 desktops, virtually all running Windows XP. The school has signed up to the NZ Microsoft Schools Software Agreement.

In addition to two Windows Servers, we also have one Linux server which runs our inhouse mail server, firewall server and Internet content filtering. It is running Suse Linux Enterprise Server. There are also several PCs running OpenSuse.

The support resource background is affected by the following considerations:

• My experience with Windows Server is mostly theoretical, with as yet limited practical knowledge.
• I'm still studying some of the MOC courses for areas of WS other than Active Directory.
• The WS environment and Active Directory is a new system in this workplace.
• The Linux server is maintained by another person as I don't have much of the knowledge needed to install/configure it.
• Outside support is largely adhoc.

On the other hand, there are some positive considerations:

• Most of the desktops are in two distinct hardware configurations as they were bought in batches.
• The desktop supplier is a specialist in the education market with wideranging experience.
• Most PCs are modern (Pentium III minimum) and all are running at least Windows XP SP2. No horrible old Windows 98 PCs (phew!)
• One of the servers is running WS2003 R2 (the other is SP1).

The purposes for setting up this blog are severalfold: to provide a documentation reference for me to use when referring to procedures that I don't perform that often, to share those experiences with others who may find them useful, and to encourage discussion and networking between computer support professionals in NZ schools.

Customising RIS images with drivers

When you create a basic RIS image, it comes with just the drivers that Windows supplies. To get even a flat image installed on a bare machine, you may find extra network card drivers are needed so that Windows can connect to the network and download the files it needs to install Windows.

For a flat / Risetup image (a base installation of Windows) the procedure for customising drivers is along the following lines. There are two distinct points at which additional network card drivers may be required:

1. The initial setup phase of connecting to the RIS server and copying the files to the local computer.
2. The plug and play detection phase in which the network hardware is installed by Windows. At this point you can also add extra drivers for other pieces of hardware.

Once the installation of a particular image is commenced, Windows Setup runs. At this point, it needs to find network drivers from those included in the image to load the rest of the files needed to perform the setup. It is at this stage that you may see a message reading "The operating system image you selected does not contain the necessary drivers for your network adapter." To resolve this particular issue the .inf and .sys files supplied by the network card manufacturer must be copied to the i386 folder of the RIS image you are installing from.

Once Windows is able to connect to the RIS server, it will complete the initial stages of setup and restart in the GUI setup mode. At this point, network and other drivers can be added to the image so that Windows can install drivers for all hardware it detects. This step is required if using an unattended installation (SIF file). The articles listed below document how to create a folder structure and how to customise the SIF file to tell Windows where those files are. These files are copied to the root of the Windows hard drive.

After changes have been made to the image drivers you need to restart the RIS service, the procedure for which is included in these articles.

Knowledge Base Article 314479 also documents how to add the drivers to RIPREP images (machine images created for cloning to other machines). This task requires additional work, which I haven't yet mastered. I'll document my journey along this particular path in a future posting.

• How to add a third-party OEM network adapter to a RIS installation
• How to Add Third-Party OEM Network Adapters to RIS Installations
• How to Add OEM Plug and Play Drivers to Windows XP

Upgrading WS2003 to SP2 causes RIS problems

Windows Server 2003 Service Pack 2 upgrades the RIS server, if you have one, to Windows Deployment Services. WDS can run in a legacy mode for backward compatibility with RIS - it is normally set up as a mixed environment to allow both to run. WDS is the new technology for deploying images that is introduced with Windows Vista.

This is of interest in our scenario as we have just started using RIS and have got as far as creating an RISETUP image to load Windows onto naked machines. I hope to go a lot further and create full machine images so we don't have to use Ghost anymore.

The following are important points or issues you may face when installing SP2 and having it upgrade your existing RIS configuration:

• If the WDS server and DHCP server are the same computer, WDS must be configured to not listen on port 67 and the DHCP Scope Option 60 must be set to "PXEClient". The WDS wizard covers these settings when first run, and they can be configured as options in WDS server properties later on.
• You may get a "PXE-E55: ProxyDHCP service did not reply to request on port 4011" error when you try a PXE boot to the WDS server for the first time after upgrading your RIS server. The DHCP phase of the PXE boot will take a long time before this error finally pops up. To resolve this, run "Windows Deployment Services Legacy" in the Administrative Tools folder and select the option to perform a diagnostic check. Alternatively you can run "risetup -check". It appears this step is necessary to ensure WDS services are initialised and started. 
• You may then get "PXE-E3B: TFTP Error - File not found" messages. Open "Windows Deployment Services" (not the Legacy version) in the Administrative Tools folder, select your RIS server and select Properties. On the Boot tab you will see a list of default boot programs. For x86 this will point to "boot\x86\pxeboot.com". If you do not have any Vista images to install then this file will not actually exist. In this case, you can make the installation work by changing this to "oschooser\i386\startrom.com" which is the old RIS file. (Thanks to the TechArena forums for this tip)

Windows Mandatory Profile Issues

Mandatory profiles are something that came in from NT4 or earlier. They are a great way of working around limits of the Windows profile model. If you have a few hundred users who don't need a customisable profile or to save profile settings, a man profile provides a great way of setting up users with one profile on the server that they can't change.

Essentially Windows has a certain mindset when it comes to profiles. Man profiles give you the ability not to have a local profile stored (saves disk space on the desktop), the ability to have a common profile for everyone (saves disk space on the server) and the ability to have a profile that the user can't change. For some users, individual profiles aren't really necessary. The way that Windows works with profiles makes it difficult to dispense with them completely on a network. The ideal would be a local profile on each machine that doesn't get saved, but this isn't supported. The man profile is what we get, and if we can live with its issues, it does a pretty good job.

The documentation for Windows suggests ambivalence towards man profiles. XP documentation suggests using policy lockdowns instead of man profiles, but the policy settings can't replace everything that a man profile can do. Man profiles are supported in Vista, but I haven't yet found out whether this is for backward compatibility or because MS has been listening better to customers' needs. There are some things for a user that can only be done in a profile, and other issues like the profile storage space requirement, synchronising roaming profiles, and upload bandwidth at logoff. As long as the profile model used in recent versions of Windows continues, man profiles will be justified.

There are some problems in use of man profiles. One of the most significant concerns per-user GPOs. If you have not got the profile set up properly, none of your GPOs will be applied. This is a big deal if you have lockdown policies in effect. There is no obvious reason, apart from setting the correct security permissions for the Everyone group, why this should be so. I've spent hours trying to figure out why a man profile wouldn't load GPOs, only to give up, create a new one and see it work.

Welcome

This is my new blog. I'm a computer technician working in the education sector of New Zealand, and this blog will chronicle the challenges of maintaining 100+ PCs and three servers in a predominantly Windows environment.

I'm creating this blog using Windows Live Writer at home, but due to tech problems I'll have to use the Blogger website at work. (UPDATE: WLW now functions at work as well, so I'll use it both places) As far as WLW goes, this means living with the technical limitations of this product but it gives me a means of evaluating this product and perhaps contributing to the beta program while at the same time being able to discuss issues that arise from working in the computing industry.

So I hope you find something of interest to you, and at the same time I hope that this blog will provide me with a means of getting feedback on some of the challenges that we experience in this industry, especially those of a technical support person working in an organisation where computers are just another resource, rather than a major focus.