By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The good news is that, for the most part, Windows Vista has been designed to integrate into an existing Active Directory network; there's no need to wait for the release of Windows Server 2008 to be able to deploy Vista to your users as a whole. However, here are some issues of interest for IT administrators:
Other changes will have a more direct effect on your user population as a whole. Here are some issues you need to be aware of, including additional tools and services information to improve the management of your Vista clients:
Administrative tools for Windows Server 2003. At the moment, there is not a Vista-compliant version of the familiar adminpak.msi MSI installer, which installs MMC snap-ins such as Active Directory Users and Computers, AD Domains and Trusts and AD Sites and Services. The default installation of these tools, though, doesn't function on Windows Vista. Shortcuts to the tools don't appear on the Start Menu, and attempting to load one of the snap-ins manually produces an error. Until there is a new version of these tools, the only way to administer a 2003 Active Directory network from a Vista client is to manually register the DLLs associated with the adminpak tools. This is a somewhat lengthy process, but it has been well-documented in the following Microsoft KB article about running Windows Server 2003 management tools on a Vista-based computer. Administrative tools for Microsoft Exchange. Even worse news is the fact that admin tools for Exchange 2003 and even for the new Exchange 2007 are not supported on a Microsoft Vista client at present. If you are administering an Exchange environment, for example, you'll need to retain a Windows XP workstation to run the Exchange admin tools until there is a Vista-compliant version of the 2003 and 2007 tools. A brand-new activation model. As part of the ongoing attempt to battle software piracy, Microsoft has completely overhauled the software activation model within Windows Vista. Companies will now require a Key Management Service (KMS) to manage volume software licensing for any network larger than 25 workstations.
However, this new activation model won't apply to any OEM-licensed software such as an HP or Dell machine that's been pre-loaded with Vista by the manufacturer. Neither does it apply to copies of Vista that you might buy shrink-wrapped from a software retailer. You can learn more about the Volume Activation process, which is a step-by-step guide on the Microsoft Web site.
Windows Vista is the first new client operating system to be released by Microsoft in several years, and planning for a large-scale upgrade can be an involved process. Luckily, for the most part, Vista is capable of integrating into existing Active Directory environments. Although the integration process will not be invisible, particularly from the standpoint of an IT manager, with careful planning you can minimize the visible effects that it will have on your user population as a whole.
No drive mappings for admins? If you have one or more login scripts that map network drives for your users, you may find yourself in a situation where Vista clients are no longer receiving the appropriate drive mappings while Windows XP clients are functioning normally. You'll usually see this behavior when your end users are running as administrators on their local workstations.
If you remove the users' administrative privileges, login scripts will begin to function just fine. This occurs because of the new least-privilege model in Windows Vista, the same privilege model that brought us User Account Control (UAC.) The current solution for this is to use launchapp.wsf from the Microsoft Web site, to launch your login scripts.
The good news here is that you don't actually need to change your existing scripts: If you have an existing script called login.vbs, you can create a "wrapper script" to use WMI to check if the target workstation is running Vista, and then run cscript launchapp.wsf login.vbs. (A better solution still would be to limit the number of users who are running as local administrators on their workstations. That creates a much more secure environment for your user base as a whole.)
Vista network security. One of the security enhancements of Vista allows you to manage 802.1X connections via Group Policy, but to enable these security settings you must modify the Active Directory schema. Once that's done, create and modify the necessary Group Policy Objects from a Windows Vista computer that's been joined to your domain. You can find instructions to create the correct LDIFDE file on the TechNet Web site. Device and application compatibility. Though you've heard it before, this bears repeating anytime you plan a large-scale desktop deployment: Windows Vista is a significant upgrade to the desktop operating system, which means that your existing hardware and desktop applications need to be evaluated to ensure that they will continue to function. In particular, older versions of many commercial software packages, including Microsoft Office and many antivirus and security suites, may not function under Vista without an upgrade to the latest version of the software. Likewise, take a detailed inventory of peripheral devices like printers, scanners and other USB devices and make sure there are Vista-compatible drivers available for them.
Laura E. Hunter (CISSP, MCSE: Security, MCDBA, Microsoft MVP) is an Active Directory architect for a major engineering and staffing firm where she provides Active Directory planning, implementation and troubleshooting services for business units and schools across enterprise networks. Hunter is a four-time recipient of the prestigious Microsoft Most Valuable Professional award in the area of Windows Server-Networking. She is the author of Active Directory Field Guide (Apress Publishing) as well as co-author of the Active Directory Cookbook, Second Edition (O'Reilly). You can contact her at firstname.lastname@example.org.