Rollout Strategy

Before you start upgrading users to the new OS, the basic recommendation for rollout is to upgrade a few administrative workstations to Windows Vista quickly. This not only lets administrators familiarize themselves with the new OS, it also gives you some place to build and manage group policies for computers running Windows Vista. As of this writing there are Group Policy extensions for some of the Windows Vista settings available for Windows Small Business Server 2003 R2 (http://www.microsoft.com/downloads/details.aspx?FamilyID=). However, there is no update for Windows Server 2003 to support management of Windows Vista specific Group Policy settings. That means you need a Vista workstation to manage the settings.

It is also highly recommended that you plan a schema upgrade for Active Directory so that you can manage wireless settings and use BitLocker key escrow, if you wish to do so. Full hard disk encryption is a worthwhile technology at least on all mobile computers. BitLocker does cost extra though, as it is only available on Enterprise Edition and Ultimate. Evaluate your options, and if BitLocker is your choice, start planning now for how to handle key escrow. Our experience tells us that manual key escrow works fine, until the first VP misplaces his USB flash drive with the key, and needs to get the recovery password.

We also recommend that you do not put Windows Vista settings in the GPOs you use for the existing clients in your environments. Chances are you do not want to have all the same settings apply to them. For example, we ran into trouble in a pilot when we discovered that the existing group policies force deployed McAfee's Host Intrusion Prevent System using Group Policy Software Installation. That particular tool was written to modify parts of the OS that Windows Vista considers it an aggressive act to modify; parts only a rootkit might modify. Consequently, every one of the Windows Vista computers "blue screened" on the first boot after they were joined to the domain. You really want to create separate GPOs, and then, judiciously, port settings that will work on Windows Vista. You can augment them with settings that are specific to Windows Vista.

After you have created your Windows Vista specific GPOs, you should use WMI filters to ensure that they apply only to computers running the new OS. In Chapter 11, we showed how to create such a WMI filter to manage the firewall settings. For your WMI scripting enjoyment, on the Web site for the book, we have a little script that dumps out all OS parameters in WMI. Any, and all, can be used to write WMI filters to ensure that your policies apply only to the right systems. One useful, but often overlooked, parameter is the Product-Type. A product type of 1 indicates a workstation, 2 indicates a DC, and 3 is a server. By putting and ProductType=“1” in your WMI filter, you can ensure your policy applies only to workstations, for instance.

Logon Scripts Fail Because of UAC

Some very common operations may need to be rethought due to the new features in Windows Vista. For instance, UAC will block certain operations in logon scripts because they may require administrative interaction. An example is a logon script that maps drives. If you find this failing when you move to Windows Vista (we have not seen that particular operation fail), you can postpone that part of the logon script until the user's desktop has been fully initialized. Microsoft provides a script, launchapp.wsf, on the TechNet Web site that creates a scheduled task instead. The actual logon script is started as soon as the launchapp script is done running, but this should be enough of a delay to make it work properly. Test whether you have the problem first though. Unless you have logon scripts with very specific traits, you will not have a problem.

Using Group Policy in a NAP Environment

We have deliberately not discussed Network Access Protection (NAP) much in this book. NAP is a policy enforcement mechanism, pieces of which ship in Windows Vista. NAP is designed to intercept and assess clients' configuration state before they receive full network connectivity. An administrator could define requirements that must be fulfilled before a client is permitted to access network resources, such as up-to-date patch state, and a firewall in a certain configuration.

The client component for NAP ships in Windows Vista, but as the server components are required, and will only ship in Windows Server Code Name Longhorn, we decided to skip most of our discussion of NAP until we write an as-yet-not-planned book on that product. Besides, NAP is a policy deployment and enforcement mechanism; not a security solution. NAP cannot keep malicious hosts out of the network. It can only ensure that hosts that want to comply with policy keep doing so.

There are some interesting things that happen to Group Policy when you use NAP, however, that merit mentioning here. The entire purpose of NAP is to deny clients full connectivity until they have proven themselves to be in a known good state. Until that time they are placed in "quarantine" where they have very limited access to network resources. NLA, which is used to detect the presence of a domain controller, unfortunately does not detect the transition from a quarantined to a non-quarantine environment. This means that NLA will detect the domain but the Group Policy client will be unable to download and apply Group Policy because the client is quarantined. When the client is released from quarantine, NLA fails to notice, and never notifies the Group Policy client to refresh group policy.

Microsoft has so far published only a fairly unsatisfactory work-around for this problem. It involves the administrator writing a script that continuously scours the Event Log for quarantine removal events, and triggers a Group Policy refresh when it sees one. One can only hope that Microsoft uses at least some of the developer hours between now and when Windows Server Code Name Longhorn finally ships to fix NLA to work with NAP.