December 2008
Interop: Authenticate Linux Clients with Active Directory
Many IT shops are divided into two camps—the Windows team and the Linux team—but we all have the same ultimate goal of providing high-quality and cost-effective IT services. One way you can do this is by sharing core software infrastructure. Think Windows and Linux don’t mix? See how you can configure Linux machines to use Active Directory for authentication. Gil Kirkpatrick
Interop: Managing Macs in Your Windows Environment
Today, the likelihood of a homogeneous network has become increasingly remote. It’s in your interest not to limit yourself to a single platform. Instead, you can be known as the IT guy who can do whatever needs to be done—whether it be supporting Mac or Windows. Don Jones teaches what you need to know to set up a Mac on your Windows network, troubleshoot network problems, share files and folders among Macs and Windows-based systems, and configure Macs to use your network printers. Don Jones
Interop: Interacting with Windows from a Mac Environment
How times have changed! These days it is fairly easy to bring Macs into your Windows network infrastructure. And with a little work you can even integrate some of the operating system services. Learn how to connect Macs to Active Directory, see how you can use Entourage with Exchange, integrate the Messenger for Mac 7 application with your Windows-based communications, and explore how you can bridge the platforms with virtualization. Wes Miller
Interop: Managing the Root Password on Your Mac
How do you give your Mac users the rights they need on an as-needed basis and improve security at the same time? Surprisingly, by enabling the root account. Find out how. Chris Stoneff
Active Directory: Understanding Proxy Authentication in AD LDS
Proxy authentication lets users perform a simple bind to an Active Directory Lightweight Directory Services instance but still have an association to an Active Directory account. This can be very useful: it gives developers full access to a user object without giving them access to the Active Directory account, and it allows products that require the X.500 format to be used with Active Directory. Here’s what you need to know about proxy authentication. Ken St. Cyr
Columns
From the Editor: Can’t We All Just Get Along?: | Letters: Readers Speak Out: | Toolbox: New Products for IT Pros: Greg Steen looks at managing your environment with Desktop Authority, checking site links with Xenu Link Sleuth, and managing partitions with GParted Live. Greg also discusses the book “How to Cheat at Administering Office Communications Server 2007”.Greg Steen
SQL Q&A: Row-Overflow, Differential Backups, and More: Paul Randal answers your questions about SQL Server. In this installment, Paul discusses the row-overflow feature, database mirroring and automatic failovers, backup strategies, and managing workloads and memory for failover scenarios.Paul S. Randal | Utility Spotlight: Change Analysis Diagnostic: See how the Change Analysis Diagnostic tool can help users discover system changes on their computers (from updates, new software, and changed hardware) and resolve problems they may encounter due to these changes.Lance Whitney | Utility Spotlight: SyncToy 2.0: This column describes what’s new in version 2 of SyncToy, a utility that helps you keep your files in sync across computers and external drives.Jay Munro
Inside SharePoint: Enterprise Project Management with SharePoint: Microsoft Office Project Server (MOPS) 2007 is extremely complex and difficult to deploy. Yet the effort is worthwhile—MOPS inherits the strengths of SharePoint as an enterprise platform, allowing you to increase the efficiency of team collaboration within and across departments. This article discusses some of the challenges you’ll face when deploying MOPS.Pav Cherny | Windows PowerShell: Building a Better Inventory Tool: Following up on the November installment of his Windows PowerShell column, Don Jones demonstrates an even better inventorying tool and demonstrates a sound process for building your own custom Windows PowerShell functions.Don Jones | Hey, Scripting Guy!: Calculating Server Uptime: You need to calculate server downtime in order to report on server uptime. The Scripting Guys have a Windows PowerShell script that can do this for you.The Microsoft Scripting Guys
Security Watch: Revisiting the 10 Immutable Laws of Security, Part 3: It's been about 8 years since "The 10 Immutable Laws of Security" were first published, and a lot has changed since then. In part three of this series, Jesper Johansson wraps up his analysis of the immutable laws to see if they still hold true after all this time.Jesper M. Johansson | Sustainable Computing: Power Management Settings for Compliance and a Reduced Footprint: In this month’s installment of the Sustainable Computing column we’ll discuss how features in Microsoft operating systems, various IT tools, and system management solutions (such as Microsoft System Center) can help you save money and minimize carbon emissions.Frank Koch, Mike Stephens, and Michael Walsh | Field Notes: Prep Your Patch Policy: Without a thorough and consistent service pack policy, an organization runs the risk of disruptions and downtime. This is because systems throughout the organization may have different patches installed. The key is to think outside your domain.Mark D. Scott
Field Notes: Mark{IT}ing: Synergy in the Shadows: This column delves into the potentials of aligning IT and marketing.Romi Mahajan | Windows Confidential: Keep Your Caches Close: Raymond Chen looks at how a poorly implemented proxy server can completely nullify the benefits of a proxy server.Raymond Chen


Interop
Authenticate Linux Clients with Active Directory
Gil Kirkpatrick
At a Glance:
  • How authentication works in Windows and Linux
  • Using Samba and Winbind
  • Implementation strategies
  • Walking through the Linux-to-Active Directory integrationItem

Contents
Windows Authentication
Linux Authentication
Samba and Winbind
Three Authentication Strategies
Our Implementation Plan
Finding the Right Software
Building Samba
Configuring Linux Networking
Configuring Linux Time Synchronization
Configuring PAM and NSS
Installing and Configuring Samba
The ID Mapping Problem
Joining the Domain and Logging In
What if It Doesn't Work?
Now that It Works, What Do You Have?
Third-Party Solutions
Republicans and Democrats. Toothpaste and orange juice. Linux and Windows. Some things just don’t mix, right? Every IT shop I’ve ever been involved with has been divided into two camps: the Windows team and the Linux team. They don’t really compete with each other, but they sure don't collaborate either. In fact, some places even go so far as to put a yellow line on the floor just to make absolutely sure that there's no inappropriate fraternization between the two groups.
I'm a Windows guy, and I've certainly poked fun at my Linux-oriented colleagues, but we all have the same goal of providing high-quality and cost-effective IT services to the organization. One way we can do that is by sharing core software infrastructure like Active Directory. Just about all IT organizations have settled on Active Directory to provide authentication services to their Windows desktops and servers. Instead of maintaining a separate authentication infrastructure for the Linux environment (along with a separate set of user names and passwords), wouldn't it be better if the Linux computers used Active Directory as well? I think it would, and I'll show you how to do it in this article.

Windows Authentication
Windows has shipped with an integrated network authentication and single sign-on system for quite some time now. Before Windows 2000, Windows NT domain controllers (DCs) provided authentication services to Windows clients using the NT LAN Manager (NTLM) protocol. Although NTLM was not as secure as was originally thought, it was very helpful because it neatly solved the problem of needing to maintain duplicate user accounts across multiple servers on the network.
Starting with Windows 2000, Microsoft moved from NTLM to Active Directory and its integrated Kerberos authentication services. Kerberos was considerably more secure than NTLM, and it scaled better, too. And Kerberos was an industry standard already used by Linux and UNIX systems, which opened the door to integrating those platforms with Windows.

Linux Authentication
Originally, Linux (and the GNU tools and libraries that run on it) was not built with a single authentication mechanism in mind. As a result of this, Linux application developers generally took to creating their own authentication scheme. They managed to accomplish this by either looking up names and password hashes in /etc/passwd (the traditional text file containing Linux user credentials) or providing an entirely different (and separate) mechanism.
The resulting plethora of authentication mechanisms was unmanageable. In 1995, Sun proposed a mechanism called Pluggable Authentication Modules (PAM). PAM provided a common set of authentication APIs that all application developers could use, along with an administrator-configured back end that allowed for multiple "pluggable" authentication schemes. By using the PAM APIs for authentication and the Name Server Switch (NSS) APIs for looking up user information, Linux application developers could write less code, and Linux administrators could have a single place to configure and manage the authentication process.
Most Linux distributions come with several PAM authentication modules, including modules that support authentication to an LDAP directory and authentication using Kerberos. You can use these modules to authenticate to Active Directory, but there are some significant limitations, as I will discuss later in this article.

Samba and Winbind
Samba is an open-source project that aims to provide integration between Windows and Linux environments. Samba contains components that give Linux machines access to Windows file and print services as well as provide Linux-based services that emulate Windows NT 4.0 DCs. Using the Samba client components, Linux machines can take advantage of Windows authentication services provided by Windows NT and Active Directory DCs.
The particular part of Samba that is most interesting to us for this project is called Winbind. Winbind is a daemon (service in Windows parlance) that runs on Samba clients and acts as a proxy for communication between PAM and NSS running on the Linux machine and Active Directory running on a DC. In particular, Winbind uses Kerberos to authenticate with Active Directory and LDAP to retrieve user and group information. Winbind also provides additional services such as the ability to locate DCs using an algorithm similar to the DCLOCATOR in Active Directory and the ability to reset Active Directory passwords by communicating with a DC using RPC.
Winbind solves a few problems that simply using Kerberos with PAM doesn't. In particular, instead of hard-coding a DC to authenticate to the way the PAM Kerberos module does, Winbind selects a DC by searching DNS locator records similar to the way the Microsoft DC LOCATOR module does.

Three Authentication Strategies
Given the availability of LDAP, Kerberos, and Winbind on Linux machines, there are three different implementation strategies we can employ to allow our Linux machine to use Active Directory for authentication.
Using LDAP Authentication The easiest but least satisfactory way to use Active Directory for authentication is to configure PAM to use LDAP authentication, as shown in Figure 1. Although Active Directory is an LDAPv3 service, Windows clients use Kerberos (with fallback to NTLM), not LDAP, for authentication purposes.
LDAP authentication (called LDAP binding) passes the user name and password in clear text over the network. This is insecure and unacceptable for most purposes.
Figure 1 Authenticating to Active Directory using LDAP
The only way to mitigate this risk of passing credentials in the clear is to encrypt the client-Active Directory communication channel using something such as SSL. While this is certainly doable, it imposes the additional burden of managing the SSL certificates on both the DC and the Linux machine. Furthermore, using the PAM LDAP module does not support changing reset or expired passwords.
Using LDAP and Kerberos Another strategy for leveraging Active Directory for Linux authentication is to configure PAM to use Kerberos authentication and NSS to use LDAP to look up user and group information, as shown in Figure 2. This scheme has the advantage of being relatively more secure, and it leverages the "in-the-box" capabilities of Linux. But it doesn't take advantage of the DNS Service Location (SRV) records that Active Directory DCs publish, so you are forced to pick a specific set of DCs to authenticate to. It also doesn't provide a very intuitive way of managing expiring Active Directory passwords or, until recently, for proper group membership lookups.
Figure 2 Authenticating to Active Directory using LDAP and Kerberos
Using Winbind The third way to use Active Directory for Linux authentication is to configure PAM and NSS to make calls to the Winbind daemon. Winbind will translate the different PAM and NSS requests into the corresponding Active Directory calls, using either LDAP, Kerberos, or RPC, depending on which is most appropriate. Figure 3 shows this strategy.
Figure 3 Authenticating to Active Directory using Winbind

Our Implementation Plan
Because of the enhanced integration with Active Directory, I chose to use Winbind on Red Hat Enterprise Linux 5 (RHEL5) for my Linux-to-Active Directory integration project. RHEL5 is the current version of the commercial Red Hat Linux distribution, and it is fairly popular in enterprise datacenters.
Getting RHEL5 to authenticate to Active Directory basically requires five separate steps, as follows:
  1. Locate and download the appropriate Samba and other dependent components.
  2. Build Samba.
  3. Install and configure Samba.
  4. Configure Linux, specifically PAM and NSS.
  5. Configure Active Directory.
The next few sections in this article describe these steps in more detail.

Finding the Right Software
One of the biggest differences between Linux and Windows is that Linux consists of a small operating system kernel and a huge collection of separately downloadable and installable components. This makes it possible to create very specific Linux configurations optimized for certain tasks, but it can also make configuration and management of a server extremely complicated. Different distributions handle this in different ways. Red Hat (and its non-commercial cousin Fedora) use the Red Hat Package Manager (RPM) to install and manage these components.
Linux components for Red Hat come in two forms. RPM files contain binary files that have been pre-compiled and built for a specific combination of component version, Linux distribution, and CPU architecture. So you could download and install, for instance, the 1.3.8-5 version of the Common UNIX Printing System (CUPS) built for Fedora version 10 running on an Intel x86 architecture CPU. Given that there are a dozen different CPU architectures, more than 100 Linux distributions, and thousands of packages and versions, you can see that there are an incredible number of binary RPMs from which to choose.
Source RPM files, on the other hand, contain the actual source code for a given package. The expectation is that you will download and install the sources, configure the build options, and compile and link the binaries yourself. The idea of building your own operating system components is daunting for a Windows guy used to installing whatever Microsoft provides on the Windows installation CD, but the package manager makes the process fairly painless and surprisingly reliable. The Samba group releases updates and security patches at a furious rate; in July and August 2008 alone, there were four releases of Samba 3.2, with a total of more than 100 bug and security fixes. For this project, I downloaded the sources for the latest stable version of Samba, version 3.0.31.
Why did I download the Samba sources instead of a pre-compiled set of binaries? That was certainly what I attempted to do first. What I discovered after many hours with a debugger was that the binaries I downloaded were not built with the correct options to support Active Directory authentication. In particular, the code that supports Linux ID mapping in Active Directory was turned off in the default builds; hence I had to rebuild Samba with the appropriate build options. I'll talk more about ID mapping later in this article.
Even though Linux is natively a small kernel, the Red Hat Enterprise distribution comes with many packages preinstalled. Normally this makes life much easier because you start out with a complete working operating system, but the packages that are preinstalled sometimes conflict with software you wish to install later.
I did not include Samba when I installed Red Hat (normally Samba is installed by default) because I wanted to use a more current version. However, the newer version of Samba requires new versions of several other libraries and utilities that were already installed. These sorts of dependency problems are quite annoying, but they are easily solved using the RPM.
There are many Web sites that host binary RPM packages. The one I used (for no other reason that it was the first one I found) is called PBONE, located at rpm.pbone.net. It has a convenient way of searching for packages and had all the binaries that I needed for my CPU architecture (i386) and operating system distribution (Red Hat Enterprise Linux 5/Fedora 7&8).
I had to download and update the packages listed in Figure 4 to build and install the latest 3.0 version of Samba (there is an even later 3.2 version tree that I have not tried). Note that these packages target the Fedora Core (fc) distribution. Red Hat is based on the same sources Fedora uses and is completely interoperable with it. Packages built for Fedora Core 7 and later will run on RHEL5 with no modification. Place the downloaded RPM files in the /usr/src/redhat/RPMS directory.
Figure 4 Packages needed for building and installing Samba 3.0.31
samba-3.031-0.fc8.src.rpm | Samba 3.0.31 source RPM
gnutls1.6.3-3.fc7.i386 | GNU Transport Layer Security (TLS) libraries
gnutils-devel-1.6.3-3.fc7.i386 | GNU TLS development files
popt-1.12-3.fc8.i386 | Command-line argument parsing libraries
popt-devel-1.12-3.fc8.i386 | Command-line argument parsing development files
cups-libs-1.2.12-11.fc7.i386 | Common UNIX Printer System libraries
cups-devel-1.2.12-11.fc7.i386 | Common UNIX Printer System development files
cups-1.2.12.11.fc7.i386 | Common UNIX Printer System binaries

Building Samba
The first step in building Samba is to download the proper source RPM. I downloaded the source RPM for Samba 3.0.31 from the PBONE site. Next, place the downloaded source RPM file in /usr/src/redhat/SRPMS; this is the standard directory for source RPMs during the build process.
Open a terminal session (command-line window in Windows parlance) and move to the SRPMS folder. Once that is done, install the source package using the command, as shown in Figure 5.
Figure 5 Installing the Samba source RPM
If you see the error warning "user mockbuild does not exist—using root," don't worry. This error indicates that the Mock build utilities aren't installed. The build process will work without them.
Next, move to the /usr/src/redhat/SPECS directory and edit the file SAMBA.SPEC, which contains the Samba build options. Search for the line that starts with "CFLAGS=", and make sure the option "--with-shared-modules=idmap_ad,idmap_rid" is present. This option ensures that the build process will include the code that translates Linux UIDs (unique identifiers) properly to Active Directory. Figure 6 shows this option.
Figure 6 The with-shared-modules build option
Next, you may have to update some of the libraries on your machine to properly build and install Samba; it depends on what versions of the libraries you happen to have installed. In my case, I had to install the packages listed in Figure 4 using the rpm --install command; in some cases I had to use the --force option to get past some of the dependency problems.
To build Samba, move to the /usr/src/redhat directory and run the command rpmbuild –bb SPECS/samba.spec, as shown in Figure 7. The process will leave a new samba-3.0.31-0.i386 RPM file in the /usr/src/redhat/RPMS directory. We will install this RPM file later in the project.
Figure 7 Creating the Samba binary RPM file

Configuring Linux Networking
In order to authenticate with Active Directory, your Linux machine must be able to communicate with a DC. You have to configure three networking settings in order for this to happen.
First, it's important to make sure that the network interface for your Linux machine is configured properly, either by using Dynamic Host Configuration Protocol (DHCP) or by assigning it an appropriate IP address and netmask using the ifconfig command. Under RHEL5, you configure the network by selecting Network from the System | Administration menu, as shown in Figure 8.
Figure 8 Configuring the network
Next, ensure that the DNS resolver for the Linux machine is set to use the same DNS name server that your DCs use; in the majority of cases, this is a DC in the domain to which you want to join the Linux machine, assuming you are using Active Directory-integrated DNS. You configure the DNS resolver on the DNS tab of the same Network configuration utility you used to configure the network, as shown in Figure 9.
Figure 9 Setting the primary DNS resolver
Finally, once you have completed those steps, you must set the host name of the Linux computer to reflect its name in the domain. Even though you can set the host name using the Network configuration app, this doesn't seem to always work properly.
Instead, edit the /etc/hosts file directly, and add an entry below the localhost.localdomain entry that has the form <ip address> <FQDN> <host name>. (An example would be "10.7.5.2 rhel5.linuxauth.local linuxauth".) I should note that failure to do this will result in the creation of an incorrect computer object in the directory after you join the Linux computer to the domain.

Configuring Linux Time Synchronization
The Kerberos protocol is dependent on the authenticating systems having clocks that are synchronized within a relatively small value. By default, Active Directory allows a maximum time skew of five minutes. To ensure that your Linux systems and your DCs' system clocks stay within this value, you should configure your Linux systems to use the Network Time Protocol (NTP) service of a DC.
Next, on the Linux server, run the Date & Time utility from the System | Administration menu, and then click on the Network Time Protocol tab. Check the Enable Network Time Protocol box, and then add the IP address of the DC you want to use as a network time source. Note that this should typically be the DC in the domain that holds the primary domain controller (PDC) emulator Flexible Single Master Operations (FSMO) role. Figure 10 is an example of how to set the Linux network time source.
Figure 10 Configuring the Network Time Protocol

Configuring PAM and NSS
PAM and NSS provide the glue between a Linux application, such as the desktop, and Winbind. Like many Linux services, you configure PAM and NSS through text files. We'll look at configuring PAM first.
PAM provides four authentication-related facilities to apps that use it. The authentication facility lets an application determine who is using it. The account facility provides account management functions that aren't specifically related to authentication, such as login time restriction. The password facility provides mechanisms for soliciting and managing passwords. The session facility performs user-related setup and tear-down tasks for the application, such as logging or creating files in a user-specific directory.
PAM under Red Hat stores its configuration files in the /etc/pam.d directory, which will contain a text file for each application that uses PAM for authentication. For instance, the file /etc/pam.d/gdm contains the PAM configuration information for the Gnome Desktop Manager (GDM), the default windowing environment for Red Hat. Each PAM configuration file contains multiple lines, with each line defining some aspect of the PAM authentication process. Figure 11 shows the contents of the PAM configuration file for GDM.
Figure 11 PAM configuration file for Gnome Desktop Manager
Each entry in a PAM configuration file has the form <management group> <control> <module> <parameters>, where <management group> corresponds to the facility the configuration entry pertains to: auth, account, password, or session. The control keywords, which are described in Figure 12, tell PAM how to process the configuration entry. The third column of the file contains the name of a PAM shared library in the /lib/security directory. Shared libraries contain dynamically loadable executable code, similar to DLLs in Windows. Additional terms after the module name are parameters that PAM passes to the shared library.
Figure 12 PAM control keywords
Keyword | Description
Required | If the module succeeds, PAM continues evaluating the remaining entries for the management group, and the results will be determined by the results of the remaining modules. If the module fails, PAM continues evaluation but will return failure to the calling application.
Requisite | If the module succeeds, PAM continues evaluating the management group entries. If the module fails, PAM returns to the calling application with no further processing.
Sufficient | If the module succeeds, PAM will return success to the calling application. If the module fails, PAM continues evaluation, but the results will be determined by subsequent modules.
Optional | PAM ignores the results of the module unless it is the only module specified for the management group.
Include | PAM includes the contents of the referenced PAM configuration file and processes the entries it contains.
You can see that each management group has several entries. PAM processes the entries in order by calling the named module. The module then returns either success or failure, and PAM proceeds according to the control keyword.
You'll notice that the PAM configuration file for GDM includes system-auth in all of its management groups. This is how PAM establishes default authentication behavior for GDM. By modifying system-auth, you can modify the authentication behavior for all of the applications that include the system-auth file in their PAM configurations. The default system-auth file is shown in Figure 13.
Figure 13 PAM system-auth file
The Name Service Switch (NSS) module hides the specifics of system data storage from the application developer, in much the same way that PAM hides the details of authentication. NSS lets the administrator specify the way system databases are stored. In particular, the administrator can specify how user name and password information is stored. Because we want applications to look up user information in Active Directory using Winbind, we have to modify the NSS configuration file to show that.
Red Hat includes a little graphical applet for configuring PAM and NSS called system-config-authentication. It takes care of most (but not all) of the changes you need to make to the system-auth and nss.conf files.
Run the system-config-authentication application and you will see a dialog like the one shown in Figure 14. Check the Winbind option on both the User Information tab (which configures the nss.conf file) and the Authentication tab (which modifies system-auth file).
Figure 14 The systemconfig-authentication dialog
Click the Configure Winbind button and you will see the dialog in Figure 15. Enter the name of the domain you want users to authenticate to in the Winbind Domain field, and select "ads" as the security model. Enter the DNS domain name of the Active Directory domain in the Winbind ADS Realm field. In the Winbind Domain Controllers field, enter either the name of a DC you want this Linux system to authenticate with or an asterisk, indicating that Winbind should select a DC by querying DNS SRV records.
Figure 15 Configure Winbind dialog
Select the appropriate default command shell your Active Directory users should have; in this case, I selected the Bourne-again Shell, or BASH. Don't try the "Join Domain" button at this point. You will join the machine to the domain later on.
There is one additional change to make to the /etc/pam.d/system-auth file after you have modified it to support Winbind. When a Linux user logs in, the system requires that the user have a home directory. The home directory contains many user-specific preferences and configuration items, much like the Windows registry. The problem is that because you are creating your users in Active Directory, Linux will not automatically create the user's home directory. Luckily, you can configure PAM to do this as part of its session configuration.
Open the /etc/pam.d/system-auth file, then scroll down toward the bottom and insert a line before the last line in the session section that reads "session optional map_mkhomedir.so skel=/etc/skel umask=0644" (see Figure 16). This line configures PAM to create a home directory for a user if one doesn't exist. It will use the directory /etc/skel as a "skeleton" or template, and it will assign the permissions mask 0644 (read and write for owner, read for the primary group, and read for everyone else) to the new folder.
Figure 16 Creating a home directory for users

Installing and Configuring Samba
To install the Samba binaries you just created, change to the /usr/src/redhat/RPMS directory. All of the RPM files created by the rpmbuild command will appear in this directory. Remember that Samba includes binaries that allow a Linux client to access a Windows (or Samba) file share, as well as code that allows a Linux system to act as a Windows file server, a Windows printer server, and a Windows NT 4.0-style DC.
We don't need all of that to allow Linux to authenticate to Active Directory; all we really need are the Samba common files and the Samba client binaries. These files are conveniently split out into two RPM files: samba-client-3.0.31-0.i386.rpm and samba-common-3.0.31-0.i386.rpm. Install the RPM files using the rpm --install command. Here is an example: rpm --install samba-common-3.0.31-0.i386.rpm. (Note that you will need to install the –common RPM file first.)
Once you've installed the Samba client binaries, you must modify the default Samba configuration to make sure Winbind handles authentication properly with Active Directory. All of the Samba configuration information (both client and server) can be found in the smb.conf text file, which by default is in the /etc/samba directory. Smb.conf can contain an enormous number of configuration options, and a complete discussion of its contents is beyond the scope of this article. The samba.org Web site and the Linux man pages discuss smb.conf in some detail.
The first step is to configure Winbind to use Active Directory for authentication. You must set the security model in smb.conf to "ads". The system-config-authentication utility should have set this for you already, but it's always good to check. Edit the smb.conf file and search for the section labeled Domain Member Options. Find the line that starts with "security" and make sure it reads "security = ads". The next configuration step determines how Winbind will map Windows security principals such as users and groups to Linux identifiers, and that requires a little more explanation.

The ID Mapping Problem
There's one big problem I haven't mentioned yet with authenticating Linux users with Active Directory, and that is the problem of UIDs for users and groups. Internally, neither Linux nor Windows refer to users by user name; instead they use a unique internal identifier. Windows uses the Security Identifier, or SID, which is a variable-length structure that uniquely identifies each user within a Windows domain. The SID also contains a unique domain identifier so that Windows can distinguish between users in different domains.
Linux has a much simpler scheme. Each user on a Linux machine has a UID that is simply a 32-bit integer. But the scope of the UID is limited to the machine itself. There is no guarantee that the user with UID 436 on one Linux machine is the same as the user with UID 436 on another Linux machine. Consequently, a user will have to login to each machine he needs to access, clearly not a desirable situation.
Linux network administrators usually address this problem by providing network authentication using either Network Information System (NIS) or a shared LDAP directory. The network authentication system provides the UID for the user, and all the Linux machines that use that authentication system will share the same user and group identifiers. In this situation, I will use Active Directory to provide the unique user and group identifiers.
There are two strategies I can use in order to address this problem. The first (and also most obvious) strategy is to create a UID for each user and group and store that identifier with the respective object in Active Directory. This way, when Winbind authenticates a user, it can look up the UID for the user and provide it to Linux as the user's internal identifier. Winbind refers to this scheme as Active Directory ID mapping, or idmap_ad. Figure 17 shows the process of Active Directory ID mapping.
Figure 17 Active Directory ID mapping
The only downside to Active Directory ID mapping is that we have to provide a mechanism to ensure that every user and group has an identifier, and that these identifiers are all unique in the forest. See the sidebar, "Configuring Active Directory for Active Directory ID Mapping," for more information.
Happily, there is another ID mapping strategy that has a lot less administrative overhead. Recall that the Windows SID uniquely identifies the user within a domain as well as the domain itself. The portion of the SID that uniquely identifies the user within the domain is called the Relative Identifier, or RID, and is in fact a 32-bit integer. So, Winbind can simply extract the RID from the SID when the user logs in and then use the RID as the unique internal UID. Winbind refers to this strategy as RID mapping, or idmap_rid. Figure 18 illustrates how RID mapping actually works.
Figure 18 RID mapping
RID mapping has the benefit of zero administrative overhead, but you can't use it in a multi-domain environment because of the likelihood of users in different domains having the same RID value. But if you have a single Active Directory domain, RID mapping is the way to go.
To configure the Winbind ID mapping strategy, edit the /etc/samba/smb.conf file again and add the line "idmap backend = ad" to use the Active Directory mapping strategy, or "idmap backend = rid" if you want to use the RID mapping strategy. Make sure that there are no other lines specifying the mapping strategy in the file.
There are a couple of other configuration options we need to add to the smb.conf file for Winbind. Even though we set up PAM to make the home directory for each user when they log in, we need to tell Winbind what the name of that home directory is. We do this by adding the line "template homedir = /home/%U" to smb.conf (see Figure 19). This tells Winbind that the home directory for each user that authenticates using Active Directory will be /home/<user name>. Be sure to create the /home directory beforehand.
Figure 19 Specifying the name of the home directory

Joining the Domain and Logging In
Now that the network, PAM, NSS, and Samba Winbind are all configured properly, it's time to join the Linux machine to the domain. You do this using the Samba NET command. At a shell prompt, run "net ads join –U <administrator name>". Replace <administrator name> with the name of an account that has sufficient privileges to join a machine to the domain.
The net command will prompt you for the user's password. If everything works properly, the net command will join your machine to the domain. You can use Active Directory Users and Computers to locate the newly created computer account.
You can test the state of the join using the Winbind test tool called wbinfo. Running wbinfo –t will test the trust relationship between the machine and the domain. Running wbinfo –u lists all the users in the domain, and wbinfo –g lists all the groups.
If you successfully join the Linux machine to the domain, the next step is to try to log in using an Active Directory user account and password. Log off the Linux machine, and log in using an Active Directory user name. If everything works properly, you should be able to log in.
Configuring Active Directory for Active Directory ID Mapping
This information applies only if you're using Active Directory ID mapping. If you've decided to use RID mapping, feel free to skip this sidebar.
Before you can start logging in to your Red Hat server using an Active Directory account, you have to make some changes to Active Directory itself. First, the Active Directory schema has to accommodate the attributes that Winbind uses to store user information. If you are running Windows Server 2003 R2, the schema is ready to go. If you have an earlier version of the Active Directory schema, you will have to extend it using the Microsoft Services for UNIX (SFU) package.
You can find more on Services for UNIX on TechNet. SFU also includes an additional property page for the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in that lets you manage the user ID and group ID information that Linux requires.
Once the schema is properly set up, you have to provide Linux identifiers for all of the users (and the groups to which they are members) that might log in to your Linux machine. This means that you have to define values for the uidNumber and gidNumber attributes for the users and groups that might log in to your Linux machines. But you should be aware of some requirements for these attributes:
  1. Linux requires a UID for every user that authenticates. Because you want to manage user information in Active Directory, every user account that will log in to a Linux machine must have a unique uidNumber attribute. The specific value you use for a uidNumber isn't important, but it must be unique across all the users that might log in to the Linux machine.
  2. Every Linux user must also have a default group identifier, so each Active Directory user that will log in to a Linux machine requires a value for the gidNumber attribute as well. This value doesn't have to be unique among users, but it must uniquely identify the group.
  3. Every group in Active Directory should have a unique value for its gidNumber attribute. Strictly speaking, it's OK for groups to not have a value for the gidNumber attribute, but Winbind expects, when it authenticates a user, that every group to which that user is a member will have a unique gidNumber value. It's probably easiest just to make sure that every group has a unique gidNumber value.
  4. Winbind expects that every user it looks up in Active Directory is a member of the Domain Users group, so it also expects that the Domain Users group has a value for its gidNumber attribute.

What if It Doesn't Work?
Setting up a Linux machine to authenticate with Active Directory using Winbind is not a trivial project. There are lots of pieces to configure and lots of things that can go wrong. The fact that every version of Linux and every version of Samba is a little different doesn't help matters. But there are a handful of places you can look to help determine what's going on.
First, there is the Linux system log file, which is maintained in /var/log/messages. Samba will place messages within this file for significant events such as missing files or bad configuration. In addition to the system log file, there are also the log files for Samba and Winbind. You can find these in /var/log/samba, and they will provide you with some additional information.
You can increase the detail (and the volume) of the log messages emitted by Winbind by modifying its startup script to set the debug level. Edit the /etc/init.d/winbind shell script, and add "-d 5" to the winbindd command. This will increase the debug level to 5 (allowable values are from 1 to 10), which will cause winbind to generate more detailed error messages.
If Winbind is getting as far as communicating with a DC, you can run a network packet capture utility such as Netmon 3.1. This lets you analyze exactly what Winbind is trying to do. And you can also inspect the Windows security log on the DC, which will show authentication attempts.

Now that It Works, What Do You Have?
If you've managed to get everything to work, you now have the ability to log into your Linux system using credentials that you maintain in Active Directory. This is a huge improvement over managing identities locally on the Linux machine or using an insecure system such as NIS. It lets you centralize your user management on one identity store: Active Directory.
But there are a several things that are missing to make this solution truly useful. First, getting technical support is a bit of a hit-or-miss operation. Most Linux organizations are somewhat in the dark when it comes to Active Directory, and the support you can get from the Linux community depends entirely on who happens to read your post and how they feel that day.
There are also no migration or deployment tools with Samba. If you have existing Linux accounts with their associated user IDs and permissions, you will have to manually ensure that they maintain their UIDs when you migrate them to Active Directory.
Finally, one of the most important Active Directory apps, Group Policy, isn't yet available with Samba, although it is in the works. Even though you can join a Linux system to Active Directory with Samba, you can't manage it using Group Policy.

Third-Party Solutions
Authenticating Linux machines with Active Directory is clearly A Good Thing, but rolling your own solution using Samba Winbind is tedious if not downright painful. You would think some innovative software vendors would step up with an easier-to-use solution, and you would be right.
There are four commercial software vendors that have developed easy-to-install-and-use versions of what I've demonstrated in this article. They provide the code and migration tools for nearly every popular version of Linux, UNIX, and Apple Macintoshes, as well as support for managing Linux machines using Group Policy.
The four companies are Centrify , Likewise Software, Quest Software and Symark . All four vendors provide similar functionality, including Group Policy management, across a wide array of Linux distributions. Likewise Software has recently open-sourced its implementation, called Likewise Open, although its Group Policy component remains a commercial product. Likewise Open will be available with several major Linux distributions. (Full disclosure: while in the process of writing this article, my company, NetPro, was acquired by Quest Software.)
Does it make sense to build your own authentication system using Samba and Winbind when there are commercial options available? If spending money on integration software isn't in the budget, then going the open-source route with Samba has the advantage of being free. You also get all the source code, which can be a compelling benefit. But migrating existing Linux machines and their existing UIDs is a very thorny problem.
On the other hand, if you want to save installation and implementation time, you have existing Linux machines you need to migrate, or you would rather have someone to call for an authoritative answer to your question, then checking out one of the commercial solutions makes sense. And if you need Group Policy management, then the commercial alternative is your only choice.
But whichever way you go, integrating Linux authentication with Active Directory reduces the effort you spend managing multiple user accounts, improves system security, and provides you with a single identity store to manage and audit. And those are all pretty compelling reasons to give it a try.

Gil Kirkpatrick has designed or developed dozens of successful commercial software products in his 30-year career, and he is the founder of the Directory Experts Conference (now called The Experts Conference). Gil is the author of Active Directory Programming and is a frequent contributor to Windows IT Pro and TechNet Magazine. In his current role as Expert-in-Residence at NetPro (now part of Quest Software), Gil consults on various security, identity, and marketing projects and speaks at technology seminars and conferences around the world.


Interop
Managing Macs in Your Windows Environment
Don Jones
At a Glance:
  • Setting up a Mac on your network
  • Troubleshooting network problems
  • Sharing files and folders among Macs and Windows-based systems
  • Using network printers for your Mac

Contents
Getting on the Network
Troubleshooting the Network
Unsupported Networking?
File Sharing
Print Sharing
Embrace Your Macs
The Mac family of computers from Apple is becoming increasingly popular on more and more networks. For instance, at the end of 2007, Digital Trends reported that the US Army uses about 20,000 Macs on a regular basis. This is one part of a larger program that is intended to increase diversity in the computing base so that a single attack (such as a virus) would not impact all of its computers.
Macs can become a part of a primarily Windows-based network for a variety of reasons. Someone on the network may simply think Macs are cool, users who own Macs at home may want a similar computing experience at work, or users who have been trained on Macs may opt to work on Macs. Whatever the reason, it happens, and you need to be prepared for the time when, as a Windows network administrator, you have to deal with Macs in your environment.
You may not think so, but this actually creates a fantastic opportunity for you as an IT professional. Instead of being like many administrators who "don't do Macs," you can be the IT guy who will do whatever the organization needs—whether it be supporting Macs or Windows. This can greatly increase your value to the organization, broaden your resume (for promotions and future job prospects), and bring a little something different to your daily routine. Fortunately, current Mac client computers aren't very difficult to support. In fact, you'll be surprised at how similar they are to Windows computers.
The Internet has played an enormous role in bringing Macs and Windows closer together. Internet technologies were based primarily on technologies found in UNIX operating systems, such as the TCP/IP protocol suite. Over the past decade or so, Windows has adopted many of those protocols for standard operations, such as networking, printing, and even authentication. The current Mac operating system, Mac OS X 10.5, is actually based on the BSD (Berkeley Software Distribution) UNIX platform, and thus it uses many of the same protocols under the hood. Sure, the Mac UI differs from the Windows UI, but what's happening underneath those UIs is becoming increasingly similar.

Getting on the Network
The first challenge to integrating Macs in the infrastructure—getting them on the network—has definitely gotten easier. While older Macs support TCP/IP, Macs have always been known to rely primarily on the AppleTalk protocol, a proprietary network protocol known for its chattiness. In fact, the Microsoft Services for Macintosh solution gave Windows Server the ability not only to speak AppleTalk but also to emulate a Mac for file and print sharing.
What many people don't know is that AppleTalk has officially been a dead protocol for many years. Apple itself turned off AppleTalk in the late 1990s, and most infrastructure devices (routers and so forth) stopped supporting it in the 2001 and 2002 timeframe. Today, Macs are almost purely TCP/IP. Click on the omnipresent Apple menu at the top of the screen, select System Preferences (the Mac equivalent of the Windows Control Panel), and double-click Network to configure the network.
Figure 1 shows you that the available networking interfaces—Ethernet, the wireless AirPort, and so forth—are easily configured to use Dynamic Host Configuration Protocol (DHCP), which is the default. And just as the latest versions of Windows, Mac now even supports IPv6.
Figure 1 Configuring networking interfaces on a Mac
Clicking Advanced will allow you to configure more details on TCP/IP, DNS, and even WINS. (Anyone still using WINS out there?) You can enable AppleTalk if the system needs to communicate with older Macs, and modern 802.1X authentication is available. As shown in Figure 2, you can manually configure various protocol proxies or allow proxy configuration to occur automatically by means of a PAC file.
Figure 2 Configuring proxy settings on a Mac
So much for AppleTalk! You might, however, be interested in a TCP/IP-based advertising and discovery protocol that Macs use. This protocol is called Bonjour, and there's a version of it available for Windows, too. (It's important to note that Bonjour was called Rendezvous while under development, and it is still referred to by that name in some older technical documents.)
You can think of Bonjour as a spiritual successor to NetBIOS, although it bears a stronger resemblance to Universal Plug-N-Play (UPnP), another protocol supported by both Mac and Windows. The main purpose of Bonjour is to advertise available services such as file sharing, printers, and remote speakers (used by Apple iTunes and Apple TV).
Bonjour isn't a broadcast-based protocol, so it isn't as chatty as you might think—though it does put a noticeable amount of additional traffic on the network. It can be disabled—in a corporate environment where you're not relying on computers being able to advertise and discover services, disabling Bonjour can remove a bit of overhead from the network. To disable Bonjour, just open a terminal window (the Mac command-line window, which typically runs the UNIX BASH shell) and run:
launchctl unload -w
  /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
Note that disabling Bonjour can make some of the built-in Mac applications, perhaps most notably iChat, behave a bit oddly. If you plan to allow internal apps like iChat (which is compatible with AOL Instant Messenger, which some companies allow internally), you should do some testing first to make sure everything works as expected.
Once on the network, Macs behave in almost exactly the same way as your Windows clients behave. They use DHCP to get an IP configuration, they auto-configure IPv6 if you're not providing an IPv6 configuration via DHCP, they use your DNS and proxy servers, and so forth.

Troubleshooting the Network
Macs offer two distinct ways to troubleshoot the network. One approach will be more familiar to Windows administrators because it utilizes many of the command-line tools you already use. You start by clicking on the desktop wallpaper of the Mac—this activates Finder, which is the Mac equivalent to Windows Explorer.
You can then press Shift+Command+U to open the Utilities folder. Now double-click Terminal to open the BASH shell. Here you have access to most of the common network troubleshooting tools—Ping, Traceroute (it's not tracert, but it does work the same way), Nslookup, and more. Figure 3 shows a few of them in action. Note that ipconfig is available, but it is a very different—and more powerful—command than what you get in Windows. You'll need to take some time to learn how to use Ipconfig on the Mac, though you might find that the Mac UI offers an easier way to access this information.
Figure 3 Using some familiar network troubleshooting tools on the Mac
If you'd rather not use a command line, you can use the Network Utility application, which is an excellent all-in-one tool with a graphical UI (see Figure 4). The Network Utility application can be found in the same Utilities folder where Terminal is located.
Figure 4 The Network Utility app gives a graphical UI to network troubleshooting
Network Utility provides a graphical UI for Netstat, Ping, DNS Lookup, Traceroute, and more. It even has a built-in port scanner! You can perform most of your network troubleshooting right from this tool. The Info tab even displays the configuration information you would get from ipconfig on a Windows computer.

Unsupported Networking?
I've had some users bring up the lack of Spanning Tree Protocol (STP) support in Macs. Most newer networking switches support STP as a means of reducing network overhead and improving throughput. And there's a persistent belief that Macs don't work when STP is enabled.
It is true that the AppleTalk protocol does not work well with STP, and if you must use AppleTalk, you'll have to disable STP on the switch ports used by Apple computers. But as I already mentioned, AppleTalk is considered a dead protocol and there shouldn't be much reason to use it.
My suggestion is that you shut off AppleTalk unless you explicitly need to leave it enabled to support older Macs—and I mean Macs running OS 8 or the very earliest versions of OS 9. That's more than 10 years old! Macs running TCP/IP have no troubles with STP or anything else you may be using to fine-tune your network infrastructure.

File Sharing
You might be surprised to learn that Macs have built-in abilities to connect to Windows-based shared folders. With Finder active, press Command+K (or select Connect to Server from the Go menu). As Figure 5 illustrates, you simply need to enter the protocol prefix smb:// and then the name of the server to which you want to connect. Once that is done, you will be prompted to authenticate, and if you haven't specified a shared folder, you will be prompted to select one.
Figure 5 Connecting to Windows-based shared folders
Unlike Windows systems, Macs don't have drive letters, and, therefore, you can't map a network drive. Instead, connected drives show up in Finder, along with regular, local disks. Connected drives can use FTP, Server Message Block (SMB), or many other protocols. And although Macs don't technically have logon scripts, you can easily configure them to have drives automatically reconnect each time the user logs on.
To do this, open a Finder window to view a list of connected drives. Then open System Preferences and select Accounts. Select the user's account and switch to the Login Items tab. Then drag any connected drives from Finder to the list of login items and ensure that each drive is checked to have it automatically reconnect at login.
Likewise, Macs can share local folders with Windows clients. In System Preferences, you need to open the Sharing panel and enable the File Sharing option, as shown in Figure 6. Then add whatever folders you like to the list of Shared Folders. This procedure is different than on Windows. In Windows Explorer, you would right-click the folders you want to share and configure sharing on the folder itself. With a Mac, you centrally control the list of folders to be shared.
Figure 6 Enabling the File Sharing option on a Mac
This is also where you control Mac permissions. But Macs, given their UNIX base, have a simpler system of permissions than Windows has. Essentially, on each folder, you can assign Read, Read & Write, Write Only, or No Access permissions to any user or group. One helpful trick is to click the Options button in the Sharing pane and ensure that files are being shared using SMB, the protocol Windows clients know how to use. The default is to share only via Apple File Protocol (AFP), which is accessible only to other Macs.

Print Sharing
Printing from a Mac can be tricky—not because printing is difficult to set up, but rather because there are so many options from which to choose. The first step, obviously, is to find out the type of printer to which you're printing and then to obtain a Mac-compatible device driver for it. Note that this step can be difficult for older printers, but here is a short list of rules that can help you find the right driver:
  • Newer inkjet printers, especially those from Canon, Epson, and HP, typically have Mac drivers. Check the vendor's Web site.
  • Apple is notorious for making sweeping changes to the printing subsystem in minor version releases. So it's important to always match printer drivers to the major and minor version number of the Mac OS. A printer driver written for OS 10.2 might not work with 10.5.
  • Laser printers are the toughest to find specific drivers for, but you can usually use either a generic HP PCL driver or a generic PostScript driver, depending on which of the following two printer control languages your laser printer supports. Adobe publishes a free, generic PostScript driver for Macs and a free open-source PCL driver for Macs is available at sourceforge.net.
Newer versions of the Mac OS, on the other hand, use a licensed version of the Common UNIX Printing System (CUPS), which makes it much easier for vendors to write drivers. It's important for you to understand that Macs don't work with the Windows Point and Print system, which means you cannot simply store the Mac printer driver on a Windows print server, as you can for different versions of Windows. And Macs aren't able to utilize the print server's printer driver, either.
Instead, Macs need to have their own locally installed printer driver. The printer driver is responsible for accepting print data from an application and then generating the print spool file. How the spool file gets to the printer depends on what type of printer you're using.
With the right driver installed, you can then set the printer up in System Preferences, under the Print & Fax panel. You'll see that Macs support a variety of methods for connecting to printers:
  • Line Printer Daemon (LPD) is supported by UNIX print servers, by Windows servers running Microsoft Services for UNIX, and by most printers attaching directly to the network or attaching by means of a network print server device.
  • HP JetDirect connections are supported directly.
  • Internet Printing Protocol (IPP), which is based on HTTP and used within CUPS, is supported by many remote-printing services offered at hotels and other venues.
  • Windows printers shared by a Windows server or client computer (see Figure 7) are supported, as Macs have the ability to browse Windows workgroups (which they detect by using the network browse master) or domains.
  • Bluetooth printers aren't typically used in an enterprise situation, but if you have a user who needs a personal printer, this provides an easy way to connect to one.
  • AppleTalk, which of course requires that the AppleTalk protocol be turned on, is useful for connecting to older printers that support AppleTalk.
  • Vendor-specific connectivity, such as Canon IJ Network, Epson FireWire, Epson TCP/IP, HP All-in-One faxes, and HP IP Printing.
  • Bonjour is supported by many newer network printers designed for small office and workgroup use (such as many of the newer networked all-in-one devices), allowing printers to advertise their presence and making it possible for Macs to quickly locate them.
Figure 7 Accessing shared Windows printers
From a Windows perspective, the ability for Macs to connect directly to Windows printers, and to connect to LPD printers, will be the most useful option for you. Keep in mind that Windows print servers often use either LPD or JetDirect to connect to physical print devices.
While a Mac can indeed connect directly to the physical printer using the same protocol, remember that you won't be able to use the Windows server computer to manage the print jobs submitted by the Mac. As an alternative, having the Mac submit print jobs to the Windows server, rather than directly to the printer, allows the Mac print jobs to be prioritized and managed along with the print jobs being submitted by your Windows client users.

Embrace Your Macs
As you can see, getting Macs running on your network and providing them with basic infrastructure services such as networking, file sharing, and printing isn't all that different from providing those same services to Windows client computers. In fact, Macs are becoming increasingly capable as full-fledged clients on a Windows network—so much so that I've started running a regular series of Mac interop articles on my blog.
The mission of striving for an entirely homogeneous network is fading fast, as businesses recognize that different platforms offer different strengths that can be exploited to increase productivity. The use of open and well-understood protocols in Windows makes it easy to incorporate other client platforms. And, of course, the fact that Macs use the same protocols makes it easier to integrate and support Mac systems in your Windows environment.
I hope you found this information helpful in your quest to become the IT guy who does it all, Mac or Windows!

Don Jones is the coauthor of Windows PowerShell: TFM and the author of dozens of other IT books. Reach him through his blog at www.concentratedtech.com.


Interop
Interacting with Windows from a Mac Environment
Wes Miller
At a Glance:
  • Connecting to Active Directory with Directory Utility
  • Using Entourage with Exchange
  • Communicating via Messenger and OCS
  • Bridging the platforms with virtualization

Contents
Active Directory
Exchange
Network Access Protection
OCS and Messenger
Connecting Back to Windows
Information Rights Management
A Platform in Common
Virtualization
Wrap-Up
Organizations today are likely to include both Macs and Windows PCs in their environments, and getting them to work together has become much easier. That wasn't always the case. In 1995, I started working at a small ISP and service bureau in Raleigh, North Carolina, where most employees used Macs though a few of us ran Windows. Only just before I left in 1996 did we actually achieve any nominal amount of interoperability.
For networking, Macs relied on AppleTalk while Windows used TCP/IP as its default protocol (Apple was just beginning to dabble with TCP/IP). Further, Macs had a proprietary file-sharing mechanism, while Windows was using what would come to be called the Server Message Block (SMB) protocol. The two were so incompatible that we had them isolated on separate networks, due primarily to the chattiness of AppleTalk.
Times have changed—today, not only can you bring Macs into your Windows network infrastructure, you can also integrate some of the operating system services. Don Jones's article in this issue covers networking Macs and Windows. I will focus on getting the two types of systems to actually interoperate.
Interoperability between Macs and Windows machines involves working with the software and operating system services that enable the functionality enterprises require. And it presumes a base level of hardware so that the interoperability can actually occur, with virtualization often serving as the bridge between the two platforms. The Mac's move from AppleTalk to TCP/IP was hugely important to interoperability with Windows. And as you'll see, the move to an Intel-based architecture was equally, if not more, important.

Active Directory
Yes—that's right. Look at Figure 1, and you'll see a test Active Directory domain that I have installed at my house—with my iMac as a member.
Figure 1 An Active Directory domain containing a Mac
Since OS X first shipped, ISVs have built tools that will, to some degree, integrate Macs into Active Directory (or, conversely, even allow you to push out Group Policy to a Mac client). OS X 10.5 ("Leopard"), which shipped in 2007, integrates some support directly, allowing you to join a Mac to a Windows Active Directory domain easily.
Macs, in their own environment, use Apple's LDAP directory, Open Directory. Though Open Directory and Active Directory use different schemas, the fact that Macs can join a directory at all means you can begin centrally managing them. Odds are you've invested in an Active Directory infrastructure, and without much work, you can integrate Macs into your Active Directory.
To integrate a Mac into Active Directory without third-party tools, you must have an Intel- or PowerPC-based Mac running Mac OS X 10.5 or later. Once you have booted up the system and logged on, open the Applications folder and browse to the Utilities folder. There you will find a utility named, logically enough, Directory Utility; go ahead and start it up. If your Mac has an associated Open Directory relationship already, it will be visible here. Otherwise, you will see something similar to Figure 2.
Figure 2 The Mac’s Directory Utility
Begin by unlocking the lock in the lowerleft corner and providing your administrative credentials. Then click the + sign to add a directory. When that dialog opens, select Active Directory and you will see the dialog in Figure 3.
Figure 3 Adding an Active Directory directory
The experience isn't much different from joining a Windows system to Active Directory, except that it's all on one page and doesn't seem to accept legacy-style credentials (domain\user). Credentials must be provided in the newer user@domain.tld form. Once joined, you will see the directory listed in the Directory Utility (see Figure 4). Note that if you are just joining a few computers or want to use the GUI, Directory Utility is a fast way to do it. If you want to join several computers from a script or you're more comfortable with Terminal (the Mac command shell), you can also run dsconfigad, as follows (type it all on one line):
dsconfigad –f –a computername –domain yourforest
 .yourdomain.tld –u domainaccount –p domainpassword –lu
 localadminaccount –lp localadminpassword
Figure 4 Active Directory on the Mac
Note that if you ever intend to join a Mac to both Active Directory and Open Directory, the recommendation is to always join it to Active Directory first, then Open Directory.
Now that you have joined the system to Active Directory, what can you do? The only Mac e-mail client that provides native mail and calendar access to Exchange, Microsoft Entourage, isn't quite as rich when it comes to enumerating directory attributes as Microsoft Outlook is. So in addition to providing management capabilities, the Directory Utility (also available in the /Applications/Utilities folder) allows you to see directory attributes of users, groups, and more (see Figure 5).
Figure 5 Directory Utility lets you view attributes of users and groups
As I noted, there are several applications available that will help you manage Mac systems from Active Directory, and even from Group Policy itself—practically treating Macs as Windows systems when it comes to management. Take a look at applications such as ADmitMac or Centrify DirectControl, just to name a couple.

Exchange
For years, connecting a Mac to Exchange meant requiring Mac users to use POP3/SMTP or Internet Message Access Protocol (IMAP) access to Exchange, or to simply use Outlook Web Access. All of these are, however, subpar compared to the full Exchange/Outlook experience.
Both the 2004 and 2008 versions of Microsoft Office for the Mac provide full Exchange support via Entourage (as does Mac OS X Mail, but it lacks native calendaring). Though you don't get the richness of a full Active Directory integration with the address book, what you do get is a much more robust push e-mail experience (as well as meeting requests, contacts, and calendar) than you would have using Internet-protocol access to Exchange. Entourage supports all recent versions of Microsoft Exchange.
An important note—Safari, Apple's default Web browser, only supports Outlook Web Access Light when connecting to Exchange via the Web. (Internet Explorer is the only browser that supports full Outlook Web Access functionality.)

Network Access Protection
If you are using Windows Server 2008 and are deploying network access protection (NAP), you may want to take note that Microsoft has licensed its NAP architecture to two vendors, UNet and Avenda, to build clients for the Mac (as well as for Linux).

OCS and Messenger
With its latest release (an update to the version that originally shipped with Microsoft Office 2008 for the Mac), the Messenger for Mac 7 application provides support to other MSN Messenger/Live Messenger users. Equally important in a Windows organization, it now supports access to corporate implementations of Office Communication Server (OCS). The screenshot in Figure 6 shows the Corporate area of the Messenger Accounts where you can specify the information for connecting to OCS.
Figure 6 You can specify the information for connecting Messenger to OCS

Connecting Back to Windows
For some time, Microsoft has provided a version of the Remote Desktop client for the Macintosh. Last year, Microsoft released a great new version, Remote Desktop Connection Client 2 (which was updated this year), that allows Macs to connect back to Windows—even to Windows Vista or Windows Server 2008 systems. Figure 7 shows Remote Desktop for the Mac. This version supports drive, printer, and audio redirection, but lacks other device redirection. It also adds the ability to establish multiple simultaneous connections.
Figure 7 Connecting a Mac to Windows

Information Rights Management
As I noted in my November 2008 The Desktop Files column, Microsoft doesn't support access to documents protected with Information Rights Management (IRM) from within Microsoft Office for Mac 2004 or 2008 today (see "You cannot open documents protected with IRM on Office for Macintosh"). These versions can open Office Open XML documents—the latter natively, the former natively with the latest updates and the format convertor installed. But neither is capable of opening IRM-protected documents directly, and Macs have no native way to interact with IRM-protected e-mail either.
If a Mac user needs to be able to access IRM-protected content, the most expedient way is to use one of the virtualization technologies for the Mac and to run a domain-joined instance of Windows, which allows for management and easier integration with IRM. The Windows system would be equipped with your enterprise-licensed copy of Office 2003 or Office 2007, configured to work with IRM.
The only complexity created by this solution is that you now have another Windows system to manage (in addition to the Mac). But that, of course, is one of the double-edged swords of virtualization—that Windows installations can propagate if not managed carefully. There is also the potential challenge of having to learn to work with Office on Windows, as well as on the Mac.
The only alternative besides virtualization also involves a second Windows installation and is harder on the end user. You could use a Boot Camp volume with Windows installed on it, configured as I've described above, but running in a Boot Camp volume on the Mac, directly (we'll discuss Boot Camp in more detail later). Let's briefly overview Boot Camp and virtualization on the Mac. The discussion of Boot Camp and virtualization is predicated on the use of an Intel-based Macintosh. Legacy PowerPC-based Macs can only provide emulation through software emulation products, such as Microsoft Virtual PC, rather than true virtualization.

A Platform in Common
Several years ago, Apple moved from a PowerPC-based architecture to Intel x86, allowing commodity hardware to bring the platform costs down while increasing performance. Just as important for some, Macs now had a platform in common with Windows, though Macs used the Extensible Firmware Interface (EFI) instead of BIOS. And they used the GUID Partitioning Table (GPT) partition type instead of the Master Boot Record (MBR) partition type used by 32- and 64-bit Windows.
The first systems sold by Apple were all single core and x86 only. All Mac systems sold today are x64-capable and have dual-core processors—allowing for a very satisfactory experience when using virtualization software, and even providing a great experience running Windows XP or Windows Vista with Aero, natively via Boot Camp.
By using EFI and GPT (incidentally, these were both designed largely by Intel and are used by the Intel Itanium 64-bit processor architecture), Apple avoided much of the legacy complexity of the BIOS architecture and allowed for much more flexible disk partitioning scenarios than Windows. MBR disks have numerous limitations on how many volumes can be created, what types, and size limits. GPT was designed specifically to overcome these limitations.
As a result of the move to an x86 architecture, a hacking community evolved around getting the Mac OS to run Windows XP. The complexities here are pretty significant, as 32-bit Windows supports neither EFI or GPT. Apple created a simple utility called Boot Camp that was originally available as a beta download and is now included exclusively in Mac OS X 10.5. By providing BIOS emulation and a rather creative "overlay" partition format where the disk is partitioned using matched MBR and GPT partition entries, Windows can boot from its own volume while the Mac continues on its volume.
Boot Camp is very easy to use; it repartitions the disk on the fly and helps install Windows. The only downside of Boot Camp is that in order to switch operating system environments, you must reboot the Mac into Windows, then reboot again to get back to the Mac. In short, it works—especially for technophiles like TechNet Magazine readers (but I have to say I don't like how inconvenient the actual process is).
If the user has an application that requires access to the actual hardware of the computer (such as a graphics-intensive application or a FireWire-attached peripheral), then Boot Camp may be just what is needed. But virtualization can provide much the same experience, though with some limitations. The largest problem with Boot Camp is probably the fact that in their native configurations, Windows can't access Mac HFS+ formatted volumes, and Macs can't write (though they can read) NTFS-formatted volumes.
I'd like to take a minute to describe two free utilities and one commercial product that make Boot Camp even easier to use. The free rEFIt utility allows you to take a Mac and create more flexible boot configurations than the BootCamp single-volume scenario allows for (only one instance of Windows can be installed via Boot Camp). Using rEFIt, I have a Macintosh that will triple boot between Mac OS X (installed first), Windows XP (installed using Boot Camp), and Windows Vista Ultimate (installed using rEFIt). You should use rEFIt carefully (read the documentation)—it is a very powerful tool that can potentially harm your system if not used properly.
Also free, the NTFS-3G utility allows Mac OS X not only to read but also write to NTFS-formatted volumes. Finally, MacDrive 7 ($49.95/system) is, to my knowledge, the only way to give a Boot Camp-booted Windows volume the ability to read and write to a Mac OS X HFS+ formatted volume.

Virtualization
Though Connectix, the company that sold its emulation and virtualization tools to Microsoft, made a Virtual PC product for the Mac, this product was really an emulation, not a virtualization, product. Essentially, it emulated an x86 instruction set on top of PowerPC-based computers. The result was functional, but not exactly speedy enough for everyday use. Today, Microsoft's Virtual PC product will work only on legacy PowerPC-based Macs. But since Apple's much-talked-about move to the x86 architecture, at least three distinct virtualization products have been made available for the Mac. Some even offer GPU emulation, allowing more graphically intensive applications (or better yet, games) to run on the Mac—and do so with performance at or near running on physical hardware.
The predominant Mac virtualization products are VMware Fusion and Parallels Desktop for Mac. Both products allow you to boot the same Boot Camp partitions virtually as well as via Boot Camp (giving you the best of both worlds) and enable a "transparent" mode where applications running in a Windows virtual machine actually look as if they are running on the Mac directly. They also support drag and drop to and from the Mac and Windows virtual machine.
Note that virtualizing an IRM client does potentially circumvent the IRM protection—it's relatively easy to perform a screen capture of a Windows VM running on a Mac. But, as I noted in my November 2008 The Desktop Files column, IRM works well only until you hit "the analog hole," which is easier for a nefarious user to do from a virtualized machine—something to be aware of.
Sure, it would be ideal if you could provide Mac (or any other platform) users the same experience as Windows users with the same ease of use. But some tools (such as IRM, SQL Server applications, or Microsoft .NET applications) cannot run natively and must be used from a Windows installation that is either running virtualized or under Boot Camp (or both). And any applications that require a high-end GPU or DirectX 10 must be run via a Windows installation running via Boot Camp. Virtualization provides a great bridge for applications that are Windows-only when you have users who need to use Macs.

Wrap-Up
With the move to an Intel x86-based architecture, numerous applications available natively, and strong virtualization/native-booting solutions available today, Mac/Windows platform interoperability is easier than it has ever been before. For the Mac users in your organization, the need to be isolated on a separate network, with no easy way to share files with Windows machines, is a thing of the past.

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.


Interop
Managing the Root Password on Your Mac
Chris Stoneff
At a Glance:
  • Elevating privileges on the Mac
  • Enabling the root account
  • Making the sudo command available to users Item

The basic situation on a Macintosh running OS X is not unlike Windows Vista with User Account Control (UAC) still enabled: you are stripped of your admin rights, the root or admin account is disabled, and you are prompted to elevate your rights when you do something that requires admin privileges. In Windows Vista, you probably know how to manage and use your admin account when you need it. But if you're new to the Mac, it may be not be immediately obvious.
On a Mac, in order to perform administrative functions (especially in Terminal), you need to be able to issue the sudo command, which requires authenticating. That's easy—the way Macs are configured out of the box, all you need to do is reenter your own password to provide the necessary authentication.
Too easy, some would say, because just as with Windows, it means that if your password is guessed or stolen or cracked and it provides access to your system locally or via SSH, the attacker can take over your box exactly as if you had root enabled it (root is equivalent to administrator in Windows). Even worse, if attackers initiate a shell using "sudo –s", virtually nothing will be entered into your system log.
So how do you give your Mac users the rights they need on an as-needed basis and improve security at the same time? Oddly enough, by enabling the root account.
By default, OS X has the root account disabled, which follows generic safety measures. The problem is that in this state, as noted above, a user need only retype his own credentials to obtain elevated privileges. To ensure that users cannot simply reenter their own credentials to obtain root-level (administrator) access, you need to enable the root account by giving the account "root" a password. To do this, use your Directory Utility or, from a Terminal, issue the following command:
sudo passwd root
Then follow the prompts to enter a new password (see Figure 1). Don't forget to change the password regularly.
Figure 1 Creating a password for root
With the root account enabled, users can no longer simply reenter their own password to obtain root-level (administrator) privileges. This allows more granularity in setting privileges because now a separate elevated account must be called in order to perform administrative functions. This account can be managed and secured independently of the normal user account by using third-party solutions to randomize and securely store the account password and provide a delegated and audited interface to obtain the password as needed.
Now that that's taken care of, you need to make sure the sudo command is available to those who need it. Keep in mind the three levels of users in OS X: users, admins, and root. By default, users can't issue sudo commands; only admins and root users can. If you don't want your users to have admin permissions, but you do want them to be able to issue sudo commands when necessary, you will need to enable sudo for the users on your OS X system. You can do this either by editing the /private/etc/sudoers file to include specific users or by uncommenting the example line in Figure 2 that starts with '%wheel' and then adding your users to the wheel group.
Figure 2 Enabling sudo for specified users
By following the items outlined here, you can allow the root password of your Mac systems to be managed by automated processes that would randomly generate a new password on a regular basis or following password recovery. Thus your systems can remain compliant with your company's policies as well as governance put forth by the Payment Card Industry (PCI) Data Security Standard, Sarbanes-Oxley (SOX), the Health Insurance Portability and Accountability Act (HIPAA), and others. You will also stop users and admins from being able to unthinkingly elevate their privileges by simply retyping their own password.

Chris Stoneff is a Product Manager at Lieberman Software, a security and systems management software developer. His biggest drive is not just to know how something works a certain way, but why.


Active Directory
Understanding Proxy Authentication in AD LDS
Ken St. Cyr
At a Glance:
  • Defining proxy authentication
  • Why proxy authentication is useful
  • Inside the proxy object
  • What happens during authenticationItem

Contents
What Is Proxy Authentication?
Benefits of Proxy Authentication
Inside the Proxy Object
How the Authentication Is Actually Performed
Setting up a Proxy Authentication Lab
Conclusion
As with any LDAP-enabled directory service, Microsoft Active Directory Lightweight Directory Services (AD LDS—formerly called ADAM) requires a user to bind before executing any LDAP operations against the directory. This bind can be done through a few different methods, including a simple LDAP bind, a Simple Authentication and Security Layer (SASL) bind, or even bind redirection. The bind could also be anonymous, in which case the user presents a null password. In this article, I am going to discuss and analyze one method specifically—bind redirection, otherwise known as proxy authentication.

What Is Proxy Authentication?
Proxy authentication allows a user to perform a simple bind to an AD LDS instance, while still maintaining an association to an Active Directory account. Two accounts are involved in the transaction. The first is a special object in AD LDS called a userProxy object. The second is the user's account in Active Directory.
The AD LDS userProxy object is a representation of the Active Directory account. The proxy object is tied to the Active Directory account through that account's security identifier (SID). There is no password stored on the actual proxy object itself.
When a user performs a simple bind to an LDS instance with a proxy object, the bind is redirected to Active Directory by passing the SID and password to a domain controller. The AD LDS server performs the authentication, and the entire process is invisible to the end user. This is illustrated in Figure 1, where Lucy is connecting to an AD LDS instance called "CN=AppDir,DC=contoso,DC=com" with her AD LDS user account.
Figure 1 Connecting with AD LDS
For the authentication, Lucy is using a simple bind, and she supplies her distinguished name (DN) and password as she would during a normal LDAP bind. Although Lucy seemingly connects with her typical LDS user account, she is actually using a proxy object. The authentication to Active Directory is happening behind the scenes, and Lucy has no clue that she's actually using her Active Directory account to bind.

Benefits of Proxy Authentication
The power of proxy authentication lies in giving application developers access to a user object without giving them access to the Active Directory account. Consider what happens when a new directory-enabled application is being built and the application needs to store some data in Active Directory. The application can either use an existing attribute or create a new one.
The danger in using an existing unused attribute is that the attribute is likely there for another purpose. Even if it's unused now, it could be used in the future; if it's used for some different purpose, the Active Directory administrators would have to keep track of how it's being used. And what if the app developer needs more than one attribute?
With proxy authentication, a representation of the Active Directory user object exists in the AD LDS directory. An application-specific directory allows the application developer to modify the schema any way he'd like in the context of AD LDS. Attributes can be added, changed, or repurposed in any manner the developer chooses, and the Active Directory administrator doesn't have to worry about making multiple schema changes or keeping track of how attributes are used. If another application comes online and wants to use the same attribute, it's not a problem because it can be a separate AD LDS instance and won't have any attribute conflicts.
Proxy authentication can also be useful in situations that require the X.500 format. Active Directory does not use typical X.500 nomenclature for DNs. For example, a user object in Active Directory has the DN "CN=Lucy D. Smith,CN=Users,DC=contoso,DC=com". However, in AD LDS, the user's DN could be "CN=Lucy D. Smith,CN=Users,O=Contoso,C=US", which is compatible with X.500.
This is helpful when you're using a third-party LDAP client or trying to integrate with a third party directory that requires the X.500 format. In this way, LDS can be an intermediary directory between a third-party directory and Active Directory. Using proxy authentication, the service account that the third-party directory needs to use to bind to the LDS instance can be held in Active Directory instead of LDS itself.

Inside the Proxy Object
So far I've given a brief overview of how the LDS proxy object is tied to the Active Directory user account. I'll now look at this in more detail and examine what's actually happening behind the scenes, starting with the object class.
In Windows Server 2008, the %SYSTEMROOT%\ADAM directory contains two LDF files that represent a proxy object:
  • MS-UserProxy.LDF
  • MS-UserProxyFull.LDF
MS-UserProxy.LDF holds the definition for the simple userProxy class, which has basic attributes and contains the msDS-BindProxy auxiliary class. MS-UserProxyFull.LDF contains the msDS-BindProxy auxiliary class as well, but it also pre-populates additional user attributes into the mayContain attribute of the class. Because of this, the attribute classes have to exist beforehand. So when importing the userProxyFull class, either the user or inetOrgPerson class needs to be imported first. Both user and inetOrgPerson contain the attribute class definitions for the attributes that userProxyFull uses. Figure 2 shows the differences between the userProxy class and the userProxyFull class.
Figure 2 The userProxy and userProxyFull classes
The fact that both classes contain msDS-BindProxy as an auxiliary class is significant. An auxiliary class is a type of class that can provide additional data to a structural class. In LDS, for example, the User class is a structural class that is inherited from the Organizational-Person class, which means that the User class has everything that the Organizational-Person class has. But the User class also has an auxiliary class called msDS-BindableObject, which means User contains all of the mandatory and optional attributes of msDS-BindableObject in addition to the attributes from the Organizational-Person class. In this instance, using msDS-BindableObject as an auxiliary class makes the User class bindable.
Since the userProxy class has msDS-BindProxy as an auxiliary class (see Figure 3), it now also contains the entire mandatory and optional attribute set of msDS-BindProxy. The msDS-BindProxy auxiliary class is what turns an object into a proxy object. So even if you have a custom class, you can add the msDS-BindProxy auxiliary class and use your custom objects for proxy authentication.
Figure 3 Creating a proxy object
If you were to examine the msDS-BindProxy class, you would notice that there is only one mandatory attribute defined—objectSID. This is the attribute that the SID of the Active Directory user account will be placed in to create the association between the proxy object in LDS and the user object in Active Directory. This attribute can only be populated when the object is created. It cannot be changed without deleting the object and recreating it.

How the Authentication Is Actually Performed
To truly understand what's happening behind the scenes, we'll need to go a little bit deeper into how the authentication is performed. I'll walk through two network traces that will help show how proxy authentication works. The first trace is a network capture of a proxy user's simple bind from a Windows XP workstation to a Windows Server 2008 LDS instance. In this capture, Lucy binds with her proxy user object using LDP.EXE from her workstation.
Figure 4 shows the three packets in the capture that we need to examine. Packet 1 is the bind request from the workstation (10.0.0.107) to the Active Directory LDS server (10.0.0.201). The bind request contains Lucy's DN, "cn=lucy,cn=people,cn=appdir,dc=contoso,dc=com". Packet 2 is the response from the Active Directory LDS server to the workstation, indicating a successful bind. And packet 3 is the acknowledgment from the workstation to the Active Directory LDS server, indicating the acknowledgment of the bind response.
Figure 4 Bind request and response
If you dig into the details of packet 1 (see Figure 5), you'll notice something shocking. The password that Lucy supplied (P@ssw0rd) is displayed in clear text in the capture. This is, in fact, one of the downfalls of using a simple LDAP bind for authentication. Unless the bind is wrapped in SSL encryption, the user's password will be advertised to anyone listening on the network.
Figure 5 Simple bind with SSL turned off
Active Directory LDS does enable SSL by default, however. You have to go out of your way to turn it off, which is exactly what I did for this exercise in order to make the network trace readable. And I didn't bother to assign a certificate to the Active Directory LDS server, but in an actual implementation, you absolutely want to ensure that the Active Directory LDS server has a valid certificate that can be used for SSL.
The second trace is a network capture from the Active Directory LDS server to the domain controller (DC). This trace is a bit larger than the first one, so I'll break it up into chunks. The first 9 packets of this trace are shown in Figure 6.
Figure 6 AD LDS connecting to the domain controller
The first packet should look familiar to you. This is in the incoming bind request from the workstation. Again, this packet contains Lucy's DN and password in clear text. Packets 2 through 9 show the AD LDS server (10.0.0.201) connecting to the domain controller (10.0.0.200). This consists of some address resolution protocol (ARP) messages followed by a remote procedure call (RPC) connection to the DC.
In Figure 7, packets 10 and 11 call a method named LsarLookupSids3, an RPC call that tells the DC to take a batch of SIDs and return their corresponding names. The AD LDS server makes the request in packet 10 and receives the response from the DC in packet 11.
Figure 7 Kerberos authentication attempt
Then, after a brief TCP handshake to start the Kerberos session (packets 12–14), in packet 15 the AD LDS server attempts to get the authentication service ticket (AS-REQ) from the Key Distribution Center (KDC). In packet 16, the authentication service ticket request is denied because the DC is expecting some pre-authentication data that the AD LDS server didn't provide. In this case, the DC wants the timestamp so it can be used for identity verification. The Kerberos session ends and a reset is requested (packets 17–19).
Figure 8 shows the rest of the capture. Packets 20–22 establish a new Kerberos session and a new authentication service request is sent from the AD LDS server to the DC in packet 23. This new request contains the necessary pre-authentication data, indicated by the successful reply from the DC in packet 25. The AD LDS server now has the authentication service ticket and can place a request to the ticket granting service to authenticate Lucy's credentials.
Figure 8 Successful authentication
The ticket granting service request and response are captured in packets 33 and 34. The receipt of the KRB_TGS_REP in packet 34 indicates that Lucy is successfully authenticated. Finally, in packet 38 the AD LDS server passes the bind response back to the workstation, letting Lucy know that she has successfully bound to the AD LDS instance. Although this process involves several steps, the total time for this entire transaction is only about 1/10th of a second.
What would happen if Lucy entered the wrong password? In our example, the authentication service request would fail at packet 25. The failure of the authentication service request would tell the AD LDS server that Lucy's credentials were bad. Instead of issuing a request to the ticket granting service, the AD LDS server would issue a bind response back to the workstation, stating that the credentials were invalid.
Here is a recap of what happened in the successful exchange:
  1. The workstation sends a bind request to the AD LDS server.
  2. The AD LDS server establishes a connection with the DC.
  3. The AD LDS server asks the DC to translate Lucy's SID into an identifier that it can use for authentication.
  4. The DC gives the AD LDS server Lucy's ID.
  5. The AD LDS server gets a ticket granting ticket (TGT) from the DC with Lucy's ID.
  6. The AD LDS server gets a session ticket to itself using Lucy's TGT.
  7. The AD LDS server sends a successful bind response back to the workstation.
This process shows that the connection from the workstation to the AD LDS server is a standard LDAP bind transaction. Then from the AD LDS server to the DC, Kerberos is used to securely authenticate the user.

Setting up a Proxy Authentication Lab
Now that you know how proxy authentication works, let's see how you can set this up in a lab environment. Note that for this exercise, I'll be disabling the requirement for SSL in proxy authentication. As I mentioned earlier, however, please remember that you should not disable this requirement in a real-life implementation.
Before you start, you will need a fully functional domain with a Windows Server 2008 member server and a workstation joined to it. The Windows Server 2008 member server will run AD LDS, and the workstation will be the client endpoint. The advantage in separating these computers is that you can take network captures of the interaction between them. To set up the lab, I'll walk you through the following steps:
  • Install AD LDS on the member server.
  • Disable the SSL requirement for proxy authentication.
  • Import the userProxy class into the AD LDS schema.
  • Create the proxy object and assign permissions to it.
  • Bind to the AD LDS directory with the proxy object.
The first step is to install AD LDS on the Windows Server 2008 member server. In the Server Manager, you will find the option to install LDS in the "Add Roles" wizard. After the role is installed, a new option will appear in the Administrative Tools menu called Active Directory Lightweight Directory Services Setup Wizard. Use this wizard to create a new LDS instance.
When prompted for the name of the application partition, enter any DN you'd like. Remember that LDS supports X.500 naming, so you're not limited to using a "DC=" style name. In my examples, I used "cn=appdir,dc=contoso,dc=com", but I could have also used "cn=appdir,o=contoso,c=us".
After the AD LDS instance is installed, the next step is to disable the SSL requirement for proxy authentication. In the ADSI Edit snap-in (adsiedit.msc), you should connect to the configuration partition of the AD LDS instance using the administrator account you specified during the install. If you don't know the DN of the configuration partition, you can choose "Configuration" from the "Select a well known naming context" dropdown list in the connection settings dialog in ADSI Edit.
Browse to the container "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={guid}" and bring up the properties dialog of the "CN=Directory Service" container. There is a multi-value string attribute in the attribute list called msDS-Other-Settings that lists multiple strings, each indicating a different setting for the AD LDS instance. Edit this attribute and change the string "RequireSecureProxyBind" to a value of 0.
The next step is to import the schema class definition for the userProxy class. You may have already imported it when prompted to do so in the AD LDS wizard. If so, you can skip this step. If you did not already import it, do so with the following LDIFDE.EXE command. Ensure that you specify the name of the AD LDS server and the correct port in the command:
C:\> ldifde –i -f c:\windows\adam\ms-userproxy.ldf –s
   server:port –k –j . –c
   "cn=schema,cn=configuration,dc=X"
   #schemaNamingContext
Now that the object class has been imported, the proxy object can be created. I'll use LDP.EXE, but you could use another tool or some programmatic method. Using LDP, connect to your AD LDS instance and bind with your administrator credentials. Browse to the DN of your AD LDS instance and then choose the container in which you want to create the proxy object. Right-click on the container and choose Add Child from the dropdown list. In the Add dialog, you will need to enter the DN of the new proxy object in the DN field. For example, you can use "cn=lucy,cn=appdir,o=contoso,c=us".
You'll also need to create two attributes with this object. The first is objectClass, which indicates the kind of object being created. The value for this example should be userProxy. Put this information in the Edit Entry section of the dialog and click the Enter button.
The second attribute to add is objectSID, which contains the SID of the Active Directory user account with which this proxy object is associated. You can obtain this SID with a variety of methods, but I just connected to Active Directory in a separate LDP instance and copied the objectSID attribute from the user account there. After entering this information, the Add dialog should be similar to Figure 9. Finally, click the Run button to commit the change.
Figure 9 Creating a proxy object
In order to use the proxy object you just created, you'll need to give it some permissions. You can accomplish this easily by selecting the "CN=Readers" object under the "CN=Roles" container in LDP. Right-click and choose Modify from the dropdown list. Add an attribute called member and for the value, enter the DN of the userProxy object you created. Remember to click the Enter button before clicking Run. Now the userProxy object should be a member of the Readers group in the LDS instance.
Everything should be set up, so you can now test the proxy authentication. Open a new instance of LDP and connect to the AD LDS server. This time, however, when you bind to your instance, select Simple Bind and type in the DN of the proxy object in the user name field. For the password, enter the password of the Active Directory account you tied this proxy object to. Click OK and you should now be bound to the instance in read-only mode.
Spend some time taking network traces and trying out different bind methods. One exercise might be to turn SSL back on and take a capture of the LDAP bind process then. You could even purposely mistype a user name or password and see what happens to the authentication process.

Conclusion
Don't be alarmed over the difficulty of using proxy authentication. I took the approach of demonstrating this process with LDP and ADSI Edit because it gives you a better look behind the scenes. Because of that, the example I walked you through here illustrates proxy authentication from a very hands-on perspective.
In practice, the lengthy process of creating userProxy objects and manipulating them is usually codified through an identity management system or a custom-developed front end for creating accounts. I encourage you to build your own LDS lab and see for yourself how you can use proxy authentication for integrating your third-party directories and applications.

Ken St. Cyr is a consultant for Microsoft and has designed and implemented directory solutions based on Active Directory since its inception. He recently became one of the first to achieve the Microsoft Certified Master certification for Directory Services. Contact him at ken.stcyr@microsoft.com.


From the Editor Can’t We All Just Get Along?
Joshua Hoffman

Mahatma Gandhi once said, "Honest differences are often a healthy sign of progress." Truer words were never spoken. And if you've taken a look at the cover of this month's issue of TechNet Magazine, or perhaps read through the Table of Contents, you probably have a pretty good idea of why those words of wisdom are foremost in my mind right now.
It may surprise you to see words such as "Linux" or "Mac." These certainly aren't topics discussed in our pages very often. Yet, while we hold fast to our belief that Microsoft products and technologies offer many of the most compelling IT solutions available (and we also admit to our bias in that opinion), we are, if nothing else, realists. We know that any number of circumstances—business requirements, organizational issues, or even just plain personal preferences—often lead to situations where an IT professional is responsible for managing a heterogeneous environment.
Loyalty is OK. Preference is OK. You like Windows? Cool! You prefer a Mac? That's your choice. But the fact is, you've got a job to do, and restricting yourself to being just the "PC Guy" or just the "Mac Guy" hinders your chances of getting ahead. Our job is to help you do your job, so set aside partisanship this month and instead focus on what it takes to get things done in the real world. (Don't you wish it were that easy in politics?)
We begin with a seminal article from our own Gil Kirkpatrick. You may have seen Gil's work grace our pages in the past—always with truly expert content about Active Directory. Well, Gil has outdone himself this time with a definitive guide to integrating Linux clients into your Active Directory environment. It's a must read.
You'll also see two of our contributing editors—Don Jones and Wes Miller—tackle interop topics this month. Don and Wes are both experts in the Windows platform, but they also secretly harbor a bit of a "thing" for Macs. So in this issue, they'll walk you through what it takes to make your Macs and your PCs get along: connecting Macs to Windows file shares and shared printers, integrating Macs into Active Directory, configuring network settings on a Mac, and much more.
Needless to say, we feel like we've gone out on a bit of a limb with this issue, so we're anxious to hear your feedback! Drop us a line at tnmag@microsoft.com and let us know what you think.
—Joshua Hoffman

Thanks to the following Microsoft technical experts: Eric Charran, Eric Huebner, Don Jones, Jingmei Li, Michael Murgolo, JJ Streicher-Bremer, and Jim Truher.


Letters Readers Speak Out

The Windows Linker
In response to Raymond Chen's September 2008 Windows Confidential column, "Windows 95 Unplugged", I'd have to say that I think the story of the Windows linker is not quite complete. The original Windows linker came from Convergent Technologies. If you have a copy of it and dump it to the screen, you will see the letters GW; these are the initials of Greg Walsh, the programmer who wrote the linker. The difference in the code was the signature and the checksum.
—Ken W.

VMM and VMware Virtual Center
As a VMware administrator, I was happy to read the October 2008 article "Manage Your Virtual Environments with VMM 2008". It's really great that Virtual Machine Manager (VMM) supports managing VMware systems, but something wasn't clear from the article. Is VMM a replacement for VMware Virtual Center? Do I still need to buy VMware feature licenses, such as VMotion support, from VMware, or will VMM enable VMotion for me without VMware software?
—George H.
For VMware environments, VMM is a complement to the Virtual Center infrastructure and can replace the Virtual Center console. But VMM requires a Virtual Center server to manage the VMware hosts. While VMM does communicate with the hosts directly for some functions, most functions, including VMotion, require a Virtual Center server. Also, VMM doesn't enable any VMware-specific functions that are not enabled in Virtual Center, such as Distributed Resource Scheduler (DRS) or VMotion. Your Virtual Center must be licensed for VMotion for VMM to enable it.
—Edwin Yuen, Technical Product Manager, Windows Enterprise Management, Division for System Center VMM

Dual and Quad Cores
In the September 2008 Exchange Queue & A column, HenrikWalther discussed processor cores. I followed this up by reading the article "Planning Processor Configurations," which discussed only dual-core processors.
My concern is whether quad-core processors would change any of the information from your column. Was the decrease in mailbox server performance you mentioned due to the number of processor sockets in a server (for example, 4 sockets × dual core = 8 processor cores)? Does quad-core technology change this at all? Does having a single-socket quad core give you the same performance as a 2-socket dual-core configuration in Exchange 2007?
—Scott M.
Quad-core processors also work very well with Exchange Server 2007. Normally, when I spec Exchange 2007 Mailbox servers, I always try to get 2 × quad core and these always deliver very good performance. But you could also use 4 dual-core processors. You would rarely notice any difference.
The potential decrease in performance comes when you use more than 8 cores in total (not processors), such as using 3 quad-core processors or 5 dual-core processors.
—Henrik Walther, Columnist, Exchange Queue & A

Admin Passwords
I read your article "Understanding Shared Account Password Management" in the September 2008 issue. We always disable the admin account. Why do we need to manage its password?
—Karen H.
In Windows, just because the administrator account is disabled doesn't mean it can't be used. Take a look at the article "How to Access the Computer after You Disable the Administrator Account", which does a good job of explaining things. The referenced article specifically notes Windows Server 2003, but the information applies to the other Windows operating systems as well.
Further, just because the account is disabled doesn't mean it can't be re-enabled at any other time, even without access to safe mode—this can be done by anyone with sufficient rights to manage accounts on your system. Even if you use Group Policy Objects (GPOs) to disable the account, the account can be re-enabled. Moreover, using Group Policy = (with default settings) can take up to 120 minutes to refresh on the client.
—Chris Stoneff

Got something to say? E-mail us at tnmag@microsoft.com, or visit our blog forum at blogs.technet.com/tnmag.


Toolbox New Products for IT Pros
Greg Steen

The opinions expressed in this column are solely those of the author and do not necessarily reflect the opinions of Microsoft. All prices were confirmed October 2, 2008, and are subject to change.

Manage Partitions
GParted Live
gparted.sourceforge.net/livecd.php
The typical computer user probably has no need or desire to muck around with the partitions of his system. But if you are in the IT business or you are a serious computer user, or both, it has probably been necessary for you at one time or another to shuffle the partitions on your system drives.
If the latter description is true of you, then you will be happy to learn that there is a great free tool out there that can help you manage your partitions—GParted. GParted, also known as Gnome Partition Manager, is a community-supported and open-source project. It is an industrial-strength package for creating, destroying, resizing, checking, and copying partitions and the file systems on them.
A side venture of the project and the focus of this review is GParted Live, which is basically the GParted application bundled onto a small bootable live CD version of Debian GNU/Linux. It enables you to use all of the features of the latest versions of GParted.
To get started, you simply download the .iso file from the project Web site and burn it to a CD. Once that has been completed, you reboot your system to the CD and GParted Live kicks into action, starting a small Linux instance in memory. The tool then automatically detects your subsystems and launches XWindows, presenting a graphical UI for GParted.
The desktop includes big buttons for launching a shell (command prompt), changing your screen resolution, mounting a USB drive, taking a screenshot, and rebooting the system. Once you're up and running, you can easily create, move, resize, mark as bootable, and delete partitions on your drives. You can also do the same for file systems of pretty much any type you need on those partitions. In addition to marking a partition bootable, you can also set flags, such as hidden, LVM, and RAID.
The project Web site offers instructions and downloads for a bootable USB version of GParted. You can link to numerous walk-throughs that can guide you through the issues you may encounter when resizing Windows Vista system partitions. If you're looking for a robust and easy-to-use partition management solution, consider adding GParted Live to your toolbox.

Price: Free.
Manage system partitions with GParted Live

Check Site Links
Xenu Link Sleuth
home.snafu.de/tilman/xenulink.html
Whether you run a giant content-driven Web site, you are responsible for your company's intranet, or you just have a personal blog, it's a good idea to verify that the links within the content and on the site remain valid over time. One tool that will help you identify rogue and dead links is the free Link Sleuth from Xenu.
Link Sleuth has a simple design and is easy to use. You simply point the tool to the URL (or set of URLs) that you wish to use as your starting point and click OK in order to start crawling your site. Even SSL links are fair game.
The utility then kicks off a number of parallel threads to request the pages referred to from your starting point. As the spidering progresses, feedback includes a collection of color-coded links in which green means good and red means bad.
In addition to the link on the site, the UI also shows you a specific status code for the request's response, the content type of the response (such as text/xml or text/html), the size of the page request in bytes, the page title, the number of links into and out of that requested page, the type of Web server, the type of error if one is encountered upon request, and the time it took to get a complete response from the request. The error messages returned contain more than the response code; they include helpful messages.
In terms of options, you can choose whether to follow external links encountered to help you verify that any external content you're linking to is valid. You can also choose what types of links you want to report, such as redirects, broken links, FTP URLs, text URLs, and orphaned files.
As a default, Link Sleuth kicks off 30 threads in parallel when it crawls your site, but you can adjust the number to be between 1 and 100, depending on your environment. Once finished, the application can generate an HTML report of the links it found, as well as a site map and a bunch of useful aggregate data reports about what it encountered. From the UI, you can also choose to retry any broken links or export the results to a tab-delimited file. All in all, Link Sleuth is a useful, free, and simple link checker.
Price: Free.
Validate site links with Link Sleuth

Manage Your Environment
Desktop Authority
scriptlogic.com/products/desktopauthority
Centralized control over desktops throughout your organization can be a real time saver. This can help you enforce company policy and security procedures as well as mitigate threats by ensuring machines are up to date with antivirus, anti-spyware, and the latest applicable patches. But most important, you can do all this without having to walk around to individual machines.
One application that can help you manage your environment is Desktop Authority from ScriptLogic. Desktop Authority lets you manage your Windows clients (Windows 95 through Windows Vista) from a centralized graphical user interface (though some of the features are only supported for Windows 2000 and later). With this tool, you can ensure that corporate standards and regulatory compliance are enforced across the machines within your environment.
One of the features that make this solution stand out from some of its competitors is the granularity to which you can perform management tasks, allowing you to adapt the configurations to meet the needs of a diverse set of end users. You can turn on and modify the exceptions for Windows Firewall on your client machines, for example. You can also add printers, map network drives, set environment variables, and specify file permissions. Other profile options allow you to manage Outlook profiles, Microsoft Office preferences, and Internet Explorer defaults.
It is also easy to ensure power schemes and inactivity timeouts, modify registry settings, display legal notices, and apply Group Policy templates across your domain. You can add any custom pre- or post-logon script you may need. You can even coordinate application installations and updates through remote Microsoft Installer deployment on a scheduled basis.
All user profile, customization, and hardware and software inventory information is stored in a centralized SQL Server database (a requirement for installation). This allows for easy recovery and auditing.
Desktop Authority includes a reporting tool that is useful when you need to audit the machines in your environment. It offers a number of pre-configured reports that cover hardware and software inventories; patch and OS status; and profile details, such as Outlook settings, power schemes, and Windows Firewall settings.
Most of the reports can be tweaked, but if you have a very particular requirement, you can use the Report Wizard to generate the exact data you need. Report layouts, graphics, and details are all customizable, and reports can be generated as PDFs, Excel spreadsheets, RTFs, text, TIFFs, and HTML. And, for convenience, you can schedule and e-mail the reports to keep automated tabs on your environment.
ScriptLogic offers optional add-on components that let you achieve even greater control over your workstations. The USB and Port Security option allows you to lock down things such as USB ports, Bluetooth devices, PCMCIA controllers, and WiFi devices. The Patch Management option can automatically download and distribute patches for the operating system and other applications based on the schedule, validation, and patch class logic you choose to apply. And a Spyware Detection and Removal option consolidates scanning, removal, and reporting of malware in your environment.
Price: Starts at $39 per seat.
Manage your environment with Desktop Authority

Book Review
Cheat at Administering Office Communications Server 2007
elsevierdirect.com
Microsoft Office Communications Server (OCS) 2007 is an expansion from Live Communications Server (LCS) 2005, and it represents a huge leap forward from the previous LCS 2003. This server application set delivers integrated management of real-time communication in your organization, covering Voice over IP (VoIP), voicemail, IM, and Web conferencing. It even supports integration with PBX systems.
OCS 2007 clearly offers a lot of new features and capabilities. Fortunately, How to Cheat at Administering Microsoft Office Communications Server 2007 (Syngress, 2007) can help you get up to speed quickly, whether you are planning a new deployment, managing an existing deployment, or simply curious about what OCS 2007 can do.
If you are familiar with other books in the How to Cheat at … series, you will notice that this book sticks to the familiar format. It starts out with a chapter on what people mean by unified communications, offering a short history of software communication, the advent of IP communications (and the technological hurdles therein), and an explanation of the Microsoft strategy for unification.
The book then gives an overview of some of the new and improved features you'll find in OCS 2007, such as "enhanced presence" capabilities (this, in case you're wondering, has to do with how OCS 2007 provides the availability, connectivity, and location of a user you are trying to connect with), group IM, Web conferencing, archiving, and improved federation. There is also an overview of the different server role components: the front-end server, edge server, mediation server, archiving server, and communicator Web access.
After the introductory chapters, the book guides you through the installation of a front-end server. This server handles basic presence functionality; authentication; filtering of SPIM (the IM equivalent of SPAM); and routing of VoIP calls, IM, and conferencing traffic.
The book then covers the new Microsoft Office Communicator 2007, which is basically the end user's front end to OCS. This tool allows the user to control presence, contacts, history, alerts, and audio/visual features for voice calling and video conferencing. The book explains these capabilities as well as covers the basics of how to customize Office Communicator by tailoring menus and features for your environment.
The next few sections explain how to set up a consolidated edge server (the services that connect your OCS environment to the outside world) with all three edge services on the same machine—Access Edge, A/V Edge, and Web Conferencing Edge. Moving on to the Mediation server component of an OCS deployment, the book demonstrates the installation and configuration options for handling PBX and Public Switched Telephone Network (PSTN) legacy system integration.
Archiving and standards compliance is now a legal necessity that touches many parts of your infrastructure and communications. The following chapter focuses on this, detailing how OCS 2007 addresses those issues through the archival and call detail record (CDR) server role. Here the book also touches on the specifics of compliance for the Health Insurance Portability and Accountability Act (HIPAA), the SEC, and Sarbanes-Oxley as it relates to IM history, meetings, and call history.
Next, you find out how to configure conferencing services in an OCS deployment, and you learn how to configure and use Office Communicator for videoconferencing. The book also explains how Office Communicator integrates with Outlook and details the differences between on-premises and hosted live meeting conferencing. Here, too, you can find out how to use the Live Meeting client to share applications, desktops, and whiteboards, as well as how to conduct real-time polls and Q&A sessions as the conference progresses.
Following conferencing, the book goes on to cover other forms of integration, such as joining PBX and IP-PBX systems to your deployment through the use of two voice solutions: the Enterprise Voice option (which uses computer microphones and speakers or headsets) and a gateway device to connect to your traditional PBX system and Remote Call Control, or RCC, (in which the office communications client sends the digits of your call to a PBX phone that then handles the call).
The book provides useful information on how to get OCS 2007 to work with the Unified Messaging features offered by Exchange 2007. This covers the basics of configuring and integrating the two systems so users, for instance, can create and access voicemails from the Communicator client and receive missed-call notifications in Outlook and Communicator. If you already have an LCS 2005 infrastructure in place, you will find great benefit from the chapter that covers upgrades, options, and strategies for migrating.
The book ends with a section discussing OCS 2007 management. It explains using logs, usage records, the route helper, and the snooper tool to tune and monitor your own deployment.

Price: $49.95.

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.


SQL Q&A Row-Overflow, Differential Backups, and More
Paul S. Randal

Q I recently upgraded an application to run on SQL Server 2005. One of the things I've taken advantage of is the ability to have rows greater than 8,060 bytes so I can allow users to create longer data fields without getting an error from SQL Server. Now that this application is in production, we're having performance issues for some scan queries that used to run fine before the schema change. I've checked the fragmentation of the various indexes and everything is OK. Why are the queries running slowly on SQL Server 2005?
A The feature you are using, row-overflow, is great for allowing the occasional row to be longer than 8,060 bytes, but it is not well suited for the majority of rows being oversized and can lead to a drop in query performance, as you are experiencing.
The reason for this is that when a row is about to become oversized, one of the variable-length columns in the row is pushed "off-row." This means the column is taken from the row on the data or index page and moved to a text page. In place of the old column value, a pointer is substituted that points to the new location of the column value in the data file.
This is exactly the same mechanism used to store regular LOB (Large Object) columns, such as XML, text, image, or varchar(max). Note that if the table schema contains multiple variable-length columns, there is no guarantee that the same column will be pushed off-row when multiple rows become oversized.
This mechanism can create a performance problem. Suddenly a query to retrieve a variable-length column from a single row in a table might need an additional I/O if the column has been pushed off-row (to read in the text page containing the off-row location of the value). If multiple rows are oversized, a query to retrieve the same variable-length column from multiple rows could have unpredictable performance, depending on how many of the values have been pushed off-row.
In your case, a query performing a range scan or table scan for a select list that includes a variable-length column is suffering from poor performance due to row-overflow and its effects. It doesn't matter whether the indexes are perfectly fragmented—when a variable-length column has been pushed off-row, the previously efficient scan is essentially interrupted since a random I/O is necessary to read the text page containing the off-row value.
Row-overflow is still very useful for occasional oversized rows. However, if query performance is critical, it should not be a heavily exploited component in your design.

Q We've just introduced database mirroring between two failover clusters as a way of getting geo-redundancy for less than the cost of storage area network (SAN) replication. The datacenters are within the same city, so we're able to use synchronous mirroring. The problem is that when a failover occurs on the local cluster, the mirrored database fails over to the remote cluster, which is not the behavior we want. How can we stop this from happening? We want the failover to happen only if the local cluster is unavailable.
A For increased availability, mirroring is set up with a witness server so failovers occur automatically if the principal becomes unavailable. The idea is that if the entire local cluster goes down, database mirroring will failover to the second cluster and the application can continue.
The problem occurs when a cluster failover happens. The failover takes longer to occur than the default time-out setting of database mirroring. The witness server and mirror server (meaning the active SQL Server instance on the second cluster) agree that they cannot see the principal, and then the mirror server initiates a mirroring failover to the second cluster.
The easiest method for preventing this is to remove the witness server so that database mirroring does not automatically failover if the local cluster goes down. Of course, this reduces availability, as a human is then needed to initiate a failover.
The second option is to alter the default timeout setting of database mirroring. This is the number of once-per-second "pings" that the principal must fail to respond to before it is declared unavailable. This setting is called the partner timeout and has a default value of 10. The current timeout value for the database can be found using the following code:
SELECT [mirroring_connection_timeout]
  FROM master.sys.database_mirroring
  WHERE [database_id] = DB_ID ('mydbname');
GO
The timeout value can be changed using the following code:
ALTER DATABASE mydbname
  SET PARTNER TIMEOUT <timeoutvalue>;
GO
For this scenario, the partner time-out needs to be set higher than the usual time it takes a cluster failover to occur on the local cluster. This may be a little tricky to determine given the variability in the time it takes to run recovery on the mirrored database when the cluster failover occurs, but you should be able to determine an upper bound. The problem with this method is that the timeout value may have to be minutes, which may be unacceptable for when a real disaster occurs.

Q My backup strategy involves full and log backups, but I've heard that I should add differential backups to decrease restore time. I take a full backup once a week and hourly log backups. I tried adding daily differential backups, but one odd thing I've noticed is that the differential backups at the end of the week are close to the same size as the weekly full backup. I was under the impression that they are incremental, just like log backups. Am I missing something?
A The misunderstanding here is around the nature of differential backups. Unlike log backups, differential backups are not incremental. A differential backup contains all the changed data file extents since the previous full backup (and this applies to database, filegroup, and file level backups).
When an extent (a logical group of eight contiguous data file pages) is changed in any way, it is marked in a special bitmap page called the differential map (or more commonly known as the diff map). There is a diff map for each 4GB chunk of each data file. When a differential backup is taken, the backup subsystem scans all the diff maps and copies all the changed extents, but the diff maps are not reset. This means that if more extents are changed between successive differential backups, the later backups will be larger. The diff maps are only reset when a full backup is performed.
If the application workload is such that the database contents are extensively changed within a short period of time (say, within a week), then a weekly full backup will be almost the same size as a differential backup that was taken just before the next full backup. This explains the behavior that you're observing.
You are correct in thinking that differential backups offer a way to reduce restore time in a disaster-recovery situation. If the backup strategy is to take weekly full backups and hourly log backups, an up-to-the-minute restore would require the following:
  • Take a tail-of-the-log backup (all the logs generated since the most recent log backup).
  • Restore the most recent full database backup.
  • Restore all log backups, in sequence, since the most recent full database backup.
  • Restore the tail-of-the-log backup.
This could require a lot of log backups to be restored, especially if the disaster occurs just before the next full backup is due. (A worst-case scenario would mean 24 + 24 + 24 + 24 + 24 + 24 + 23 log backups to be restored!) By adding daily differential backups to this strategy, the restore sequence changes to this:
  • Take a tail-of-the-log backup (all the logs generated since the most recent log backup).
  • Restore the most recent full database backup.
  • Restore the most recent differential backup.
  • Restore all log backups, in sequence, since the most recent differential backup.
  • Restore the tail-of-the-log backup.
This could remove the need for restoring a lot of log backups, as restoring a differential backup is essentially the same as restoring all the log backups in the period covered by the differential backup.
The very worst case in a scenario where a daily differential backup is performed would be 23 log backups, even on the last day of the week. The one downside of differential backups not being incremental is that they can take more space, but that's almost always a worthwhile trade-off to reduce restore time.

Q I have a two-node failover cluster. Each node is running a single instance of SQL Server 2005. I'm following the common advice of setting each instance to only use 50% of the available memory. Now I'm having issues because the workload on both instances needs more memory to maintain the same performance levels. If I remove the memory limitation, or make it higher, I think I'll run into problems when one of the instances fails over and they are both running on just one node. What do you recommend?
A I'll answer this question for the two-node, two-instance case, but everything below also applies to other multi-instance setups (N-1 failover clusters, where there are N nodes and N-1 SQL Server instances).
Many people experience a high workload (consuming more than 50% of server memory) on both instances and don't take into account the effect on the workloads when both instances end up running on a single node after a failover occurs. Without any special configuration, it's possible for the memory distribution between the instances to become disproportionate, so one workload runs fine and the other slows to a crawl.
With SQL Server 2000, the recommendation is to limit each instance to a maximum of 50% of cluster node memory. This is because the memory manager in SQL Server 2000 does not respond to memory pressure—if SQL Server takes, say, 80% of the node's memory, it will not give it back. In a failover situation, this means another instance just starting up would only have 20% of the memory available. By limiting both instances to a maximum of 50% of a node's memory, a fail-over instance is guaranteed 50% of the memory. The problem with this is that the workload on each instance is also limited to 50% of the memory.
With SQL Server 2005 (and SQL Server 2008), the memory manager can respond to memory pressure so the 50% maximum is no longer appropriate. But without some kind of limitation, if two instances are running on one cluster node, they may pressure each other until a disproportionate memory distribution is reached.
The answer is to set each instance to have a minimum amount of memory so they cannot be pressured to release too much memory. A common setting for a two-node, two-instance setup is to have each instance configured for a minimum of 40% of the memory. This means that when each instance is running on a separate node, they can consume as much memory as they want. When a failover occurs, each instance is guaranteed a certain amount of memory to preserve a set level of workload performance, with a little left over to be shared between them. Though this means that the performance of both workloads may drop in a failover situation (as expected), they won't be limited at all for the vast majority of the time when each instance is running on a separate cluster node.

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. Paul is an expert on disaster recovery, high availability, and database maintenance and is a regular presenter at conferences around the world. He blogs at SQLskills.com/blogs/paul.


Utility Spotlight Change Analysis Diagnostic
Lance Whitney

One of the PCs you support has just caught a new bug—maybe it's freezing or crashing, maybe some application has stopped working. Naturally, it's up to you to fix it. Sometimes the culprit can be a conflict with a recent change—a new application, an update, a driver. So how can you find out what's been recently installed? The Microsoft Change Analysis Diagnostic tool will tell you. This free utility scans a computer running Windows XP to reveal all the recent modifications.
The Change Analysis Diagnostic tool identifies changes that occur on PCs
Change Analysis Diagnostic scans for six distinct categories of changes:
  1. Software Programs—installed applications, such as those listed in Add/Remove Programs
  2. Windows hotfixes and other OS updates
  3. Windows drivers and services
  4. ActiveX controls downloaded via Internet Explorer
  5. Browser Helper Objects (BHOs)—typically toolbars and other items that load with your browser
  6. Auto-Start Extensibility Points (ASEPs)—programs that start automatically without user action.
Download the file, WindowsXP-KB924732-x86-ENU.exe, and run it in order to install. Just click on Start and choose the Run command. In the Open: field, type statechangediag. The file itself, statechangediag.exe, is stored in the directory named c:\windows\pchealth\helpctr\binaries\.
After the tool loads, you determine how far back to scan for changes—7 days, 14 days, 21 days, or a duration of your own choosing, which you set from an onscreen calendar. The scan takes a few minutes to run. The results are then saved as an XML file, which you can save and/or view through your Web browser. By default, the results file, scdiag.xml, is stored in the c:\documents and settings\username directory with its XSL stylesheet, scstyle.xsl.
The results report lists each change in its own separate table, with specific stats based on the category of change. For most categories, you'll see the Application Name or Filename and directory path, the Installation Date, and the Change Type (identified as "Create" if the program was installed, "Delete" if removed, and "Modify" if changed). Hotfixes and updates include a link to Microsoft Knowledge Base articles. ActiveX controls, BHOs, and ASEPs display their associated registry keys.
By default, the tool runs in Wizard mode, but you can also run it at a command line with the following options:
Nogui runs the tool in a console window instead of the GUI-based Wizard.
Verbose changes the output log to verbose, providing more detailed error messages.
History lets you specify the number of previous days to scan for changes. Seven days is the default. Enter the number of days after the -history string.
You can analyze the report yourself or work with Microsoft support to identify any recent changes that might be affecting the computer. Change Analysis Diagnostic uses Windows System Restore data to determine all recent changes. Therefore, it requires that System Restore be turned on and restore points have been created. As its name indicates, the tool runs only on Windows XP systems, and only those with SP2 or higher.

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.


Utility Spotlight SyncToy 2.0
Jay Munro

In the March 2007 Utility Spotlight column in TechNet Magazine, I described SyncToy, a free utility that makes it easier to copy and back up files from your computer to the network, external drives, or other computers. Using a "folder pair" concept, as shown in Figure 1, SyncToy lets you define one or more folders to keep in sync.
Figure 2 SyncToy uses a paired-folder architecture, where you specify a left and a right directory
While the original SyncToy is a tough act to follow, SyncToy 2.0 steps up to the plate by simplifying some choices and adding some really useful new features. Like its predecessor, SyncToy 2.0 is a free download. Running on the client side, SyncToy is not meant as a full-blown backup solution, but it fills the niche of automating repetitive file copying tasks you'd normally do manually.
SyncToy 2.0 installs quickly on Windows Vista or Windows XP and is available in 32-bit or 64-bit versions. You can upgrade from earlier versions of SyncToy and preserve your existing folder pairs. However, you must synchronize your folders first with the earlier version, then do the upgrade to avoid data loss when you use SyncToy 2.0. Once you upgrade, you should sync all your folders again to be sure SyncToy 2.0 is ready to track changes to your folders later.
Folder-pair creation in SyncToy 2.0 is done with a three-step wizard, where you specify two folders, type of copy or sync action, and a name for the folder pair. When you're done, you can preview and run a sync on one or more folder pairs. A useful new twist is that SyncToy 2.0 lets you go back and change the name of the folder pair.
The user interface is intuitive, with comprehensive help if you need it. If you're new to SyncToy, the basic idea is to copy, rename, or delete files between a pair of folders. You define folder pairs on which you can perform various actions, depending on the options you set. Options include excluding files based on file names or attributes, selecting subfolders, or performing file content checks. The file check option calculates and compares unique hash values for each file. By default, it's turned off for better performance, but if you're syncing files that have the same size and time stamps, you might want to turn this feature on.
In the original SyncToy, you had the choice of five different types of sync actions. SyncToy 2.0 offers three: Synchronize, Echo, and Contribute. At first, this seems like a step backward, but on a closer look, the extra two actions previously available were almost identical to other options. When you select an action in the folder-pair wizard, you get a short description of each action in the UI, so it's easy to choose the type you need. Here's how they work:
Synchronize Copies new and updated files in both directions. If you rename or delete a file in one folder, that action is replicated in the other.
Echo Copies new and updated files and performs deletes and renames only from the left folder to the right.
Contribute Copies new and updated files on the left to the right while ignoring deletions.
A new feature with SyncToy 2.0 is the ability to sync multiple folders to the same destination, which lets you combine or sync files from multiple folders on one or more computers. This can come in handy when using multiple laptops synced with a single network folder. So, no more excuses from the outside sales guys that they couldn't save their files to the network.
If you're using multiple external USB drives, you'll appreciate the dynamic drive assignment on folders. Since Windows assigns drive letters on a first-come, first-served basis, drive letters can get mixed up. If this happens, SyncToy automatically scans through all possible drive letters, to find the folder, and updates the folder-pair information.
SyncToy's setup has been improved as well, and there have been a number of under-the-hood updates to fix or enhance unattended execution, metadata location issues, and error handling. You now can also sync encrypted files to unencrypted folders, a boon for road warrior laptop-to-server tasks.
While SyncToy is well-designed and -tested, it isn't part of Windows and is not supported by Microsoft. However, there is a very active and responsive group of people on the SyncToy forum where you can ask questions, get help from others, and give feedback to the team.

Jay Munro is a writer on the Windows User Assistance team at Microsoft, specializing in Internet Explorer. Previously, he was a project leader with PC Magazine labs.


Inside SharePoint Enterprise Project Management with SharePoint
Pav Cherny

Contents
Project Server Architecture
SharePoint Integration
Server Farm Deployments
Welcome to IIS 7
Session Database Permissions
Shared Services Permissions
Windows Firewall
MOPS Services and Service Accounts
Analysis Services Integration
Conclusion
Which SharePoint technologies are right for you? In your effort to find the answer, you've probably sifted through a seemingly endless list of categories, including Collaboration and Social Computing, Portals, Enterprise Search, Enterprise Content Management, Business Processes and Forms, Business Intelligence, and Developer Platform Capabilities, and compared the features available in Windows SharePoint Services (WSS) 3.0, Microsoft Office Search Server 2008 Express, Microsoft Office Forms Server 2007, and Microsoft Office SharePoint Server (MOSS) 2007. However, there's one technology you may never have considered because Microsoft does not list it under SharePoint Products and Technologies—Enterprise Project Management (EPM), which is enabled through Microsoft Office Project Server (MOPS) 2007.
But MOPS 2007 is SharePoint technology; it builds on and extends WSS 3.0 in a way that is comparable to MOSS 2007. MOPS 2007 is the right choice if you want to increase the efficiency of team collaboration within and across departments through work, resource, and budget management beyond the lightweight task-management capabilities included in WSS 3.0 and MOSS 2007. With MOPS, you can turn team sites into project workspaces, manage team collaboration within and across departments, and establish a solid EPM foundation for an entire organization. First, however, you need to master the deployment challenges.
In this column, I discuss the deployment of MOPS 2007 in a Windows Server 2008 environment with SQL Server 2005 SP2 and WSS 3.0 SP1. First, I briefly review the MOPS architecture to show how the components integrate with WSS 3.0 from a system architect's point of view. This information makes it easier to follow the subsequent discussion of typical deployment and integration challenges you might encounter, such as application pool configuration issues, missing access permissions, Queue system startup errors, and issues related to SQL Server 2005 Analysis Services.
To illustrate the deployment and troubleshooting steps, I use a basic test environment with two WSS 3.0 servers in a server farm, a dedicated domain controller, and a separate computer running SQL Server, similar to the test environment I've been using so far for this SharePoint column. You can find corresponding worksheets with step-by-step instructions in the companion material for this column, located on the TechNet Magazine Web site.

Project Server Architecture
MOPS 2007 is one of the most advanced and complex SharePoint applications. It takes full advantage of the WSS 3.0 platform for centralized administration, site provisioning, authentication, and security. Also, it adds further components, such as 25 general and specialized MOPS Web Parts and a new collection of up to four MOPS databases per Project Web Access (PWA) site. Each is accessed through a set of 21 public and internal MOPS Web services that jointly form the Project Server Interface (PSI), as illustrated in Figure 1. You can find more details about MOPS Web services on MSDN.
Figure 1 SharePoint integration with MOPS 2007
The MOPS 2007 architecture relies on a variety of components distributed across client workstations, application servers, and database servers. I discuss the most important of these components in this column, but if you are interested in all the technical details, read the "Project Server Architecture" documentation in the Project 2007 SDK.
Just keep in mind when reading the SDK that PWA Web Parts and Microsoft Office Project Professional 2007 do not access the PSI Web services directly. The SDK suggests that clients make direct calls to the PSI, but most applications actually use the PSI Forwarder, which is a component in PWA sites that provides indirect access to the PSI Web services. Only server-based components, such as the Queue service and the Events service, that run with system-level permissions make direct PSI calls. This little detail is important for you to remember in troubleshooting situations for several reasons, specifically:
  • PWA sites define database context (every single PWA site has separate Draft, Published, Archive, and Reporting databases) and user permissions, but regular user accounts are not granted access to the PSI Web services.
  • The PSI Forwarder does not support impersonation and uses the PWA site's application pool account to access the PSI Web services on behalf of the users.
  • PSI calls do not necessarily use local PSI Web services if the farm includes multiple application-server instances.

SharePoint Integration
Now let's take a closer look at the actual MOPS integration with SharePoint. From a SharePoint admin's perspective, MOPS is a shared Web app managed as a farm service in SharePoint 3.0 Central Administration. This is relatively straightforward for administrators familiar with Shared Service Providers (SSPs) in MOSS 2007.
But if you are a WSS 3.0 administrator and new to SSP administration, you'll want to check out the "Deploying Project Server 2007" worksheet, available in the companion material, for step-by-step instructions to create and configure a SharePoint farm's shared services and PWA sites. Following the MOPS installation and configuration, you can analyze the system implementation in IIS Manager. As illustrated in Figure 2, you should see separate Web sites for shared services, SSP administration, and site collections on a MOPS application server.
Figure 2 Project Server 2007 access through PWA and PSI Forwarder
Clients access the PSI Web services through the _vti_bin/PSI virtual directory in a PWA site. However, the PSI Web services don't reside in this virtual directory. The _vti_bin/PSI virtual directory maps to the following physical path: %COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI. You will find that this directory contains a web.config file that specifies in an <httpHandlers> section that all HTTP requests to *.asmx files (that is, ASP.NET-based Web services) should be passed to a custom HTTP handler, instantiated through Microsoft.Office.Project.Server.PSIForwarderHandlerFactory.
This custom HTTP handler is the PSI Forwarder. The PSI Forwarder establishes a new HTTP connection to the actual PSI Web services, forwards the client's HTTP request, and then returns the results to the client.
The PSI Web services are available to the PSI Forwarder via HTTP through the PSI virtual directory of the Shared Services Web application, which is hosted in the Office Server Web services site. This virtual directory maps by default to the physical path %PROGRAMFILES %\Microsoft Office Servers\12.0\WebServices\Shared\PSI, and this is where you can find the MOPS 2007 *.asmx files.
I will explain more about the Office Server Web services site later; for now, the most important fact to take away from Figure 2 is that the PSI Forwarder communicates with the PSI Web services by using the identity of the PWA site's Web application pool account instead of the user currently accessing the PWA site.

Server Farm Deployments
The PSI Forwarder also plays an important role in server farm deployments that use separate Web front-end servers and application servers to increase system scalability and availability. A MOPS front-end server is a WSS 3.0 server that does not host the PSI Web services or other MOPS services (such as Queue service and Events service) but provides clients with access to PWA sites, which include the PSI Forwarder, as illustrated in Figure 3.
Figure 3 A medium-size MOPS 2007 server farm
An application server, on the other hand, is a WSS 3.0 server that has the full set of MOPS components and services installed. Application servers can host PWA sites, but more often than not they only provide back-end services to front-end servers and do not run the WSS Web Application service. You choose the server role during the MOPS installation.
Figure 3 shows the configuration for a medium-size server farm. You can add additional front-end servers to increase scalability as well as additional application servers for high availability, depending on your organization's requirements. It is not necessary to configure a load-balancing cluster for MOPS application servers because the PSI Forwarder automatically load-balances PSI requests if multiple MOPS application servers exist in the server farm. For detailed information regarding the MOPS deployment options, see the "Deployment Guide for Office Project Server 2007."

Welcome to IIS 7
Enough theory! Let's tackle some real-world issues that you might encounter during the deployment of MOPS 2007. One of my favorite issues relates to host-named site collections for PWA sites. In this scenario, you successfully deploy MOPS, configure the SSP, provision a PWA site in host-header mode by entering the full PWA URL (for example, pwa) after selecting the Use Project Web Access path as host header checkbox on the Create Project Web Access Site page. Then, after all resources are provisioned successfully, you attempt to open the site, but, instead of PWA, you reach the standard IIS 7 Welcome screen.
This is what happens if the Default Web Site is not SharePoint-extended and there is no other Web site with an appropriate site binding for the PWA URL. Without an explicit site binding, IIS associates the pwa request with the non-extended Default Web Site, so you see the Welcome screen. You might have expected SharePoint 3.0 Central Administration to add the required binding to the SharePoint Web app that you selected to host the PWA site, but this does not happen.
To address this issue, you must SharePoint-extend the Default Web Site and then use this site collection to provision PWA sites, as outlined in the Troubleshooting IIS and PWA companion worksheet. Alternatively, you can add the missing site binding manually in IIS Manager to the Web application selected for PWA. Don't forget to perform this step on all WSS servers that host the PWA site.

Session Database Permissions
If you decide to extend the Default Web Site, make sure you use a domain account for the application pool—see "Plan for Administrative and Service Accounts (Office SharePoint Server)"—otherwise, you will encounter permission-related issues after provisioning PWA sites, which usually manifest themselves in a typically uninformative SharePoint error message, such as the one displayed in Figure 4.
Figure 4 Error accessing the SSP database
To find more meaningful information, you should check out the trace logs, located in the %COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\LOGS directory. This can be a tedious task if your farm includes multiple load-balanced Web front-end servers.
For troubleshooting purposes, it is good to change the DNS record for the PWA host name and point it temporarily to a single front-end server. That way you know which server handles the client requests so you only need to check that one server's trace log files.
Open the most recent log file in Notepad and search for the entry "Cannot open database." If you find it, you know that you are dealing with a database permissions issue. For example, the trace log in Figure 4 shows that the account LITWARE\WSS02$ does not have access to the database SharedServices1_DB. This is a clear indicator that the PWA site is running with a Network Service identity.
LITWARE\WSS02$ is the computer account of the Web front-end server and SharedServices1_DB is the Shared Services Provider database. Among other things, the Web front-end servers use this database in order to maintain ASP.NET Session State data in the ASPStateTempSessions table, but LITWARE\WSS02$ does not have access to this database.
It's important to note that you must make sure you include the Shared Services Provider database in your weekly database maintenance activities to ensure stable system performance. For example, you should remove expired session state data from the ASPStateTempSessions table by using the SQL command TRUNCATE TABLE ASPStateTempSessions, as documented in "Deploy Project Server 2007 to a Server Farm Environment."
Network Service-related configuration issues can be confusing, so I am going to take a closer look at them. Domain accounts (such as LITWARE\SspConfigAdmin) work for application pools in server farms because they are exactly the same on all computers. In contrast, the Network Service account (NT AUTHORITY\NETWORK SERVICE) is different on every single computer. On a front-end server that is named wss02.litware.com, the NT AUTHORITY\NETWORK SERVICE account translates into LITWARE\WSS02$. But on a server with the name sql01.litware.com, the NT AUTHORITY\NETWORK SERVICE account refers to LITWARE\SQL01$ instead. There lies the problem.
If you examine the SQL Server permissions for SharedServices1_DB in SQL Server Management Studio, you can see that the NT AUTHORITY\NETWORK SERVICE account has db_owner permissions in an attempt to grant application pools that use the Network Service account access to the Shared Services Provider database. But remember that this works only in a single-server installation.
You can fix the permission assignments by explicitly granting LITWARE\WSS02$ and all other WSS server accounts (perhaps LITWARE\WSS01$ and so forth) db_owner permissions for SharedServices1_DB, but it is better to use domain accounts for application pools instead so that all front-end servers use the same identity that SharePoint has granted the required database permissions.

Shared Services Permissions
If your PWA site's application pool uses the Network Service account for any reason, you will also encounter SSP-related permissions issues. Remember I mentioned that the PSI Forwarder accesses the PSI Web services on behalf of the user in the context of the PWA sites application pool account? If this account doesn't have permissions to access the Office Server Web services site, you are back at square one with the usual SharePoint error message. This time, the trace log on the front-end server states "The request failed with HTTP status 401: Unauthorized," as displayed in Figure 5.
Figure 5 The request failed with HTTP status 401: Unauthorized
Keep in mind that this error does not refer to user permissions in PWA. SharePoint permissions granted in a PWA site determine which users can access that site's _vti_bin/PSI virtual subdirectory, but these users do not receive access permissions to the Shared Services Web app or the PSI Web services on the application server.
Even if you are a PWA site collection administrator, MOPS still fails if the PWA site's application pool account has no access to the PSI Web services. This is particularly the case if you ignore the recommendation to use domain accounts for application pools in a server farm and use the Network Service account instead.
To verify SSP access permissions on the application server, check out the web.config file in the root directory of the Office Server Web services site (by default, %PROGRAMFILES%\Microsoft Office Servers\12.0\WebServices\Root). You might notice the NT AUTHORITY\NETWORK SERVICE entry in the <authorization> section, which is supposed to authorize app pools that use the Network Service account. But again, it doesn't accomplish the task because the entry only refers to the local computer, which is not the front-end server.
The best strategy is to change the application pool configuration and use a domain account. But if you insist on using the Network Service account, you must authorize the front-end server accounts explicitly.
Don't edit the web.config file on the application server directly—SharePoint will overwrite your changes. Instead, use SharePoint 3.0 Central Administration to grant the missing permissions, as outlined in the "Testing Shared Service Provider Access Permissions" worksheet. Also, verify the configuration by using a simple ASP.NET app that establishes a direct HTTP connection to the PSI Web services, such as SSPCheck (which is included in the companion material). Just make sure you run the ASP.NET test application under the PWA site's application pool to obtain reliable results.

Windows Firewall
At this point, chances are good that you can open PWA—unless, of course, you are attempting to access PWA through a Web front-end server and the Windows Firewall on the MOPS application server blocks TCP ports 56737 and 56738. These are the default ports assigned to the Office Server Web services site for HTTP and HTTPS communication.
SharePoint doesn't open these ports automatically on the MOPS application server when creating the Office Server Web services site. If you have Windows Firewall enabled on the application server, you must manually create a firewall rule in order to allow traffic to these ports so that front-end servers can access the PSI Web services. If a firewall blocks these ports, you receive the error message displayed in Figure 6 and the trace log on the front-end server states "connected host has failed to respond."
Figure 6 Project Web Access cannot connect to Project Server

MOPS Services and Service Accounts
Having solved the front-end/back-end communication issues, you should be able to access Project Web Access. Congratulations! Now it's time to focus on a more difficult MOPS-specific issue. Take a deep breath and then open the application event log on your MOPS application server, and don't be shocked if you see thousands and thousands of error messages stating that the "Queue system could not start," as shown in Figure 7. You might also notice that MOPS services cause a nearly 100% CPU utilization.
Figure 7 The Queue system could not start
The Queue system is the backbone of the MOPS application infrastructure for MOPS database insert and update request handling, running clean-up and maintenance jobs and for updating the Reporting database for use in data analysis tasks. This is explained in great detail in the article "Microsoft Office Project Server 2007 Queuing System." According to this article, the Queue system relies on a Windows service, implemented in the assembly Microsoft.Office.Project.Server.Queuing.exe and running under the identity of the SharePoint configuration administration and timer service account to access the farm's configuration database.
On startup, the Windows service retrieves the list of all SSPs from the configuration database, including the corresponding SSP administrator accounts and their encrypted passwords, and then starts an additional Microsoft.Office.Project.Server.Queuing.exe process for each SSP associated with PWA sites in the context of the corresponding SSP administrator account. In other words, Microsoft.Office.Project.Server.Queuing.exe starts multiple instances of itself under different accounts, so the total number of Microsoft.Office.Project.Server.Queuing.exe processes running on a MOPS application server is equal to the number of SSPs plus one.
The additional process instances are the queue worker processes. Each individual queue worker process determines its own set of PWA sites from its associated SSP, starts separate polling threads for each of the PWA sites, and begins processing the jobs queued for the corresponding PWA site databases. That's how the Queue system works, and you can verify this in Windows Task Manager.
On a MOPS app server in a farm with one SSP associated with PWA sites, you can see two Microsoft.Office.Project.Server.Queuing.exe processes—one running as the configuration administration account and the other running as the SSP administrator account. In my test environment, these accounts are WssConfigAdmin and SspConfigAdmin, as shown in Figure 8.
Figure 8 Inter-process communication fails because access is denied
So why doesn't the Queue system start? The error entry in the application event log doesn't provide sufficient information, but you can obtain more details if you temporarily set the Least Critical Event to Report to the Trace Log for all categories to Verbose in SharePoint 3.0 Central Administration on the Operations tab under Diagnostics Logging.
Figure 8 shows a resulting trace log, and if you take a closer look, you can see that the ProjectQueueService (the overall Window service) starts a QueueExecService (a queue worker process), but the QueueExecService process fails because access is denied. As QueueExecService fails, ProjectQueueService attempts to restart it, but it again fails for the very same reason, and so it continues consuming CPU cycles and filling the event and tracing logs with thousands of errors. It's an infinite loop.
Unfortunately, even the most detailed trace log does not reveal the specific cause of the Access is denied error. But don't despair—through the process of elimination you can quickly get to the root cause.
If you change the SSP administrator account in SharePoint 3.0 Central Administration and specify the configuration administration account (WssConfigAdmin), the Queue system starts. It also works the other way around; if you simply leave the SSP administrator account unchanged (SspConfigAdmin) and use it as the service account for the Windows service, the Queue system starts as well.
It follows then that both the configuration administration account and the SSP administrator account have all required permissions; it's just that the Queue system doesn't start if ProjectQueueService and QueueExecService use different accounts.
This is a clear indicator of a permissions issue between separate processes that want to interact with each other on the local computer. After all, the ProjectQueueService and QueueExecService processes must monitor each other to ensure a consistent service behavior (notice the ProcessWatcher entries in the trace log in Figure 8). For example, when you shut down the ProjectQueueService Windows service, any QueueExecService worker processes must shut down as well.
It is the attempt to access a process running in a different security context that results in the error. Accessing a process in another security context requires elevated privileges. Even though the service accounts might have these privileges, Windows Server 2008 still denies access because User Account Control (UAC) is enabled by default, which causes processes to run with standard privileges.
As soon as you disable UAC, ProjectQueueService and QueueExecService processes can run with elevated privileges and the Queue system starts. The choice is yours between using the configuration administration account as the administrator account for all SSPs, thus running all queue processes with the same account, or weakening security on your MOPS application servers by disabling UAC.
SharePoint Resources

SharePoint Products and Technologies Web Site
microsoft.com/sharepoint

Windows SharePoint Services TechCenter
technet.microsoft.com/windowsserver/sharepoint

Windows SharePoint Services Developer Center
msdn.microsoft.com/sharepoint

Microsoft Office Project 2007 General Reference
msdn.microsoft.com/library/bb258902

Microsoft SharePoint Products and Technologies Team Blog
blogs.msdn.com/sharepoint

Plan for Administrative and Service Accounts (Office SharePoint Server)
technet.microsoft.com/library/cc263445

Analysis Services Integration
Let's conclude this column with a SQL Server 2005 Analysis Services issue that you are likely to encounter if you follow the instructions outlined in "Requirements for using SQL Server 2005 Analysis Services with the Project Server 2007 Cube Building Service" (dated 2007-04-05 at the time of this writing). If you follow the path to create the Analysis Services repository by creating a SQL Server 2005 database as documented, you will end up with the error displayed in Figure 9 when trying to build the cube in PWA.
Figure 9 Cube building error due to incorrect Analysis Services configuration
The important point is that MOPS 2007 is designed for SQL Server 2000 Analysis Services. SQL Server 2005 Analysis Services require additional configuration steps for backward compatibility. The SQL Server 2000 version stores repository information about the cube build in a Microsoft Jet database, and although it is possible to migrate a Jet database to work with SQL Server 2005, it is not necessary in a fresh MOPS deployment.
The TechNet article to which I just referred explains how to configure SQL Server 2005 to emulate the functionality of the Jet database regardless of whether or not the Jet database is actually present. Yet, the article fails to mention that MOPS still checks repository locking information in the .dso file share on the database server regardless of whether Analysis Services is configured to use a Jet database (the old method) or a preconfigured SQL Server 2005 database (which is the preferred method).
Unless this file share exists and the SSP administrator account is given Full Control access to this file share, the cube build fails with the permissions error displayed in Figure 9. For SQL Server 2005 Analysis Services to function correctly with the MOPS Cube Building Service, follow the steps outlined in the "Configuring Cubes" companion worksheet.

Conclusion
MOPS 2007 is not easy to deploy. The architecture is complex, and a successful deployment involves numerous steps, ranging from proper planning of server farm configurations, installing binary files and running the SharePoint Products and Technologies Configuration Wizard on application servers and Web front-end servers, through provisioning application pools, shared services, SSP administration sites, and PWA sites in SharePoint 3.0 Central Administration, to finally configuring Analysis Services in SQL Server Management Studio.
Contributing to the deployment challenges are interfering security features of Windows Server 2008, such as Windows Firewall and UAC, weaknesses in the SharePoint admin tools, and omissions in the MOPS deployment documentation. You cannot rely on SharePoint 3.0 Central Administration to warn you if your application pools use the Network Service account in a server farm, apply all required configuration changes automatically (such as IIS site bindings and Windows firewall rules), or check the operational state of provisioned PWA sites.
Also, don't expect everything to work out of the box. Make sure you fully understand the MOPS architecture and dependencies, do not deviate from product recommendations, and thoroughly validate the MOPS configuration and functionality by creating test project plans and resources to ensure deployment success.
Despite these challenges, MOPS also inherits the strengths of SharePoint as an enterprise platform. By relying on SharePoint and Web services technologies, MOPS eliminates the need for direct database connectivity on client workstations. Through the Queue system, MOPS increases sustainability during peak hours (for some unexplainable reason, all program managers want to update their project plans on Monday morning), and through additional MOSS technologies, it is possible to integrate MOPS with further line-of-business applications.
Having developed business solutions for Project Server 2003 in the past, I find the MOPS 2007 deployment challenges minuscule in comparison to the past scalability issues, the old ODBC connectivity issues over slow network connections, and the pain of building database queries that involved so many JOIN statements that I had to use Excel to keep track of all the sub queries. MOPS 2007 is a significant milestone in the EPM evolution, and it is worth the deployment effort.

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 Building a Better Inventory Tool
Don Jones

Contents
Objects Are Always the Same
Flexible Output
Flexible Input
What about Errors?
Making This Really Useful
In the previous installment of this column, I created a function that could retrieve service pack inventory information from multiple remote computers. While this is a very practical tool that can be quite handy, I was also concerned with the process I used to develop the tool. In this installment, I want to demonstrate the process I use so you will be better equipped to build your own functions.
The function I created in the previous installment looks like this:
Function Get-SPInventory {
  PROCESS {
    $wmi = Get-WmiObject Win32_OperatingSystem
      –comp $_ |
    Select CSName,BuildNumber,
      ServicePackMajorVersion
    Write-Output $wmi
  }
}
And here is how you can use it:
Get-Content c:\computernames.txt |
Get-SPInventory
This works well, if the text file includes one computer name per line.
One particular weakness of this function is that it is limited to returning data from a single WMI (Windows Management Instrumentation) class. So what if I also want to return the BIOS serial number?

Video
Following up on the previous installment of his Windows PowerShell column, Don Jones shows you how to make an even better inventorying tool. And, in doing so, he demonstrates a sound process for building your own custom Windows PowerShell functions.

Objects Are Always the Same
The problem is that my function is retrieving the Win32_OperatingSystem class from WMI and simply outputting that object. The Win32_OperatingSystem class, like all objects, is fixed in the data it contains—it doesn't include a BIOS serial number and never can. As long as I am merely outputting Win32_OperatingSystem objects, my output can never include a serial number.
No matter how much you rummage around in WMI, you will not find a single object class that includes both BIOS serial numbers and service pack information. As a result, my function cannot simply output a WMI class. Instead, I need it to output a custom object that I make up on the fly—one that contains all of the data I need.
To create a new, blank object with no properties, I just run this:
$obj = New-Object PSObject
The new object is stored in the variable $obj, and I can add whatever data I want to it. Once I have added all my data, it will then become the output of my function.
Inside my function, I've retrieved the Win32_OperatingSystem information and stored it in the variable $wmi. Using that information is as simple as referring to properties of $wmi. For example, to get the BuildNumber property, I would use this:
$wmi.BuildNumber
To add a property to my custom object, I have to pipe the object (which is in the variable $obj) to Add-Member. I tell Add-Member what type of property I want to add (always a NoteProperty), the name of the property I want to add, and the value I want the property to have, like so:
$obj | Add-Member NoteProperty BuildNumber
($wmi.BuildNumber)
I can do this for the computer system name and service pack version as well:
$obj | Add-Member NotePropertyCSName
  ($wmi.CSName)
$obj | Add-Member NotePropertySPVersion
  ($wmi.ServicePackMajorVersion)
Wrapping that up yields a new function (see Figure 1). Notice that I've changed the Write-Output line to output the custom object, rather than the original $wmi object.
Figure 1 A custom object
Function Get-SPInventory {
  PROCESS {
    $wmi = Get-WmiObject Win32_       OperatingSystem –comp $_ |
       Select CSName,BuildNumber,ServicePack         MajorVersion
    $obj = New-Object PSObject
    $obj | Add-Member NoteProperty
      BuildNumber ($wmi.BuildNumber)
    $obj | Add-Member NoteProperty CSName      ($wmi.CSName)
    $obj | Add-Member NoteProperty SPVersion
      ($wmi.ServicePackMajorVersion)
    Write-Output $obj
  }
}
Now I need to get that BIOS serial number. Some searching turns up the Win32_BIOS class, which has a SerialNumber property (Figure 2 shows a portion of the online documentation page). So I simply have to query the Win32_BIOS class, add the SerialNumber property to my custom object, and I'm done. You can see the revised function in Figure 3.
Figure 2 Win32_BIOS class documentation page
Figure 3 With SerialNumber property
Function Get-SPInventory {
  PROCESS {
    $wmi = Get-WmiObject Win32_      OperatingSystem –comp $_ |
      Select CSName,BuildNumber,ServicePack        MajorVersion
    $obj = New-Object PSObject
    $obj | Add-Member NoteProperty
      BuildNumber ($wmi.BuildNumber)
    $obj | Add-Member NoteProperty CSName      ($wmi.CSName)
    $obj | Add-Member NoteProperty SPVersion
      ($wmi.ServicePackMajorVersion)

    $wmi = Get-WmiObject Win32_BIOS –comp $_ |
      Select SerialNumber
    $obj | Add-Member NoteProperty BIOSSerial
      ($wmi.SerialNumber)
    Write-Output $obj
  }
}

Flexible Output
By using a custom object for the output, I've created a variety of potential uses for this function. For example, to include only Windows Server 2008 computers, I can use this:
Gc c:\computernames.txt | Get-SPInventory |
Where { $_.BuildNumber –eq 6001 }
Or, to create an HTML file listing all of the Windows Vista computers that don't have Service Pack 1 installed, I can use this:
Gc c:\computernames.txt | Get-SPInventory |
Where { $_.BuildNumber –eq 6000 } |
ConvertTo-HTML | Out-File c:\VistaInventory.html
The possibilities are endless—XML, CSV, tables, lists, HTML, sorted, filtered, grouped, and so on. The built-in cmdlets in Windows PowerShell are designed to work with objects. By creating objects for the output, you can take advantage of everything Windows PowerShell is capable of doing—with no extra work!

Flexible Input
Unfortunately, my function isn't as flexible in terms of input. This is partially a limitation of how functions are designed in version 1 of Windows PowerShell—version 2 will introduce script cmdlets, which offer a great deal more flexibility.
My function expects its pipeline input to be simple string objects. The function wouldn't work if I were to replace the Get-Content command with, say, a cmdlet to retrieve all the computer names from Active Directory, like this:
Get-QADComputer | Get-SPInventory
In this case, the Get-QADComputer command (part of a free set of Active Directory management cmdlets you can get at quest.com/powershell) is returning an object that has a Name property, rather than returning simple string objects. To make that command work, I would have to tweak the function, shown in Figure 4; it's important for you to note that the changes are highlighted in red.
Figure 4 The final product
Function Get-SPInventory {
  PROCESS {
    $wmi = Get-WmiObject Win32_OperatingSystem –comp
    $_.Name | Select
      CSName,BuildNumber,
        ServicePackMajorVersion
    $obj = New-Object PSObject
    $obj | Add-Member NoteProperty
      BuildNumber ($wmi.BuildNumber)
    $obj | Add-Member NoteProperty CSName
      ($wmi.CSName)
    $obj | Add-Member NoteProperty SPVersion
      ($wmi.ServicePackMajorVersion)

    $wmi = Get-WmiObject Win32_BIOS –comp $_.Name |
      Select SerialNumber
    $obj | Add-Member NoteProperty BIOSSerial
      ($wmi.SerialNumber)
    Write-Output $obj
  }
}
Rather than passing the entire pipeline object to the –computerName parameter, my function is now acting on the pipeline object's Name property. This minor change is quite worthwhile in terms of flexibility—by using Get-QADComputer, I am able to limit my input to computers in a specific organizational unit, for example, or to only those computers that are matching other criteria based on Active Directory attributes.

What about Errors?
Inevitably, this function will eventually come across a computer that it can't connect to, it doesn't have permission to connect to, or so on. The function, as it is currently written, will display an error message in red text within the Windows PowerShell console window, and then continue on to the next computer.
That, of course, might be just what you want it to do. Or you might prefer the function to suppress those error messages. This is easy to do simply by adding this one line to the start of the function's PROCESS script block:
$ErrorActionPreference = "SilentlyContinue"
Then again, you might want to take a more complex approach and create an error log that lists the names of the computers that weren't reachable. Windows PowerShell can do that, but you'll have to wait until next month to see how to do this!
Cmdlet of the Month: Export-Alias And Import-Alias
Here's a great way to share custom aliases that you've created or to easily load your custom aliases each time the shell starts. After you create all the aliases you want, export them to a file, like this:
Export-Alias c:\aliases.xml
Then, to load those aliases back into the shell, run this command:
Import-Alias c:\aliases.xml
You can place that second command in your Windows PowerShell profile script to have it run each time the shell starts. Also, you can place the file on a network share in order to have it readily available to the other administrators you work with.

Making This Really Useful
So far, you may have been typing this function into a .ps1 file and running the script. That's all well and good, but it does have a few usability problems. One issue is that anytime you want to use the function you would have to open up that script file, modify the line that calls the function (to add whatever output, sorting, or other commands you need at that time), save the script, and run it. It would be much easier if the function itself were available right within the shell's console window, almost like a cmdlet.
There are two options for going about doing this. The first is to simply copy the function into a Windows PowerShell profile script, one of the four script files that the shell will automatically run (if they exist) each time it starts. The Quick Start Guide that is installed with Windows PowerShell lists the four locations.
I usually use the file that is named profile.ps1, which has to be located in the folder named WindowsPowerShell (no spaces) inside your Documents folder (or My Documents on Windows XP and Windows Server 2003 computers). Once the function is in your profile, it'll be available right from the command prompt anytime you're in the shell.
The second option is to include the function—just the function, with no other code—in a script and dot source that script into the shell. What typically happens when you run a script is Windows PowerShell creates a new scope for the script. Anything that goes on in the script takes place within that scope, such as the definition of functions. When the script finishes running, the scope is discarded and anything that went on within that scope is lost.
As a result of this, remember that if you have a script file that contains only the Get-SPInventory function, running that script will create a new scope, define the function, and discard the scope, and then the function will go away. Obviously, that's not very useful to you.
Dot sourcing, on the other hand, runs a script without creating a new scope. If I've put Get-SPInventory into a file named MyFunction.ps1, I can dot source it like this:
PS C:\> . c:\functions\myfunction
Note the lone period, followed by a space, that precedes the script's path and file name. That tells the shell to run the script in the current scope, meaning everything that happens in the script will stick around after the script finishes running. The result is that the Get-SPInventory script is now defined in the shell and you can use it right from the command line, almost as if it were a cmdlet.

Don Jones is a cofounder of Concentrated Technology and author of numerous IT books. Read his weekly Windows PowerShell tips or contact him at ConcentratedTech.com.


Hey, Scripting Guy! Calculating Server Uptime
The Microsoft Scripting Guys

Up is up and down is down. Seems rather obvious—except, that is, when you're talking about server uptime. To know uptime, you need to know downtime. Nearly every network administrator is concerned about server uptime. (Except, that is, when he is worried about server downtime.) Most administrators have uptime goals and need to provide uptime reports to upper management.
What's the big deal? It seems like you could use the Win32_OperatingSystem WMI class, which has two properties that should make such an operation pretty easy: LastBootUpTime and LocalDateTime. All you need to do, you think, is subtract the LastBootUptime from the LocalDateTime, and then all is right with the world and you can even go catch a quick nine holes before dinner.
So you fire up Windows PowerShell to query the Win32_OperatingSystem WMI class and select the properties, as shown here:
PS C:\> $wmi = Get-WmiObject -Class Win32_OperatingSystem
PS C:\> $wmi.LocalDateTime - $wmi.LastBootUpTime
But when you run these commands, you are greeted not with the friendly uptime of your server, but by the rather mournful error message you see in Figure 1.
Figure 1 An error is returned when trying to subtract WMI UTC time values
The error message is perhaps a bit misleading: "Bad numeric constant." Huh? You know what a number is and you know what a constant is, but what does this have to do with time?
When confronted with strange error messages, it's best to look directly at the data the script is trying to parse. Moreover, with Windows PowerShell, it generally makes sense to see what type of data is being used.
To examine the data the script is using, you can simply print it to the screen. Here's what you get:
PS C:\> $wmi.LocalDateTime
20080905184214.290000-240
The number seems a bit strange. What kind of a date is this? To find out, use the GetType method. The good thing about GetType is that it is nearly always available. All you need to do is call it. And here's the source of the problem—the LocalDateTime value is being reported as a string, not as a System.DateTime value:
PS C:\> $wmi.LocalDateTime.gettype()

IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True     True     String
System.Object
If you need to subtract one time from another time, make sure you're dealing with time values and not strings. This is easy to do using the ConvertToDateTime method, which Windows PowerShell adds to all WMI classes:
PS C:\> $wmi = Get-WmiObject -Class Win32_OperatingSystem
PS C:\> $wmi.ConvertToDateTime($wmi.LocalDateTime) –
$wmi.ConvertToDateTime($wmi.LastBootUpTime)
When you subtract one time value from another, you are left with an instance of a System.TimeSpan object. This means you can choose how to display your uptime information without having to perform a lot of arithmetic. You need only choose which property to display (and hopefully you count your uptime in TotalDays and not in TotalMilliseconds). The default display of the System.TimeSpan object is shown here:
Days              : 0
Hours             : 0
Minutes           : 40
Seconds           : 55
Milliseconds      : 914
Ticks             : 24559148010
TotalDays         : 0.0284249398263889
TotalHours        : 0.682198555833333
TotalMinutes      : 40.93191335
TotalSeconds      : 2455.914801
TotalMilliseconds : 2455914.801
The problem with this method is that it only tells you how long the server has been up since the last restart. It does not calculate downtime. This is where up is down—to calculate uptime, first you need to know the downtime.
So how do you figure out how long the server has been down? To do this, you need to know when the server starts and when it shuts down. You can get this information from the System event log. One of the first processes that starts on your server or workstation is the event log, and one of the last things that stop when a server is shut down is the event log. Each of these start/stop events generates an eventID—6005 when the event log starts and 6006 when the event log stops. Figure 2 shows an example of an event log starting.
Figure 2 The event log service starts shortly after computer startup
By gathering the 6005 and 6006 events from the System Log, sorting them, and subtracting the starts from the stops, you can determine the amount of time the server was down between restarts. If you then subtract that amount from the number of minutes during the period of time in question, you can calculate the percentage of server uptime. This is the approach taken in the CalculateSystemUpTimeFromEventLog.ps1 script, which is shown in Figure 3.
Figure 3 CalculateSystemUpTimeFromEventLog 3
#---------------------------------------------------------------
# CalculateSystemUpTimeFromEventLog.ps1
# ed wilson, msft, 9/6/2008
#
# Creates a system.TimeSpan object to subtract date values
# Uses a .NET Framework class, system.collections.sortedlist to sort the events from eventlog.
#
#---------------------------------------------------------------
#Requires -version 2.0
Param($NumberOfDays = 30, [switch]$debug)

if($debug) { $DebugPreference = " continue" }

[timespan]$uptime = New-TimeSpan -start 0 -end 0
$currentTime = get-Date
$startUpID = 6005
$shutDownID = 6006
$minutesInPeriod = (24*60)*$NumberOfDays
$startingDate = (Get-Date -Hour 00 -Minute 00 -Second 00).adddays(-$numberOfDays)

Write-debug "'$uptime $uptime" ; start-sleep -s 1
write-debug "'$currentTime $currentTime" ; start-sleep -s 1
write-debug "'$startingDate $startingDate" ; start-sleep -s 1

$events = Get-EventLog -LogName system |
Where-Object { $_.eventID -eq  $startUpID -OR $_.eventID -eq $shutDownID `
  -and $_.TimeGenerated -ge $startingDate }

write-debug "'$events $($events)" ; start-sleep -s 1

$sortedList = New-object system.collections.sortedlist

ForEach($event in $events)
{
 $sortedList.Add( $event.timeGenerated, $event.eventID )
} #end foreach event
$uptime = $currentTime - $sortedList.keys[$($sortedList.Keys.Count-1)]
Write-Debug "Current uptime $uptime"

For($item = $sortedList.Count-2 ; $item -ge 0 ; $item -- )
{
 Write-Debug "$item `t `t $($sortedList.GetByIndex($item)) `t `
   $($sortedList.Keys[$item])"
 if($sortedList.GetByIndex($item) -eq $startUpID)
 {
  $uptime += ($sortedList.Keys[$item+1] - $sortedList.Keys[$item])
  Write-Debug "adding uptime. `t uptime is now: $uptime"
 } #end if
} #end for item

"Total up time on $env:computername since $startingDate is " + "{0:n2}" -f `
  $uptime.TotalMinutes + " minutes."
$UpTimeMinutes = $Uptime.TotalMinutes
$percentDownTime = "{0:n2}" -f (100 - ($UpTimeMinutes/$minutesInPeriod)*100)
$percentUpTime = 100 - $percentDowntime

"$percentDowntime% downtime and $percentUpTime% uptime."
The script begins by using the Param statement to define a couple of command-line parameters whose values you can change when you run the script from the command line. The first, $NumberOfDays, lets you specify a different number of days to use in the uptime report. (Note that I have supplied a default value of 30 days in the script so you can run the script without having to supply a value for the parameter. Of course, you can change this if necessary.)
The second, [switch]$debug, is a switched parameter that lets you obtain certain debugging information from the script if you include it on the command line when running the script. This information can help you feel more confident in the results you get from the script. There could be times when the 6006 event log service-stopping message is not present, perhaps as a result of a catastrophic failure of the server that rendered it unable to write to the event log, causing the script to subtract an uptime value from another uptime value and skew the results.
After the $debug variable is supplied from the command line, it is present on the Variable: drive. In that case, the value of the $debugPreference variable is set to continue, which means the script will continue to run and any value supplied to Write-Debug will be visible. Note that, by default, the value of $debugPreference is silentlycontinue, so if you don't set the value of $debugPreference to continue, the script will run, but any value supplied to Write-Debug will be silent (that is, it will not be visible).
When the script runs, the resulting output lists each occurrence of the 6005 and 6006 event log entries (as you can see in Figure 4) and shows the uptime calculation. Using this information, you can confirm the accuracy of the results.
Figure 4 Debug mode displays a tracing of each time value that is added to the uptime calculation
The next step is to create an instance of the System.TimeSpan object. You could use the New-Object cmdlet to create a default timespan object you would use to perform date-difference calculations:
PS C:\> [timespan]$ts = New-Object system.timespan
But Windows PowerShell actually has a New-TimeSpan cmdlet for creating a timespan object, so it makes sense to use it. Using this cmdlet makes the script easier to read, and the object that is created is equivalent to the timespan object created with New-Object.
Now, you can initialize a few variables, starting with $currentTime, which is used to hold the current time and date value. You get this information from the Get-Date cmdlet:
$currentTime = get-Date
Next, initialize the two variables that will hold the startup and shutdown eventID numbers. You don't really need to do this, but the code will be easier to read and easier to troubleshoot if you avoid embedding the two as string literal values.
The next step is to create a variable called $minutesInPeriod to hold the result of the calculation used to figure out the number of minutes during the period of time in question:
$minutesInPeriod = (24*60)*$NumberOfDays
Finally, you need to create the $startingDate variable, which will hold a System.DateTime object that represents the starting time of the reporting period. The date will be midnight of the beginning date for the period:
$startingDate = (Get-Date -Hour 00 -Minute 00 -Second 00).adddays(-$numberOfDays)
After the variables are created, you retrieve the events from the event log and store the results of the query in the $events variable. Use the Get-EventLog cmdlet to query the event log, specifying "system" as the log name. In Windows PowerShell 2.0, you could use a –source parameter to reduce the amount of information that needs to be sorted out in the Where-Object cmdlet. But in Windows PowerShell 1.0, you don't have that choice and must therefore sort through all the unfiltered events returned by the query. So pipeline the events to the Where-Object cmdlet to filter out the appropriate event log entries. As you examine the Where-Object filter, you'll see why the Scripting Guys had you create the variables to hold the parameters.
The command reads much better than it would if you used the string literals. The get eventIDs are equal either to $startUpID or to $shutDownID. You should also make sure the timeGenerated property of the event log entry is greater than or equal to the $startingDate, like so:
$events = Get-EventLog -LogName system |
Where-Object { $_.eventID -eq  $startUpID -OR $_.eventID -eq $shutDownID -and $_.TimeGenerated -ge $startingDate }
Keep in mind that this command will only run locally. In Windows PowerShell 2.0, you could use the –computerName parameter to make the command work remotely.
The next step is to create a sorted list object. Why? Because when you walk through the collection of events, you are not guaranteed in which order the event log entries are reported. Even if you pipeline the objects to the Sort-Object cmdlet and store the results back into a variable, when you iterate through the objects and store the results into a hash table, you cannot be certain that the list will maintain the results of the sort procedure.
In order to sidestep these frustrating and difficult-to-debug problems, you create an instance of the System.Collections.SortedList object, using the default constructor for the object. The default constructor tells the sorted list to sort dates chronologically. Store the empty sorted list object in the $sortedList variable:
$sortedList = New-object system.collections.sortedlist
After you create the sorted list object, you need to populate it. To do this, use the ForEach statement and walk through the collection of event log entries stored in the $entries variable. As you walk through the collection, the $event variable keeps track of your position in the collection. You can use the add method to add two properties to the System.Collections.SortedList object. The sorted list allows you to add a key and a value property (similar to a Dictionary object except that it also lets you index into the collection just like an array does). Add the timegenerated property as the key and the eventID as the value property:
ForEach($event in $events)
{
 $sortedList.Add( $event.timeGenerated,
 $event.eventID )
} #end foreach event
Next, you calculate the current uptime of the server. To do this, you use the most recent event log entry in the sorted list. Note that this will always be a 6005 instance because if the most recent entry were 6006, the server would still be down. Since the index is zero based, the most recent entry will be the count –1.
To retrieve the time-generated value, you need to look at the key property of the sorted list. To get the index value, use the count property and subtract one from it. Then subtract the time the 6005 event was generated from the date time value stored in the $currenttime variable you populated earlier. You can print out the results of this calculation only if the script is run in debug mode. This code is shown here:
$uptime = $currentTime -
$sortedList.keys[$($sortedList.Keys.Count-1)]
Write-Debug "Current uptime $uptime"
It is now time to walk through the sorted list object and calculate the uptime for the server. Because you are using the System.Collections.Sorted list object, you will take advantage of the fact that you can index into the list. To do this, use the for statement, beginning at the count -2 because we used count -1 earlier to figure the current amount of uptime.
We are going to count backward to get the uptime, so the condition specified in the second position of the for statement is when the item is greater or equal to 0. In the third position of the for statement you use --, which will decrement the value of $item by one. You use the Write-Debug cmdlet to print out the value of the index number if the script is run with the –debug switch. You also tab over by using the `t character and print out the timegenerated time value. This section of code is shown here:
For($item = $sortedList.Count-2 ; $item -ge
  0 ; $item--)
{
 Write-Debug "$item `t `t $($sortedList.
 GetByIndex($item)) `t `
   $($sortedList.Keys[$item])"
If the eventID value is equal to 6005, which is the startup eventID value, you calculate the amount of uptime by subtracting the start time from the previous downtime value. Store this value in the $uptime variable. If you are in debug mode, you can use the Write-Debug cmdlet to print these values to the screen:
if($sortedList.GetByIndex($item) -eq $startUpID)
 {
  $uptime += ($sortedList.Keys[$item+1]
  - $sortedList.Keys[$item])
  Write-Debug "adding uptime. `t uptime is now: $uptime"
 } #end if
} #end for item
Last, you need to generate the report. Pick up the computer name from the system environment variable computer. You use the current time stored in the $startingdate value, and you display the total minutes of uptime for the period. You use the format specifier {0:n2} to print the number to two digits. Next, calculate the percentage of downtime by dividing the number of uptime minutes by the number of minutes in the time period covered by the report. Use the same format specifier to print the value to two decimal places. Just for fun, you can also calculate the percent of uptime and then print out both values, like so:
"Total up time on $env:computername since $startingDate is " + "{0:n2}" -f `
  $uptime.TotalMinutes + " minutes."
$UpTimeMinutes = $Uptime.TotalMinutes
$percentDownTime = "{0:n2}" -f (100 - ($UpTimeMinutes/$minutesInPeriod)*100)
$percentUpTime = 100 - $percentDowntime
"$percentDowntime% downtime and $percentUpTime% uptime."
So now The Scripting Guys return to the original question: When is up down? You now see that you can't talk about uptime without taking downtime into consideration. If you thought this was fun, check out the other "Hey, Scripting Guy" columns on TechNet or go to the Script Center.

Version Issues
While testing the CalculateSystemUptimeFromEventLog.ps1 script on his laptop, Contributing Editor Michael Murgolo ran across a most annoying error. I gave the script to my friend Jit, and he ran into the same error. What was that error? Well, here it is:
PS C:\> C:\fso\CalculateSystemUpTimeFromEventLog.ps1
Cannot index into a null array.
At C:\fso\CalculateSystemUpTimeFromEventLog.ps1:36 char:43 + $uptime =
$currentTime - $sortedList.keys[$ <<<< ($sortedList.Keys.Count-1)]
Total up time on LISBON since 09/02/2008 00:00:00 is 0.00 minutes.
100.00% downtime and 0% uptime.
The error, "Cannot index into a null array," is an indication that the array was not created properly. So I dug into the code that creates the array:
ForEach($event in $events)
{
 $sortedList.Add( $event.timeGenerated,
 $event.eventID )
} #end foreach event
In the end, that code was fine. What was causing the error?
Next, I decided to look at the SortedList object. To do this, I wrote a simple script that creates an instance of the System.Collections.SortedList class and adds some information to it. At this point, I used the keys property to print out the listing of the keys. Here is that code:
$aryList = 1,2,3,4,5
$sl = New-Object Collections.SortedList
ForEach($i in $aryList)
{
 $sl.add($i,$i)
}

$sl.keys
On my computer, this code works fine. On Jit's computer, it failed. Bummer. But at least it pointed me in the right direction. The problem, as it turns out, is that there is a bug with the System.Collections.SortedList in Windows PowerShell 1.0. And I happen to be running the most recent build of the yet to be released Windows PowerShell 2.0 where that bug was fixed, and thus the code runs fine.
So where does that leave our script? As it turns out, the SortedList class has a method called GetKey, and that method works on both Windows PowerShell 1.0 and Windows PowerShell 2.0. So for the 1.0 version of the script, we modify the code to use GetKey instead of iterating through the keys collection. In the 2.0 version of the script, we add a tag that requires version 2.0 of Windows PowerShell. If you try to run that script on a Windows PowerShell 1.0 machine, the script will simply exit and you will not get the error.
Michael also pointed out something that's not a bug but is related to a design consideration. He noted that the script will not properly detect uptime if you hibernate or sleep the computer. This is true, as we do not detect or look for these events.
In reality, however, I am not concerned with uptime on my laptop or desktop computer. I am only interested in uptime on a server, and I have yet to meet the server that sleeps or hibernates. It could happen, of course, and it might be an interesting way to conserve electricity in the data center, but it's not something I've encountered yet. Let me know if you hibernate your servers. You can reach me at Scripter@Microsoft.com.

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

December 2008: PowerShell Commands
The list below contains 21 Windows PowerShell commands. The square contains the same commands, but they are hidden. Your job is to find the commands, which may be hidden horizontally, vertically, or diagonally (forward or backward).
EXPORT-CSV | FORMAT-LIST | FORMAT-TABLE
GET-ACL | GET-ALIAS | GET-CHILDITEM
GET-LOCATION | INVOKE-ITEM | MEASURE-OBJECT
NEW-ITEMPROPERTY | OUT-HOST | OUT-NULL
REMOVE-PSSNAPIN | SET-ACL | SET-TRACESOURCE
SPLIT-PATH | START-SLEEP | STOP-SERVICE
SUSPEND-SERVICE | WRITE-DEBUG | WRITE-WARNING

ANSWER:
Dr. Scripto's Scripting Perplexer
Answer: December 2008: PowerShell Commands

Ed Wilson is a Senior Consultant at Microsoft and a well-known scripting expert. He is a Microsoft Certified Trainer who delivers a popular Windows PowerShell workshop to Microsoft Premier customers worldwide. He has written eight books including several on Windows scripting, and has contributed to almost a dozen other books. Ed holds more than 20 industry certifications. Craig Liebendorfer is a wordsmith and longtime Microsoft Web editor. Craig still can't believe there's a job that pays him to work with words every day. One of his favorite things is irreverent humor, so he should fit right in here. He considers his magnificent daughter to be his greatest accomplishment in life.

Craig Liebendorfer is a wordsmith and longtime Microsoft Web editor. Craig still can’t believe there’s a job that pays him to work with words every day. One of his favorite things is irreverent humor, so he should fit right in here. He considers his magnificent daughter to be his greatest accomplishment in life.


Security Watch Revisiting the 10 Immutable Laws of Security, Part 3
Jesper M. Johansson

You’re probably familiar with the “10 Immutable Laws of Security.” This is an essay on security that was published about eight years ago and remains important and popular to this day. That said, a lot has changed in the past eight years, so I have set out to examine these laws and see if they still hold true. In the previous twoinstallments of the Security Watch column, I discussed the first seven of these laws.
So far, those laws hold up quite well, despite the monumental advances in security and connectivity we've seen in recent years. While a few of the laws may have a slightly different interpretation today, and while there may be some forms of partial mitigation for one or two of the laws, they still qualify as laws. They are still very useful in framing an information security strategy, and in a common law system we expect laws to grow with us.
This month I will discuss the last three laws and conclude with some insight on how the environment may have changed and created a new void that the laws no longer fill. And if, by chance, you haven't read the original essay, you can find it on TechNet.
Law #8: An out-of-date virus scanner is only marginally better than no virus scanner at all.
Of all the laws, this is the one that most shows its age. It is not that there are no viruses any longer—quite the opposite. Today the antivirus vendors claim they add several hundred thousand infectors per year. And in the "Symantec Global Internet Security Threat Report," published in April 2008, Symantec announced that it now detects more than 1 million different threats.
Where Law 8 shows its age is in that it specifies a virus scanner. Back in the late 1990s, viruses were pretty much what we had to worry about. However, the days when a Microsoft Word macro virus was the worst thing with which we had to contend are now long gone. Today we fight viruses, worms, spyware, adware, keystroke loggers, rootkits, phishing Web sites, spam, and bots. And if those aren't enough to keep you on your toes, you also have to watch out for fake anti-malware software.
Viruses are a fairly quaint technology compared to all the other malicious things we have to deal with today. Does it really matter, then, if your antivirus software is out of date if all you have is something that detects viruses? Obviously, there is virtually no anti-malware software available today that only detects viruses—but the law's emphasis here on virus scanner is where its age shows. To be even marginally useful, an anti-malware solution must detect much more than just viruses.
As noted in the last installment of my three-part series "Passwords and Credit Cards", this has led to a checkbox ecosystem where the various security software vendors compete based on the number of checkboxes they can claim to fill. One of the ways they fill those checkboxes is by protecting against all the different types of malware.
Most anti-malware software is available only as suites that do much more than anti-malware and include consoles to manage all the features. Figure 1 shows the console provided by Microsoft Windows Live OneCare, which includes antivirus, antispyware, and backup features; tracks the built-in phishing filter in Internet Explorer; and includes a separate firewall that is not based on the one built into Windows (a redundancy that is customary in security suites). Today, antivirus software is really anti-malware software typically with extras.
Figure 1 The Live OneCare console is quite typical of security suites today
That's because there is more malware than ever before, and the criminals writing malware are getting better at disguising it as legitimate software. It has really become a hybrid of Trojan horse software and other malware.
The average user has an extremely hard time telling legitimate from malicious software. And a lot of malware is served up from legitimate Web sites, or sites that used to be legitimate, often in the form of advertisements. Some even do their evil deeds automatically, with no user interaction whatsoever beyond visiting the site.
Anti-malware software can help detect some of this malicious software. The best approach to keep this wave of criminality at bay is to use both anti-malware software and judicious computer practices. While some may argue that judicious practices are sufficient alone, this depends on good judgment and common sense—attributes that are, sadly, disturbingly uncommon.
Or consider another scenario: computer use by children. They have no relevant experience to call upon; moreover, many parents do not understand computer security well enough to impart its importance to their children. Furthermore, it is nearly impossible to supervise children every minute they are using a computer.
In that situation, anti-malware software provides at least a partial safety net—it forces the criminals to keep improving their practices. And while this can cause a vicious cycle where the malware becomes better and better, clearly it also keeps quite a bit of it at bay.
Anti-malware software may at least keep the most basic malware out of the ecosystem, allowing security professionals to focus on the more sophisticated attacks. If anti-malware software is removed entirely from the ecosystem, it is indeed likely that we would be absolutely overrun even by unsophisticated malware. The problem would be many orders of magnitude worse than today.
None of this answers the question on the table, however, which is "does Law 8 still hold?" Obviously, it depends on interpretation. From a purist perspective, the Law says that antivirus that is not up to date is only marginally better than no antivirus. However, with malware mutating as rapidly as it does, you could easily argue that antivirus software that is not up to date is entirely useless. This may be a bit of a hyperbole, but it's not an entirely unreasonable claim.
A much more realistic way to look at Law 8 is to reinterpret it for the modern world. Thus, I would restate it as "Anti-malware software must be used and kept up to date." If one takes that more pragmatic view of the Law, then Law 8 definitely holds. After all, even the most ardent opponents of anti-malware software can't argue successfully that we should banish it from the security ecosystem entirely.
I personally tend to take a fairly interpretive view of laws and would argue that Law 8 still holds. However, I would add that, with malware mutating more and more rapidly, it is absolutely critical to keep anti-malware software up to date.
Law #9: Absolute anonymity isn't practical in real life or on the Web.
When I think about this law, I find it difficult not to crack some joke about how our governments and large corporations make sure we have very little anonymity. The United States government and The TJX Companies together have made sure that personal information on about half of the U.S. population has entered into the portfolio of the criminal underground. While I would love to imagine that there is any such thing as anonymity, in all practicality, anonymity doesn't exist today (unless you're willing to completely disconnect, give up your bank accounts, move to a desert island, and drop off the radar entirely).
There is a vast amount of information about all of us that we either give away deliberately or that can be gleaned just from interacting with us. Social networking sites have collectively assured that most adults who use the Internet, and many children, have a wealth of personal information publicly available. Much of it is not necessarily information we want people to have access to. Some of it is embarrassing to us or others. (Remember that a prospective employer may see that incriminating photo of you).
Then there is information that can be downright damaging. Phone numbers, addresses, finances, and any other kind of personal information should be treated as sensitive. In one case, a user had come up with a really good way to track all the Internet sites he uses for banking, managing credit cards, and so on. He created a custom homepage with all the links he needed. To make it easy to remember all the right pieces of information, he also scanned all of his important documents, including a check with his bank account number printed on it, his credit cards (front and back), his driver's license, his passport, and even his social security card.
This would have worked well if he had put the Web page in a secure place. Unfortunately, his personal home page, which was hosted on his ISP, was not private. The URL showed up in the referrer string on every page he clicked on from his page. Following that URL back revealed personal information worth many thousands of dollars on the criminal market. This is an extreme case, but it highlights the point of how important it is that you carefully manage the information you allow to go online about yourself.
While social networking sites generally offer elaborate privacy options, they are often not turned on by default. Figure 2 shows the privacy controls for Facebook, albeit not in their default settings. The point is, while you cannot expect to have absolute anonymity, you can retain a certain measure of anonymity if you are careful.
Figure 2 Privacy settings on Facebook can be restricted if you change the defaults
Privacy on the Internet, as in real life, is largely dependent on how you manage it. You can't help it when a government agency or corporation mishandles your personal information, but you can work on mitigating the impact of such a breach. And you can avoid handing over too much information when not absolutely necessary.
One very useful method of controlling your personal information is establishing a fraud alert with the major credit-reporting bureaus. Unfortunately, due to persistent and successful lobbying by credit bureaus, they are permitted to make these fraud alerts very onerous to obtain. They cost anywhere from $6 to $12 per bureau, per three-month period, and usually must be manually renewed. A better option is to use a third-party service, such as Debix (debix.com), and have them establish the fraud alerts for you.
If you do not need to obtain credit, you can set up a credit freeze, preventing anyone from pulling your credit report. However, the credit bureaus have ensured that credit freezes are not legal in most states, and in many other states they are restricted only to people who have already had their personal information stolen. Credit freezes also cost much more money and often have to be set up via certified mail. (Curiously, they can usually be lifted with a simple phone call.)
Another way to control your personal information is to restrict who gets it. Do not hand it over to organizations that do not need it. Stick to organizations you trust, and do not patronize organizations that have shown a disregard for your protection in the past. There is no reason for you to establish an account and provide credentials to get basic information. If access to a product manual requires you to register on a Web site, either do not use the product or use fake information to register. If you need an e-mail address to do so, use a free Web mail service to set up a temporary fake account.
All of this really serves as proof that Law 9 most definitely still holds. Your ability to keep things private on the Web, and in real life, has not gotten any better in recent years; it has really gotten quite a bit worse. Since the original laws were published, virtually everything has gone online and the Internet is now used as the conduit for a tremendous amount of business that uses your information.
Thus, it is now more important than ever to keep track of your personal information. The one modification I might make to Law 9 is to rewrite it as "Absolute anonymity is impossible on the Web, but you are in control of how close to anonymous you get."
Law #10: Technology is not a panacea.
Law 10 is a catch-all. It is meant to point out that there is no big, blue secure-me-now button—or at least not one that works. Technology alone is incapable of assuaging our security concerns. This is a serious issue because so much of the security industry has tried its best to convince people that technology, in fact, is a panacea. The recurring message is that all you need is the latest version of the right security suite and you can stop worrying about everything else.
That is not actually where Scott Culp was going with Law 10 when it was originally written, but as with all great laws, they grow and evolve with the times. The original intent was to point out that technology itself will not be perfect, and even if it were, the attackers would go elsewhere. Back when the laws were written, the technical security record was far from stellar. Microsoft was under siege, and Law 10 was, in some ways, a way for Microsoft to explain its security record.
Law 10, however, was also prescient in many ways. The explanation includes the statement that if you raise the cost and difficulty of attacking security technology, bad guys will respond by shifting their focus away from the technology and toward the user.
That is exactly what has happened. Technology is too hard to break; humans are not. So the criminals are attacking human beings with various social engineering and phishing techniques. In a world where insecurity can be monetized, that is the natural progression of things.
Law 10 not only holds, it was very much ahead of its time—so much ahead of its time, that is, that while the law is as true today, the explanation seems a bit dated. Perhaps the law simply had a different connotation when it was written. Today it still holds, but the meaning has changed and the interpretation needs to grow. We must look beyond technology and work on the process part of security and the people side of the equation. To be successful, we must figure out how to secure those portions of the ecosystem.

Now What?
The laws have proven to be remarkably resilient. They all hold eight years hence. A few, notably Law 10, seem like they have even grown with the times and could just as easily have been written yesterday. The final law, being a catch-all for all practical purposes, was visionary (or at least turned out that way). It seems to have foreseen the new branch of soft security that is so critical to a healthy ecosystem.
Technology truly is no panacea. Only by understanding that fact could the Laws have been formulated in the first place. Only by taking into account the fact that technology is fallible can a person fully appreciate all the other laws. In fact, if you look at Laws 1 through 9, at some point they all come down to soft security and process. All of them are essentially about misconfiguration, a missing patch, a vulnerability introduced by a human being, or some other form of mishandling of the system or the data it protects.
When I first set out to write this three-part series, I had every intention of adding a few laws of my own. In the course of analyzing the laws, however, I have come to realize that doing so is unnecessary. Law 10 sums up all the others and covers anything I might have added. In fact, rather than adding, I would simply restate Law 10 as "Technology is not a panacea, and moving beyond this misperception is essential to security."
Remember that these laws come from a time when the IT environment was shifting from a Y2K mind-set to a world of auditing experts. Security has now overtaken all mindshare.
Why is that? It is largely because of the explosive growth of criminal enterprises. The criminals, many of them operating in the open in countries without a legal system interested in protecting us, realized that they could monetize lax computer security. This has touched the drug trade, the mafia in the former Eastern Bloc, terrorist groups, and so on.
Computer crime is now driven purely by three factors: greed, ideology, and national supremacy. To combat these new attacks, we must operate within the framework of the immutable laws. We must also make difficult trade-offs, but I will save that discussion for a future column.

Jesper M. Johansson is a Principal Security Architect for a well-known Fortune 200 and is a contributing editor to TechNet Magazine. He holds a Ph.D. in Management Information Systems, has more than 20 years experience in security, and is a Microsoft Most Valuable Professional (MVP) in Enterprise Security. His latest book is the Windows Server 2008 Security Resource Kit.


Sustainable Computing Power Management Settings for Compliance and a Reduced Footprint
Frank Koch, Mike Stephens, and Michael Walsh

Contents
Bring Windows Server 2008 and Windows Vista Power Management Settings into Compliance
Bring Windows Server 2003 and Windows XP Power Management Settings into Compliance
Enforcing Energy-Efficient Architectures with Microsoft System Center
System Center Capacity Planner 2007
System Center Configuration Manager 2007
Microsoft offers a number of solutions that can help IT Professionals reduce the energy footprint of their infrastructure. In this installment of the Sustainable Computing column, we want to discuss how features available in Microsoft operating systems, various IT tools, and system management solutions (such as Microsoft System Center) can help you save money and minimize carbon emissions.
With Microsoft System Center Configuration Manager 2007, you can easily monitor and capture the configuration information of servers, desktops, and laptops across your network. In doing so, Configuration Manager utilizes Desired Configuration Management (DCM) to evaluate systems and determine whether they are configured in accordance with corporate requirements.
DCM supports imported configuration packs, which are best practices created by Microsoft and other software vendors to identify common configuration errors for applications and operating systems. For instance, the August 2008 release of the Microsoft Assessment Configuration Pack for ENERGY STAR Power Management allows administrators to assess display and hibernation settings on Windows XP and Windows Vista to determine whether systems adhere to the ENERGY STAR guidelines set by the United States Environmental Protection Agency (EPA). These guidlelines are as follows:
  • Computers must enter system standby or hibernate after 30 to 60 minutes of inactivity.
  • Monitors must enter sleep mode after 5 to 20 minutes of inactivity.
Using the new configuration pack, administrators can also ensure that a warning notification report is created if screen savers are not disabled. (Screen savers should not be used if you are trying to reduce your footprint.)

Bring Windows Server 2008 and Windows Vista Power Management Settings into Compliance
Windows Server 2008 and Windows Vista are configured by default to take advantage of energy-efficient features. They also allow you to use Group Policy to centrally manage a greater number of features than Microsoft Windows Server 2003. With the latest Microsoft operating systems, all power management settings support Group Policy and ship with more than 35 power management settings that administrators can use to create the power management strategy that best suits their needs. They can then use Group Policy to roll out their energy settings.
As you probably know, Group Policy allows administrators to define specific configurations for groups of users and computers. These settings are specified through the Group Policy Object Editor (formally known as GPedit) and contained in a Group Policy object (GPO), which is in turn linked to Active Directory containers, such as sites, domains, or OUs.
In this way, Group Policy settings are applied to the users and computers in those Active Directory containers. IT professionals therefore can configure a user's work environment once and rely on the system to enforce the policies as defined.
To take advantage of Group Policy, you must acquire the Group Policy Management Console (GPMC), which is a comprehensive administrative tool for Group Policy management. GPMC comes with both Windows Server 2008 and Windows Vista. Note that Windows Vista SP1 requires you to download the Microsoft Remote Server Administration Tools for Windows Vista. This free download includes an updated version of GPMC. The first version of GPMC (version 1.0) is meant for configuring Group Policy in a Windows Server 2003 and Windows XP.
The advantage of using Group Policy to configure power settings is that Windows Server 2008 and Windows Vista will use the values specified by Group Policy, preventing end users from changing the settings. If the user attempts to make a change, the Windows Vista Power Options Control Panel informs the user that the selected power policies may not be changed because they are enforced by the administrator.
While Windows Vista does let the user switch between power plans (such as battery saver and balanced), the administrator can use Group Policy to enforce specific settings within those power plans. Even if the user changes power plans, the Group Policy power setting is enforced.
To enforce a power setting using Group Policy, administrators must use the Management Console to edit a new or existing GPO. The power management policies are located in Power Management, under Computer Configuration | Administrative Templates | System | Power Management. Note that there are no power management policies under User Configuration in Windows Vista, and each power setting lets you specify separate values for when the computer is plugged-in (AC) or running on battery power (DC).
For a complete description of how to deploy power management settings to bring your Windows Vista systems into compliance, see the May 2008 installment of this column, "Conserving Energy with Group Policy".

Bring Windows Server 2003 and Windows XP Power Management Settings into Compliance
If you find that you have Windows Server 2003 and Windows XP systems that do not meet the desired power management requirements, you can then use Group Policy Preferences to bring those systems into compliance. To use this functionality, you need the GPMC.
You'll also need to acquire the client-side extensions that allow Windows Server 2003 and Windows XP to process GPOs that contain preference configuration data. These are also available as free downloads for Windows Server 2003, Windows XP, and Windows Vista.
Group Policy Preferences offer two items that can be used to configure power management settings on Windows Server 2003 and Windows XP. The Power Schemes preference allows you to create, modify, and delete power schemes. In other words, it allows administrators to configure Windows XP clients to use one of the pre-existing power schemes, modify the settings included in one of the pre-existing power schemes, or deploy a custom power scheme. The Power Options Preference provides a way to configure hibernation, configure prompting for a password when the computer resumes, and set the Power button action for mobile computers.
When you view properties on a Power Option Preference item, the configuration screen closely resembles the properties dialog provided by the OS.
There are some important points you should keep in mind when working with these Preference items. First off, Preferences allow administrators to choose which settings they want to control and which settings they do not want to configure. And, an important point, Preference items are not Group Policy settings. They are not enforced but rather just applied. Users with proper privileges can change a Preference setting to another selection, though the setting will return on the next Group Policy refresh unless it has been configured otherwise.
Power Schemes has the same enable/disable feature as Power Options and behaves in the same fashion. Power Schemes provides settings for two scenarios: Plugged-in and Running on batteries. You can use Power Schemes to define the time-out settings for turning off monitors, hard disks, system standby, and system hibernate.
The Power Schemes action field determines the action that Group Policy processing applies to the specific preference item. There are four actions to choose from:
  • Create generates a new Power Scheme. If a Power Scheme with the same name already exists on the target computer, the Preference item does nothing.
  • Delete will delete a Power Scheme.
  • Update will update Power Schemes. If you try to update a Power Scheme that does not exist on the target computer, then a new Power Scheme is created with that name.
  • Replace is very similar to Update. Whereas Update simply updates the enabled settings on the existing Power Scheme, leaving all other settings as they were, Replace actually deletes the named Power Scheme from the computer and creates a new Power Scheme based on the settings specified in the Power Scheme Preference item.
Here are some other things you should keep in mind:
  • Power management Preference items can target both computer and user configurations. This means the user settings, possibly from another Preference item, will replace the current power settings.
  • Local Administrators are Administrators. Administrators can change their power configuration, but standard users cannot.
  • When Group Policy applies power management Preference items, those items become the current power management scheme—even after the user logs off.
  • Power management Preference items support background refresh and, therefore, settings can change.
Aside from Group Policy Preferences, Windows Server 2003 administrators can also use a manual command line tool called Powercfg (support.microsoft.com/kb/324347). With this tool, an administrator can access the settings from the Power Options tool in the Control Panel and set those settings from the command line.
Powercfg also extends some settings that are not available in Control Panel, although Powercfg does not let you configure all the settings in the Power Options tool. Unfortunately, this tool doesn't let you centralize configuration of power management settings and, therefore, it is not the best option for enterprise administrators. With the right processor and driver, though, System Center Configuration Manager can overcome this shortcoming by centrally deploying an updated power profile (and any necessary drivers) across all Windows Server 2003 servers.

Enforcing Energy-Efficient Architectures with Microsoft System Center
To truly achieve energy efficiency across the enterprise, you must think beyond power management settings and take into consideration the entire profile of your organization's architecture.
Fortunately, Microsoft System Center provides powerful tools to analyze and optimize architectures for energy efficiency. Two particularly useful features are the Capacity Planner and Configuration Manager.

System Center Capacity Planner 2007
Microsoft System Center Capacity Planner 2007 allows you to profile your existing server architecture, including Microsoft Exchange Server 2007, Microsoft Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007, and Microsoft System Center Operations Manager 2007. This enables you to generate an architectural model based upon:
  • Topology (site locations, types of networks, network components, and network characteristics such as bandwidth and latency)
  • Hardware (server distribution and characteristics, server and network mapping, and so on)
  • Software (server role and service mapping, file and storage device mapping, and the like)
  • Usage profiles (site usage and client usage)
The model provides two primary benefits to administrators. First, you can use the model to plan the correct amount of infrastructure needed for a new application to meet service-level goals. This can help you eliminate over-provisioning. Second, you can survey your hardware and software to account for inefficiencies in hardware, software, and components. Based on the goals and objectives of your organization, you can then procure replacements for devices that do not comply with requirements.

System Center Configuration Manager 2007
Microsoft System Center Configuration Manager 2007 also provides detailed asset information beyond just the server infrastructure. As with Capacity Planner 2007, the information provided by Configuration Manager 2007 can help you determine, for example, which machines and components should be replaced first based on energy efficiency.
Configuration Manager can provide even greater insight. For example, say you are deploying graphic cards across an enterprise that has a lot of CAD systems. There might be a large variety of graphics cards, so we'll categorize them as high-end and low-end for the purpose of this example and further assume that high-end cards consume much more energy than the low-end cards. If you want to optimize for energy efficiency in this environment, you'll need to ensure that only CAD users are in possession of the high-end graphics card machines and only non-CAD users are in possession of low-end graphics card machines.
Configuration Manager provides an overview of who has what component in combination with which software. Using this information, you can quickly profile the organization's machines and determine who is using the high-end graphics cards for Blizzard's World of Warcraft or Microsoft Flight Simulator and who is using the cards for CAD purposes. Knowledge is the key here, and Configuration Manager provides the detailed asset information you'll need to optimize your architecture for energy efficiency.

Frank Koch works for Microsoft.
Mike Stephens works for Microsoft.
Michael Walsh is the Senior Environmental Product Manager at Microsoft.


Field Notes Prep Your Patch Policy
Mark D. Scott

I was recently working with a client when we ran into an interesting service pack issue. The IT team decided to apply SP2 to its SQL Server production servers. They did what one would expect from a responsible team: they applied the service pack to the servers in the test environment to assure the applications that used SQL Server did not break. Everything seemed to test out fine. They notified everyone in the organization and scheduled the patch to be applied to the servers.
Things went into place in production without a hitch. They continued to distribute the patches to the servers in stage, test, and finally development. A textbook deployment. Until one of the developers tried to open his Reporting Services project. Suddenly, he had myriad quirky little problems. Reports would open, but parts of the reports would be unavailable. Another developer opened an Analysis Services database. No problem. Until he tried to open the Calculated Members tab. Something was definitely broken.
As you may have guessed, the issue was that while the servers had received the service pack, the developers had not. Since the SQL Server client tools installed on the desktops were considered part of the desktop deployment and not the server deployment, they were not considered in the upgrade. And distributing the service pack to the developers involved another round of testing and setting up the distribution. (We will not even mention the fact that not all the developers were put out of commission—which meant that some had already applied an out-of-policy service pack to their desktop. That is another article altogether.).
While this mess was being straightened out, maintenance on some of the analytic applications used by the company ground to a halt. The event brought to the fore how inconsistent and unclear the policy was on service packs. It also demonstrated some fractures in interdepartmental communications. Distribution of service packs is very important because it keeps the ecosphere more secure.
Some organizations resist the application of service packs, fearing the strife and confusion of distributing the software more than the vulnerabilities the service pack can help overcome. Other organizations have no policy at all, allowing individual users and system administrators to apply or ignore patches as they see fit. This creates its own maintenance nightmares as patches appear on one server but not another. Some are fully protected while others remain at the same state as when they were installed.
Most larger and/or more sophisticated IT organizations have read the infrastructure optimization models and realize that they should be proactively establishing policy and implementing procedures that assure this type of thing does not happen. They know that they can automate many of these issues and prevent this kind of gaffe. However, at the end of the day and at the edge of the tools lies the fact that people need to understand that what they do affects other people and other departments. And then they need to communicate with one another.
It is easy to think of the ways a service pack will affect your domain, to consider the subset of things that touches your systems, and to cover your own bases. It is more difficult to think outside your private box and consider the effects of the change outside of your realm. Sometimes we become as siloed in our thinking as the applications we shepherd.
The good news is that this event was relatively easily corrected. The organization did have a mature model. Once the issue was identified (again, somewhat confused because the problem only existed for the developers that played by the rules), the patch was quickly (and automatically) distributed. A fresh dose of clear communications and a well-designed system helped correct the problem with minimal downtime or disruption.
It seems that the answer lies in allowing our infrastructure, and ourselves, to mature. An effective service pack policy addresses procedures, products, and people.

Mark D. Scott is a Senior Consultant with Microsoft Consulting Services. He works closely with clients to help design and build large-scale, data-centric applications. You can reach Mark at granddaddy2002@msn.com or mascott@microsoft.com.


Field Notes Mark{IT}ing: Synergy in the Shadows
Romi Mahajan

Marketers and IT folks fundamentally need each other. At the surface this might seem far-fetched, flying in the face of canonical wisdom. In attempts to counter this proposition, skeptics will no doubt trot out evidence of "different cultures" and "different goals." Downright naysayers will point to antagonism between these two groups and will certainly have testimonial evidence to buoy their arguments. More benignly, many will simply argue that the concept is too abstract and, as such, holds no particular promise for further analysis.
I am willing to concede 25% of each of these arguments as long as their proponents concede that the cultural differences and perceived antagonism can at least theoretically be rendered irrelevant if the groups find common cause. I will argue, further, that whatever differences might exist can continue but will be seen as surface phenomena and not reflective of structural or innate divisions.
The argument has three planks. First, that IT and marketing have common goals. Second, that the "external perceptions" of both groups are very similar. Third, that companies that strive to align the two will enjoy comparative advantage as untapped potential turns into kinetic success.
Common Goals
The last 10 years has seen a fundamental shift in the discussion of the "goals" of both IT and marketing, thereby further aligning them. In each case, both areas of endeavor are support functions enabling the core process of making money that all capitalist institutions elevate to the position of primacy. Each "department" is called upon to create value against the backdrop of an elusive ROI calculus. Each is measured by the perception of what "renders" to the process of production and sales. The fundamental "architecture" of IT and marketing is governed through a flow of communications that IT largely enables. Marketers are asked to "run campaigns," and their IT brethren are asked to "complete projects," and both sets of people work against the triple constraints of time, people, and financial resources.
It would be disingenuous to overstate the commonality of goals. They certainly appear different—that is they are rendered in a different lexicon. The manifest "product" of labor is both tactically and tactilely different. But these are surface attributes that dishonor the fundamental similarity of the core essences of each area.
External Perceptions
I challenge anyone to find either an IT person or a marketer who hasn't been publicly or privately lambasted for being a "cost center." I issue the same needle-in-haystack challenge to find someone from one of these groups who hasn't had to justify his existence in at times demeaning ways.
Neither group has crisply defined native measures of success. As such, both are easy scapegoats for corporate underperformance.
While "marketing" is perceived by some to be glamorous, marketers will be the first to say that they are always in a precarious position, in virtually any corporation. IT, while less glamorous to most, is in the same place. Both, however, enable the potential of success, IT through providing the ability to amplify the processes of communication, production, and measurement and marketing through the ability to provide the narrative that connects companies and their products to those who would buy them.
Need for Alignment
Rapid response to markets, trends, buying patterns, demographic shifts, and a whole host of "dynamic events" is a sine qua non for success in any environment of "creative destruction." Only marketing—the central vector for input and the central purveyor of output—can anticipate (or acknowledge) these trends, and only IT can facilitate and scale a company's response to them.
Comparative advantage is rendered through this alignment insofar as the ability to execute without direction is just as useless as deep nuanced knowledge with no edifice for action.
In my experience, IT folks sanctimoniously bristle at the perceived "extravagance" of marketers and marketers project disdain for IT folks' perceived lack of communication skills. Both positions are unfortunate. Both groups of people have to make a common cause, to align even where alignment seems unnatural or might, frankly, take a lot of work.
Corporate executives need to enable this alignment with appropriate incentives. In the absence of this, the potential that could be will go unrealized and the synergies will stay in the shadows.

Romi Mahajan is Chief Marketing Officer of Ascentium Corporation. Before joining Ascentium, he spent more than seven years at Microsoft, where his last role was as Director of Technical Audience and Platform Marketing. Romi is widely published in the areas of technology, politics, economics, and sociology.


Windows Confidential Keep Your Caches Close
Raymond Chen

Caches can improve performance, but you have to use them correctly. There are usually a lot of parameters you can fiddle with, but even if your cache's policies are tuned correctly, you still have to use the cache correctly.
Here's an example based on actual events. I've transposed the scenario into something readers will more readily understand so I don't have to go on about the details of a technology that's irrelevant to the underlying issue.
Suppose a New York-based company has a central Web server that functions as a document archive. The company can make requests such as "Give me the Petition for Dismissal from the Johnson case that we filed on June 23, 2005." This is effectively a static Web page since that document never changes—if the petition needs to be updated, an amendment is filed while the original document remains unchanged because, well, they already filed it. To change the original petition they'd need a time machine to go back in time. (And while they're at it, they'd accidentally change the course of human history through some seemingly insignificant action.)
This usage pattern maps well to a caching Web proxy server. If somebody asks for the June 23 Petition and then a short time later somebody else asks for the same document, the proxy server can respond to the second query and provide the same results as the first query, saving a round-trip to the central server.
This particular organization already had a caching Web proxy server and configured the Miami office to take advantage of it. But they found no performance improvement. Even when requesting the same document several times in a row from the proxy, the response was just as slow as requesting the document directly from the central server. What went wrong? Was the proxy server broken?
The proxy server was, in fact, working just fine. The problem was where the proxy server was located: the Miami office had a slow connection to New York and was using the caching Web proxy that was installed at the New York office.
The diagram in Figure 1 makes it pretty clear why the proxy didn't speed up anything. Even if the proxy did a perfect job and every request could be filled without going to the central server, the documents still had to be transferred over the slow connection between Miami and New York.
Figure 1 Proxy server on the wrong side of a slow connection
If you're going to use a cache, the cache needs to be faster than the thing it's caching. In this example, the connection from the Miami office to the proxy server needs to be faster than the connection from the Miami office to the central server. The proxy server needs to be installed closer to the Miami office. For the best results, the proxy server should be installed in Miami, as shown in Figure 2.
Figure 2 A far more useful proxy setup for the Miami office
With the proxy server located in Miami, when an attorney in Miami wants to call up the June 23 Petition, the request will go to the local proxy, which will quickly hand over the document from its cache. If the document isn't already in the cache, the document will be retrieved from the server and then cached for the next time someone in the Miami office requests it.
Caches take advantage of temporal locality, but moving the proxy to the Miami office also exploits geographic locality: the attorneys in the Miami office tend to request different documents than the attorneys in the New York office (since, of course, they handle different cases), and keeping a different cache for each remote office allows each one to serve its assigned office better.
The organization installed a proxy server in the Miami office and configured the computers in that office to use the local proxy. Now they're happy with the performance.

Raymond Chen's Web site, The Old New Thing, and his identically titled book (Addison-Wesley, 2007) both deal with Windows history and Win32 programming. Some club soda will get that stain out.