With Windows 7 now released to manufacture and with licensing available for Software Assurance customers, the time is right for enterprise administrators to begin testing the new operating system in earnest.
For while Windows 7 itself is really a somewhat modest improvement over Windows Vista in terms of performance, features and security, the time is coming for most enterprises to consider a client upgrade to take best advantage of the latest technologies. Come October, Windows XP will celebrate its eighth birthday, and the aging OS is not the best choice out there for multicore systems and 64-bit architecture on the hardware side, nor is it best-suited for modern networking technologies such as IPv6, ISCSI or even wireless networking.
The most noticeable and compelling aspect of Windows 7 is undoubtedly the revamped Aero interface (which I first looked at in my review of the public beta). With the Aero Peek thumbnail-driven task bar blending access to dormant applications and background windows alike; new Jump Lists providing quick access to application-specific documents and history; and Libraries extending the scope of access beyond the computer and out to the network, a lot of applications and documents are now within the user’s reach with just a few clicks.
But GUI enhancements are not what will drive enterprise uptake of the new operating system.
For this audience, there are a number of features in Windows 7–including DirectAccess (remote access into the network leveraging IPv6) and BranchCache (local caching of files and sites)–that are designed to work with servers and domains upgraded to the latest version of Microsoft’s server line, Windows Server 2008 R2. eWEEK Labs will look at those kinds of features down the road in our “better together” testing of the two products in use in tandem. In the near future we’ll also look in more depth at the new Enterprise Search and the myriad virtualization options available for use with Windows 7.
For this review, however, I focused on some of the questions that arise early in an evaluation: Will the platform install on a relatively current stable of hardware? Can I upgrade to get there? Will it improve security on the desktop? Will it improve performance over the last version of Windows?
For those questions, the answers, respectively, are: yes, it depends, it depends and somewhat.
Microsoft provides two avenues to get to Windows 7: a custom installation and an upgrade installation. Most computers will need a custom installation, however because the opportunities for in-place upgrades will be few and far between.
For example, users moving to Windows 7 from Windows XP must go with a custom installation, as there is no direct upgrade option under any circumstances. Users moving from 32-bit Vista to 64-bit Windows 7 (or vice versa, if you have need to go that way) must also do a custom installation.
Only users moving from Vista to Windows 7 within the same architecture (32 bit to 32 bit or 64 bit to 64 bit) have the option to perform an in-place upgrade, and, even then, there are limits. This is because you cannot downshift across versions: If you currently have Vista Ultimate, you cannot upgrade to Win 7 Home Premium or Professional. You can go up–say, from Vista Home Premium to Windows 7 Ultimate–though. Also of note, you cannot move from Vista Ultimate to Windows 7 Enterprise. (Check out Walt Mossberg’s useful upgrade chart here.)
To perform custom installations, users will need to collect and reinstall all applications as part of the process. At the very least, I would advise that users put a Windows 7- or Windows Vista-compatible driver for the computer’s network adapter on a USB stick before beginning a custom install. Windows 7 will, however, keep all your data intact– the custom installation process collects the old operating system C: drive and saves it on the upgraded system in a folder called Windows.old.
In addition, Microsoft provides a link to the beta of Windows Upgrade Advisor, a program that scans the current system for incompatible programs and drivers. At the very least, users should expect their current anti-malware suites to have issues in Windows 7, so I would advise removing the application before upgrade–even if the Advisor reports the program only as a potential problem.
I tested both the 32-bit and 64-bit iterations of Windows 7 Ultimate against their Vista SP2 Ultimate counterparts on a pair of machines.
The first machine represents a common recent-model laptop similar to those used in businesses both large and small today: a Dell XPS M1330 with 3GB of RAM, a 2.6GHz Core2Duo T9500 processor, a 160GB hard drive and an NVidia M8400 Graphics chip. The other system I used represents a much higher-end desktop: a home-built 3.0GHz quad-core Phenom II 945 with 4GB of 1066 DDR3 RAM, a 1TB hard disk and an ATI Radeon HD 4870 X2 video card.
At least from an optical media source, Windows 7 streamlined the clean install process over that provided by Windows Vista. I measured this process from first boot from the DVD to when a user could log in and interact with the client hardware system. On the Dell laptop, 32-bit Windows 7 installation took 21 minutes, compared with 32 minutes for Vista SP2; 64-bit Windows 7 took 28 minutes to install compared with 30 minutes for Vista x64.
On the desktop, installation proved fast in all instances, with Windows 7 again providing the best times. Windows 7 scored 15 minutes for 32-bit Windows 7 installation and 18 minutes for 64-bit Windows 7 installation. Vista 32 bit and 64 bit installation timed at 18 and 19 minutes, respectively.
These times reflect clean installs, but I found times for custom installs over old operating systems to be in the same ball park. On the other hand, an in-place upgrade to Windows 7 from Vista will take much more time–my two trials have taken between 45 minutes and an hour each.
It appears that some of the disparity between Windows 7 and Vista SP2 here is due to a bit of a cheat on Windows 7’s part when it comes to evaluating system performance during installation. Vista takes several minutes to run a comprehensive system performance evaluation, while Windows 7 may look only at the video subsystem performance. To wit, Windows 7 won’t have a Windows Experience Index score to present to users, whereas Vista will try to accumulate the score during the installation.
On both of my test systems, plus several others on which I have installed Windows 7 RTM (including Lenovo T60p and X61 laptops), driver availability for recent-model systems (3 years old or younger) was surprisingly good with just the installation media–and even better upon first connection to Windows Update. On all four systems mentioned above, the only device that could not obtain a driver in this manner was a wireless WAN card in one of the laptops.
However, the functioning of the drivers was still a little dicey in some cases. With the Lenovo X61, for example, the 64-bit Win7 video driver for the laptop’s Intel 965 chipset adapter technically worked, but only with a lot of tinkering–particularly with an external monitor attached to the laptop’s VGA connector. In this case, getting the external monitor to the maximum supported resolution required me to periodically re-adjust the monitor refresh rate.
I expect Windows 7’s driver support and performance to improve significantly before the operating system’s official mid-October launch. However, don’t expect legacy support for older devices to magically appear. If a vendor never created a driver that worked well with Vista, don’t expect one to show up for Windows 7.
Windows 7 provides a number of new security options, yet, perversely, many users could potentially have worse base security with the new OS than they did with Vista.
The most compelling security features–application whitelisting and encryption of both full disks and removable drives–are not included with the Professional and Home Premium editions that many will use at work and at home. And, in concessions to user outcry, Microsoft in Windows 7 has scaled back some of the security that was first introduced with Vista.
User Account Controls, or UAC, was probably the most reviled feature of Windows Vista: Users had to become accustomed to acknowledging every system change made to the computer, including application installations, patch installations, and access to system tools such as Computer Management or the network adapter settings.
This acknowledgement was necessary because in Vista the user does not operate day-to-day as an administrator (even if he or she has administrator rights). When performing an administrative action, the UAC prompt bumps up user credentials to admin levels to perform only that task.
Windows 7 keeps UAC in place, but implements a number of changes in an effort to make the alerting and acknowledging system more palatable to users and administrators alike.
The new OS introduces levels of enforcement to UAC, presented via a Settings panel with a slider bar that can easily move the user between four different modes of enforcement.
At the strictest level–analogous to how UAC worked in Windows Vista-the system will always prompt the user when changes are made to system settings or when installed applications try to access restricted parts of the file system.
Windows 7’s default level, however, notifies the user when applications try to make changes, but not when the user does. An easy way to experience the difference is by accessing Computer Management. In the strict mode, the user must acknowledge (or approve) to even view the panel, while in the default mode an administrative user can go right in and start changing things.
The third mode is similar to the default, but doesn’t require the use of the Secure Desktop–the isolated interface that otherwise appears to the user and can’t be tampered with by a program. The fourth mode, meanwhile, never notifies the user or asks for approval. This mode is recommended for use only when accessing a program known to founder under UAC purview.
In truth, the new settings–including the new default–serve to worsen the security protections UAC affords. I’ve turned UAC in Windows 7 up to the Vista-like maximum on my machine.
An interesting complement to UAC is available to Windows 7 Ultimate and Enterprise customers. Called AppLocker (a descendant of XP and Vista’s Software Restrictions Policies), this feature provides application whitelisting–specific authorization for applications to run on a computer. A user or an administrator creates a policy that allows only authorized applications to run at all, and all others (whether malware or simply unapproved code) will not be able to start.
Control over AppLocker policies resides within Microsoft’s familiar Group Policy architecture. Using the Group Policy editor, I could view existing policies, create new ones, and decide whether to enforce the policies or simply audit them to find out whether people were using applications that could run afoul of the new security.
According to AppLocker, there are three categories of executable code (windows executables, Windows installers and scripts), and each must be configured separately. I could choose enforcement for one classification and audit-only for another.
Applications can be approved in several different ways. For granular application identification, I could base policy on an application’s hash (best for uncertified applications), on an application’s publisher (for signed applications) or on the file system path to the executable–either the file or the folder.
Windows 7 makes it easy to get started because the Group Policy editor includes a couple of simple ways to generate rules. I could create default rules with one click, creating basic rules: allowing everyone to run programs located in the Windows and Program Files directories, and allowing local Administrators to run all files.
This usage scenario makes an interesting companion to UAC and least-privilege computing. If AppLocker means a limited-rights user can run only programs found in permitted folders, and a tight UAC implementation bars users from writing to those folders, then it becomes difficult to use social engineering to trick someone into mistakenly installing bad or unwanted code.
For more granular controls, administrators can automatically generate rules. For example, I could specify a folder (such as Program Files), and a wizard would identify all executable content of the appropriate type, basing the policy either on a hash or on the path. I could further limit the scope of the policy by allowing only digitally signed executables.
These kinds of granular rules are more effective and restrictive, but keep in mind that they will require much more maintenance, as patching or upgrades will necessitate a refresh of policy settings.
One potential problem with AppLocker is that it requires one special service to be running to provide enforcement–the Application Identity service. First of all, administrators must make sure that the service starts automatically, and then they must make sure the service continues running. Often, security providers provide additional watchdog protections to ensure that a critical security service stays up in the face of attack, but I’m not sure Windows takes those measures. It is not noticeable when the service is not active but AppLocker policies are present.
Windows 7 adds removable disk encryption capabilities to the most expensive editions–Ultimate and Enterprise. Called BitLocker To Go, the utility builds encryption and key management into the USB drive itself, allowing easy sharing of protected data with other Windows 7 instances. Users need only enter the password they specified when they first encrypted the drive.
BitLocker To Go-protected drives can also be accessed on older versions of Windows, as the utility includes a reader on the USB stick itself. When inserted into an Windows XP- or Vista-based system, the drive shows the reader to the user. Run the reader, enter the protection password, and you can read the data or copy it locally. When inserted in a Mac, on the other hand, you see dozens of files, but you can’t access the protected content or manipulate the visible files.
As with Vista, Windows 7 Enterprise and Ultimate come with BitLocker full-disk encryption. BitLocker is a little easier to use on Windows 7, however. Specifically, Vista required planning for BitLocker right at the time of OS installation because a separate boot partition was needed. Windows 7 builds the boot partition automatically and slims it down (to 100MB in Windows 7 from 1.5GB in Vista). This allows users or administrators to add full-disk encryption well after initial installation without complications.
By default, BitLocker requires that the computer have an onboard TPM (Trusted Platform Module) chip in which to store the encryption keys. Users without a TPM chip can opt to use a USB stick instead, but that will necessitate some changes in Group Policy.
I tested BitLocker on the Lenovo T60p using the laptop’s TPM chip, as well as on the Dell XPS M1330 using a USB stick for the key. Depending on the size of the hard drive and the amount of data that needs to be protected, encryption can take several hours. It took just under an hour to protect my relatively data-free test machine and more than three hours to encrypt a half full 80GB disk. Thankfully, the encryption process can be paused midstream to accommodate a system reboot and will resume after the next boot.
Enterprise administrators will find solid controls over both BitLocker and BitLocker To Go in Group Policy that can be distributed throughout the domain. Administrators can control cipher strength, enforce authentication types and strength, and store recovery keys within Active Directory.
In one detail of note, I found that users running Windows 7 in a virtual machine will have trouble enabling BitLocker disk encryption. (I tried this out in VMWare Workstation 6.5, in my case.) Specifically, the hypervisor would not virtualize the TPM chip, and the OS could not recognize a USB stick early enough in the boot process to work for BitLocker. Those who want to protect data within a VM running on Windows 7 should probably look into file or folder encryption instead of full-disk protection.
With Windows 7, no longer will administrators need boot media to attempt to recover a distressed or broken Windows instance, as the new OS features a Recovery Console that is accessible simply by pressing F8 upon boot.
During tests, I found that the recovery options differed significantly for administrators and limited rights users.
As a limited rights user, I was able to kick off a diagnostic scan called StartUp Repair that automatically looks at the validity of the file system, the hard disk and the registry, then, as a last resort, offers to let the user recover to the last System Restore checkpoint.
Local administrators, on the other hand, are presented with several options. They can autofix the same problems scanned in StartUp repair, select from all available System Restore checkpoints, perform a system Image Recovery, run memory diagnostics or access the command prompt.
The command prompt lay at the heart of an irregularity I found with credentials for the Recovery Console. In tests, I found that I could log into the console as the default local administrator, but only when no other local administrator accounts are present. The problem is that, by default, the local administrator account has no password. This isn’t a problem in Windows proper, as the account is disabled by default, but in these specific instances, the account suddenly activates.
With access granted via the disabled, no-password administrator account, I found I could easily access the command line and copy any data at all on the main partition to a USB stick.
One of the biggest knocks against Windows Vista was that it was a resource hog. Although this abated somewhat as Vista evolved through Service Packs 1 and 2, the perception was common that the operating system used too much RAM by default and took too long to startup and (especially) to shut down.
To see whether Microsoft gave Windows 7 a speed bump, I ran a series of benchmarks against the 32-bit and 64-bit iterations of both Windows 7 and Vista, using both the Dell laptop and Phenom II-based systems described earlier in this review.
With each installation of Windows 7 and Windows Vista, I relied almost exclusively on drivers included with the operating system install disk or via Microsoft Updates. The sole exception: I obtained drivers from Dell and ati.adm.com for the video adapters on both machines. Tests were otherwise conducted on base installations, as no additional software (save the benchmark suite and its dependencies) or operating system patches were installed.
Benchmarks were performed using the latest version of FutureMark’s PCMark Vantage Professional suite, which performs a variety of tests on a system’s ability to record, play back and edit various types of audio and video media, as well as its ability to process large amounts of text and to quickly render Websites–among many other modern usage scenarios.
I used the 32-bit version of PCMark Vantage to test the 32-bit Windows 7 and Vista SP2 iterations and the 64-bit version of the test suite to evaluate the 64-bit systems.
The PCMark score is an aggregate number, reflecting performance on a subset of the tests that make up each of the comprehensive test suites, including Memories, TV and Movies, Gaming, Music, Communications, Productivity, and HDD hard drive tests.
The breakdown of the complete results can be found in this slideshow.
Of the aggregate PCMark scores, Windows 7 scored better across the board. In 32-bit tests, Windows 7 showed a negligible 2.6 percent improvement over Vista SP2 on the laptop (Vista 3,603, Win7 3,698), but a whopping 15.1 percent improvement on the quad-core desktop (Vista 6,096, Win7 7,018). While further testing is necessary to bear this out, the disparity suggests that Windows 7 more efficiently utilizes 32-bit systems at the RAM ceiling for the architecture.
In the 64-bit tests, Windows 7 showed an 13.6 percent increase over Vista on the laptop (Vista 3,679, Win 7 4,183) and an 8.7 percent improvement on the desktop (Vista 6703, Win 7 7284).
Senior Analyst Andrew Garcia can be reached at firstname.lastname@example.org.