July 2009
Identity and Access Management: Managing Active Directory Users with ILM 2007
Microsoft Identity Lifecycle Manager 2007 enables administrators to manage the multiple digital identities inherent in enterprises today, and to keep users, computers, and other directory objects in sync among diverse directories and databases. This article introduces the key concepts of ILM. John McGlinchey
User Account Control: Inside Windows 7 User Account Control
User Account Control is a set of technologies that has one overall goal: to make it possible for users to run as standard users. In this article, Mark Russinovich explains how the default Windows 7 UAC mode makes a PA user’s experience smoother by reducing prompts, allows them to control what legitimate software can modify their system, and still enables more software to run without administrative rights and continues to shift the software ecosystem to write software that works with standard user rights. Mark Russinovich
SQL Server: Understanding SQL Server Backups
In most situations, database backups are critical for recovering from a disaster, but there are lots of misconceptions about how backups work and what a good backup strategy is. In this article, the fi rst in a three-part series on disaster recovery, Paul S. Randal explains how the three most common types of backups work and how you can combine them into an effective backup strategy. Paul S. Randal
Columns
From the Editor: Identification Synchronization: | Toolbox: New Products for IT Pros: Greg Steen highlights new tools and utilities for the IT Professional.Greg Steen | Exchange Queue & A: New Features and Improvements in Exchange Server 2010: Are there new high-availability features in Exchange 2010? Is administration any easier? Has the Extensible Storage Engine been replaced? And what’s new with Outlook Web Access? Henrik Walther answers these questions and more.Henrik Walther
Utility Spotlight: Exchange Server Remote Connectivity Analyzer: Trying and failing to connect to Exchange Server often leaves you with no hint as to the nature of the problem. Now the Microsoft Exchange Server Remote Connectivity Analyzer can help IT administrators figure out the causes of the connectivity failures and, in many cases, provide suggested steps for resolution.Brad Hughes | Inside SharePoint: SharePoint Security Hardening: SharePoint security hardening requires an end-to-end approach that addresses the full spectrum of security dependencies and risks within and across server farms. Pav Cherny discusses how deploying NAP with IPsec enforcement is an effective way to harden your SharePoint infrastructure.Pav Cherny | Windows PowerShell: What Not to Script: Don Jones shares his top six common suggestions to improve Windows PowerShell scripts.Don Jones
Geek of all Trades: Setting Permissions from the Command Line: Greg Shields explains why setting and managing file permissions from the command line, though initially complex, can provide great benefits, and he describes two free tools to help you do this.Greg Shields | Hey, Scripting Guy!: Back Up Your Event Logs with a Windows PowerShell Script: The Microsoft Scripting Guys create a Windows PowerShell script that provides an easy way to back up, archive, and clear your event log files.The Microsoft Scripting Guys | Desktop Files: Sharing and Synchronizing Your Files: If you are searching for a way to be able to access to files from anywhere, and to share and synchronize those files easily, there are a growing number of potential solutions, as this column describes.Wes Miller
Security Watch: Thoughts on Identity, Part 2: | The Cable Guy: Support for IPv6 in Windows Server 2008 R2 and Windows 7: Windows Server 2008 R2 and Windows 7 offer new features that support IPv6 for local and remote connectivity and for simplified management of host settings, as Joseph Davies explains.Joseph Davies | Business of IT: Controlling the Business Value Debate: When questioned about the business value of IT, IT professionals must not cede the debate to the questioner. Instead of directly responding, they should choose an approach that reveals both the invalidity of the question and the virtues of IT.Romi Mahajan
Windows Confidential: Cached Credentials: Depending on your point of view, cached credentials can be both a blessing and a curse. Raymond Chen explains how they work and how you can control them.Raymond Chen


Identity and Access Management
Managing Active Directory Users with ILM 2007
John McGlinchey
At a Glance:
  • Understanding the elements of ILM 2007
  • Provisioning and deprovisioning
  • Building a rules extension for import and export
  • Using run profiles to implement changes

Contents
What Is ILM?
ILM Elements
Provisioning and Deprovisioning
Import and Export Extensions
Run Profiles
The Future
Microsoft Identity Lifecycle Manager (ILM) 2007 is a key tool that enables enterprise administrators to keep users, computers, and other directory objects in sync among diverse directories and databases. Users, computers, groups, and even the OU structure of Active Directory can be integrated with LDAP, SQL Server, and other databases. Attributes can be taken from different sources, merged into an authoritative identity, and provided back to all data sources. With ILM, an enterprise need not design a single authoritative basis for identity but can instead integrate a mesh of diverse data sources with a tailored set of rules that can mimic the processes and procedures of that enterprise.
Some of the most common ILM usage scenarios include synchronizing multiple Active Directories, updating a common Exchange Global Address List (GAL) using multiple Active Directory domains or forests, and synchronizing accounts between LDAP implementations or between LDAP and Active Directory. I have also used ILM to migrate from one or more Active Directories to a new domain in a new forest and for operating system and application provisioning using System Center Configuration Manager (SCCM).
The key concepts and methods of ILM can be an uphill learning experience for infrastructure-oriented administrators with limited development know-how. Not only do you need to know something about ILM and developing ILM extension code, you also need to understand the connected data sources like Active Directory, Exchange, LDAP, SQL Server, and so on. This sort of complexity needs to be broken into small, consumable pieces, which is what I will try to do in this article.

What Is ILM?
ILM 2007 combines Identity Management and Certificate Management that together provide key elements of the Identity and Access Management (IDA) model. The identity management part of ILM was previously known as MIIS (Microsoft Identity Integration Server) and, before that, MMS (Microsoft Meta-Directory Server). (The certificate management part, where the lifecycle of certificates and smart cards are managed, won't be covered in this article, but it can be integrated with the identity management). While identity management may have had an identity crisis of its own, it doesn't have a problem managing your identities.
A key feature of IDA with ILM is its extensibility. If there isn't a simple, clickable way to do something, you can write code to extend the functionality of ILM. Though some simple ILM implementations don't need any code at all, most need to do some sort of provisioning of either user accounts or groups, so you're probably destined to write some code. Don't worry, though. ILM provisioning code is pretty straightforward once you have the key concepts down and understand when and how your code plays into the big picture of IDA.

ILM Elements
As with any complex undertaking, you need to understand the important concepts before diving in.
The Metaverse and Connected Directories The metaverse (MV) is simply a database. It's a pretty complex database, but still just a database. ILM uses the MV to store the configuration of all the connected directories (CDs) that import data into or export data out from the MV. Be warned—do not dig into the MV database. And never mess with it. Do not try to run reports directly from the MV database or change anything in it. You will just end up corrupting it. (I speak here from experience.)
Management Agents Management Agents (MAs) are the tools you use to define CDs. You create a rule for importing and exporting data into the MV from a CD using the MA import and export rules. This rule also defines which MA contributes which attribute and how data is purged from the MV once it disappears from all CDs. TechNet has downloadable scenario documents and rule sets that you can use to get started quickly once you understand how it all works. Once you've mastered simple scenarios, then more complex solutions that involve many data sources, complex data manipulations, and detailed rules can be implemented using ILM.
MAs can filter out data from the CD that isn't needed in order to make the connection more efficient. For example, you may not need to scan every OU in an Active Directory. Selecting only the necessary OUs can make scanning for changed or new objects much faster. In a connected SQL Server database, filtering out unnecessary data can save a lot of time when processing import rules (although an even more efficient method is to use a SQL Server view to provide only the necessary data to the MA in the first place).
Connector Space, Importing, and Exporting Each MA connects the MV through a unique connector space (CS) that mirrors the data elements of the CD. Data is then moved to or from the CS to the MV based on the import and export rules. Creating a new object in a connected directory is a simple matter of creating a connector in the CS for that CD and then exporting that object to the CD.
The example in Figure 1 shows an MA connected to an Active Directory. This is the easiest and most common MA that can be configured. Figure 2 shows the attributes that are flowing into and out of the MV. The arrows define the direction of data flow. Note that not all the attributes are selected, only the ones that are deemed necessary to implement the data flow model. The data is flowed as-is with no changes unless there is an import or export extension.
Figure 1 A management agent connects ILM to a connected directory, in this case, an Active Directory, with the ability to select specific organizational units.
Figure 2 The attribute flow defines how each attribute will import into and export out of ILM.
During attribute flows, you may come across an attribute that is being imported from multiple CDs. If the attribute occurs in more than one CD, you may need to decide which CD will contribute the attribute. This is called attribute precedence.

Joining and Projecting Joining means connecting an entry in a connector space to an existing MV object. The criteria for the join rule are totally up to you. If you are joining users from a database into the MV, you might use employee numbers or some combination of names and numbers. You need to use something that makes a unique connection between the CD and the MV within the CS. Remember that the join criteria must be unique or the join rule will cause an error. That said, ILM is totally extensible and if you wanted to, you could write code to decide which of the non-unique entries to join.
Projecting means pushing data into the MV from a Connected Directory's Connected Space. To do this, you need to create a projection rule (see Figure 3), which involves just a few clicks of the mouse. Provisioning, which we'll get to in a minute, means to push data into the CS of a CD from the MV, and this definitely involves more than a few mouse clicks. Think of it this way: you "project into" the MV and you "provision out" of the MV. You can project without writing code, but to provision, you will have to write some code. That's not to say you can't implement a data flow that doesn't do any provisioning. If all of your objects exist already and you just want to make sure the attributes stay in sync, you might not need any code. Just configure all the import and export data flows and join rules and you're nearly good to go.
Figure 3 Join and projection rules are used to define how objects are associated with or created in ILM.
An MA can have multiple join rules, each with multiple join criteria, but there can only be one projection rule.

Provisioning and Deprovisioning
The code in Figure 4 shows an example of what you need to provision a new user in Active Directory. How did we figure out that we needed to create a new user? In this particular case, we got the information from an H/R system, but it could just as well have come from something as simple as a spreadsheet or text file with new users' information and an MA set up to import those users into the MV. ILM is very flexible and can import data from a variety of sources. For now, let's stick to Active Directory. The example code used here is derived from MIIS 2003 Scenarios available for download from "Microsoft® Identity Integration Server 2003 Scenarios."
Figure 4 Provisioning New Objects in Connected Directories
''   Copyright (c) Microsoft Corporation.  All rights reserved.

Imports Microsoft.MetadirectoryServices
Imports System.Xml

Public Class MVProvision
    Implements IMVSynchronization

    '
    ' These two variables are initialized based on a xml configuration file
    ' The values are read during the Initialize() method of the Rules Extension
    '
    Dim fabrikamUsersContainer As String
    Dim fabrikamDisabledUsersContainer As String

    '
    ' Number of retries on name conflict
    '
    Private Const RETRY_NUM_LIMIT = 1000

    Public Sub Provision( _
        ByVal mventry As MVEntry) _
        Implements IMVSynchronization.Provision

        Dim employeeStatus As String
        Dim ADMA As ConnectedMA
        Dim dn As ReferenceValue
        Dim container As String
        Dim rdn As String
        Dim myConnector As CSEntry
        Dim csentry As CSEntry
        Dim numADConnectors As Integer
        Dim successful As Boolean = False
        Dim cnForObject As String
        Dim numberToAppend As Integer = 1

        If Not mventry.ObjectType.Equals("person") Then
            Exit Sub
        End If

        If Not mventry("cn").IsPresent Then
            Throw New UnexpectedDataException("cn does not exist on MV bject")
        End If

        ADMA = mventry.ConnectedMAs("ADMA")
        '
        ' Get the cn attribute from MV which will be used to configure CS dn
        '
        cnForObject = mventry("cn").Value.ToString()

        '
        ' Based on the value of "employeeStatus" determine the container in AD
        '
        employeeStatus = mventry("employeeStatus").Value.ToLower
        Select Case employeeStatus
            Case "active"
                container = UsersContainer
            Case "inactive"
                container = DisabledUsersContainer
            Case Else
                '
                ' employeeStatus must be active or inactive to be valid
                ' any other case is an error condition for this object.
                ' Throw an exception to abort this object's synchronization.
                '
                Throw New UnexpectedDataException("employeeStatus=" + employeeStatus.ToString)
        End Select

        Do
            Try

                ' Based on the value of "cn" determine the RDN in AD
                rdn = "CN=" & cnForObject

                ' Now construct the DN based on RDN and Container
                dn = ADMA.EscapeDNComponent(rdn).Concat(container)

                '
                ' If there is no connector present, add a new AD connector
                ' and call a subroutine to set the initial values on the CS Object
                '
                numADConnectors = ADMA.Connectors.Count
                If 0 = numADConnectors Then

                    csentry = ADMA.Connectors.StartNewConnector("user")
                    csentry.DN = dn
                    SetInitialValues(csentry, mventry)
                    csentry.CommitNewConnector()
                ElseIf 1 = numADConnectors Then
                    '
                    ' check if the connector has a different DN and rename if necessary
                    ' First get the connector
                    '
                    myConnector = ADMA.Connectors.ByIndex(0)

                    '
                    ' MMS will rename/move if different, if not nothing will happen
                    '
                    myConnector.DN = dn
                Else
                    Throw New UnexpectedDataException("multiple AD connectors:" +
                      numADConnectors.ToString)
                End If

                successful = True

            Catch ex As ObjectAlreadyExistsException

                '
                ' There is a duplicate object in the target AD,
                ' change the cn accordingly to avoid conflict
                '
                cnForObject = mventry("cn").Value & " (" _
                                & numberToAppend.ToString & ")"
                numberToAppend = numberToAppend + 1

                If numberToAppend > RETRY_NUM_LIMIT Then
                    Throw New UnexpectedDataException( _
                        "Retry for " & mventry("cn").Value _
                        & " exceeds limit " & numberToAppend.ToString)
                End If

            Finally ' Add cleanup code in the Finally section

            End Try

        Loop While Not successful

    End Sub
    ' Set Values on a NEW provisioned CS Entry
    Private Sub SetInitialValues( _
    ByRef csentry As CSEntry, _
    ByVal mventry As MVEntry)

        csentry("unicodepwd").Values.Add(mventry("employeeID").Value)

    End Sub

    Public Function ShouldDeleteFromMV( _
        ByVal csentry As CSEntry, _
        ByVal mventry As MVEntry) _
        As Boolean Implements IMVSynchronization.ShouldDeleteFromMV

        Throw New EntryPointNotImplementedException
    End Function

    Public Sub Initialize() Implements IMVSynchronization.Initialize

        Const SCENARIO_XML_CONFIG = "\simpleprov.xml"

        Dim config As XmlDocument = New XmlDocument
        Dim dir As String = Utils.ExtensionsDirectory()
        config.Load(dir + SCENARIO_XML_CONFIG)

        Dim rnode As XmlNode = config.SelectSingleNode(
           "rules-extension-properties/account-provisioning/container")
        Dim node As XmlNode = rnode.SelectSingleNode("root")
        Dim rootContainer As String = node.InnerText

        node = rnode.SelectSingleNode("enabled-users")
        UsersContainer = node.InnerText + "," + rootContainer

        node = rnode.SelectSingleNode("disabled-users")
        DisabledUsersContainer = node.InnerText + "," + rootContainer

    End Sub

    Public Sub Terminate() Implements IMVSynchronization.Terminate
    End Sub
End Class
In essence, the code checks to see if a user already exists. If the user doesn't exist, a new connector is created for the user, as shown in Figure 5. If the user does exist, there would already be a connector from Active Directory in the CS, meaning that ILM does not need to query Active Directory itself, just the CS of the MA that connects to Active Directory. The export rule defines the data that is going to flow to Active Directory, so the provisioning code need only create the connector and let the flow rules do the rest. One thing to remember, if you do push data within provisioning code, that data is pushed only when the connector is created, not on every sync cycle as with data flow set up using the flow rules.
Figure 5 Creating a New Connector
'
                ' If there is no connector present, add a new AD connector
                ' and call a subroutine to set the initial values on the CS Object
                '
                numADConnectors = ADMA.Connectors.Count
                If 0 = numADConnectors Then

                    csentry = ADMA.Connectors.StartNewConnector("user")
                    csentry.DN = dn
                    SetInitialValues(csentry, mventry)
                    csentry.CommitNewConnector()

                ElseIf 1 = numADConnectors Then
                    '
                    ' check if the connector has a different DN and rename if necesarry
                    ' First get the connector
                    '
                    myConnector = ADMA.Connectors.ByIndex(0)

                    '
                    ' MMS will rename/move if different, if not nothing will happen
                    '
                    myConnector.DN = dn
                Else
                    Throw New UnexpectedDataException("multiple AD connectors:" +
                      numADConnectors.ToString)
                End If

                successful = True
To configure provisioning, you will have to take your provisioning code and use Visual Studio to build it into a DLL. The name you give to the DLL doesn't much matter, but you need to put the DLL into the extensions folder where ILM is installed and then use its name to configure provisioning. One thing to remember is that provisioning happens on the MV, not on the individual MAs. The code runs whenever an MA trips over something that needs to be provisioned, but provisioning is not part of the MA configuration; it is part of the overall ILM Identity Manager configuration, as shown in Figure 6. One good troubleshooting step when experiencing errors during MA runs is to temporarily disable provisioning, thereby isolating the testing to just the import and export rules and not your provisioning code. Once you confirm that your import and export rules are working, then you can start troubleshooting your provisioning code to find the problem.
Figure 6 Using a Custom Rules Extension to Define Provisioning
Deprovisioning is the process of disconnecting an object from the MV. There are three choices for specifying an object's status:
  1. Making an object a "disconnector" means that the object is no longer joined, but it is not removed from the CD. If it is not filtered out, it may well be end up right back in the CS on the next import.
  2. Making an object an "explicit disconnector" similarly means the object is no longer joined and is not removed from the CD, but in this case it is also marked to not be reimported.
  3. Deleting the object from the CD means exactly that. The object will be deleted from both the CS and CD on the next export run.
Be very careful with your deprovisioning choices as this can be a major headache if not done properly and, even worse, you may destroy data by selecting the wrong option. Always do your testing in a lab environment with good backups.

Import and Export Extensions
At some point, you will probably find the need to do something with CD data while importing or exporting, like merging multiple attributes together to form a full name or connecting username with domain name to form an e-mail address. When this happens, it's time to start building a rules extension, which is essentially code that enables complex changes. On import, a rules extension means you can take multiple CD attributes as input to a single MV attribute. On export, it means you can bring multiple MV attribute into a single CD attribute. Note that the common element here is that the source of the data flow can use multiple attributes but the target of the data flow must be a single attribute. Again, this is pretty simple as far as code goes, and the resulting DLL will need to be placed into the extensions folder. You then use that name in defining your rules extension within the MA configuration (see Figure 7) as well as within the code to define the rule that gets implemented.
Figure 7 Custom attribute flow rules extensions can be written for complex attribute fl ows.

Run Profiles
Once you have MAs set up to import and export data, you have to tell ILM to run an import, an export, or a synchronization. To do this, you set up a run profile for each of these operations within the MA configuration and then run one of them at a time to get the data to move through the proper steps from CD to CV to MV and then from MV to CV to CD (see Figure 8).
Figure 8Data flows from connected directories to the metaverse through the connector space and back out again.
The operations can be either full, which inspects everything, or delta, which inspects only those objects that have been changed. So for a full import, ILM will inspect every object in the connected directory and import everything into the connector space. A full export does the reverse, from CS to CD. A full sync will sync every object in the MV to every connected object, while a delta sync syncs only the changed objects. When enabled, provisioning gets triggered during the sync and decides if new connectors are needed in a connected directory by inspecting the CS for that CD.
To run a profile, you right-click on an MA, select Run, and then choose a profile. Multiple steps can be combined into a single profile. For example, I typically set up a "Full Import & Full Sync" profile on every MA as well as "Delta Import & Delta Sync" and "Export" profiles. Profiles can also be run from command files using a tool called runMA.vbs, available for free download in the Scenarios mentioned earlier.
ILM MA profiles are typically run sequentially from a batch script within the Windows Scheduler Service. Yes, it seems like a throwback, but though things will probably change in the future, for now you should just build a simple script to run your MAs using runMA. Most directory data doesn't change in real time anyway. Use the task scheduler on the ILM server to run this script as often as you need to keep things up to date. Remember that MAs may need to be run in a specific order based on your data sync model and can have a significant impact on network utilization, so balance the need for data synchronization with the possibly conflicting need for a minimal impact on the network.

The Future
ILM will be getting an upgrade in the near future that will bring a new, Web-based interface, workflow integration, provisioning using a Web-based UI—and another name change. ILM is being adopted into the Forefront family of security and access management products and will soon be known as Forefront Identity Manager (FIM) 2010. Look for articles here on FIM 2010 as it gets closer to release to see how you can apply the lessons learned in this article to the next level of Identity and Access Management.

John McGlinchey, MCP, MCSA, MCSE is a Senior Consultant for Microsoft Consulting Services based in the Philadelphia, PA area, focusing on Identity and Access Management. John has more than 30 years of experience in the computer industry, including more than 20 years of consulting experience. He blogs at blogs.technet.com/johnmcg/, and he is one of the IDAGUYS at blogs.technet.com/idaguys/ who regularly blog about IDA topics. Go figure.


User Account Control
Inside Windows 7 User Account Control
Mark Russinovich
At a Glance:
  • Standard user accounts
  • User account control

Contents
UAC Technologies
Elevations and Malware Security
What's Different in Windows 7
Auto-Elevation
Auto-Elevation and UAC's Goals
Standard user accounts provide for better security and lower total cost of ownership in both home and corporate environments. When users run with standard user rights instead of administrative rights, the security configuration of the system, including antivirus and firewall, is protected. This provides users a secure area that can protect their account and the rest of the system. For enterprise deployments, the policies set by desktop IT managers cannot be overridden, and on a shared family computer, different user accounts are protected from changes made by other accounts.
However, Windows has had a long history of users running with administrative rights. As a result, software has often been developed to run in administrative accounts and take dependencies, often unintentionally, on administrative rights. To both enable more software to run with standard user rights and to help developers write applications that run correctly with standard user rights, Windows Vista introduced User Account Control (UAC). UAC is a collection of technologies that include file system and registry virtualization, the Protected Administrator (PA) account, UAC elevation prompts, and Windows Integrity levels that support these goals. I've talked about these in detail in my conference presentations and TechNet Magazine UAC internals article.
Windows 7 carries forward UAC's goals with the underlying technologies relatively unchanged. However, it does introduce two new modes that UAC's PA account can operate with and an auto-elevation mechanism for some built-in Windows components. In this post, I'll cover the motivations behind UAC's technologies, revisit the relationship between UAC and security, describe the two new modes, and explain how exactly auto-elevation works. Note that the information in this post reflects the behavior of the Windows 7 release candidate, which is different in several ways from the beta.

UAC Technologies
The most basic element and direct benefit of UAC's technology is simply making Windows more standard-user friendly. The showcase example is the difference between the privilege requirements of setting the time zone on Windows XP and Windows Vista. On Windows XP, changing the time zone—actually, even looking at the time zone with the time/date control panel applet—requires administrative rights.
That's because Windows XP doesn't differentiate between changing the time, which is a security-sensitive system operation, from changing the time zone, which merely affects the way that time is displayed. In Windows Vista (and Windows 7), changing the time zone isn't an administrative operation and the time/date control panel applet separates administrative operations from the standard user operations. This change alone enables many enterprises to configure traveling users with standard user accounts, because users can adjust the time zone to reflect their current location. Windows 7 goes further, making things like refreshing the system's IP address, using Windows Update to install optional updates and drivers, changing the display DPI, and viewing the current firewall settings accessible to standard users.
File system and registry virtualization work behind the scenes to help many applications that inadvertently use administrative rights to run correctly without them. The most common unnecessary uses of administrative rights are the storage of application settings or user data in areas of the registry or file system that are for use by the system. Some legacy applications store their settings in the system-wide portion of the registry (HKEY_LOCAL_MACHINE\Software) instead of the per-user portion (HKEY_CURRENT_USER\Software), for example, and registry virtualization diverts attempts to write to the system location to one in HKEY_CURRENT_USER (HKCU) while preserving application compatibility.
The PA account was designed to encourage developers to write their applications to require only standard user rights while enabling as many applications that share state between administrative components and standard user components to continue working. By default, the first account on a Windows Vista or Windows 7 system, which was a full administrator account on previous versions of Windows, is a PA account. Any programs a PA user executes are run with standard-user rights unless the user explicitly elevates the application, which grants the application administrative rights. Elevation prompts are triggered by user activities such as installing applications and changing system settings. These elevation prompts are the most visible UAC technology, manifesting as a switch to a screen with an allow/cancel dialog and grayed snapshot of the desktop as the background.
Accounts created subsequent to the installation are standard user accounts by default that provide the ability to elevate via an "over the shoulder" prompt that asks for credentials of an administrative account that will be used to grant administrative rights. This facility enables a family member sharing a home computer or a more security-conscious user using a standard user account to run applications with administrative rights, provided they know the password to an administrative account, without having to manually switch to a different user logon session. Common examples of such applications include installers and parental control configuration.
When UAC is enabled, all user accounts—including administrative accounts—run with standard user rights. This means that application developers must consider the fact that their software won't have administrative rights by default. This should remind them to design their application to work with standard user rights. If the application or parts of its functionality require administrative rights, it can leverage the elevation mechanism to enable the user to unlock that functionality. Generally, application developers need to make only minor changes to their applications to work well with standard user rights. As the E7 blog post on UAC shows, UAC is successfully changing the way developers write software.
Elevation prompts also provide the benefit that they "notify" the user when software wants to make changes to the system, and it gives the user an opportunity to prevent it. For example, if a software package that the user doesn't trust or want to allow to modify the system asks for administrative rights, they can decline the prompt.

Elevations and Malware Security
The primary goal of UAC is to enable more users to run with standard user rights. However, one of UAC's technologies looks and smells like a security feature: the consent prompt. Many people believed that the fact that software has to ask the user to grant it administrative rights means that they can prevent malware from gaining administrative rights. Besides the visual implication that a prompt is a gateway to administrative rights for just the operation it describes, the switch to a different desktop for the elevation dialog and the use of the Windows Integrity Mechanism, including User Interface Privilege Isolation (UIPI), seem to reinforce that belief.
As we've stated since before the launch of Windows Vista, the primary purpose of elevation is not security, though, it's convenience: if users had to switch accounts to perform administrative operations, either by logging into or Fast User Switching to an administrative account, most users would switch once and not switch back. There would be no progress changing the environment that application developers design for. So what are the secure desktop and Windows Integrity Mechanism for?
The main reason for the switch to a different desktop for the prompt is that standard user software cannot "spoof" the elevation prompt, for example, by drawing on top of the publisher name on the dialog to fool a user into thinking that Microsoft or another software vendor is generating the prompt instead of them. The alternate desktop is called a "secure desktop," because it's owned by the system rather than the user, just like the desktop upon which the system displays the Windows logon dialog.
The use of another desktop also has an important application compatibility purpose: while built-in accessibility software, like the On Screen Keyboard, works well on a desktop that's running applications owned by different users, there is third-party software that does not. That software won't work properly when an elevation dialog, which is owned by the local system account, is displayed on the desktop owned by a user.
The Windows Integrity Mechanism and UIPI were designed to create a protective barrier around elevated applications. One of its original goals was to prevent software developers from taking shortcuts and leveraging already-elevated applications to accomplish administrative tasks. An application running with standard user rights cannot send synthetic mouse or keyboard inputs into an elevated application to make it do its bidding or inject code into an elevated application to perform administrative operations.
Windows Integrity Mechanism and UIPI were used in Windows Vista for Protected Mode Internet Explorer, which makes it more difficult for malware that infects a running instance of IE to modify user account settings, for example, to configure itself to start every time the user logs on. While it was an early design goal of Windows Vista to use elevations with the secure desktop, Windows Integrity Mechanism, and UIPI to create an impermeable barrier—called a security boundary—between software running with standard user rights and administrative rights, two reasons prevented that goal from being achieved, and it was subsequently dropped: usability and application compatibility.
Figure 1 Showing the executable fi le’s name.
First, consider the elevation dialog itself. It displays the name and publisher of the primary executable that will be granted administrative rights. Unfortunately, while greater numbers of software publishers are digitally signing their code, there are those that aren't, and there are many older applications that aren't signed. For software that isn't signed, the elevation dialog simply shows the executable's file name, which makes it possible for malware already running in a users account and that's watching for an elevation of an unsigned Setup.exe application installer, for example, to replace the executable with a malicious Setup.exe without the user being able to tell (see Figure 1).
Second, the dialog doesn't tell the user what DLLs the executable will load once it starts. If the executable resides in a directory under the user's control, malware running with the user's standard rights can replace any associated DLLs in the location that the software will use. Alternatively, malware could use side-by-side functionality to cause the executable to load malicious versions of application or system DLLs. And unless a user vigilantly clicks the details button and carefully looks at the file path listed for the elevating executable, malware can copy the executable to a similarly named location, for example, \ProgramFiles\Vendor\Application.exe (note the missing space in what should be "Program Files"), where it could control what DLLs the application loads. In Figure 2, I've copied a component of Microsoft Network Monitor to the user-created C:\ProgramFiles directory that's controllable by the user and launched it.
Figure 2 Launched copy of Microsoft Network Monitor component.
Finally, for application compatibility, elevated applications share substantial state with the standard user environment that a malicious application could use to influence the behavior of an elevated application. The clearest example of this is the user's registry profile, HKEY_CURRENT_USER (HKCU). That is shared because users expect settings and extensions they register as a standard user to work in elevated applications. Malware could use shell extensions registered in HKCU to load into elevated applications that use any of the shell browsing dialogs, like File Open and File Save. Other kinds of state are also shared, most notably the Base Named Object namespace, where applications create synchronization and shared memory objects. Malware could take advantage of that sharing to hijack a shared memory object used by an elevated application, for instance, to compromise the application and then the system.
As for the Windows Integrity Mechanism, its effectiveness as a barrier is limited by the elevation issues I've mentioned, but it also has limitations caused by application compatibility. For one, UIPI doesn't prevent standard user applications from drawing on the desktop, something that could be used to trick the user into interacting with elevated applications in a way that grants malware administrative rights. Windows Integrity Mechanism also doesn't flow across the network. A standard user application running in a PA account will have access to system resources on a remote system on which that PA account has administrative rights. Addressing these limitations has major application compatibility ramifications. That said, that we are continually looking at ways to improve system security, for instance, improving Protected Mode IE, while at the same time addressing application compatibility issues and working closely with software developers.
So, how much malware protection do you get when you run in a Windows Vista PA account with UAC enabled? First, remember that for any of this to matter, malware has to get onto the system and start executing in the first place. Windows has many defense-in-depth features, including Data Execution Prevention (DEP), Address Space Load Randomization (ASLR), Protected Mode IE, the IE 8 SmartScreen Filter, and Windows Defender that help prevent malware from getting on the system and running.
As for the case where malware somehow does manage to get on a system, because malware authors (like legitimate developers) have assumed users run with administrative rights, most malware will not function correctly. That alone could be considered a security benefit. However, malware that's gotten on a system and that's designed to exploit the opportunities might be able to gain administrative rights the first time the user elevates—but the malware doesn't even need to wait for a "real" elevation because it can precipitate one that would fool even the most security conscious users. I've demonstrated publicly how malware can hijack the elevation process in my UAC Internals and Windows Security Boundaries presentations (the demo is at minute 1:03 in the security boundaries talk). Remember, though, if malware does start running, it can accomplish most of the things that malware wants to do with just standard user rights, including configuring itself to run every time the user logs on, stealing or deleting all the user's data, or even becoming part of a botnet.

What's Different in Windows 7
I mentioned some of the operations in Windows 7 that can now be performed by standard users, but as the E7 blog post on UAC explains, we also recognized that we could make the Windows experience smoother without sacrificing UAC's goals. Many users complained about the fact that Windows Vista itself frequently asks for administrative rights when they perform common system management operations. It's in our best interest, because it's in the interest of our customers, to make Windows work well for standard user environments. However, elevation prompts don't educate or encourage us to do so, but they do force users to click a second time through a dialog that the vast majority of users don't read. Windows 7, therefore, set out to minimize those prompts from the default Windows experience and enable users that run as administrators to control their prompting experience.
To do that, we further refactored the system such that someone with standard user rights can execute more tasks, and we reduced the number of prompts in several multi-prompt scenarios (for example, installing an ActiveX control in IE). Windows 7 also introduces two new UAC operating modes that are selectable in a new UAC configuration dialog (see Figure 3). You can open the dialog by going to Control Panel, clicking User Accounts, clicking User Accounts, and then clicking Change User Account Control Settings. (You can also get to it by clicking on the Change When Notifications Appear link on an elevation prompt or by going through the Action Center.)
Figure 3 Two new UAC operating modes that are selectable in a new UAC configuration dialog.
The default setting, shown in Figure 3, is one of the new levels. Unlike Always Notify, which is the selection at the top of the slider and is identical to the default mode in Windows Vista, the Windows 7 default prompts the user only when a non-Windows executable asks for elevation; the behavior for non-Windows elevations is the same as it was for Windows Vista.
The next slider position down is the second new setting and has the same label except with "(do not dim my desktop)" appended to it. The only difference between that and the default mode is that prompts happen on the user's desktop rather than on the secure desktop. The upside of that is that the user can interact with the desktop while a prompt is active, but as I mentioned earlier, the risk is that third-party accessibility software might not work correctly on the prompt dialog.
Finally, the bottom slider position turns off UAC technologies altogether, so that all software running in a PA account runs with full administrative rights, file system and registry virtualization are disabled, and Protected Mode IE is disabled. While there are no prompts at this setting, the loss of Protected Mode IE is a significant disadvantage of this mode.

Auto-Elevation
The reason that elevation of (most) Windows executables in the two middle settings doesn't result in a prompt is that the system "auto elevates" Windows executables. First, what does Windows define as a Windows executable in this context? The answer depends on several factors, but two things must hold: it must be digitally signed by the Windows publisher, which is the certificate used to sign all code included with Windows (it's not sufficient to be signed by Microsoft, so Microsoft software that's not shipped in Windows isn't included); and it must be located in one of a handful of "secure" directories. A secure directory is one that standard users can't modify and they include %SystemRoot%\System32 (e.g., \Windows\System32) and most of its subdirectories, %SystemRoot%\Ehome, as well as a handful of directories under %ProgramFiles% that include Windows Defender and Windows Journal.
Also, depending on whether the executable is a normal .exe, Mmc.exe, or a COM object, auto-elevation has additional rules. Windows executables (as just defined) of the .exe variety auto-elevate if they specify the autoElevate property in their manifest, which is also where applications indicate to UAC that they want administrative rights. Here's the Sysinternals Sigcheck utility dumping the manifest for Task Manager (Taskmgr.exe) with the command "sigcheck –m %systemroot%\system32\taskmgr.exe", which shows that Task Manager is opted in for auto-elevation, as shown in Figure 4.
Figure 4 The autoElevate Property
An easy way to find auto-elevate executables in a directory tree is to use the Sysinternals Strings utility with a command like this:
strings –s *.exe | findstr /i autoelevate
There is also a hardcoded list of Windows executables that get the auto-elevate treatment. These Windows executables also ship external to Windows 7 and so must be able to run on down-level systems where the presence of the autoexecute property would result in an error. The list includes Migwiz.exe, the migration wizard, Pkgmgr.exe, the package manager, and Spinstall.exe, the Service Pack installer.
The Microsoft Management Console, Mmc.exe, gets special treatment since it hosts many of the system management snap-ins, which are implemented as DLLs. Mmc.exe launches with a command line that specifies a .MSC file that lists the snap-ins MMC is to load. When Windows sees Mmc.exe ask for administrative rights, which it does when launched from a PA account, it validates that Mmc.exe is a Windows executable and then checks the .MSC. To be eligible for auto-elevation, the .MSC file must satisfy the Windows executable criteria (signed by Windows in a secure location) and it must be listed on an internal list of auto-elevate .MSCs. That list includes virtually all the .MSC files shipped with Windows.
Finally, COM objects can specify the need for administrative rights with a registry value in their registry key by creating a subkey named Elevation with a value named Enabled that is set to 1. Figure 5 shows the registry key for the shell's Copy/Move/Rename/Delete/Link Object that Explorer uses when a user performs a file system operation on a location their account doesn't have permissions for.
Figure 5 Shell Registry Key
For a COM object to be auto-elevated, it must also be a Windows executable and it must have been instantiated by a Windows executable. (The instantiating executable doesn't need to be marked for auto-elevation, though.) When you use Explorer to create a directory in the %ProgramFiles% directory from a PA account, for instance, the operation will auto-elevate because the COM object requests elevation, the object's DLL is a Windows executable, and Explorer is a Windows executable.

Auto-Elevation and UAC's Goals
So what's behind all the special auto-elevation rules? Choosing what to auto-elevate and what not to was guided by the question, "Can an application developer inadvertently or trivially depend on administrative rights by leveraging auto-elevate?" Since Cmd.exe can be used to execute batch scripts via command-line arguments and average users have no need to run command prompts elevated (most don't even know what a command prompt is), it was not manifested for auto-elevation. Similarly, Rundll32.exe, the executable that hosts control panel plug-ins, doesn't auto-elevate in the final release of Windows 7 because its elevation isn't required for any common management tasks, and if it auto-elevated, its ability to host arbitrary DLLs via its command-line could cause a developer to require administrator rights without realizing it.
End users have been asking for Windows to provide a way to add arbitrary applications to the auto-elevate list since the Windows Vista beta. The commonly cited reason is that some third-party application they frequently use forces them to constantly click through an elevation prompt as part of their daily routine. Windows 7, just like Windows Vista, doesn't provide such a capability. We understand the aggravation, and there might be a legitimate reason that those applications can't run without administrative rights, but the risk is too high that developers will avoid fixing their code to work with standard user rights. Even if the list of what applications get auto-elevated was only accessible by administrators, developers might simply change their application setup program, which requires a one-time elevation, to add their application to the list. We've instead chosen to invest in educating and working closely with application developers to ensure their programs work correctly as a standard user.
Several people have observed that it's possible for third-party software running in a PA account with standard user rights to take advantage of auto-elevation to gain administrative rights. For example, the software can use the WriteProcessMemory API to inject code into Explorer and the CreateRemoteThread API to execute that code, a technique called DLL injection. Since the code is executing in Explorer, which is a Windows executable, it can leverage the COM objects that auto-elevate, like the Copy/Move/Rename/Delete/Link Object, to modify system registry keys or directories and give the software administrative rights. While true, these steps require deliberate intent, aren't trivial, and therefore are not something we believe legitimate developers would opt for versus fixing their software to run with standard user rights. In fact, we recommend against any application developer taking a dependency on the elevation behavior in the system and that application developers test their software running in standard user mode.
The follow-up observation is that malware could gain administrative rights using the same techniques. Again, this is true, but as I pointed out earlier, malware can compromise the system via prompted elevations as well. From the perspective of malware, Windows 7's default mode is no more or less secure than the Always Notify mode ("Vista mode"), and malware that assumes administrative rights will still break when run in Windows 7's default mode.

Conclusion
To summarize, UAC is a set of technologies that has one overall goal: to make it possible for users to run as standard users. The combination of changes to Windows that enable standard users to perform more operations that previously required administrative rights, file and registry virtualization, and prompts all work together to realize this goal. The bottom line is that the default Windows 7 UAC mode makes a PA user’s experience smoother by reducing prompts, allows them to control what legitimate software can modify their system, and still accomplishes UAC’s goals of enabling more software to run without administrative rights and continuing to shift the software ecosystem to write software that works with standard user rights.

Mark Russinovich is a Technical Fellow at Microsoft in the Platform and Services Division.


SQL Server
Understanding SQL Server Backups
Paul S. Randal
At a Glance:
  • Full backups
  • Transaction log backups
  • Differential backups
  • Backup strategy planning and backup integrity

Contents
Full Backups
Differential Backups
Transaction Log Backups
Backup Strategy Planning
Backup Integrity
Summary
Do you really need to take SQL Server backups? Yes. Unless you don't care about your data or you don't mind having to completely recreate your database in the event of a disaster, you need some way of restoring the database to a usable point. Some people argue that having a redundant copy of the database somewhere else removes the need for having backups, but what if that copy is damaged or inaccessible? Backups are still required to make sure you can always recover.
But what kind of backups should you take? How often should you take them? What effect will they have on the database and workload? And how do you make sure they are valid?
Putting together a backup strategy is actually easier than you may think, even though the BACKUP and RESTORE commands have a plethora of options. And I'll help you figure it all out.
This is the first article in a three-part series. Here in Part 1, I cover backups. In Part 2 (September 2009 issue), I will discuss recovering from a disaster using backups. And in Part 3 (November 2009 issue), I'll look at recovering from a disaster without backups. I'm going to go a little deeper than usual in these articles, but you should be able to follow along with the help of the background material.
In this month's article, I'll explain the basics of how the various types of backup work and how you may want to use them in a backup strategy. It will help if you have some knowledge of how the transaction log works (see my article "Understanding Logging and Recovery in SQL Server." There's no point in having backups if they turn out to be corrupt when you try to use them, so I'll also explain how to add some integrity checks to them. Along the way I'll debunk some of the common misconceptions and provide links to further information.
One thing I'm not going to do is explain how the BACKUP syntax works and how to perform the various backup types. SQL Server Books Online has excellent sections that cover this so why waste space duplicating it here? See the topic "Backup (Transact-SQL)" for more info, especially the Examples section at the end. The topic "Backing Up and Restoring How-to Topics (SQL Server Management Studio)" explains how to use the tools to perform backups. It's best to review the how-to after reading this article, as here I'm going to explain the what and the why.
The implementation of your backup strategy is the relatively easy part. Designing an effective strategy is the very important, though often overlooked, part.

Full Backups
The simplest kind of backup is a full database backup. It's also possible to do a full backup of a single data file or filegroup. However, these are not commonly used and as all the principles discussed apply to them, too, I'm going to focus on database-level backups. But as of SQL Server 2005, each of the more granular backup types work exactly the same (this was not true in SQL Server 2000). The same applies to differential backups—they can be performed at the file, filegroup, or database level—but these all work in the same way, as well, regardless of the component being backed up.
A full database backup provides a complete copy of the database and provides a single point-in-time to which the database can be restored. Even though it may take many hours for the backup process to run, you can still only restore the backup to a single point (effectively at the end of the backup, but I'll discuss exactly what that point is later in this article). A full backup does not allow recovery to any point in time while the backup was running. This is also the same for differential backups.
There is a misconception about this, however, fuelled by the fact that you can use the WITH STOPAT=<a time or log sequence number> option on a restore of full and differential backups. Although the syntax allows it, the option has no effect and is just there for convenience.
Another misconception about full backups is that they only contain data. Both full backups and differential backups also contain some transaction log records so that the restored component (database, file, or filegroup) can be made transactionally consistent.
Consider an example transaction that inserts a record into a table with a single nonclustered index. The pages of the table and index are spread through the data file. The transaction is split into two parts internally: a record insertion into a data page in the table and then the insertion of the required record in an index page in the nonclustered index. If the backup process just happens to read the nonclustered index page before the record insertion, but reads the table data page after the record insertion, then the database represented by just the data in the backup is transactionally inconsistent.
This is where the transaction log comes into play. By also including some transaction log records in the backup, recovery can be run on the restored copy of the database, making it transactionally consistent. For this example transaction, depending on when it commits, the recovery part of restore may roll it forward (meaning it will appear as committed in the restored copy of the database) or roll it back (meaning it will not appear at all in the restored copy of the database). In either case, transactional consistency is maintained, which is crucial.
A full backup does the following:
  1. Force a database checkpoint and make a note of the log sequence number at this point. This flushes all updated-in-memory pages to disk before anything is read by the backup to help minimize the amount of work the recovery part of restore has to do.
  2. Start reading from the data files in the database.
  3. Stop reading from the data files and make a note of the log sequence number of the start of the oldest active transaction at that point (see my article "Understanding Logging and Recovery in SQL Server" for an explanation of these terms).
  4. Read as much transaction log as is necessary.
Explaining how much transaction log is necessary is best done with the visual aid in Figure 1. The red numbers on the timeline are explained in this list:
  1. Checkpoint and begin reading from the database.
  2. The read operation reads page X.
  3. Transaction A starts.
  4. Transaction A makes a change to page X. The copy in the backup is now out of date. Note that the backup will not read page X again—it's already passed that point in the database.
  5. Transaction B starts. It does not complete before the data read operation completes.
  6. Transaction A commits. This commits the changes to page X.
  7. The backup data read operation completes and transaction log reading starts.
Figure 1 Example Timeline of Changes During a Full Backup
Backing up enough of the transaction log is required so that recovery can successfully run during the restore and so that all pages in the database are at the same point in time—the time at which the data reading portion of the backup operation completed (Point 7). The transaction log from the beginning of the oldest active (or uncommitted) transaction (Point 5, Transaction B) to the end of the backup (Point 7), is required to allow recovery to run. The transaction log back from the backup checkpoint (Point 1) to the end of the backup (Point 7) is required to allow all pages to be brought to the same point in time.
If the transaction log was only included from the beginning of the oldest active transaction (Point 5), then the copy of page X that was restored from the backup read at Point 2 would not be updated with the changes from transaction A, which occurred at Point 4. This means that it would not be transactionally consistent with the rest of the database as of the time the read data operation completed (Point 7).
So, the minimum log sequence number (LSN) of the transaction log that is included in the full backup is MIN (LSN of backup checkpoint, LSN of oldest active transaction) and it could be for a transaction that began even before the backup began. This ensures that the restored copy of the database (or whatever you restored—page, file, filegroup, database) is completely consistent.
This mechanism means that transactions are not paused in any way by backup operations, although the extra I/O workload on the database may slow them down somewhat. The downside of this mechanism is that the transaction log cannot be cleared for the duration of the full backup because it is required. If there's a lot of update activity and the full backup takes a long time to complete, this could lead to transaction log growth—a problem that I've already discussed in several previous articles and in the SQL Q&A column.
The data contained in a full backup is not necessarily all of the contents of all data files. The backup will only contain the allocated pages from the data files. For example, a single-file database may be 100GB but only contain 15GB of allocated data. In that case, the full backup will only contain the 15GB of allocated data plus the necessary transaction log. (However, the restored database will always be the same size as the original—in this case, 100GB.)
Another misconception is that the backup process examines or changes the data it is backing up. This is untrue, except for in a single case when backup checksums are enabled, which I'll explain shortly.

Differential Backups
The other type of data backup is a differential backup. A differential backup performs the same operations as a full backup, but only contains all the data that has changed or been added since the previous full backup. A common misconception here is that differential backups are incremental. They are actually cumulative and successive differential backups after a full backup and will increase in size as more data is changed or added.
In every 4GB section (called a GAM interval) of every data file there is a special database page called a differential bitmap that tracks which portions (called extents) of that 4GB section have changed since the last full backup, indicating data that has changed or been added to the database. (There are several other allocation bitmaps, too, and you can find more information about these in my blog article "Inside The Storage Engine: GAM, SGAM, PFS and other allocation maps").
A differential backup scans through these bitmaps and only backs up the data file extents that are marked as changed. The bitmaps are reset by the next full backup, so you can see that as more and more of the database changes, more of it will be marked in the differential bitmaps and successive differential backups will be larger and larger. Eventually, if most of the database has changed, a differential backup may become as large as the full backup. You can find out how large your next differential backup will be using a script I wrote that is available from my blog article "New script: How much of the database has changed since the last full backup?." Incidentally, this script can also be used to get an idea of the churn rate of a database—for instance, on a SharePoint content database.
As a side note, if you want to take an ad-hoc full backup and not have it reset the differential bitmaps, you should use the WITH COPY_ONLY option on the BACKUP statement. This is very useful, as otherwise the next differential backups would be based on the ad-hoc full backup you took, instead of on the regular (probably scheduled) full backup. This could lead to big problems when you try to restore in a disaster situation.
So why are differential backups useful? As I'll discuss in the backup strategy section, differential backups can really speed up restore operations by allowing many transaction log backups to be skipped in the restore process. It's much faster to essentially jump forward in time using a differential backup than to have to replay a lot of transaction log records to get to the same point in time.

Transaction Log Backups
Transaction log backups are only possible in the FULL or BULK_LOGGED recovery models, whereas full and differential backups are also possible in the SIMPLE recovery model.
A transaction log backup contains all the transaction log records generated since the last log backup (or full backup that starts a log backup chain) and is used to allow the database to be recovered to a specific point in time (usually the time right before a disaster strikes). This means they are incremental, unlike differential backups, which are cumulative. Since these are incremental, if you want to restore the database to a particular point in time, you need to have all the transaction log records necessary to replay database changes up to that point in time. These are contained in the log backup chain.
A log backup chain is an unbroken series of log backups that contain all the transaction log records necessary to recover a database to a point in time. A chain starts with a full database backup, and continues until something breaks the chain, thus preventing more log backups being taken until another full (or differential) backup is taken.
Operations that break the log backup chain include switching to the SIMPLE recovery model, reverting from a database snapshot, and forcibly clearing the log using the WITH NO_LOG or TRUNCATE_ONLY options (which are not available in SQL Server 2008). It is inadvisable to break the log backup chain, as it forces another (potentially large) full backup to be taken.
Although a log backup chain stretches back to a full backup, you don't necessarily need to restore all those log backups during recovery. If you took a full backup, say, on Sunday night and on Wednesday night, with log backups every half hour since Sunday night, then restoring the database after a disaster on Friday could use Wednesday's full backup plus all the log backups since Wednesday night instead of having to go all the way back to Sunday night's full backup. (The second article in our series will go deeper into this topic.)
Log backups are also required to help manage the size of the transaction log. In the FULL or BULK_LOGGED recovery models, the log will not clear until a log backup has been performed (see the February article for details of what log clearing means), so regular log backups must be performed to prevent the log file from growing out of control. If the log cannot clear, the log will grow until it runs out of space. As such, if you don't want to do point-in-time recovery using log backups, the easiest option is to switch to the SIMPLE recovery model and not use the FULL or BULK_LOGGED recovery models. I discuss this in more depth in the blog post "Importance of proper transaction log size management."
There is a special case in logging that improves performance by allowing some operations to run as minimally-logged operations, where only the page allocations are logged, not the actual insertion of data. This can improve the performance of operations such as bulk loads and index rebuilds. In these cases, not everything about the operation is logged, so the backed up log records don't contain enough information to completely replay the operation. In that case, how can restore and recovery possibly work if there isn't enough information?
The answer is that the first log backup following a minimally-logged operation will also contain some data. Just like the differential bitmaps I mentioned earlier, there is another bitmap called the minimally-logged bitmap (sometimes called the bulk-changed map). This bitmap tracks which extents of a data file have been changed because of a minimally-logged operation.
The log backup following a minimally-logged operation will scan through these bitmaps and also back up those data extents that are marked as having changed. The bitmaps are cleared after being scanned. This means that the log backup has enough information to completely replay the effects of the minimally-logged operation in the database, when the log backup is restored. There's a twist though: There's nothing in that log backup that says when any particular data extent was changed. So a log backup that also contains data from a minimally logged operation cannot be restored to any point in time except the end of the time period covered (or beyond, if the log backup is part of a log backup chain that you're restoring from). So, while you can get performance improvements when switching to the BULK_LOGGED recovery model, you must consider changing to it as a temporary operation—just to improve your batch process and once the batch process is complete, you should switch back to FULL and perform a log backup as soon as possible.
There is also a special case log backup to allow the log to be backed up after a disaster that damages the data files. This is called a tail-of-the-log (or tail-log) backup, where the data files can be damaged or destroyed, but all the transaction log leading up to the disaster point can be backed up. This allows minimal work loss (called up-to-the-minute recovery) when the database is subsequently restored; however, it is supported only when the database is running in the FULL recovery model. More information on these and restrictions with minimally logged operations can be found in the Books Online topic "Tail-Log Backups." The first screen cast that accompanies this article shows me demonstrating tail-of-the-log backups.
In versions of SQL Server prior to SQL Server 2005, transaction log backups could not be performed concurrently with full database or differential database backups—they would block until the database-level backup completed. File and filegroup-based backups did not cause log backups to block. While this complicated the recovery process for file and filegroup backups, it gave them an advantage by not blocking log backups. In SQL Server 2005, all full and differential backups (regardless of component) work in the same way. The behavior now is that the concurrent transaction log backup completes, but the transaction log is not cleared until the full or differential backup (that requires the log) also completes.

Backup Strategy Planning
Now that you know about the three types of backups and how they work, I'll show you how you might put them together into a backup strategy.
A common question I get is how to start thinking about a backup strategy. I always like to say that you shouldn't design a backup strategy. You should design a restore strategy—that enables you to restore as little as possible in the event of a disaster so your downtime is as small as possible while still preserving your data. After you've worked that out, then work out what backups you need so you can perform the restores you need. In other words, your backup strategy should allow you to meet your Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
With a strategy that only includes full backups you're somewhat limited in what you can do with restores. Basically, you can only restore to the time of each full backup, as in Figure 2. If disaster strikes at 23:59 on Saturday, just before the next full backup is scheduled, then all the work since the last full backup might be lost. For this reason, if data-loss needs to be avoided and the data cannot be recreated, log backups are also included, as shown in Figure 3.
Figure 2 Backup Strategy with only Full Backups
Figure 3 Backup Strategy with Full and Log Backups
Imagine that the log backups are being taken every 30 minutes. As long as all the backups are available, this means that the database can be restored to any point in time. However, this still may not be the best strategy. What if disaster strikes at 23:59 on Saturday with this strategy in place? First thing would be to take a tail-of-the-log backup and then start restoring.
To restore the database up to the point of the disaster would mean restoring last Sunday's full backup and then 336 log backups (that's six days of 48 log backups per day, plus 47 on Saturday plus the tail-of-the-log backup). Depending on how much churn there was in the database over the week that could be a huge amount of transaction log that will take a very long time to replay. That's clearly not an optimal restore strategy—but it's a common strategy I see in the field. If you have a strategy like this, make sure that you've practiced doing a restore so you know whether you can meet your RTO in the event of a disaster.
To mitigate this problem, some strategies use more frequent full backups—but these might be prohibitively large to take every day, for instance. The alternative is to use differential backups, which only contain the data that has changed since the previous full backup. Continuing our example, that strategy is illustrated in Figure 4.
Figure 4 Backup Strategy with Full, Log, and Differential Backups
With this strategy, recovering from a disaster at 23:59 on Saturday is a lot faster. Remember that a differential backup is cumulative—so the restore strategy is the Sunday full backup, the 00:00 Saturday differential backup, plus all the log backups from Saturday. Having the differential backup from 00:00 Saturday means that all the log backups before that can be skipped, as the differential backup contains the same as the net-result of restoring all those log backups.
This was a pretty simple and contrived example, but it clearly shows the benefits of each backup type. Once you've designed your backup strategy, make sure you test it to ensure that it allows you to perform your desired restores.
Here's an example that I saw a customer face a few years back. A customer had a corrupt database and wanted to recover with zero data-loss. They were reluctant to use their backups and tried running repair on a copy of the database, but it had to delete data, forcing them into using their backups. It turned out that they had a full backup from January plus a log backup every half-hour up to April—over 5,000 backups in total and all on tape! I'm sure you're rolling your eyes and thinking "I bet it didn't work," but in fact it did; however, it took three days to do it! The customer thought they had a great backup strategy—FULL recovery model plus log backups—but their backup strategy didn't allow them to do the restores that they wanted.

Backup Integrity
There's no point in having backups if you find that they're corrupt when you try to restore from them. Of course, the best way to check the validity of your backups is to restore them on another server, but in SQL Server 2005 a new feature was introduced that allowed some backup integrity checks to be performed without having to actually restore them. You can use the WITH CHECKSUM option when taking a backup (of any variety).
This creates a checksum over the entire backup stream, which is stored in the backup itself. If the backup is a full or differential, and the database has page checksums enabled, then this option will also cause all existing page checksums to be tested as the backup process reads the pages. If a bad page checksum is found, the backup operation will fail. This offers great protection against accidentally backing up a database that's already corrupt in some way. (You can find more information about page checksums in the "Top Tips for Effective Database Maintenance" article from August 2008.)
Once the backup has completed, it can be verified using a command like the following:
RESTORE VERIFYONLY FROM <backup device(s)> WITH CHECKSUM
This will recalculate the checksum over the entire backup stream and compare it against the one stored in the backup. For full and differential backups, it will also test any page checksums on pages in the backup. If any problems are found, then you know that backup has been corrupted in some way.
Naturally, there are the exceptions to the rule, where you may want to back up a corrupt database (if it's the only copy of the database you have and you're going to have to run repair, for instance). In that case, you can force the backup to complete using the WITH CONTINUE_AFTER_ERROR option.
You can find more information on backup validation on information on backup validation on my blog and also watch me demonstrate some aspects of backup validation in the second screen cast that accompanies this article.

Summary
As with any complex topic, there are lots of areas of backups that I didn't have space to cover, but now that the basics are covered, you can dive into some of the Books Online and blog links for deeper information. The best place to start in Books Online is the topic "Backup Overview (SQL Server)." On my blog, you can start with the Backup/Restore category.
One area that you may think is conspicuous in its absence is backup compression. This is deliberate as I'll be covering it later in the year in an article on all the new compression technologies in SQL Server 2008. In the meantime, you can check out the Books Online topic "Backup Compression (SQL Server)" and also on my blog.
If I had to sum up this article in three bullet points, they would be:
  • Make sure you have backups.
  • Make sure you have valid backups.
  • Make sure you have the right backups.
In other words, take backups if you want to be able to restore your database, do something so you know the backups will work when you need them to, and make sure you can restore from your backups and meet your RTO and RPO.
In the next article, I'll explain all about restoring from your backups, including the different kinds of restore operations and how they work, restoring from multiple backups, and partial database availability.
In the meantime, and as always, if you have any feedback or questions, drop me a line at Paul@SQLskills.com.

Paul S. Randal is the Managing Director of SQLskills.com, a SQL Server MVP, and Microsoft Regional Director. 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.


From the Editor It’s All Gotta Work
Mitch Irsfeld

"Can we see some ID, please?" In the digital world, the correct response would be, "Which one?"
Managing user identities means synchronizing those identities among different directories, databases and applications. That's where Microsoft Identity Lifecycle Manager (ILM) 2007 comes in. Understanding the key concepts of ILM can help reduce a very complex set of activities into the component parts that actually simplifies the process of managing directories across a heterogeneous enterprise. This month, John McClinchey walks us through the key elements of ILM and shows us how to write some provisioning code.
But implementing a successful digital identity system in the real world requires an understanding of human nature as well as the nature of identity systems. In Part Two of his "Thoughts on Identity" in the Security Watch column this month, Jesper M. Johansson provides eight more principles of a successful digital identity system. In this case, the real world is the business world, where an identity solution needs to be as inclusionary as possible while still securing the sensitive information of both the business and the customer. As Johansson points out, digital identity systems are quite complicated. But users in the business world need to be shielded from that complexity while still providing the appropriate level of trust. Does that mean single sign-on? Maybe not.
At the client level, managing user accounts is facilitated with User Account Control (UAC). First introduced with Windows Vista, UAC enables you to adjust the permission levels of user accounts and set policies for user rights. Windows 7 introduces two new modes for the Protected Administrator account level and a new auto-elevation mechanism. The changes enable standard users to now perform more operations without requiring administrative rights. Mark Russinovich goes inside the Windows 7 UAC this month as he explains the reasons for the changes and the new capabilities from both a user experience and a security standpoint.
Finally, we encourage you to examine the effectiveness of your database backups. While making sure you have backups of your SQL Server database may seem like a no-brainer, how do you know that you've made valid backups and that you have the right backups when and if you need to restore your database? Putting together a backup strategy for SQL Server databases doesn't have to be as onerous as it may appear. In the first of a three-part series, Paul Randal explains how the various types of backup work and how to put them together in your overall backup and restore strategy.
Mitch Irsfeld is managing editor of the TechNet Flash newsletter and TechNet Flash Feed, a daily news blog providing updates on the latest Microsoft engagements for IT professionals.
—Mitch Irsfeld
Thanks to the following Microsoft technical experts: Brjann Brekkan, Bobby Gill, Sushil Gupta, Jesper M. Johannson, John Macintyre, Michael Murgolo, Sanjeev Nair, Scott Schnoll, Sean Siler, and BJ Whalen.


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 at the time of writing, and are subject to change.

Audit Tool
ObserveIT Express
observeit-sys.com/ObserveIT-Express.asp
Having an easy-to-access, searchable, and visual audit tool can be an invaluable asset for troubleshooting, compliance, and audit protection as well as provide both a deterrent for system abuse and some proof for prosecution if the need arise. One such offering is ObserveIT Express from ObserveIT Ltd., which describes its solution as a "people-audit" tool.
ObserveIT Express is the free edition of the company's flagship product. It allows you to record and replay the past 24 hours of user sessions and monitor up to five servers. You can monitor any Windows NT, 2000, 2003 or XP system with ObserveIT, but at this writing, it's not yet available for Windows Vista. You'll need to enable mixed-mode authentication on your SQL server where the ObserveIT data and configuration information is stored.
Once you have the central application server on your host and agents installed on the servers you want to monitor, you simply connect to the Web console to view the recorded sessions and events on the monitored servers. All the data from the sessions is compressed and secured on the backend SQL Server database. The Web console UI is a tabbed interface with Server Diary, User Diary, Search, Reports, and Configuration Settings views.
The Server Diary view lets you pick a monitored server and shows you a chronological view of the sessions on that machine, including information on users and session durations and links to slideshow video of the actual session. You'll see exactly what each user did in each session, including details on actions taken, such as commands run from a command prompt, services that were restarted or programs that were launched.
The User Diary view shows you a similar view by user account, regardless of which machines individual users connected to. If you're concerned about a particular action that was executed, you can go to the Search view and type in keywords such as "iisreset" or "command prompt;" the tool will bring back all sessions that included that particular action type. The Reports view groups by application, displaying statistics on particular application events. The Configuration view lets you tweak the installation to your needs, although with the free edition you can't change much. If you want more than the defaults, you'll need to upgrade to the product's full version.
So if you're looking for a quick solution for auditing your Windows sessions, you may want to consider adding ObserveIT Express to your IT toolbox.
If you need more than 24 hours' worth of replay, want to tie the product into your current auditing or monitoring tools such as Microsoft System Center Operations Manager, want to configure which applications and what users should be monitored, or need real-time alerting of user action, consider upgrading to the ObserveIT Pro edition, which starts at $500 per agent plus $5,000 for a perpetual license to the management console and Web front end for your environment.

Price: Basic version, free; Pro edition, $500 per agent plus $5,000 for perpetual license.
ObserveIT Express

Information Tracking
Mouse Tracks 2009 Enterprise Edition
gritware.com/Help_Desk_Software.aspx
Tracking information is among the key operational activities of the systems engineer. Whether you are working on the NOC or on the help desk or are the "IT guy," you probably use, or have the need for, an inventory- and asset-management system and a help-desk ticketing system. And the larger your organization grows, the more critical those systems become to ensuring a smooth workflow and happy end users. One easy-to-use and relatively low-cost option for your environment is Gritware LLC's Mouse Tracks 2009 Enterprise Edition.
The application is split into a simple and logically laid out WinForm front-end application with either a SQL server or Access database as the data repository. At its heart, the application is a data-entry and reporting application, and the top section of the UI has a row of buttons for each of the different features. Each of the different views allows you to add, edit, delete, import, and duplicate the records for that section. You can also filter the view to isolate the rows that most interest you.
The Computers button takes you to the Computers List view, which provides an overview of the machines that you've added to the system, including asset tags, locations, computer names, operating systems, and when each machine was last audited. From here, you can launch the Audit Wizard, which reaches out to your domain via LDAP query (or simple host name) to pull the machine information such as CPU, network, BIOS, software, peripherals, and video information into the repository.
The Peripherals and Software buttons will show you any imported or added peripherals and software, again with asset tags as you have them assigned and with other pertinent details. That allows you to quickly look up who has what where in your environment. The Software Asset list also groups your different software packages by licenses, so you can see whether your purchased license count matches your actual license count. In addition to the standard data add/remove/update functions, the application's Users view also lets you directly import your user base from Active Directory. From here, you can also select which users have access to the Mouse Tracks software.
If you need to keep track of books as assets, the Documentation view lets you assign asset tags, descriptions, locations, and other details to help you accomplish that task—and "check out" books or documents to users. And the Purchase Orders view lets you manage vendor contacts and create purchase orders, including terms, messages, and shipping information. It also allows you to mark individual items on each P.O. as received so that you know when items arrived for later auditing. In addition to asset management, Mouse Tracks also offers a set of tools for your help-desk functions, including a Knowledge Base and Help-Desk Ticketing system.
The Knowledge Base is searchable and organized by type so you can find a solution while you're talking with a customer. The Help Desk function lets you assign tickets to technicians and track the time needed to resolve each issue. In addition, the Help Desk view lets you define custom fields so that you can keep track of any extra details you may need.
Finally, the Graphs and Reports views let you "pretty up" and aggregate the data you have in your Mouse Tracks system for auditing and presentation (for instance, for when you're putting together license requests or next year's budget). You can even design and create your own graphs and reports to customize the views as needed, using templates or even custom SQL to get the data you need to do so.
Mouse Tracks 2009 Enterprise Edition starts at $795 for a three-user license. But for smaller environments, you might want to consider the slightly limited Standard Edition, which supports up to 15 named users—it starts at $345 for one named user. And if it is just you running the environment, you may even be able to get by with the free edition, which is limited to one user and 20 audited computers. Both the standard and the free editions are also restricted to an Access database backend. Volume discounts and free trials are also available.

Price: Starts at $795 for a three-user license.
MouseTracks 2009 Enterprise Edition

Book Review
Windows Server 2008 Security Resource Kit
microsoft.com/learning/en/us/Books/11841.aspx
Many new security features and best-practice rules of thumb have been introduced with the Windows Server 2008 family of products. Jesper M. Johansson's Windows Server 2008 Security Resource Kit is designed to help you get up to speed on these new features and security in general. Written with numerous contributing Microsoft Most Valuable Professional (MVPs) and the Microsoft Security Team, the book is part of the familiar Resource Kit series from Microsoft Press.
The book is split into three well-defined sections: Part I, Windows Security Fundamentals; Part II, Implementing Identity and Access (IDA) Control Using Active Directory; and Part III, Common Security Scenarios. The book's structure allows you to either read it end to end for an overall understanding or access individual chapters directly—though, as you would expect, the later chapters build on the fundamentals of the first part of the book.
The book's first part starts on the ground floor of Windows security, covering how "objects" are protected from the various "subjects" via authentication and authorization as well as audited to provide as history of actions. You'll then cover the nuts and bolts of those authentication and authorization protocols in the Windows world, including NTLM, Kerberos, password hashing, and password cracking.
Next, you'll learn about protecting objects with the various tools available in the OS while also covering user rights, ACLs, and the Security Descriptor Definition Language. The next chapter dives into the sometimes dreaded, but protective, User Account Control (UAC), offering best practices and describing how it works "under the covers." Then you'll address remote access to resources and how to secure objects with Network Access Protection (NAP) and the Windows Firewall with Advanced Security and, in doing so, IPSec and the Routing and Remote Access Services (RRAS).
Services are at the heart of any operating system, and the next chapter will teach you about safeguarding this significant attack surface on your machines by learning how they can be attacked and how you can protect against such attacks through service "hardening" and security. Arguably one of the most powerful features of Windows security, Group Policy can be an incredibly potent way to fine-tune and protect en masse in your environment, and the book's chapter on that subject will help you learn how to do just that.
Then, wrapping up Part I, you'll learn how to create and observe the different audit trails at your disposal with Windows Server 2008 so that you can see exactly who did what when.
Part II delves into IDA with two in-depth chapters. The first covers the new user interface to Active Directory Domain Services (AD DS), the importance of Read-Only Domain Controllers (RODC), and AD DS auditing. The second chapter covers what's new with Windows Server 2008 PKI and certificate services in general in the new server OS.
Part III jumps into the real-world practicality of all you've learned in the previous chapters, applying the security features and techniques through common security scenarios. In this section's six chapters, you'll learn how to secure the different types of server roles now that the "install all by default" has been reversed in the Windows server system. You'll also see different techniques for managing server updates across your environments and learn how to identify and mitigate the various security dependencies in your infrastructure. The use of branch offices is still growing in many companies, and the next chapter shows you the new features and techniques to help you protect those remote locations. The final two chapters address small-business concerns and the basics of application security.
The book comes with a great companion CD that contains a set of management scripts and utilities and a bonus chapter entitled "Implementing Active Directory Rights Management Services." If you're looking to get up to speed on the enhancements and features found in the latest Windows Server operating system, take a look at the Windows Server 2008 Security Resource Kit.

Space Saver
Duplicate File Remover
duplicatefileremover.com
Typical shared folders and network storage tend to lend themselves to have multiple copies of the same documents, photos, ISOs, and executables. If you're concerned about space and would like to consolidate those files by removing all those unneeded duplicates, there are many tools out there to help you do so. But how do you ensure that that those extra files are truly duplicates? Going by file names alone would, of course, lead to some angry end users. One tool out there to help you safely clean up all those duplicates is the Duplicate File Remover from Object Rescue.
At launch (after you stop giggling at the application's mascot of a sheep armed with a bazooka), you define your search. The utility lets you pick what types of files you're concerned with—documents, photos, music, video—or you can define your own search based upon file type, size, creation date, and folder exclusions. Note that you can also opt to avoid hidden and system files.
Then, you pick the drive, folder, or network share you wish to search, and Duplicate File Remover builds a list from the selected search areas to determine which files are duplicates. Another plus: the utility will also report on which files it wasn't able to access due to security or other exclusion reasons.
Once that process is complete the application scans the files based on the selected metrics and sorts them into groups, setting one as the primary file and marking the rest as duplicates. Depending upon what action you want to take with the results, you can also use the quick toggle buttons at the top of the user interface to check all duplicates, check or uncheck a selected group, or uncheck all the items before you start.
Then you can delete marked files, copy them, or move them to another location (great for verification, in case a file was incorrectly identified as a duplicate). Or you can create a hard link from the original to the duplicates if you need to maintain the folder/file structure but want to gain back the disk space (and ensure that there's only one file to update and manage).
At the bottom of the UI, the utility also gives you overview statistics such as the total number of files, the number of duplicates found, and the space those duplicates take up on your drive. Finally, when you're done, you can generate an HTML report as an audit trail of what actions you took.
Price: $29.95 for a single user license.
Figure 3 Duplicate File Remover

If you have a favorite tool or utility you would like to see featured here, please write to the author at tntools@microsoft.com.

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.


Exchange Queue & A New Features and Improvements in Exchange Server 2010
Henrik Walther

This month's installment of the Exchange Queue & A column is extra exciting, as it covers some of the brand new features and improvements included with the new version of Exchange, Exchange Server 2010 (codenamed E14).
QDoes the new version of Microsoft Exchange replace the Extensible Storage Engine (ESE) database technology with a version based on SQL Server?
AThis was a common question back when Exchange 2007 was being developed and the answer is still the same. No, the ESE database technology has not been replaced in the new version of Exchange.
That said, you can expect a lot of improvements relating to the ESE database technology in Exchange Server 2010. Exchange 2007 significantly reduced the I/O footprint for Exchange Server due to its 64-bit architecture, database cache optimizations, the elimination of the streaming database (STM) file, and the installable file system (IFS). Exchange Server 2010 does even more. Exchange 2007 reduced the I/O footprint up to 70 percent—and Exchange Server 2010 will do considerably better.
QHave the high-availability features we know from Exchange Server 2007 changed in the new version of Exchange?

AYes, there are several significant changes to high-availability features in Exchange 2010. As most of you are probably aware, Exchange 2007 introduced new high-availability features such as Cluster Continuous Replication (CCR) and Local Continuous Replication (LCR). To provide site resiliency capabilities for Exchange environments, Standby Continuous Replication (SCR) was added in Exchange 2007 SP1.
Although these features work very well in most enterprise environments, some administrators consider CCR and SCR to be a bit complex to deploy.
With Exchange Server 2010, the Exchange product group has done a lot of work to make the high-availability and site-resiliency features easier to deploy and manage. The result is that Exchange 2010 combines the key availability and resilience features of cluster continuous replication (CCR) and standby continuous replication (SCR) into single high-availability solution that handles both on-site and off-site data replication. Mailbox servers can now be defined as part of a Database Availability Group ( DAG) to provide automatic recovery at the individual mailbox database level instead of at the server level. (see Figure 1). Each Mailbox server in the DAG can host a copy of a mailbox database from any of the server members of the DAG. Like CCR, DAG also uses some Windows Failover Clustering technology, but you no longer need to mess around with the Windows Failover Clustering console or cluadmin.exe. Exchange High Availability is now managed via the Exchange Management Console or the Exchange Management Shell. A new process called the Active Manager runs on the Mailbox servers to manage which mailbox database copies should be active, and only part of the Windows Failover Clustering features are used by a DAG.
Figure 1 Creating a New DAG
On a related note, the concept of storage groups has also been removed from Exchange Server 2010. Now databases live at the organization level, making storage groups obsolete. Although transaction logs used to be associated with storage groups, logs still exist in Exchange Server 2010 as the Extensible Storage Engine and the database use them.
QAre there any improvements relating to Transport server redundancy?

AIndeed there are. Most of you are familiar with the Transport Dumpster feature from Exchange 2007. This feature allowed a Hub Transport server in the same Active Directory site as a CCR-based Mailbox server to resubmit any lost mail after a failover. With Exchange Server 2010, a feature known as Shadow Redundancy has been introduced. Shadow Redundancy provides redundancy for the entire time messages are in transit. With this feature, a message deletion from the ESE-based message queue (mail.que) on a Hub Transport or Edge Transport server will be delayed until an Exchange Server 2010 Transport server has verified that all of the hops the message uses have completed and only then will the message be deleted. Should any of these hops fail, the message will be resubmitted.
Of course, the Transport Dumpster has also been greatly improved. We will cover these improvements in a future installment of the Exchange Queue & A column.
QCan you talk a little about how administration has been improved in Exchange Server 2010?

ASome of the most notable changes related to administration result from the fact that Exchange Server 2010 is based on Windows PowerShell V2; which can be used remotely. This means you can administer Exchange 2010 servers across the network with only Windows PowerShell V2 and Windows Remote Management 2.0 installed on the local machine.
Another interesting change is that you can now add more Exchange organizations to the Exchange Management Console—whether on-premises Exchange organizations or cloud-based organizations such as Exchange Online.
And unlike Exchange 2007 where you had to use the Export-Mailbox and Import-Mailbox cmdlets to export and import data to or from PST files, you can now export and import mailbox data directly via the Exchange Management Console GUI, as shown in Figure 2
Figure 2 Exporting a Mailbox via the Exchange Management Console
QHas client access been improved in Exchange Server 2010?

AYes, there are a number of enhancements related to client access. Probably the most significant one is that Outlook 2007 and later clients will no longer connect directly to the Mailbox servers using MAPI. MAPI is still the primary connection protocol, but with Exchange 2010 these clients will connect to the Client Access Servers (CAS) using a new RPC Client Access Service. This new service is entirely rewritten in managed code, and one of the reasons for the introduction of this service is to restrict all data access to a single common path in the middle tier. The net result will be an improved client experience. For instance, Outlook users will no longer be aware when a failover occurs between mailbox databases in a DAG, as the end point connection for Outlook clients now are CAS.
QIs there anything new for disclaimers based on transport rules in Exchange 2010?

AYes. With Exchange 2010, disclaimers will now support HTML-formatted text, images, and hyperlinks.

QWhat about the Exchange 2007 permission model—any changes made in this area?

AThe permission model we know from Exchange 2007 has actually been replaced with a new one called Role-Based Access Control (RBAC). RBAC makes it possible to define broader or more precise roles and assignments derived from users and/or administrators and the tasks they perform. As most of you already know, Exchange 2007 has only three broad roles to modify: Org, Recipient, and Server, which, along with the fact that permissions are focused on Active Directory objects, makes it extremely difficult to grant or delegate more granular permissions. Exchange 2010 even includes self-management roles, which allow users to create and manage distribution groups.
QI've heard about a new control panel included with Outlook Web Access 2010. Can you explain what this is all about?

AYes, OWA 2010 now includes the Exchange Control Panel (ECP), shown in Figure 3, which replaces the old OWA 2007 Options page. The ECP can be considered a more formal management tool for users as well as administrators. Within the ECP, you can manage all the options that were included with the old Options page and much more. For instance, users can now create and manage distribution groups, perform message-tracking for their own messages, configure retention policies, and even change property fields for their Active Directory user account so that it always contains up-to-date information. And Exchange administrators can create new mailbox-enabled users from within the ECP.
Figure 3 The new Exchange Control Panel in Outlook Web Access 2010
QWill it be possible to use the premium version of Outlook Web Access 2010 OWA with browsers other than Internet Explorer?

AYes, the front-end team in the Exchange product group invested heavily in making sure end users would get the best OWA 2010 experience whether they use Internet Explorer or any of the other popular browsers available today. Now you can also use Safari or Firefox and still get the OWA 2010 premium experience.
QCan you tell about some of the new features and enhancements to OWA 2010 that will especially appeal to end users?

ALet me start by saying that there are lots of exciting features and improvements in the new Exchanger 2010 OWA 2010 client. Here are some of my favorites: Search folders and Favorites are included in the navigation pane. You can now set categories for messages directly from within OWA 2010. OWA 2010 gives you the option of showing calendars side-by-side, and there's a great conversation view that makes the Inbox much easier to digest (see Figure 4). You can now send text (SMS) messages from OWA 2010. And last but certainly not least, OWA 2010 now integrates with Office Communicator, so you can take advantage of its capabilities, such as seeing presence of colleagues on your contact list, sending and receiving instant messages, and more.
Figure 4 OWA 2010’s Conversation View

Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP, with more than 15 years of experience in the IT business. He works as a Technology Architect for Trifork Infrastructure Consulting (a Microsoft Gold partner based in Denmark) and as a Technical Writer for Biblioso Corporation (a U.S.-based company that specializes in managed documentation and localization services).


Utility Spotlight Exchange Server Remote Connectivity Analyzer
Brad Hughes

Have you ever gotten an error message when connecting to Exchange Server that gave you little or no clue as to what the actual problem is? Perhaps while connecting RPC over HTTP, you got the response "The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action," or even more likely, you got prompted over and over again for credentials with no error message whatsoever. Maybe when you tried using ActiveSync, you saw the less-than-useful "0x85010014–ActiveSync encountered a problem on the server." Well, those days are over! Now you can get help from the Microsoft Exchange Server Remote Connectivity Analyzer ( ExRCA).
ExRCA is a Web-based troubleshooting and diagnostic tool intended to identify the point of failure for Internet-based Exchange Server client connectivity scenarios. The goal is to simulate all of the activities a client must be able to perform to connect, and then isolate the exact point of failure. In many cases, ExRCA can actually point out known configuration issues and provide suggested steps for resolution. The connectivity testing across the Internet (from outside your organization) is actually performed by a Web site hosted in the Microsoft datacenter.
Currently, ExRCA includes support for the following scenarios:
  • Outlook Anywhere and Autodiscover for Exchange 2007/Outlook 2007
  • RPC over HTTP for Exchange 2003/Outlook 2003
  • Exchange ActiveSync and Autodiscover for Exchange 2007/Windows Mobile 6.1 and other Autodiscover-capable devices
  • Exchange ActiveSync for devices prior to Windows Mobile 6.1 and other third-party licensees
  • Inbound SMTP mail-flow
There are definite plans to support more scenarios in the future.
Figure 1 shows the results of an inbound SMTP e-mail test. This is a simple example where no MX records were present for the domain alpineskihouse.com. The test isolates your configuration problem and gives you the link "Tell me more about this issue and how to resolve it." This link takes you to landing pages on TechNet that are specific to each error, with more detail about the specific issue and how to resolve it. All of the TechNet content is enabled for "Community Content." So if you find a resolution we don't have documented, we encourage you to leave a comment so that others may benefit from your resolution.
Figure 1 Sample Output
There are a number of issues we are hoping to correct in a future release. Some of the major ones are
  • No ability to ignore the trust requirement for SSL when performing Outlook Anywhere / RPC over HTTP tests. Unfortunately, the Windows RPC API doesn't give us the ability to allow an untrusted certificate from our application. We're hoping to work with the Windows team to enable this for a future version of the tool.
  • The Captcha/Human Interactive Proof ( HIP) can be incredibly hard to read. In a future release, we're planning to implement the Windows Live ID HIP that's already used in Hotmail and various other Microsoft services. It should be much easier to read.
  • Navigating using the browser forward and back buttons breaks things and causes you to get errors. Some updates to the ASP.NET wizard control were included in the Microsoft .NET Framework 3.5 SP1; we're hoping to utilize some of those enhancements to make the navigation more seamless in a future release.
The Exchange Remote Connectivity analyzer is available at www.testexchangeconnectivity.com. You can watch a video that shows how to use the tool at edge.technet.com/Media/The-Remote-Connectivity-Analyzer-for-Exchange-Server.

Brad Hughes is a Senior Escalation Engineer with Customer Service and Support for Exchange Server.


Inside SharePoint SharePoint Security Hardening
Pav Cherny

Contents
Security Dependencies in a SharePoint Environment
Enabling Network Access Protection
Establishing Domain Isolation
Implementing Server (and Workstation) Isolation
Conclusion
SharePoint security hardening requires an end-to-end approach that addresses the full spectrum of security dependencies and risks within and across server farms. In particular, recent innovations and technologies available out of the box with Windows Server 2008, such as Network Access Protection (NAP) with Internet Protocol Security (IPsec) enforcement, can help to increase SharePoint security. Yet detailed Microsoft recommendations for SharePoint security hardening in a Windows Server 2008 environment are hard to find. The Windows Server 2008 Resource Center for SharePoint Products and Technologies doesn't include a security guide. In addition, the security-hardening guides for Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007 are still based on Microsoft patterns and practices that are dated June 2003 and were only partially updated in January 2006—which was still long before the release of Windows Server 2008 and Internet Information Services (IIS) 7.0, in any case.
Clearly, revised guidelines are highly overdue, and not just because we have long since moved on from Windows 2000, SQL Server 2000, IIS 5.0 and Microsoft .NET Framework 1.1, but also because the old ways of dealing with security hardening have proven insufficient time and again. It's simply not enough to secure a SharePoint farm as an isolated server island, as if SharePoint farms exist in a vacuum. The reality is that not a single security-hardening step in a SharePoint farm matters if the Active Directory forest is insecure, if the intranet environment is infested with spyware and rootkits or if users inadvertently or maliciously violate security policies by, for instance, downloading and installing file-sharing software from questionable sources.
It's possible to tackle these issues by using Windows Server 2008 technology. It's the key to achieving a high level of security in a SharePoint environment, end to end, from the client computers all the way up to the database servers.
In this article, I discuss SharePoint security aspects in an intranet environment based on Windows Server 2008. This discussion entails analyzing general SharePoint security dependencies beyond the limits of an individual farm and then deploying NAP with IPsec enforcement with corresponding security and isolation rules to mitigate risks. For SharePoint administrators, an obvious advantage of NAP is that it can stop unmanaged client computers from accessing SharePoint resources and downloading documents. Another, perhaps less obvious, advantage is that you can divide your intranet into separate logical networks through domain and server isolation. In this way, you can protect the inbound and outbound client-to-server and server-to-server communication and also limit traffic to desired front-end servers. Assuming that up to 30 percent of a company's SharePoint sites reside on rogue departmental farms, inadequately secured and out of the IT department's control, the benefits of restricting client traffic cannot be overemphasized. As always, the companion material includes worksheets with step-by-step instructions for following my explanations in a test environment.

Security Dependencies in a SharePoint Environment
Considering the complexity of SharePoint-based solutions, the sheer volume of data stored in SharePoint sites and the often contradictory security and productivity requirements in an enterprise, it can be tough to determine how and where to get started with SharePoint security hardening. Perhaps the first step is to retire the long-held notion that our intranets are friendly environments, sufficiently protected through perimeter firewalls and virus scanners. Firewalls and scanners don't block a malicious user from attaching a PS2 or USB hardware keylogger to a client computer—no drivers required. They also won't keep a zero-day rootkit from turning your mobile computers into zombies while they are connected to an inadequately secured environment at home, in hotels or airports or at customer sites. It may sound harsh, but categorizing your internal environment as hostile helps in terms of recognizing critical security dependencies within and across SharePoint farms.
Let's see what critical issues we can discover in a straightforward test lab, such as the one depicted in Figure 1 and outlined in the companion worksheet "Deploying a Test Environment With Multiple SharePoint Farms and a Network Policy Server." This SharePoint environment isn't secure. In fact, my deployment worksheet violates several security best practices and ignores important dependencies. I usually get away with it, assuming that there are no security requirements in test labs. Of course, I could have done worse by installing SharePoint on a domain controller or by granting security accounts administrative permissions, but these intentional configuration errors are not necessary. From a security perspective, my test environment is already bad enough.
Figure 1 An Insecure Test Environment with Multiple SharePoint Farms
For starters, I use the domain- administrator account to log on to all servers and workstations and install all systems while they were connected to the Internet. This is risky. It's better to avoid logging on to an unsecured computer by using a domain-administrator account. Likewise, it's a best practice to install and patch computers in a separate, secure staging environment prior to deployment. Windows Automated Installation Kit (AIK) and Windows Deployment Services (WDS) offer a good solution, yet I didn't take advantage of these technologies in my test lab for reasons of complexity. Because I took shortcuts, my Active Directory environment might already be compromised—and with it all my SharePoint farms. The game is over before it even started! A SharePoint farm can never be more secure than its Active Directory environment.
Domain-administrator accounts are very sensitive accounts indeed. You're also in a sensitive area when you access SharePoint resources, such as the SharePoint 3.0 Central Administration site and SharePoint site collections. Accessing a SharePoint site implies running ASP.NET code under the identity of the current user on the front-end server. If that current user happens to be a domain administrator, then the code runs with administrative privileges. You should deny domain administrators and local server administrators access to the SharePoint Web applications because it's possible to exploit their elevated privileges, such as extracting security accounts and passwords, as explained in the January 2009 column. If an attacker can trick a SharePoint administrator into deploying a malicious component or enabling inline ASP.NET code, the attacker might also be able to determine the security-account passwords and subsequently gain access to all sites in all farms that use those accounts.
In my test lab, I ignored these security-account dependencies and administrative risks, configured the WSS farm and the HR farm with the same security accounts and used the domain-administrator account to work with SharePoint 3.0 Central Administration in both farms. Sharing security accounts between farms is a bad idea, especially if they have different security requirements. A farm that shares its accounts depends on the other farm for security—and can therefore never reach a higher level of security than that of the other farm.
Using separate security accounts is an important best practice, but a compromised farm can still provide an avenue for attacks on other farms in the same Active Directory environment. For example, it doesn't take much effort to turn a compromised SharePoint server into an internal phishing platform. An attacker might enable Basic authentication or get a malicious component into an established SharePoint farm that sends a "WWW-Authenticate" header to the users and intercepts the returned credentials in plaintext, as illustrated in Figure 2. Because users trust their internal SharePoint sites, it's likely that they will enter the requested credentials without hesitation—and the attack succeeds.
Figure 2 A compromised SharePoint farm can enable attacks on other farms.
Of course, it's difficult to compromise a properly maintained SharePoint server, but that's not the point. The point is preventing security breaches on systems that aren't properly maintained from spreading to sensitive systems with higher-level security. Therefore, at least for the most sensitive SharePoint resources, such as an HR farm with personally identifiable information, you must consider these access dependencies, which basically imply that a SharePoint farm can only be as secure as the least-secure sites that the farm administrators, site-collection administrators, and site users can access with their user accounts.
Don't forget to include the client computers in your analysis of access and usage dependencies. Again, my test environment sets a poor example because any user can use any workstation to access any resource, and the computers aren't equipped with virus scanners or the latest security patches. Just imagine a user with the rights of a farm or site-collection administrator logging on locally to a spyware-infested client computer or to a computer in an unlocked office, where an attacker can easily attach a hardware keylogger. Farms and site collections are compromised as soon as the attacker gains access to an administrator account and password on any computer in any location. File-sharing software on client computers also poses security risks, as client computers tend to store content from SharePoint sites locally, manually, or automatically downloading that information into temporary files. Hence, a SharePoint farm can never be more secure than the client computers that the users use to access the farm's resources.
Of course, there are further weaknesses in my test environment. I invite you to study the relevant sections in the SharePoint security-hardening guides and continue this review on your own. You should recognize at least a handful of additional issues, such as that the SharePoint 3.0 Central Administration sites and search roles are hosted directly on front-end servers that service site content, that there's no antivirus solution on the servers, that the WSS farm and the HR farm share a common and unprotected database server, that all computers in the test environment have direct access to the database server, and that the network communication takes place in plaintext. None of this is desirable, so let's tackle some of these security issues.

Enabling Network Access Protection
There are many steps you can take to increase the security in a SharePoint environment, such as controlling physical access to computers and the network, configuring vLANs and access control lists (ACLs) on routers, and securing infrastructure servers (DNS servers, DHCP servers, domain controllers, and so forth) through deploying Microsoft Forefront Security for SharePoint and Active Directory Rights Management Services (AD RMS). Physical access controls and basic TCP/IP networking and router configurations are beyond the scope of this column and AD RMS has been discussed in previous columns, so that leaves us with NAP, IPsec, HTTP over Secure Sockets Layer (SSL), and Forefront Security as the next logical topics. This column focuses on NAP and IPsec. HTTP over SSL and Forefront Security will be addressed in future columns.
NAP with IPsec offers at least three key advantages for an internal SharePoint environment:
  • You can enforce system health policies and automatically remedy compliance issues on client computers running Windows XP Service Pack 3 and Windows Vista;
  • You can implement an additional layer of network security through IPsec and Windows Firewall across an entire Active Directory forest;
  • You can establish encrypted communication channels through Encapsulating Security Payload (ESP) within a SharePoint farm and between servers and client computers.
A bonus is the ability to manage the network communication centrally through Group Policy and audit network access. In short, NAP with IPsec is an important enabler of an effective end-to-end security strategy for SharePoint.
At the core, NAP with IPsec relies on a clever distribution mechanism for X.509 certificates. On the client computer, system health agents (SHAs) inform the NAP agent about their compliance status through statement-of-health (SoH) documents, which the NAP agent consolidates in a system statement of health (SSoH). It passes the SSoH to the IPsec NAP Enforcement Client (NAP EC) on the client computer, which in turn passes the SSoH to the NAP Enforcement Server (NAP ES). This is the Health Registration Authority (HRA) that obtains system-health certificates from a certification authority (CA) for compliant computers. Figure 3 illustrates how a NAP client obtains a health certificate.
Figure 3 NAP Client/Server Communication to Exchange Health Information and Certificates
To determine that the requesting computer is compliant, the NAP ES passes the SSoH in a RADIUS message to the Network Policy Server (NPS). The NPS again passes the SSoH to the NAP Administration Server, which in turn extracts the individual SoHs from the SSoH and forwards them to the corresponding System Health Validators (SHVs). The SHVs analyze the SoH information and return a statement-of-health response (SoHR), which the NPS consolidates in a system-statement-of-health response (SSoHR) that the NAP system then passes back to the SHAs on the client computer. Through SoH and SoHRs, SHVs communicate with their corresponding SHA counterparts. For example, the SoHR from an antivirus SHV can instruct the corresponding antivirus SHA to download the latest version of the signature file from a remediation server to bring the client computer back into compliance.
On the server side, NAP also compares the SoHRs to the configured network and health policies and issues a system-health certificate if the client computer is compliant. The NAP client receives the certificate from the NAP ES and stores it in its computer certificate store. The certificate is now available for Internet Key Exchange (IKE) negotiation to establish IPsec security associations with trusted communication partners. The NAP client renews the system-health certificate whenever it is about to expire or when an SHA indicates a health-status change to the NAP agent. The bottom line is that compliant computers receive a health certificate and noncompliant computers don't. For deep technical details, I highly recommend the white paper "Network Access Protection Platform Architecture." The companion worksheet "Configuring Network Access Protection" describes the steps to deploy a basic NAP infrastructure in a test lab.

Establishing Domain Isolation
Even in my humble little test lab with NPS and HRA roles on a single server, you can immediately notice the benefits of NAP. As soon as you enable NAP on the client computers through Group Policy settings, NAP strongly encourages you to install the latest security patches and a virus scanner. The NAP client informs you about missing security components, and the network status includes a notification informing you that network access may be limited until the computer meets health requirements. At this point, however, noncompliant computers still have access to all servers in the network because we haven't yet configured IPsec policies. Without IPsec policies that request or require authentication for inbound and outbound connections, the NAP infrastructure really isn't much more than a health-certificate distribution mechanism. We need to implement domain isolation for NAP to be effective.
Implementing domain isolation means dividing the internal network into segments of restricted, boundary, and secure networks through IPsec enforcement policies. The objective is to prevent noncompliant computers from accessing any servers in the internal network—with the exception of those servers that the noncompliant computers must be able to access to become compliant and obtain a health certificate. In Figure 4, this concerns the NAP server NPS01. The difference between the boundary segment and the secure segment is that the IPsec policy for the boundary segment requests authentication for inbound and outbound connections and thus permits fallback to plaintext communication with noncompliant computers, while the secure segment requires authentication for inbound connections, which prohibits fallback to plaintext and blocks noncompliant computers. You can use the companion worksheet "Configuring IPsec Policies for Health Enforcement" to implement this segmentation.
Figure 4 Restricted, Boundary, and Secure Networks for NAPNAP
The domain controller in Figure 4 is a special case. You can request or require IPsec-protected communication between domain members and domain controllers if your computers run Windows Vista or Windows Server 2008 (see the companion worksheet "Configuring IPSec for Domain Controller Communication"), but this configuration is not supported for Windows Server 2003 and Windows XP. If you decide not to use IPsec for domain-controller communication, DC01 becomes part of the restricted network; requesting IPsec moves the domain controller into the boundary segment and requiring IPsec makes the domain controller a member of the secure segment. The configuration depends on your specific situation and needs. If possible, I recommend using IPsec.

Implementing Server (and Workstation) Isolation
Establishing NAP with IPsec enforcement and domain isolation serves as the first significant milestone towards security hardening. All client computers must now meet reasonable health requirements before they can access any internal SharePoint resources. Next, you can focus on segmenting the SharePoint environment into multiple tiers to achieve a fine level of communication control, end to end, including the communication of client computers. Figure 5 illustrates a possible segmentation strategy based on the role of each individual computer in the internal network.
Figure 5 An Improved Test Environment with Multiple SharePoint Farms
As you'll notice in Figure 5, my test environment now includes additional systems. Among other things, I changed the configuration of the WSS and HR farms and specified separate security accounts, moved the HR configuration and content databases to a separate SQL server and deployed separate computers for SharePoint 3.0 Central Administration and the SharePoint Search role in both farms. Check out the various worksheets in the companion material, which illustrate how to accomplish these steps.
Securing the communication between the tiers is now a straightforward process, thanks to our NAP with IPsec preparation work. Through Group Policy, you can centrally manage all rules for Windows Firewall with Advanced Security to lock down inbound and outbound communication on clients and servers to the most restrictive levels. I recommend disabling rule merging in Group Policy to prevent local administrators from applying conflicting firewall and connection security rules on any domain member. For example, you can lock down UDP and TCP port 1434 on the database servers, open a custom TCP port for the default SQL Server instance, encrypt the traffic, open only the TCP ports that your Web applications use on the front-end servers, and block all non-HR computers from accessing any server or client computer in the HR department.
References
Network Access Protection Web site
go.microsoft.com/fwlink/?LinkId=69752
SharePoint Products and Technologies Web site
microsoft.com/sharepoint
Windows SharePoint Services TechCenter
technet.microsoft.com/windowsserver/sharepoint
Windows SharePoint Services Developer Center
msdn2.microsoft.com/sharepoint
Microsoft SharePoint Products and Technologies Team Blog
blogs.msdn.com/sharepoint
An interesting question is whether you should also block sensitive computers from accessing nonsensitive computers—for instance, should you keep HR clients from accessing non-HR SharePoint servers in the WSS farm. This is an example where security and productivity requirements collide. For productivity reasons, I think it's impossible to refuse HR people access to company-wide SharePoint sites such as sites in my WSS farm, which implies that the WSS farm must conform to the same security standards as the HR farm. So in both farms, I had to move the SharePoint 3.0 Central Administration sites and search roles to a separate computer and apply firewall and connection security rules. Of course, you should also designate dedicated, nonprivileged accounts for SharePoint administration in both farms and apply further security-hardening steps. Joel Oleson has posted a great summary list of security-hardening steps on his SharePoint Land blog. I highly recommend following Joel's advice in an IPsec-enabled infrastructure that provides a rock-solid foundation for end-to-end SharePoint security hardening.

Conclusion
SharePoint farms don't exist in a vacuum. They exist in an environment that includes client computers, infrastructure servers, and networking equipment. That means you must attend to these components if you want to achieve better security through SharePoint securing-hardening. It's impossible to secure a SharePoint farm in an insecure Active Directory environment. It's impossible to secure a SharePoint farm if the client computers are infested with spyware. It's impossible to secure a SharePoint farm if an attacker can highjack user accounts, administrator accounts, or security accounts anywhere.
Windows Server 2008 technology provides the basis to cast a broad security net over an Active Directory forest through Network Access Protection with Internet Protocol Security enforcement, Windows Firewall with Advanced Security, and Group Policy management. Taking advantage of these technologies in a SharePoint environment is definitely worth the effort. You can control and secure the communication between workstations, servers, and domain controllers; you can enforce system health standards; you can implement domain isolation; and you can enforce separate tiers in the internal SharePoint environment. Through membership in security groups or organizational units, Active Directory automatically determines the policy settings that apply to each domain member, including client computers, database servers, front-end servers, and middle-tier servers for administration and other purposes. You can establish general policies for each tier and specific policies for each computer type and server role. You can prevent users from hosting SharePoint on client computers by blocking all incoming connections, and you can prevent departments from hosting unapproved and insecure SharePoint farms that might provide avenues for attacks on other farms in the internal network.
But don't go overboard with restrictions. Keep in mind that many departmental business processes rely on SharePoint deployments outside of the data center. After all, SharePoint is a business-critical collaboration platform in the enterprise.

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 Corp., a company that specializes in managed documentation and localization services.


Windows PowerShell What Not to Script
Don Jones

Contents
Do Not Overuse Variables
Meaningful Variable Names
Simplify Comparisons
Don't Break Your Script
Loop the Loop
Don't Be So Silent
Show Me Your Scripts
I recently made an offer (which still stands) to readers of my ConcentratedTech.com blog: Send me your Windows PowerShell scripts and I'll review them and offer any suggestions I have to help improve them. The idea actually came from a survey my co-bloggers and I ran—a reader suggested that this would provide a great, real-world way for people to improve their scripting skills. Over the past few months, I've noticed a few trends as I find myself making several particular suggestions repeatedly. So I've compiled a list of them to share with you here.
Let me first state, however, that any script that gets the job done (successfully and without collateral damage, of course) is a good script. Some of the things I'm suggesting may seem nitpicky and some of them certainly are. However, each of my suggestions does have some distinct advantages, which I'll try to point out as I go.
Don't take offense if you're actually doing some of the "bad practices" I point out. I know that a lot of people that script in Windows PowerShell started out scripting with VBScript and some of these "bad practices" are actually very common in the VBScript world. This is a great opportunity, then, to learn how Windows PowerShell and VBScript are a bit different and how to write scripts that make use of the unique advantages Windows PowerShell has to offer.
With that said, here are my top six common suggestions I've made over the past few months.

Do Not Overuse Variables
Sure, variables are useful, but let's not get carried away. I've been seeing a lot of this kind of scripting:
$varfile = "c:\names.txt"
$varexists = Test-Path $varfile
if ($varexists –eq $false) {
  Write-Output "The file $varfile does not exist"
  break
}
$varnames = Get-Content $varfile
There are a few practices I'd like to see changed in an example like this. First and foremost, there's little need to stick all that information into variables. It's possible to rewrite this with fewer variables. Why bother? Well, the shell might not care how many variables you use, but I'm a big, big fan of making scripts as readable as possible so someone can read your script on paper or in a script editor and be able to figure out what the script is doing. The more variables you include, the more someone will have to track in his head—and the less likely he'll be able to figure out what the script is up to. If I can't figure out the script on paper, I'm less likely to be able to debug the script if there's a problem. So I'd start by rewriting this sample as follows:
$varfile = "c:\names.txt"
If ((Test-Path $varfile) –eq $false) {
Write-Output "The file $varfile does not   exist"
  break
}
$varnames = Get-Content $varfile
All I'm really doing is eliminating the $varexists variable and directly utilizing the output of Test-Path. This way, I don't have to look at the If construct, see $varexists, and then go back and figure out what $varexists is supposed to contain. It's less for me to keep track of in my head. Notice that I left $varfile; this is because I use that information three times—if you're re-using information multiple times, then it's worth putting into a variable.

Meaningful Variable Names
Continuing with the previous example, always remember that variable names should help you remember what's inside a variable. You don't need to use name prefixes like "var" because the $ character tells you it's a variable. In fact, name prefixes like "str" for strings or "int" for integers are outdated ("that's so 1993" is what I say when I'm teaching classes). Just use straightforward variable names. Here's the example rewritten:
$filename = "c:\names.txt"
If ((Test-Path $filename) –eq $false) {
Write-Output "The file $filename does not exist"
  break
}
$computernames = Get-Content $filename

Simplify Comparisons
I'm not a fan of comparison operators in Windows PowerShell—ones like –gt, -lt, -eq, and so forth. My lack of fondness probably comes from my long experience with VBScript, where I could use familiar operators such as >, <, and =. Many of you probably recognize these operators from grade school math lessons, and so they require less mental parsing when you read them. Whenever possible, then, I like to avoid using an operator. And any condition where you check for something to be True or False is an opportunity to get rid of an operator:
$filename = "c:\names.txt"
If (-not (Test-Path $filename)) {
Write-Output "The file $filename does not exist"
  break
}
$computernames = Get-Content $filename
Because the Test-Path cmdlet returns True or False, there's no need to compare it to True or False. Everything inside the If constructs parentheses needs to boil down to True or False. Normally, you would use a comparison to achieve that, but if whatever is in there is already generating True or False, you can just use that info directly.
I should note that the –not operator is one I actually do like. It's more like common English than the equivalent != operator used by many languages.
Also, I should comment on the parentheses I'm putting around Test-Path and its input parameter, $filename. I've started enclosing commands in parentheses because it helps me visually grasp them as a single unit. Windows PowerShell uses spaces, rather than some other character, to separate things like commands, parameter names, and parameter values. Enclosing the entire command string in parentheses helps me see it all together, without forcing me to actually look at the spaces and determine where the command starts and stops.

Don't Break Your Script
The last suggestion I have for this running example is the way its logic is built. If the file doesn't exist, I break out of the script. If the file does exist, I never execute the Break statement and so the script continues. Whenever possible, I like to avoid using Break to exit a script. I'd rewrite the example—again—as follows:
$filename = "c:\names.txt"
If (Test-Path $filename) {
$computernames = Get-Content $filename
  # do whatever we planned to do
} else {
Write-Output "The file $filename does not exist"
}
This way, I've simplified the logic in the If construct. I've also eliminated the need to use the Break statement, which reduces confusion about what the script is doing. I'm the first to admit that this suggestion is absolutely a nitpick, but I think good coding practices help make better scripts, and this is definitely a better practice than bailing out of a script halfway through. This type of construct is easier to debug, and it's much easier to follow on paper if you're looking at a script and trying to figure out what it does.

Loop the Loop
Several of the scripts I reviewed needed to read information from a text file and loop through each line of the file. For example, you might want to contact a series of computers, so you could list their names, one name per line, in a text file. Here's a common construct I've seen:
$line = 0
$names = get-content c:\names.txt
while ($line –lt $names.length) {
  # do something with $names[$line]
  $line++
}
This loads the file into the variable $names and then manually enumerates through the collection as if it were an array. The $line variable keeps track of which line I'm working with. It works fine—but I'm doing a bit more work than I need to do, and I'm making the code a bit more difficult for someone else to read later. The ForEach construct in Windows PowerShell is a bit more appropriate for enumerating collections. (Technically, Get-Content returns a collection, not an array). Try this instead:
Foreach ($name in (Get-Content c:\names.txt))
{
  # do something with $name
}
There are a few advantages here. In keeping with my previous suggestion, I'm putting the call to Get-Content right within the construct, since I think that makes it a bit clearer as to what's going on. ForEach will enumerate through the entire collection, regardless of how long it is. Each time through, it will take the next item in the collection and put that item in the $name variable. So the variable name represents what it contains—a computer name. And that makes the script easier to read and to follow.
Windows PowerShell Q & A
Q Is there a way to define a permanent custom alias in Windows PowerShell?
A If you've ever created a new alias, you've probably noticed that it goes away when you close the shell. For example, this creates a new alias d, which is a shortcut to the Get-ChildItem command:
New-Alias d Get-ChildItem
But when I close the shell, the alias is lost. The trick is to create a Windows PowerShell profile. In your Documents folder, create a new folder called WindowsPowerShell. Within that folder, create a text file named profile.ps1. In that text file, place any commands that you want to execute automatically each time the shell launches—including a new alias definition. The profile ensures that the commands run every time you launch the shell, creating a "permanent" alias that's always available in Windows PowerShell.
I don't need to worry about what line I'm working with or keep a $line variable to keep track of that—the ForEach construct does that for me. Eliminating three lines of code makes the code a bit more succinct and requires you to keep track of fewer things in your head when you're trying to figure out what the script does.

Don't Be So Silent
The one practice I really want to nip in the bud is the practice of suppressing shell errors in an entire script. Say you're looking at a script that includes this line right at the top:
$ErrorActionPreference = "SilentlyContinue"
Stop it immediately.
This doesn't make errors go away, but it does suppress them. Yes, there are certainly times when you will anticipate and want to disregard a certain error, such as when you're using Windows Management Instrumentation (WMI) to connect to remote machines that are potentially unavailable. But there's never a reason to globally disregard errors. Error messages are useful and point out problems that you can sometimes fix.
If you want to disregard errors for a particular cmdlet, you can do so by adding the –EA "SilentlyContinue" parameter to that cmdlet. If you want to disregard errors for several commands in a row, either add the –EA parameter to each or add the $ErrorActionPreference line immediately before those commands and after those commands, add:
$ErrorActionPreference = "Continue"
This sets error handling back to normal.
Personally, I don't like turning off errors at all unless I'm handling those errors myself. For example:
Trap {
  # output error to a log file or something
}
Get-WmiObject Win32_Service –computerName $remote –EA Stop
This brief example shows how the –EA "Stop" parameter will generate true exceptions, rather than just error messages, giving you an opportunity to trap them and handle them on your own. You might log them to a file, display a friendlier error message, or do something else to that effect.

Show Me Your Scripts
As I said, some of these have been a bit nitpicky—but they all offer distinct advantages that are worth consideration. I invite you to share your own Windows PowerShell scripts. I review a couple each month and post my suggestions on ConcentratedTech.com. Feel free to look up some of my past suggestions and maybe even submit your own scripts for review. I look forward to hearing from you!

Don Jones is a co-founder of Concentrated Technology. You can read tips on Windows PowerShell and other IT topics, as well as contact Don, on his blog at ConcentratedTech.com.


Geek of all Trades Setting Permissions from the Command Line
Greg Shields

Contents
Very Many Cacls
Managing Permissions over Time
Envisioning Permissions
An old friend and fellow IT professional has this pointed saying I find myself repeating a lot lately. It relates to how you go about accomplishing the tasks in your daily job—and your career. He says with finger in the air, "IT professionals who don't learn to complete their tasks from the command line won't be IT professionals in the next five years."
Figure 1 A Sample File Server Folder Structure
Now that's a dramatic statement, but it is one every IT professional should pay attention to. No matter whether you're a jack-of-all-trades or you dig deep into a specific focus, getting your hands off that mouse and onto the keyboard is arguably the number one skill you must master if you're to be successful in the coming years. Why the command line? Simply put: efficiency, repeatability, and assurance.
If you manage a technology through its GUI, any action accomplished there effectively evaporates once completed. You just can't reuse mouse clicks. In contrast, completing that action through the command line—whether via a command or a script—enables you to reuse your work over and over.
Nowhere is this more evident than with setting and managing Windows file system permissions, a task we do all the time. We set perms on files and folders. We update and manage our share permissions. From time to time, we might even update object permissions in the registry. All of these are actions that can be accomplished through the explorer or regedit graphical interfaces. But using those interfaces is cumbersome, prone to error, and hard on your wrists. If you've ever gotten most of the way through a long permissions change, only to have it crash on you somewhere in the middle with "Access is Denied," you know this pain.
Permissions modifications through the GUI are particularly problematic due to the sheer number of actors in play. Your small environment may have thousands of individual folders and hundreds of users, any of which can have multiple permissions assigned. Managing the enormous number of potential configurations that can result is no easy task. And if you share the workload with more than one administrator, you can be assured that things will change the very second you finally perfect the perms on a complex folder structure.
The way around these problems is to commit yourself to managing file system permissions from the command line. By taking your hand off the mouse and investing some effort in familiarizing yourself with a couple of tools, you'll be rewarded with a more efficient solution that is infinitely repeatable with complete assurance of success.

Very Many Cacls
The first tool we'll look at is "change access control lists," or cacls, a command line tool that has had a long and fruitful history with the Windows operating system. The original cacls shipped with Windows NT 4.0 and enabled a set of basic capabilities for changing permissions at the command line but was limited in what it could accomplish. To resolve these limitations, Microsoft subsequently released an expanded xcacls in the Windows NT Resource Kit. Later yet, an unsupported xcacls.vbs was released that went further with capability but backward in terms of performance.
The most recent and fully featured version, icacls, ships with Windows Vista and Windows Server 2008 and can be downloaded for Windows XP and Windows Server 2003 at support.microsoft.com/kb/919240. Icacls includes much of the added functionality found in the experimental VBScript but arrives as a dramatically faster EXE. Icacls also adds support for managing Windows Integrity Levels, a secondary layer of access control we won't cover in this article.
Let's assume you are responsible for managing permissions on a file server with a folder structure resembling the one in Figure 1. There you'll see a root folder named Shared that contains the Finance and Marketing subfolders, which contains additional subfolders. You'll also notice that the folders are configured so that increasingly smaller groups of people can access lower-level shares. For example, Finance Users can read information in the Budget folder, but only Budget Users can write to it. A restricted folder is also present at the bottom that no one should be able to see except those with Restricted access. This is a common structure on many file servers today.
You can use icacls to set permissions like those in Figure 1, but exactly how to do this is not immediately obvious. To set the indicated permissions for just the Metrics folder, you would use the following syntax:
icacls C:\Shared\Finance\Metrics /grant:r "Finance Users":(OI)(CI)M /grant:r "Metrics Users":(OI)(CI)M
Unfortunately, with great power comes great complexity. As you can see, icacls' syntax can be quite impenetrable, at least until you understand how Windows permissions work. Remember that an individual permission can be applied to a single folder object or to the object plus its subfolders and files. This is the concept of inheritance. When you apply the simple Modify permission within the explorer GUI to a folder, as in Figure 2, you are actually applying it to that folder as well as all subfolders and files.
Figure 2 Applying Simple Permissions Automatically Sets Inheritance for Subfolders and Files.
In the command line above, you can see that for each group, the M for modify comes after (OI)(CI), which stand for "object inherit" and "container inherit" respectively. Both of these are necessary if you want icacls to apply the simple modify permission. You'll also notice that ":r" is added after the /grant switch. This modifier instructs icacls to clear any directly applied permissions on the object before adding the permissions you set in the command line.
Complex, yes, but Windows permissions are complex. Keep in mind that the end goal—reusable commands—will actually make things much simpler.
To continue the example, let's walk through the entire set of icacls command lines you would use to reset and correctly apply the stated permissions to the Finance folder structure as well as its root:
Icacls C:\Shared /inheritance:r /grant:r "Domain Users":(OI)(CI)R /grant:r
   "File Admins":(OI)(CI)F

Icacls C:\Shared\Finance /inheritance:r /grant:r "Finance Users":(OI)(CI)R /grant:r
   "File Admins":(OI)(CI)F

Icacls C:\Shared\Finance\Budget /grant:r "Budget Users":(OI)(CI)M
Icacls C:\Shared\Finance\Metrics /grant:r "Metrics Users":(OI)(CI)M
The first line actually accomplishes two tasks. It starts with the "/inheritance:r" switch to completely remove all inherited permissions from the folder above so that the Shared folder doesn't inherit. This breaks the Shared folder's inheritance from the folder immediately above it. Once this is done, the Read permission for is set for Domain Users and the Full Control permission for File Admins.
Because we don't want Domain Users to have access to the Finance folder at all, line two breaks and clears the permissions inheritance once again. It then applies the Full Control permission to File Admins and the Read permission to Finance Users.
With lines three and four, we don't want to break the permissions inheritance because both the File Admins and the Finance Users groups should have the same access to these subfolders. In these two lines, we are simply granting another permission—in addition to the existing inherited permissions—so that the Budget Users and Metrics Users can write to these folders.
Setting permissions for the Marketing folder is slightly different. We use the same permissions flow for the Product folder as we did for the subfolders under Finance, but the Restricted folder will be treated a bit differently. Let's suppose that folder contains highly secret documents that should be seen by only a very few individuals. Your first thought may be, "A-ha! Here, I'll use the Deny permissions to prevent the wrong users from accessing this folder!"
But keep in mind that the Deny permissions is actually far too powerful a setting for most situations as it automatically overrides every other permission. Therefore, adding the Deny permission to the Marketing Users group for this folder means that any Restricted users who are also Marketing users would be shut out. A more appropriate solution here is to break the inheritance again and simply eliminate all permissions for the Marketing Users group. Thus, the three icacls command lines required to set the permissions for this structure are
Icacls C:\Shared\Marketing /inheritance:r /grant:r
  "Finance Users":(OI)(CI)R /grant:r "File Admins":(OI)(CI)F

Icacls C:\Shared\Marketing\Product /grant:r "Product Users":(OI)(CI)M

Icacls C:\Shared\Marketing\Restricted /inheritance:r /grant:r
   "File Admins":(OI)(CI)F /grant:r "Restricted Users":(OI)(CI)M

Managing Permissions over Time
So it takes seven lines at the command prompt to set permissions on this simple folder structure. That seems like a lot of work to accomplish relatively little, but consider your IT environment and how things change over time. How many times have you configured a folder structure, only to have some inexperienced fellow administrator make changes while you're away? How many times has your help desk responded to a phone call by blindly modifying your exquisitely designed permissions structure at the whim of a user? These are common problems that are particularly challenging if your environment has too many people with too much access. If you use the mouse and the Windows GUI to keep all these folders straight, you're in for long evenings tracking down changes.
Let me offer you a much better solution. If you spend the extra time up front coding your permissions structure into a command line tool like icacls, reapplying that structure involves little more than double-clicking a batch file. Once you've authored lines like the seven above, keep them around for later use. You'll find that it becomes trivial to revert your permissions structure back to its intended state by simply invoking those lines again.
If built-in automation is more your style, icacls also lets you store and reapply permissions. Once you've applied your equivalent of the seven lines above, run this command:
icacls C:\Shared /save {fileName} /T
Icacls will analyze the permissions structure for C:\Shared and create the file identified in {fileName}. As you can see in Figure 3, the contents of this file are in a binary format and, as a result, the file should not be opened in a text editor like Notepad. However, you can use this file as is to reapply those permissions at a later time. The command syntax to reapply the permissions to the same folder is
Figure 3 Icacls’ Save Function Creates a File that can Reapply Permissions at a Later Time.
icacls C:\Shared /restore {fileName}
With this, you have an easy-to-deploy solution for fixing permissions when they've deviated from your original design.

Envisioning Permissions
As you've seen, icacls is very useful for setting and managing permissions. What it is not so great at is allowing you to see your permissions structure. If you've found yourself walking down the folder tree, right-clicking each folder and choosing Properties to check each object's Security tab, you know what a pain that is. Icacls does have a mechanism for viewing permissions, but its tool is text-based and not entirely useful. If you run the command
icacls C:\Shared /t
icacls will list the permissions on each object in your entire folder structure; however, watching screenfuls of text fly by is no way to find a broken perm.
A far better idea is to download the free AccessEnum tool. AccessEnum is a very simple application that helps you visualize the permissions assigned to a specific folder structure. Specifically, when you target AccessEnum to a top-level folder in a folder tree, the tool scans the files and folders beneath and reports back where permissions are different from the parent.
This difference-based view of permissions helps you find where permissions have been misconfigured. It works because of the natural way in which permissions are set in a folder structure. If you look back at Figure 1, you'll see how well-designed Read permissions typically flow down from the top level. Modify permissions are set at specific levels down the structure as users change from readers to contributors. AccessEnum's difference-based view supports this by hiding permissions that don't change and exposing only those that do. Figure 4 shows an example of how AccessEnum's view might look when applied to this column's sample folder structure.
Figure 4 AccessEnum Helps with Visualizing Your Permissions Structure.
The net result of using icacls and AccessEnum should be a more cohesive application of permissions within your file servers. A further result will be a greater level of data security, as you will be assured your users can access only the files and folders that make sense for them.
This short description only touches the surface of Windows permissions and how they can be applied. Through tools like icacls, you can set permissions that apply to only one folder with no inheritance to the folders below, useful where you want to allow access at a single layer only. You can set integrity levels for data that requires special handling no matter what discretionary controls you apply to it. You can even search for files and permissions across entire structures when necessary. So get your hands off that mouse and start architecting permissions from the command line.

Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Greg's Jack-of-all-Trades tips and tricks at www.ConcentratedTech.com.


Hey, Scripting Guy! Back Up Your Event Logs with a Windows PowerShell Script
The Microsoft Scripting Guys

Hot! Sweltering, sticky, breath-taking humid heat was the first thing Jason and I noticed when we landed at the airport in Kuala Lumpur, Malaysia. Before we had reached the curb, a friendly cab driver had our bags in the trunk and the door open for us. The trip was brisk through palm tree–lined roads that led to Kuala Lumpur City Center ( KLCC). As soon as we entered the highway, we could see the glistening top of the Patronus Towers that mark KLCC from miles away in every direction. We were in town to teach a Microsoft Operations Framework ( MOF ) class to a group of Microsoft employees.
The highlight of the MOF class was an airport simulation that absolutely no one ever got right on the first attempt. But that was part of the point of the class—process improvement. We had taught the class more than twenty times, and no one ever succeeded on the first day. Some classes barely made it through the simulation on the last day of the class. Until now.
At the end of the first day, it was time for round one of the simulation. Jason and I exchanged knowing glances as we gave out the instructions. The students sat with rapt attention, and then as the clock started ticking, instead of the usual loud running around in scrambled confusion, the students quietly got together into a small huddle. They talked rapidly for about five minutes as one student opened up his laptop and began making notes. Then they calmly turned around and proceeded to win the game in the first round.
How did they do it? They simply directed all of their attention to the essential elements of the scenario. They ignored all the nonessential information and created a new process that solved the problem. Because they focused on the core problem, they were free of any complicated work rules, and they were able to focus their energy on the task at hand.
Overly complex work rules can hinder productivity. Today's script grew out of a situation one customer faced in which they were spending several hours a day backing up event logs from various network servers and copying them to a central storage location where they were later backed up to tape. After we got past their complex work rules, we were able to create a custom script that did exactly what they needed. This script saved that customer 10 hours a week and 500 hours a year in labor that they had previously spent managing event logs.
When we take time out from complicated work rules, we can focus more attention and energy on the task at hand, which is to provide IT services. Let's take a look at a script that can be used to back up, archive, and clear event logs across the network. The entire BackUpAndClearEventLogs.ps1 script is shown in Figure 1.
Figure 1 BackUpAndClearEventLogs.ps1
Param(
       $LogsArchive = "c:\logarchive",
       $List,
       $computers,
       [switch]$AD,
       [switch]$Localhost,
       [switch]$clear,
       [switch]$Help
     )
Function Get-ADComputers
{
 $ds = New-Object DirectoryServices.DirectorySearcher
 $ds.Filter = "ObjectCategory=Computer"
 $ds.FindAll() |
     ForEach-Object { $_.Properties['dnshostname']}
} #end Get-AdComputers

Function Test-ComputerConnection
{
 ForEach($Computer in $Computers)
 {
  $Result = Get-WmiObject -Class win32_pingstatus -Filter "address='$computer'"
  If($Result.Statuscode -eq 0)
   {
     if($computer.length -ge 1)
        {
         Write-Host "+ Processing $Computer"
         Get-BackUpFolder
        }
   } #end if
   else { "Skipping $computer .. not accessible" }
 } #end Foreach
} #end Test-ComputerConnection

Function Get-BackUpFolder
{
 $Folder = "{1}-Logs-{0:MMddyymm}" -f [DateTime]::now,$computer
  New-Item "$LogsArchive\$folder" -type Directory -force  | out-Null
  If(!(Test-Path "\\$computer\c$\LogFolder\$folder"))
    {
      New-Item "\\$computer\c$\LogFolder\$folder" -type Directory -force | out-Null
    } #end if
 Backup-EventLogs($Folder)
} #end Get-BackUpFolder

Function Backup-EventLogs
{
 $Eventlogs = Get-WmiObject -Class Win32_NTEventLogFile -ComputerName $computer
 Foreach($log in $EventLogs)
        {
            $path = "\\{0}\c$\LogFolder\$folder\{1}.evt" -f $Computer,$log.LogFileName
            $ErrBackup = ($log.BackupEventLog($path)).ReturnValue
            if($clear)
               {
                if($ErrBackup -eq 0)
                  {
                   $errClear = ($log.ClearEventLog()).ReturnValue
                  } #end if
                else
                  {
                    "Unable to clear event log because backup failed"
                    "Backup Error was " + $ErrBackup
                  } #end else
               } #end if clear
            Copy-EventLogsToArchive -path $path -Folder $Folder
        } #end foreach log
} #end Backup-EventLogs

Function Copy-EventLogsToArchive($path, $folder)
{
 Copy-Item -path $path -dest "$LogsArchive\$folder" -force
} # end Copy-EventLogsToArchive

Function Get-HelpText
{
 $helpText= `
@"
 DESCRIPTION:
 NAME: BackUpAndClearEventLogs.ps1
 This script will backup, archive, and clear the event logs on
 both local and remote computers. It will accept a computer name,
 query AD, or read a text file for the list of computers.

 PARAMETERS:
 -LogsArchive local or remote collection of all computers event logs
 -List path to a list of computer names to process
 -Computers one or more computer names typed in
 -AD switch that causes script to query AD for all computer accounts
 -Localhost switch that runs script against local computer only
 -Clear switch that causes script to empty the event log if the back succeeds
 -Help displays this help topic

 SYNTAX:
 BackUpAndClearEventLogs.ps1 -LocalHost

 Backs up all event logs on local computer. Archives them to C:\logarchive.

 BackUpAndClearEventLogs.ps1 -AD -Clear

 Searches AD for all computers. Connects to these computers, and backs up all event
 logs. Archives all event logs to C:\logarchive. It then clears all event logs
 if the backup operation was successful.

 BackUpAndClearEventLogs.ps1 -List C:\fso\ListOfComputers.txt

 Reads the ListOfComputers.txt file to obtain a list of computer. Connects to these
 computers, and backs up all event logs. Archives all event logs to C:\logarchive.

 BackUpAndClearEventLogs.ps1 -Computers "Berlin,Vista" -LogsArchive "\\berlin\C$\fso\Logs"

 Connects to a remote computers named Berlin and Vista, and backs up    all event
 logs. Archives all event logs from all computers to the path c:\fso\Logs directory on
   a remote computer named Berlin.

BackUpAndClearEventLogs.ps1 -help

Prints the help topic for the script
"@ #end helpText
  $helpText
}

# *** Entry Point To Script ***

If($AD) { $Computers = Get-ADComputers; Test-ComputerConnection; exit }
If($List) { $Computers = Get-Content -path $list; Test-ComputerConnection; exit }
If($LocalHost) { $computers = $env:computerName; Test-ComputerConnection; exit }
If($Computers)
  {
   if($Computers.Contains(",")) {$Computers = $Computers.Split(",")}
   Test-ComputerConnection; exit
  }
If($help) { Get-HelpText; exit }
"Missing parameters" ; Get-HelpText
The first thing we do in the BackUpAndClearEventLogs.ps1 script is use the Param statement to create some command-line parameters for the script, like so:
Param(
       $LogsArchive = "c:\logarchive",
       $List,
       $Computers,
       [switch]$AD,
       [switch]$Localhost,
       [switch]$Clear,
       [switch]$Help
     )
We use several parameters in order to give the script lots of flexibility. The -LogsArchive parameter is used to define the location of the event log archive. We set this to a default location on the C:\ drive, but by using -LogsArchive, you can choose any location that makes sense for your computing environment.
The -List parameter lets you supply a list of computers to the script via a text file. This parameter expects the complete path to a text file containing the computer names. The syntax for the text file is simple; you just place the name of each computer you want to work with on its own individual line.
The -Computers parameter allows you to supply a list of computers from the command line when you run the script. To use this parameter, you place within a set of quotation marks computer names separated by commas. Ideally, you'd use this parameter if you wanted to check just a small number of computers.
Next come four switched parameters. One of the coolest is a switched parameter called –AD, which lets you query Active Directory for a list of computers. It makes sense to use this switch if you are going to check a large number of event logs on all the computers on your network. Of course, on a large network this could take quite a long time. If you want to run the script against your local computer, use the -Localhost switch, which instructs the script to execute against the local machine. Besides backing up the event logs and archiving them to a central location, you can also empty the contents of the event logs by using the -Clear switched parameter. To get Help information, run the script using -Help. We now come to the first function in our script. The Get-ADComputers function is a query used to retrieve a listing of all of the computer accounts in Active Directory. This function does not require any input parameters. When the function is called, it uses the New-Object cmdlet to create an instance of a DirectoryServices.DirectorySearcher class from the Microsoft .NET Framework. We do not pass any information to the New-Object cmdlet, so the DirectoryServices.DirectorySearcher class is created using the default constructor. The new DirectorySearcher class is stored in the $ds variable, as shown here:
Function Get-ADComputers
{
$ds = New-Object DirectoryServices.DirectorySearcher
After we have an instance of the DirectorySearcher class, we can use the Filter property to create a search filter to reduce the number of items that are retrieved. LDAP search filters are documented in "Search Filter Syntax." The attribute we want is called ObjectCategory, and we're looking for a value of "Computer." After we have created our filter, we use the FindAll method from the DirectorySearcher object:
$ds.Filter = "ObjectCategory=Computer"
$ds.FindAll() |
The results from the FindAll method are pipelined to the ForEach-Object cmdlet, which is used to iterate through the collection of DirectoryEntry objects that are returned by FindAll. Inside the script block, delineated by the curly brackets, we use the $_ automatic variable to refer to the current item on the pipeline. We access the properties of the DirectoryEntry object and return the dnshostname:
ForEach-Object {$_.Properties['dnshostname']}
} #end Get-ADComputers
Now we'll create the Test-ComputerConnection function to ensure that the computer is on the network and running. This will prevent timeout issues and make the script more efficient. We begin by using the Function keyword, then specify the name of the function and open the script block:
Function Test-ComputerConnection
{
Next we need to walk through the collection of computers stored in the $Computers variable, which we'll do using the ForEach statement with the $Computer variable as the enumerator. We then open the script block using a left curly bracket:
ForEach($Computer in $Computers)
{
We need to use the WMI class Win32_PingStatus to ping the remote computer. To do this, we use the Get-WmiObject cmdlet and specify the class Win32_PingStatus and create a filter that examines the address property to see if it matches the value stored in the $Computer variable. We store the results of this WMI query in a variable named $Result, as shown here:
$Result = Get-WmiObject -Class Win32_PingStatus -Filter "address='$computer'"
Now we evaluate the status code returned from the WMI query. If the status code is equal to zero, there were no errors and the computer is up and running:
If($Result.Statuscode -eq 0)
   {
For some strange reason, on my computer the query returns a phantom computer that it evaluates as present but that did not have a name. To get rid of the phantom computer, I added a line of code to ensure that the computer name was at least one character long:
if($computer.length -ge 1)
        {
Next we provide a bit of feedback to the user by displaying a status message stating that we are processing the computer. We use the Write-Host cmdlet to provide this feedback:
Write-Host "+t Processing $Computer"
Now we call the Get-BackupFolder function to find the folder to be used for the backup:
Get-BackUpFolder
        }
   } #end if
If the computer is not accessible, there is no point in attempting to back up the event log because we won't be able to reach it. We display a status message indicating that we will skip the computer and exit the function:
else { "Skipping $computer .. not accessible" }
 } #end Foreach
} #end Test-ComputerConnection
After evaluating the accessibility of the computer, it is time to create the Get-BackupFolder function:
Function Get-BackupFolder
{
The next line of code is somewhat odd-looking and therefore a bit confusing:
$Folder = "{1}-Logs-{0:MMddyymm}" -f [DateTime]::now,$computer
We are using the format operator (-f ) to perform some value substitution within the string that we will use for the folder name. The string contains the number 1 in a pair of curly brackets, the word Logs surrounded by dashes, and another pair of curly brackets enclosing the number 0 followed by a bunch of letters.
Let's take this one step at a time. The –f operator performs a substitution of values contained in the string. Just as with an array, the first element begins at 0, the second at 1. The items on the right side of the –f operator are the substitute values that are placed in the appropriate slots on the left side.
Before getting back to the main script, let's take a moment to consider an example to clarify how substitution is done in the script. Notice how we substitute the word one for the {0} portion and the word two for the {1} portion in the following code:
PS C:\Users\edwilson> $test = "{0}-first-{1}-second" -f "one","two"
PS C:\Users\edwilson> $test
one-first-two-second
We probably should have rearranged our code so that the first element was in the first position. Instead, we have written it such that the second element is in the first position, and the first element is in the second position. If we had moved things around a bit, the line of code would have looked something like this:
PS C:\Users\edwilson> $computer = "localhost"
PS C:\Users\edwilson> $Folder = "{0}-Logs-{1:MMddyymm}" -f $computer, [DateTime]::now
PS C:\Users\edwilson> $Folder
localhost-Logs-04070938
The {1:MMddyymm} in the above command is used to supply the current date and time. We don't want the normal display of the DateTime object that is shown here because it is too long and has characters that are not allowed for a folder name. The default display for the DateTime object is Tuesday, April 07, 2009 6:45:37 PM.
The letter patterns that follow the colon character in our script are used to control the way the DateTime values will be displayed. In our case, the month is followed by the day, the year, and the minute. These DateTime format strings are documented at Custom DateTime Format Strings. They were also discussed in a recent article on the Microsoft Script Center, "How Can I Check the Size of My Event Log and Then Backup and Archive It If It Is More Than Half Full?"
Next we create the event log archive folder. To create the folder, we use the New-Item cmdlet and specify the type as Directory. We use the variable $LogsArchive and the pattern that we stored in the $folder variable to create the path to the archive. We use the -force parameter to enable creation of the entire path, if it is required. Because we are not interested in the feedback from this command, we pipeline the results to the Out-Null cmdlet, shown here:
New-Item "$LogsArchive\$folder" -type Directory -force | Out-Null
We also need to determine if the log folder exists on the computer. To do this we use the Test-Path cmdlet, like so:
If(!(Test-Path "\\$computer\c$\LogFolder\$folder"))
    {
The Test-Path cmdlet returns a $true or $false Boolean value. It is asking, "Is the log folder there?" Placing the not operator ( ! ) in front of the Test-Path cmdlet indicates we are interested only if the folder does not exist.
If the log folder does not exist on the remote computer, we use the New-Item cmdlet to create it. We have a hard-coded value of LogFolder, but you can change this. As in the previous New-Item cmdlet, we use the -force parameter to create the entire path and pipeline the results to the Out-Null cmdlet:
New-Item "\\$computer\c$\LogFolder\$folder" -type Directory -force | out-Null
    } #end if
We now want to call the Backup-EventLogs function, which performs the actual backup of the event logs. We pass the path stored in the $folder variable when we call the function:
Backup-EventLogs($folder)
} #end Get-BackUpFolder
Next, we create the Backup-EventLogs function:
Function Backup-EventLogs
{
We use the Win32_NTEventLogFile WMI class to perform the actual backup. To do this, we call the Get-WmiObject cmdlet and give it the class name of Win32_NTEventLogFile as well as the computer name contained in the $computer variable. We store the resulting WMI object in the $Eventlogs variable:
$Eventlogs = Get-WmiObject -Class Win32_NTEventLogFile -ComputerName $computer
By performing a generic, unfiltered WMI query, we return event log objects representing each event log on the computer. These are the classic event logs shown in Figure 2.
In order to work with these event logs, we need to use the ForEach statement to walk through the collection of WMI objects. We use the variable $log as our enumerator to help keep our place as we walk through the collection:
Figure 2 Classic event logs retrieved by Win32_NTEventLogFile
ForEach($log in $EventLogs)
        {
We now need to create the path. Once again, we use the format operator to do some pattern substitution. The {0} is a placeholder for the computer name in the path that will be used for the event logs. The {1} is a placeholder that is used to hold the log file name that will be used when backing up the event log:
$path = "\\{0}\c$\LogFolder\$folder\{1}.evt" -f $Computer,$log.LogFileName
Now we call the BackupEventLog method from the Win32_NTEventLogFile WMI class. We pass the path to the BackupEventLog method and retrieve the return value from the method call. We store the return value in the $ErrBackup variable as seen here:
$ErrBackup = ($log.BackupEventLog($path)).ReturnValue
If the script were run with the –clear switch, the $clear variable would be present and, in that case, we would need to clear the event logs. Therefore, we use the if statement to determine whether the $clear variable is present:
if($clear)
               {
Before we empty the event logs, we would like to ensure that the event log was successfully backed up. To do this, we inspect the value stored in the $ErrBackup variable. If it is equal to zero, we know there were no errors during the backup operation and that it is safe to proceed with emptying the event logs:
if($ErrBackup -eq 0)
                  {
We call the ClearEventLog method from the Win32_NTEventLogFile WMI class and retrieve the ReturnValue from the method call. We store the ReturnValue in the $errClear variable as shown here:
$errClear = ($log.ClearEventLog()).ReturnValue
                  } #end if
If the value of the $ErrBackup variable is not equal to 0, we do not clear out the event logs. Instead, we display a status message stating we were unable to clear the event log because the backup operation failed. To provide additional troubleshooting information, we show the status code that was retrieved from the backup operation:
else
                  {
                    "Unable to clear event log because backup failed"
                    "Backup Error was " + $ErrBackup
                  } #end else
               } #end if clear
Next, we copy the event logs to the archive location. To do this, we call the Copy-EventLogsToArchive function and give it the path to the event logs and the folder for the destination:
Copy-EventLogsToArchive -path $path -Folder $Folder
        } #end foreach log
} #end Backup-EventLogs
Copy-EventLogsToArchive uses the Copy-Item cmdlet to copy the event logs to the archive location. We again use the -force parameter to create the folder if it does not exist:
Function Copy-EventLogsToArchive($path, $folder)
{
 Copy-Item -path $path -dest "$LogsArchive\$folder" -force
} # end Copy-EventLogsToArchive
Now we need to create some Help text for the script. To do this, we create a Get-HelpText function that stores the Help information in a single variable: $helpText. The Help text is written as a here-string, which lets us format the text as we want it to appear on the screen without concerning ourselves with escaping quotation marks. This makes it a lot easier for us to type a large string such as the one in Figure 3.
Figure 3 Get-HelpText Function
Function Get-HelpText
{
 $helpText= `
@"
 DESCRIPTION:
 NAME: BackUpAndClearEventLogs.ps1
 This script will backup, archive, and clear the event logs on
 both local and remote computers. It will accept a computer name,
 query AD, or read a text file for the list of computers.
 PARAMETERS:
 -LogsArchive local or remote collection of all computers event logs
 -List path to a list of computer names to process
 -Computers one or more computer names typed in
 -AD switch that causes script to query AD for all computer accounts
 -Localhost switch that runs script against local computer only
 -Clear switch that causes script to empty the event log if the back succeeds
 -Help displays this help topic
 SYNTAX:
 BackUpAndClearEventLogs.ps1 -LocalHost
Backs up all event logs on local computer. Archives them to C:\logarchive.
 BackUpAndClearEventLogs.ps1 -AD -Clear
 Searches AD for all computers. Connects to these computers, and backs up all event
 logs. Archives all event logs to C:\logarchive. It then clears all event logs if the
 backup operation was successful.
 BackUpAndClearEventLogs.ps1 -List C:\fso\ListOfComputers.txt
 Reads the ListOfComputers.txt file to obtain a list of computer. Connects to these
 computers, and backs up all event logs. Archives all event logs to C:\logarchive.
 BackUpAndClearEventLogs.ps1 -Computers "Berlin,Vista" -LogsArchive "\\berlin\C$\fso\Logs"
 Connects to a remote computers named Berlin and Vista, and backs up all event
 logs. Archives all event logs from all computers to the path c:\fso\Logs directory on
 a remote computer named Berlin.
 BackUpAndClearEventLogs.ps1 -help
 Prints the help topic for the script
 "@ #end helpText
To display the Help text, we call the variable by name:
$helpText
}
Next, we parse the command-line input shown here:
If($AD) { $Computers = Get-ADComputers; Test-ComputerConnection; exit }
If($List) { $Computers = Get-Content -path $list; Test-ComputerConnection; exit }
If($LocalHost) { $computers = $env:computerName; Test-ComputerConnection; exit }
If the $AD variable is present, the script was run with the -AD switch and we therefore populate the $Computers variable with the information obtained from the Get-ADComputers function. We then call the Test-ComputerConnection function, which will determine if the computer is online and back up the event logs. Then we exit the script. If the $List variable is present, we use the Get-Content cmdlet to read a text file and populate the $Computers variable. We then call the Test-ComputerConnection function and exit the script. If the $LocalHost variable is present, we populate the $Computers variable by reading the value directly from the computerName environment variable. We then call the Test-ComputerConnection function and exit the script.
If the $Computers variable is present, it means that the script was run and that the computer names were supplied from the command line. We will need to break these computer names into an array. To do this, we use the split method of the string object:
If($Computers)
  {
   if($Computers.Contains(",")) {$Computers = $Computers.Split(",")}
   Test-ComputerConnection; exit
  }
If the script was run with the -help switch, we call the Get-HelpText function, display the Help, and exit the script:
If($help) { Get-HelpText; exit }
If no parameters are present, we display a message that states we're missing parameters and then call the Get-Help test function:
"Missing parameters" ; Get-HelpText
The BackupAndClearEventLogs.ps1 script can be easily adapted to serve your needs on your network. For example, you could modify the Active Directory query so that it returns only servers from a particular organizational unit, or you could add an additional WMI query to further filter out the machines that are processed. We hope you enjoy the script and can use it where you work. Visit us and the community of scripters on the Script Center at where you can also catch our daily Hey, Scripting Guy! articles.

Ed Wilson, a well-known scripting expert, is the author of eight books, including Windows PowerShell Scripting Guide Microsoft Press (2008) and Microsoft Windows PowerShell Step by Step Microsoft Press (2007). Ed holds more than 20 industry certifications, including Microsoft Certified Systems Engineer (MCSE) and Certified Information Systems Security Professional (CISSP). In his spare time, he enjoys woodworking, underwater photography, and scuba diving. And tea.

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 greatest accomplishment in life to be his magnificent daughter.


Desktop Files Sharing and Synchronizing Your Files
Wes Miller

Contents
Roaming User Profiles
Enter the Mesh
Explicit Synchronization
What's the Cost?
Let's Groove
Problem Files
The Cloud
What does the word roaming mean to you? To me it means, “Wherever I go, there’s my stuff.” Simplistic, but really, isn’t that what would make life much easier for all of us? How often have you been at home and gotten an e-mail from a coworker asking for a specific file, only to be out of luck because your work machine is powered down, or the VPN is too busy because it's an inclement weather day? How convenient would it be if you could always get to the files you need to get to, no matter where you are?
So let's take a look at the roaming technologies out there in the Windows world today, then at the kinds of complexities roaming can bring, including what you need to watch out.

Roaming User Profiles
When I joined Microsoft in 1997, there was no mechanism that let users make sure they had access to their files wherever they were. That changed, to a large degree, with the arrival of Roaming User Profiles (RUP) with Windows 2000 in organizations that deployed Active Directory, and to a larger degree (and a lower pain tolerance), with Windows Vista Folder Redirection.
RUP is still with us and still used in some customer scenarios. While RUP is powerful, it brings with it some significant problems if implemented or used incorrectly. In particular, synchronization works only at logon or logoff time, and it's a last-in wins approach; data loss is potentially a huge problem. Given that a user's data defines the role of a computer, losing that data can be catastrophic.
Moreover, the dependencies mean that there are scenarios where RUP is a pain to work with. In particular, you need Active Directory up and deployed, so it isn't a solution for small businesses and won't work at all for home users. (Microsoft employees with home domains don't count!)
If all of your users are running Windows (ideally they use the same version across their roaming user profile; otherwise there can be some interesting side effects as different Windows versions write their specific settings to the profile), and you have an Active Directory deployed and everyone authenticates against it, you might be a candidate for RUP.
Folder Redirection goes a step further, allowing you to have profiles stored on the server and using Off-line Folders in the OS to synchronize. Better, but still not perfect, especially if you don't have a domain, you are working on a home network, or the users are offline/offsite more often than not.

Enter the Mesh
As you read this, I've been working for about three months on a new Microsoft Press title with Mark Russinovich. Right from the beginning, I've had to deal with a certain problem—I use a collection of machines: two Windows Vista, two Windows XP, and two Macs running OS X 10.5. You never realize just how hard it is to keep a bunch of files synchronized across a bunch of computers, until you have to do it regularly.
In an ideal world, you'd tell a synchronization tool, "synchronize this folder across all of my systems," and it would just work, despite the fact that different Windows versions use a different path for Windows, different user profiles, and so forth, and that their Mac counterparts store files very differently.
Microsoft's latest offering, the beta release of Live Mesh, in fact does exactly this, handling with ease the synchronization of files across disparate machines. Setup is a snap. There's a small installer that must be downloaded to all clients and installed, at which point a small icon is placed in the Windows Notification Area to help you to set up a Mesh, as shown in Figure 1.
Figure 1 The Live Mesh icon is the blue circle in the center of the Windows Notification Area.
Live Mesh works to, in essence, mesh your information. It collects your devices, your data, and your people (contacts) together, no matter where that information is—on one or more of your Windows PCs, Macintoshes, Windows Mobile devices, or even on someone else's computers or devices. Note that in the current release, a system can be a member of only one Mesh at a time. Figure 2 shows how Mesh represents a group of computers online.
Figure 2 The Devices in a Live Mesh
Though you may have added data and devices to your Mesh, nothing is shared yet, even if this is the second or third system, and that's a good thing! Have you ever deployed a new system on Active Directory with Roaming User Profiles and logged on, only to be sideswiped by all of the synchronizing files being downloaded? It's not too bad if you don't roam much, but what if your desktop and documents look like mine? Then you're in trouble.
But Live Mesh lets you decide what directories you want shared, and which systems to share them with. So you can create a directory shared by only two clients, another shared by two more, and then a third shared by everyone.
When setting up a folder in Live Mesh, you can either use an existing directory or create a new one entirely. I tend to create a new directory underneath the Documents directory (or equivalent, depending whether the machine is running Windows Vista, Windows XP, or OSX) and synchronize that.
The nicest part of Live Mesh is that once you've set up new folders, they get offered to other Mesh devices with no effort (ghosted icons are placed on your desktop; double-clicking them lets you specify whether to sync them (now or ever). All of your Mesh folders are available online in your Live Desktop, shown in Figure 3, so you can access them from anywhere. And, the online storage is free. There also is a Windows Mobile version of the Mesh client that allows you to bring data from that device into your Mesh.
Figure 3 The Live Desktop
Live Mesh is elegant in its simplicity, and the fact that it allows cross-platform synchronization between Windows and Mac clients is very convenient. In addition to sharing, Live Mesh also provides the ability to connect back to a Windows Mesh device, as through Remote Desktop.
One of the most compelling features of Live Mesh is the visible logging/auditing that it does. Every change is tracked and shown in a panel that displays next to the folders being shared when they are open.
Microsoft also offers a service called LiveSync (formerly known as FolderShare) that predates Live Mesh. The key difference is that LiveSync (see Figure 4) is much more like traditional file synchronization, and is less about creating a "mesh" or group of linked computers, though it also lets you share folders with other Windows Live users. I encourage you to check them both out and see which fits your scenarios better.
Figure 4 The Live Sync Interface
What if you don't require offline access, but instead need your files to be always available wherever you are, without a download? In that case, Live SkyDrive is a great solution. Live SkyDrive gives you 25GB of free storage on a server where you can place files and access them from anywhere. The difference between Live Mesh and SkyDrive is subtle, but important. With SkyDrive, you actually store data on the server and you retrieve it when needed, more like a traditional sync-less file server.
Microsoft isn't the only synchronization game in town. In fact, Apple's Mobile Me now works cross-platform on Windows as well as Macs—though it is not free like the Microsoft offerings. There are also numerous third-party file synchronization utilities and platforms such as Syncplicity that provide cross-platform synchronization functionality.

Explicit Synchronization
There's something I like to call "explicit synchronization" that involves the use of a particular tool to synchronize a specific file, set of files, or type of files. The best example is an idea I call roaming Favorites. On Windows, Favorites exist as a set of *.url files with meta information about them stored in a binary format in the Windows registry. There are tools today that attempt to accomplish just what I have in mind, including Live Favorites, which lets you sync your Internet Explorer favorites across multiple PCs, and Xmarks, which synchronizes bookmarks across the Firefox, Internet Explorer, and Safari browsers. You can also think of MED-V, discussed in my May article (and it has now shipped), as an explicit synchronizer. We'll discuss how momentarily.

What's the Cost?
Most synchronization platforms are free; or at least free for a certain amount of storage. Most vendors seem to offer 5–10GB of free storage and charge if you use more. Some also put fees in place based upon the bandwidth utilized, more like classic phone line charges.
It is vital to pick a reputable synchronization vendor. The files you want to be able to access from anywhere are often your most critical files. Imagine the horror of a service losing them, then synchronizing, deleting all copies. Not a fun scenario to visualize, or live through.
Similarly, it's important to make sure the communication stream between your system(s) and the synchronizing host is secure. Ideally, verify that your data is encrypted on the host.
Perhaps most crucial is to make sure you aren't violating company policy by roaming company information that shouldn't be external out of your organization. All too often, companies find themselves extricating "remote access" software from PCs that should not have any access. The same issues, or worse, can occur with synchronization solutions outside of the firewall.
References
Configuring Roaming User Profiles
technet.microsoft.com/en-us/library/cc738596.aspx
Managing Roaming User Data Deployment Guide
technet.microsoft.com/en-us/library/cc766489.aspx
Live Mesh
mesh.com
Live Sync
sync.live.com
Live SkyDrive
Skydrive.live.com
Groove 2007
office.microsoft.com/en-us/groove/FX100487641033.aspx
DirectAccess enhances mobility and manageability
microsoft.com/windows/enterprise/products/directaccess.aspx
Microsoft Enterprise Desktop Virtualization (MED-V)
microsoft.com/windows/enterprise/products/med-v.aspx

Let's Groove
Groove, an additional component of the Microsoft Office suite, should not be left out of this discussion. I won't drill into too much detail here, simply because Groove has been covered several times in the pages of TechNet.
Groove is interesting in that it gives you a shared workspace as well as very secure file sharing among corporate users and members of their work team that may not even be a part of the organization or have internal network access. Groove is not free and has additional up-front costs related to deploying, configuring, and maintaining your Groove infrastructure. But it has the advantage of being secure; it is implemented within your organization's view but allows for a method of roaming and sharing that works even outside of the firewall, though only in a manner approved by the organization.

Problem Files
Some file types, such as Outlook PST and Access MDB files, can't be synchronized for the same reason SQL database files or any other proprietary data store is problematic to back up or synchronize—because they may be locked. And some files are simply too large to rationally synchronize (unless the roaming provider supports massively large roaming and very advanced synchronization, and I've yet to see one that does this).
What am I talking about? Virtual machines, even if they are powered off, are extremely taxing for roaming. They are simply too large, and if they are written to every day, the volume of data to be transferred could be simply unfeasible to replicate at any regular interval. Imagine synchronizing a simple 5GB Windows XP VPC image every night. Suppose it's one you use every day, say with an Outlook PST file on it. This is a significant amount of data to sync, and a huge amount of data churn daily.
I'm not aware of any traditional roaming solution that can handle this today. However, this is where you want to consider the right tool for the job. You might want to use RUP or Mesh for your basic file and data synchronization, and then take advantage of Microsoft Enterprise Desktop Virtualization (MED-V) for more advanced needs. By differentiating the workload, you can synchronize everything, allowing users to access VPC images wherever they are, and still manage to keep those images managed and patched.
In this scenario, you are using two tools to complete two tasks. Sure, in an ideal world maybe you'd only need one. But until then, you can combine tools to build the solution you need to synchronize your files to the systems (or handheld devices) you need.
There is no reason you can't use Folder Redirection, Live Mesh, MED-V, XMarks, and even Mobile Me on the same system. But in such a case, it becomes really important (as I've learned myself with Mobile Me) to understand who is the file master, and to make sure that you aren't copying confidential data out of your organization.

The Cloud
We've all heard a growing chorus promoting "the cloud" for Internet-based storage and applications. I expect the next several years to be very interesting as they meld (and to a degree, blur) the cut line between the Internet and your intranet. DirectAccess, in Windows 7 and Windows Server 2008, will surely blur this line further and make synchronization an even more interesting challenge. DirectAccess makes it easier to get to your corporate data without requiring you to place the data in a potentially risky scenario. The use of Internet or cloud-based approaches to synchronization may become problematic for businesses as compliance and security initiatives make delineation between corporate and personal use of systems necessary.
In any case, whether you want to begin roaming your own personal data at home or you're looking for a solution within your organization to allow more creative sharing of and access to files, there is a growing collection of solutions to choose from, with more surely on the way.

Wes Miller is the Director of Product Management at CoreTrace (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.


Security Watch Thoughts on Identity, Part 2
Jesper M. Johansson

Contents
Be Platform Agnostic
Work Well with the User's Cognitive Framework
Guarantee Two-Way Identification
Permit the User to Provide Claims with an Assurance Level Appropriate to the Service Provided
Focus on Consistency of the Claims as Opposed to a Canonical Identity
Don't Mix Trust Levels
Don't Violate Laws or Regulations—or Expectations
Permit All User-facing Attributes to Be Modified or Deleted
Summary
Last month, I embarked on the somewhat daunting task of describing identity systems and, in particular, why we still don’t have an industry standard one. First, I defi ned what identity really is, and why we care about identities in digital systems. Then I covered the problems with identity—notably, the fact that we all have not just one identity, but many. Then I pointed out that if you don't believe you've got enough, you can always create, or buy, a few more.
As discussed, this creates a problem in authentication because we typically think of identity as an ontological identity—a representation of a real, physical person. In most systems, that relationship turns out to be an unnecessary complication. Most identities don't need to be representative of the real-world entity they identify or even identify any real-world entity at all—in fact, it's often undesirable for them to do so.
Finally, I covered how authentication works—specifically, that the really interesting part happens in the socio-technical system where the consumer of some service provides proof of identity. I noted that a successful digital-identity system must fulfill certain criteria and conform to a set of basic principles. In Part I, I covered the first two such principles: "The identity provider is at least as sensitive as the most sensitive relying party" and "Permit the enterprise to protect its customer relationships and to own and control information that it deems as business confidential." Here, in Part II, I conclude the series by covering additional principles that successful digital identity systems must meet.

Be Platform Agnostic
Because they're in business to make money, companies will cater to their customers. They'll endeavor to reduce the amount of "friction" required for the customer to hand over their hard-earned dollars. Any smart business will avoid making requirements of its customers that reduce the customer's likelihood of staying a customer, nor any requirement that reduces the customer base. That means that no mainstream business will use an identity solution that excludes some number of its customers from being able to spend money at the business. Likewise, no rational business is going to implement an identity solution that requires its customers to go to extra lengths to install new software or components to in order to use it.
A similar implementation decision will be made for an identity solution that works for only a subset of customers. Let's say that such a solution costs $5 million to implement. Let's also say that the free cash flow for the business—the proportion of its revenue that is not earmarked for any current development project—is 7 percent of its gross revenues. In this case, the company would need to generate an additional $71.5 million in revenues from the solution just to cover the cost of implementation. That is a significant number, especially if it provides only an incrementally improved solution for a subset of customers. There would have to be a measureable impact to the security of those customers to justify it. Few, if any, identity solutions will meet those requirements.

Work Well with the User's Cognitive Framework
Ultimately, an identity system that people use must work within the human cognitive framework. Surprising as it may seem, human beings didn't evolve to deal with digital identity systems. Nor, it would seem, were they particularly intelligently designed to do so. Many scholars in cognitive science claim that the fundamental wiring of human beings was designed to deal with life in a cave, foraging for food (and mates), and trying to survive attacks by saber-toothed cats. Undoubtedly, mankind has spent a lot longer living in caves than in cubicles and a lot longer communicating with smoke signals than electrons. In cave life, we had little use for digital identities, and, consequently, we didn't evolve with wiring specifically geared to understanding them.
Consequently, our mental model of the world doesn't include managing hundreds of digital identities to safeguard electronic transactions. However, it is perfectly reasonable to assume that people had to use code words while living in caves. Certain words likely had special meaning and got special results. "Please" probably had some kind of forerunner in caveman-speak, just to mention one.
I'm not saying that using code words, or the current equivalent—passwords—is the only reasonable way to authenticate a digital identity. I am saying that if a majority of users is to accept your digital-identity system, it must not require them to change their cognitive model of the world. Cognitive models are largely hard-wired. We can certainly deal with systems that don't fit with cognitive models—but doing so comes at a cost: stress, frustration and anger. Using such a system would have to include a benefit that outweighs the cost of those factors. By contrast, an intuitively obvious system will receive greater levels of adoption even if it provides fewer other benefits.

Guarantee Two-Way Identification
Among the most important aspects of a digital-identity system—and one that, unfortunately, isn't well understood by the users of such systems—is the identification of the relying party and/or identity provider to end users. The relying party—or more commonly, the service provider—is often implicitly trusted by end users. That's why phishing attacks—that is, stealing an identity by posing as a trusted party—are so incredibly successful. It doesn't take much to fool a sufficient number of users to reveal their secrets.
A successful digital-identity system must permit all parties to authenticate themselves in ways that fit the cognitive model of the system user. Unfortunately, this crucial aspect of the system is often ignored by the service providers. In my "Security is About Passwords and Credit Cards" series, I illustrated how a popular credit-card company actively refuses to identify itself to you before you authenticate to it. At this writing, it gives me no pleasure to report that Discover still refuses to show a user a digital identity before requesting the user to authenticate. If you go to the Discover Card Web site, you'll be redirected and asked for your username and password without any opportunity to verify that you aren't sending your credentials to a phishing site. One can only wonder how many Discover accounts have been compromised because cardholders have been conditioned to provider their usernames and passwords to anyone who asks.
On the other hand, it's impossible to argue that SSL has been a successful component of digital-identity systems. The fact that it permits user authentication is virtually unknown, at least to users. The fact that it is primarily designed to prove server identity is ignored by many service providers. Instead, SSL is used as an expensive key-exchange mechanism and as a primary source of revenue to companies that issue the certificates that nobody bothers to inspect. As currently implemented, SSL is failing as a component in digital-identity systems. It doesn't work with the user's cognitive models and while it permits service providers to identify themselves, this identification is presented to end users so poorly that most don't understand how to use it.
A successful end-to-end digital-identity system must make identification of both parties to the transaction an integral part of the authentication workflow. However, a digital-identity system must first and foremost solve the digital-identity problem. Managing digital identities, refreshing digital identities, storing digital identities, transmitting claims proving digital identities, verifying digital identities, and granting appropriate access to digital identities are all problems that are difficult enough on their own. If a digital-identity system can be used to solve other problems as well, that's a bonus—but it shouldn't be among the system's design goals.
A perfect example is phishing. Phishing is a human problem, not a digital-identity one. Phishing attacks human beings, not technologies. Ultimately, the only solution to phishing will be to help people make more intelligent security decisions. An identity system can certainly do that, but not at the expense of the core purpose of such a system which is to help users and service providers identify themselves to each other.

Permit the User to Provide Claims with an Assurance Level Appropriate to the Service Provided
Most users use many different information services. Some services provide highly sensitive information, such as bank-accounts or retirement-savings accounts. Some provide information that may be sensitive in some cases, such as e-mail. Others provide information of value to users' reputation, such as social-networking sites. Still others provide information that isn't at all sensitive, such as a software supplier's technical-support site.
Yet, despite the different levels of sensitivity involved with these services, many try to use the same identity. For example, the same identity I use to access my e-mail is requested every time I try to get product information from my software supplier; if I chose to do so, I could manage my banking information with the same identity. I believe that my e-mail has significant value; my banking information definitely does. Software product information? Not so much. Because I could easily get a salesperson to print it out and even drive 30 miles to deliver it all, I consider that information to have virtually no value at all.
This type of overloaded use of credentials is endemic to identity systems. It is called "single sign-on." In some ways, single sign-on is an appealing concept. In an enterprise environment, it has great business value and, if it isn't already available, it should be added to the agenda right now. Outside the enterprise, where we deal with information of very disparate value, single sign-on is dangerous. If you walked up to your newsstand and the salesperson asked you for two forms of identity before you were allowed to buy your morning paper, you'd surely object, but the same request made before you can withdraw $2,000 from your bank account or drive away in a new car wouldn't raise your eyebrows.
The same separation of claims must be supported by a successful digital-identity system. Users should be able to present a set of credentials appropriate to the level of risk represented by the data or services they arerequesting.
Single sign-on is inappropriate in broadly used digital-identity systems. It's certainly acceptable to use single sign-on to access the system itself, but the actual credentials presented to the relying party—the service provider—must be commensurate with the service the user is receiving. For that reason, it's highly likely that, whatever form a successful digital-identity system takes, it will support a two-layer identity system: one layer to sign into the digital-identity system itself and another to actually identify the user to the relying party. A system that provides this facility nicely is Microsoft's InfoCard system.
Better still, a good digital-identity system should make it easy for the user to submit a set of claims defined for a service to that service, but warn the user when submitting them to another service. In other words, the digital-identity system should help users identify the service providers they are attempting to access.

Focus on Consistency of the Claims as Opposed to a Canonical Identity
A successful digital-identity system must respect the individual's right to privacy. While the exact expectation of privacy differs greatly between cultures, the overall human desire for privacy, however it is defined, is indisputable. You might even call privacy an innate human need. It can easily be considered a safety need, under Abraham Maslow's hierarchy of needs shown in Figure 1. Maslow, writing in pre-Internet times, may simply have excluded it because privacy was not as much of an issue in 1943.
Figure 1 Maslow’s Hierarchy of Needs
If we accept privacy as a human need, or at least a desire, we can discuss that need in the context of a digital-identity system. Consider, for example, a system such as a discussion board about your favorite hobby. Most such discussion boards require authentication; in other words, they implement a digital-identity system. What identity do you use for that board? Do you use your real name or do you go by a moniker such as "Deep Diver 13"? Most of us would probably use some kind of nickname. Requiring us to register a valid phone number and home address for such a purpose would probably be considered a violation of privacy. Requiring us to use a digital identity that maps to our physical person, and which also maps to our health records, is almost certainly going to be considered a violation of privacy.
I've often said that, for most purposes, digital-identity systems need only be concerned with whether a user can lie consistently. A user doesn't have to bind his or her digital identity a given system to a physical identity or even to a digital identity used in another system. Users should be able to conceal their true identities and hide links to other systems, whether at the same sensitivity level or other ones, by using different digital identities.
The system, in essence, must focus on the consistency of the claims presented by the user, rather than on binding those claims to a canonical, typically ontological, identity. As long as the same set of claims is presented, the user should be accepted, and for most purposes, that is all the system requires. Take a retail Web site, for instance. The retailer really doesn't need to care about who a user actually is, unless the laws governing the transaction require it. The retailer needs to care only about whether users can present the same lies today as when they set up their accounts, and whether their methods of payment still work. In most cases, that is sufficient to make a successful transaction. Many identity systems overdo the "identity" part and attempt to tie identity to a person, as opposed to a user.
Perhaps even more important than providing the user the ability to protect his or her ontological identity is the ability to make it easy to manufacture identities. A digital-identity system is, after all, just software. It could very easily help users manage identities to maximize user privacy. A digital-identity system that implements this ability stands a much better chance of success than one that ignores it.

Don't Mix Trust Levels
One interesting feature of the digital- identity systems is that they often require use of an identity provider that differs from the service provider. If the trust the user places in the service provider doesn't match the level of trust placed in the identity provider, there's obvious discord. If the user trusts the service provider, but not the identity provider that the service provider uses, the user may be reluctant to use the service provider for that very reason. An interesting example where this might occur is Expedia.com. Formerly a Microsoft subsidiary, Expedia uses Microsoft Passport, now Windows Live ID, for authentication, as shown in Figure 2.
Figure 2 Expedia supports sign-in with Windows Live ID.
Now let's say that a user trusts Expedia, but not Microsoft. If Expedia required use of Windows Live ID (which it doesn't) would that user be willing to use Expedia at all? Maybe. Maybe not. Whichever the case may be, the user is able to use an Expedia identity on Expedia as opposed to a Windows Live ID one, and some users may prefer that.
Of course, the same trust issue goes the other way. If a user trusts Microsoft but not Expedia, the user may be unwilling to use Expedia if it requires use of Windows Live ID. Perhaps the user has used Windows Live ID for highly sensitive purposes, such as protecting bank-account information through MSN Money. In that case, some users may be reluctant to use the same Windows Live ID that protects their bank-account information to book travel reservations.
This property of a system is very much in line with the previous item about requiring claims in accordance with the sensitivity of the information that they protect. In a nutshell, the user must trust certain parties in any transaction, but the extent to which those parties are trusted may differ. Mixing trust levels is likely to provide users with reasons to distrust the system.

Don't Violate Laws or Regulations—or Expectations
Few issues in information-security management today are as vexing as legal and regulatory compliance. While many security professionals probably don't want to think of lawyers as their best friends, attorneys are becoming absolutely necessary to the cause. Privacy is a matter of law and regulation, and those laws and regulation differ in different jurisdictions.
This raises an interesting issue. Let's say that a particular digital-identity system is actively recruiting relying parties. The identity claims get picked up by a relying party that provides information that isn't very sensitive, such as access to a discussion forum. The relying party provides a level of security for the identity claims commensurate with the sensitivity of the information they serve—in other words, very little. Now let's say that the identity provider signs a contract with a credit-reporting agency, and consequently modifies the claims packet to include a national ID number or some representation of it. This new claim is suddenly being transmitted to the discussion board. The discussion board's security protocols don't provide the security level required for such information, so it may violate various laws and regulations.
These are typically simple issues to work around, and if the remaining principles are followed, it's unlikely that this one will be violated, but it's still an important consideration. Likewise, digital-identity systems that are used across national borders must be sensitive to different rules. Asking for a particular piece of identifying information may be perfectly legitimate in one jurisdiction; asking for the same information somewhere else may be illegal or subject to regulation.
For example, asking for age as part of a digital-identity system makes the identity provider subject to the Children's Online Privacy Protection Act in the United States and similar laws in other jurisdictions. If an identity provider makes that information available to any relying party that doesn't request it, the compliance requirement is transferred to that relying party even if it didn't want the information. Obviously, it's critical that a digital-identity system is capable of respecting those types of laws and regulations and not put anyone in violation.

Permit All User-facing Attributes to Be Modified or Deleted
Finally, a digital identity system must put users in control of their own data. This is perhaps the most controversial of all the principles. The identity providers often view the information they collect as business data. Users, by contrast, consider their names, addresses and other information their personal property to use as they see fit, which might include revoking someone's right to have it.
Clearly, current practices already reject users' rights to completely control access to their information; anyone who has attempted to get one of the three U.S. credit-reporting agencies to delete personal information can attest to this. Even if that information is documented as incorrect, the credit-reporting agencies are usually happy to keep selling it. Accuracy and approval by the subject of the data is irrelevant. Discussing the ethics of a system where someone else is permitted to profit from your identifying information without your consent is beyond the scope of this article, but for a system to be widely accepted by users, a digital-identity system must not put users' information beyond their control.
This means that all information must be modifiable, including aspects such as usernames. A very common type of username is an e-mail address. In spite of the fact that using an e-mail address as an identifier may violate some of the separation principles discussed earlier, it also makes sense to use an e-mail address as an identifier because it's guaranteed to be unique. However, it is also a mutable entity and another person is often granted a previously used e-mail address. That means that the identity system must not only permit a user to modify his or her user ID if it's an e-mail address, but also that the system must deal with problems that occur when new users pick up old addresses. What would happen if a new user tried the forgotten-password feature and received access to another user's account information? That's probably not optimal. Decommissioning an e-mail address is a perfectly valid use-case. The digital identity system needs to deal with this contingency as well as with other changes in information, such as names.

Summary
Clearly, digital-identity systems are quite complicated. Not only are they complicated to build, as we already knew, but the principles they need to comply with to be broadly successful are complex as well. We can draw two conclusions from this discussion. First, digital identity systems must be simplified. We've spent several years trying to design systems that work around users, not through users. Digital-identity systems must provide users with control of their information without making undue requests of them. At the extreme end, they must support users who wish to be anonymous. Likewise, they must not require businesses to expend more on implementing the system than the system is worth.
Second, digital-identity systems must provide identification services that are appropriate to the way they are used. They must provide for multiple levels of claims to support the assurance level required for the systems that those claims are being used to authenticate. In other words, on the Internet as a whole, single sign-on is probably going to be appropriate only to the system used to manage identities—it won't be the identity itself.
Whether we will ever see a single, very successful system that meets all these principles remains to be seen. Most people agree that we are not there yet.

Jesper M. Johansson is Principal Security Architect for a well-known Fortune 200 company, working on risk-based security vision and security strategy. He is also a contributing editor to TechNet Magazine. His work consists of ensuring security in some of the largest, most distributed systems in the world. He holds a Ph.D. in Management Information Systems, has more than 20 years experience in security and is a Microsoft Most Valuable Professionals in Enterprise Security. His latest book is the Windows Server 2008 Security Resource Kit (Microsoft Press, 2008).


The Cable Guy Support for IPv6 in Windows Server 2008 R2 and Windows 7
Joseph Davies

Contents
HomeGroup
DirectAccess
IP-HTTPS
Teredo Server and Relay
Configuring a Teredo Server
Configuring a Teredo Relay
Group Policy Settings for Transition Technologies
With Windows Server 2008 R2 and Windows 7 (now in beta testing), Microsoft continues its platform-wide support for IPv6 with a protocol stack that supports industry standards and built-in applications and services. As with Windows Vista and Windows Server 2008, IPv6 in Windows Server 2008 R2 and Windows 7 is installed and enabled by default. (See the sidebar "The Argument against Disabling IPv6.")
In this column, we'll take a look at the features in Windows 7 and Windows Server 2008 R2 that take advantage of IPv6. In doing so, we'll see how IPv6 can be leveraged to create new and innovative productivity and connectivity solutions.

HomeGroup
HomeGroup in Windows 7 is a new way for computers on home networks to associate with each other and to let family members share documents, pictures, music, videos, and printers. HomeGroup relies on IPv6 connectivity and the Windows Peer-to-Peer Networking Platform on computers running Windows 7 on a single-subnet home network.
For more information, see "At Home with HomeGroup in Windows 7" and view the video.
The Argument against Disabling IPv6
It is unfortunate that some organizations disable IPv6 on their computers running Windows Vista or Windows Server 2008, where it is installed and enabled by default. Many disable IPv6-based on the assumption that they are not running any applications or services that use it. Others might disable it because of a misperception that having both IPv4 and IPv6 enabled effectively doubles their DNS and Web traffic. This is not true.
From Microsoft's perspective, IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows Vista, Windows Server 2008, or later versions, some components will not function. Moreover, applications that you might not think are using IPv6—such as Remote Assistance, HomeGroup, DirectAccess, and Windows Mail—could be.
Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled. By leaving IPv6 enabled, you do not disable IPv6-only applications and services (for example, HomeGroup in Windows 7 and DirectAccess in Windows 7 and Windows Server 2008 R2 are IPv6-only) and your hosts can take advantage of IPv6-enhanced connectivity.

DirectAccess
DirectAccess is a key feature in Windows 7 and Windows Server 2008 R2 that provides remote DirectAccess clients with bidirectional access to intranet resources by using an IPsec-protected connection to a DirectAccess server. DirectAccess leverages end-to-end global IPv6 addressing and connectivity to transparently connect remote computers to an intranet as if they were connected with an Ethernet cable.
DirectAccess clients running Windows 7 or Windows Server 2008 R2 automatically create a protected and tunneled IPv6 connection to a DirectAccess server running Windows Server 2008 R2 whenever a client determines it is on the Internet.
For more information about DirectAccess, see DirectAccess and the Thin Edge Network, and the resources at microsoft.com/directaccess.

IP-HTTPS
6to4 and Teredo are two transition technologies that allow an IPv6 host to tunnel IPv6 traffic across the IPv4 Internet. However, Web proxy servers and some firewalls might block this encapsulated IPv6 traffic. IP-HTTPS is a new protocol for Windows 7 and Windows Server 2008 R2 that allows hosts to establish connectivity through a Web proxy or firewall by tunneling IPv6 packets inside an IPv4-based secure HTTPS session.
IP-HTTPS is used only when the client cannot connect to the server using any of the other standard IPv6 connectivity protocols—native IPv6, Teredo, or 6to4. You can configure IP-HTTPS behavior with Netsh.exe command-line tool commands in the netsh interface httpstunnel context or with the new IP-HTTPS State Group Policy setting described later in this article.

Teredo Server and Relay
Windows Server 2008 R2 includes support for Teredo server and relay functionality. Previous versions of Windows included support only for a Teredo client and a Teredo host-specific relay. To understand what this means, let's step back and review some background on Teredo.
Teredo is an IPv6 transition technology defined in RFC 4380 that provides unicast IPv6 connectivity across the IPv4 Internet for hosts separated from the Internet by a Network Address Translation (NAT) device that does not support 6to4 or native IPv6 addressing. Figure 1 shows the components of a Teredo infrastructure.
Figure 1 Components of a Teredo Infrastructure
A Teredo client tunnels IPv6 packets to either other Teredo clients or to nodes on an IPv6 network, such as the IPv6 Internet, through a Teredo relay or Teredo host-specific relay. A Teredo client communicates with a Teredo server to configure a Teredo-based IPv6 address or to help initiate communication with other Teredo clients or hosts on the IPv6 Internet.
A Teredo relay is a router that forwards packets between Teredo clients on the IPv4 Internet and IPv6 hosts. A Teredo host-specific relay is an IPv6/IPv4 node that has an interface and connectivity to both the IPv4 Internet and the IPv6 Internet and can communicate directly with Teredo clients over the IPv4 Internet, without the need for an intermediate Teredo relay.
Prior to Windows Server 2008 R2, Microsoft deployed Teredo servers and relays on the Internet that Windows-based Teredo clients use by default, and left it to ISPs to deploy additional Teredo servers and relays for their customers.

Configuring a Teredo Server
The DirectAccess Setup wizard automatically configures Teredo server functionality on the DirectAccess server and configures DirectAccess clients to use that DirectAccess server as a Teredo server. To manually configure a computer running Windows Server 2008 R2 as a Teredo server, connect the computer to the IPv4 Internet and configure two consecutive, public, static IPv4 addresses on the Internet interface. For example, configure the Internet interface with the IPv4 addresses 131.107.41.171 and 131.107.41.172. Then, at a command prompt, run the netsh interface teredo set state server FirstIPAddress command.
By default, Windows-based Teredo clients resolve the name teredo.ipv6.microsoft.com to determine the IPv4 address of the Microsoft Teredo server on the Internet. If you deploy your own Teredo server, you must configure your client computers with either the first IPv4 address of your Teredo server or a DNS name that resolves to that same IPv4 address. You can use the netsh interface teredo set state server=NameOrFirstIPv4Address command to configure your hosts with your Teredo server. Alternatively, for computers running Windows 7 and Windows Server 2008 R2, you can use the Teredo Server Name Group Policy setting described in this article.

Configuring a Teredo Relay
Teredo host-specific relay functionality is enabled by default, but the host is acting as an endpoint, rather than a router. In contrast, a Teredo relay forwards IPv6 packets between interfaces corresponding to the IPv4 Internet and an IPv6 network, which could be an intranet or the IPv6 Internet.
To enable relay functionality, you need to enable forwarding on the Teredo interface and the interfaces that connect to your IPv6 network. Examples of such interfaces are an Ethernet interface for a native IPv6 intranet or your Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) interface if you are using ISATAP for IPv6 connectivity on your intranet. Use the netsh interface ipv6 set interface interface=InterfaceNameOrIndex forwarding=enabled command to enable forwarding on the appropriate interfaces.

Group Policy Settings for Transition Technologies
You can centrally configure settings for IP-HTTPS, Teredo, 6to4, and ISATAP through Group Policy for computers running Windows 7 or Windows Server 2008 R2. In previous versions of Windows, you had to configure the equivalent settings through Netsh.exe commands.
You'll find these settings in the Group Policy Management Editor snap-in at Computer Configuration|Policies|Administrative Templates|Network|TCP/IP Settings|IPv6 Transition Technologies. Figure 2 shows the new Group Policy settings.
Figure 2 IPv6 Transition Technologies Group Policy Settings
Setting name | Description | Netsh.exe command equivalent
6to4 Relay Name | Allows you to specify a 6to4 relay name for a 6to4 host. A 6to4 relay is used as a default gateway for IPv6 network traffic sent by the 6to4 host. | netsh interface 6to4 set relay name=
6to4 Relay Name Resolution Interval | Allows you to specify the interval at which the 6to4 relay name is resolved. | netsh interface 6to4 set relay interval=
6to4 State | Allows you to configure the state of the 6to4 client. | netsh interface 6to4 set state=
IP-HTTPS State | Allows you to configure the state of the IP-HTTPS client. | netsh interface httpstunnel set interface state=
ISATAP Router Name | Allows you to specify a router name or IPv4 address for an ISATAP router. | netsh interface ipv6 isatap set router name=
ISATAP State | Allows you to configure the state of the ISATAP host. | netsh interface ipv6 isatap set state=
Teredo Client Port | Allows you to specify the UDP port the Teredo client will use to send packets. | netsh interface teredo set state clientport=
Teredo Default Qualified | Allows you to set Teredo to be ready to communicate. By default, Teredo enters a dormant state when not in use. The qualification process brings it out of a dormant state. | N/A
Teredo Refresh Rate | Allows you to configure the rate at which Teredo clients refresh the NAT translation table. | netsh interface teredo set state refreshinterval=
Teredo Server Name | Allows you to specify the name of the Teredo server. | netsh interface teredo set state servername=
Teredo State | Allows you to specify the state of the Teredo service. | netsh interface teredo set state type=
The DirectAccess Setup wizard uses these Group Policy settings to configure DirectAccess clients with the DirectAccess server as the Teredo server and the ISATAP router. You can also use them independently of DirectAccess to deploy ISATAP on your intranet or to centrally configure 6to4, Teredo, and IP-HTTPS settings for your hosts.

Joseph Davies is a Principal Technical Writer on the Windows networking writing team at Microsoft. He is author or coauthor of a number of books published by Microsoft Press in 2008, including Windows Server 2008 Networking and Network Access Protection (NAP) Understanding IPv6,, Second Edition, and Windows Server 2008 TCP/IP Protocols and Services.


Business of IT Controlling the Business Value Debate
Romi Mahajan

Are questions every truly innocent? In the world of business, I think not.
The questions asked and the answers given drive outcomes in equal measure. The reason is simple—questions don't emerge out of nothing; instead, they arise from a perspective that in many cases predefines the range of "acceptable" answers. The world of the IT professional is plagued by this phenomenon more than the worlds of other professionals, more so in times of economic duress. And the fundamentally misguided question that emerges over and over is, "does IT provide business value?"
Before I expound on this matter, I have my own "guilty" questions to ask. Do you like the treatment you get on a daily basis? Do you believe that IT has value? Do you believe that all of the people who ask the questions are themselves valuable?
So, how to deal with that question of your value?
My first piece of advice is to never answer that question. Answering it cedes the terms of debate to the questioner. The question is not innocent; it is teleological—it asks for the defense of a point that will be contradicted by foregone conclusion. As with a Greek tragedy, the outcome is clear.
My second piece of advice is to engage your interlocutor—but on your own terms. There are a few noteworthy ways of doing this.
The Reductio-Ad-Absurdum Approach When asked to justify the value of IT, immediately and confidently ask the asker what the value of good plumbing, elevators, or Post-it notes is. When he looks at you sheepishly, follow with a direct challenge to quantify the value of parking spaces and non-leaking roofs.
The Condescension Approach When asked the question, immediately respond with something akin to "I don't answer questions of suspect intent." Then proceed to speak in simple terms about the things IT enables. Don't ever legitimize the question; instead offer a speech about the virtues (not value) of IT.
The Inversion Approach When asked about the "business of IT," immediately discuss the "IT of business." In other words, invert the question by reflecting on the fundamental irony of the times in the world of IT, whereby instead of realizing that IT powers business, people ask how business can benefit from IT.
In a previous column ("Reinventing IT in Difficult Times"), I wrote that for modern industry IT is as vital as plumbing. I wrote further that IT organizations are in a difficult era. The neo-Taylorist push for efficiency ( Frederick Winslow Taylor was among the first efficiency experts), coupled with an unprecedented downturn in the economy, has delivered a one-two punch to already struggling organizations. The flight-towards-mediocrity ethos, driven by a semi-religious obsession with overhead reduction, has driven the IT organization—which never quite made it into the limelight it had been seeking—to its current nadir.
Part of the problem stems from our collective acceptance of the terms of debate laid down by others. All revolutions create their own ontology. IT professionals must do so as well.
Modern business is defined by dynamism, requiring the constant tracking of information, both concrete and inchoate. And dynamism requires the democratization of information to enable people to act in real time. It is technology that enables this process. While technology may not be sufficient, it is certainly necessary.
Questions therefore about IT and the IT organization are naïve at best and malicious at worst. Revolutionaries never accept the canards that define the status quo. I am asking each one of you to become one.

Romi Mahajan is Chief Marketing Officer of Ascentium Corporation. Before joining Ascentium, he spent 7+ 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 Cached Credentials
Raymond Chen

If you are logged on to your computer with a domain account, change your password (say from another computer), then lock your workstation, you can unlock it with your old password even though the password has been changed. Why is that?
When you log on, the Winlogon service remembers a hash of that password, and when you attempt to unlock a locked workstation, the password you enter is hashed and compared to the hash of the password you used to log on. If they match, then Winlogon proceeds to unlock the workstation, even though the password might be stale. This behavior is a network performance optimization to avoid inundating the domain controller with authentication requests. Most unlock operations are with the correct password, and avoiding the connection to the domain controller reduces network traffic and significantly improves performance over slow network connections.
But wait, does this mean that you can't lock users out of the network by changing their passwords?
No, you can still lock users out of the network by changing their passwords. The cached password hash is used only for accessing the local workstation. Once the user tries to access a network resource, that network resource will ask the domain controller, "Hey, is this really the guy he claims to be?" and the domain controller will reply, "Nice try."
But wait, does this mean that you can keep unlocking your workstation with a stale password and therefore bypass a password change on the domain controller and thereby keep using your workstation?
Well, yeah, but you could already do that: the trick is called don't lock your workstation in the first place. If you never lock your workstation, then it doesn't matter how the workstation unlocking algorithm works, because it never even runs!
If you would prefer that unlocking a workstation connect to the domain controller to verify that the password has not expired, then you can use the Group Policy Editor to enable the Require Domain Controller authentication to unlock workstation policy.
Note that this one-level password cache for unlocking a workstation is different from cached domain logon credentials. Cached credentials are used when a domain controller is not available to verify a password. Under those conditions, the password entered by the user is compared to the one stored in the cache, and if they match (or more accurately, if the hashes of the hashes match), then the logon is deemed to have succeeded. Whereas the cache for unlocking a workstation is a performance optimization to avoid contacting the domain controller (even though it is available), the credentials cache is a fallback used when the domain controller is unavailable entirely, but you still want to let users access local machine resources.
Cached credentials can be both a blessing and a curse, depending on what color glasses you're wearing. For laptop users, cached credentials are essential for logging on to the laptop when the computer is disconnected from the corporate network. Without them, laptops would just become paperweights when not in the office, which counteracts one of the reasons for having laptops in the first place.
On the other hand, cached credentials permit an offline attack on the information stored in the credential cache. If the laptop falls into unfriendly hands, an attacker can take all the time in the world to try to guess the user's password without your domain controller finding out. Mind you, the credential cache doesn't contain the passwords or even the hashes of the passwords, so a purported "cracked" password is only a probabilistic success (and you can tilt the odds in your favor by requiring strong passwords). Of course, a stolen laptop grants unrestricted physical access to the hacker, so the unencrypted information on the laptop itself is already compromised, password or no password. Even so, if the idea of cached credentials give you the heebie-jeebies (warranted or not), you can set the CachedLogonsCount to zero to disable them. If you combine this with Require Domain Controller authentication to unlock workstation policy, you've got the password caches turned off in both directions.

Raymond Chen's Web site, "The Old New Thing," and identically titled book (Addison-Wesley, 2007) deal with Windows history, Win32 programming, and Krashen's Comprehensible Input Hypothesis.