Vista – The Road to Production at UVM
As everyone now knows, Vista has officially launched. We don’t expect to see Vista shipping on new Dell systems until sometime in January, but that is really just around the corner. Vista has dozens of significant new features and hundreds of smaller changes that will affect the ways that we deploy, configure, and support Windows at UVM. Now is the time to get ready for Vista! The Enterprise Technology Services department has convened a new committee of the IT Standards group to ramp up IT staff at UVM for Vista support.
This article will present an overview of many of the policy decision points, technology infrastructure implementation hurdles, and workstation security changes that will need to be made before we can realistically claim to support Vista at UVM. Each section will contain an introduction to a key Vista technology, and will be followed by questions concerning its deployment and support. Each section will conclude with links to external documentation whenever possible.
Please consider how you can assist in this gargantuan effort. The Vista support committee will be happy to accept your help with any of these tasks.
The Vista support committee will continue to make information available to the UVM community though a few channels. Email discussion will occur on the IT-Standards mailing list:
Major announcements will be posted to IT-Announce:
Notes from the IT Standards Vista task force can be found in the semi-official “UVM Wiki”:
Additional Vista work notes pertaining to support of Vista in the CAMPUS Active Directory domain can be found in the “Active Directory at UVM” Sharepoint site:
Vista product editions:
Many people have been bewildered by the impressive array of Vista product editions. The prospect of supporting many separate Vistas has many IT support staff concerned. However, in practice we really will need concern ourselves only with four of the eight editions: Home Basic, Home Premium, and Enterprise, and Ultimate.
Both varieties of the “Home” editions lack corporate management features, and thus will not be deployed or supported on institutionally-owned systems.
“Business” edition is the baseline managed Vista product, and it will be the default edition sold on business-class computers at retail stores. However, Business edition will likely be a fringe product at UVM owing to the availability of the “Enterprise” edition. Enterprise edition is available to Volume License customers (such as ourselves), and it includes the drive encryption feature known as “BitLocker”.
“Ultimate” edition contains all of the features of all other editions, plus some multimedia tools not available elsewhere. This is not likely to be seen much at UVM except perhaps in media labs, or on high-end workstations used by individuals with specialized multi-media needs.
Thus it seems that “Home” editions will be fairly typical for student systems, while the vast majority of faculty/staff computers will run “Enterprise” edition. However, we will need to verify the actual availability of the Enterprise product for Campus Agreement customers. At this time, we still have not obtained access to all Vista products, so the seeming clarity of this decision may be called into question in a few weeks.
A matrix of Vista product editions and their various features can be found at Paul Thurrott’s excellent “SuperSite for Windows”:
User Account Control (UAC):
Under default conditions, new Vista deployments prompt the user to create a new user account with Administrator privileges. A common criticism of Windows security has been that any user session running with Administrator-level privileges decreases the effective security of the system – a malware attack can take advantage of the rights of the current user to take complete control of the computer.
However, a new feature of Vista known as User Account Control (UAC) can mitigate this vulnerability. UAC forces administrative users to “sign-off” on any action that would require administrative access before that action occurs on the system. This prompting occurs in a “Secure Desktop” environment that clearly delineates prompt from other running tasks.
In a default installation, the user is given a simple Allow/Deny prompt any time an action taken on the system requires administrative privilege… even if the current user is an administrator. This mode of operations is called “admin approval mode”. Alternatively, admin approval mode can be configured to force the user to enter his credentials for each administrative action (either in the form of a password, or an alternative authentication mechanism such as Smart Card for biometric scan).
UAC also can be configured to allow non-privileged users an opportunity to enter the credentials of a privileged user when administrator rights are required. This UAC mode of operation is called “Over-the-Shoulder Authentication”. This functionality is similar to that of the familiar “run as” command originally introduced in Windows 2000, but it is more transparent to the end-user.
Microsoft recommends that organizations restrict their users to run in standard (or non-privileged) mode, and refrain from sharing any administrative credentials with the user. Although this seems sensible from a security perspective, this approach may not be workable from a support perspective. If central IT does not take responsibility for the ongoing maintenance of software on end-user workstations, preventing staff from making administrator-level modifications to the computer can severely hamper user productivity.
Unsolicited opinion alert… Microsoft put a lot of consideration into UAC. Considerable user feedback on UAC was gathered and analyzed during the Vista beta program. Microsoft used this feedback to refine the UAC defaults to their present state. I think that in absence of a managed systems initiative at UVM, we should use the UAC defaults for new Vista deployments. Although this does mean that most users will continue to run as administrator, UAC still forces users to effectively run as standard users, and we should see corresponding improvements in session security. Forcing departmental users to run as standard users without access to administrator credentials will put a strain on IT support staff for which they are not prepared. And If we distribute a local Administrator password to the client, we really will see no improvement in system security over the default. If we keep UAC running in default admin-approval mode, we also gain the freedom to disable the default “Administrator” account, this gaining some additional security from scripted attacks on that account.
Given the broad impact of the UAC feature, it is unsurprisingly that Microsoft has made a mountain of UAC information available. Below are some links that may be useful.
Technet has a good overview of UAC technology:
TechNet provides this article which may be of assistance to anyone attempting to understand the changes in Vista which affect users running in standard mode:
Finally, the team at Microsoft which develops UAS has their own blog, which is loaded with useful links on specific UAC topics:
Driver Installation Control
Should we choose to restrict some or all users to run as “standard users”, we will need to be prepared for frequent support calls to assist in the installation of supplemental system drivers and software. On Vista Enterprise and Ultimate editions there is a supplemental feature of UAC which may mitigate some of these calls. By using this “Driver Installation Control” feature, the installation of drivers from a “trusted store” can be delegated to standard users. Also, whole classes of drivers (such as printers and removable media) can be flagged for installation by non-administrative users.
More research needs to be conducted into the feasibility of this delegation feature. Is the pool of hardware that our clients utilize predictable enough to make the implementation of a useful trusted driver store possible? Also, if we delegate the ability to install whole classes of drivers to standard users, are we effectively crippling the security of the standard user session?
Unfortunately, comprehensive documentation on this feature is hard to come by. A basic overview of Driver Installation Control is available in the TechNet article previously referenced above:
Hopefully, additional documentation will become available in the near future.
ActiveX Installer Service
Another supplemental feature of UAC makes it possible to delegate installation of ActiveX controls from “approved sites” to standard users. This functaionality is made possible though the “ActiveX Installer Service”. If we restrict many users to standard mode, we might want to consider maintaining a well-maintained list of common ActiveX controls (such as Adobe Flash and Adobe Reader) to reduce the frequency of requests for Over-the-Shoulder credential requests.
As with the “Driver Installation Control” feature discussed above, research needs to be conducted into the practicality of this feature. Maintenance of the trusted controls list will require dedication of central IT resources to the task.
The UAC team blog has made this information available on the ActiveX Installer Service:
Unfortunately, as with the Driver Installation Control service discussed above, more technical information of the ActiveX Installer Service is hard to come by at this time.
BitLocker Volume Encryption
BitLocker is a whole-volume encryption technology available in Vista Enterprise and Ultimate editions. When activated, BitLocker will encrypt all of the contents of the system volume on a single Vista install. By contrast, the Encrypting File System (EFS) which is available on Windows 2000 and XP encrypts only selected files and folders on an XP installation, but not the NTFS file system itself. BitLocker effectively renders a hard unless it is loaded on its native workstation. This feature could be extremely valuable in ensuring regulatory compliance (HIPPA, FERPA, etc.), and also could help to reduce the dangers caused by the loss or theft of institutionally-owned computers.
A full discussion of the technology behind BitLocker is out of the scope of this article. Links are provided at the end of this section for those who want to learn more about the hocus-pocus that makes BitLocker possible.
In its most basic mode, BitLocker checks OS file integrity and then allows any user to boot the operating system. A BitLocker-protected system will not load if it has been removed from its native hardware, or if its boot files have been modified. This level of protection is helpful, but an unauthorized user still could access data on the drive if they have physical access to the entire workstation (i.e. if the BitLocker-protected laptop computer is stolen, rather than just its hard drive). In order to properly protect the encrypted drive data, you must add supplemental protection either by requiring input of a PIN number or presence of a USB key at boot time. These supplemental protections make loading the OS a two-factor process. You must possess both the BitLocker-protected computer and its USB decryption device or you must have knowledge of the decryption PIN.
Note that BitLocker only protects the operating system volume. Additional volumes cannot be encrypted by BitLocker, and so use of either EFS or a third-party encryption program will be required if there is a need to store sensitive data on multiple partitions.
Before we can recommend or support BitLocker in the enterprise, we need to answer the following questions:
- Will BitLocker impose enough of a performance penalty on older systems that we do not want to restrict its use to current-generation systems?
- Will the hardware requirements of BitLocker makes its use impossible on legacy computers?
- What is the recovery model for lost volume encryption keys? If a user loses his BitLocker USB key, his system will become unusable. A Key Escrow will be required to permit system recovery in these instances. According to BitLocker documentation, this Escrow is integrated into the product, but we will want to test the recovery process in several scenarios to ensure supportability.
- Given that BitLocker only protects the system volume and not the entire hard drive, is this an adequate technology? Most client systems deployed at UVM have only a single partition, so this product limitation is of no consequence. However, we will want to make sure that this will not be a problem for a significant portion of our clients, and have workarounds available of any staff who need them.
A fair high-level overview of the technology from Wikipedia:
A more in-depth presentation is available on Microsoft TechNet:
A step-by-step implementation also is available on TechNet:
Volume Licensing and Product Activation
With Windows XP, Microsoft introduced the anti-piracy program known as “Windows Product Activation”. To the great relief of system administrators everywhere, Volume License customers were not required to perform product activation. With Vista, this has changed. UVM will be required to activate all institutionally-owned installs of Vista from a central pool of activations. Microsoft has made two methods of Vista product activation available to volume customers: Multiple Activation Keys (MAK) and the Key Management Service (KMS). Most organizations will need to use a combination of these methods. It appears that we will want to use both methods as UVM as well.
MAK activation is similar to the product activation methodology used in retail versions of XP. The only difference is that the product key entered to allow activation can be used on more than one system. MAK activation has the advantage of being one-time and permanent (you only need to key in the MAK into the Vista client once during the lifetime of the OS). If we use MAK activation, we will need to closely guard our keys from casual distribution. Any leak of our keys could cause rapid depletion of remaining available activations and a good deal of hassle in reactivating invalidated products. Microsoft recommends that we never publically disclose the MAK to end-users, and has made a variety of tools available to allow organizations to remotely activate managed systems. We do not yet have access to these tools, and will need time to test them before they can be implemented in production.
If we choose to use KMS activation, we will need to install redundant KMS servers on campus and secure them. Because KMS is designed to be a lightweight, easy-to-use service, it will activate any volume-licensed Vista client on the KMS network. The advantage of KMS is that it requires intervention neither from the Vista client nor from the KMS administrator to function. KMS activations are non-perpetual and will expire if a Vista client fails to check in for a six-month period. This has the advantage of allowing the organization to reclaim activations for systems that have left our management jurisdiction without intervention from Microsoft. It has the disadvantage that the KMS service is non-discriminatory; recall that KMS will activate any non-activated Vista client, even non-authorized privately-owned systems. Thus, we will need to design a mechanism external to the KMS to limit access to the service to only those clients who are entitled to it. We are just at the starting stages of planning this service, and do not have any coherent thoughts on how we might accomplish these service restrictions at this time.
Vista Volume Activation Step-by-Step Guide:
Vista Volume Activation FAQ:
Webcast on Volume Activation in Higher Education environments:
All editions of Vista ship with the IPv6 protocol activated by default. Microsoft engineers want to make sure that Vista users will be prepared for an IPv6-based Internet if and when IPv4 starts to get phased out. Although the presence of the IPv6 stack should not create any real issues for end users, it will create some additional load on campus DNS servers, and may slow network access in some unusual circumstances. Thus, we might want to consider deactivating IPv6 on the primary network interface of systems deployed at the University.
Application Compatibility Testing
Fundamental changes in the architecture of Windows Vista make application compatibility a much greater problem than it was with Windows XP. Many line-of-business applications used at UVM are not yet supported on Vista. Until all supported applications are validated on Vista, central IT support of the operating system will be limited.
ETS staff are maintaining a matrix of supported Windows software at UVM on the Sharepoint Active Directory site:
We will endeavor to keep this list up-to-date with application updates as they become available.
Vista has shipped with an impressive Business Desktop Deployment (BDD) guide, which includes a powerful Automated Installation Kit (AIK). One of the promises of these tools is the reduction of the number of images that need to be maintained by IT staff. This is an exciting prospect as ETS maintains a library of over 80 Windows XP system images at present. With this many images available, true image maintenance never really occurs.
Many questions need to be answered before ETS will be ready to perform customized installations of Vista. The remainder of this section will enumerate some of these questions, and some factors to be considered when answering them.
- Can additional MS (i.e. Office 2007) and third-party (i.e. Antivirus, VPN) products be added as components in the Windows System Image Manager (SIM)? If not, are these easy ways to automate the installation of additional software onto systems in the post-imaging process (i.e. using product installation command lines in the Unattended.XML file used by the Vista setup program)?
- How will we handle domain-joined vs. non-domain joined systems during image deployment? The new network deployment tool known as Windows Deployment Services (WDS) automatically creates domain computer accounts at system installation time. However, student systems are not joined to our CAMPUS domain, so this computer account never will be used. It’s presence in the Active Directory domain creates a management problem.
- How will we handle deployment of systems which are not entitled to use of our Vista Volume License media (i.e. Student-owned systems)? Can use easily deploy images based on Dell OEM media? Should we eschew imaging in favor of a scripted installation of after-market software followed by a “reseal” operation? Without answers to these questions, we will be blocked from re-imaging any student systems that are covered under a Volume License (i.e. all systems other than those maintained by the Business School).
- What software should be part of the standard configuration? Is this software currently Vista-compatible?
- How will we maintain security patches on managed systems? Our current patch management system for domain-joined computers (Windows Server Update Service, or WSUS) will not provide updates for Vista. To maintain Vista systems we will need to upgrade to WSUSv3, which currently is available only in beta. Another consideration is the need to provide updated drivers to Vista users. Although the array of out-of-box drivers included in Vista is impressive, users of older hardware will need supplemental drivers immediately after installation. Synchronizing these drivers into the WSUSv3 system will present an administrative challenge that we need to think through.
The Windows AIK contains extensive documentation on these topics, and is freely available for download at the Microsoft download site:
A more lightweight download is the Windows AIK users guide for Vista, RC1. Note that this is the pre-release documentation, and that it may contain differenced from the RTM documentation contained in the full AIK download:
Group Policy for Vista
With the release of a new operating system, we need to deploy new operating systems management tools. As we have previously mentioned, Vista has dozens of significant new features, many of which may need to be managed in our various Active Directory domains.
Fortunately, Microsoft already has released Vista Group Policy extensions (ADMX) which, after being imported into a Windows 2003 Active Directory infrastructure, will allow very granular management of Vista features. But as will all Group Policy changes, we will need to do extensive testing of all proposed management settings. Improper configuration of Group policy can result in the effective crippling of all systems in a domain.
A spreadsheet of ADMX Group Policy setting is available from the Microsoft download site:
Also, a Step-by-Step guide to the deployment of ADMX-based Group Policy setting can be found here: