June 2008 June 2008
Security: The Great Debate: Security by Obscurity
Security by obscurity involves taking measures that don't remove an attack vector but instead conceal it. Some argue that this is a bad practice while others claim that as part of a larger strategy, every bit counts. The debate is quite heated, and some of our finest security experts face off, explaining security by obscurity and presenting both sides of the debate. Jesper M. Johansson and Roger Grimes
Security: New Elevation PowerToys for Windows Vista
Michael Murgolo is back with an update to his Elevation PowerToys. You'll find enhanced Run as Administrator functionality that works with third-party scripting tools, a way to replace a handy Windows XP feature removed from Windows Vista, and many more useful tools. Michael Murgolo
Security: Advances in BitLocker Drive Encryption
Windows Vista SP1 and Windows Server 2008 introduce important changes to BitLocker, including support for data volumes and improved protection against cryptographic attacks. Byron Hynes explores the new features, demonstrates how to use BitLocker on a server, and discusses some of the recent media coverage affecting BitLocker. Byron Hynes
Security: Application Lockdown with Software Restriction Policies
When you want to reduce the total cost of ownership of the desktop machines in your organization, application lockdown can be a great help, letting you limit IT issues related to unsupported applications. See how you can use software restriction policies and Group Policy to control the applications being run throughout your IT infrastructure. Chris Corio and Durga Prasad Sayana
Security: Managing the Windows Vista Firewall
The recent update to the Windows Vista Firewall offers some impressive new features that make it a compelling choice for the corporate environment. Jesper M. Johansson gives a brief overview of the evolution of the Windows Firewall and delves into enhancements—such as new rules and profiles, domain isolation, and encryption—that will have administrators taking a closer look. Jesper M. Johansson
Security: Secure E-Mail Using Digital Certificates
Secure Multi-Purpose Internet Mail Extensions let you hide information in transit, validate senders, and authenticate messages. Learn how to secure e-mail using digital certificates and how to troubleshoot problems you may encounter on your S/MIME system. Matt Clapham and Blake Hutchinson
Columns
From the Editor: The Great Debate: | Letters: Readers Speak Out: | Toolbox: New Products for IT Pros:
Windows Vista: Top Security Features in Windows Vista: Why should you upgrade to Windows Vista? Among many reasons, the new security features make it a must-have. This article explores some of the major security features introduced in Windows Vista.Anthony (A.J.) Smith and Ned Gnichtel | Sustainable Computing: Learning from the Quincy Datacenter: The Microsoft datacenter located in Quincy, WA is powered entirely by hydroelectricity. Dave Ohara takes you on a tour of this facility and shares some best practices from the Microsoft datacenter team for building and operating a sustainable datacenter.Dave Ohara | SQL Q&A: I/O Errors, Database Mirroring, and More: Paul Randal answers your SQL Server questions, showing you how to create corruption in a test database, helping you avoid a shrink-grow-shrink-grow cycle, and explaining how you can determine how many databases you can mirror before performance starts to degrade.Paul S. Randal
Utility Spotlight: Windows Vista Upgrade Advisor: Ready to upgrade the systems in your organization to Windows Vista? Find out how the Windows Vista Upgrade Advisor can help you determine whether your systems are ready for Windows Vista and which versions they can support.Lance Whitney | Inside Sharepoint: Decentralizing Site Administration: Explore the advantages and implications of delegating administrative control over SharePoint sites to individual departments while maintaining centralized administrative control over the SharePoint infrastructure.Pav Cherny | Windows PowerShell: Looking Good: Discover how the object-oriented nature of Windows PowerShell allows you to apply formatting to its output.Don Jones
Hey, Scripting Guy!: Not-So-Hard Work Has Its Rewards, Too: The Scripting Guys ponder hard work, true happiness, and outputting data to the command window in a readable tabular format.The Microsoft Scripting Guys | The Desktop Files: Security vs. Compliance: IT professionals often find themselves with objectives that contradict one another. Take a look at how being compliant often comes at the expense of being less secure.Wes Miller | The Business of IT: 10 Keys to Becoming an Environmental Leader: As IT departments play an increasingly important role in corporate environmental efforts, IT professionals are finding an opportunity to drive change and become thought leaders in their companies and industries. Here's an overview to becoming an effective thought leader for environmental and sustainability initiatives in your organization.Michael Walsh and Eliza Walsh
Field Notes: Sharing a Split Screen: Developed by Microsoft Research India, Split Screen allows two users to share a monitor while running separate instances of the OS on each side.Kentaro Toyama | Windows Confidential: The Two Worst PCs Ever: Raymond Chen fondly reminisces about working with the two worst computers ever made.Raymond Chen


Security
The Great Debate: Security by Obscurity
Jesper M. Johansson and Roger Grimes
At a Glance:
  • Defining security by obscurity
  • Evaluating security by obscurity measures
  • Assessing the value of renaming the Administrator account
  • Making informed risk-management decisions

The term "security by obscurity" is often met with derision from security people, particularly those who like to consider themselves experts. Nearly akin to a four-letter word in some circles, security
by obscurity, as noted on Wikipedia (en.wikipedia.org/wiki/Security_through_obscurity), represents one of the truly controversial aspects of security. You will often see mocking references to people whose efforts are dismissed as "just security by obscurity."
Security by obscurity is, in a nutshell, a violation of Kerckhoffs' Principle, which holds that a system should be secure because of its design, not because the design is unknown to an adversary. The basic premise of Kerckhoffs' Principle is that secrets don't remain secret for very long.
As a very good example, take the Windows NT® LAN Manager (NTLM) authentication protocol, which was initially considered a design secret. In order to implement the Samba interoperability product for UNIX-based operating systems, the Samba team had to reverse engineer the protocol. The result was the most comprehensive documentation on NTLM available (monyo.com/technical/samba/translation/ntlm.en.html) as well as the discovery of a number of bugs. Because so much of security grew out of cryptography, and so many secret designs have been revealed, many security practitioners believe all of Information Security should follow Kerckhoffs' Principle.
But is security by obscurity always bad? In this article, we will explain what security by obscurity is, attempt to shed some light on why many consider it a waste of time (and others don't), and show you why the answer, as usual, is far more complicated than it seems at first.

Introduction to Security by Obscurity
Security by obscurity does not include measures that do absolutely nothing to mitigate a problem. For example, an organization that blocks Network News Transfer Protocol (NNTP) at the border routers to prevent employees from reading newsgroups but permits outbound Secure Shell (SSH) is not engaging in security by obscurity. Since SSH can tunnel every protocol, the problem is not obscured; the silly mitigation that was implemented fails to do anything other than prevent legitimate users from accomplishing legitimate tasks without violating security policies. Such measures are not security by obscurity; they are just silly and pointless.
As the word "security" in the phrase "security by obscurity" implies, you do get some protection out of the measure. However, what is also implied—and this is the problem—is that you are not actually doing anything to stop an attack on one or more vectors. (An attack vector is essentially a means by which an attacker can access a system.)
Suppose you have a vulnerable Web server, for example, that can be attacked over TCP port 80 using a public exploit. To close that particular vector, you can patch the Web server or you can turn it off; either action would completely stop this vector. You could partially stop the attack vector by using a firewall or IPsec to close port 80 to all but a few select computers. This wouldn't completely block the attack vector, but it would significantly mitigate the problem.
Security by obscurity, on the other hand, involves taking some measure that does not stop the attack vector but merely conceals it. For example, you may decide to move the Web server to port 81 instead of 80 so only those who know where to find your Web server will be able to do so. Or so that argument goes. In reality, moving your Web server to port 81 stops only some attacks, and mostly just inconveniences the end user. A competent intruder would simply run a port scanner and a Web banner grabber against a large number of ports to discover Web servers on non-standard ports. As soon as he finds one, he can fire off the exploit against your server because you did not actually eliminate the attack vector, you merely (temporarily) obscured it.
Does this mean you should not even try? The answer is that it depends. As with everything else in the Information Security field, it all comes down to risk management. To understand the key factors to consider, we will take a quick look at a few more security by obscurity measures and then discuss one—renaming the Administrator account—in more detail.

Assessing Security Measures
Examples of security by obscurity abound. They may be actions that system and network managers take, or they may be initiated by software developers. What they all have in common, however, is that they intend to mitigate a vulnerability by hiding it from potential attackers.
Might not some of these procedures have at least some beneficial effect? Is it truly fair to say that all security by obscurity is bad? You will certainly find proponents of at least some of these measures. For example, in Windows® it is possible to hide drive letters in Windows Explorer. Many environments, most notably school computer labs, use this technique to keep users from saving data to the hard drive. Of course, most applications can still save data to the hard drive, so it provides little value as an ultimate security measure. However, the institutions that have implemented it often claim it reduces data on the hard drive.
Another type of security by obscurity practice often implemented on Windows is turning off the administrative network shares (such as C$, Admin$, and so forth). This is thought to keep an attacker from being able to connect to the computer remotely. In reality, this is not only not true, but an attacker who has an account that can use the administrative shares can remotely re-enable those very same shares. Yet many organizations swear that disabling these shares reduces the incidences of malware on their networks.
One of our favorite examples of misplaced effort is the "Allow undock without having to log on" setting in Windows. If this is set to disabled, the "undock computer" button is hidden from the logon screen. The idea behind this is that this way an attacker cannot gracefully undock the computer. Of course, any intruder can simply stuff both the computer and the docking station into a bag and walk off with them, whether or not that button is visible. This possibility is marginally not even security by obscurity.
Another clear example is the "Allow Server Operators to schedule tasks" setting, which, exactly as it states, permits users who are members of the Server Operators group to schedule tasks. This is a sensitive issue because such tasks may run as Local System, and only administrators should be able to schedule tasks that run as Local System. Of course, server operators can potentially make themselves administrators through any number of different vectors, so preventing them from scheduling tasks in this manner actually has minimal value.
Yet many organizations like this setting because it allows their engineers to be server operators instead of administrators, which means they are less likely to accidentally destroy the server. That, in and of itself, may carry some benefit.
So what's the verdict? Obviously, some of these issues can be very complicated. We have spent many enjoyable hours debating these types of measures. Roger is firmly in the camp that finds value in such practices. Jesper, on the other hand, believes they are, at best, a waste of time in most cases. Let's explore one of the most often cited—and disputed—cases for security by obscurity: renaming the Administrator account. Roger will argue for the measure, Jesper against. Security notables Aaron Margosis and Steve Riley also weigh in, in the sidebars "Rename the Administrator Account" and "Don't Change Defaults," respectively.

Hiding the Administrator Account
Renaming the Administrator account, relative identifier (RID) 500, to something unknown by the general public is often recommended by security professionals and is included in several Microsoft hardening guides. Group Policy even includes a setting for renaming the Administrator account, as shown in Figure 1. The idea is that if the Administrator account is renamed, an attacker will have a more difficult time logging in as the true administrator. Of course, the obvious problem with using Group Policy for this operation is that the renamed Administrator account will have the same name on every computer to which this Group Policy object was applied. That lessens the obscurity value of this particular security measure.
Figure 1 Renaming the Administrator account
Figure 1 Renaming the Administrator account
It is also important in this context to realize that any user with a legitimate account can retrieve the name of the Administrator account, regardless of whether it has been renamed or not. The Administrator account always has a RID of 500. By simply asking for the name of the account with RID 500, any user with an account can see what it is really called, as shown in Figure 2.
Figure 2 Finding renamed Administrator accounts
Figure 2 Finding renamed Administrator accounts

Roger's Take
The main argument I hear against renaming the Administrator account is that it is so easy to convert any security principal account name into its related security identifier (SID) and find out its RID. And the true Administrator account always has a RID of 500. So, if an attacker can easily convert user account names into the SID/RID combinations and find RID 500, why bother?
But it's not so simple. In order to accomplish user account name-to-SID/RID translations, you must have access to either the NetBIOS or LDAP ports. Most perimeter fire walls don't allow that type of access over the Internet, so until the attacker completely bypasses the firewall, he won't be translating anything. Furthermore, anonymous SID translations don't work against Windows XP and later versions of Windows, except on domain controllers (DCs). Against most externally facing computers (the ones most at risk), the attacker would need authenticated credentials to do name-to-SID translations.
So there are a fair number of real defense-in-depth hurdles that have to be bypassed in order to begin a translation attack. And even if the attacker gets this far, he ends up in the same spot he'd be in if the account name wasn't renamed. Renaming the Administrator account can only improve security. It certainly can't hurt it.
It's Another Secret If an attacker does not know the Administrator account name, it becomes yet another "secret" label, analogous to a password, which an attacker has to know. Granted, user account names are significantly less likely to be as complex as an administrative password, but it's still one more hurdle that exponentially complicates the problem of password guessing/cracking. If you've ever done password penetration testing, you already know how much more work it is to have to guess both the user name and the password. It compounds an already difficult task and makes it that much more difficult.
Thwarts Automated Malware and Script Kiddies I've been practicing Windows security defense for 22 years now, and I've been running eight Windows honeypots, exposed to the Internet, for the past 5 years. In all of that time, I've never seen automated malware (which comprises the vast majority of all attacks) ever use any user account label except Administrator (or root, in the case of *NIX systems). If you rename your Administrator account, you immediately kill all malware that relies on the administrator name. And that translates to decreased security risk.
The same goes for script kiddies. Every "kewl" Windows hacking manual I know mentions name-to-SID translation techniques, but for some reason, I've never seen a case of it on my honeypots if I've also had a "fake" Administrator account to throw them off. Good hackers should always verify that the Administrator account they found is the real Administrator (RID 500), but they don't. I don't know why. I blame it on lazy hackers and ordinary human behavior.
Stops Most Professionals, Too This surprises most people. When you've been running honeypots for a few years, you quickly recognize the difference between automated attacks, script kiddies, and professionals. In the past five years, with millions of reported attacks against my honeypots, I've never seen the professionals do SID translation when the fake Administrator account was present.
I'm sure some of the professional criminals do undertake SID translation, but I'm willing to bet that's a small minority, and one I've never documented in the wild. Why wouldn't the professionals do it? I'm guessing that they don't see any reason to try something when the majority of the world isn't doing it.
Simplifies Alerting Now, the other side may contend that if renaming the Administrator account became prevalent, it would lose its value as an obscurity technique. The argument is that malware, script kiddies, and professionals would change their default tactics to look for names other than just Administrator. And this is a valid concern. Fortunately, it doesn't change the essential condition. First, if the Windows super-privileged account isn't named Administrator, the malicious hacker must work harder. That's just a fact. And if the malicious hacker has to work harder, he is a little less likely to try that avenue of attack, perhaps allowing one of the other offsetting defense-in-depth techniques to detect the malicious activity faster.
And that leads me to my last point in favor of renaming. If your Administrator account is never called Administrator, and you create another account with that name, as shown in Figure 3, you have a good alerting mechanism. If your event monitoring detects an attempted logon using the default name, it is an event to be immediately explored.
Figure 3 Log in attempts to a decoy account named Administrator can serve as an early warning
Figure 3 Log in attempts to a decoy account named Administrator can serve as an early warning
Our event logs are full of "bad" logons that don't mean anything. Typically, it's just a user (or Windows) trying to log on using a bad password or something like that. If your Administrator account is called Administrator, though, how can you easily separate good from malicious logon attempts? If you never have a logon account called Administrator, and you detect an attempted logon using that account name, you know the intent is probably malicious. Early warning with low noise has much value in today's defense.

Don't Change Defaults by Steve Riley
I'm on the "don't change" side of the renaming issue. This really isn't even a security matter—it's a systems management issue. And as I spend more time thinking in the systems management space (because management and security are becoming one), I become more and more a fan of not doing anything that can potentially increase a system's brittleness. One sure-fire way to increase brittleness is to change things from defaults. There are two (well, OK, three) reasons people change default settings:
  • There is a known requirement for the functionality the change provides.
  • There is an assumption that the change will improve security.
  • (Alert: silliness ahead.) Someone read about it in a magazine article.
If you need to change from a default name because of reason number 1, go right ahead and do so. These kinds of changes rarely result in system instability, often because they have been previously tested.
If you are making a change from a default for reason number 2, please stop first and reconsider. These kinds of changes are almost never tested by the software manufacturer, and therefore the manufacturer can't predict how the system will behave after you've made the change. Furthermore, there are generally much better alternatives that will provide you with true security.
If a bad guy happens to know an account name, so what? It's the password, and the strength of that password, that keeps the bad guy out of your system. The urge to change default account names like Administrator and Guest to something not so easy to guess is often actually indicative of a desire to avoid strong passwords or passphrases. Fix the real problem (lousy secrets) and you can then avoid brittleness (changing default names).

Jesper's Turn
As with the arguments for, there are valid arguments against renaming the Administrator account. Before getting into that, however, I must concede that Roger's last point is quite valid. However, in a highly managed environment, any logon with the Administrator account should be investigated because that account should never be used other than in emergency recovery situations.
It's Superfluous The main risk that renaming the Administrator account is supposed to mitigate is that of someone guessing its password remotely. But only a user who does not have another authorized account on the computer would be thwarted by renaming the Administrator account. Such an attacker would typically try a series of random passwords to log into the Administrator account. However, such an attacker would receive the same error message regardless of whether he guessed the account name wrong or the password wrong.
That suggests that one of the primary arguments for renaming the Administrator account—that the script kiddies go away—is flawed. They do not go away any sooner when the Administrator account is renamed than when it has the original name because they can't tell! They will guess the same set of random passwords no matter what and then move on to the next potential victim.
This means that as long as the password on the Administrator account is strong enough to repel attacks, renaming the account provides no additional value. Let us say we have a 15-character password on our Administrator account, composed of upper- and lowercase letters, numbers, and symbols chosen from the entire keyboard. Guessing that password across the network will take roughly 591,310,404,907 years. By comparison, that is approximately 43 times longer than the universe has existed.
Now, let's say we rename the Administrator account, and we make it one of 1,000 possible values. We would extend the time to guess the password to 591,310,404,906,787 years, or 43,161 times longer than the universe has existed. Are we more secure? Sure, we are three orders of magnitude more secure. Did we make it any less likely that the attacker will guess our password? Well, it is infinitesimally small in either case. In other words, in real terms, we are absolutely no better off than with the original Administrator account name. Just because renaming the account kills malware that attempts to use it does not mean that malware would have been successful had you not renamed the account. In fact, if you use a strong password, as you should, you can virtually guarantee that it would not have been successful, regardless of the name of the account.
It is clear that much security guidance requires renaming the Administrator account; but that does not make it a valuable, or even valid, security measure. It simply removes your ability to make a proper risk management decision about it. Security guides have very frequently required settings that make no difference, and in many cases, settings that do not even exist. Eventually, to progress in the field of security, we must step above the requirements and actually analyze the issues, and assess whether the mitigations make sense or not. It is important to remember one critical point here—the fact that an attacker is targeting a feature is, in and of itself, not a sufficient enough reason to modify that feature. You should modify a feature only if you have a reasonable expectation that an attack will be successful unless you do modify the feature.
If we assume a strong password, the likelihood of success is effectively zero whether the account is renamed or not. Therefore, as long as you have a strong password, you have no particular security reason to rename the account. Moreover, if you, like me, operate on the principle that a computer will probably be more stable the fewer tweaks and changes you make to it (a well-established fact, by the way), that's even more reason not to rename the Administrator account.
Shifts Focus to Low-Value Mitigations One problem with low-value security by obscurity mitigations is that they risk shifting the organization's focus from higher-value mitigations. For example, the time and effort put into renaming the Administrator account can't be used on something else. If that something else provides higher value than renaming the Administrator accounts, the organization has lost an opportunity. This may not sound like a real cost, but imagine renaming 50,000 Administrator accounts, and you start to get the idea.
Worse still is the very real possibility that the organization's leadership will rest once the low-value mitigation is in place. Management may not always understand the minimal value provided by security by obscurity mitigations and may not take additional steps. This can actually pose a significant risk to the organization, though the risk is quite avoidable if management simply devotes time and effort to understanding the value of the mitigations being implemented.
Expensive to Manage Finally, depending on how well the mitigation is implemented, it can become quite expensive to manage. If you simply set a Group Policy Object (GPO) to rename the Administrator account, the cost is very low. Everyone will know the name, and the cost of deployment is nearly nil. However, the value it provides is also quite minimal because, as I said, everyone with an account will know what the name is. Thus, to really get much value out of this mitigation, you need to use different names on different hosts, and that becomes quite an expensive system to manage.
You would be far better off using a tool like passgen (protectyourwindowsnetwork.com/tools.htm) to set a 100-character completely random password on all the Administrator accounts across the network and use different accounts for day-to-day management instead. Considering that the Administrator account is purely for disaster recovery purposes (except on Windows Small Business Server 2003), this should not impact your network management system at all. Furthermore, the attacker would have a better chance of finding a needle on the bottom of the Pacific Ocean than correctly guessing the password on any of your Administrator accounts. By focusing on strong, unique passwords instead, the script kiddies can keep guessing all they want.

Rename the Administrator Account by Aaron Margosis
Jesper, in an ideal world you would be absolutely correct. Passwords would always be strong enough to make brute-force guessing infeasible, and -500 local admin accounts would only ever be used for emergency recovery. In the real world, though, neither is true.
Despite the great security evangelizing you have done, and in particular the terrific passphrase series you authored ("The Great Debates: Pass Phrases vs. Passwords," Parts 1, 2, and 3, at go.microsoft.com/fwlink/?LinkId=113157; go.microsoft.com/fwlink/?LinkId=113159; and go.microsoft.com/fwlink/?LinkId=113160), many sysadmins do not have an up-to-date understanding of what constitutes a strong password.
It wasn't very long ago that a password made up of eight random characters drawn from multiple character sets was strong; Moore's Law rendered that obsolete. User (and sysadmin) education is a weak link and most likely will remain so, at least until the topic of password strength becomes a hot item for the cable news channels to obsess about.
So, given that real-world password guessing today doesn't require 600 billion years and can instead often be done during lunch, adding a x1000 multiplier can have real value. And against the many automated attacks that try to pound on the account named Administrator, renaming the account renders it invulnerable.
The time and effort typically involved in renaming the admin account is usually low; typically, as you noted, it's a simple GPO setting. The U.S. Government's Federal Desktop Core Configuration (csrc.nist.gov/fdcc), in fact, requires renaming the -500 account. The rename is just one of many required settings and not one I've seen taking an inordinate amount of time or attention. Nor have I seen anyone lulled into a false sense of security regarding its value—I have yet to hear anyone say, "We don't need patch management because we renamed our admin accounts."
Does the rename have any value when the account is renamed the same across an entire organization? It's not a huge value, but there is some: for one, it blocks automated attacks that expect Administrator, and second, the set of potential attackers is not necessarily a subset of the "everyone" who knows the new name. (The bigger risk is when local admin accounts—renamed or not—share a common password across an organization. Managing those remains the bigger and more important problem. Disabling the -500 account is one way to address it, but this blocks an important recovery avenue when domain accounts can't be used.) I'll also point out that our security guides have long recommended renaming the default accounts, so doing so has been well tested and is fully supported.
I think we all know by now that obscurity measures—by themselves—do not constitute adequate defense. But they can enhance other security measures, and Roger's data shows that quite clearly. As long as the cost of implementation is low, organizations should not rule them out.

It's All about Risk Management
Virtually any security by obscurity measure can be analyzed the way we have here. There are pros and cons to any scheme, and the right approach for one organization does not necessarily fit a different organization. In the end, this becomes a risk management problem. Do the risks outweigh the costs of implementing the solution? Every decision you make in protecting your information assets must be an informed risk management decision, and rarely are choices black or white.
True, some decisions have already been made for you. For example, while you can certainly choose not to encrypt credit card information or store the credit card verification codes, either action will likely result in a loss of your ability to accept credit cards as a form of payment. The probable negative impact to your business of that decision is such that you do not really have a choice. In other words, while this is most certainly a risk management decision, it is one that is quite easy to make.
Likewise, it's also true that nobody in his right mind would connect an open wireless network to the back end of the in-store network in a physical store. However, that doesn't mean that the decision is not a risk management decision. It is. One may chose to do so, and if one does, one should suffer the consequences (which never seems to actually happen, unfortunately).
The key step to take here is to clearly articulate the problem you need to address, the proposed solutions to that problem, and the pros and cons of each. Once you have that, you have the information you need to make an informed risk management decision. Without that information, you are making decisions based on a hunch, and those are rarely good decisions.

Jesper M. Johansson is a Software Architect working on security software and is a contributing editor to TechNet Magazine. He holds a PhD in Management Information Systems, has more than 20 years of experience in security, and is a Microsoft MVP in Enterprise Security. Jesper's latest book is the Windows Server 2008 Security Resource Kit.
Roger Grimes (CPA, CISSP, MCSE: Security), Senior Security Consultant for the Microsoft ACE team, has authored or contributed to eight books on computer security and authored more than 200 magazine articles. He is a frequent security conference speaker and the InfoWorld security columnist.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


Security
New Elevation PowerToys for Windows Vista
Michael Murgolo
At a Glance:
  • Run as Administrator for third-party scripting tools
  • Run as Another User
  • Prompt Here as System for CMD and Windows PowerShell
  • Drag-and-drop Elevation Gadget
Download the code for this article: Elevation2008_06.exe (197KB)

Welcome to another edition of the Elevation PowerToys for Windows Vista. I took a close look at this in the June 2007 issue of TechNet Magazine. Here we are a year later. This time around, I want to show you how I expanded the Run as Administrator functionality to some
of my favorite third-party scripting tools, demonstrate how you can replace a nice Windows® XP feature that was removed from Windows Vista®, and look at some of the handy tools that are included in Elevation PowerToys.

Run as Administrator for Additional Scripting Tools
One topic I discussed in the previous article (available at technet.microsoft.com/magazine/cc162321.aspx) was enabling the Run as Administrator option for the native Windows scripting tools. For this article, I've created Run as Administrator PowerToys for some third-party scripting tools:
  • AutoIt v3 (www.hiddensoft.com)
  • AutoHotkey (www.autohotkey.com)
  • ActivePerl (www.activestate.com)
  • KiXtart 2010 (www.kixtart.org)
The code for each of these is included in the download for this article, which you can find at technetmagazine.com. The actual files are named ElevateAutoIt3.inf, ElevateAutoHotKey.inf, ElevatePerlScript.inf, and ElevateKiXtart.inf, respectively. For AutoIt v3, AutoHotkey, and ActivePerl, set up is quite simple. Just download the corresponding application and install it in the default location. After you've installed the applications you are interested in, you can then just install the appropriate Run as Administrator PowerToy for each tool.
Unfortunately, KiXtart 2010 does not provide an installer. Therefore, in order to make sure KiXtart is installed in a standard location so my PowerToy will work properly, I've provided an INF file that will installKiXtart 2010 (v 4.60) into Program Files\KiXtart and register the .kix file extension.
Go to www.kixtart.org/?p=downloads, download KiX2010_460.zip, and unzip it into a folder. Copy the Install_KiXtart.inf file (included in the code download that accompanies this article) into that same folder. Then right-click on Install_KiXtart.inf and select Install. After that, you can simply install the ElevateKiXtart.inf PowerToy.

Run as Another User PowerToy
User Account Control (UAC) was created to make the operating system less vulnerable to malware by having users, even those who are Administrators, run most applications with standard user privileges. UAC offers elevation potential for administrative tasks and other app functions. This elevation potential is provided through the Run as Administrator option, which you get when right-clicking on executable files. The Elevation PowerToys that I discussed in the June 2007 issue extended this capability to work on other file and object types.
The functionality built into Windows Vista works quite well for many administrative tasks. However, one important scenario was left out for Windows Vista. Many IT departments have a policy where network administrators use one user account for their everyday tasks (using e-mail, creating documents, and the like) and another account that is used only for network administration (or local computer administration).
This is done to help lower the risk that if a network administrator accidentally runs malware doing his everyday tasks, he will not compromise his entire system—or the domain he is on. This was accomplished on Windows XP using the Run as... right-click option. But this option is gone in Windows Vista because it was replaced with the Run as Administrator option.
The runas command-line tool, however, still exists in Windows Vista. Unfortunately, it cannot be used for the most common dual account tasks—running Microsoft® Management Console (MMC) snap-ins. For example, say you have been delegated some account management tasks in Active Directory®. You are running as a standard user for everyday tasks, and your network administration account is also a member of the local administrators group (so you can install network management tools when needed) on a Windows Vista computer with UAC enabled. Now you want to start Active Directory User & Computers (ADU&C) with your Active Directory administrative account, so you try the runas command, as follows:
runas /user:mydomain\admin
"mmc.exe %windir%\system32\dsa.msc"
Unfortunately, this does not cause ADU&C to launch. Instead, you receive a runas error that says "The requested operation requires elevation." What is happening in this case is that the MMC executable is marked to run at the highestAvailable privilege level. Since the highestAvailable level for your network administration account is as administrator, launching ADU&C in this manner would require elevation. Since runas does not cause a prompt for elevation, the error occurs.
So Windows Vista makes this scenario difficult by not providing a context menu item for Run as... and by providing no built-in means to run a process as another user that requires elevation.
This would be a frustrating article if there was no solution to this, but as luck would have it, one of my original Elevation PowerToys provides the key to solving the second problem, and I've whipped up another one to solve the first. (I wish I could claim that I thought up the solution to the elevation problem, but this was hit upon by Gov Maharaj of the Windows AppCompat team.)
It turns out that the Elevate Command PowerToy can be used with the runas command. Where the previous command failed to cause an elevation prompt, the following will cause the prompt:
runas /user:mydomain\admin
"elevate mmc.exe%windir%\system32\dsa.msc"
This causes runas to launch elevate.cmd (technically, the process being launched is cmd.exe) as the other user, and the elevate command takes care of launching mmc.exe with an elevation prompt.
Finally, I've taken this trick, combined it with file associations for .exe and .msc files, and given it an HTML Application UI to create a PowerToy that creates a Run as Another User option available through the right-click menu. When you select Run as Another User, you get an HTML Application like the one shown in Figure 1.
Figure 1 Run as Another User tool
Figure 1 Run as Another User tool
Here, just enter the user name and domain—for an account on the local computer, check the Use Local Account checkbox. You can then click the Run button to launch the application as a standard user, or you can click the Run as Admin button to launch the application with elevated privileges. After you click either of these two buttons, runas.exe will run and prompt for a password or smart card pin.
Since this PowerToy uses the Elevate Command PowerToy, you need to install that first. Then right-click on the RunAs.inf file, select Install, and approve the elevation. To uninstall the tool, use the Programs and Features Control Panel.
You will find that some of the shortcuts to .msc files in the Administrative Tools (such as Computer Management) will work with this PowerToy. But note that if you install the Windows Server® 2003 administrative tools using adminpak.msi, the shortcuts that are created are not standard shortcuts to the .msc files. Instead, they are Windows Installer shortcuts, and as a result Windows Explorer will not display the Run as Another User option for those shortcuts.
For those shortcuts you will either have to find the actual .msc files and right-click on them or create new shortcuts to the .msc files. Additionally, runas does not work with Internet Explorer® due to the way Internet Explorer was re-architected for Protected Mode in Windows Vista (you can find additional information concerning this issue at support.microsoft.com/?id=922980).
Note: between the time I finished these PowerToys and the publication of this article, Windows Sysinternals has released a new tool that is functionally very similar to my Run as Another User PowerToy. It's called ShellRunas and can be found on the Windows Systernals site: technet.microsoft.com/sysinternals/cc300361.
Since the folks at Sysinternals actually write real code for a living, you may prefer their tool for your own use. I decided to leave mine in the article as an example of how this task in particular and shell extensions in general can be done using HTML Applications with script code.

CMD and PowerShell Prompt Here as System
There are times when it is necessary to run programs in the Local System context. For example, many software distribution tools, such as System Center Configuration Manager (SCCM), use a client agent that runs as Local System to accomplish its tasks.
To test the behavior of a software installation program running as Local System before attempting a distribution with a product such as SCCM, it can be helpful to start the installer using a command prompt running as Local System. Therefore, I set out to create my CMD and PowerShell Prompt Here as System PowerToys.
When using Windows XP, I used to accomplish a function like this with a command shell script:
@echo off
sc create CmdAsSystem type= own type= interact
binPath= "cmd /c start cmd /k (cd c:\ ^& color ec ^&
title ***** SYSTEM *****)"
net start CmdAsSystem
sc delete CmdAsSystem
However, if you try to run this from an elevated command prompt on Windows Vista, you get the following error message and the command prompt running as System will not appear:
WARNING:  The service CmdAsSystem is configured
as interactive whose support is being deprecated.
The service may not function properly.
The problem is that this script tries to create and start an interactive service. Interactive services will not function correctly due to Session 0 Isolation in Windows Vista. (For an explanation of Session 0 Isolation, see the "Services in Windows Vista" whitepaper available at microsoft.com/whdc/system/vista/Vista_Services.mspx.)
To work around this limitation, I used the Psexec tool that was developed by Sysinternals (see technet.microsoft.com/sysinternals/bb897553.aspx). This tool allows processes to be started in the System context. Unfortunately, most Sysinternals tools do not include an installer. Therefore, I've provided an INF file (available in the code download) to install the whole Sysinternals Suite (which includes Psexec) into Program Files\Sysinternals Suite. As an added bonus, this INF file creates Start Menu shortcuts for the Suite's graphical tools.
To install the suite, first download SysinternalsSuite.zip from technet.microsoft.com/ sysinternals/bb842062.aspx and unzip it into a folder. Copy my INF file (Install_SysinternalsSuite.inf) into that folder, right-click Install_SysinternalsSuite.inf, and select Install. Since these new PowerToys use the Elevate Command PowerToy, install that next. After doing that, you can install CmdHereAsSystem.inf and PowerShellHereAsSystem.inf. Once these PowerToys are installed, you will then have the CMD Prompt Here as System and PowerShell Prompt Here as System options available as right-click items for folders and drives in Windows Explorer, as you can see in Figure 2.
Figure 2 CMD Prompt Here as System and PowerShell Prompt Here as System options
Figure 2 CMD Prompt Here as System and PowerShell Prompt Here as System options
Figure 3 shows a CMD prompt running as system. I selected the bright colors as a reminder that this prompt is running as System and can do unexpected (and damaging) things to the system if the wrong commands are entered.
Figure 3 CMD Prompt as System must be used responsibly
Figure 3 CMD Prompt as System must be used responsibly
Finally, these PowerToys add commands to the system so that these prompts can be started in the Run dialog or a CMD prompt. For example, executing the following command from the Run box will start a CMD prompt as System in the Windows folder:
cmdassystem "c:\windows"
The equivalent command for Windows PowerShellTM is psassystem. You should note that I have also modified the CMD and PowerShell Prompt Here as Administrator PowerToys to install similar commands—cmdasadmin and psasadmin, respectively.

Elevation Gadget
Most of my PowerToys require clicking the right mouse button. But as a bonus for this update, I have included something a bit more fun. This is a Windows Sidebar Gadget, which I call the Elevation Gadget (shown in Figure 4). It is a drag-and-drop target. Just drag an executable or a script from Windows Explorer that has a runas action defined and it will launch as elevated.
Figure 4 The drag-and-drop Elevation Gadget
Figure 4 The drag-and-drop Elevation Gadget
If you have installed my previous Elevation PowerToys, then this will work for Windows Script Host scripts, Windows PowerShell scripts, HTML Applications, and Windows Installer packages and patches (as well as executables and command shell scripts that have a runas action defined by default in Windows Vista). And you can also drag more than one item at a time. (Just try dragging a folder to the gadget and see what happens.)
To install the gadget, double-click on Elevation.gadget (available in the code download). If you would like to look at the code for the gadget, just add the .cab extension to the file name. You can then extract the contents from the Cab file.

Wrapping Up
The download for this article contains both the new PowerToys and the ones from the original article. I've made minor changes to a few of the old ones. For example, the original versions of Windows PowerShell Prompt Here as Administrator and Elevate WSH Script both installed their own copies of elevate.cmd and elevate.vbs. Since several of the new PowerToys also depend on these files, I've changed these tools to require Elevate Command PowerToy to be installed (and then they share that copy). To determine if a PowerToy requires the installation of the Elevate Command PowerToy, check the header in the INF file.
Some other original PowerToys have minor, non-functional changes as well. Always uninstall the old version of a PowerToy before installing the latest. Since this collection has now expanded to 17 tools, I've included command shell scripts to install and uninstall the entire collection (InstallAllPowerToys.cmd and UninstallAllPowerToys.cmd, respectively). You can customize these to install and uninstall only the tools that you need to use.
You should keep in mind that InstallAllPowerToys.cmd does not install the Run as Administrator PowerToys for third-party scripting tools by default. You can modify this script to install only those PowerToys for which you have installed the software. When you run either of these, it will re-launch itself as elevated. UninstallAllPowerToys.cmd should remove all the old versions of these tools as well.
As with all my PowerToys, these are unsupported, use-at-your-own-risk tools. And they are not official Microsoft products—they are my own personal creations. These were only tested by me and a few other volunteers on 32-bit Windows Vista with US English as the default language. Finally, it is possible that any or all of these PowerToys may not work with future Windows updates, service packs, or operating system versions.

Michael Murgolo is a Senior Infrastructure Consultant for Microsoft Consulting Services. He focuses on operating systems, deployment, network services, Active Directory, systems management, automation, and patch management. He is a subject matter expert in the area of desktop deployment and migration.


Security
Advances in BitLocker Drive Encryption
Byron Hynes
At a Glance:
  • Enhancements to BitLocker
  • Getting and installing BitLocker
  • Using BitLocker on a server
  • Considerations for complete data protection

In last year's security issue of TechNet Magazine, I took you on a short tour of some of the features of Windows BitLocker Drive Encryption in order to show how it was implemented in the initial release of Windows Vista. Now, with the release of Service Pack 1 for
Windows Vista® and the new Windows Server® 2008 operating system, the time has come to revisit BitLocker®.
In this article, I will discuss some of the changes found in the latest version, give an overview of how to install and use BitLocker on a server, and touch on some recently reported considerations to bear in mind. (By the way, to read last year's article, "Keys to Protecting Data with BitLocker Drive Encryption," go to technet.microsoft.com/magazine/cc138009.aspx.)

What's New
The changes introduced with this release of BitLocker bring new flexibility without altering any basic operations. The changes I'll review are support for data volumes; allowing three-factor authentication for machine access; support for Unified Extensible Firmware Interface (UEFI), the new industry-standard firmware for 64-bit systems; better protection against cryptographic attacks on volume metadata; and increased use of the Trusted Platform Module (TPM).

Data Volumes
When Windows Vista was first released, the BitLocker control panel only allowed you to turn on encryption for the Windows® operating system volume (usually the C: drive). For many consumers, this was perfectly adequate, since home computers are typically configured with all of the user's data and programs stored on the same volume as the operating system. In businesses, though, and certainly on servers, this is often not the case. As a result, one of the most common requests we heard from customers was for the ability to encrypt data volumes—volumes other than the OS volume that are installed in the computer (note that BitLocker is not designed to encrypt removable media).
As you can see in Figure 1, I have three usable volumes on this computer. (I actually have four if you include the small active partition used for startup.) My operating system is installed on drive C: (this is actually shown by the Windows "flag" on the icon), and two data volumes are also present, E: and P:. The P: volume has already been encrypted with BitLocker and is currently locked. The E: volume is not yet encrypted. In Windows Vista SP1 and Windows Server 2008, I can encrypt and unlock these data volumes from the BitLocker Control Panel applet.
Figure 1 The Bitlocker interface
Figure 1 The Bitlocker interface
If your operating system volume is encrypted with BitLocker, the default behavior is that encrypted data volumes are unlocked whenever the operating system volume is unlocked. If you use the control panel to unlock a data volume, you can see this option presented as a checkbox, as in Figure 2.
Figure 2 Saving keys for autounlock
Figure 2 Saving keys for autounlock
To turn a data volume's "autounlock" on or off, use the manage-bde.wsf command-line tool. Manage-bde.wsf is a powerful script included with Windows that uses the underlying Windows Management Instrumentation﻿ (WMI) providers installed with BitLocker.
For example, to mark data volume P: so that it must be manually unlocked, use the following command:
manage-bde.wsf –autounlock –disable P:
To turn autounlock back on for P:, use:
manage-bde.wsf –autounlock –enable P:
The BitLocker control panel does not expose everything you can do with BitLocker and data volumes, so you should use the -? option to explore the manage-bde.wsf commands. The manage-bde.wsf syntax is also included in the "Windows BitLocker Drive Encryption Design Guide" and the "Windows BitLocker Deployment Guide," which are available from the Microsoft Download Center at go.microsoft.com/fwlink/?LinkId=115215.

TPM+USB+PIN
Customers also wanted to be able to use additional authentication factors with BitLocker. BitLocker uses the TPM chip in your computer in order to verify the integrity of the platform—in other words, to determine that the early startup components, including the BIOS, have not been tampered with or corrupted. However, since the release of Windows Vista, you can now also require either a PIN or the presence of a USB flash drive containing a key created when you enabled BitLocker.
With Windows Server 2008 and Windows Vista SP1, you can now combine all three. The TPM continues to verify platform integrity, the USB key represents "something you have," and the PIN represents "something you know." This configuration provides very strong protection against unauthorized users being able to start the computer and unlock BitLocker-protected drives.
As with many things in security, however, this represents a trade-off. Obviously, when BitLocker is configured this way, a computer cannot automatically restart. In the case of a server, for example, you must decide which is more important: a seamless restart or higher levels of protection.

UEFI Support
With Windows Server 2008 and Windows Vista SP1, support has also been added for computers equipped with a Unified Extensible Firmware Interface (UEFI). UEFI is a specification that represents a modernization of the traditional BIOS used by most computers at startup. For more information about the UEFI specification, please visit www.uefi.org.

Increased Protection
When BitLocker detects that the system has been changed, or if a required PIN or USB key is not available at startup, BitLocker enters recovery mode. In recovery, BitLocker-enabled volumes remain locked and a text-mode dialog called the Recovery Console is presented to the user.
To unlock the drive, the user must enter a recovery password (a 48-digit number) either from the keyboard or from a USB flash drive. (When stored on a USB flash drive, the password is sometimes called a recovery key, because it is a binary, not text, format.)
BitLocker uses the recovery password to decrypt the keys stored in the volume metadata—the Volume Master Key (VMK) and then the Full Volume Encryption Key (FVEK)—to unlock the drive. For recovery to be successful, a copy of the recovery password must be available.
Because of this, in addition to storage by the user (such as on a USB flash drive), I highly recommend that you also store the recovery password centrally. The operating system includes functionality for storing recovery passwords in Active Directory® Domain Services (ADDS).
Secrets stored in the volume metadata, such as the VMK, are encrypted and the integrity of the entire volume metadata is cryptographically protected. If BitLocker detects that the volume metadata has been tampered with, it will refuse to use any of the metadata and it won't unlock any protected volumes. Note that the recovery password alone will not unlock a drive in this state.
It is important to stress that this situation only occurs with a deliberate security attack against the computer. If it happens, there's a good chance your computer is already in the hands of an evil-doer and out of your control. It will not arise from a simple unplanned change to the platform or if you forget your PIN.
To unlock the volume, you will need the following three items:
  • The recovery password (as text to type in or on a USB flash drive)
  • The binary key package that includes encrypted versions of the FVEK and VMK
  • The BitLocker Repair Tool
In short, you need to make sure your enterprise always has access to all of these things.
The recovery password can be backed up manually or automatically. I recommend using the Group Policy setting to automatically back up the recovery password to Active Directory Domain Services.
When you configure this setting, as shown in Figure 3, include the option to back up the binary key package. The binary key package includes encrypted versions of the VMK and FVEK, allowing you to use the BitLocker Repair Tool, if necessary.
Figure 3 Configuring Group Policy to include key packages in recovery information
Figure 3 Configuring Group Policy to include key packages in recovery information
The BitLocker Repair Tool has been designed to help you recover data from damaged disks that are BitLocker-enabled. Note that this is an advanced tool, meant for use by experienced administrators. For more information on the BitLocker Repair Tool, read the Microsoft Knowledge Base article at support.microsoft.com/kb/928201, or watch my webcast, "Microsoft BitLocker in the Enterprise: BitLocker Tools to Make Your Life Easier" (which includes a live demo), at go.microsoft.com/fwlink/?LinkId=114985.
This is a good place to point out that BitLocker does not replace the need to back up your data. If your disk is damaged or has been deliberately attacked, there is no certainty that the BitLocker Repair Tool will be able to recover any, let alone all, of the data.

Broader TPM Usage
Technically, this isn't a BitLocker change, but it's cool enough to be worth mentioning. Prior to SP1, the only part of the Windows OS that made use of TPM was BitLocker, but now the TPM is also used for some other functions as well. For one, when Windows sees that a TPM is available, it uses the TPM as a source of increased entropy when generating random numbers. This improves the quality of all sorts of encryption (and might even make your game play better, too).
However, this also means that not all TPM-related events shown in the Event Viewer are necessarily related to BitLocker. As an IT pro, you want to be aware that other system components—and potentially software from other vendors—can and will make use of the TPM, and therefore will cause events to be logged.

BitLocker in Windows Server 2008
Because of the shared codebase between Windows Vista and Windows Server 2008, the BitLocker changes appearing in SP1 are part and parcel of Windows Server 2008. But why is BitLocker relevant on a server? After all, BitLocker, by design, protects a computer from offline attacks. In other words, BitLocker offers no protection to a running system and servers, of course, are generally expected to be running all the time.
As it turns out, there are occasions where a server, or a hard disk from a server, could be exposed to an offline attack. Even if that never happens, BitLocker can help greatly when it is time to decommission a server or a hard disk, as we'll see. First, let's look at how to get BitLocker installed and running on a server.

Getting and Installing BitLocker
BitLocker is included in all editions of Windows Server 2008, but it is an optional component, or feature, that must be installed from either Server Manager or the command line. BitLocker is implemented, in part, as an NTFS filter driver. Installing this filter driver requires a restart of the computer, so be aware that activating BitLocker on a server will require a reboot. Also, as with Windows Vista, BitLocker requires a split-load configuration, where the active partition used to start the computer remains unencrypted. The BitLocker Drive Preparation tool is available to help you correctly configure your hard disks to support BitLocker if the server has not come pre-configured from the manufacturer. If you are comfortable with hard drive partitioning, however, you can certainly configure the hard disks manually.
To install BitLocker into Windows Server 2008, you can use the Server Manager graphical interface to select BitLocker from the list of features, as shown in Figure 4, or you can use the Server Manager command-line interface, by issuing the command:
Figure 4 Selecting BitLocker in Server Manager
Figure 4 Selecting BitLocker in Server Manager
ServerManagerCmd –install BitLocker –restart
When you use Server Manager, it installs BitLocker and the management tools for BitLocker. You can also install the management components without installing BitLocker itself. This avoids the need for the restart since the filter driver is not included. The name of this component is "RSAT-BitLocker."
BitLocker works just fine on computers running the Server Core installation option, but you can't use Server Manager to install BitLocker on Server Core or use the graphical user interface to manage BitLocker on Server Core. Instead, to install the components, use the command-line tools pkgmgr or ocsetup.
Once you have the BitLocker binaries installed and your disks configured in the required split-load configuration, you can enable BitLocker on the OS volume. The BitLocker control panel applet has the same icons and options in Windows Server 2008 as it does in Windows Vista SP1. In order to enable the advanced modes of BitLocker, you will need to adjust the default settings using the Local Policy Editor or a Group Policy Object that applies to the server.
On Server Core, or if you just don't want to use the control panel, you can use manage-bde.wsf to enable BitLocker. To enable BitLocker on drive C:, type
manage-bde.wsf –on C: -RecoveryPassword –RecoveryKey F:\
where C: is the volume to encrypt, and F:\ is a USB key or another volume where a copy of the recovery key will be stored (in binary format). You can also use a UNC path to store the recovery key on a network drive. A recovery password (in numeric text format) will also be generated and displayed. You might wish to add the –skiphardwaretest parameter if you are certain the hardware platform meets all BitLocker requirements. This will save one reboot.

Server Scenarios
Now, let's discuss some specific scenarios where BitLocker is useful for servers. Bear in mind that, as I mentioned, BitLocker is designed to help protect you against offline attacks—the kind of attacks carried out when Windows is not running.
Branch Offices One of the first and most obvious uses for BitLocker on a server is as part of the Windows Server 2008 branch office strategy. Between one-quarter and one-third of servers are installed in branch offices—that is, offices that may have lower physical security, less access to IT support, and perhaps less connectivity to datacenters. Branch offices are also an attractive target for attacks. In conjunction with features such as read-only domain controllers (RODCs), BitLocker can help protect sensitive data that must be stored in a branch office to be useful, but is not as easily physically secured as it would perhaps be in a datacenter.
This is a good opportunity to give some thought to the right level of protection. Which is more important—preventing unauthorized access to data, or requiring that a server come back up immediately and without intervention? My suggestion is that in many branch offices, it would be acceptable to require the entry of a PIN to restart a server, but that is a decision that each company has to make.
Disks in Shipment It is often necessary to ship data on a hard drive to a faraway location. This may include shipping a single disk, or pre-configuring and shipping an entire server. During shipment, the data on those disks is out of your control and could be copied, lost, or stolen.
To mitigate this risk, enable BitLocker on the volumes in the computer before shipment, then remove all of the key protectors except a recovery key or recovery password. This key or password can be hand-carried separately from the server or even communicated by phone or encrypted e-mail to staff at the receiving end. Once the computer or disk is received, the recovery password is used to unlock the drive. The drive can be left encrypted (add back any other key protectors), or the disk can be fully decrypted after delivery, if desired.
This is a particularly effective way to prestage domain controllers or servers for branch offices.
Theft of a Server As noted in the previous section, there is a very real danger of a server (especially a domain controller) being stolen. Thieves may grab a laptop out of opportunity, but a server might be a carefully chosen target. If BitLocker is configured to require only TPM integrity checking, the stolen server could simply be powered up and booted. In contrast, if the drives in a server are protected with BitLocker and BitLocker is configured in an advanced mode—requiring a USB key, a PIN, or both—it is very difficult for the thieves to get any useful information in any reasonable time frame.
Theft of a Disk Conversely, however, if just a disk is stolen, the TPM still provides a great deal of protection. Only the TPM from the original server can be used to unlock the BitLocker-protected drive, so the disk cannot simply be inserted into another computer and read.
Reduced Exposure By ordering server hardware that includes a TPM chip and using BitLocker platform integrity checking, you increase the defense against some forms of malware. In particular, BitLocker will detect changes made while Windows is offline or changes made to early startup components, especially if malware, such as a rootkit, requires a reboot to install. This is not a total solution, but combined with features such as Windows code integrity and products such as Microsoft® ForefrontTM Client Security, it is another effective layer of defense-in-depth.
Secure Decommissioning One of the most useful scenarios for BitLocker comes at the end of the lifecycle of a server or disk. How often have you heard about servers, or their disks, being disposed of without being properly decommissioned? Did you know that used hard drives sometimes sell for more on auction sites than new ones, as unscrupulous buyers hope to skim useful information from those disks?
Happily, rather than undertaking an expensive and time-consuming process to cleanse the disk of useful data, BitLocker allows another approach. Basically, no information is ever written to the disk in a useful format. Since the encrypted data is unusable, it is a quick, simple step to remove all of the key information. After that, it doesn't matter what happens to the disk hardware—it can be sold, recycled, repurposed, or whatever without the fear that the data could fall into the wrong hands.
In Windows Vista and Windows Server 2008, the format command was updated to wipe the BitLocker keys, including multiple overwrites. Now you have a simple and effective way to decommission a drive.

Recent News
As I write this, admittedly several weeks before you get to hold the publication, a number of recent articles, papers and news reports have discussed some interesting hardware characteristics and how they affect BitLocker, other Windows security features, and other encryption products from various vendors. I'd like to take a moment to address some of the findings.
One such item was published by researchers at Princeton University who demonstrated (very effectively!) a trait of modern computer memory sometimes termed "DRAM remanence" (available at citp.princeton.edu/pub/coldboot.pdf). In simple terms, the content of computer memory can be accessed for some period of time after power is removed from the memory. BitLocker, of course, keeps keys to decrypt data in memory while Windows is running, and the concern is that the keys could be acquired by unauthorized users.
Another demonstration by Adam Boileau (security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) showed how IEEE 1394 (often called FireWire) allows direct memory access (DMA), which can be used to acquire secrets from Windows, such as passwords or decryption keys. What's interesting about this is that DMA is almost the point of 1394; it's not a flaw, but rather what Firewire is designed to do.
What both of these attacks have in common, though, is that they require physical access to a running (or at least a very recently running) computer. BitLocker is not designed to protect against online attacks, and it does not eliminate the need for some amount of physical security. Proper defense-in-depth requires using a number of tools and features, creating an environment of physical security, outlining essential corporate policies and continually educating users.
As well, these are not new discoveries. They have been known about for some time, and, in fact, are discussed in the Microsoft® Data Encryption Toolkit (DET). The risk analysis provided in the DET is intended to help customers balance security with usability, and with the cost of implementation and management. This is no small point. We believe that educated customers are best suited to make decisions about the trade-offs of security, usability, and cost.
In addition to the DET, some of my colleagues have provided some excellent commentary and guidance. First, Russ Humphries discussed security trade-offs in the context of DRAM remanence in his blog entry at go.microsoft.com/fwlink/?LinkId=115217. Furthermore, Douglas MacIver wrote about additional specific configurations steps and countermeasures that you can take today, on the System Integrity (SI) team blog at go.microsoft.com/fwlink/?LinkId=115218. I highly recommend taking the time to read both of these helpful blog entries. You should also read the DET.
Key among these recommendations is to use an advanced mode (that is, one that requires a USB key or PIN) and not to leave a computer unattended in sleep mode (use hibernate instead).

Conclusion
BitLocker remains one the most useful features of Windows Vista. With the release of SP1, it has been enhanced in direct response to customer feedback to enable more scenarios and meet a wider range of needs for data protection. Expanding that data-at-rest protection into Windows Server 2008 gives you more ways to protect data and maintain compliance whether that data is stored on servers or client workstations, in the datacenter, the branch office, or with a mobile worker.

Byron Hynes is an Enterprise Technology Strategist with the Microsoft Enterprise and Partner Group (EPG), focusing on security features and products. Prior to joining EPG, he worked in the Windows Server Division and closely with BitLocker (System Integrity) since 2005. Your comments and questions are welcome. Grab his attention at Tech•Ed 2008, or send an e-mail to bhynes@microsoft.com.


Security
Application Lockdown with Software Restriction Policies
Chris Corio and Durga Prasad Sayana
At a Glance:
  • How software restriction policies work
  • Inventorying applications in your environment
  • Creating and enforcing policies

When IT professionals look to reduce the total cost of ownership, or TCO, of their desktop machines, there are two key strategies that often come to mind. The first one is to get your desktop
users' accounts out of the Administrators group. And the second one is to limit the applications that the users can run. Approaching these problems can be quite a challenge in an enterprise environment, but Windows Vista® offers some technologies that can help you to achieve these goals.
Windows Vista, and its User Account Control (UAC) feature, has made a giant step toward helping IT professionals run their enterprise users as members of the Users group (Standard Users). UAC changed the default security context for all applications to be that of a User rather than an Administrator. This migration to the Users group is still a formidable task, but as the industry adjusts to this new paradigm, the task will get easier over time.
After analyzing the challenges of moving users to the Users group, or sometimes during this process﻿, many administrators catalog what applications their users need to run and consider the steps necessary to allow only these applications. The software restriction policy feature is designed to help IT pros do just that.
You simply specify what applications are allowed to run and then deploy the policy using Group Policy. Enforcing such a policy throughout an entire enterprise can reduce TCO, as this lockdown will limit issues that are related to unsupported applications. (And you can also use software restriction policies in some interesting and very extreme ways, as we discuss in the sidebar "The Bare-Bones Software Restriction Policy.")

How Software Restriction Policy Works
Software restriction policy aims to control exactly what code a user can execute on a Windows Vista machine. You, the administrator, create a policy that defines what can (or cannot) be run in your environment. This policy is then evaluated whenever and wherever code may be executed. This includes during process creation, in a call to ShellExecute, and when a script runs. (We'll look at this in more detail in a moment.)
If it is determined that an application is allowed to execute, the application will start. If, however, it is determined that an application is not allowed to run, the app is blocked and the user is notified. For example, if you tried to run Solitaire from the Start menu and it wasn't allowed, you'd receive a dialog similar to the one shown in Figure 1.
Figure 1 A dialog appears when an application is blocked
Figure 1 A dialog appears when an application is blocked
The UI for defining a software restriction policy is exposed in the Group Policy Object Editor (GPOE), and this is where the lockdown policy is authored. There are a variety of methods for defining what code can and can't run. Once the policy is complete and tested, you can deploy it.

Defining the Software Restriction Policy
The first major decision you will make, a decision that will dramatically affect how software restriction policy will work in your environment, is to choose a default rule type. Software restriction policies can be deployed in one of two modes: Allow List or Deny List. Basically, you're choosing whether you want to create a policy that describes every application that is allowed to run in your environment or a policy that defines every application that cannot run.
In Allow List mode, the default rule within your policy is Restricted and will block all applications that you don't explicitly allow to run. In Deny List mode, the default rule is Unrestricted and restricts only the applications that you have explicitly listed.
Deny List mode, as you might guess, is an unrealistic approach if you are seeking a broad TCO reduction and the security benefits resulting from an application lockdown. Creating and maintaining an extensive list that blocks all malware and other problematic apps would be next to impossible; therefore, we recommend that software restriction policy be implemented in Allow List mode, which means a default rule of Restricted.

Inventorying Apps in Your Environment
If you're going to design a policy that will specify what applications can run, you need to determine exactly which applications are required by your users. The software restriction policy feature offers an advanced logging feature with a very simple policy to understand exactly what applications are running in your environment.
On a sample set of machines within your environment, deploy software restriction policy with the default rule set to Unrestricted and be sure to remove all other additional rules. The plan is to enable software restriction policy but not allow it to restrict applications; instead, you are using it to just monitor what is being run.
Next, create the following registry value in order to enable the advanced logging feature and set the path to where the log file should be written:
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
Now, when an application is run and the software restriction policy evaluated (it is evaluated even though it is allowing everything to run), an entry is written to the log file﻿.
Each log entry includes the caller of the software restriction policy and the process ID (PID) of the calling process, the target being evaluated, the type of software restriction policy rule that was hit, and an identifier for the rule. Here's a sample entry written when a user double-clicks on notepad.exe:
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
This log file represents every piece of executable code that software restriction policy will check when it is enabled and set to block applications. That means that you must decide for each entry in the log file whether or not it should be accounted for in your Allowed List. Note that you'll see several binaries being checked that are part of Windows® and required for the system to work.
The logging technique that we describe here offers a clear way for you to understand exactly what applications the software restriction policy will encounter in your environment. But it is not the only way to accomplish this task.
The Inventory Collector that is included as part of the Microsoft® Application Compatibility Toolkit 5.0 gives you the capability to inventory the applications that are being used in your environment. This tool offers a variety of different ways for you to discover what applications are installed in your environment, and it also consolidates the results into a central database.

Authoring Additional Rules
Now that you have a list of applications that must be allowed to run in your environment, you are ready to create the actual rules that will permit these applications to run. The software restriction policy feature uses two ways to identify policy—one is based on the cryptographic properties of an application (such as its hash), and the other defines a Trusted Path or folder in which trusted applications should reside.
Figure 2 shows where you would add rules to allow the applications to run in the Software Restriction Policies node of the GPOE (gpedit.msc). The most straightforward way to define applications in your environment is to create a hash rule for every single binary you encountered during the logging phase.
Figure 2 Using gpedit.msc to author software restriction policies
Figure 2 Using gpedit.msc to author software restriction policies
Since the hash is a unique value that is returned for a particular set of bits, each binary in your policy is going to have a different hash. This approach is particularly secure and will only allow the specific binaries in your policy to run.
Of course, there are some drawbacks to this approach. For instance, your environment could easily have several thousand binaries. It could be difficult to author all of these rules in the software restriction policy UI, and as the number of rules gets particularly large, performance can be affected. In addition, each application update in your environment will require one or more new hash rules to be deployed in the environment. Updating such a large policy as applications are updated can be a huge burden.
Fortunately, ﻿this burden can be avoided because there are two other ways to identify rules that make it easier to use software restriction policies in your environment. Venturing further down the cryptographic security route, you can create a rule that will allow any binary that is signed by a particular certificate to run.
Doing this helps to simplify the maintenance of the policy list since, when an application is updated, the new binaries will generally be signed by the same certificate as the previous ones. However, if you don't want a previous version of the binary to run in your environment, you'll need to add a R﻿estricted hash rule in order to prevent the file from being allowed.
By default, the evaluation of certificate rules is disabled for software restriction policies. There are two reasons behind why this had to be done.
First, the certificate rules in the software restriction policies are defined by what is in the system's Trusted Publishers store. Because the Trusted Publishers store is used for purposes other than just software restriction policy rules, this requires additional time and consideration when it is used for the software restriction policies feature.
The second reason is that in order to determine whether a file's signature is valid, you must take a hash of the file and compare it to the signature information. Hashing a file is a very expensive operation—the entire file must be read off of the disk and processed to calculate this hash.
In order to enable certificate rules, navigate to the Software Restriction Policies node and select Enforcement Object in the results pane. Then double-click to open its properties dialog and select the enforce certificate rules radio option.
The other common way to identify code is to use the path of the code on the local machine. This is an effective and efficient technique, but it has one drawback—you must be careful to ensure that the security settings are set properly on the folder.
If you add a particular path rule, and this path allows users to write files there (to the desktop, for example), they would be able execute anything they want just by putting the executable in that folder. However, if your users are not in the Administrators group, they generally don't have the ability to modify anything in the Program Files or Windows directories. This means that if all your applications are in the Program Files directory and your users aren't Administrators, then you should look to path rules for having a very simple and efficient policy.
Path rules offer some other features that make it more appropriate for some environments. It allows for wildcards and lets you use environment variables to make it easier to define rules that are portable in your environment—after all, %systemdrive% might not be﻿ c:\ for every user.
As for performance and maintenance, this is probably the most hassle-free way to identify code. Path rules are certainly something to consider, but you need to be aware of the additional security considerations.

Network Zone Rules
Software restriction policy does include a rule type called Network Zone rules, although this type of rule is being deprecated. The original intention of these rules was based on the idea that the source of particular executable code could be identified and trusted, and thus the code would be allowed to run. Unfortunately, this is particularly difficult to do and, as a result, never worked particularly well. Currently, this type of rule is not enforced in the majority of places on the software restriction policy entry points.
In cases where most applications are installed to the %Program Files% directory but there are other executable files that are installed elsewhere and signed by a specific certificate, it may make sense to use rules of different types. A few hash rules, a couple of path rules, and you'll find you've got the right policy for yourself.
Just keep in mind that there is an order in which the rules are processed (as shown in Figure 3). Certificate rules are the most specific, hash rules are next, then path rules, and then path rules with wildcards in them. So, if a piece code is identified by a hash rule and a path rule, the security level of the hash rule will take priority.
Figure 3 Rule﻿ processing order
Figure 3 Rule﻿ processing order

Policy Enforcement
The software restriction policies feature provides a breadth of coverage on the system being secured. The idea is that any location from which code can be executed should be integrated with the software restriction policy and, in turn, check the policy to see if the executable code is allowed to run.
While there are numerous places that check the software restriction policy, the most straightforward entry point is CreateProcess. During CreateProcess, the policy is checked to determine whether or not the binary that represents the application is permitted to execute. The policy check is done by the SaferIdentifyLevel API, which is publicly documented. The general process is illustrated in Figure 4. (We'll discuss SaferIdentifyLevel in more detail in a moment.)
Figure 4 Using SaferIdentifyLevel to determine whether a binary can be executed
Figure 4 Using SaferIdentifyLevel to determine whether a binary can be executed
After CreateProcess, the next most commonly used API where software restriction policy is enforced is ShellExecute. This is the API that is called when the user clicks on an application in the Start menu or double-clicks something on the desktop.
ShellExecute can be called on a wide variety of file formats. In cases such as a .txt file, calling ShellExecute on the file doesn't actually result in the file being executed—technically, of course, the file is opened. For this reason, software restriction policy contains a list of executable file types so that it can control what types of files are checked when ShellExecute is called. You can customize this list ﻿of executable file types in the software restriction policy UI.
Beyond CreateProcess and ShellExecute, there are two other key integration points: LoadLibrary and script hosts. LoadLibrary is obviously an important place to check executable code, but unfortunately LoadLibrary presents some special constraints.
Most applications have one executable and several DLLs that are loaded. And there are typically lots of applications running on the system. This means that LoadLibrary would require a lot of checking of the policy. Depending on your policy for identifying code, this could be a very expensive entry point to enforce—imagine checking the hash of every DLL loaded on the system, which includes hashing the binary and then comparing it to a list of perhaps thousands of hashes.
This functionality is disabled by default, but it can be enabled manually. To do this, navigate to the Software Restriction Policies node in gpedit.msc and double-click on Enforcement. After that, select the All software files radio button.
As we mentioned, software restriction policy is integrated with most script hosts in the system. This includes cmd, VBScript, Cscript, and JScript®. These entry points, as well as the others, use the primary software restriction policy enforcement API: SaferIdentifyLevel.
The SaferIdentifyLevel API determines whether a specified executable should be allowed to run by looking up the identification information in the relevant software restriction policies. This is a publicly documented API. Third-party script hosts and executable environments can and should use it﻿ in order to integrate with software restriction policy so the policy can determine whether ﻿a piece of executable code should be allowed to run.

Running as a Standard User
A not-so-well-known feature of the software restriction policy is its ability to filter the privileges of certain applications when they're launched. This functionality was introduced in Windows XP, but it wasn't exposed in the software restriction policy UI until Windows Vista.
In this way, it was a precursor to ﻿Windows Vista UAC because you could use it to run an application as a Standard User even when the user was a member of the Administrators group. This is what happens when you create a rule and set the Security Level to Normal User in the Additional Rules UI.
Both UAC's token filtering functionality and software restriction policies' Normal User rules ﻿take advantage of an underlying API that implements the same behavior as the CreateRestrictedToken API. However, the overall architectural differences in the technologies are very significant. But UAC differs from software restriction policy in a couple of key ways.
First, in Windows Vista with UAC enabled, every application is started with a security token similar to a member of the Users group by default, even when the user is an Administrator. This is achievable with software restriction policy, but there is no means to start an application with the user's actual Administrator token—for instance, when the user needs to install an application. The change in default security context and ease of access to a user's full administrator token are key benefits of UAC.
The second difference is that, in the case of executables, the code itself expresses what privilege level is required in order for it to function. This is a key distinction because independent software vendors (ISVs) and developers understand the needs of their code. For example, if a control panel application needs to edit something that requires administrator privilege, it can specify that requirement in its manifest. Thus the ISV can describe the privileges needed by an application rather than imposing a certain privilege level upon it without any means available to change this level.
For now, you should avoid using the Normal User rules unless you really understand how they work. UAC is an excellent way to help get your desktop users out of the Administrators group, and you should seriously consider simply leaving UAC in your enterprise environment.

Software Restriction Policies in Use Today
There are a number of moving parts that you need to account for when you use software restriction policy. But it's not as you might think, and, in fact, you may even be using software restriction policies today without realizing it. If, for instance, you run Parental Controls on a Windows Vista system, you are using software restriction policies to control the execution of applications.
Software restriction policy was an important technological development when it was first introduced in Windows XP. But application lockdown is really just now starting to get the attention of IT professionals.
The software restriction policy feature in Windows Vista has some rough edges that still need to be polished, but it is clear that administrators want to have this increased control over what is running in their environments. Fortunately for all of us, this technology will continue to evolve and make it easier for IT pros to manage their systems and lower the cost of running a Microsoft Windows environment.﻿
The Bare-Bones Software Restriction Policy
One application of software restriction policy is to create a policy that locks down Windows into a kiosk mode. Microsoft actually produces a tool kit, called SteadyState™, for creating this kiosk. However, if you are only interested in locking down the applications that can run, this can be achieved more simply.
To allow the minimum set of applications required to log on to Windows Vista, create a policy that allows logonui.exe and userinit.exe to run from %windir%\system32. Most users will probably also need the following applications allowed to run:
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
If you want the default Windows shell, you would also want to add %windir%\explorer.exe.
Alternatively, you could choose to boot directly into an application, such as Internet Explorer®. In that case, it would be necessary for you to list iexplore.exe instead of explorer.exe.
Another aspect of this bare-bones policy is that your users should not be in the Administrators group. This is important so that they cannot bypass the policy. However, because they can only run a very basic set of applications and do not have the privileges of an Administrator, the users will not have the privileges to install applications or maintain the system.
You will need to have some way to do that for these machines. If you intend to update and maintain these machines by logging on locally with an Administrator account, you should select the radio button that applies software restriction policy to all users except local administrators. The policy should also include consent.exe and cmd.exe. This will allow the Administrator to launch any administration option from an Administrator cmd prompt.
Note that UAC limits the privileges of the user's security token by default to make it look like the token isn't a member of the Administrators group. Even if you set the setting above to not apply the policy to Administrators, it will still be applied to the users. It is only when you go through the UAC elevation experience that the Administrator actually gets the full administrator privileges and the software restriction policy will then not be applied.

Chris CorioChris Corio was a member of the Windows Security team at Microsoft for more than five years. His primary focus at Microsoft was application security technologies and management technologies for securing Windows. You can reach Chris at winsecurity@chriscorio.com.
Durga Prasad Sayana﻿Durga Prasad Sayana is a Software Design Engineer/Test on the Windows Core Security team. His primary interests are security technologies and software testing. You can reach Durga at durgas@microsoft.com.


Security
Managing the Windows Vista Firewall
Jesper M. Johansson
At a Glance:
  • Rule types and scenarios
  • Firewall profiles
  • Domain isolation rules
  • The problem with outbound filtering

A while ago I wrote an article in my blog about the Windows Vista firewall. That post simply pointed out some of the nice features but did not offer up much in the way of deployment advice.
In this article, I go into more detail on some of the features in the Windows Vista® firewall that are specifically designed to ease enterprise management. And I will also be giving advice on how you can use them to make your job simpler and ensure your users are more secure.
With the recent release of SP1 for Windows Vista, you might expect enterprise deployment of Windows Vista to pick up. (It's common for enterprises to wait for the first service pack to be released before migrating to a new OS.) If you're one of the IT pros who are now looking a bit more seriously at Windows Vista for your enterprise environment, you should take a close look at the firewall. Once you realize what the Windows Vista firewall can do, you may want to renegotiate the agreement you have for that third-party security suite to remove the firewall from the package.

Windows Firewalls Then and Now
The firewall in the original release of Windows® XP left a lot to be desired. While it adequately matched the security functionality in commercial host-based firewalls at the time, it didn't add anything new or innovative.
The replacement that came in Windows XP SP2 was completely modified. It was specifically designed to ease enterprise manageability. The Windows XP SP2 firewall is very appealing in that it is lightweight, centrally manageable, effective, and unintrusive. But perhaps most important, it does something very critical: The Windows XP SP2 firewall protects the system at boot.
This last point is crucial. I have seen many systems in the past get infected during boot even with a firewall turned on. In fact, during the height of the Blaster epidemic, attack rates ran as high as one in four minutes. In other words, if you left an unprotected computer on the Internet it could have gotten infected, on average, in four minutes. And if you were relying on a firewall that did not protect the system at boot, 1 system out of 12 would have been infected at reboot. These figures were what drove Microsoft to ensure that the Windows XP SP2 firewall protected the system at boot.
In Windows Vista, the firewall received another complete makeover. The most obvious change, from a management perspective, is that the management interfaces of Internet Protocol Security (IPsec) and the firewall have merged. This is a very logical change. IPsec and the firewall are both designed to block things that are not allowed. The difference is that in the firewall, the parameters that define what is allowed are not very granular, while blocking or allowing large swaths of the address space in IPsec is cumbersome.
With the two features located in a single management interface, admins can make use of both technologies seamlessly, with less worry about whether something requires an IPsec rule or should instead have a firewall filter. In essence, you have a single view of the network attack surface of the system and this helps to minimize the risk of mistakes.
SP1 for Windows Vista adds some reliability enhancements to the firewall features. It also adds new algorithms, notably the Suite B algorithms, for use in IPsec. This is a set of encryption-related algorithms, comprising the Advanced Encryption System (AES), Elliptic Curve Cryptography (ECC), and Secure Hash Algorithm (SHA) 256 and 384.
Most importantly, however, Service Pack 1 adds support for Network Access Protection (NAP). NAP is a policy enforcement tool that ensures that managed and non-compromised clients are up-to-date with the latest security policies, updates, and anti-malware definitions before they are permitted to connect to the network. NAP cannot stop malicious hosts from connecting to the network, but it does ensure that all managed hosts are fully compliant so long as they are not actively compromised.
The Windows Vista firewall, called the Windows Firewall with Advanced Security, is also included in Windows Server® 2008. All the features are also manageable remotely and can be configured across a network using Group Policy.

Rule Types and Scenarios
The combination of firewall and IPsec functionality in the management interface means there are now two different types of rules: directional rules and connection rules. The directional rules are standard firewall rules that define which traffic to allow in the appropriate direction. The connection rules define the protection parameters for connections between computers. To draw an analogy, the directional rules are a bit like the firewall rules you know in previous firewalls while the connection rules are more like the IPsec rules used in conjunction with the firewall in Windows XP SP2.
By combining the firewall and IPsec into the same interface, several very interesting scenarios are enabled. For example, isolating systems from each other on the network is one of the most valuable security concepts available today. Microsoft calls this "Server and Domain Isolation."
Server and Domain Isolation uses both IPsec and firewall functionality. Recognizing this, the new firewall management interface includes specific functionality for isolation rules. These are appropriate if, say, you want to restrict the connection based on attributes of the source or destination systems, such as domain membership.
As you can see in Figure 1, the New Connection Security Rule Wizard starts out by asking what type of rule you want to create. If you select Isolation, the wizard preconfigures certain settings that are appropriate for an isolation rule.
Figure 1 Using the New Connection Security Rule Wizard to create an isolation rule
Figure 1 Using the New Connection Security Rule Wizard to create an isolation rule
You may also notice in Figure 1 that the isolation rule mentions health status. The rules used for Server and Domain Isolation are actually the same rules you use for NAP.
You can't enforce authentication for some types of traffic. For instance, you probably do not want to require authentication for DNS resolution. For the endpoints of that type of traffic, you need an authentication exemption rule. An authentication exemption rule is exactly what it sounds like—it exempts the traffic from IPsec requirements.
A server-to-server rule is a bit misnamed. While more commonly used with servers, it can also be used with clients. A server-to-server rule simply configures a connection to require authentication. This is different from an isolation rule in that not only does an isolation rule require authentication, it also requires fulfillment of some additional criteria, such as domain membership or health state.
A tunnel rule essentially defines a site-to-site Virtual Private Network (VPN) and the tunnel between the gateways. Tunnel rules are rarely used with Windows Vista, as it is unlikely that you will use Windows Vista in a gateway capacity. You can create fully custom rules. This lets you customize every parameter of the rule.

Rule Ordering
The rule ordering is a bit complicated at first glance. The key to understanding rule ordering is to first forget about ordering. It is not so much about ordering as it is about a matching selection. Consider inbound traffic as an example. Inbound traffic that does not match any rule that allows it is blocked by default. You may consider that as an ordering that says "Allow rules are considered first," but that assumption would be incorrect. If a specific packet is matched by both an allow rule and a block rule, the block rule will win. That means that the matching, in simple terms, is:
  1. Block rules. If a packet or connection matches one of these, it is discarded.
  2. Allow rules. If a packet or connection matches one of these, it is allowed.
  3. Default directional profile behavior. If no block or allow rules match, the traffic will be treated according to the behavior specified as the default for traffic in that direction in that profile. In the inbound direction in all profiles, that means blocking the traffic in a default configuration. In the outbound direction, by default, it means allowing the traffic in the default configuration.
The matching process is moderated by authenticated bypass (IPsec) rules. Using that type of rule, all authenticated traffic that matches the other parameters of the rule is permitted, regardless of whether it matches any other rules or not. Authenticated bypass rules are directional rules that have the Override block rules option selected, as shown in Figure 2. Those are considered first, so as to allow authenticated traffic to always reach the system. This is key to allowing you to easily allow traffic from authenticated hosts but block traffic from everyone else. You can consider that rule as 0 in the ordering. Thus, the complete rule order list looks like this:
Figure 2 Checking the Override block rules option to configure an authenticated bypass rule
Figure 2 Checking the Override block rules option to configure an authenticated bypass rule

0. Authenticated bypass rules
1. Block rules
2. Allow rules
3. Default directional profile behavior

It does not really matter if there are multiple rules within each class that match the traffic pattern. As soon as any rule matches the traffic, rule processing stops.

Public, Private, and on the Domain
Networking Resources
  • TechNet Security Center
  • Using the Netsh Advfirewall Command-Line Tool
  • Security Rules for Windows Firewall and for IPsec-Based Connections in Windows Vista and in Windows Server 2008
  • Security Watch Using SCW on Windows Server 2008

The new firewall has three profiles: public, private, and domain. The Windows XP SP2 firewall, on the other hand, had two network profiles: standard and domain. The domain profile is automatically invoked when the computer can find the domain controller. In Windows XP, the standard profile was used otherwise. This provided powerful functionality for a security admin who could lock the computer down completely when it was roaming and still allow all the remote management functionality that's necessary when on the organization's network. But this approach presented certain problems for some users—in particular, those with personal networks at home. Because the standard profile was always used if the system was unable to reach the domain controller, the system was locked down from the user's home.
The new private profile included in Windows Vista helps to resolve this issue. Now when you connect the system to a new network, it will ask whether that network is public (this is simply the new name for the former standard profile) or private and configure the system appropriately. The system remembers this each time it connects to that particular network, based on network parameters presented to it by the infrastructure servers on the network. This is not foolproof by any means, but it helps in that it allows more networks to be better locked down.
The detection logic for whether the system is on the domain has also been improved. The result is a faster, more reliable transition and fewer systems that think they should be using the public or private profiles when they are actually on the domain.
You can tie your rules to a particular type of network, preventing the system from volunteering too much information and trying to connect to systems on untrusted networks. This is one area where the integration of the firewall and IPsec starts to pay off.
Using these new rules, you can provide some restrictions that were not previously possible. For instance, for many years attackers have attempted luring attacks to get users to make Server Message Block (SMB)—for Windows networking—connections to untrusted hosts, thereby forcing an authentication sequence giving them a challenge-response pair that can be used to crack passwords. Older versions of this attack were also used to downgrade to clear text authentication or to reflect the user's challenge-response pair back to the originating computer. The former technique was broken years ago. The latter technique was mitigated with Windows XP SP2—but keep in mind that volunteering challenge-response pairs is nevertheless unwise.
To prevent this, you could use another new function in the Windows Vista firewall—outbound filtering. An administrator could decide, for instance, to block all outbound SMB connections (those terminating at ports TCP 135, 139, 445, and UDP 137, 138, 445) in the public profile. This would make it more difficult for a system to be used in a luring attack to gain challenge-response pairs, or prevent it from accessing untrusted Windows File Shares on the Internet.
Again, this is certainly not foolproof. For example, if the system has already been compromised, this rule would not stop the system from communicating out as the attacker could simply disable the rule. However, it can be very useful as a measure to protect well-behaving but potentially exposed systems.
It is important to mention in this context that, just like in Windows XP SP2, only one profile can be active at a time on Windows Vista and Windows Server 2008. If there are two network interfaces live in the system and one of them is on the domain while the other is on a public network, the public firewall profile will be applied to both. The most restrictive profile will always be used. As you might guess, the public profile is more restrictive than the private profile, and the private profile is more restrictive than the domain profile. So beware that the outbound SMB blocking rule can break much traffic over VPN connections.
To enable traffic over a VPN connection when the computer is on a public or private network, you create directional rules that apply only to VPN interfaces. For this to work, the VPN interfaces must be recognized as such by Windows. If you do not use the Microsoft® Routing and Remotes Access Services VPN server, test this functionality before deploying it widely. It is primarily a problem with inbound traffic to the client and any custom outbound rules you create.

Building Firewall Rules
Building a firewall rule is much easier in the new firewall. The New Rule Wizard, shown in Figure 3, allows you to define all the usual types of rules. And it includes predefined rules for particular services.
Figure 3 Predefined rules in the New Rule Wizard
Figure 3 Predefined rules in the New Rule Wizard
The predefined rules are particularly important. Server isolation is essentially about restricting services such that they are only available to those systems that need to use them. On server products, the Windows Security Configuration Wizard (SCW) can be used to make this easier, although still not quite pain free. (I discussed the SCW in the March 2008 issue of TechNet Magazine.)
But the client versions of Windows have not had similar functionality until now. When you use the predefined rule type, much of the hard work is done for you—the task of determining which endpoints a service uses. The firewall is not only application-aware in that it knows which program the "iSCSI Service" represents; it also contains predefined rules that describe certain functionality. This allows you to focus on which computers need to be covered in a rule. That is still a difficult and time-consuming task, but at least one that is unique to your environment.
There is also a custom rule (obscured by the dropdown in Figure 3) that gives you all the flexibility you can expect from an authenticating firewall. For instance, if you want a rule that only allows IPsec encrypted traffic, you would select the option to only allow secure connections on the Action page of the wizard shown in Figure 2.
When you select this, you also have the option to turn on encryption. If you leave this option blank, the traffic will use ESP-NULL (encapsulated security payload with a NULL key). This is the recommended way to use IPsec for authentication. It allows most network management tools to keep working because the traffic is traversing the network in the clear, and if you ever want encryption, you can simply check the box.
In many situations, encryption of network traffic is not nearly as important as not accepting any traffic from malicious hosts. Encrypting traffic on the network blocks a bad guy who has gained access to the network itself from seeing what is in the packet. Requiring authentication may prevent you from sending the packet in the first place and from getting attacked. Granted, there are many situations where network-level encryption is important, but there are also many other situations where you only need authentication.

Building Domain Isolation Rules
In most environments, you want a limited number of computers to be able to send traffic to a workstation. At the very least, all workstations should be configured with domain isolation rules. This was complicated in Windows XP, but it's easy in Windows Vista.
First, open the management tool of your choice and select the Connection Security Rules node. Then right-click on the node and select New Rule and you get the dialog shown in Figure 1. Select Isolation rule and click Next. You now have to select whether you want enforcement of the rule or not. In most cases on workstations, you will want to require authentication for inbound traffic. This prevents any computer that is not domain joined from sending traffic to the workstation. However, in order to request services from infrastructure services, the system must permit some outbound traffic to pass in the clear. The best option, therefore, is to require authentication for inbound connections and request authentication for outbound connections.
Next, pick the authentication method. The default selection is called, well, Default—not a particularly helpful title. You can configure the default authentication method on a per-computer basis in the IPsec properties (accessed by right-clicking on the Windows Firewall With Advanced Security node and selecting properties). The default authentication method is always Kerberos because this is the simplest and most secure. However, for clarity's sake, I recommend that you actually select it when you build your rules. Normally, you want to only authenticate the computer, not the user as well. If you require both, you may be unable to accept certain kinds of management traffic, such as anonymously transmitted SNMP traffic.
After you've selected the authentication method, all you need to do is select which profiles you want this rule to be available in. Because it is a rule that applies to domain joined computers, which can present a Kerberos ticket, it makes no sense to open this particular hole in either the Private or Public profiles. Save the rule, and you are done.
Basic isolation rules are not complicated any longer. However, to take advantage of the power of IPsec for isolation, you need to implement server isolation, even on your workstations. Doing so, you can restrict your workstations from listening to other clients. Instead, they will only respond to the appropriate management stations. Imagine how much less the impact of various malware breakouts would have been had client systems refused to listen to other clients.

Scripting the Firewall
The new firewall comes with a substantial API that allows you to script both deployment and assessment. Ideally, you should use Group Policy for deployment, but since Group Policy is not always available, it is important to have a proper API-set to configure the firewall. The APIs are grouped under the INetFWPolicy2 set of APIs. The Software Development Kit and the MSDN® Library contain more complete details on how to use them, but a few examples help illustrate the point.
One common sample is the need to determine whether a group of rules is turned on. Say, for instance, an application or administrator needs to determine whether file and printer sharing is allowed from a system. This can be accomplished through INetFWPolicy2::IsRuleGroupCurrentlyEnabled. Figure 4 provides a VBScript sample that demonstrates this function.
Figure 4 Using INetFWPolicy2::IsRuleGroupCurrentlyEnabled
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if
Now, if file and printer sharing is off and you need to turn it on, you first need to ensure that this can be done and will not be over-ridden by Group Policy. This is done with the INetFWPolicy2::LocalPolicyModifyState API. A skeleton, which can be filled in with actual code, is shown here:
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Command-Line and Interface Types
No firewall would be complete without a proper command-line for management. There is a sub-context under netsh, called advfirewall. The advfirewall context gives you command line access to everything you can do in the graphical UI. For example, if you want to implement the outbound block on port 445, you can run the following command from an elevated command prompt:
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
You need to then run the same command, replacing TCP with UDP to complete the block. At that point, you have completed implementation of the rule.
One cool feature in the firewall is the ability to configure rules based on the network interface type. Recall that some rules may impact VPN connections. As long as Windows recognizes the interface as a VPN interface, you can use this type of rule to exempt traffic over that interface:
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
You can do this in the GUI as well, but not until after you create the rule. You then have to right-click on the rule, select Properties, and click on the Advanced tab. There you find an Interface types section where you can select the right interface types.

Outbound Filtering
The lack of outbound filtering in the Windows XP SP2 firewall was held out as the primary proof that the built-in firewall was inadequate for security. There must be thousands of articles written about how insecure the Windows XP SP2 firewall is due to its lack of outbound filtering. This is in spite of the fact that no firewall on Windows XP could securely provide outbound filtering.
The fundamental functionality that transforms outbound filtering into a useful security feature from a mere speed bump—or policy enforcement tool, as I used it earlier—simply does not exist in Windows XP. It does exist, however, in Windows Vista. It is only logical, therefore, that the new firewall makes use of this feature. By default, most inbound traffic is blocked and most outbound traffic is allowed.
By default, outbound filtering in the new Windows Vista firewall blocks only unnecessary traffic from services. This is actually all that can be done to provide protection against a compromise on the host that provides the outbound filters, and doing this on Windows XP would have been meaningless.
Services in Windows Vista can run with a highly restricted token. In essence, each service has its own security identifier (SID), which is unique to that service. This Service SID can be used to restrict access to resources, such as network ports. This is the same functionality we saw earlier when we looked at restricting traffic to users. This means that even though two services may run as NetworkService, they cannot manage each other's processes and the firewall can be configured to allow only one of them to communicate out. If the one that is blocked is compromised, it cannot hijack the allowed service and use its allowed port to communicate out because the port is restricted by Service SID.
This functionality is another one of the very cool security features added to Windows Vista, and the new firewall uses it to actually provide real security value by outbound firewall filtering.
In fact, firewall filtering on service SIDs is enabled by default in the new firewall. However, there is no GUI to configure it. The rules are predefined in the HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices registry key. You should be very careful, however, with modifying that key manually, as this is unsupported.

How Much Security Can Outbound Filtering Provide?
A matter of significant misunderstanding in the security community is how much security value is actually offered by outbound filtering. I have mentioned two scenarios so far that provide security through outbound filtering, but both rely on new functionality in Windows Vista that was not previously available. In spite of this, there is a general perception that outbound filtering is generally good and should be a key factor in firewall purchasing decisions.
Ironically, in many organizations, outbound filtering capabilities drove the purchase decision, and then outbound filtering wasn't used once the firewall was implemented. This is misguided and leads to a waste of money and effort from the Information Security group. It seems to be driven more by a desire to feel good about doing something security-related than by actual analysis of a real threat. Far too often, the desire for this type of "security theater" drives decisions that should instead be driven by facts.
There is a very simple fact about outbound filtering that its proponents fail to take into account. The usual argument from the host-based firewall vendors is that if a system is compromised, whether by a worm or by an interactive malicious user, outbound filtering will stop the worm from infecting other systems or will stop the attacker from communicating out. This is not true.
What is true is that, all else being equal, outbound filtering would have stopped some historical malware. However, if Windows XP had come with outbound filtering, the worms we have seen so far would more than likely have been written to turn it off or else to circumvent it.
On Windows XP (and earlier versions of Windows), any worm running as a service (and all the common worms that come up in conversation did run as a service), could have done this. The only reason they did not is that there were virtually no environments using outbound filtering and therefore it was unnecessary to disable it. In an interactive attack, the attacker can circumvent outbound filters at will. If the attacker has the ability to run arbitrary code, this is easy. But if necessary, the attacker can also lure the user into circumventing the filters.
Circumventing outbound host-based firewall filters can be accomplished in several ways, depending on the scenario of the actual attack. The simplest way to go about it is to "ask" an over-privileged user to do it for you. Too many environments still run their users as administrators. Those users have the right to circumvent security policies at will. All the attacker needs to do is present the user with a choice between some intangible and non-immediate security benefit and something the user values more—the proverbial naked dancing pigs.
In many cases, the user has been so inundated with these types of dialogs that they quickly click without actually comprehending what is happening. This is problem number one with outbound filtering. Given the choice between security and sufficiently enticing rewards, like naked dancing pigs, the naked dancing pigs will win every time because the vast majority of dialogs asking users to make security decisions are devoid of any information that would enable them to actually make such a decision.
Presenting dialogs, asking for security decisions, with sufficient information to base that decision on is much harder than it sounds because it would require the security product, such as the firewall, not just to understand ports, protocols, and the application that is making the request, but also to understand what it is the request really is trying to do and what that means to the user. This information is very difficult to obtain programmatically. For instance, the fact that Microsoft Word is attempting to make an outbound connection is not nearly as interesting as what exactly Word is trying to do with that connection.
We need to reduce the number of meaningless dialogs, not increase them, and outbound filtering firewalls do not help with this. To get a feel for the state of the art in providing users with valuable information, I went and looked at the sales documentation for a major host-based firewall vendor. The glossies tout the firewall's outbound filtering capacity and advising capability. The advising capability detects what the user is trying to do and gives appropriate advice. Or so the theory goes. The text in the brochure was accompanied by a screenshot that says: "Advice is not yet available for this program. Choose below or click More Info for assistance." It seems that even in the marketing material, vendors can't produce informative dialogs.
Since users do not possess sufficient information to make the right security decisions, it would then be incumbent on the administrator to configure all outbound filtering because the end user is not able to. This increases the administration burden of the administrator infinitely.
Even if the user does click "No. Bug me again later" when asked by the firewall, the malware can usually step right around the firewall. As long as the user whom the malicious code is executing as can open outbound connections on some port, the evil code can simply use that port. Thus, any process can piggyback on an existing process. That is allowed on down-level operating systems. Starting with Windows Vista, the processes can be suitably restricted, which is why services, which are the ones that are restricted by default, are blocked using the outbound filters by default.
Unfortunately, most people think outbound host-based firewall filtering will keep a compromised asset from attacking other assets. That is not possible. Putting protective measures on a compromised asset and asking it not to compromise any other assets simply does not work. Protection belongs on the asset you are trying to protect, not the one you are trying to protect against! Asking the bad guys not to steal anything after they have already broken into your house is unlikely to be as effective as keeping them from breaking into the house in the first place.

Jesper M. Johansson is a Software Architect working on security software and is a contributing editor to TechNet Magazine. He holds a PhD in Management Information Systems, has more than 20 years experience in security, and is a Microsoft MVP in Enterprise Security. His latest book is Windows Server 2008 Security Resource Kit.


Security
Secure E-Mail Using Digital Certificates
Matt Clapham and Blake Hutchinson
At a Glance:
  • Creating a verifiable identity
  • Updating certificate status
  • Getting and exchanging certificates
  • Troubleshooting your S/MIME system

For millennia, humans have used various methods to hide information in transit, validate the sender, and authenticate the message. As civilization evolved, one method for doing all three tasks has been developed and is becoming widely used. Secure Multi-Purpose Internet Mail
Extensions (S/MIME) is a system for sending e-mail securely using encryption and digital signatures.
Current encryption (hiding) technologies fall into two main types: symmetric (secret) key algorithms, such as Data Encryption Standard (DES) or Advanced Encryption Standard (AES), and asymmetric (public/private) key algorithms, such as RSA or Elliptical Curve Cryptography (ECC). The modern sender-validation tools are mathematical one-way functions called hashes that make unique signatures. Two commonly used hashing methods are Message Digest algorithm 5 (MD5) and Secure Hash Algorithm (SHA). Computers can use these to generate a unique hash or number that corresponds to the individual source text (identical source texts hash to the same value). These simple tools are leveraged and combined to build a public key infrastructure (PKI) system.

A Verifiable Identity
Certificate Authority Resources
  • Using a Certificate Authority for the Encrypting File Service
  • Certificate Authority Servers Cannot Be Renamed or Removed from the Network
  • How to Remove a Trusted Certificate Authority from Computers in the Domain
  • How to Decommission a Windows Enterprise Certification Authority and How to Remove All Related Objects from Windows Server 2003 and from Windows 2000 Server
  • How to Move a Certificate Authority to a New Server Running on a Domain Controller

Identities within a PKI system are managed using digital certificates, which are not unlike the government identification most people carry across an international border—the passport. The passport standard of the digital certificate world is the X.509 format, and it's widely used for both signing and encrypting in technologies such as S/MIME, Internet Protocol Security (IPsec), Secure Shell (SSH), wireless network security, virtual private networks (VPNs), and even secure server communications (such as SSL Web sites).
Certificates are built on top of asymmetric cryptography and hashes. To create a certificate, the requestor (the entity wanting a key signed by some higher authority) generates a private key. The key is kept locked away so its authenticity is never challenged. Along with the private key, a corresponding public key is also generated. As its name implies, the public portion of the pair is not secret and is distributed freely, though still in some way that ensures its authenticity.
This key pair allows for two fundamental operations. First, anyone can use the public key to encrypt something that only the private key can decrypt; second, the public key can be used to decrypt something encrypted with the private key. This is important for verifying a signature that only a private key could have created.
The request to the certificate authority includes details such as the identity of the person or computer the key is intended for, the algorithm type and strength, and the public portion of the key pair. The certificate authority (CA) receives and validates the information in the request and, using a hash algorithm, creates a unique identifier corresponding to the information.
Using its private key, the CA encrypts the hash of the information and assembles it into a standard format (such as X.509), creating a certificate corresponding to the original request. The X.509 certificate will contain a list of claims including the identity of the certificate (the subject), a validity time frame, the public key, and the operations the certificate can be used for. The certificate is then returned to the requestor; it is a token that states, in effect, "I, the CA, vouch for this public key and the private portion corresponding to it, for all uses described herein."
For root CAs (those at the highest level of the chain of trust), certificates are self-signed. Most acceptable root CAs come preinstalled in the base operating system or application but may be updated or altered via packages or enterprise configuration. Between the root CA and a leaf node (which typically describes an individual person or system), there may be one or more intermediate CAs.
The chain consists of all nodes and all preceding certificates embedded within them, signed by the CA at that level. A third party trying to validate the certificate can check the locally calculated hash and compare it to the one decrypted from the certificate using the corresponding public key for that particular CA or individual. That's it—a completely validated chain of trust from leaf to root—assuming, of course, the root is trusted.

Updating Certificate Status
Every good CA has a means for distributing a list of certificates that should no longer be trusted. This Certificate Revocation List (CRL) describes which issued items have been specifically negated by the CA. Conveniently, the location of the CRL is typically a property of the CA certificate.
CAs routinely issue CRLs on two bases: a schedule (perhaps every two weeks) or an event (some occurrence that indicates an issued certificate should no longer be trusted). A CA will sign its issued CRLs when it publishes them. When a receiving system evaluates the validity of a chain, it typically attempts to acquire the CRL for each issuing CA in the chain (via the details embedded in the certificates themselves or through some predefined trustworthy distribution mechanism). If any CRL is unavailable, the client may fall back on a recent, successfully cached copy as long as it's not older than the specified CRL update period. Failing that, however, the client systems will typically show some sort of error indicating that the certificate appears valid but the revocation status can't be determined.
Many applications take significantly longer to load a certificate if they are unable to validate the chain or the CRL for every node in the chain. Depending on what the certificate was protecting, the user may or may not want to trust it. A routinely updated, widely available CRL distribution point is absolutely necessary for every CA, especially for those public roots.
Roots are the foundation of the certificate chain, and chaining is the foundation of all certificate hierarchies. Most client systems or apps will only assume that a leaf node certificate is valid if it chains back to a trusted root. This could be an enterprise CA, owned and operated by that particular company, or it could be a public root CA (such as VeriSign).
For public root CAs, there are expectations of significant operational expertise so that integrity is assured. Enterprises should strive for the same level for their in-house operations, as the sanctity of a root CA in that context is just as important. For optimal protection, root CAs should actually be kept offline and only used to issue certificates and update CRLs. For more information on CA operational best practices, please see the articles listed in the "Certificate Authority Resources" sidebar.
One important aspect to consider is key recovery. In order to facilitate investigations and to assure that data isn't irretrievably locked away by a user, the enterprise should make backup copies of all user-issued keys. Furthermore, these backup copies should be stored in a safe repository. That way, if a user's key disappears, for example when a smart card gets left behind in a taxi, any content protected by the key can still be accessed.
Finally, within every good cryptographic system is the concept of lifecycle management. As computers get faster, algorithms get weaker. Every good cryptosystem needs the ability to renew itself and shift to new algorithms and key sizes over time. CAs should be updated appropriately when cryptographic weaknesses are identified and certain functions are phased in or out.

Implementing S/MIME
There are several stages to bootstrapping, composing, sending, and receiving signed or encrypted e-mail using S/MIME. We'll cover the details, problems, and potential solutions as we progress through a typical S/MIME scenario: two users sending signed and/or encrypted e-mail to each other from two different Active Directory® forests and different certificate authority chains (that is, from operationally separate entities, whether within the same company or not) using Microsoft® Office Outlook® 2007.
We'll assume that the necessary infrastructure is already in place to enable the operations we are going to describe. In our case, we are using an Active Directory-integrated enterprise certificate server.

Getting Certificates
The first task is to get the appropriate certificates. To do so, you open the Certificate Manager MMC (certmgr.msc), right-click on the Personal folder, select All Tasks on the pop-up list, then select Request New from the list.
This launches the Certificate Enrollment wizard, as shown in Figure 1. By default, several enterprise-centric options will be shown, but the User certificate is the important one. It will be used to enable the signing and encryption processes later. The certificate must be capable of being used for:
Figure 1 Requesting a certificate
Figure 1 Requesting a certificate
  • Digital signatures (creating a message with a seal of authenticity from its creator)
  • Key encipherment (protecting one key with another for technologies such as the Encrypting File System)
  • Secure mail (encrypted messaging that can be read only by the intended recipient in possession of the corresponding pri- vate key)
To send S/MIME signed e-mail, the key encipherment property is not required. However, to send or receive encrypted mail, this property is required, though the signature property is not. By default, the templates in Windows® Certificate Services enable these three properties. If the user is not permitted to request new certificates, none will be shown when the wizard launches. If no enterprise CA is available, the user will be presented with an "Enrollment error" indicating the domain or CA could not be contacted. For this walkthrough, we will assume a single certificate allowing both signature and encipherment.

Exchanging Certificates
The easiest way for two users to start sending encrypted e-mails is to simply send signed messages to each other. After composing a message, the user clicks on the Sign button. (Sometimes the button is hidden by default in Outlook until used at least once. It can be found by clicking on the Options setting for new messages, clicking the "Security Settings..." button, then checking the "Add a digital signature to this message" box on the Security Properties dialog.) The signing button (a little yellow envelope with a red ribbon on it that says Sign) adds a digital signature to the message to establish its source authenticity.
Upon hitting the Send button, the user may be prompted to provide additional tokens of key possession, such as inserting a smart card or entering a PIN. This depends on the particular methods of key protection in place in the organization.
The user receiving the S/MIME-signed message will need to view and right-click on the sender's name (after From:) and select "Add to Outlook contacts" from the context menu, which either adds a new contact entry or updates an existing one. The certificate is then associated with that particular contact entry. Note that within a common Active Directory environment (two users in the same forest or company), public user certificate distribution is done automatically via attributes in the user's Active Directory object.
Another way of exchanging certificates is for each user to send their S/MIME certificate(s) as an attachment. To do this, both parties will need to export their certificate(s) to a CER file. The users will need to view the certificate and follow the export process that we will soon discuss, taking care not to export the private key with it, as shown in Figure 2.
Figure 2 When exchanging certificates, don't export the private key
Figure 2 When exchanging certificates, don't export the private key
Each receiver then manually creates a contact entry in Outlook and adds the certificate to the sender's entry. Once the two users have exchanged certificates, they will be able to exchange encrypted e-mail with each other.

Troubleshooting
Sometimes the receiver has difficulty opening the encrypted message. The three most likely sources of problems we've seen in this area are untrusted root CAs, intermediate CAs that can't be validated, and CRLs that are not available.
An untrusted root CA typically shows in Outlook as an error message associated with the signature: "There are problems with the signature. Click the signature button for details." To solve the problem, open the certificate from within Outlook and click on the "View Certificate Authority" button from the pop-up dialog. Look at the message on the General tab of the certificate properties dialog. If it indicates that the CA Root certificate is not trusted and needs to be installed, go to the Details tab. Click the "Copy to File..." button and follow the wizard, accepting all defaults and providing a file name and folder when prompted.
Now open a new Microsoft Management Console (MMC) as a machine administrator. Go to File|Add/Remove Snap-in (Ctrl+M), select Certificates, and add it for the computer account, choosing Local computer when prompted. Next, expand the Certificates node in the left-hand tree, then do the same to the Trusted Root Certificate Authorities. Right-click and select All Tasks|Import from the pop-up menu. Import the previously mentioned exported certificate file to the Trusted Root Certificate Authorities and click Finish. Then have the affected user restart Outlook.
These instructions should be used only to add a root CA that you know to be trusted. Not all roots are created equal. Carefully consider who owns and operates the root CA before using this method to add a root to the store for the entire system. If your enterprise controls the list of trusted roots via Group Policy, the configuration will be pushed down to client systems. In that case, the instructions may not work. If they don't, you may need to explore alternatives such as secure Web sites or servers for exchanging data, as e-mail won't be a seamless and protected experience.
The second issue noted above, intermediate CAs cannot be validated, typically occurs in two situations: a client attempting to validate the certificate is unable to get to the Authority Information Access (AIA) location defined in the certificate, or the client has a version of the intermediate CA certificate that doesn't match what the CA is issuing (the client is often a version or two behind). These conditions appear very similar within the Outlook user interface. We've only seen it in a very specific circumstance when a mid-level CA in the chain expired and was reissued before other subordinate certificates it issued had expired.
Basically, this problem occurs when the chain has gaps in it. Some parent certificates may not be well-detailed or not embedded in the leaf node appropriately, further complicating the situation.
To resolve this issue, the sender will need to open a new message and click on the new message Options, then on the Security settings button, and then on the Change settings button. Now click the Choose button for the signing certificate, then on the View Certificate button on the pop-up dialog. Go to the Certificate Path tab, select the issuer of the leaf node (that is, up one level in the chain), and click the View Certificate button. Click the Details tab, then the Copy to File... button, then complete the export wizard, selecting PKCS #7 (.P7B). Make sure that the "Include all certificates in the certification path" option is checked, as shown in Figure 3. Finally, send the exported chain file to the desired receiver.
Figure 3 Fixing the gaps in a certificate chain
Figure 3 Fixing the gaps in a certificate chain
After getting the exported certificate chain, the recipient will need to open and import the chain much as we imported a root previously. The one difference is that the chosen storage folder should be the Intermediate Certificate Authorities. If the message opens and the certificate is shown as valid in Outlook, things are working properly.
As for the third issue, CRLs not being available, the fix is comparably simple. The initial response from Outlook will look very similar to the prior issue. However, the error will show even if the root or intermediate signing CAs are trusted. For each level of the certificate chain above the leaf, open the certificate's properties, then the details tab, and look at the field called "CRL Distribution Points."
For each CRL distribution point listed (especially the Internet-accessible ones), verify that the CRL file URL can be opened. As each level validates, move up one level in the chain. If any CRL can't be acquired, it's probably the source of the problem. To resolve the issue, you should verify that your local network policy is not blocking your access. Otherwise, try contacting the company that owns the CA or wait for the CA's CRL distribution point to return to operational status.

Distributing Certificates
Distribution is the easy part. Basically, the signed message is transmitted to a mail server, which then sends it from one location to another via a tried-and-true method, SMTP. The one problem we've seen with signed or encrypted mail in transit is that some mail systems reject or break signed or encrypted messages that pass through them. The fix is to work with the IT manager of the system to get the message types allowed. Of course, you may have to live with the fact that some message types are blocked. The receiving party may have good reason for not allowing encrypted messages in a particular operational environment.

Encrypting Replies
To create an encrypted reply (assuming the above bootstrapping process has already been completed), the sender need only create a message and then click the Encrypt button (the little yellow envelope with the blue lock on it that says Encrypt) in the message composition window. If the Encrypt button is unavailable, follow the steps for sending a signed message, except at the last step, and mark the "Encrypt message contents and attachments" checkbox instead.
S/MIME signing is not required for sending an encrypted message to a recipient, but the two certainly go well together, as signing lets the reader validate the sender (the encryption function makes no claims as to the sender). The encryption process will attempt to encrypt the message with the known public keys of all recipients. If the system is unable to find certificates for some intended recipients, they will be flagged in a pop-up dialog that offers to send the message unencrypted, as Figure 4 shows.
Figure 4 You can decide to send an unencrypted message if you encounter a problem with a certificate
Figure 4 You can decide to send an unencrypted message if you encounter a problem with a certificate
By default, signing and encrypting should work with other comparably configured client systems, but occasionally cross-version encrypted or signed messaging may have issues if the hashing or encryption algorithm is unsupported down-level. We encountered such an issue when sending a signed e-mail (using SHA-512 as the hashing algorithm) to a user running Windows XP SP2. Because the receiving system did not support the hash, the user was not able to validate the signature or read the message. However, it is unlikely users will encounter many problems at this stage unless the Outlook defaults have been changed.
Upon receipt of the message, the intended recipient should be able to open it, provided the private key associated with the public certificate is available. Again, the user may be required to provide an additional token to prove possession of the private key, depending on how it was deployed. Other users who have completed a similar bootstrapping process may take part in similar signed and encrypted communications with the sender. If a user changes his private key at some point (perhaps due to a lost computer), he will need to re-request certificates and redistribute a signed message or certificate file to others wanting to exchange encrypted mail.

Conclusion
Getting signed and encrypted S/MIME working between two users in two different directories or organizations typically isn't much more complicated than what we just discussed. Signing is very handy when used correctly, as it adds authenticity to the message. For sensitive details, encrypted messages provide an extra level of secrecy for data in transit. Combined, the two allow both authenticity of source and secrecy of data. And with the process we've described here, it won't be challenging for most users to take advantage of these capabilities.

Matt Clapham, CISSP, is a Security Engineer in Microsoft IT. He performs security reviews on LOB apps by day and dabbles with technology, gaming, computer music, or security by night. He occasionally speaks to the Puget Sound IT security community. Contact him at matt.clapham@microsoft.com.
Blake Hutchinson is a Support Analyst in the Business Online Services Group (BOSG) at Microsoft. His role includes operational support and project review of in-house-created LOB tools for BOSG's enterprise customers. Blake enjoys photography, skiing, and computer games. Reach him at blakeh@microsoft.com.


From the Editor The Great Debate
Joshua Hoffman

I love a great debate. I'm not talking about pedestrian disagreements, where differing opinions and strong personalities cause mindless clashes. What a waste of time. But a truly great debate, where smart people with opposing points of view come together to passionately present their arguments for consideration—that's a powerful thing. Think enlightenment. Think Socrates.
This month we present you with one of the truly great debates in the IT industry—security by obscurity. I'd explain the concept here, but I have a sneaking suspicion that by the time you finished reading those three words, most of you have already expressed your opinion on the subject, and probably out loud. I'm also willing to wager that most of you fall squarely into one of two camps: either "Security by obscurity is completely useless" or "When it comes to security, every little bit helps".
Well, this month we bring together renowned security experts Jesper Johansson and Roger Grimes to present both sides of this debate. We've also included special supportive commentary for each side from two additional luminaries, Aaron Margosis and Steve Riley. While I'm certainly proud of every page we publish, I have to admit that this is one of my favorite articles in a long time. I hope that, regardless of which side you take in this great debate, you read this piece with an open mind. I'm confident that you'll enjoy it.
This being our annual security issue, there is, of course, much more. We're revisiting some of the topics we covered in last year's issue. One of the most popular pieces last year discussed a set of Script Elevation Power Toys from contributing editor Michael Murgolo, which help run VBScript or Windows PowerShell scripts in an elevated context in conjunction with the User Account Control feature of Windows Vista. Michael received a lot of very positive feedback from that piece, so he's returned this year with a whole new set of utilities to extend his original code. I urge you to give these very powerful tools a try.
Byron Hynes was also with us last year, with an introduction to BitLocker Drive Encryption in Windows Vista. Byron reprises his role with a look at what has changed in BitLocker with the release of Windows Vista SP1 and Windows Server 2008. As well, we have articles on software restriction policies, management of the Windows Vista Firewall, troubleshooting S/MIME, the second edition of our new Inside SharePoint column, business ideas for promoting sustainable computing... the list goes on. Enjoy! —Joshua Hoffman

Thanks to the following Microsoft technical experts: Troy Funk, Aaron Margosis, Michael Murgolo, Steve Peschka, Steve Riley, Mark Russinovich, Jon Schwartz, and Jim Truher.


Letters Readers Speak Out

Windows Backups
I was so excited to read your coverage of Windows Server® 2008 (TechNet Magazine, March 2008, technet.microsoft.com/magazine/cc268370), I went to the launch event and got myself a copy for my home network. Everything went well with the installation. However, I was stumped on the backups.
NT Backup has been removed, and the new Windows Server Backup does not support tape drives, although the OS does. (I back up my personal data, including Active Directory® and Exchange Server 2007, to a tape drive.)
I tried downloading Microsoft® Data Protection Manager (DPM) following the hints on the Web, even though DPM may be overkill for my installation. However, DPM does not install on Windows Server 2008, and I did not have any luck with their manual installation instructions. What are small installations going to do for backups?
—Ravi S.

DPM is indeed the solution for tape backups, as the new solution in Windows Server 2008 is optimized for disk-based storage. DPM will officially support Windows Server 2008 in the next couple of months.
—Karandeep Anand, Senior Program Manager Lead, Microsoft

Survey Workflows
In the February 2008 article "Building a Powerful Survey Infrastructure" (technet.microsoft.com/magazine/cc194407), the following statement is in the Working with WSS Alone section: "You also have the option of assigning a workflow to the survey."
It is my understanding that Windows® SharePoint® Services 3.0 (WSS) and Microsoft Office SharePoint Server 2007 (MOSS) do not support workflows associated with survey responses. I have tried to associate a workflow with a survey response, and while SharePoint Designer allows the association, the workflow always has a Failed on Start error. There is a Knowledge Base article (support.microsoft.com/kb/926370) that clearly states that workflows associated with survey responses are not supported.
I understand that it is possible to link an event receiver to a survey and then initiate some other process, but this really is not a workflow as commonly referenced in SharePoint. Was this statement just made in error, or is there something I am missing here?
—Matt B.

The paragraph referenced talks about how WSS provides a wizard for a step-by-step process to create surveys. There is also a discussion about the various options (branching logic, open/closed questions, and so on).
One of the options that the wizard really provides is assigning a workflow; so, in a way, it's not exactly incorrect to say "you have the option of assigning a workflow to a survey." You are able to assign it. However, as you point out, workflows in surveys just don't work, even though for some reason that option is included. Let me try to explain why this is.
After associating a workflow with a survey and trying to start it, you will receive the Failed on Start error. The logs for this activity show this:
RunWorkflow: System.ArgumentException: Invalid field name.
{<<< GUID>>>} at ...
That GUID represents the workflow instance. It seems like a great way to make sure the right workflow is triggered, except that the "survey" list type does not support the workflow attribute. It's just not coded in. So when the workflow tries to activate with the MakeActivation method and does something like this:
internal static void MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)
{e.EventData = new object[ ] { workflow.InstanceId, new SPWorkflowActivation
Properties(workflow, e.RunAsUserId, associationData, initiationData) };
...
}
it calls SPWorkflowActivationProperties, which looks like this:
internal SPWorkflowActivationProperties(SPWorkflow workflow,
int runAsUserId, string associationData, string initiationData)
{
...
this.m_itemGuid = new Guid((string)
this.Item[SPBuiltInFieldId.GUID]);
...
}
So if it expects the GUID string as an attribute in the survey (which is apparently supposed to be built-in), and the survey does not have the attribute for workflow GUID, it can never work.
There is a possible workaround, so you are on the right track in your thinking about this. The workaround involves creating a custom list that triggers a workflow and linking an event receiver to the survey with ItemEventReceiver. This event receiver creates an item in the custom list, which then triggers a workflow. But you are correct; this isn't really the same thing. To make a long story short—yes, that was a good catch on your part; it does not actually work.
—Pav Cherny, Columnist, Inside SharePoint, TechNet Magazine


Toolbox New Products for IT Pros
Greg Steen

Make announcements over the network
NetSupport Notify
www.netsupportnotify.com
The PC-based work environment is nearly ubiquitous in the office workplace. Most users are in front of their screens during the day and are connected to a network that you help manage. Besides providing a transport for shared resources, applications, and the Internet, your company's network can also be used as part of your organization's strategy for communicating important messages to users. One tool that can help you deliver messages to users across the LAN and wide area network (WAN) is NetSupport Notify, from NetSupport Limited.
This lightweight application server gives you quick and reliable broadcast messaging support. You could, for example, easily alert users about an unexpected service loss to a shared resource, let people know that the security alarm they are hearing was triggered by accident, or notify employees about a building emergency.
Some simple broadcast messaging tools you may come across are limited to the LAN on which they are installed. NetSupport Notify, however, is agent-based, and with its notification gateway component, it can easily traverse your network topology, reaching both Windows® and Mac clients, whether they are connected directly, over a wireless connection, or connected via virtual private network.
The notification service runs as a Windows service, and you connect to the service via the administrative notification console, which can be installed on the same or a different machine. Notifications from the service are classified into one of three levels of severity: message, alert, or a critical. Once a message is received by the client, an event log entry is made and the server is notified that the message has been received. Other message options include playing a beep in addition to showing the window, forcing the notification to always be visible, and setting an automatic timeout on the message to self-close.
You can also choose to target just specific notification groups. The notification console can connect to multiple notification servers, so one console can be the center of the message broadcast.
In addition to the server and console, NetSupport Notify also includes a deployment tool that allows you to remotely deploy the agent to your end users, saving you a visit to the desktop. You can specify target machines by IP address range or through Windows networking domains and workgroups discovery.
The deployment console also gives you a quick view of your network, showing you the version of the agent installed along with vitals, such as the DNS name, MAC address, IP address, platform, and whether the console has access to the remote machine. If you use Active Directory®, you can manage the configuration and deployment via group policy.
To protect against unauthorized broadcasts (such as "Hey, there's a party in my office at 4:00!"), the agents and consoles employ a security code similar to a Windows Management Instrumentation (WMI) key string. In addition, you can control the ability to send alerts through Active Directory policy.
Price: Starts at $180 for a 75-user license.
Deliver announcements to your employees with NetSupport Notify
Deliver announcements to your employees with NetSupport Notify

Monitor your network
NetOptics: Teeny Tap
www.netoptics.com
Used in combination with a good monitoring application, passive network taps can be a vital tool in troubleshooting flaky networks, fixing misbehaving applications, and mitigating potential threats to your infrastructure. One cool tap that was brought to my attention for 10/100 networks is the incredibly portable Teeny Tap from NetOptics.
This, well, "tiny" 3.125 inch by 1.5 inch device provides full-duplex traffic monitoring from Layer 1 up, allowing you to easily spot-check or continuously monitor traffic on your 10/100 network. The device achieves full-duplex monitoring with its two monitoring RJ45 ports, which give you a deep view of traffic flowing on both sides of its two network ports when both are connected to your network monitor, protocol analyst, IDS/IPS, or other probe.
Teeny Tap does not require an IP address. By isolating you from the network, you are able to remain invisible to those who may use your presence as a cue to stop fiddling with the network. Meanwhile, the Zero Delay feature ensures that a power loss to the tap will not affect the flow of traffic through the tap—there should be no delay or packets lost.
The tap can be powered by USB or with the included power supply; or you can use both for redundancy, which is a notable capability for such a small device. Teeny Tap is also compatible with Power over Ethernet-based services, such as network cameras and IP telephones. Thus, you could also monitor traffic there to ensure your communications are secure.
The Teeny Tap kit includes the tap, a universal power supply, two cross-over and two straight-through RJ45 cables, and a carrying case. If you require a bit more horsepower in your environment, you may want to check out some of the other network tap products that are offered by NetOptics. The line of products covers the gamut, scaling from small office networks to large enterprise environments for both copper and fiber networks from 10MBs to 10GBs.
Price: $325 (direct).
Monitor your network with Teeny Tap
Monitor your network with Teeny Tap

Optimize your computer
DTweak Pro
www.daoisoft.com
As an IT professional (and general tech junkie), you undoubtedly have the desire to tweak your system and squeak out as much performance and as much of a customized experience as you can for your day-to-day activities. There are a bunch of tools out there to help optimize and customize the user experience on your computer running Windows Vista®. One low-cost option is DTweak Pro from Daoisoft. (A version is also available for Windows® XP and Windows Server® 2003.)
The application offers a number of quick access views to different tools and customizations for Windows Vista. For example, in the Daily Tools section, you can run a registry cleaner, a file cleanup utility, registry and disk defragmentation tools, and a hard-disk performance monitor.
With DTweak, you can also easily see and tailor your startup items, get CPU information (including the CPU ID, bus speed, and clock speed), and gather computer information, such as the vendor, bootup state, memory configuration, and system type. You can even tweak your I/O cache memory and the amount of time to wait for ending crashed programs and hung services.
The GUI's Tools section provides links to built-in Windows Vista tools, including diskpart and system restore, as well as links to handy network tools, such as finger, ping, netstat, and nslookup. Other network tweaks include adjusting your maximum transmission unit, TCP/IP TTL, and DNS timeout settings, and limiting your bandwidth with the QoS packet scheduler service.
Price: $29.95 (direct download).
Tweak and optimize your system with DTweak
Tweak and optimize your system with DTweak

Book Review
Microsoft Exchange Server 2007 Administrator's Companion
www.microsoft.com/mspress
E-mail can be a finicky beast. For instance, you have no real control over the flow of incoming messages. If you try to stave off the incoming flood by suspending your SMTP server until its queues are reduced, you risk having the sender receive a "message undeliverable" notice. The analogy of a plumbing system is very accurate—water is always flowing, and if you crank down a valve in one section, you risk a burst pipe in another. A well-planned, well-tuned, and flexible e-mail infrastructure is critical if you want to keep your business at large running smoothly.
Obviously, Microsoft Exchange Server® 2007 is designed to handle enormous volumes of mail, and it is designed to allow you to tailor your infrastructure to meet the needs of your organization—both today's needs and tomorrow's. But there are so many options and decisions for you to make in an Exchange 2007 deployment. And Exchange covers much more than e-mail, further complicating the task.
You really need to have a good reference or two to help you make the right architectural and management decisions. One reference that can be indispensable is the Microsoft Exchange Server 2007 Administrator's Companion.
This book covers the product deployment lifecycle, from planning and deployment to maintenance and security. It also discusses the various clients and client connectivity options available for Exchange 2007. It starts out with an overview of the differences between the various versions and a look at what's new in Exchange 2007. You also get a full overview of the different architectural components of Exchange Server 2007.
The following section explains how to plan for deploying Exchange and shows you how to calculate your storage requirements, server and processor requirements, and add fault tolerance. The book then covers the actual installation and deployment, showing you how to get your server ready for Exchange and how to install the different components of the software. You even get an in-depth reference to clustering Exchange services to achieve a higher level of availability.
The book next covers the numerous management tools at your disposal, such as the Exchange MMC panel and the new Windows PowerShell™-based Exchange Management Shell. Here too you'll learn everything from how to create mailboxes to creating storage groups and backup and restore operations. Another nice thing about this section is that is shows you how to do all those operations both with the management GUI and via the commandline with Windows PowerShell.
Exchange 2007 has a number of Unified Messaging features, which allow you to manage both data and voice communications with one system, and the book also shows you how to set and use voice messaging, fax messaging, and voice-based inbox access, to name a few.
Delving into maintenance, the book covers basic troubleshooting techniques and tools, corruption and disaster recovery, and performance tuning. Security, obviously, should be of paramount concern to any unified messaging system—the book has in-depth info for securing your deployment. You learn about security policy and guidelines, antivirus and anti-spam features, and the public key infrastructure.
Finally, the book explores Exchange clients and how to support other POP3 and Internet Message Access Protocol clients in your organization. All in all, this is a good general reference for any administrator, whether she is planning for, maintaining, or just interested in the Exchange Server 2007 server unified messaging platform.
Price: $49.99 (list).

Greg Steen is a technology professional, entrepreneur, and enthusiast. He is always on the hunt for new tools to help make operations, QA, and development easier for the IT professional.


Windows Vista Top Security Features in Windows Vista
Anthony (A.J.) Smith and Ned Gnichtel

Contents
User Account Control
Internet Explorer Protected Mode
Standard User Support
BitLocker Drive Encryption
Windows Resource Protection
Services Hardening
Advanced Firewall
One of the most common questions customers ask is, "Why should we upgrade to Windows Vista?" There are a lot of reasons to upgrade, but the new security features are among the most significant. Security was a top priority during Windows Vista development, and Microsoft believes the new operating
system is fundamentally more secure than previous versions of Windows®. In this article, we will describe some of the most important security features introduced with Windows Vista®.

User Account Control
From the user perspective, User Account Control (UAC) enables automated elevation request processes, thus notifying users when a program or action requires elevated (administrator) privileges. This solution is far more satisfactory than the "Run As" elevation model present in previous versions of Windows, as it doesn't require that the user know in advance when specific actions or programs require elevated privileges to run correctly.
UAC provides a much safer environment when privileged and non-privileged applications share the same user session and desktop. To achieve this, UAC is built upon a core enabling technology called Mandatory Integrity Control (MIC). MIC implements integrity levels that essentially override the standard Windows NT® discretionary access control model by preventing processes with a lower integrity, such as those of a standard user, from writing to higher-integrity objects and processes that belong to the system or an administrator. This has several important benefits:
  • It prevents lower-integrity processes from modify higher-integrity system objects and registry keys.
  • It provides a first layer of protection against common shatter attacks, wherein malicious code attempts to use window messages to probe and then implement privilege escalation by having vulnerable, elevated processes run arbitrary code.
  • It prevents lower-integrity processes from using window messages to drive the user interface of an elevated process.
UAC uses this functionality to enable a key scenario called Admin Approval Mode (AAM). For home and technical users, AAM is the most common UAC mode, wherein a user logs on interactively with a user account that is a member of the Local Administrators group.
The Logon Security Authentication Subsystem, unlike in previous version of Windows, creates only a standard user security token for the base interactive session when UAC is enabled. When a user needs to run a process, or execute an action, that requires the full admin token, that new process is then instantiated, after the user is prompted via a dialog box shown on the secure desktop (see Figure 1), with a full administrator token.
Figure 1 The user is prompted for administrative credentials when necessary
Without MIC, it would not be possible for UAC to enable the AAM scenario because there would be nothing stopping a process running with the standard user privileges from interacting with the elevated process for the purposes of privilege escalation since both are running with the same user account. This would allow any arbitrary process, such as accidentally executed malware launched by the user, to attack privileged processes.
Even in scenarios where the user is configured to logon as a standard non-privileged user, MIC provides an effective barrier against "shatter" and other user interface attacks for elevated processes that share the session and desktop with non-privileged processes. In Windows XP, unlike in Windows Vista, it is possible for processes running in the user's standard account context to probe other processes, launched with an administrator's elevated privileges via "Run As," in order to attack privileged processes.
It is important to note, however, that for all the sophistication underlying UAC, it is not a true security boundary. UAC, through several well-known mechanisms, can be defeated (though when configured in its most stringent form, UAC attacks are not trivial). But UAC does provide basic impediments to the most common types of privilege-escalation attacks.
Most importantly, with the advent of AAM, by default all Windows applications, unless flagged to request elevation, run with standard user privileges, regardless of administrator group membership or explicitly granted privileges. This is the UAC's most important accomplishment, forcing the Windows application ecosystem to provide applications that run correctly under standard user privileges.

Internet Explorer Protected Mode
Another security technology that takes advantage of MIC is Internet Explorer® 7 Protected Mode, available in Windows Vista. This functionality is implemented by running Internet Explorer, when UAC is enabled, with an integrity level below that of a standard user, significantly reducing the ability of Internet Explorer to modify data or install applications.
As Figure 2 shows, Protected Mode restricts the locations where Internet Explorer can write. By using MIC to effectively sandbox Internet Explorer, it prevents malware profile injection and hijack attacks even if Internet Explorer is compromised.
Figure 2 The two broker processes let Internet Explorer perform elevated operations, as long as the user consents
To allow Internet Explorer to function normally, a compatibility layer redirects certain applications to temporary Internet Explorer file locations, which have their directory integrity level set to low. Any attempt to write files or otherwise interact with files and processes running with "Normal" integrity is implemented through a special broker process called IEUSER.EXE. In combination with running with standard user privileges, Internet Explorer Protected Mode provides substantial protection against the newest forms of malware attacks.

Standard User Support
For corporate customers, Windows has historically proven a challenging system to configure for the standard user account context due to application compatibility as well as a number of common user actions that required elevated privileges. To better support the use of standard user accounts, Windows Vista implements two new sets of functionality: Registry & File System Virtualization to better support legacy applications, and new privileges and management functionality.
Because all applications, by default, now run as a standard user, Windows Vista will try to automatically assist applications that attempt to write to admin/system restricted portions of the OS, such as the system portions of the registry and the OS system directories. It does this by redirecting read or writes to these areas to special virtualized locations in the user's local profile. In essence, the application believes it is writing to those sensitive locations, but it is actually writing to the user's profile. This allows most legacy applications to run on Windows Vista successfully without modification.
To further support the standard user scenarios, Windows Vista implements several additional key features. Standard users now can:
  • Change the displayed time (not the actual system clock) using the Change the time zone privilege (see Figure 3).
  • Configure Wired Equivalent Privacy/Wi-Fi Protected Access (WEP/WPA) settings when they connect to wireless networks (or conversely, profiles for wireless can be centrally managed via Group Policy).
  • Change power management settings.
  • Install critical Windows updates (or this can be enforced by administrators).
  • Install printer and other device drivers approved by IT administrators, as well as ActiveX® control controls from administrator-approved sites, if enabled via Group Policy settings.
Figure 3 Standard users can now change the time zone

BitLocker Drive Encryption
BitLocker™ is the Microsoft full volume drive encryption technology that is available with Windows Vista Enterprise and Ultimate editions. With the introduction of SP1, this technology allows for the encryption of multiple volumes on a computer using one or more authentication factors, as Figure 4 shows.
Figure 4 You can encrypt multiple volumes using BitLocker
If the system has a trusted platform module (TPM) version 1.2, this component can act as an authentication factor, as can a USB memory stick or a PIN. If a user were to ever lose the USB memory stick or forget the pin, or if a member of the IT department needed access to the machine, a 48-key recovery password can be used to access the volumes. This password can be automatically stored in Active Directory® when BitLocker is enabled for domain-joined computers.
If there's a TPM chip, BitLocker will also check the integrity of the boot configuration data to insure that this data has not been modified or that the drive has not been removed from the machine and installed in another. The encryption used by BitLocker is very secure, with the "AES 128 bit with Diffuser" setting as a default. BitLocker can also be configured to use AES 128, AES 256, and AES 256 with Diffuser via Group Policy.

Windows Resource Protection
Windows Resource Protection (WRP) is a technology that restricts access to certain core system files, folders, and registry keys that are part of the Windows Vista installation. WRP prevents files with .dll, .exe, .ocx, and .sys file extensions from being modified or replaced.
Protecting these key resources is important to overall system stability, and, as such, they can only be modified by the Windows Module Installer service (TrustedInstaller.exe). If someone with administrative rights attempts to modify or replace a file that is protected by WRP, he will be presented with the message shown in Figure 5.
Figure 5 Access to resources is restricted in Windows Vista

Services Hardening
Services have been critical to the Windows NT family of operating system for years. While the service model provides important functionality, services have been the target for malicious software attacks because many are network facing and a number of them have historically run the highest privileged account, "LocalSystem." These factors, combined with the fact that services tend to run continuously from startup to shutdown, makes them popular attack targets.
In an effort to make services more secure, Microsoft decided to make some significant changes to how services operate. In particular, services can now run with "least privilege." Instead of having to choose either a high-privilege account, such as LocalSystem, or lower-privilege accounts, such as LocalService and NetworkService, which may not offer adequate functionality, developers can now use any account (including domain and local), and, by specifying the required privileges, the Service Control Manager will remove the unnecessary privileges.
Moreover, Windows Vista adds a number of new, built-in service accounts for granting specific rights to services. These built-in accounts remove, in most cases, the need for domain-wide service accounts, and all password management for the built-in accounts is automatically managed by the OS.
In order to isolate services, developers were given the ability to create a unique service identifier (SID) for their services. Once the SID is created, the developer can set the access control list (ACL) on an object to allow the service access to the object.
To enhance the SID further, developers can also make services more secure by using a write-restricted token to specify that the service can only write to locations it has been given explicit write access to. For example, if a service uses the LocalService account and a unique SID to gain access to "HKLM\Windows\Application X", that service has access to that registry key and to all other objects LocalService has access to. However, if the write-restricted token is added, the service only has access to the Application X registry key and not to any of the other locations LocalService can access.
A final substantial change to the service model in Windows Vista means that all services now run in an isolated Session 0. Historically, Session 0 was shared with the first locally logged on user and thus provided an attack vector to services. With Window Vista, all interactive sessions now run as Session 1 or higher, effectively isolating services from interactive processes.

Advanced Firewall
One of the most important new enterprise features of Windows Vista is the new network stack with its myriad advanced security features. The Firewall and IPsec functionality are now built on a new subsystem called the Windows Filtering Platform (WFP), which provides both the core firewall functionality and is also fully extensible by third parties via a well-documented call-out infrastructure. This allows third parties to provide, for example, application layer filtering as an addition to the existing stateful firewall without having to use unsupported hooking.
Figure 6 shows some of the advanced security that the new Windows Firewall provides. Core features provided in the new Windows Firewall are advanced inbound and outbound configurability, including restrictions based on application path and executable as well as service accounts and groups. Furthermore, connections can be restricted on a per-profile basis and can be subject to Internet Protocol security (IPsec) connection policies. And all of the built-in functionality can now be managed entirely via Group Policy.
Figure 6 Windows Firewall with Advanced Security
As you can see, Windows Vista comes with a host of new security features that not only protect against attacks but also limit the damage that attackers can do if they do gain access to a computer. If you were wondering why you should upgrade to Windows Vista, now you know. 

Anthony (A.J.) Smith is a Windows Client Technology Solution Professional with the Microsoft Enterprise and Partner Group (EPG), focusing on Windows Vista deployment and adoption in the New York City area. Prior to joining Microsoft, he spent his career focusing on desktop technology and worked in desktop support, planning, and deployment roles. Anthony is also a regular contributor to the TechNet NY Metro Core Infrastructure Specialist Team Blog at blogs.technet.com/nymciblog.
Ned Gnichtel is an Account Technology Specialist with the Microsoft Enterprise and Partner Group and supports next-generation technology adoption for several of Microsoft’s Fortune 500 and strategic customers. Prior to joining Microsoft, Ned served as the Chief Technologist for distributed systems at a nationwide IT consultancy. Ned’s career has spanned multiple technology disciplines including operating system internals and device driver development, IT infrastructure development, and directory services infrastructure. Ned can be reached for questions at edwingn@microsoft.com.


Column Title Here
Learning from the Quincy Datacenter
Sustainable Computing
At CeBIT 2008, which took place this past March in Germany, Steve Ballmer discussed how the Datacenter Group at Microsoft is making efforts to develop sustainable datacenters and share the best practices it learns in the process. A major example of these efforts is the Microsoft datacenter located in Quincy, WA—the facility is
Contents
1. Modular and Efficient
2. Phased Building
3. Find the Sweet Spot
4. Organize for Collaboration
5. Monitor and Report
6. Efficient Commissioning
7. Prepare for High Loads
8. Reduce Water Use
Wrapping Up
powered entirely by hydroelectricity. And the facility is sizeable. If you walked around one complete building (there are currently two buildings, with more being built over time), including the space for IT, power and cooling equipment, the receiving area, and the office space, you would travel 1.3 miles.
I recently had a chance to take a tour of the Quincy datacenter, and now I get to share some of the methods used in building and operating a sustainable datacenter. (There is a video of the Quincy datacenter available at download.microsoft.com/download/8/7/d/87d2d871-471e-44a3-bfd0-c02d3248b8cb/Energy%20Efficiency%20in%20Datacenters-022808-Med.wmv.)
In the first installment of this column, I introduced the idea of "Putting IT on a Diet" (see technet.microsoft.com/magazine/cc462802). This concept, as well as other key elements of environmental sustainability, can be found in how Microsoft designs and operates its datacenters. Here is a look at eight strategies Microsoft employs to make the most out of every bit of energy the Quincy datacenter consumes.

  1. 1. Modular and Efficient
The lifespan of a datacenter can be 20 years. One key design goal is to minimize the resources required to build and operate the facility over that entire lifespan. Over a 20-year period, equipment will undoubtedly change. To simplify improvements that will lead to better efficiency over time, Microsoft designed the Quincy building in a modular fashion, allowing components to be upgraded without taking down the entire facility. With only about 50 people required to operate the facility, workflow efficiency is important to ensure the best use of those resources and allow work to happen quickly.

  1. 2. Phased Building
When you look at the Quincy datacenter building, it looks like one building. However, it is actually two separate buildings. The most efficient datacenter is a full datacenter. Microsoft, therefore, filled the first building to capacity before putting a single piece of equipment into the second building. This approach is being repeated throughout the site, as there is room for three more datacenter buildings, and one of these buildings can be built in as short a time as 10 months. By building the datacenter infrastructure when it's needed, Microsoft can improve the power and cooling efficiency of the datacenter and eliminate the waste that results from over provisioning capacity.

  1. 3. Find the Sweet Spot
One technique a Microsoft engineer explained to me is the concept of designing around the sweet spot of performance for each piece of equipment. Every piece of equipment has a range of optimal performance, and holistically achieving the right combination improves the overall efficiency.
Microsoft evaluated multiple permutations of equipment capacities and efficiencies to find the right combination for their power and cooling needs. Unfortunately, the exact combination is unique for every environment and even Microsoft continuously evaluates and optimizes the equipment combinations as new technologies are developed. So there is no magic recommendation here, other than that you'll need to test a variety of configurations to find the best configuration for your environment. And keep testing over time to find improvements.

  1. 4. Organize for Collaboration
You may be thinking, "I'm a system administrator and it sounds like the Microsoft datacenter efficiencies were done by the facilities staff." Given the dynamic IT environment and how quickly technology changes, a tight partnership exists between the IT pro and the facilities staff. In fact, facilities program management and the technical program manager report to the same datacenter manager who in turn oversees the whole datacenter operation. The accountability for sustainable and efficient operations falls under one organization.

  1. 5. Monitor and Report
The Quincy datacenter incorporates energy monitoring of all systems, providing real-time data. The data is recorded and archived for historical trending and analysis. The staff focuses on electricity as the most important resource, not space. Power stranded in one area, that therefore can't be used is one type of the waste Microsoft looks for. The reports are shared with hundreds of Microsoft employees to help them understand the efficiencies of the operations and how much energy is consumed to provide particular services.
Common questions asked by people on staff include: What is the overall efficiency of the datacenter (measured by PUE)? What are the actual versus calculated power usages? How much capacity does my group have? What are the electricity costs for my business unit?

  1. 6. Efficient Commissioning
Efficiency starts the moment servers are delivered pre-populated in racks. This eliminates the bulky packaging typical used for server shipments. The only packaging required is the wooden shipping crate, which is recyclable. Just a matter of hours after a server shipment arrives, equipment is ready to be deployed and operating. The staff estimates that they can commission the space of one of these buildings in as little as three months.

  1. 7. Prepare for High Loads
One of the downsides of running at higher efficiencies is the equipment is run at high load conditions. Since the current industry norm is underutilization, this can cause problems.
As Microsoft was filling up the server rooms, some pieces of equipment began to display problems as they neared capacity. When contacted, vendors were actually surprised to hear that Microsoft was consistently running this equipment at high load conditions, as most of their customers do not come close to capacity ratings.
So Microsoft operations recommends that if you are going to run at high loads, make a high load test part of the acceptance criteria. Keep this in mind for projects such as server consolidation, as a higher power concentration in a rack can create high loads.

  1. 8. Reduce Water Use
The Quincy datacenter is located in the middle of farmland near the Columbia River. Besides offering a good source of electricity, this provides an ample supply of water. However, water for agriculture does not provide a lot of waste water since the water evaporates or soaks into the ground.
Datacenters use a lot of water for the cooling system. After use, the water is sent to the local waste water treatment facility. Unfortunately, the waste water system in Quincy was not ready to handle the quantity of water resulting from a datacenter. In this case, Microsoft built a water treatment facility to reduce the waste water, drastically lowering the datacenters water use. For another facility (located in San Antonio, TX), Microsoft developed a plan to use gray water from other industries, making their water use a non-issue.

Wrapping Up
When you put IT on an energy diet and start designing more sustainable solutions, it's a good idea to see what you can learn from others. Seeing what issues other organizations have encountered and how they have addressed these issues will give you ideas on what to look for and what you can do to improve your operations.
One of the goals of the Microsoft Datacenter Group is to help the overall industry find ways to operate more efficiently. To help spread more efficient practices, the group participates in industry organizations such as The Green Grid (www.thegreengrid.org), Climate Savers (www.climatesaverscomputing.org), ASHRAE (www.ashrae.org), AFCOM (www.afcom.com), and The Uptime Institute (uptimeinstitute.org).
I'd like to thank the datacenter staff in Redmond, WA and Quincy for providing me with the opportunity to see how Microsoft runs a sustainable, energy-efficient datacenter.


SQL Q&A I/O Errors, Database Mirroring, and More
Paul S. Randal

Q I've started running regular consistency checks on the databases that I manage, and I've even added some SQL Agent alerts to catch any I/O errors that user queries encounter. I don't know if the logic I've implemented around the checks and alerts will work because none of my databases have corruption issues. How can I create some corruption in a test database so I can make sure everything I've set up works correctly? Also, is there anything else I should do to detect I/O errors?
A In SQL Server® 2000, the old trick to create a corrupt database for testing was to manually delete a row from the sysindexes table of a test database. But with SQL Server 2005, corrupting a system table in such a manner is very difficult. The best way to corrupt a test database yourself is to use a hex editor to alter a data file while the database is shut down. Here's what to do:
  • Shut down the database so the data files are not locked. (Be careful that you don't detach the database, though, because if you corrupt the wrong page, you may not be able to attach it again.)
  • Pick an offset more than, say, 100 pages into the file (at least 819200 bytes), but make sure it's aligned on an 8192-byte boundary (a page boundary). This avoids critical metadata pages and allocation bitmaps, letting you start the database and run DBCC CHECKDB on it.
  • Write a few bytes of zeroes into the file at the chosen offset. Using this technique is almost guaranteed to introduce some page header corruption errors.
That said, the fastest way to create a corrupt test database is to use one that someone else has already created. You can find samples of corrupt SQL Server 2000 and SQL Server 2005 databases (with explanations) on my blog (at go.microsoft.com/fwlink/?LinkId=115151).
As for your second question concerning what you should do in order to detect I/O errors—you should enable page checksums. This feature was introduced in SQL Server 2005 as a way of protecting an entire database page from errors that were introduced by the I/O subsystem.
Basically, when a page is written to disk, the last thing SQL Server does is calculate a checksum over the whole 8KB page and stamp the checksum on the page. When a page is read from disk, if it has a page checksum, the checksum is recalculated and compared to the one stored on the page. If they don't match, something outside SQL Server corrupted the page and an 824 error is raised. The error is displayed to the connection that caused the page to be read, as well as logged to the SQL Server error log and the Windows® Application Event Log.
Page checksums are on by default for all databases created on SQL Server 2005 and SQL Server 2008. However, they must be manually enabled for databases upgraded from previous versions of SQL Server. You can enable page checksums with this code:
ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

Tip: Change the Default SQL Server Port
By default, the configured port of SQL Server instances is 1433. Once this port is used by an instance, it can't be occupied by another instance. Therefore, if you install a second (named) instance listening on the net using tcp, it will need another port. And in some cases, the administrator may want to change the port for obfuscation reasons (though this form of obfuscation is minor and can be easily broken by a port scanner). Of course, you then have to configure the client to use a different port. There are three common approaches to do this.
First, assuming the admin changed the port of an instance to 5555, you can either simply specify the port number of the instance within the machine name you want to connect to using the syntax MyServername,5555. If the port changes again, the clients will have to change their connectionStrings again as well.
Another option is to use SQL Server Aliases, which are configured on the client. Besides specifying an alias name, the server name, port name, and protocol must also be specified. Once configured, the alias can be used like a server name to connect to the database instance. The advantage with this option is that server configuration changes can be deployed by a domain administrator, as the settings are stored in the registry.
The third option for named instances where the user only knows the instance name and specifies the name using MachineName\InstanceName within the connectionString is to use the SQL Server Browser Service. This is already implemented in SQL Server 2000 as a part of a running service. However, in SQL Server 2005, SQL Server Browser Service was built as a separate service. Besides doing instance discovery for the machine, it also answers incoming User Datagram Protocol (UDP) requests on port 1434 with the appropriate port number for the requested instance, enabling redirection for the client and supporting a transparent connection.
—Jens K. Suessmeyer, Database Consultant at Microsoft

Q To remove all the fragmentation in my database, I've set up a nightly maintenance plan that rebuilds all the indexes in the production database, which is running on SQL Server 2005 Enterprise Edition with SP2. I've noticed that this causes the database to grow excessively, so I added a step to shrink out all the extra space, as there isn't much space on the disk. Now it seems like the rebuild step isn't working. What's going on?
A You've hit upon a common problem people face when setting up a maintenance plan. You're caught in a shrink-grow-shrink-grow cycle.
When an index is rebuilt, a new copy of the index is created before the existing index is deleted. This procedure requires extra space in the database files—usually around the same amount of space that the current index uses. In SQL Server 2000, extra space was also required for sorting the index rows (roughly 20 percent of the size of the index), but that requirement has been eliminated for a simple index rebuild in SQL Server 2005.
Admins sometimes want to remove the extra space that was created during the index rebuild, so they add a shrink operation to the maintenance plan after the rebuild step. It is not widely known, however, that this shrink will cause index fragmentation due to the nature of its algorithm. This means that the newly rebuilt and defragmented index will immediately become fragmented—canceling out the effect of rebuilding it in the first place.
Given that the database file will just grow again the next time the index rebuilds take place, it is better to allow the database to have the extra space in it and entirely avoid running the shrink operation. (In addition, continually growing and shrinking the database files will cause file fragmentation at the OS level—which can contribute to poor performance in the same way as index fragmentation.)
Finally, one thing you might consider is reducing the frequency of when you rebuild indexes. You may even want to try using an alternative method, such as the old DBCC INDEXDEFRAG that I wrote for SQL Server 2000 or the newer ALTER INDEX REORGANIZE syntax in SQL Server 2005 and SQL Server 2008.
There is a useful white paper that discusses index fragmentation and gives guidance on when to remove fragmentation (at go.microsoft.com/fwlink/?LinkId=115154). While this paper was written for SQL Server 2000, the concepts are still the same.

Q We've been evaluating the disaster recovery strategy at my organization, and I think database mirroring is the right way to go for our situation. The server I'm trying to protect has a lot of unrelated databases (the result of a prior server consolidation project), and I'd like to use database mirroring for all of them. The question I'm struggling to answer is how many databases will I be able to mirror before performance starts to degrade?
A The answer to this question is one I use very frequently: It depends! The published guidelines say not to mirror more than 10 databases per instance, but 10 is just a rough guess at what the maximum will be for most users. You need to consider the following factors for your hardware setup:
  • How much memory do the principal and mirror instances have? (Ideally, this should be the same.)
  • How much processing power do the principal and mirror instances have? (This should also be the same.)
  • How much bandwidth does the I/O subsystem have on the mirror instance? (This should be the same as on the principal.)
  • How much transaction log does the workload on each of the databases generate?
  • How much network bandwidth is available between the principal and the mirror instances?
The last two factors are the most critical. If the network bandwidth available between the two instances is not enough to handle the combined transaction log generation rate per second from all the databases being mirrored, then performance will drop on the principal databases. SQL Server 2008 helps alleviate some of this burden with log stream compression.
The next most critical thing to consider is the memory and thread requirements for mirroring. Each mirrored database takes one thread plus some memory. On low-powered servers, lots of mirrored databases may be too much load on the server when combined with the regular workload.
You also need to consider how you're going to run database mirroring. In synchronous mode, transactions on the principal database cannot commit until all the transaction log records have been copied to the mirrored database's transaction log. Therefore, any delay caused by an overloaded network could cause a workload performance issue on the principal.
In asynchronous mode, transactions can commit on the principal without having to wait, but a network delay could cause the amount of transaction log waiting to be sent to the mirror to grow. This can cause issues with transaction log size. Worse, any unsent transaction log will be lost in the event of failure—so the more unsent transaction log, the more potential there is for data loss in a recovery situation.
Scenarios can vary greatly, and I've seen some interesting examples in real production environments. For instance, I saw one environment with 150 databases, all of which had very small amounts of activity and not all at the same time. All 150 database are mirrored with no problems.
On the contrary, I've seen a setup that has only three heavily loaded databases, but without a good network connection. In that scenario, they can barely mirror one database before the lack of network bandwidth causes workload degradation.
The key to success is to, first, do the log generation calculation. If it seems that the available network bandwidth will support the number of databases you want to mirror, you may be OK. Test your configuration before you put it into production and make sure to include all operations that could generate transaction log—especially any database maintenance you may do.

Paul S. Randal is the Managing Director of SQLskills.com and a SQL Server MVP. He worked on the SQL Server Storage Engine team at Microsoft from 1999 to 2007. Paul wrote DBCC CHECKDB/repair for SQL Server 2005 and was responsible for the Core Storage Engine during SQL Server 2008 development. An expert on disaster recovery, high availability, and database maintenance, Paul is a regular presenter at conferences. He blogs at SQLskills.com/blogs/paul.


Utility Spotlight Windows Vista Upgrade Advisor
Lance Whitney

It's finally time to start planning your organization's upgrade to Windows Vista® and, as with any upgrade, there are questions. Do your network clients meet the hardware and software requirements? What compatibility issues will you face? To help answer these and other questions, Microsoft provides the free Windows Vista Upgrade Advisor. This utility scans all installed hardware and software on a PC to determine if an upgrade is feasible. If it is, the Advisor recommends the optimal version of Windows Vista and reveals any issues to address before upgrading.
The Upgrade Advisor scan typically takes several minutes. While the scan runs, a chart lists the different versions of Windows Vista, comparing the features of each. You can also select a specific edition—Ultimate, Home Premium, Business, or Home Basic—to view a brief description and list of prominent features. After the scan completes, the Report Details screen tells you whether your PC is Windows Vista-capable and which version is advisable. Details include:
System Requirements This tells you if your hardware—CPU, RAM, video memory, and CD/DVD drive—are sufficient. If this is not the case, you'll see details on what is needed to upgrade your PC, for example, how much memory you need to add.
Devices This examines all external devices and drivers, including modem, printer, scanner, sound card, monitor, and video card. If a device doesn't pass the compatibility test, the report explains what action to take, such as downloading the latest drivers from the manufacturer's Web site. A link to the Web site is conveniently provided.
Upgrade Advisor reports known compatibility problems and recommends ways to resolve them
Upgrade Advisor reports known compatibility problems and recommends ways to resolve them
Programs This analyzes installed software. You'll learn which applications are able to run under Windows Vista as they are and which ones are incompatible or need to be upgraded in order to pass the test.
If any of the components fail the compatibility test under a more powerful version of Windows Vista, such as Ultimate, you can return to the introductory screen and select another version, such as Business. Then you'll be able to see if your PC meets all requirements of that version.
Finally, a Task List describes your PC's hardware configuration and itemizes the tasks you need to complete both before and after installing Windows Vista. It summarizes the items from the previous screens and offers additional recommendations, as the screenshot shows. You can print the Task List or save it as an HTML file.
The Upgrade Advisor runs under 32-bit Windows Vista or Windows® XP Service Pack 2, and requires the Microsoft® .NET Framework 2.0 and MSXML 6.0. To learn more and download the tool, just browse to microsoft.com/windows/products/windowsvista/buyorupgrade/upgradeadvisor.mspx.

Lance Whitney is an IT consultant, trainer, and technical writer. He has spent countless hours tweaking Windows workstations and servers. Originally a journalist, he took a blind leap into the IT world 15 years ago.


Inside Sharepoint Decentralizing Site Administration
Pav Cherny

Download the code for this article: SharePoint2008_06.exe (1160KB)

Microsoft Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007 support a flexible administration and security model that enables IT organizations to centralize control over infrastructure components, such as Web servers and database servers, and decentralize control over hosted
site collections and sites. Centralizing the SharePoint® infrastructure helps to reduce maintenance overhead, consolidate business logic, provide a single point of access to SharePoint resources, and avoid unnecessary investments in technology.
At the same time, decentralizing site administration lets you ensure that individual departments retain autonomous control over their departmental SharePoint site collections, sites, document libraries, lists, workflow solutions, and other SharePoint resources. However, a side effect of delegating site administration to individual departments is increased maintenance complexity for the IT department. For example, how do you keep track of resource usage, expired SharePoint sites, and outdated content in a centralized infrastructure if you don't have access to the site collections and sites within your environment?
In this article, I discuss the security model of WSS 3.0, including its advantages and implications when delegating administrative control over SharePoint sites to individual departments while maintaining centralized administrative control over the SharePoint infrastructure. I show you how delegated site administration works, how access permissions and security trimming at the site, list, and item level help maintain a secure and user-friendly work environment, and how Web farm administrators can gain access to the necessary site statistics without elevated SharePoint permissions.
If you want to follow my explanations in a test lab, download the companion material for this column at technetmagazine.com. The material includes detailed deployment instructions for a Windows Server® 2008-based Web farm that reflects a production environment for a company with multiple departments reasonably well.

SharePoint Infrastructure and Site Collection Administration
You can build a SharePoint infrastructure based on either a single-server deployment or a Web farm deployment. In fact, companies often have both. The single-server deployment is suitable for individual departments that need a quick and straightforward collaboration solution. Performance and reliability requirements are minimal. Users tend to be understanding if a departmental SharePoint server, often deployed on workstation hardware, is unavailable because system maintenance is the department's own responsibility and the users within that department are, after all, not IT administrators.
The picture changes entirely for server resources maintained by the IT department. Performance and reliability become critical factors, often requiring the deployment of high-availability solutions to ensure service level agreement (SLA) conformity. Load-balanced Web farm deployments, SQL Server® failover clusters, and databases stored on Storage Area Networks (SAN) can help to meet the performance and high-availability needs of your company. See Figure 1 for an illustration of this architecture.
Figure 1 A SharePoint infrastructure with SQL Server failover cluster and SAN
Figure 1 A SharePoint infrastructure with SQL Server failover cluster and SAN
As you can see in Figure 1, several types of administrators must work together to maintain the resources in a centralized SharePoint infrastructure, yet each of these administrators sees the environment from a different perspective. For example, the servers in the infrastructure are transparent to site collection administrators. Site collection administrators work with the standard SharePoint user interface. This interface does not change whether you host the sites on a workstation computer running WSS 3.0 in your office or on a Web farm in a data center.
The SharePoint infrastructure is also transparent to database administrators and SAN storage engineers. For these administrators, SharePoint databases are no different from any other SQL Server databases, and the logical unit numbers (LUNs) for the SQL Server failover cluster are no different from any other LUNs. The administrator who is most directly concerned with the SharePoint infrastructure is the Web farm administrator, yet this person has no control over the site collections, databases, or LUNs.
It is fair to say that departmental site collection administrators are generally unaware of infrastructure details. After all, it is not necessary to know these details to provision sites and delegate access permissions to teams and groups within a department. It's easy to create a new site and start collaborating, and issues, such as the high storage costs associated with SAN technology, seldom come to mind.
With every project and initiative, new team sites appear, expired sites linger, outdated content is not deleted, and the SharePoint environment mushrooms at an impressive pace until it reaches a scale that system admins can no longer ignore. For example, the internal SharePoint environment at Microsoft once included more than 180,000 sites before Microsoft IT started a simplification initiative in 2006.
Educating site collection administrators can help keep matters under control in a centralized SharePoint infrastructure. Applying site collection quotas and locks is also useful, yet these methods are not very effective when dealing with outdated team sites and content that wastes precious storage and backup resources.
Outdated content does not necessarily push a site collection over its quota. Of course, you can configure SharePoint to send e-mail notifications to site collection owners and automatically delete unused site collections after a specified period by using the Site Use Confirmation and Deletion feature in the SharePoint 3.0 Central Administration site, but this feature does not work at the individual site level. A site collection can contain current and obsolete sites, but the Site Use Confirmation and Deletion feature doesn't work at this level of granularity.
Later I'll show you how to identify unused sites and outdated content by checking the last modification date of documents and list items, even without access permissions to the site collection. This reporting feature is not available out of the box, but fortunately it is not difficult to implement.

Decentralized SharePoint Site Administration
Delegating SharePoint site administration privileges is very straightforward. By using the SharePoint 3.0 Central Administration site, the command-line tool Stsadm.exe, or a custom provisioning tool, you can create Web applications, managed paths, and site collections in the infrastructure. As a Web farm administrator, you can specify primary and secondary site collection administrators when creating a site collection. These site collection administrators can be regular domain users. They do not require administrative permissions on the Web farm or on other infrastructure servers. They use their Web browsers to perform site administration tasks directly in the SharePoint user interface.
Figure 2 illustrates delegated site administration according to the step-by-step instructions you'll find in the worksheets in the companion material. In this example, the Web farm administrator provisioned separate site collections for the HR department (http://sharepoint/hr) and the IT department (http://sharepoint/it).
Figure 2 Delegated SharePoint site administration
Figure 2 Delegated SharePoint site administration
The HR and IT administrators can then use the Sites and Workspaces feature available under the Site Actions menu in the SharePoint user interface to create sub-level sites and can either apply permissions from the parent site or define new administrative and user permissions for the sub-level sites. Note that unless explicitly configured otherwise, the Web farm administrator can't access any top-level or sub-level sites, the HR administrator can't access the IT sites, and the IT administrator can't access the HR sites, although all sites are hosted in the same SharePoint environment.
The design of the site collections and site hierarchies depends on organizational requirements. In the Figure 2 example, I did not create a master site on top of http://sharepoint/hr and http://sharepoint/it. In other words, there is no site collection at the http://sharepoint path. But you can easily create a site collection at this path or use other managed paths, such as http://sharepoint/sites/hr and http://sharepoint/sites/it.
You can also create separate Web applications for HR and IT to establish more intuitive base URLs, such as http://hr and http://it, provision general portal sites for the departments, and then use roll-up Web Parts to list information from sub-level sites in these master sites. Separate site collections facilitate autonomous administration; help limit access to departmental information; provide individual customization capabilities for Master Pages, page layouts, templates, Web Parts, and navigation controls; and can be used to place sensitive data in dedicated content databases, separate from other site collections and content databases.

Roles, Site Permissions, and Security Trimming
Once the site collections exist and administrative permissions have been delegated, a site collection administrator can open a top-level site and use the Site Settings feature available under the Site Actions menu to manage the site collection. This includes adding (or removing) other site collection administrators with full permissions to all sites in the site collection, creating groups, associating these groups with roles, and adding users to these groups to grant read and contributor permissions. It also includes provisioning sub-level group sites and team sites.
Although you can grant SharePoint permissions to users individually, it's better to create SharePoint groups according to specific roles. For example, SharePoint includes three default groups for the roles Visitors, Contributors, and Owners. Visitors have read-only access; Contributors can add items to lists and document libraries and personalize Web pages; and Owners have full control.
One feature worth noting is that SharePoint performs security trimming based on the user role, which means that users only see those links and items in the user interface that they actually have permissions to access. If you disallow a user access to a resource, such as a list (by configuring explicit permissions under List Settings) or a selected list item (by using the Manage Permissions command in the item's context menu), the list or item will disappear for this user. If the user specifies the URL of the item in the browser directly, the user reaches the Error: Access Denied page.
Figure 3 shows security trimming in action. The HR administrator has full permissions and is able to reach the Site Actions menu to perform administrative tasks. The HR Visitor, on the other hand, only has read-only permissions to the site collection and does not see this menu.
Figure 3 Security trimming based on user roles in the SharePoint interface
Figure 3 Security trimming based on user roles in the SharePoint interface
Security trimming is useful as it hides inaccessible features, links, and items, but it also implies that Web farm administrators can't use the SharePoint user interface to list sites and site resources without having access permissions. You will not be able to see these resources in Web pages or Web Parts. Furthermore, inaccessible resources do not appear in search results because SharePoint Enterprise Search performs security trimming at query time based on identity of the user submitting the query.

What about the Command Line?
If the graphical user interface does not supply an avenue to the desired information without elevated permissions at the site collection level, perhaps the command-line tool Stsadm.exe provides the solution. For example, you might think you could use the command
Stsadm -o enumsites -url http://sharepoint
to list all site collections and owners within the http://sharepoint Web app. Then you should be able to list all sub-sites by using this command:
Stsadm -o enumsubwebs -url <site collection>
Yet, in a Web farm environment, Stsadm.exe typically greets this with an error message indicating that database access permissions are missing. Stsadm.exe cannot enumerate the site collections even though you are a Web farm administrator and can manage the site collections in SharePoint 3.0 Central Administration. The following is the error message you receive if you use Stsadm.exe on a Web farm without SQL Server access permissions:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o enumsites -url http://sharepoint
<Sites Count="2">
<Site Error="Cannot open database &quot;WSS_Content&quot; requested by the login. The login failed.&#xD;&#xA;Login failed for user 'CONTOSO\SPAdmin'.">
<Site Error="Cannot open database &quot;WSS_Content&quot; requested by the login. The login failed.&#xD;&#xA;Login failed for user 'CONTOSO\SPAdmin'." />
The Web farm administrator receives this error message because Stsadm.exe runs in the context of the logged on user, such as CONTOSO\SPAdmin, whereas the SharePoint 3.0 Central Administration site accesses the SharePoint databases in the context of the system account associated with the SharePoint Central Administration v3 application pool, such as CONTOSO\WssConfigAdmin. Although granting your account db_owner permissions for the content database in SQL Server enables you to run the Stsadm -o enumsites -url http://sharepoint command, you are still not able to enumerate the sub-level sites within the site collections. The command Stsadm -o enumsubwebs -url <site collection> returns Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) and you are back at square one. However, there is a better, more successful way that doesn't require elevated SQL Server permissions.

Site Information in Content Databases
If you cannot obtain the required information through the standard SharePoint interfaces and tools, you must go directly to the SharePoint content databases. But first a word of caution—this should be a last resort! The content databases rely on proprietary schemas and database structures that Microsoft only partially documented in the WSS 3.0 SDK in an attempt to discourage customers from working with the databases directly. Whenever possible, you should use the SharePoint user interface, command-line tools, object model, or Web services to access the desired information.
If you have no other alternative and must go directly to the databases, you should at least constrain the solution to read-only access. Modifying the database schema or database structures is not supported and can cause serious problems that might require you to restore site collections from backup or reinstall the SharePoint Web farm.
A possible alternative to implementing a reporting solution that directly accesses the content databases is to specify the Web farm administrator account as a secondary owner in the site collection configuration. Web farm administrators can perform this step in the SharePoint 3.0 Central Administration site. You can find the corresponding Site Collection Administrators link under SharePoint Site Management on the Application Management page.
As a secondary site collection administrator, you can open the site collection in your Web browser, display the Site Settings, and then click on the Site Usage Report link under Site Administration, provided that you have enabled Usage Analysis Processing in SharePoint 3.0 Central Administration. Look under Logging and Reporting on the Operations page if you want to track usage data in log files on your SharePoint servers. The Site Usage Report feature is disabled by default.
However, manually creating site usage reports for individual site collections is not practical in environments with a large number of site collections or with strict requirements that prevent you from granting Web farm administrators the required permissions. A more practical approach is to implement a straightforward ASP.NET reporting application that lists all site collections and sites from the content database together with important statistics, such as the number of items, the combined total size of all items, and the last modification date of the items, as illustrated in Figure 4.
Figure 4 Obtaining site statistics drectly from a content database
Figure 4 Obtaining site statistics drectly from a content database
If you run this application under the identity of the SharePoint Central Administration v3 application pool account, you can get access to the content databases without the need for elevated SQL Server permissions. As mentioned earlier, the Central Administration account already has the required SQL Server permissions.
The companion material includes a simple reporting solution that uses SELECT queries to the content database on the SQL server, and step-by-step instructions for deploying this solution on a Web server. It is important to note that I did not implement any security checks. The solution runs with anonymous authentication.
It is not necessary to authenticate the user because the Central Administration account provides the required security context to access the content databases. I used a custom port for the solution's Web site, blocked through Windows® Firewall on Windows Server 2008, so only a local user can open the Web application. This fulfilled the security requirements in my test environment, but in a production environment, you should tighten security further, such as by enabling Windows authentication and configuring restrictive access permissions to the virtual directory of the ASP.NET application.

Conclusion
SharePoint provides flexible site collection and site administration capabilities that enable you to centralize the SharePoint infrastructure while decentralizing site administration according to your company's specific needs. A centralized infrastructure can be beneficial to companies of any size because a consolidated environment helps lower costs; facilitates information sharing within and across departments; provides the basis to apply expert knowledge in a targeted way to maintain the environment with high security, reliability, and scalability; and gives users a single point of access to sites and SharePoint resources in the company network.
At the same time, individual departments and business units can remain in control of their SharePoint resources. Web farm administrators can designate site collection administrators who then perform site administration tasks within their areas of responsibility without any further involvement of the IT department.
However, with the shift of control to the departments, Web farm administrators also lose the ability to monitor resource utilization in the infrastructure using the standard SharePoint features and tools. Applying quotas to content databases, sending e-mail reminders to site collection administrators, and tracking usage data for reporting purposes can help to mitigate the issue, but in order to manage the SharePoint infrastructure efficiently, Web farm administrators need further tools that extract the required site metadata directly from the content databases in a read-only fashion.
The options available include using SQL Server 2005 Reporting Services or a similar enterprise-level reporting solution. As the example in the companion material shows, you can also use SQL Server SELECT queries to obtain the required information.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corporation, a company that specializes in managed documentation and localization services.


Windows PowerShell Looking Good
Don Jones

It's not uncommon to want your scripts to produce nice-looking output, and I'm often asked about the best way to produce things like tables. There are really a couple of ways to go about doing this. The first step is to write a script that puts the data—that is, whatever data it is that I want to display in a formatted fashion—into variables named
$data1, $data2, and $data3. Now I can get down to formatting the data.

The Text Way
The most common way folks tend to approach this task is the same way they'd handle it if they were working in a language such as VBScript, Perl, KiXtart, or another text-oriented language. I might start by writing out a set of column headers to the screen:
Write-Host "ColumnA'tColumnB'tColumnC"
Note that the `t is a special escape sequence in Windows PowerShellTM that inserts a tab character. To write out each line of my table—remembering that my data is in $data1, $data2, and $data3—I have a few choices. One is to simply write the variables, relying on the shell's ability to replace variables with their contents inside double quotation marks:
Write-Host "$data1't$data2't$data3"
Another slightly more attractive way to achieve this uses the –f operator. This technique separates the formatting from the data and makes what I think is an easier-to-read and more easily maintained line of code:
Write-Host "{0}'t{1}'t{3}" –f $data1,$data2,$data3
This entire approach has significant problems, though. First, by relying on the fixed tab stops in the console window, I am setting myself up for some odd formatting. For example, if a particular table row has a 20-character value in the first column, I throw the entire formatting for that row out of whack. Also, since I'm outputting this text by using Write-Host, I'm pretty much limited to a console display.
There's no easy way to send that output to a file or to put it in other formats, should I ever want to do so. Most importantly, this text-based approach completely ignores the inherently object-based shell that I'm working in, failing to take advantage of all the incredible techniques and capabilities that Windows PowerShell offers.
Video
Watch Don Jones demonstrate how you can easily add formatting to your Windows PowerShell output.

The Windows PowerShell Way
Windows PowerShell is an object-oriented shell. That means, ideally, everything you work with should be in objects, allowing the shell to turn things into text displays when needed. But how do you create objects for arbitrary pieces of data?
Continuing my example, I start by creating a blank custom object and storing it in a variable:
$obj = New-Object PSObject
This gives me a fresh, empty object to work with. I then add my data to the object in the form of properties. To do this, I simply pipe my object to the Add-Member cmdlet. I add something called a NoteProperty, give the property a name (a good idea is to use the column headers as property names), and then insert the data as the values for the properties:
$obj | Add-Member NotePropertyColumnA $data1
$obj | Add-Member NotePropertyColumnB $data2
$obj | Add-Member NotePropertyColumnC $data3
Now I simply output this object—not to the console, but to the pipeline:
Write-Output $obj
I can then repeat these steps for each table row that I need to output. The following is a short function that accepts a string and outputs an uppercase and lowercase version, along with the original string:
functionStringVersions {
param([string]$inputString)
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty Original($inputString)
  $obj | Add-Member NoteProperty Uppercase($inputString.ToUpper())
  $obj | Add-Member NoteProperty Lowercase($inputString.ToLower())
  Write-Output $obj
}
$strings = @("one","two","three")
foreach ($item in $strings) {
StringVersions $item
}
I start with an array of string variables, going through each of them one at a time and sending them to the function. And the function's output is written to the pipeline.
You should note that there are shorter ways to write this code, but I chose this technique because it clearly illustrates the point I want to make. The result, as shown in Figure 1, is a perfectly formatted table. That's because the shell already knows how to format objects in a table.
Figure 1 Windows PowerShell output displayed in a table
Figure 1 Windows PowerShell output displayed in a table
Whenever an object has four or fewer properties, Windows PowerShell chooses a table automatically. So with no work whatsoever on my part, I now have a great-looking table.

But Wait, There's More!
Cmdlet of the Month: Get-Command
I'm sure you've used Get-Command, or its handy alias (gcm), once or twice to review the list of available Windows PowerShell cmdlets. But you may not know how flexible gcm really is. For instance, if you want to see everything Windows PowerShell can do with a service, run gcm -noun service. Or, if you want to see all of the Windows PowerShell export options, try gcm -verb export. If you just need to see what cmdlets were added by a particular snap-in, such as the PowerShell Community Extensions, try gcm -pssnapin pscx. (You can replace "pscx" with any snap-in name to see that snap-in's cmdlets.)
As you can see, Get-Command is a key player in the discoverability of Windows PowerShell. It allows you to learn what functionality is available without even having to pick up a manual. And note that gcm is a more accurate way of discovering functionality than using a command such as Help *. The Help function only lists available help topics. Any cmdlets that didn't ship with help don't show up in the help listing—even though the cmdlets are there if you need them.

The benefit of this technique goes far beyond tables. When you're working with objects, Windows PowerShell knows how to do a huge range of things. Want your data in a CSV file? Use Export-CSV. Prefer an HTML table? Pipe your objects to ConvertTo-HTML. Need a list format? Pipe them to Format-List. By using objects, you can make use of all the things the shell already knows how to do. Here's a revised example:
functionStringVersions {
  PROCESS {
   $obj = New-Object PSObject
   $obj | Add-Member NoteProperty Original($_)
   $obj | Add-Member NoteProperty Uppercase($_.ToUpper())
   $obj | Add-Member NoteProperty Lowercase($_.ToLower())
   Write-Output $obj
}
}
This time around, I've modified the function to accept pipeline input—this is always a better idea when you're working with objects—and to output to the pipeline.
This function now has its code inside of a PROCESS scriptblock. This means that function will accept pipeline input and will execute the PROCESS scriptblock once for each object that is piped in.
Within the PROCESS scriptblock, the special $_ variable refers to the current pipeline object that's being processed. The practical result of this is that now I can simply pipe in an array of strings:
@("one","two","three") | StringVersions
I get a table because the function is putting its output into the pipeline. At the end of the pipeline, the shell knows to call on its formatting subsystem, which makes the decision to use a table because the objects in the pipeline have fewer than five properties (for more properties, the shell will use a list by default).
But I don't have to rely on the default behavior. I can simply pipe those objects to another cmdlet to have something else done with them:
@("one","two","three") | StringVersions | Format-List
@("one","two","three") | StringVersions | ConvertTo-HTML | Out-File "strings.html"
@("one","two","three") | StringVersions | Export-CSV "strings.csv"
@("one","two","three") | StringVersions | Select Uppercase,Lowercase -unique
Figure 2 shows the resulting HTML from the second example displayed in a Web browser. By simply representing my output data in objects, rather than representing it as simple text, I suddenly now have complete access to a wealth of functionality that is built into the shell—a variety of formatting layouts; HTML conversion; export options; the ability to sort, filter, and group; and more.
Figure 2 Windows PowerShell data output in HTML format
Figure 2 Windows PowerShell data output in HTML format
This is very powerful stuff. In fact, I will go so far as to suggest that every script you write should produce an object as its output so you can use that output in as many different ways as possible—all without writing a single additional line of code.

Don Jones is an expert in Windows administrative automation and has authored such books as Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed. You can reach him through the forums on ScriptingAnswers.com.


Hey, Scripting Guy! Not-So-Hard Work Has Its Rewards, Too
The Microsoft Scripting Guys

Download the code for this article: HeyScriptingGuy2008_06.exe (150KB)

For hundreds of years, people have believed that hard work is it own reward; that true satisfaction comes from putting in an honest day's labor; that true happiness comes from the destination, not the journey; that—well, you get the idea. Work hard and without complaint (think Cinderella), and, someday, you will be rewarded.
Note: is that really true, that if you work hard you'll not only be happier but, someday, you'll be rewarded for your efforts? Why are you asking us a question like that?
Of course, Cinderella was lucky; after all, if you live with a wicked stepmother and a couple of wicked stepsisters, you have all sorts of opportunities to work hard. But what if you're not so fortunate? What if you don't live with a wicked stepmother and a couple of wicked stepsisters? How are you supposed to put in long, grueling, thankless days of work? How will you ever find true happiness?
Well, if you're bound and determined to work your fingers to the bone, the Scripting Guys suggest you try writing a script that outputs data in nice, neat, tabular format, like the output shown in Figure 1.
Figure 1 Tabular output
Figure 1 Tabular output
Like we said, Cinderella was very lucky: she got to clean the house from top to bottom and, when finished, got to sit in the hearth amidst the ashes and soot. But even Cinderella would have balked at having to write a script that could display data in tabular format. Sitting in the ashes and soot is one thing. Writing a script that outputs data in tabular format is quite another altogether.
Note: well, unless you have to sit in the hearth to write your scripts; then they're pretty much the same thing.
Why would Cinderella balk at this task? Because it's just too darn hard. The only way to display data in tabular format in VBScript is to do something along these lines:
  • Start by determining the maximum size for each column. For example, you may want the display name of a service to fill up 52 character spaces.
  • From there, calculate the number of characters in a piece of data. For example, the display name Adobe LM Service has 16 characters.
  • If the display name exceeds the 52-character limit, determine the number of characters that need to be chopped off the end of the string to make it fit in the allotted space. If the display name doesn't exceed 52 character spaces, determine how many blank spaces must be added to the end of the string to make the length exactly 52 characters.
  • Repeat for the next set of data. And the next. And so on.
If you're familiar with the story of Cinderella, then you know it's possible that your fairy godmother will pop in unannounced, turn a mouse into a system administrator (no comments on how easy that might be), and then the mouse will write this script for you. But you probably shouldn't count on that happening. You're probably on your own here.
On the bright side, though, you'll be the most satisfied person in the world. That's because you'll also be the hardest-working person in the world. The hardest working by far.
Of course, some people would be willing to trade a little satisfaction for the opportunity to not have to work quite so hard. If you're one of those people, you're probably thinking, "Thank goodness the Scripting Guys are here; they'll tell me how to change a mouse into a system administrator, then tell me how to get that mouse to format my output as a table." Well, we're afraid we have bad news for you: the Scripting Guys have no idea how to turn a mouse into a system administrator. (Although we can turn a system administrator into a mouse, if that's of use to you.) We don't know how you can get someone to write scripts for you, let alone scripts that will output data in tabular format.
But that's OK. As long as you're running Windows® XP or Windows Server® 2003 (which many of you are), you don't need a mouse to write your scripts for you. (No, sorry, we're afraid this doesn't work on Windows Vista®.) Instead, you can do this yourself, and with minimal effort, thanks to the Microsoft.CmdLib object. Take a look at the sample script in Figure 2.
Figure 2 Creating a tabular display
Dim arrResultsArray()
i = 0

Set objCmdLib = _
  CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = _
  WScript.Application

arrHeader = Array("Display Name", _
  "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" _
  & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery _
  ("Select * FROM Win32_Service")

For Each objService In colServices
  ReDim Preserve arrResultsArray(i)
  arrResultsArray(i) = _
  Array(objService.DisplayName, _
    objService.State,objService.StartMode)
  i = i + 1
Next
objCmdLib.ShowResults arrHeader, _
  arrResultsArray, arrMaxLength, _
  strFormat, blnPrintHeader, arrBlnHide
In case you're wondering, Microsoft.CmdLib is a COM object that ships with Windows XP and Windows Server 2003. This object has a number of different features; for more information, type cmdlib.wsc /? at the command prompt and read the comments in the script file that pops up on screen. For today, we're interested in only one feature of Microsoft.CmdLib: the ability to display data in tabular format.
This leads to an obvious question: how do you display data in tabular format? Let's see if we can figure that out. As you can see, our sample script kicks off by defining a dynamic array named arrResultsArray:
Dim arrResultsArray()
In a typical script, data is echoed back to the screen as quickly as it is retrieved. But why would you expect the Scripting Guys to do anything in typical fashion? In this script, we aren't going to echo back the data as it is retrieved. Instead, we're going to store all the returned data in an array, then let Microsoft.CmdLib format and display the data for us.
In other words, that's why we start out by creating a dynamic array (that is, an array that can be resized during the course of the script). After defining the array, we set the value of a counter variable named i to 0; we'll use this variable to keep track of the current size of the array.
In case you're wondering, we set the value of i to 0 because the first item in an array is always given the index number 0. Consequently, when we add the first item to the array, we're adding item 0 rather than item 1.
Next we need to initialize our instance of the Microsoft.CmdLib object; that's what these two lines of code are for:
Set objCmdLib = _
CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = WScript.Application
And that brings us to this little block of code:
arrHeader = Array("Display Name", "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)
What we're doing here is setting up a few parameters for configuring our output. In the first line, we're assigning values to an array named arrHeader; as you might expect, these are the headings for each column in our output table. For this sample script, we're going to retrieve information about the services running on a computer, then we're going to display the values of the DisplayName, State, and Start Mode properties for each service.
Not too surprisingly, we assign our array the column names Display Name, State, and Start Mode (though we could have just as easily assigned our columns the names A, B, and C; Larry, Moe, and Curly; or anything else we wanted. The column names don't have to be the same as the property names).
Note: there are many variations of the Cinderella story, including the names of her stepsisters. In the Disney version of Cinderella, the stepsisters are named Drizzella and Anastasia, which just happen to be the first and middle names of our Scripting Editor!
In the second line of the code, we're assigning values to another array, named arrMaxLength. This array holds the size of each column in the table. In our output, we want to allocate 52 character spaces to column 1 (the service display name); we then want to allocate 12 spaces each to the service state and start mode. (Microsoft.CmdLib will automatically insert a blank space between columns.) If we want our column sizes to be 52, 12, and 12 character spaces (which we do), we use code that looks like this:
arrMaxLength = Array(52, 12, 12)
The third line specifies the output format for our data. We want the data displayed as a table; hence we set the value of strFormat (the variable that holds the output type) to, well, Table. Suppose instead we wanted to display the data as a comma-separated values list. In that case, we'd set the format to CSV, like so:
strFormat = "CSV"
In turn, we'd get output similar to what we have here:
"Display Name","State","Start Mode"
"Adobe LM Service","Stopped","Manual"
"Adobe Active File Monitor V4","Stopped","Manual"
"Alerter","Stopped","Manual"
"Application Layer Gateway Service","Running","Manual"
"Apple Mobile Device","Running","Auto"
"Application Management","Stopped","Manual"
Notice how Microsoft.CmdLib not only put commas between each item, but also enclosed the individual values in double quotes. That's a nicer feature than you might first think. After all, to do this manually, you'd have to use code like the following:
Wscript.Echo Chr(34) & objService.DisplayName & Chr(34) & "," & Chr(34) &
   objService.State & Chr(34) & "," & Chr(34) & objService.StartMode & Chr(34)
Yuck.
What's that? You don't like tables, but you don't like the CSV format either? Well, in that case try setting the format to List, which gives you output similar to this:
Display Name: Adobe LM Service
State:        Stopped
Start Mode:   Manual
Display Name: Adobe Active File Monitor V4
State:        Stopped
Start Mode:   Manual
But we digress. (As we are prone to do on occasion.) After defining the output format, we set the value of a variable named blnPrintHeader to True:
blnPrintHeader = True
We're going to use blnPrintHeader to tell Microsoft.CmdLib to print the column headings. What if we don't want to print the column headings? That's fine; in that case, set blnPrintHeader to False:
blnPrintHeader = False
Last, we have this line of code:
arrBlnHide = Array(False, False, False)
When it comes time to display your data, Microsoft.CmdLib gives you the option of showing or hiding a column. To hide a column (that is, to suppress data for a particular property), set the value for that property to True; to show a column, set the value to False.
In our output, we're going to show the values for the DisplayName, State, and StartMode properties, in that order; hence we use the values False, False, False in our array. What we if wanted to show the DisplayName, hide the State, and show the StartMode? In that case, we'd use this line of code:
arrBlnHide = Array(False, True, False)
Remember, use False to show a column and True to hide a column.
At this point we're ready to output some data—or we would be if we actually had some data. (Have the Scripting Guys ever written a script that failed to output data, then spent an inordinate amount of time debugging that script, only to discover that they hadn't bothered to actually retrieve any data in the first place? Uh, no, of course not; whatever makes you say that?)
With that in mind, our next step is to bind to the Windows Management Instrumentation (WMI) service on the local computer, then use the ExecQuery method to retrieve information about all the services installed on that computer:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery ("Select * FROM Win32_Service")
We should probably mention that you aren't limited to working with WMI data here. As you might expect, Microsoft.CmdLib can work with any kind of data. WMI is just a handy way to retrieve a bunch of data.
Once we have our collection of service-related data, we set up a For Each loop to cycle through all the services in the collection. However, instead of echoing back the property values for each service, we execute this code:
ReDim Preserve arrResultsArray(i)
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
i = i + 1
What are we doing in this block of code? Well, in line 1 we're resizing our array, using the command ReDim Preserve to not only resize the array but also to preserve any existing data in that array. (Without the Preserve keyword, the array would be resized, but any data currently in that array would be erased.)
What size are we making the array? The first time through the loop, we're making an array of size 0; in other words, we're creating an array containing one element. And how do we know for certain we're making an array of size 0? Because we're using the counter variable i, and that variable is equal to 0.
So if we're using the variable i to represent the size of the array, doesn't that mean we'll always be setting the size to 0? Well, it would, except that each time we go through the loop we increment the value of i by 1; as you can see, that's what we do in line 3 of our code block.
That leaves us with just one line of code to worry about:
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
Here we're simply taking the property values of interest—DisplayName, State, and StartMode—and adding them to the array arrResultsArray. Notice that we don't add the property values individually; instead, we add them as an array of values. Granted, that's a little unusual: it means that each item in the array arrResultsArray will be another array; that's just the way Microsoft.CmdLib works.
Of course, that might cause you to start worrying again. "An array of arrays? How in the world am I supposed to access all the individual values in an array full of arrays?" Don't panic. It's easy: let Microsoft.CmdLib take care of it for you.
Note: sorry, but accessing all the individual values in an array of arrays is about the only thing Microsoft.CmdLib can do for you. However, cleaning your wicked stepmother's chambers, doing dishes, and making clothes for your evil stepsisters are being considered for the next release of the object.
In fact, we can output our data—in neat tabular format—simply by calling the ShowResults method and passing the method all the arrays and variables we configured earlier in the script:
objCmdLib.ShowResults arrHeader, arrResultsArray, arrMaxLength, strFormat, blnPrintHeader, arrBlnHide
What's all that going to look like? It's going to look like the nicely formatted output we hoped for when we looked at Figure 1.
Not bad, eh? You get nice-looking output, and you hardly had to do any work at all. (And your next script will be even easier, because all you'll have to do is make a few minor changes to this first script.)
Now, admittedly, you won't get the same sense of satisfaction that Cinderella got from slaving all day and all night just so she could display script output in a table. And, to be honest, you probably won't get to marry a prince, either; that's not really part of the deal. But that seems like a small price to pay in order to get such nice output from a VBScript script, especially when you consider what princes tend to be like these days.
And who knows: you might get yourself a prince anyway. After all, even royalty needs to get information about all the services installed on their computers, right?

Dr. Scripto's Scripting Perplexer
The monthly challenge that tests not only your puzzle-solving skills, but also your scripting skills.

June 2008: PowerShell Pathway
In each of these puzzles, connect the letters horizontally, vertically, and diagonally to make up the name of a Windows PowerShell cmdlet. Each letter will be used only once. Here's an example:
The cmdlet created in this puzzle is New-Alias. Now it's your turn. Here are three more puzzles:

ANSWER:
Dr. Scripto's Scripting Perplexer
Answers: PowerShell Pathway, June 2008

Read-Host

Set-AuthenticodeSignature

The Microsoft Scripting Guys work for—well, are employed by—Microsoft. When not playing/coaching/watching baseball (and various other activities), they run the TechNet Script Center. Check it out at www.scriptingguys.com.


The Desktop Files Security vs. Compliance
Wes Miller

As an IT professional, you may be faced with objectives that should complement each other but often compete instead. Security and compliance are two such organizational goals, where the achievement of one should enhance the other. Alas, this is not usually the case. My intention with this column is to give you
an overview of why being secure doesn't always mean being compliant with the initiatives required of you, and why being compliant often doesn't mean being secure, or at least not as secure as you should be if compliance truly equated to security.

Security Isn't a Checkbox
SDL Resources
  • The Security Development Lifecycle by Michael Howard and Steve Lipner (Microsoft Press, 2006)
  • The Security Development Lifecycle Blog
  • A Look inside the Security Development Lifecycle at Microsoft
  • Security Developer Center
  • The Trustworthy Computing Security Development Lifecycle

Compliance generally involves requirements (people, process, infrastructure, technology, and so forth) imposed on an organization, industry, company, or product from the outside. Sometimes compliance has to do with standards promulgated from within the industry (such as the Payment Card Industry Data Security Standards, or PCI-DSS). Ideally these are initiatives that align with the way your organization already works, at least to a degree. As adoption of a standard proliferates, you find you can't afford to ignore it, not if you want to do business; eventually, you have to jump in and make the best of it.
It's the other kind of compliance that's usually more troublesome. I'm referring here to initiatives set forth by the government, such as Health Insurance Portability and Accountability (HIPAA) and Sarbanes-Oxley, where implementation and timing is seldom a matter of choice.
The key point to understand about regulatory compliance is that it often involves a "top down" approach. There is typically a cookie-cutter template that defines the initiative, and you must look at your products and processes and try to figure out how they can mesh with the oddly shaped template handed down to you. You need to remain aware not only of the intent of the compliance initiative but, perhaps more importantly, what the legal or financial ramifications may be for not following through with it, or for being unsuccessful (if indeed there are any).
While we may well agree with the intent of many compliance initiatives, implementation is often difficult and may not meet the desired objective. And, regrettably, many are toothless (that is, there are no direct legal or financial ramifications that can be imposed for failing).
I can tell you that, as a medical patient, I can't completely describe the net benefit of HIPAA for me. What I can tell you is that it means I have a lot more paperwork to deal with when I go to a physician. Even worse may be the unintended consequences. Ever try to get important medical information from one doctor or agency to another? If there's no written permission, it's not going to happen, no matter how urgently the information is needed.
The point is that, in many senses, some compliance initiatives become checkbox initiatives. That is, you are designing or modifying your process or your product solely to meet the compliance initiative. As I often ask my three-year-old, "is that a good idea?"
Security, on the other hand, is a bottom-up initiative—when done correctly. Whether you are designing a software product or the architecture for your organization's new network, the key concept to remember is measure twice, cut once. When you are designing product architecture, for example, just as a good initial pass would describe communication, localization, versions, and so forth, so should it describe the security elements that need to be built into the application from day one (and which you should continue to investigate and refine throughout development).
If you are working with an application or architecture you inherited (as I'm sure most of you are), it's just as critical to perform the kind of in-depth security review that I often mention in this column. If you don't understand how something works, how can you possibly understand how secure it is or isn't? For more on the Microsoft® Security Development Lifecycle (SDL), see the sidebar "SDL Resources."

The Big Picture
I remember early on being educated that security doesn't equate to simply implementing encryption, access control lists (ACLs) or TLS, or public key infrastructure (PKI). Real security is all about understanding the big picture: understanding why that version of that protocol was dropped or was never even supported; why this new piece of plumbing stops man-in-the-middle attacks; how your implementation for product v2 is so much more secure than v1, even if v1 was much faster. And it's also necessary that you understand how all the parts of your infrastructure fit together.
Compliance, on the other hand, means taking your technology and making sure that the infrastructure you have built meets certain criteria. Some initiatives, like Payment Card Industry Data Security Standards (PCI-DSS) or North American Electric Reliability Council (NERC), are well intended and may end up fostering real security change. But at the end of the day—with a smorgasbord selection of "compliance initiatives" that you need to mesh with your own particular projects, and finite resources available, security initiatives lose ground.
Security has long been the stepchild of software development. Surely many of you have been in an organization where security was something that "we'll do later." Well, compliance initiatives are now here to stay because that ethos—that security can wait—doesn't work, and it never has.

Good Enough
Recently I've changed jobs. I'm now working for a startup here in Austin, Texas, that is building an application whitelisting technology somewhat similar to the technology we built at Winternals with our Protection Manager product. One thing I've found very interesting to talk with customers about is how secure they feel their current technologies are—or more specifically, how secure they believe the suite of technologies they are using is making their infrastructure. While it is entirely likely that most of them are secure and aren't being split open with security vulnerabilities, the assessment I hear often that makes me cringe a little is that a system is "secure enough."
Compliance initiatives are funny—you can meet them or fail to meet them. The responsibility is yours. The cost of not meeting an initiative is usually a fine, a penalty, or removal from an organization. Often it's not enough to ensure anything truly changes.
In the case of a federally mandated initiative, I regularly encounter the attitude, "good enough to please the auditor," or the willingness to run without actually putting any compliance framework into place because the backing legislation (such as HIPAA) does not adequately fund enforcement—meaning it costs a whole lot less to drive without insurance and face any potential consequences later.
Security often hits the same roadblock, but in my mind at least it is more concrete. If you, as a developer or implementer, actively tell management that leaving section foo out of the spec will leave the product markedly more vulnerable to breach, you can at least say after the product ships or your deployment is complete, "I told you so." With compliance initiatives, my experience is that fulfillment is often hurried, with as limited a budget as possible. The goal is simply to meet the bare minimum required by the initiative—thus perhaps meeting the letter of the initiative but hardly the spirit, in my opinion.

Deciding Where You Are
Security and Compliance Resources
  • Security and Compliance Solutions Guidance
  • Security Guidance
  • Payment Card Industry Data Security Standard Compliance Planning Guide
  • Regulatory Compliance and Security Updates
  • Achieving Compliance
  • Office for Civil Rights—HIPAA
  • PCI Security Standards Council
  • North American Electric Reliability Council

While it may be idealistic for me to say that you should make your product and your organization as secure as possible, the reality is that most compliance initiatives are indeed a compromise resulting from poor engineering or, more often, complacency. We live in a world where "good enough" is, unfortunately, good enough. In the world of security, however, rarely is "good enough" wise. We, the IT professionals of the world, may take compliance initiatives to heart and try to meet them in both spirit and implementation, and yet must also make sure that the infrastructure we're putting in place is not merely as secure as it could be, but rather as secure as it must be. In other words, be compliant through real security, not by just meeting the initiative.
It's important to take a step back and look at the technology you are building, whether it is a piece of commercial software or a set of technologies you are looking to integrate into a larger system. I can't stress enough the importance of understanding the interlocking parts of the system, how all the parts work together, and the larger threats posed against your system.
Depending on the industry you work in, different compliance initiatives may play a role in your work. You may encounter them in your daily life or only when you are designing new projects or technologies. Or, it may be the case that they are only a part of your work during specifically designated compliance reviews or audits. No matter. I don't think that compliance initiatives should be ignored, but I would challenge you to challenge the status quo, and instead of working solely to meet the compliance initiatives you are tasked with, perform a full security review to understand your technology from the inside out, and model it at the same time as your compliance review.

What Have You Got to Lose?
At the end of the day, the penalties for failing to meet a compliance initiative may seem ambiguous. The lack of compliance puts you at risk for the exact scenario the initiative was put in place to shield from. The consequences may seem vague or distant, but they are real. They may not be your (individual) consequences either. Be pragmatic, but always keep the worst case scenarios close at heart.
If you look at the same space, from a strictly security perspective, the threat should be obvious—and more importantly, you should be able to immediately identify the potential cost of leaving the vulnerability open.
Many people with whom I've discussed this topic have emphasized the fact that compliance initiatives are sometimes swept under the rug—since compliance initiatives often leave quite a bit open to interpretation. Once you've conducted a security review, however, that should not be true about any security omission. The immediate threats of ignored security should be clearly visible. If they are not, you may want to reconsider who you are involving in your security reviews; you may be missing key team members who can help find the actual issues in your solution.

Chasing the Tail
In last year's security-focused column, I discussed "How Not to Lose Your Data" (technet.microsoft.com/magazine/cc162325). A year has gone by, more systems have been compromised, more unencrypted laptops have been lost, and more personal information has been put into potentially questionable hands. It's hard to tell if any progress has been made at all. Why are we still in the same place? Projects often run late, on a shoestring budget, with ridiculously overstretched resources, trying to deliver too many features in too short a time frame.
That kind of environment, unfortunately, leads to one where the barest minimum of work becomes the norm. That's certainly not a way to ensure that a solution is secure or compliant, and also not fatal to a project's time line or costs.
Personally, I'm a firm believer that:
  1. You shouldn't build a solution if you aren't willing to secure it.
  2. Any time you add new features, you need to design the security in before you begin.
  3. If your organization isn't willing to build in security as a step in your engineering process, you should question what your overall company or organizational objectives are.
Organizations increasingly have customer or partner personal data that they are responsible for keeping safe. It is unfortunate that we live in a world where, too often, security is not the default and employees don't feel safe questioning the organization's dedication to security.
The actual failure of security (not of compliance) all too often becomes the trigger that indicates "it's time to secure the system now," and "identity theft insurance" has become a standard accountability ploy to appease customers, students, patients, and employees whose personal data, and potential financial well-being, have been compromised.
We're all being asked to do too much, often for too little, and usually in too short a time. But it's our responsibility as IT professionals to question why security isn't the key focus, why too often management thinks about security only in the face of either compliance initiatives or more likely, security failure and its real or potential legal threats (that could potentially embarrass and even risk the organization).

Take My Challenge
More than anything, I invite you to challenge the status quo. If you're being asked just to meet compliance objectives—try to ensure that as you do, you aren't just wasting time meeting someone else's concept of security. Be sure, rather, that your goal is to secure the system and, along the way, define enough of the process or your infrastructure to meet the compliance initiative. For more information on this topic, see the "Security and Compliance Resources" sidebar.
In short, remember that compliance is all too often not a path to security. Security, however, if implemented and instrumented correctly, can quite often be a path to compliance.

Wes Miller is a Senior Technical Product Manager at CoreTrace (www.CoreTrace.com) in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager at Microsoft. Wes can be reached at technet@getwired.com.


The Business of IT 10 Keys to Becoming an Environmental Leader
Michael Walsh and Eliza Walsh

It seems every company is talking about their environmental efforts. IT can play a key role in these efforts—creating a great opportunity for you to drive change and become a thought leader in your company and industry. But where do you start? Here are 10 keys to being an effective leader for environmental and sustainability initiatives.
Familiarize Yourself with the Issues
The first step is to develop broad and deep familiarity expertise on environmental sustainability and computing. As an IT professional, you should start with a ﻿good understanding of the ways to reduce the environmental impact of computing, such as power management, hardware consolidation, and environmental waste management.
As an environmental leader, you also must envision how software and hardware can help to reduce the impact of operations beyond the IT department. You may find yourself working closely with HR managers, attorneys, and business managers to define policies addressing the company's overall environmental impact—perhaps everything from business travel policies to global carbon footprint regulations.
Individuals inside and outside of your company will expect you to have subject matter expertise on the environment, the company, and the industries in which your company operate. So, you'll need to assess your understanding of environmental sustainability and sustainable computing as well as the unique needs of your company in the short and long term.
If you are new to the company or assuming a new role, there will likely be pressure (real or perceived) to act quickly. This is especially true in companies that have very little history of positioning themselves in an environmentally conscious way (and are now anxious to do so).
You should resist this temptation to move too quickly. That can risk your credibility as well as the company's. In the short term, focus on urgent issues and postpone communicating strategic initiatives until you are ready or your ramp-up period has expired.

Objectively Assess Your Company
The next step is to critically assess the environmental and sustainability of your company or line of business. To do this, you'll need to engage key stakeholders and other influential people inside and outside of the company.
You'll need to develop a network of internal and external contacts—people who can enable you to define the ecosystem of stakeholders. They can help you develop an understanding of where the company is on environmental sustainability.
Depending on your responsibilities, you may need to find out where your company stands on compliance (current and future) with environmental regulations, standards, and laws. You might have to measure your company's position with respect to your competition and analyst expectations. You should also understand how customers, partners, governmental organizations, and influential customer advocates perceive your company and its environmental efforts. And you may need to determine current and future technological, financial, and environmental constraints concerning your initiative.
Depending on your company's size and budget, additional research may be worth considering. Constructive insight can come from internal surveys, focus groups, and third-party research. It can help you better understand employee satisfaction regarding past corporate environmental action, where your company stands with respect to the competition, and where latent market opportunities exist. The greatest potential value here, however, is the ability of the third-party research to either validate or refute the opinions held by your key stakeholders.

Envision Where You Want to Be and When
Now you can begin to comprehend where your company needs to be, both in the short term and the long term. To start, you can approximate these as one year and five years, respectively, and then begin to adjust these time frames for your specific needs. The key take-away is that the environment is definitely not a short-term issue, and those who position themselves only in the short term do their company, shareholders, partners, and customers a serious disservice.
To determine where your company needs to be in both the one-year and the five-year periods, you should determine the current and future business landscape that you face. This includes the company culture, the company's short- and long-term business objectives, current and future budgetary constraints, geographic expansion plans, and your industry's changing legal and regulatory environment.
For example, a data center provides a context on the conflict between tactical decision-making and strategic positioning. In the past, space served as the primary consideration for data center design. However, in the past few years, power increasingly challenged space as a limiting factor for growth and became a rising operational cost. Data center operators, who realized the long-term implications of the increased importance of power, took steps to mitigate energy inefficiencies, which included radical shifts in data center management that contradicted the prevailing space-driven decision factor. In some cases, the investments made to mitigate power bore significant short-term costs when compared to maintaining the existing paradigm. However, with the significant rise in energy prices, the data center operators who proactively altered the course of data center management a few years ago are now seen as visionaries, and their companies have more than compensated for the initial investments.

Develop a Vision and Strategy
Now you have to develop a vision and strategy. Obviously, this should arise out of your understanding of where the business is and where it needs to be. When setting the vision and strategy, you should not consider these as being perpetual in nature. While your company's commitment to the environment may be enduring, your vision and strategy likely won't be. It will face major revisions due to internal and external variables, such as changing regulatory requirements, shifts in customer perception, and evolving business needs. With the rise of the corporate environmental initiative, it is important to align the IT vision and strategy with any larger corporate vision and strategy.
When you set the vision, you are setting the direction of your business. You must carefully choose your words so that they are deliberate, concise, and coherent, but not exhaustive. Vision is not meant to address everything your company will do regarding the environment. It should address only those issues that need to be mentioned to correctly orient your employees and partners. A mission statement (or vision statement) is often used to convey the vision. It's essential that you begin to communicate your vision within your first six months.
By setting the strategy, you are not just defining the direction, but also establishing the explicit business goals and objectives as well as outlining the investments that will be made to achieve these goals and objectives. There are existing models that can help you formulate a strategic plan. Two of the best models for environment and sustainability issues are the SWOT (Strengths, Weaknesses, Opportunities, and Threats) and PESTLE (Political, Economic, Social, Technological, Legal, and Environmental) models. You can then define the strategy in a document, such as a strategic plan.
Note that leaders who widely solicit feedback on their vision and strategy from perceived adopter and resistor stakeholders prior to release of a written statement are more likely to be successful. This is especially true of those who address feedback from the resistors in their final plan.

Evangelize the Business Imperative
Evangelism doesn't have to wait for you to release a vision and strategy. Rather, evangelism must start the day you assume the role. After the release of your vision and strategy, however, you will need to take a more public role—both internally and externally. Initially, you or a proxy will need to communicate your vision to influential groups, such as employees, analysts, media, partners, customers, and customer advocates. You will need to inspire and motivate them to believe in your vision and strategy and make a persuasive argument that your strategy is in the best interest of your company and your target audiences.
In time, you will need to shift your focus to the individual elements of the strategy. Throughout, you must also periodically update these target audiences, pointing out significant milestones that demonstrate success, communicating changes in strategy, and speaking frankly about challenges that your company or industry at large has.
Be ready for each audience to present different interests and needs. While you will need to speak to the specific needs and interests of each audience, your underlying vision and strategy must remain consistent. This will help you more effectively gain buy-in from the various target audiences.
Resist the urge to communicate conflicting "business needs" to appease different audiences. Leaders who do so will not establish credibility on the issues. At a minimum, this can limit their effectiveness in leading change. At worst, this can jeopardize the credibility of the entire company. Figure 1 highlights seven keys to communicating your message effectively.
Figure 1 Sev﻿en keys to communicating your message
Figure 1 Sev﻿en keys to communicating your message

Manage your Messaging
As you evangelize your vision and strategy, consider the professionalism and integrity of both your internal and external messaging. Environment and sustainability are linked to corporate social responsibility as much as they are linked to product development, services, sales, and marketing. Even if your organization has assigned environmental leadership to you functionally—without giving you direct ownership over environmental sustainability citizenship efforts—you should operate under the assumption that you will be held to the same standards as a citizenship leader.
Do not underestimate your external audience's passion for environmental issues and their familiarity with environmental business practices. More importantly, you should not underestimate their ability to deconstruct your communication if it lacks integrity or promises too much or too little. Otherwise, your company may be labeled a "greenwasher."
Therefore, you need a communications strategy that incorporates a review process that includes internal pundits who can provide feedback before you take a public position. Your communications strategy should frame the key elements of your messaging, such as, ﻿for example, a corporate environmental fact sheet, a messaging framework, a list of approved spokespersons, and talking ﻿points. The communication strategy, which is key to clear structure and consistency, should be completed soon after the development of your vision and strategy. You can benefit from placing personal accountabilities on the primary owners of the messaging.

Enable Management through Measurement
It's important that you manage the accountabilities that are within the scope of your vision and strategy. Whether operations, product development, or sales and marketing, you must define the factors that impact your ability to meet your goals and objectives. These factors should be organized into a concise list and mapped to the overall strategic plan. You will then need to qualitatively and/or quantitatively baseline these factors and establish tracking metrics that enable future analysis. These metrics should be actively managed.
Accountabilities for reporting on these tracking metrics should be clearly defined, and you should hold regular meetings that include all the key stakeholders. The stakeholders can then discuss the impact of the tracking metrics on the health of the strategic plan, which is made possible by the mapping of the metrics to the factors and the factors in turn to the individual elements of the strategic plan.
Unfortunately, many environmental leaders will find that their organizations are not prepared to support such tracking metrics with the measurement tools. But these tools are necessary to provide the qualitative and quantitative data you need to properly analyze and report on environment and sustainability efforts. You, therefore, must develop specialized measurement tools, whether through business process redesign, deployment of collaboration and measurement technology, or the development of customized internal tools.
Without support from senior leadership regarding the company's investment in these measurement tools, you will probably face serious cost-benefit decisions about whether to make the right measurement tools a priority at the expense of additional headcount.

Analyze and Report Environmental Impact
The collection of the quantitative and qualitative data enables in-depth analysis. This analysis is critical for leaders who want to understand how successful their initiatives are and what the impact of their actions has been on the company or its lin﻿e of business.
The changing regulatory, standardization, legal, and voluntary corporate reporting landscape with respect to the environment has placed increasing pressure on companies to release detailed information about their environmental footprints. Having the necessary tools and processes in place to support management, measurement, and analysis facilitates the collection of the information demanded for mandated annual reports, required filings, and voluntary corporate sustainability reports. It is, therefore, important that you understand what your reporting requirements are and what they will be in the future, so that you can invest in an integrated management, measurement, analysis, and reporting infrastructure that will grow with your business needs.
Technology for analysis and reporting is very important to companies seeking to emerge as thought leaders. Software plays a key role in this space—especially software used for environmental management, process design, data collection, data manipulation, remote sensing, collaboration, visualization, and presentation.
Commercially available software will sometimes need to be customized for specific applications in the environmental space. Thus, significant investment in technology may be required to enable an integrated management, measurement, analysis, and reporting infrastructure.

Be a Thought Leader
Thought leadership is something every environmental leader should aspire to achieve. While there are various types of thought leaders (see Figure 2 for some examples), they all have this in common: their expertise is derived not from a title but rather from their record of taking action and leading change with integrity and openness.
Figure 2 Types of thought leaders
Figure 2 Types of thought leaders
The global environmental sustainability ecosystem relies on thought leaders to drive change. With an expansive network of contacts across governmental, non-governmental, industry, and consumer advocacy organizations, a thought leader can connect influential parties to address issues that require close collaboration. A thought leader is also familiar with many of the emerging environmental issues that are of concern to the global community and can carry the flag of these issues to a global audience.
Finally, a thought leader envisions solutions to important issues that have yet to fall into the focus of the industry at large. Development of these solutions may require influencing and collaborating with others—including competitors—and may push your own company into markets not yet serviced, but the result is that thought leaders can effect change that is global.

Remain Current
This is an emerging discipline and there are regular changes to the body of knowledge. Ongoing credibility will require a scholarly understanding of the diverse scientific, policy, legal, economic, technology, and business perspectives promoted by other environmental leaders. It will also require not necessarily conforming with the predominate opinions of the day, but rather promoting unique perspectives based upon an expert understanding of environmental sustainability and computing. This ﻿integrity will be a major differentiator given the increasing number of environmental leaders (or people claiming to be thought leaders) in the indus﻿try.
An established leader must also have security in delegating responsibilities to subordinates who possess specific knowledge on a topic of interest and deferring to more senior representatives of environmental policy within the company when an engagement calls for it. While regular meetings with your seniors and reports will ensure that you maintain comprehensive knowledge on your company's efforts with respect to environmental sustainability, the key is knowing when you need to speak on behalf of the company. This requires a clear understanding of your core commitments and is a trait that reflects the sincere responsibility you have to uphold the convictions on the environment that your internal and external audiences expect.

Michael Walsh is Senior Environmental Product Manager at Microsoft.
Eliza Walsh is a Communications Strategy Consultant and formerly served as a Communications Specialist for Microsoft in China.


Field Notes Sharing a Split Screen
Kentaro Toyama

Extending PC access to as many people as possible is the laudable goal of Microsoft Research India, which has seen success with MultiPoint (discussed in the May 2008 issue of TechNet Magazine), a program that allows many users to interact with one PC using multiple mice.
Split Screen is another form of simultaneous shared access computing conceived by Microsoft Research India. The program sets up a single PC with two keyboards and two mice, and then adapts Terminal Services to split the monitor down the middle. Two people can then share the monitor, running separate instances of the OS and their choice of software independently on each side (﻿research.microsoft.com/users/udaip/splitscreen.htm). For example, one person could be doing word processing while the other works on a spreadsheet.
To enable Split Screen, we use three separate instances of Terminal Server running within Windows Server® 2003 (we are currently upgrading to Windows Server 2008). The first one is a container, and it captures and redistributes all mice and keyboard events. This layer uses the same trick we used for MultiPoint, where all mouse and keyboard events are captured, together with their device IDs (Windows® automatically assigns unique IDs to USB devices as they're plugged in; these are not unique to the hardware device, but they're unique within the current instance of operation—just what's required to realize whether two mouse clicks are coming from the same mouse or from different mice). The container also draws the mouse cursors.
Within it, we open two additional instances of Terminal Server that each receive only the events relevant for one screen. In default mode, all the mouse events from the mouse with ID x, for instance, will end up in the left-hand split screen while those from ID y will end up in the right-hand split screen.
Split Screen uses Terminal Services to split a PC monitor down the middle
Split Screen uses Terminal Services to split a PC monitor down the middle
It's important to have the container instance of Terminal Server so that we have total control of what events go where and to enable more advanced features. For instance, we can allow the right-hand cursor to cross over to the left-hand screen and simply point (perhaps for tutorial usage), or even to interact with the other window.
In this case, some portion of the right-hand mouse events would also feed into the left screen. We had also considered using virtualization technology in Windows to perform similar functions; it can be done, but we found it consumed greater resources.
Researchers were concerned people might become frustrated having only half a screen. We conducted studies in Bangalore, India, with the Hope Foundation that teaches low-income urban youth the basics of computers. Students seemed to learn just as much with Split Screen as they did when they had a single PC to themselves, at least for a limited array of IT training tasks. We also looked for ergonomic problems, but they didn't arise, even on 14" screens. Most importantly, the IT-training center was happy to be able to accommodate twice as many students with the same number of PCs.
Microsoft Research India is in discussions with Terminal Services and other Microsoft groups to determine whether Split Screen is a technology worth bringing to market. If Split Screen sounds like something you'd want to employ, please let us know what scenarios you'd like to use it in. Send e-mail to splitscr@microsoft.com.

Kentaro Toyama is the Assistant Managing Director of Microsoft Research India (research.microsoft.com/india) and Principal Researcher of the Technology for Emerging Markets group (research.microsoft.com/research/tem), which develops technologies for economically poor communities worldwide.


Windows Confidential The Two Worst PCs Ever
Raymond Chen

In March 2007 , when PC World developed its list of the 10 worst PCs of all time, the top two slots caught my eye because we actually used both of them at work. Well, "used" is a strong term. Perhaps I should say that I witnessed these machines, as they spent the majority of their productive lives in a Microsoft employee's office.
The Mattel-branded Barbie PC ranked as second-worst in PC World's list. This computer was a vast improvement over those cheap computers in a boring color. Instead, it was a cheap computer in a boring color that you could dress up with pink stickers applied to the case, the monitor, the speakers—you get the idea. It also came with Barbie-themed software pre-installed.
We acquired one of as a test machine, and the poor tester who was stuck with this computer at least had the sense of humor to dive in with mock enthusiasm, applying all the enclosed stickers and decorations to ensure that the computer was installed "as designed." It was set on a table in clear view from the hallway and anybody who walked past and spotted the bright pink computing disaster was welcome to come on in and play with it.
The Barbie PC served as an ongoing source of amusement. Whenever the machine encountered problems and developers needed to visit the office to debug the machine, you could always count on a double-take or a shout of "cool!" once they realized what kind of computer they had to work on. I'm told that one summer the college interns installed a copy of the Datacenter Edition of Windows Server® on the Barbie PC, just to be twisted.
Top honors—or perhaps more accurately bottom honors—went to the Packard Bell PC. Ah, the memories. Just one example of how well this computer was designed: the out-of-the-box configuration had every single expansion slot filled. Perhaps they thought, "Our computer is so perfect, you'll never need to upgrade it!"
Back in the days of the Windows® 95 project, a senior executive bought one as his home machine and regularly installed the latest build of Windows 95 on it as part of the dogfooding effort. As you might expect, it ran into all sorts of problems and had to be brought in frequently to be debugged.
The development manager of the Windows 95 project was a clever man who took a daringly direct approach to solving problems. For example, to make sure that Windows 95 shipped with broad application compatibility coverage, he drove his pick-up truck to the local computer store and bought one copy of every single PC program in the store. He then unloaded the software onto tables in the cafeteria and invited the Windows 95 product team members to come in and take two pieces of software—with the proviso that they had to install and run any software they took, as well as file bugs against everything that didn't work right, no matter how minor. In exchange, they got to keep the software. The scene in the cafeteria was like a flea market, with people browsing the tables for a good deal and excitedly asking their colleagues, "What'd you get?"
Embarrassed by how often the senior executive had to bring in his home computer to be debugged, the development manager of the Windows 95 project once again took the direct approach. He went to the local computer store and bought a Packard Bell PC identical to the senior executive's.
The fact that two of these computers even existed was bad enough; what made it worse is that the second computer was given to me with the task of installing every new build of Windows 95 on it and debugging any issues that arose. This way, when the senior executive installed the latest build on his home computer, the build would be trouble-free.
If you've been following along and connecting the dots, you may have noticed an obstacle to this plan. Since there were no open expansion slots on the Packard Bell PC, there was nowhere to install a network adapter card. I had to resort to other devious means of obtaining network connectivity. I really hated that computer.

Raymond Chen's Web site, The Old New Thing, and identically titled book deal with Windows history and Win32 programming. The objects in his mirror are closer than they appear.