 TechNet Magazine July 2007

TechNet Magazine July 2007

Communications: Data Protection and Disaster Recovery for Exchange Server 2007

Exchange Server 2007 includes an array of options to support high availability and disaster recovery. Explore the alternatives Exchange has to offer and plan the ideal recovery solution for your organization.

Lee Benjamin Communications: Improve Security with Windows Mobile 6

While smartphones and PDAs offer access to the network from outside the office, they can also expose the network to new vulnerabilities. Here’s a guide to how Windows Mobile 6 and Exchange Server can help protect your company’s mobile devices and infrastructure.

Matt Fontaine Communications: A Powerful Alternative to Public Folders

MOSS 2007 provides a far more powerful solution for sharing data than Exchange public folders, offering enhanced capabilities and easier administration. Take a look at how you can use SharePoint for sharing calendars, contacts, and documents.

Alan Maddison Communications: Log onto Outlook Web Access with Smart Cards

One of the most vulnerable links in the security chain has to do with weak, easily compromised passwords. Learn how you can improve e-mail security by implementing two-factor smart card authentication for your mobile users.

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Windows Administration: The ActiveX Installer Service in Windows Vista

How do you secure the desktop against malicious ActiveX controls without limiting application compatibility? We’ll take you on a tour of the ActiveX Installer Service (AxIS) in Windows Vista that addresses this issue with a new way to manage ActiveX controls.

Rob Campbell and Joel Yoker From the Editor: Six Degrees

Joshua Trupin Toolbox: New Products for IT Pros

Greg Steen SQL Q&A: Inside Clustering, Mysterious Hangs, the SA Account, and More

Edited by Nancy Michell Utility Spotlight: SMSMap

Seeing the whole SMS hierarchy as a picture can help you quickly understand how your infrastructure is laid out. This handy tool automates creation of your infrastructure diagram in Visio via COM.

Jeff Tondt How IT Works: Troubleshooting RPC Errors

Ever been confused by cryptic remote procedure call errors? Take a look at some common errors, techniques you can use to identify errors, and solutions to specific problems.

Zubair Alexander The Cable Guy: IPv6 Traffic over VPN Connections

Before implementing IPv6 support on your intranet, you need to understand how it is supported over VPN connections. Here's a detailed look at what you need to know.

Joseph Davies Windows PowerShell: Rethinking the Pipeline

Don't mistake the pipeline in Windows PowerShell for the UNIX pipeline. The Windows PowerShell pipeline is responsible for far different and far more powerful functionality.

Don Jones Hey, Scripting Guy!: In Scripts, as in Life, Looks Are Important

For scripts that run in a graphical environment, looks are as important as function and performance. Explore techniques for using cascading style sheets to improve the look of your scripts.

The Microsoft Scripting Guys Exchange Queue & A: Edge and Hub Transport Roles, Virtual Machines, and More

Find out how the Edge and Hub Transport server roles differ, take a look at how the setup process has changed for Exchange 2007, find and read the setup logs, and more.

KC Lemson and Nino Bilic Security Watch: Tools for Managing ACLs

Managing ACLs can be one of the more complicated aspects of protecting the security of your users' systems. Here are some useful utilities to help automate and simplify these tasks.

Jesper M. Johansson The Desktop Files: The Microsoft Desktop Optimization Pack

Microsoft Desktop Optimization Pack brings together a number of valuable utilities that Microsoft has recently acquired—and one that was built internally. Explore all of its components and see how they can save your IT department a lot of time.

Wes Miller Windows Confidential: The Healing Powers of Safe Mode

Did you know that besides disabling drivers, Windows safe mode repairs problems that can be repaired automatically? Find out why?

Raymond Chen


 Communications: Data Protection and Disaster Recovery for Exchange Server 2007
Communications Lee Benjamin

Data Protection and Disaster Recovery for Exchange Server 2007
At a Glance:
  • Basic backup and restore
  • Data continuity
  • Replication technologies
  • Alternative solutions

Microsoft Exchange Server was designed with backup in mind. Organizations need to back up their messaging data, and they have to be able to restore that information as well. To meet these needs, Microsoft built a full spectrum of data protection options, from traditional
backup and restore at the low end, to operational continuity, to true business continuity solutions that provide the highest levels of availability and disaster recovery. In this article, I look at those options and help you decide how to implement the best Exchange recovery solution for your organization.

LEVEL 1: BASIC BACKUP AND RESTORE
You can back up Exchange files by taking its databases offline, but you can also back it up while it is running. In fact, the latter is most often the recommended way to back up Exchange. But Exchange is more than a set of files. It is an information store with large database files and transaction logs. Messages sent to Exchange are recorded immediately in the transaction logs and when the system has some spare cycles (usually just a few milliseconds later), the messages are copied into the database itself. By getting the information to disk as quickly as possible, Exchange provides a very high level of recoverability. Fundamental to restoring Exchange is the availability of both sets of information. Should your system fail, it is the combination of a previous backup, along with all of the transactions since that point, that allow you to restore Exchange to the most recent information. Note that Exchange automatically replays transactions into a restored database as necessary.
The way backup programs access information in the Exchange database is through the Extensible Storage Engine (ESE) backup API or newer VSS solutions I will talk about later. Whenever an ESE backup is initiated, Exchange temporarily suspends all writes to its databases. At the same time that ESE temporarily sets the database into a read-only mode that makes it available to be copied in a full backup, it also makes use of a temporary database to hold new transactions that occur during the backup. When the backup is complete, ESE returns the database to its normal read/write mode and applies the transactions that have been accumulating in its temporary database. Backup also purges old transaction logs at the end of a successful backup process.
While this backup process is straightforward and transparent even to users who log on in the middle of the night while the backup is progressing, ESE can take a very long time to complete, especially because Exchange databases can range anywhere from a few gigabytes to a manageable 30 to 50, or even to 100GB—which becomes nearly impossible to back up overnight when using standard technologies. To get an idea of the options available using NTBackup.exe, take a look at Figure 1.
Figure 1 Using the NTBackup utility
Figure 1 Using the NTBackup utility

Best Practices for Exchange
If you want to be able to quickly recover from common hardware and system failures, you should run full Exchange backups nightly. To improve performance and recoverability whenever an Exchange server uses local disks, it is important that you use separate RAID arrays to store the Exchange databases and the Exchange transaction logs. That way, if a RAID array controller fails, or if more than one disk in the array fails so that the remaining disks can no longer reconstruct the striped data, you will still be able to recover. If you lose your transaction logs, you will still have up-to-date Exchange databases on the other drives that will let you continue normal operations with new transaction logs. If you lose the database drives, your recovery strategy is to go back to your previous night’s full backup for the Exchange databases and then apply the current day’s transaction logs to bring it up-to-date.
It is important that you limit the size of your Exchange databases so that each can be backed up—and more importantly, restored—in a reasonable amount of time. For most organizations, that means holding the size of the databases to between 30 and 50GB. When a database grows beyond that size, it is advisable to split it into multiple databases so that restoration will be manageable.

The Backup and Restore Continuum
Placement of the databases and transaction logs is very important—not only for backup performance but also for recovery speed. Today, all servers support various levels of disk drive redundancy, referred to as RAID. Basically, RAID allows a disk drive to fail without crashing the system, though system performance will be slower until the disk is replaced and rebuilt. Until that time, the array controller must reconstruct the data from the remaining disks on the fly in response to each disk access request. For more information on mailbox server storage design, see the Microsoft IT Showcase paper "Going 64-Bit with Exchange Server 2007".
A core feature of Exchange is its single-instance database design. This means that within an Exchange database, only a single copy of a specific message is stored, along with a single attachment (if one exists). If the message was sent to multiple recipients on the same information store, additional pointers to the objects (message, attachment) are created, but the objects are not duplicated. This is not only a great delivery efficiency benefit, but can also be a space saver for Exchange, both on disk and on tape.
While Exchange is good at bringing back the entire database, restoring individual mailboxes, folders, or messages requires bringing back the entire tape first. Not surprisingly, users wanted more granular restore capabilities. The single instance on the tape makes that very hard. Backup vendors responded to this need with the "Brick-Level Backup" (which I do not recommend). After completing a full backup of the Exchange database using the approved ESE Backup API, backup products then add each mailbox to the backup tape. Because the backup API does not provide a way to pull the data from individual mailboxes, MAPI is used. As a result, the backup tape is considerably longer because you are duplicating all those messages and attachments.
Microsoft has made some enhancements that partially address the problem. For example, the administrative wastebasket (or Dumpster) keeps items around for a period of time after they are deleted by users just in case they are needed. In addition, it is no longer necessary to keep a spare server around as an Exchange Recovery Forest; Recovery Storage Groups allow an administrator to partially mount restored databases that have been brought back from tape, and to copy or merge data down to the mailbox level.

Practice Makes Perfect
Many organizations learn the hard way that regardless of the level of backup and recovery they decide on, backup media and recovery procedures must be tested on a regular basis. Too many administrators learn whether their backup technology and restore procedures actually work only after a disaster. The best time to test is the day after you build and configure your shiny new server, when it is operational as part of your Exchange organization but has only a few users on it. At that time you should perform an Exchange Full Backup, regular backups of your drives, and also capture the System state, which includes the critical files on your system disk as well as the IIS metabase (where Exchange routing configuration is held). Then calmly reformat the new server and start over, updating the notes you took when you initially built the server. You should be able to restore settings from the System State, but also have adequate documentation to re-implement system configuration settings manually.
The time you spend on this fire drill will significantly reduce your recovery time in the future. Repeat the process on a periodic basis. While you are at it, time how long it takes to get tapes brought back from offsite. Those who have suffered through that seemingly interminable interval often begin to think more seriously about how disk-to-disk backups can be an important part of their backup and restore strategy—even if offsite tape storage continues to provide their ultimate backstop for disaster recovery.

Challenges of Tape Backup
Restoring from tape takes too much time. Exchange is now so critical to organizations that users and management expect it to always be available. When a serious problem occurs, most organizations are caught off guard. No one is prepared to hear that it will take eight hours to restore that 75GB database from tape—and that doesn’t even include the time spent getting the tapes from the offsite storage facility or reinstalling the operating system.
Moreover, there is also the challenge of retrieving the correct database from tape. In the 10 years since Exchange was first released, the cost of disk storage and wide area networks has fallen considerably. As a result, many organizations can afford faster methods of backup and restore. It’s feasible for these organizations to take advantage of technologies that enable them to gain operational continuity and disaster recovery for their Exchange infrastructure.

LEVEL 2: OPERATIONAL CONTINUITY
Operational Continuity is a set of processes and technologies meant to make recovery as quick as possible, minimizing unexpected downtime. Operational Continuity offers improved Recovery Time Objective (RTO) and Recovery Point Objective (RPO) over tape for local recovery. It strives to eliminate, wherever possible, the time it takes to get tapes back onsite. Take a look at Figure 2 to compare Operational Continuity to backup and restore and DR.
Figure 2 Recovery continuum
Figure 2 Recovery continuum
This diagram illustrates the recovery and availability continuum from slow and cheap at the lower left to fast and expensive at the upper right, with a deliberately fuzzy transition between operational continuity and disaster recovery solutions.
The graph gives you an idea of the tradeoffs between cost, time to recover, and availability across these approaches. In this article, I intentionally make a clear distinction between local continuity processes and disaster recovery. DR is always viewed as remote, with getting the data offsite a primary objective. Distance introduces additional challenges and typically is much more expensive, but DR is about the business continuing after catastrophic events. I will cover this in more depth later.

Some History
As Exchange became a more vital part of the infrastructure and as more information was stored in its databases, it was clear that backup and restore times would need to be reduced. Working with Microsoft, some large organizations came up with an approach that offered a much improved return to partial operations. If an organization could receive and send new e-mail to the outside world, it would appear as if nothing had happened. After all, appearances matter.
To implement this "dial-tone" restore for Exchange, a new empty database was put up in place of the damaged one. Exchange and Active Directory® then created new mailboxes with proper permissions, and users were able to send and receive. Once the backup tape was retrieved and the data recovered, it could be administratively mounted. The Exchange administrator would then merge the restored mailboxes into the dial-tone mailboxes. Mailboxes could be prioritized as needed. Though an improvement, this was a time-consuming and complex process that originally used EXMERGE, and was then adapted to Recovery Storage Groups. It should be noted though, that full data restoration after a dial-tone recovery scenario can be an arduous and complicated task (especially when up to 50 storage groups are possible in Exchange 2007). If you consider implementing a dial-tone recovery scenario, be careful to ensure that the benefits will outweigh the effort.

Volume Shadow Copy Services
To take advantage of cheaper disks and to remove processor overhead from the production Exchange servers, a new backup API was developed for Microsoft® Windows Server® 2003 and Exchange. The Volume Shadow Copy Service (VSS) was created to make consistent point-in-time copies of data. These snapshots are quick read-only copies of the Exchange data that successively include only the data that has changed. The copies usually point to another server with available disk space or to a Storage Area Network (SAN). Multiple snapshots can be kept, with backups made to tape. As a result, the production Exchange server no longer has to suffer the performance impact of the backup software and tape copy overhead.
There are several advantages to using VSS for Exchange data protection. First, the performance load of tape backup operations can be removed from your Exchange server. Though backup to tape still needs to happen, it can use the copy of the Exchange data and not impact user performance. Second, it becomes possible to take snapshots more frequently than once a night. And, as a bonus, you can keep multiple snapshots on the secondary server or other local storage.
There are a number of third-party products on the market that take advantage of the VSS snapshot capabilities. Some simply reduce the time required to back up and restore Exchange databases, while others add capabilities such as more granular recovery than native Exchange includes so you can restore down to the mailbox level. While no one likes such brick backups, people do want to be able to restore specific folders or even single messages.

Replication Technologies
Software-mediated Exchange failover is an option some replication vendors provide. It causes a standby Exchange server to go live and then tells Active Directory that all the users’ mailboxes have moved. There are two ways to accomplish this, both of which require some customizations to Exchange and Windows environments. One involves playing some tricks with your DNS so that the standby server takes over the name and IP address of the failed server. This approach has the advantage of being easy on the client workstations since Outlook® thinks it is still using the same server.
The second approach uses a standby server running Exchange that holds copies of the database but has nothing mounted. In a failure, the standby server informs Active Directory that all user mailboxes have been moved to it. Then a script is run, or a Group Policy is distributed, that tells the clients they are on a different mail server. Outlook 2007 is Active Directory-aware, which makes the process easier because it will automatically figure out these mappings on its own.

Local Clustering with MSCS
Higher in the availability continuum is Microsoft Cluster Services (MSCS); Exchange is a cluster-aware application. Clustering shares information between two or more computers so that if one fails, the others can take over. Today most Exchange clusters are two or four nodes, though up to eight nodes can be used. One node is always designated as passive—operational with Windows Server running and Exchange Server installed, but with no active mailboxes. A two-node active/active cluster was possible in Exchange 2003, but due to performance loads, is now discouraged and will not be supported on Exchange 2007.
As with the Exchange 2003 cluster arrangement, the Exchange 2007 clusters that include a passive node can still use a single shared storage array. Though cluster-quality storage arrays typically have a number of redundancy features to withstand many types of failures, they still provide only one copy of the data, which leaves a window of vulnerability open. That’s why these clusters are called single-copy clusters (SCC), to distinguish them from the next frontier in data protection that arrives with multiple-copy clusters (MCC) in Exchange 2007. We will discuss MCCs further when we look at disaster recovery.

Local Continuous Replication
Local Continuous Replication (LCR) is a new feature of Exchange 2007 that provides an improved way of maintaining a second copy of the Exchange databases and transaction logs within the same server. This adds a layer of redundancy to the best practice of having the Exchange database on one RAID array and the transaction logs on another: LCR makes it possible to store a secondary copy of the logs on the array that stores the primary copy of the database, and then store a secondary copy of the database on the array that stores the primary copy of the logs (see Figure 3). If either the RAID controller or the array fails, you still have your database and transaction logs on the other array. In this way, you can continue operating—albeit somewhat nervously and with some performance degradation—until you are able to rebuild your failed array.
Figure 3 Configuring LCR
Figure 3 Configuring LCR
LCR is a local operational continuity solution, not a backup solution, so you will still need a full backup strategy. With LCR, there is also a performance hit because your server will now be making two copies of the database and transaction logs. Furthermore, in the Exchange 2007 implementation, there are some limitations that will make LCR suitable only for smaller organizations because LCR supports only one database in a storage group and only one public folder database in an organization.
Failover using an LCR recovery is not instantaneous—a knowledgeable IT professional will have to run scripts to get Exchange back up. The process requires executing Exchange Management Shell commands that are run outside the Exchange management console.
Where Exchange Server 2003 Enterprise Edition enabled an organization to run up to 20 Exchange databases (four storage groups of up to five databases each), Exchange 2007 Enterprise Edition allows up to 50 storage groups, each with its own database. The transaction logs have also been reduced from 5MB files in Exchange 2003 to 1MB files in Exchange 2007. Both of these changes are designed to support LCR—plus cluster continuous replication (CCR), which will become relevant in a bit.
Small- and medium-size organizations will use LCR in order to provide improved data protection for their Exchange operations. LCR is easy to implement but still involves manual intervention. As a same-server/local-disk solution, LCR is only a first step toward improved operational continuity. While it does protect against failures of a RAID array and RAID controllers, multiple simultaneous disk crashes or RAID controller failures are relatively rare. A majority of the time, failure scenarios involve the collapse of the entire server, which takes us to the next step in Exchange protection.

Third-Party Local Off-Host Replication
To further the recovery capabilities of Exchange, third-party vendors have developed products that take advantage of "off-host" replication using the Exchange log files to keep a standby copy of the Exchange database on another machine. In this case, the data protection or archiving solution performs an ESE full backup of Exchange to a different computer and then pulls transaction logs as soon as Exchange closes them. It inserts those transactions into its Exchange database copy so that it is always up to date. As I’ve noted, these logs are relatively small (5MB in Exchange 2003 and 1MB in Exchange 2007) so that once the full backup is completed, there’s almost no overhead on the Exchange server in copying these log files to the off-host server.

LEVEL 3: DISASTER RECOVERY AND HIGH AVAILABILITY
Disaster recovery is the ability to get back up and running if the major data center becomes unavailable. Exchange merits effective disaster recovery because e-mail and calendar functions are the lifeblood of many organizations today.
Some companies imagine that their traditional tape backups stored offsite are a form of disaster recovery, but if your sole data center is destroyed by fire or flood, a van returning with spools of tape is of little value. Disaster recovery necessarily involves moving not only your data to an alternate location, but also the technology and processes to bring the application back up and running. To be effective, disaster recovery relies on separating primary and secondary systems by some distance. How far apart the sites should be depends on the magnitude of disaster you are concerned with surmounting. If you’re worried about fire, perhaps another building on your campus is sufficiently remote. However, infrastructure disasters involving trains or airplanes could affect a radius of a mile or more. Many disasters are regional: floods, ice storms, earthquakes, and even power outages. Communications can suffer its own calamities—anything from a backhoe that severs the link to your ISP, to denial of service attacks, to Internet DoS attacks aimed at commerce in general.
As a practical matter, if your organization already has more than one site with IT staff, one of those locations might meet your criteria for remote operational continuity, given the types of disasters you are defending against. Using your own facility and staff will be far less expensive than contracting with a disaster recovery provider or renting space in a new location.
Ultimately, disaster recovery is also about perception: giving customers the confidence that you are still in business. People are understanding when a disaster hits a city or area, but if your company is not back online within a couple of days to a week, chances are that customers and suppliers will believe the worst; many companies fail for that reason. To the customer, your operation must look like it is recovering to assure them your business is continuing. Customers will have different ideas regarding timely recovery: they are understandably less patient with outages at their financial services companies than with, say, outages at their suppliers of office furniture.

Disaster Recovery Demands
Being able to get Exchange back online after a disaster requires replicating its data to the secondary site and using replication technology that is prepared to present the data to a warm Exchange server that’s ready to run with it, then notifying the Outlook clients that their mailboxes have moved.
Exchange is a demanding application to replicate, particularly over long distances. As a true transactional database, the order of each write is supremely important. Complicating the challenge, the transport protocol Exchange uses to communicate all transactions and system information between servers is SMTP, a known bandwidth-intensive protocol. Furthermore, with Exchange clusters a heartbeat must be maintained between systems every 500 milliseconds. If a secondary node doesn’t receive that heartbeat, it may trigger the start of a failover.
The complexities of managing such challenges may be why Microsoft is only now entering this space with Exchange 2007. In the absence of a Microsoft entry, several third-party solutions have been developed to replicate Exchange data using host-based or array-based replication.
Vendors realized they could extend a cluster by dispersing nodes to different locations; this is called a stretch cluster. Today, the most common way to implement stretch clusters is through general-purpose third-party data replication products or those specifically geared to stretch an Exchange node. You can do this with MSCS, but the subnet requirement is challenging over a WAN. Clustering and the complexities of provisioning reliable high-bandwidth connectivity to remote data centers understandably increase the cost and staffing requirements to build, maintain and periodically test disaster recovery systems.

Cluster Continuous Replication
Microsoft extends its cluster support with cluster continuous replication in Exchange 2007. CCR extends LCR’s ability to maintain two copies of an Exchange database and transaction logs to implement the same idea on two cluster nodes. Disaster recovery implies geographic separation of primary and secondary systems, and the Microsoft multi-copy-clusters (MCC) won’t be able to span significant distances until Windows Server 2008, formerly code-named "Longhorn," makes stretch clusters possible.
The technology that enables MCC nodes to have separate copies of the data is called majority node set (MNS), which refers to the election process that the two or more nodes conduct to determine which holds the live copy of the data. When there is a failure, the remaining nodes hold a new election to determine which will take over as the new primary processing/data server. Supporting this technical democracy is CCR, which makes sure that each node has an up-to-date database. Exchange 2007 clusters using CCR are limited to two nodes only.
In larger shops, Exchange servers typically configure the local system disk on the server itself and then connect to the Exchange database over a SAN using either SCSI, fiber, or iSCSI disk arrays. With an MCC/MNS cluster, an interesting question is whether high-end Exchange storage will evolve back to using local RAID arrays for each node. If the purpose of an MNS cluster is to enable each node to have its own separate storage, will it still make sense to point each node to a SAN whose main purpose is to provide common storage?
A likely middle-of-the-road MCC/MNS cluster scenario would have the primary node with storage on the SAN, and a secondary cluster node with either local disks or a lower-cost iSCSI SAN. This secondary node could be remote from the primary datacenter, in a location that does not have a SAN infrastructure.
Regardless of how that shakes out, MCC using MNS and CCR are another step up in the hierarchy of redundancy and enhanced availability because multiple computers are able to fail over and the data is replicated on separate storage elements. This is still entirely confined within a single data center until Windows Server 2008 arrives, however. Windows Server 2008 will natively support stretch clusters, enabling nodes in an MNS cluster to be geographically separated as far as desired—provided that the network latency between nodes is reliably less than 500ms. Until then (and beyond), third-party cluster technology can sit on top of Microsoft MNS and CCR to provide the geographic separation needed to stretch clusters to be an effective disaster recovery solution.
Clustering is at the high end of the continuum of disaster recovery, and CCR is properly positioned as a high-availability capability of Exchange. And even though the combination will have cost and staff overhead, it promises to be an exciting top-of-the-line solution for customers who want to operate a homogeneous Microsoft environment.

Third-Party Remote Operational Continuity
There is no doubt that the Microsoft solution and third-party extensions will occupy the very high end of the recovery continuum when it becomes available. Automatic failover within seconds—that’s about as good as it gets. Yet not every company needs that level of availability and business continuity, nor can they afford to invest the hundreds of thousands of dollars necessary to deliver it. For many companies, a reliable solution that fully restores Exchange in minutes will deliver all of the operational continuity that they require.
As an example, Mimosa Systems, Inc. extends the operational continuity within a single datacenter to remote continuity. At a remote location, Mimosa DR maintains a copy of Exchange, keeps it current with the transaction logs shipped from the primary Exchange server, and is always ready to make this live copy available to your standby Exchange server. The remote Exchange server uses standard server hardware and, just like the single-data center implementation, you keep it warmed up and always ready to be activated in the event of a disaster. Should disaster strike, an operator at the remote site initiates the failover and performs the failover including mounting the standby database files, remapping mailboxes and Outlook profiles. It should be noted though that such third-party solutions are subject to the support boundaries defined in the Knowledge Base article "Microsoft support policy for third-party products that modify or extract Exchange database contents".

Wrap-Up
Exchange data protection is available as a continuum of technologies and procedures that can be grouped into three levels based on cost and capabilities. As you begin to think about their requirements for Exchange data protection, you should consider how much downtime your stakeholders are able to tolerate. Greater performance and faster recovery cost more, with high-end options well into six figures. More affordable solutions exist that approach, but don’t quite reach, the highest levels of availability. The choices you make should reflect the true needs of your organization.
Service Pack 1 for Exchange 2007
Currently in beta testing, Service Pack 1 (SP1) for Exchange 2007 is slated to include a number of features that administrators have been missing, including enhancements to OWA, additional GUI capabilities in the Console, and more.
Of particular interest to administrators planning recovery solutions, Exchange 2007 SP1 also includes a third availability solution to complement LCR and CCR: Standby Continuous Replication (SCR). This is a middle-ground approach and Microsoft looks to that sweet spot of greater recoverability, without the complexity of full "high availability."
SCR will allow replication of the Exchange database and transaction logs to a different Exchange server than the one where your mailboxes typically reside. The SCR target can be local or remote, and can be a standby Exchange server or a cluster. However, SCR does not require a cluster in either location and it differs from CCR in that the target is a standby environment and the failover is a manual process. Note that you still need to get that first large copy over the wire—essentially a full backup. You may need to do this large replication from time to time and must be aware of the implications on your network, just as with CCR and third-party solutions. I expect to see significant adoption of both SCR and CCR, and of add-on products that provide similar and sometimes greater capabilities.

Lee Benjamin runs ExchangeGuy Consulting Services where he works directly with customers and advises Microsoft Partners. Lee is chairman of the largest Exchange user group in the world, ExchangeServerBoston, and a director for BostonUserGroups. Lee is also an MVP for Exchange, a Microsoft Certified Trainer, and a regular speaker at industry conferences.
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 Communications: Improve Security with Windows Mobile 6
Communications Matt Fontaine

Improve Security with Windows Mobile 6
At a Glance:
  • On-device security
  • Exchange Server security
  • Network security

Mobile devices increase the productivity of workers around the world, giving them access to corporate information and keeping them connected even while they’re away from the
physical office. The productivity increases are real: just turn on the mobile device and get to work.
On the other side of that coin are the IT professionals who are challenged with the difficult task of keeping the virtual office secure and stable. From their perspective, every mobile device is a potential network security leak to be plugged and a potential data theft liability. Building a more secure deployment of mobile devices is crucial, but must also be balanced with providing a seamless and intuitive user experience.
Microsoft® Windows Mobile® 6 and its predecessor, Windows Mobile 5.0 with the Messaging and Security Feature Pack (MSFP), include many features that help you secure corporate infrastructure with minimal difficulty—and with minimal inconvenience for your users. Using Microsoft Exchange Server as the messaging platform further increases the security options available. In this article, I demonstrate how you can use Windows Mobile, Exchange Server, and some network security best practices as a foundation for protecting your company’s mobile devices.

Mobile Communication Architecture
There are three layers to consider when planning or upgrading a mobile deployment: the device, the message server, and the network (see Figure 1). At the device level, key challenges include allowing only authorized access to the device and preventing unauthorized applications on the device. Windows Mobile helps prevent unauthorized access to the device itself through PIN authentification and password protection, device timeout locking, and the ability to "wipe" or erase the device’s memory either locally or remotely if it is lost or stolen. Data encryption of the communication channel and removable storage is supported. Preventing unauthorized applications such as viruses or spyware from being installed or accessing critical parts of the device is also essential. Management role definition, application access tiers, code signing settings, security settings, and security certificates combine to help achieve device-level protection.
Figure 1 Layers of mobile communication
Figure 1 Layers of mobile communication
The next security layer is the messaging server, such as Exchange Server 2003 with Service Pack 2 (SP2) or Exchange Server 2007. This layer includes both message security—the technology by which messages are transmitted securely to and from devices—as well as the interaction between the message server and the mobile device via Exchange ActiveSync®. Exchange Server is not required to use Windows Mobile devices, but using Exchange offers cost, scalability, performance, and administrative advantages.
Good device-level and messaging server security practices are key, but protecting the network layer is also critical. By configuring your corporate network according to best practices and implementing strong security protocols, you can help prevent damage to the network even if one or more mobile devices are compromised.

On-Device Security Policies
The first line of defense against security breaches is the Windows Mobile-powered device itself. The Windows Mobile operating system provides extensive device-level security services supporting authentication, storage card encryption, virtual private networking (VPN), Wi-Fi encryption, and secure sockets layer (SSL) services. Device-level security involves managing who has access to a device and its data, controlling which applications can run on the device, and establishing how data is transmitted to and from the device. In general, administrators have a good deal of flexibility in setting and enforcing security policies on both Windows Mobile 5.0 with MSFP and Windows Mobile 6.
User access is managed through a PIN or password authentication. A device can be set to lock automatically after a period of inactivity or after being turned off, requiring a user to unlock the device again to use it (see Figure 2). The specifics of user access control are set by security policies, which can be changed depending on the administrator’s security role.
Figure 2 Setting password policies
Figure 2 Setting password policies
Security policies define global levels of security for the mobile device (see Figure 3). Who can set and change these security policies is determined by security roles. The Manager role, usually reserved for mobile operators, provides complete control over security policy settings. The Enterprise role is used by Exchange to manage some device policies, which are configured by the Exchange administrator. Depending on your agreement with the device provider, you may be able to customize security policies for your company.
Figure 3 Security policies for mobile devices (Close Figure 3)

Policy Mobile Device
Block unauthorized penetration into device

Windows Mobile 5.0 with MSFP

Specify that the user must always authenticate on the device to unlock it or allow the user to enter a PIN on the desktop.
Default role: Manager, Enterprise.

Windows Mobile 6

Allow or deny the user permission to change mobile encryption settings for removable storage media.
Default role: Manager, Enterprise.
Specify whether or not the user must authenticate on the device when connected if device lock is active. Default role: Manager, Enterprise.
Protect sensitive data in case of device theft or loss

Windows Mobile 5.0 with MSFP

Specify that the user must always authenticate on the device to unlock it or allow the user to enter a PIN on the desktop.
Default role: Manager, Enterprise.

Windows Mobile 5.0 with MSFP and Windows Mobile 6

Specify whether a password must be configured on the device. Configure local and remote device wipe settings.
Default role: Manager, Enterprise.
Customizable authentication methods used by Windows Mobile are controlled by Local Authentication Plug-Ins (LAPs), which interact with the Local Authentication Subsystem (LASS). This technology allows Exchange Server to control the device configuration at a granular level—for example, by enforcing password length and strength requirements or enabling simple PIN authentication.
Windows Mobile 6 has an expanded set of LAP functions that are configured using Exchange Server 2007. You can enable PIN pattern recognition (for example, denying use of simple patterns such as "1111" or "1234"), configure password or PIN expiration periods, allow users to request a PIN reset based on certain conditions, or keep a PIN/password history to prevent users from re-using old PINs or passwords when they are called upon to create a new one (see Figure 4).
Figure 4 Enforcing PIN and password usage
Figure 4 Enforcing PIN and password usage

Protecting Data on Devices
In the event that an incorrect PIN or password is entered more times than the limit set by the administrator, the local device-wipe feature hard-resets the device, erasing its memory—including user authentication credentials. The limit is set as part of the security policies in Exchange Server. After every two incorrect entries, the device prompts the user to enter a structured key string to continue. This prevents the device from being wiped accidentally because of random key presses. Remotely wiping the storage card is also possible when using Windows Mobile 6 and Exchange Server 2007.
Locking down a device isn’t much good if someone leaves a 2GB storage card filled with sensitive corporate data in a taxi. Fortunately, you can use Windows Mobile 6 to deal with this problem as well. It can encrypt storage card data so that only the device that wrote to the storage card can read it. As with many other enhanced security features of Windows Mobile 6, Exchange Server 2007 can be used to provision this security feature over the air. Storage card encryption is largely transparent to the user. Exchange Server 2007 lets the administrator choose whether users can change their storage card encryption settings.
Whether or not applications can run on a Windows Mobile device is based on three levels of permission: Privileged, Normal, and Blocked. Privileged-level applications (signed by a certificate in the Privileged certificate store) can write to the registry and system files, and can also install certificates. As with a desktop PC or server, the more applications that can alter the operating system environment, the greater the chance of compromising that environment. Reducing the number of applications with Privileged access is generally good practice. Most applications only need to run at Normal level (apps that are either signed by a certificate in the Unpriv certificate store or unsigned applications that the user has agreed to run), which allows them to execute but prevents access to system files. Blocked applications are just that—they are blocked and cannot run due to incorrect signing or user action.
Devices can have either a one-tier or two-tier security access configuration. With a one-tier access configuration, unsigned applications are either run with Privileged access or are blocked and simply cannot run. A two-tier access configuration will run unsigned applications at normal level if policy checks successfully or if the user allows the application to run. Depending on device settings, the user can be prompted as to whether to execute an unsigned application or not.
Digital certificates—one of the most commonly used forms of personal, device, and application authentication—are a crucial piece of Windows Mobile security on the device, server, and network levels. The Windows Mobile operating system stores several types of certificates in different certificate stores on the device. With regard to applications, certificates determine which ones can be installed and run. For an application to run on a Windows Mobile-powered device without the user being prompted, it must be signed with a certificate proving that it was accepted by the Microsoft Mobile2Mobile program. Applications are granted permission levels based on which certificates they have associated with them.
For network authentication, each mobile device comes with a number of trusted commercial root certificates issued by a Certificate Authority (CA) as shown in Figure 5. The messaging server (for example, Exchange Server) verifies the authenticity of a device’s root certificate before establishing an SSL connection with that device. If your company uses custom certificates, you may be able to install them on the Windows Mobile-powered devices you purchase, or you may have to create new certificates. I’ll discuss this further in the Network Security section of this article.
Figure 5 Managing digital certificates
Figure 5 Managing digital certificates
ActiveSync and Internet Explorer® Mobile can use SSL to help secure data transmission between the device and a corporate Web server. This is true whether the connection exists to synchronize Microsoft Exchange data, configure the device, or download applications. SSL encrypts the communication channel with 128-bit RC4 or 3DES ciphers so data cannot be read by outside parties. Windows Mobile also supports VPN, which uses packet encryption to provide security similar to a dedicated line while accessing a server over the Internet.

Exchange Server Security
While Windows Mobile-powered devices don’t require Exchange Server to function, the two systems have been designed to work closely together and present a robust end-to-end mobile messaging and productivity solution. Since the release of Windows Mobile 5.0 with MSFP, ActiveSync has been enhanced to allow remote management of Windows Mobile device settings. It provides an easy yet powerful means to propagate and enforce global security settings across most Windows Mobile devices.
ActiveSync runs on IIS, the application/Web server component of Microsoft Windows Server 2003. IIS provides built-in security that helps protect ActiveSync itself from attacks arriving through the network. Because Microsoft Office Outlook® Web Access (OWA) is also based on IIS, you can use the same security certificates for both ActiveSync and OWA.
When ActiveSync is used to propagate an Enterprise policy, that policy is delivered to devices the next time they are synchronized with Exchange Server. Users must accept the changes or they are not allowed to connect to the server. Many networks deal with a wide range of devices, including legacy hardware that is unable to accept sophisticated security policies. If necessary, you can exempt certain devices, such as legacy hardware, from the security policy requirement so they can continue to connect.
Exchange Server 2003 SP2 and Exchange Server 2007 have somewhat different security policy control capabilities. Exchange Server 2003 SP2 can be used to specify a minimum password length from 4 to 18 characters, require both numbers and letters in a password, and set how long a period of inactivity is allowed before a device locks. This version of Exchange Server can also set how often security settings are pushed to devices, as well as allow the aforementioned exemptions for legacy devices.
With the release of Exchange Server 2007, the ActiveSync mobile device management capabilities have been enhanced to include all the Exchange Server 2003 SP2 capabilities, plus the following:
  • Allow or disallow simple passwords (such as "1234" or "1111")
  • Enable or disable attachment downloads
  • Require storage card encryption
  • Set maximum attachment size
  • Enable recovery of a device password by the user via OWA
  • Enable access to Universal Naming Convention (UNC) and Microsoft Windows SharePoint® Services (WSS) files
With Exchange Server 2007, IT professionals have the flexibility to tailor policies to each user or device, to manage policies for groups of users, as well as to exempt specific users from security policies altogether.

Remote Access Wipe
In addition to the local device wipe detailed earlier, you can wipe a Windows Mobile powered device remotely using Exchange Server 2003 SP2, Exchange Server 2007, or OWA. Remote wipes, which take place upon synchronization, can be performed even if you’re not using ActiveSync security policies. A remote wipe hard reset cannot be stopped from the device. Data, settings, and security keys are overwritten with repeated zeros, making it extremely difficult to recover any data not part of the core operating system.

Network Security
Network security is just as important to mobile security as the device and messaging server components. It is also the part of the mobile infrastructure that is most clearly in your control. Even if one or more mobile devices happen to get compromised, configuring your corporate network according to best practices and implementing the right security protocols can help prevent damage to the network.
Windows Mobile works well with a variety of network types. Using standard Internet security protocols and firewalls, you can design a solution that suits your needs for performance, stability, and security.
When messaging servers are kept within the corporate network, they can be protected by an edge firewall that acts as a buffer between the Internet and the corporate servers. Microsoft Internet Security and Acceleration (ISA) Server 2004 or ISA Server 2006, both of which have features designed especially for this purpose, inspects all incoming packets to determine their identity before passing them along to the Exchange servers, and then sends outbound information back to the client via the Internet.
Configuring ISA Server requires that you enable SSL encryption and designate port 443 as the SSL Web listening port for Exchange Server traffic. This minimizes exposure to the Internet by limiting it to a single port. Also, all clients should be required to establish an SSL link before connecting via ActiveSync.
ISA Server can pre-authenticate users of Web applications like OWA to help prevent unauthenticated users from reaching the application servers. ISA Server 2006 improves the SSL bridging model of ISA Server 2004 by acting as the SSL termination point for Windows Mobile-powered devices. This allows Windows Mobile-powered devices to authenticate to the Exchange server, without ever making a direct connection with it, instead relying on ISA Server 2006 to pass traffic back and forth. And since the recommended location of ISA Server 2006 is in the perimeter network, this allows an extra layer of security between the public Internet cloud and the Exchange Server front end.

Authentication
There are two basic flavors of authentication from which to choose: basic and certificate-based. Basic refers to a standard name-and-password-enabled, SSL-based connection between a Windows Mobile client and the Exchange front-end server. It still requires a certificate because Exchange Server looks for a matching root certificate on the device before authenticating. Windows Mobile and IIS allow you to use the broad array of encryption methodologies associated with SSL.
Certificate-based authentication, which is available in both Windows Mobile 5.0 with MSFP and Windows Mobile 6, uses Transport Layer Security (TLS) rather than SSL basic authentication. In addition to the root certificate, TLS requires that each user have a certificate with public and private keys. Because TLS uses an encryption key (up to 2,048 bits) instead of a password, this protocol offers stronger authentication.
With Windows Mobile 6, to enroll a user certificate using Desktop Enroll requires that the device be docked with a desktop that is in the same domain as the certificate enrollment server. The user authenticates the enrollment using a password, smart card, or other method, and then connects the device to a desktop PC. The user then accesses the certificate system through the desktop, which, in turn, installs the certificate on the mobile device. Desktop Enroll can serve a variety of Windows Mobile security purposes, including certificate renewal, as well as distribution of ActiveSync authentication certificates, SSL/TLS authentication certificates, 802.1x Wi-Fi certificates or S/MIME digital signing certificates.
Security protocols such as SSL protect message data while in transit, but do not encrypt them once they land on the Windows Mobile device or the Exchange server. S/MIME is a secure form of the familiar MIME e-mail standard that supports digitally signed and/or encrypted e-mail. This provides an additional layer of protection over and above SSL transport layer encryption.

Wrapping Up
It takes attention to each of the many layers that make up a solution to create an infrastructure that is sufficiently secure. Windows Mobile, Exchange Server, and Microsoft network security products like ISA Server work together to allay much of the pain of managing mobile infrastructure. This helps take some of the pressure off IT departments, shifting the focus away from the security challenges created by mobile devices and onto the productivity increases they enable.

Special thanks to Kathy Esser, Katharine Holdsworth, Sarah Norton, and Chip Vollers for their assistance in the creation of this article.

Matt Fontaine is a technology writer for BuzzBee Company.


 Communications: A Powerful Alternative to Public Folders
Communications Alan Maddison

A Powerful Alternative to Public Folders
At a Glance:
  • Share calendars and contacts
  • Communicate with blogs and wikis
  • Share and manage documents

Public folders have been around since the first version of Microsoft Exchange, with the original goal of providing a basic platform for sharing documents, distribution-list archiving, and custom application development. From almost the very
beginning, however, administrators have struggled with the management and use of what has become an increasingly complex part of many Exchange environments. Although Exchange Server 2007 has introduced some significant improvements in the management of public folders, the challenge remains. Public folders just don’t provide the robust collaboration and document management platform that enterprises need today.
Microsoft has stated that Exchange Server 2007 may be the last version of the product that supports public folders. While they are still fully supported and will continue to have full support for the 10 years following the launch of Exchange Server 2007, this is a good time to examine an alternative.
Luckily, Microsoft has supplied a compelling option with the launch of Microsoft® Office SharePoint® Server (MOSS) 2007. MOSS 2007 provides the platform IT administrators and businesses need to replace and move beyond the capabilities offered by public folders. In this article, I demonstrate how MOSS presents a robust and powerful framework that can offer significantly more capabilities than Exchange public folders. In particular, I will focus on using SharePoint for tasks that public folders are commonly used for, such as sharing calendars, contacts, and document sharing.
Keep in mind that you will continue to need public folders until you at least update your clients. The Microsoft Outlook® clients from Outlook 97 to Outlook 2003 require public folders for a number of reasons, including Offline Address Books, the Organizational Forms Library, and free/busy lookups. Once you move to Outlook 2007 and Exchange Server 2007, you can completely eliminate your use of public folders whenever you’re ready.

SharePoint Calendars
Shared calendars are a common use for public folders, and SharePoint makes it very easy to substitute a SharePoint calendar for a public folder calendar. While a default installation of a SharePoint site includes a calendar, you will probably need to create multiple calendars to accommodate your organization’s needs. To demonstrate, I will walk you through the creation of a shared calendar for a human resources team. The first step is to select View All Site Content—this is typically shown in the top-left corner of the SharePoint site (see Figure 1).
Figure 1 Creating new site content
Figure 1 Creating new site content
After you’ve selected View All Site Content, click the Create button (which is also shown in Figure 1). Once the Create page loads, you will see the default content type options (as Figure 2 shows). In order to create a calendar, you must select Calendar in the Tracking column. Then you must fill in the name and description fields, as well as choose whether to include the calendar in the Quick Links section.
Figure 2 The Create page displays many default options
Figure 2 The Create page displays many default options
At this point, the calendar is created. The user has the option of viewing the shared calendar through the SharePoint site or directly from within Outlook. To do the latter, the user just needs to connect to the calendar using his Web browser, and then open the Actions menu, and select the Connect to Outlook option.
When the connection is first made, Outlook displays a security warning; this is to remind users that they should only connect to known and trusted sources. Once they select Yes, the calendar will be connected to Outlook. Figure 3 shows the default view, which displays the SharePoint calendar and the Outlook calendar side by side.
Figure 3 Displaying the SharePoint calendar and the Outlook calendar side by side
Figure 3 Displaying the SharePoint calendar and the Outlook calendar side by side
Once the calendar is connected to Outlook, two-way synchronization can occur. Any events entered via Outlook are synchronized with SharePoint and all users that view the calendar will see the updated entries. In addition, if you have enabled SMTP support within SharePoint, events can be e-mailed directly to the calendar and SharePoint will add those entries.

SharePoint Contacts
Shared contacts, which also rely on public folders, are used by many organizations. Again, SharePoint provides a more robust alternative, making it easy to create and manage contact lists. Continuing with the same example, I’ll now show you how to create a shared Contacts list for the example human resources department.
Once again, select View All Site Content and click the Create button. Now select the Contacts link in the Communications column. You are shown a screen where you provide information for the Name, Description, and Quick Link configuration (see Figure 4). Once you complete this information, simply click the Create button and the new Contacts list is created.
Figure 4 Filling in the Name, Description, and Quick Link configuration
Figure 4 Filling in the Name, Description, and Quick Link configuration

User Communication
You can also use SharePoint to create a discussion board (also known as a discussion list). As with the Calendars and Contacts, the creation process is very straightforward—select View All Site Content, click the Create button, and select the Discussion Board link in the Communications column. As you did previously, fill in the appropriate information for the Name, Description, and Quick Link configuration and then click the Create button. Figure 5 shows a discussion board with some example posts.
Figure 5 A sample discussion board with a couple of posts
Figure 5 A sample discussion board with a couple of posts
In addition to discussion boards, SharePoint Server now supports two very popular communication tools—blogs and wikis. Not available with public folders, blogs and wikis are new to SharePoint Server 2007 and these tools provide exciting and useful collaboration capabilities to the feature set.
Blogs provide an interactive forum where a blogger can easily share thoughts and ideas by posting them to a Web site. Typically, these posts are categorized to make it easier for readers to find posts of interest. Meanwhile, readers can provide responses to a blogger’s comments. A company, for instance, can have members of executive management keep a blog. This can be a powerful tool for communicating with employees and it provides a means for staff members to share ideas and keep communication flowing at all levels.
Creating a blog in SharePoint is easy. The first step is to select View All Site Content, click the Create button, and click Sites and Workspaces under the Web Pages column. This takes you to the New SharePoint Site page, where you must provide the Title, Name, and URL for the site. Then you choose a template for the site—in this case pick the Blog template. The last three configuration options are for permissions, navigation, and site directory listing. After you complete all the required options, press the Create button. This actually creates a subsite within your top-level site, and within the subsite are libraries and lists that provide the blogging capabilities. Once the process is complete, you are taken to the new blog.
A wiki is another great tool designed for even more collaborative authoring. Users can add, remove, and edit content on the site, as well as link many pages together. The simplest way to create a wiki is to select View All Site Content, click the Create link, and then select Wiki Page Library, which is listed in the Libraries column. After you fill in the required Name, Description, and Navigation configuration fields, press the Create button, and you’re finished. For more information on using wikis in SharePoint, see the article "Wiki While You Work" in the January 2007 issue of TechNet Magazine.

SharePoint Libraries
Public folders have in effect become document repositories, providing a central location where users can easily access and share documents. As Exchange administrators have found over the years, this is one of the primary uses that have made public folders so unwieldy. Not only does this cause an increase in Exchange I/O for the public folders database, but it also has an impact on replication throughout the Exchange infrastructure. SharePoint Libraries provide an excellent alternative, offloading the demand from Exchange and its resources.
A SharePoint Library is a location within a SharePoint site that allows you to store and manage files. There are several types of Libraries including Picture, Wiki page, Forms, and Document. When considering a replacement for public folders, the Document Library is the most appropriate choice. A Document Library supports storing, managing, and, in some cases, creating documents within the SharePoint site.
Many different types of files can be stored in a Document Library, but certain file types—such as executables and scripts—are restricted by default for security reasons. These restrictions, however, can be configured via the Operations section of the SharePoint Central Administration site.
A default installation of MOSS includes a Document Library that can be customized. Most organizations will want to create multiple libraries to support the different business units within the organization. This is easy to do using the tools provided by SharePoint. For example, to deploy a Document Library for Human Resources, select View All Site Content, click the Create link, and then choose Document Library, which is listed in the Libraries column. You will then see a number of settings that you need to configure—provide a name and description for the library, specify whether to include the library in the Quick Links section, choose whether versioning should be enabled, and select a default format for new documents created directly in the library.
Pay particular attention to the Document Version History option. The default selection for this is Disabled. However, versioning can be useful and appropriate in many environments. In addition to storing historical copies of documents, this functionality tracks when changes were made and who made them, and also provides the ability to view and restore earlier versions.
Figure 6 shows the newly created Document Library with some documents that have been uploaded. Once you have created your Document libraries, you can make these repositories available through Microsoft Outlook and Windows® Explorer. Outlook allows you to take the contents of a Document Library offline and provides a read-only copy for users who don’t have access to the network. Providing access through Windows Explorer takes advantage of My Network Places. By entering the URL of the Document Library, you can provide access for your users. In larger environments, you may want to consider using Group Policy to deploy these Network Places.
Figure 6 Document Library, which contains some documents that have been uploaded
Figure 6 Document Library, which contains some documents that have been uploaded

Beyond the Basics
SharePoint supplies a feature set that clearly surpasses the capabilities provided by public folders. In addition to giving you some of the common functionality you get with public folders, SharePoint Server also provides more powerful capabilities that can extend the power of these common uses. These enhanced abilities include:
  • Version history
  • Approval control
  • Checkout procedures
  • Workflow control
  • Document retention policies
  • Auditing
  • RSS
Features like these are critical to any enterprise content management platform, and SharePoint provides a robust framework that administrators can use with ease. This enhanced functionality can be enabled for many of the SharePoint features, including Calendars, Tasks, Discussion Boards, and Document Libraries.
To configure this functionality, select the Settings menu and then choose the settings option—for instance, the Document Library Settings option, as shown in Figure 7. You will then be shown the Settings page, where you can view all of the configuration and customization options available. The Versioning settings link under the General Settings column, for example, allows you to configure version history.
Figure 7 Selecting the settings option to configure enhanced functionality
Figure 7 Selecting the settings option to configure enhanced functionality
As I mentioned earlier, this functionality provides a record of document changes, including who made changes and when the changes were made, and lets a user view and restore earlier versions if necessary. It is also possible to control how many versions are stored by SharePoint. Once this limit is reached, items are deleted without being sent to the SharePoint Recycle Bin.
The Versioning section also allows you to configure the Content Approval and Checkout requirements you need. When Content Approval is enabled, any submitted items must be approved before they are made available to other users. Items that have not been approved remain in a pending state. The Checkout process provides content control by prohibiting multiple users from working on a file at the same time.
Workflows are another useful feature offered by SharePoint that are not available with public folders. Basically, workflows offer a structured approach to business processes that can help streamline your company’s operations. As implemented within SharePoint, workflows are a series of predefined tasks that automate the movement of a document through the designated process. The process can be iterative, which requires each step be completed before it moves onto the next step, or the process can be parallel, which allows any given task to be completed at any time. The default workflows included with SharePoint are:
  • Approval
  • Collect Feedback
  • Collect Signatures
  • Disposition Approval
Information management policies are used to enforce compliance with regulations and business requirements. A policy consists of a set of rules relating to the management and control of documents. SharePoint Server supports custom rules, but includes handy default rules, including:
  • Auditing
  • Expiration
  • Labels
  • Barcodes
Auditing provides the ability to log events based on a set of actions that you define within the site settings. You can track such actions as opening a document, downloading or viewing an item or its properties, editing a document, checking a document out or in, moving or copying items, and deleting or restoring items.
Expiration of content allows you to have content deleted to maintain compliance with your organization’s data retention policies. This data expiration can occur on a particular date or it can occur a fixed period of time after a certain event has taken place, such as document creation.
Labels are used in conjunction with printing, adding text to the printout. In practice, this policy can have a number of uses. For example, you could require that all documents from the human resources shared Document Library contain a confidentiality notice in order to be in compliance with your legal department’s regulations.
Barcodes provide a formal tracking method for both online and printed documents. SharePoint will create a unique identifier for every document and then users have the ability to insert an image of the barcode into their document.
One other significant enhancement that SharePoint offers is its integration with RSS feeds. Calendars, Contacts, Document libraries, and Discussion Boards all provide an RSS feed to which a user can subscribe. Your users can receive automated updates to help keep track of their day-to-day responsibilities, and all that is required is an RSS reader, such as Outlook 2007.

Last Words
Microsoft Office SharePoint Server 2007 provides enterprise class features and offers a more powerful alternative to Exchange public folders. A robust administrative framework makes it easy to implement a solution for sharing calendars, contacts, and documents. You can also create a variety of ways to communicate, including discussion forums, blogs, and wikis.

Alan Maddison is a Senior Consultant in the Microsoft technology practice of MTI Technology Corporation. His primary focus is on Active Directory, Exchange Server, and virtualization.


 Communications: Log onto Outlook Web Access with Smart Cards
Communications Victor Akinnagbe and Ted Dressel and Jason Opdycke

Log onto Outlook Web Access with Smart Cards
At a Glance:
  • Two-factor authentication
  • Kerberos constrained delegation
  • ISA Server and Exchange configuration

Mobile employees present a unique security challenge for IT organizations. Remote users need secure access to data and services such as e-mail. The unfortunate reality, however, is that the most
vulnerable links in the security chain involve weak passwords, malware (such as key loggers), and viruses on the remote computers that are accessing your organization’s internal resources.
One way to increase security in this mobile environment is to remove one of those vulnerable links: passwords (though the idea of allowing access to an account without a password for authentication may seem disturbing). A primary technique for eliminating the problems associated with passwords is known as two-factor authentication (or sometimes multi-factor authentication). Rather than relying on a single method—a password—to enable access, two-factor authentication enforces the use of additional authentication methods, including a username/password combination, a physical device such as a smart card, or a biometric identifier such as a fingerprint.
If you have remote users, typically you’ll have to open up your firewall a bit to allow remote access to the corporate network. A standard firewall gives you basic risk mitigation by providing network-level isolation between the internal and external networks (see Figure 1). For added security, ports are simply closed off, and if communication needs to happen with a device on the internal network, ports are then forwarded to the right place. These techniques do provide substantial network-level protection, but now multiple layers of network security have become necessary due to the ever growing sophistication of attacks.
Figure 1 Standard firewall with ports blocked or forwarded
Figure 1 Standard firewall with ports blocked or forwarded
Since the most common corporate services mobile employees are likely to use are e-mail and messaging, configuring your Exchange infrastructure securely becomes more important than ever. Giving your users access to e-mail through Outlook® Web Access (OWA) is one way of providing secure services to mobile employees. Providing more secure two-factor authentication for OWA via smart cards is another key step. In this article, we take a closer look at the configuration and setup issues you should be aware of when enabling your own smart-card-enabled OWA deployment.

Better than a Firewall
Employing Microsoft® Internet Security and Acceleration (ISA) Server 2006 on your network can simplify the task of opening your network to remote users in a more secure manner. ISA Server 2006 includes security-enhancing features such as smart-card-enabled virtual private networking (VPN), Lightweight Directory Access Protocol (LDAP) authentication to Active Directory®, and Kerberos constrained delegation. ISA Server is a little bit different from what you might traditionally think of as a firewall. It provides multiple layers of security not only by functioning at the network layer—and it can do this in place of or in conjunction with standard firewall hardware—but also by providing additional security features not typically supported in traditional firewalls, such as application filters. Don’t want someone using the HTTP POST method to a particular hosted Web site? Want to force RFC compliance on SMTP messages before they touch your Exchange server? Want to inspect encrypted Secure Sockets Layer (SSL) HTTP packets before they come into the network? ISA Server can manage all of these tasks and more to ensure that only clean, filtered traffic is forwarded to your DMZ or internal network.
SSL sessions are something of a problem for standard firewalls. As packets pass through the firewall, they remain encrypted (which means that SSL is functioning correctly). Thus, if an application such as OWA is published through a hardware or software firewall using SSL, there is really no kind of appreciable inspection that can done by the standard firewall other than stateful packet inspection. Simply opening and forwarding ports can leave a substantial attack surface area exposed. Since no real inspection is happening at the edge, uninspected and unauthenticated packets could be routed into your internal network.
ISA Server 2006 can act as an SSL endpoint for HTTP clients, ensuring that only authenticated traffic reaches the published Exchange server. ISA Server supports a useful feature called SSL bridging. Typically, a packet is encrypted by a client that is communicating via a standard SSL session with ISA Server. With SSL bridging, ISA Server can terminate the SSL encryption locally, inspect the now unencrypted packet, authenticate the user to Active Directory (if necessary), re-encrypt the packet using SSL, and pass the encrypted packet on to the appropriate Exchange server (see Figure 2). Using this technique, SSL bridging mitigates attacks hidden within an SSL session that would look like nothing more than encrypted blobs of data to a firewall that is not application-aware.
Figure 2 ISA Server takes an application layer view of traffic
Figure 2 ISA Server takes an application layer view of traffic
Preauthenticated traffic reaching the server is an important point to note when speaking of Kerberos constrained delegation. In a standard firewall, ports are simply forwarded to the Exchange server and the front-end server itself is responsible for performing authentication tasks against what could be malicious users. When authentication is required, ISA Server can directly contact Active Directory and make the request for credentials on behalf of the user. If the user is authenticated successfully, ISA Server will forward the message to the Exchange front-end server. The front-end server no longer has to authenticate random unknown user requests and can be used solely for proxying requests to the back-end servers. ISA Server 2006 can also use Kerberos constrained delegation to enable certificate-based access to technologies like Windows SharePoint Services and Exchange ActiveSync.
Exchange Server 2003 included support for Kerberos-based authentication between front-end and back-end servers for OWA logins. (You are using IPsec to protect that client traffic, aren’t you?) Exchange Server also supports Kerberos authentication to clustered mailbox servers.

Enabling Smart Card Authentication
Implementing smart-card-based authentication for OWA has been a challenge. However, a solution has been developed based on the Kerberos constrained delegation feature now available in ISA Server 2006. The solution allows a user to submit credentials via a certificate in order to successfully authenticate to OWA. Kerberos constrained delegation comes as a welcome improvement over the Kerberos delegation support in Windows® 2000, which used unconstrained delegation. The constrained function of Kerberos is more secure and limits the potential risk of sophisticated attacks using impersonation.
In the smart-card-enabled scenario, ISA Server 2006 contacts Active Directory to authenticate the user since the user does not have routable access to a Key Distribution Center (KDC) from the external network. ISA Server defers to Active Directory certificate-user mapping to authenticate the user and then acquires the respective Kerberos tickets based on the User Principal Name (UPN). In this case, ISA Server is providing Kerberos constrained delegation functionality to an Exchange front-end server via application-level filtering and reverse proxy services. If delegation is attempted without a reverse proxy, the increased risk for exploits could affect the integrity of the network or Active Directory domain.
Exchange Server 2003 and Exchange Server 2007 both allow for Basic and Integrated authentication. However, you need to apply a software update to Exchange Server 2003 for smart-card-based authentication to OWA to work. (For more information, see the article "Description of the New Feature in Exchange Server 2003 that Supports Smart Card Authentication to Outlook Web Access".) You must have a domain in the Windows Server® 2003 Native functional mode, all involved Exchange Server 2003 servers must have SP2 or later applied, and you need an ISA Server 2006 server acting as a reverse proxy for the OWA site.
After you install the software update and configure your ISA and Exchange servers, users can authenticate an OWA session using smart cards. Figure 3 shows the flow of events required for smart card authentication. A user begins by opening the OWA site in Internet Explorer® (1). In fact, the user actually connects to ISA Server and is prompted for a certificate instead of a username and password to start the OWA session. The appropriate certificate is stored on the smart card, for which the user needs a PIN.
Figure 3 Authenticating OWA with a smart card
Figure 3 Authenticating OWA with a smart card
Certificate validation (2) is handled via a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP) request, depending on the configuration of ISA Server and other installed software. ISA Server makes a request to a domain controller (DC) to verify the user’s credentials. If the request fails, ISA Server provides an error page to the user and no request gets to the Exchange front-end server.
After the credentials are verified, the Kerberos ticket is generated and the request is passed to the Exchange front-end server using integrated authentication (3). When the Exchange front-end server receives the request, it validates the Kerberos ticket and locates the user’s back-end mailbox server (4).
The front-end server requests a Kerberos ticket for the appropriate back-end server via Kerberos constrained delegation and proxies the mailbox request to the back-end server using integrated authentication (5). The request is serviced by the back-end server (6) and the mailbox data is returned to the Exchange front-end server (7). The HTML data for the OWA page is passed to ISA Server (8), which then passes it back to the client machine (9).

Configuring the Exchange Environment
The Knowledge Base article that was mentioned earlier describes the software update for Exchange Server 2003 and includes information that will help guide you through the process of enabling Kerberos constrained delegation using ISA Server 2006 and Exchange Server 2003.
The main action the software update enables is automating the process of Kerberos constrained delegation from the Exchange front-end server to the respective back-end servers. The update will not automate the process of Kerberos constrained delegation from ISA Server to the front-end server since ISA Server is not part of the Exchange organization. That delegation will have to be enabled manually from each ISA Server instance to each Exchange front-end server.
The software update adds a new tab in Exchange System Manager (ESM) that enables you to designate an Exchange front-end server as a KCD-FE (see Figure 4), which in turn allows that server to be populated in the delegation tab of the respective Exchange back-end servers.
Figure 4 Enabling Kerberos constrained delegation
Figure 4 Enabling Kerberos constrained delegation
The new UI also enables you to specify in the properties of the Administrative Group which credentials to use for populating the msDS-AllowedToDelegateTo (A2D2) attribute, as shown in Figure 5. This is the attribute that is responsible for Kerberos constrained delegation.
Figure 5 Setting the account that controls delegation
Figure 5 Setting the account that controls delegation
Respecting the principle of least privilege, you can use a standard user account and grant it the ability to delegate users and computers via a Group Policy Object (GPO). After the account has been granted this elevated permission, it can be used as a service account to automate the Kerberos constrained delegation process for the respective Administrative Group.
Make sure you take the proper steps to ensure that a malicious user will not be able to compromise the Kerberos constrained delegation service account. Even if the account is not a domain administrator, access to it could lead to sophisticated attacks by taking advantage of Kerberos delegation. Since the account will have the ability to establish new Kerberos associations, it should be used with care. Take the necessary precautions in order to ensure the security and integrity of that account: a long, complex password, increased auditing, account disablement techniques, and so on.
The Exchange software update also makes a very important change to the ESM interface regarding integrated authentication. Previously in Exchange Server 2003, when a server was designated as a front-end server, the option for enabling Integrated Windows Authentication for HTTP Virtual Directories (under the HTTP Virtual Server) was grayed out (see Figure 6).
Figure 6a The update enables integrated authentication
Figure 6a The update enables integrated authentication
Figure 6b The update enables integrated authentication
Figure 6b The update enables integrated authentication
This occurred because integrated authentication was not supported on Exchange front-end servers due to technical issues such as the fact that proxy servers interrupted NTLM sessions, users employing Kerberos authentication needed a connection to Active Directory, and Internet users were usually not part of the domain. The update described in the aforementioned Knowledge Base article removes these limitations. With the update installed, you can simply go to the virtual directory and check the box for Integrated Windows Authentication as the mechanism for verifying user credentials. When this is checked, it sets an attribute called msexchAuthenticationFlags on the virtual directory object in Active Directory (you can see it by using the Adsiedit.msc snap-in for the Microsoft Management Console).
Users checking mail through OWA may know the name of their Exchange back-end servers and can connect to them using integrated authentication while they are on the corporate intranet. The difference in user experience with integrated authentication is that since you are logged onto the network, you are not prompted for a user name and password because Internet Explorer will authenticate you to the Web site automatically. This is great for users who are on the corporate network, but external users—and OWA users are more typically external—will not usually be logged onto a domain when coming from the outside the network into an Exchange front-end server. (This process is explained in detail in the Knowledge Base article "How IIS Authenticates Browser Clients".)
In Exchange Server, the update populates the Delegation tab to use the A2D2 attribute rather than the Service Principal Name (SPN) attribute in Active Directory. If you take a look at the Exchange computer object using Adsiedit.msc, you should notice two distinct attributes: the A2D2 attribute, which is the Kerberos constrained delegation list; and the SPN attribute, which serves as a Kerberos locator and account specification point. While it is true that both attributes work together to make Kerberos constrained delegation happen, you should only modify the A2D2 attribute through the graphical interface.
Windows can use the built-in HOST SPN as an alias to locate other services. This means setspn.exe does not have to be used for Kerberos constrained delegation to work for Exchange front-end to back-end delegation. (Although explicitly specifying HTTP/Servername in the SPN attribute list will work with this solution, it leaves more room for administrator error, and is not required for Kerberos constrained delegation to function.) The Kerberos constrained delegation is looking for the A2D2 attribute in Active Directory. When this attribute is not populated (or populated with the wrong SPN value), Kerberos constrained delegation will not work between the respective servers. On an Exchange cluster, however, the A2D2 attribute from the front-end server only needs to be pointed to the cluster node computer account to work properly.
As noted earlier, a Windows Server 2003 domain containing the Exchange 2003 servers must be in Windows Server 2003 Native functional mode. Kerberos constrained delegation can’t be used unless that level of domain functionality has been achieved. If your domain is still in mixed mode and you install the software update discussed earlier, it will appear to work but the SPN registrations will actually fail. Kerberos constrained delegation is also a domain function, not a forest-level function. This means that for Exchange Server 2003, ISA Server and the Exchange front-end and back-end servers must be members of the same domain (although users from different domains can still authenticate to Kerberos constrained delegation). An ISA Server instance that is not a member of a domain or that is a member of a different domain will not work as part of this solution.

Configuring the OWA Site
IIS Admin should not be used for any kind of authentication changes to OWA. Even though OWA runs under IIS and will respond to changes in the metabase like any other Web site, Exchange introduces a bit of complexity with the Directory Services to Metabase (DS2MB) process. The DS2MB process will replicate changes from Active Directory to the IIS metabase in a one-way process that will overwrite any changes made directly to IIS. The impact of this process is that if an administrator goes in to make a change directly to the IIS metabase (such as setting integrated authentication), the solution will appear to work but will break once the next DS2MB replication cycle kicks off.
The option for enabling Integrated Windows Authentication for HTTP Virtual Directories was made available in ESM because ESM makes its edits directly to Active Directory, which then causes the change to be replicated down to the IIS metabase. Keep in mind that while stopping the System Attendant service will also stop the DS2MB process, allowing you to make changes to the IIS metabase and not have them overwritten, this is not advisable. The next time System Attendant starts, it will poll the changes from Active Directory and the solution will then be disabled automatically.
The Delegation tab shows options for Use Kerberos only and Use any authentication protocol. Simple logic would tell you to select Use Kerberos only since the solution that we’re discussing is using Kerberos constrained delegation—but this is one of those many IT situations where common logic does not apply. So instead, you should select the Use any authentication protocol option (as shown in Figure 7) because the request is not coming in as a Kerberos request; rather, it’s coming in as an HTTP request with a corresponding certificate mapped to an Active Directory account.
Figure 7 Correct authentication settings for smart cards
Figure 7 Correct authentication settings for smart cards
In this case, ISA Server is requesting the user PKI certificate over SSL. The incoming request is not a Kerberos ticket, so a transition has to happen in order for Kerberos constrained delegation to work properly. Thus, specifying the Use Kerberos only setting will break the chain of communication at ISA Server. Note, however, that the Use Kerberos only option will work on the Exchange front-end to back-end server delegation since the front-end server will only be receiving Kerberos tickets from ISA Server.
The \Exchange and \Public virtual directories are the only locations that should contain private user and public folder information. The SSL configuration in Exchange is not new to Kerberos constrained delegation or two-factor authentication, but a carryover from standard SSL enabling of OWA with basic authentication credentials. You should follow the documented methods to enable SSL on OWA because incorrectly forcing SSL can break OWA—and can cause issues with ESM as well.

Additional Configuration Details
When implementing this solution, it is much easier to deploy ISA Server and Exchange in the standard manner first. Don’t drop in the entire Kerberos constrained delegation solution with all of the settings configured (especially if you didn’t previously have ISA Server in your deployment). This can complicate the troubleshooting process should a component or step in the process fail. It’s much easier to deploy ISA Server and Exchange in the standard manner (with username and password, but without forms-based authentication), ensure that the install is working, and then transition to Kerberos constrained delegation and certificate authentication.
Typically, forms-based authentication cannot be used with smart-card-enabled OWA. Forms-based authentication indicates that a user has a username and password to submit via the standard Outlook form. However, with smart-card-based two-factor authentication, the user will have only a smart card and not a password. Thus forms-based authentication will not have any means of accepting or submitting only the certificate for authentication. Using forms-based authentication anywhere in the chain (for example, on a front-end server behind ISA Server) will break smart-card-enabled OWA configuration. If you enable forms-based authentication, the Exchange virtual directory will be forcibly set to Basic authentication, and thus the IIS metabase will be set to Basic authentication as well.
If you have a mix of users who have both usernames/passwords and smart cards, you can enable fall-back authentication on the ISA Web listener, and when a user hits the ESC button after being prompted for certificate-based credentials, she will be prompted for standard username/password credentials even if Integrated authentication is enabled behind ISA Server on the Exchange server. Additionally, ISA Server can time out the SSL session in much the same way that forms-based authentication functions.

Conclusion
Smart card support for authentication to OWA is a welcome addition to both Exchange Server 2003 and Exchange Server 2007. With the ability to log onto OWA using a certificate, users no longer have to worry about remembering long and complex passwords, and administrators now have an effective tool against key loggers and other forms of malware that can sniff out user credentials from an infected system. See the "Resources" sidebar for more information.
Having ISA Server configured correctly for two-factor authentication with smart cards increases overall security even further by performing application level filtering on the published OWA application. Additionally, ISA Server 2006 has built-in support for publishing both Exchange Server 2003 and Exchange Server 2007 through the simple publishing wizards, so ISA Server remains a sound investment for organizations transitioning to Exchange Server 2007.
Resources
  • How to Share Files that Are Removed by the "Safe HTML" Filtering Feature in Outlook Web Access for Exchange Server 2003
  • Troubleshooting Kerberos Delegation
  • Metabase Update Service
  • Authentication in ISA Server 2006
  • Kerberos Protocol Transition and Constrained Delegation
  • TechNet Webcast: Implementing Multifactor Authentication Using Smart Cards

Victor Akinnagbe is a Premier Field Engineer at Microsoft working in the Washington, D.C. area. His primary focus is on security, infrastructure, and messaging.
Ted Dressel is a Consultant at Microsoft working in the Washington, D.C. area. His primary focus is on security and infrastructure.
Jason Opdycke is a Premier Field Engineer at Microsoft working in the Charlotte area. His primary areas of focus are security, and infrastructure.


 Windows Administration: The ActiveX Installer Service in Windows Vista
Windows Administration Rob Campbell and Joel Yoker

The ActiveX Installer Service in Windows Vista
At a Glance:
  • Common challenges with ActiveX controls
  • How ActiveX controls are installed
  • Dangerous permissions
  • A safer process in Windows Vista

It’s always the same story. To substantially enhance your security, you have to give up some freedom or flexibility. If your environment is like most organizations, you have a very strong desire to harden the desktop operating system in an effort to provide a more secure computing
environment for your end users. IT administrators typically approach the task of securing the desktop by employing a combination of security policy settings, user permissions, file and registry access control lists (ACLs), and system service restrictions.
One common hurdle in the development of a secure desktop environment is how to mitigate the threats surrounding malicious ActiveX® controls while still providing an appropriate level of application compatibility in your environment. This has been a challenge with desktop operating systems for many years. Fortunately, the new ActiveX control Installer Service (AxIS) in Windows Vista™ addresses concerns specific to the management of ActiveX controls in corporate environments. AxIS provides a simple and manageable way for standard users, who wouldn’t ordinarily be permitted to install ActiveX controls, to install them from approved Web sites. Group Policy control over AxIS allows IT administrators to determine which controls users can install, regardless of which permissions they have.
In this article, we take a look at the administrative challenges surrounding ActiveX controls, how these issues were addressed in previous versions of Windows®, and how AxIS in Windows Vista provides a unique and efficient way to manage the installation of ActiveX controls.

What Is an ActiveX Control?
An ActiveX control is a piece of executable code (typically an OCX file packaged within a Cabinet file) that is installed and invoked by the user via Internet Explorer®. Web developers create ActiveX controls to add functionality to their Web applications that they can’t easily achieve with standard HTML or a simple script.
A key feature of ActiveX controls is their simple "download and execute" deployment model. ActiveX controls are installed and invoked via the HTML object tag, which has an attribute called CODEBASE that tells Internet Explorer (using a URL) where to get the control if it isn’t already installed on the user’s machine. In that case, Internet Explorer downloads the associated installation package, performs trust verification on the object, and prompts the user for installation permission via the Internet Explorer Information Bar (shown in Figure 1). During the installation, the control is registered and invoked by the rendering page. Once installed, any standard user can invoke the control. This simple mechanism of distribution and execution is meant to provide developers with an easy way to distribute their components to users of their Web application. The problem with this distribution method is that standard users cannot directly install ActiveX controls because administrative privileges are required to complete the installation.
Figure 1 ActiveX Control installation information bar
Figure 1 ActiveX Control installation information bar
When ActiveX controls were first introduced in Internet Explorer 4.0, the Internet seemed a much friendlier place. Today, executable code distributed over the Web can represent a significant threat, so Windows only allows users with local administrator rights to install ActiveX controls, and then only if the installation is approved according to policy settings. Once an ActiveX control is installed by an administrator, any user of the system can invoke it. This behavior is facilitated by a set of file and registry ACLs in Windows. While this prevents standard users from installing ActiveX controls, it does not mitigate the risks to the local administrators and standard users (with modified default permissions) who install them.
While the default protection in Windows—allowing only those with administrative privileges to perform installation—addresses ActiveX controls at the individual level, it does not address how to manage these across a large organization. A common challenge in corporate environments is how to permit the use of ActiveX controls trusted by the IT organization while mitigating potential threats delivered through external, non-trusted controls. At the end of the day, the decision to install a particular ActiveX control, good or bad, is often left up to an individual user, depending on their rights. To counteract threats, some organizations block all ActiveX controls, while others allow end-user installation but attempt to manage any malware that is installed.
Another way to prevent installation of bad controls is to enforce the restricted rights of the standard user and have the IT administrator preinstall all required controls on the desktop platform. This is effective if the ActiveX controls in use are relatively static in nature, are modified using a scheduled release process in conjunction with desktop updates, or if the organization uses a software distribution mechanism such as Systems Management Server. However, ongoing management, the ever-changing needs of internal application developers, and dependencies on external controls will continue to be a challenge with these approaches.
In instances where users have administrative privileges, the problem is different; it involves keeping these users from installing controls that are not approved. In these cases, the right of the end user to install ActiveX controls is assumed since the user has administrative privileges. (Note that having end users run as local administrators is a posture that represents high risk to the organization and is not recommended for most corporate environments.)
One solution is to have an internal Internet Component Download Server that hosts the approved controls. This solution requires the modification of the CodeBaseSearchPath string in the client’s registry. Normally, when an object tag containing the CODEBASE attribute is found in the requested HTML page, Windows clients are directed to the locations specified in the CodeBaseSearchPath data. By default, this registry string contains the CODEBASE keyword and Internet URLs for the ActiveX control gallery. To implement an Internet Component Download Server, you need to replace the default data in the CodeBaseSearchPath with the URL of the internal server where you’ll host controls approved by your organization. Like the previous approach, this solution requires ongoing management and carries the cost and complexity of hosting an internal server for ActiveX controls.
There are other solutions, such as modifying Internet Explorer zone URLActions, specifying administrator-approved controls through Group Policy, and blocking the installation of all controls at the perimeter through firewall rules. But, as you can see, all these approaches have their problems and many are eventually abandoned due to lack of flexibility. What’s worse, some of these solutions still require the user to have administrative rights. In the end, these modifications attempt to address portions of the problem, such as controlling (or blocking) where ActiveX controls come from, where they can be invoked from, and so on; however, these solutions do not mitigate the fundamental problem that users without administrator rights cannot install ActiveX controls.

What Can AxIS Do for You?
AxIS in Windows Vista allows the corporate administrator to manage ActiveX controls while maintaining a strong security posture by having users run as standard user with default file system settings. AxIS provides Group Policy options to configure trusted sources of ActiveX controls and a broker process to install controls from those trusted sources on behalf of standard users. The key benefit is that you can maintain a non-administrative security posture on user workstations along with centralized administrative control. AxIS relies on the IT administrator to identify trusted sources (typically Internet or intranet URLs) of ActiveX controls. When an object tag directs Internet Explorer to invoke a control, AxIS takes the following steps:
  1. Checks that the control is installed. If not, it must be installed prior to use.
  2. Checks the AxIS policy setting to verify if the control is from a trusted source. The specific check matches the host name of the URL specified in the CODEBASE attribute of the object tag against the list of trusted locations specified in policy.
  3. Downloads and installs the control on the user’s behalf.
If the host name of the source URL is not listed in the AxIS policy setting, the normal User Account Control (UAC) prompt will be invoked, requiring administrative rights to complete the installation. In addition, AxIS will log an event with ID 4097 in the Application event log from source AxInstallService outlining the attempted ActiveX control installation, along with the specific download path to the control. An example of the 4097 event is illustrated in Figure 2. The data from this event log entry can be used by the corporate administrator to modify Group Policy, allowing the control to be installed by AxIS on subsequent visits to the Web site.
Figure 2 4097 AxInstallService event
Figure 2 4097 AxInstallService event
AxIS is an optional component that comes with the Business, Enterprise, and Ultimate SKUs of Windows Vista, and can be enabled through an unattended option or through the Control Panel dialog box (Programs | Programs and Features | Turn Windows features on or off), as shown in Figure 3. Once enabled, AxIS walks through the steps outlined above each time a control is requested by Internet Explorer.
Figure 3 Enabling AxIS in Control Panel
Figure 3 Enabling AxIS in Control Panel
The ability to attach tasks to events in Windows Vista provides an easy way for an administrator to receive a notification from the AxIS service, such as when the installation of an ActiveX control is blocked. It is important to note that it cannot always be assumed that the ActiveX control will be installed from the same URL host name that the end user is accessing from his Web site. For this reason, the information provided by the AxInstallService 4097 (attempted installation) event can prove incredibly useful in identifying the host from which the control is attempting to be installed.
With the information you get from the event, you can configure the trusted location in Group Policy. AxIS settings in Local or Group Policy can be found in the Computer Configuration settings (as you can see in Figure 4). The Approved Installation Sites for ActiveX Controls policy setting allows you to specify host URLs of trusted locations (see Figure 5). The approved site setting requires two pieces of information—where the ActiveX control may be installed from and the behavior of the installation.
Figure 4 Settings in Group Policy Object Editor
Figure 4 Settings in Group Policy Object Editor
Figure 5 AxIS-approved installation sites
Figure 5 AxIS-approved installation sites
First, as mentioned before, a host URL is required to indicate the trusted location of the control. Unlike previous solutions, which required knowing the CLSID of the control (which often changes when controls are revised by their developers), AxIS allows for any control to be installed from the trusted location, reducing the overall administrative burden. The second piece of information is a comma-delimited string of four values, each dictating the behavior of the ActiveX control download experience. The values specify four properties: TPSSignedControl, SignedControl, UnsignedControl, and ServerCertificatePolicy. The first two properties (TPSSignedControl and SignedControl) can have one of three values: 0, 1, or 2. These values are similar to the values found in URLAction settings. A value of 0 prevents the control from being installed, a value of 1 causes the user to be prompted for permission to install, and a value of 2 causes the control to be silently installed on the user’s behalf. Unsigned controls cannot be installed silently and therefore the UnsignedControl value can only be 0 or 1. Note that if no policy is specified, the default values of 2, 1, and 0 are used.
The final property specifies the behavior of the installation based upon the certificate settings of the signed settings control. Like most SSL sites, certificates must pass a set of security tests to ensure that the certificate is valid. Invalid certificate properties are sometimes the reality of real-world signed ActiveX control implementation. Through its configuration, AxIS allows administrators to mitigate invalid information that is sometimes presented by certificates on a URL-by-URL basis. The final property is represented as a bitmasked combination of the values shown in Figure 6.
Figure 6 ServerCertificatePolicy (Close Figure 6)

Value | Definition
0x00001000 | Ignore an invalid canonical name (CN) in the certificate.
0x00000100 | Ignore unknown certificate authorities.
0x00002000 | Ignore an invalid certificate date.
0x00000200 | Ignore wrong certificate usage.
The default setting is 0, meaning all security checks must pass before AxIS completes the installation. The combination of the host setting and these four values are specified in the policy setting, as seen in Figure 7.
Figure 7 Approved AxIS host URLs
Figure 7 Approved AxIS host URLs

Conclusion
AxIS allows you to configure Group Policy to control which ActiveX controls users can install without requiring administrative privileges or complex configurations. Control at this level could be challenging in previous versions of Windows, and previously available solutions often came with serious limitations or increased management overhead. AxIS provides organizations with another tool toward taking a least-privilege approach to end user rights on desktop systems, allowing the implementation of a standard user model where end users do not require administrative privileges. Windows Vista places the IT administrator back in the driver’s seat by having the choice of which ActiveX controls are trusted within the corporate environment determined the organization, not the end user.

Rob Campbell is a Senior Technical Specialist on the Microsoft Federal team. Rob is focused on developing and deploying security solutions for United States Federal government customers.
Joel Yoker is a Senior Consultant on the Microsoft Federal team. Joel is focused on developing and deploying security solutions for United States Federal government customers.


 From the Editor: Six Degrees
From The Editor
Six Degrees
Joshua Trupin

Have you ever felt a bit disconnected? Have you sat alone in your office, staring into the abyss, wondering if there’s intelligent life out there? Whether, in fact, there’s anyone out there at all? Maybe not—especially if your inbox is perpetually stuffed to the gills like mine is.
Nevertheless, I recently experienced those pangs and decided I needed to connect. I signed up for one of those business-centric social networking sites and started adding people—everyone I’ve ever worked with, acquired an article from, or spoken to at a conference. Within a week, I had 58 contacts on my list. Great!
But that was just the first level. At the second level—acquaintances of acquaintances—I had more than 3,500 friends. And since those 3,500 contacts each had contacts of their own, I zoomed to 277,000 third-degree contacts in no time. A quick calculation on the back of an Excel spreadsheet: assume an average of 50 contacts per person—and it turns out I know over 34 billion people as sixth-degree contacts. Move over, Kevin Bacon! I know more people than exist on Planet Earth. Suddenly the abyss was teeming.
This posed a new problem, however. How can I possibly handle all these relationships? I’m open to any and all suggestions. Are you using a social/business networking site now? How do you sort the people you want to talk to from the ones you want to avoid? Drop on by the TechNet Magazine blog and tell us your thoughts on this burning issue.
If this whole Web 2.0 networking thing isn’t your speed, fear not. This month’s issue of TechNet Magazine helps you improve your communications by making better use of Exchange Server. We have five articles that provide the knowledge you need to extend your organization’s messaging reach.
Using smart card authentication with Outlook Web Access is one of our featured topics this month. It’s always a good idea to require a form of physical authentication before granting access to your company’s resources, and smart cards make this possible from anywhere. We also look at disaster recovery with Exchange Server, how to replace public folders with SharePoint in Exchange Server 2007, and how to improve mobile security with Windows Mobile 6. And of course, we have Exchange Queue & A, which should be your favorite column if you’ve got anything to do with messaging. Oops, another three people just popped up on my network. I’d better go see if I should say hi or pretend I’m sleeping.
—Joshua Trupin

Thank you to the following Microsoft technical experts: Kristian Andaker, Chris Corio, Jim Harrison, Chad Jones, Michael Lee, Shawn McGrath, Michael Murgolo, Eric Perlin, Michelle Rutzer, Gavriella Schuster, and Jim Truher.


 Toolbox: New Products for IT Pros
Toolbox
New Products for IT Pros
Greg Steen

Monitor Remote Connections
RecordTS
www.tsfactory.com
Have you ever wished you had an eye into your Terminal Server or Remote Desktop sessions? Maybe you want to know what was going on before your Remote Desktop session seemed to take down your Web site. Maybe you have an issue on your Terminal Server that you just can’t seem to replicate. Perhaps you’re concerned about security of intellectual property. Or it could be that you need to make a quick log or presentation on how you configured your SharePoint® server in a test environment. If any of these scenarios sound familiar, you should check out RecordTS from TSFactory. (TSFactory was formed by Cláudio Rodrigues, a Microsoft MVP for Terminal Services.)
RecordTS is available in two editions: Terminal Server and Remote Desktop. The right edition for you will depend on what types of connections you want to monitor. As the product Web site attests, RecordTS acts as a "security camera" into Terminal Server or Remote Desktop sessions. The software basically acts as a proxy between Terminal Services and the end-user session, allowing it to record every movement and action taken in a session.
The intuitive installation uses a simple wizard in which you point the application to the data directory where you would like to store saved sessions. The application installs an MMC snap-in (which lets you configure the service), the RecordTS service, and a session playback utility for watching recorded sessions. After opening the MMC snap-in, right-clicking on the service folder brings up a property screen where you can configure settings such as which port you want the service to run on. (This particular setting is useful if you have shifted your Terminal Services sessions to a nonstandard port.) On the Storage tab, you can set the Default Storage Folder to a local folder or a UNC path.
You can also configure the directory structure of the stored sessions. For example, you might use the domain, user, and date and time to organize the data being saved. And, perhaps the most important setting if you are storing sessions on a local disk, you can tell the service what to do if the disk runs out of space. You can choose to either not allow new connections and disconnect current sessions (the choice for the highly security conscious) or you can select to turn off session recording (the option you’ll want if you don’t want to disrupt productivity).
Under the Security tab, you can specify if you want to digitally sign all the recorded sessions by selecting an existing certificate or creating a self-signed certificate. This is worth doing if you plan to use the tool for auditing or liability purposes. On the Users tab, you can specify users who should have their sessions recorded or ones who shouldn’t.
All in all, RecordTS can be an invaluable tool for security and auditing, and its uses can be much broader, such as allowing you to record a how-to presentation. I know I find it a handy addition to my toolbox.

Price: RecordTS Remote Desktop Edition starts at $495. RecordTS Terminal Services Edition starts at $995.

Host Monitoring
Advanced Host Monitor
www.ks-soft.net
If you ever find yourself in a position of providing operational support for a mission-critical infrastructure, there is one sleep aid you can’t do without: a good, reliable host monitor. Even if you have a rock-solid hardware set and a stable and reliable application stack with no single points of failure, you’ll still want a full-featured host monitor to tell you when that redundant system has to kick in.
Advanced Host Monitor, from KS-Soft, touts having 58 different test methods and 30 alert methods. You can check for such items as process information, user sessions, average load, memory, and so on. The application provides Windows®-specific tests, Linux/UNIX tests, and platform-independent checks. Unlike the Windows tests, the Linux/UNIX tests require the installation of a Remote Monitoring Agent on the client.
There is also a Windows Management Instrumentation (WMI) monitoring test. You can browse for the correct query with the embedded WMI Explorer, which lets you easily navigate to and choose the appropriate item, as well as execute the query to verify that it will get you the data you need.
Advanced Host Monitor also has a number of database-related tests such as an ODBC query test, which verifies the availability of an ODBC data source, runs a query, and verifies the result against a known value. You can also check a host’s ability to accept incoming sessions for SQL Server™, MySQL, Oracle, Postgres, Sybase, and Interbase database servers.
There are a number of disk and file-related tests to help you keep tabs on free space, quotas, folder or file availability, and the availability of UNC shares. In addition, you get the standard network-related tests: general TCP/UDP checks, mail tests (for SMTP, POP3, and IMAP), mail relay checks, HTTP content and timing tests, and so on. You can also create monitor test interdependencies to cascade your checks, a useful option. Tests can also be scheduled on what is termed regular and irregular schedules, allowing you to be quite granular with your testing patterns.
Some of the alerting methods include sending messages to SMS, ICQ, e-mail, an event log, or a pop-up window. They can also trigger other events, such as starting or stopping services, rebooting the machine, or executing an external program.
With both the Professional and Enterprise editions of Advanced Host Monitor, you get the KS-Soft IP-tools—a set of 19 TCP/IP-related network utilities that includes port/protocol scanners and an SNMP trap watcher, which allows you to receive and process SNMP trap messages. In addition, both versions have a log analyzer and reporting component that allow you to trend historical monitoring data for your uptime reports and performance analysis reviews.
The interface itself provides a great way to get a quick overview of a number of tests simultaneously. With it, you can easily scan for issues on your monitored hosts.
Price: $599 for the Enterprise edition. $275 for the Professional edition.

Disk Cleanup
WinDirStat
www.windirstat.info
Much like your house or apartment, file storage locations tend to become cluttered over time with material that had purpose at one time, but now is just taking up valuable space. A little spring cleaning can do a lot of good, but, unlike your home, a directory tree structure doesn’t give you obvious visual clues as to where to start removing the clutter. Fortunately, there is a great visualization tool that can help you see what files are taking up space in your environment.
The GPL program WinDirStat, a Windows-based tool inspired by the Linux KDE kdirstat, shows you the files on selected drive as a set of different colored squares. The size of the squares represent the size of the files, letting you easily spot those unneeded behemoths of old ISO or ZIP files.
After you select your local drive (or a set of local drives), the program scans the directory tree, creating an in-memory map of the files. It then displays the visualization in the bottom pane of the GUI. Clicking on a colored square in the bottom pane navigates the Windows Explorer-like top pane to the location of the file. That top pane gives you useful stats like the file size, the date of the last change to that file, and other attributes. In addition, you see what percentage of the sub-tree is taken up by that file.
A very cool touch, colors are specific to file types, and clicking on a detected file type in the top-right will highlight all files of that type in the bottom pane. This is handy, for example, when you need to identify all those hidden MP3s your users have on the file server. You can also see what percentage of bytes those files comprise on the partition.
Price: Free download.

Book Review
Enemy at the Water Cooler
syngress.oreilly.com
Almost all businesses need to be connected to the Internet, and most are aware of the dangers presented by nearly constant attempts from the outside to compromise the connection points that segment the "outside" from the "inside" of their information infrastructure. However, many businesses overlook a potentially more damaging threat that exists within the organization. The power of these so-called insider threats is nicely illustrated in Enemy at the Water Cooler: Real-Life Stories of Insider Threats and Enterprise Security Management Countermeasures by Brian Contos (Syngress, 2006).
Contos offers real-world stories of past attacks and the impact they had on the companies involved. He claims that security is an ongoing process that consists of a "merger of people, process, and technology." With this book, he tries to illustrate the potential power of Enterprise Security Management (ESM) software solutions to mitigate insider threats.
As ArcSight’s Chief Security Officer, Contos relies heavily on the presentation of the company’s own ESM software solution, but that doesn’t detract from the overall value. The book lacks deep technical details, but you get a good idea of where to enhance your own security process in your organization by seeing where other organizations have failed and by understanding what an effectively implemented ESM solution can do to reduce exposure to an inside attack.
In the background chapter, "Cyber Crime and Cyber Criminals 101," Contos offers an overview of some of the different types of attackers to be aware of and their motivations. You also get a brief synopsis of some of their techniques, such as buffer overflows, code-packing, and Warhol Threats.
The following chapter delves deeper into the specifics of insider threats, including the ways in which an insider can damage a business, the concept of managing risk, and ways to address threats from a technical perspective. The technical perspective gives a brief overview of least privilege, strong authentication, access control, and incident detection and management. This paves the way to a discussion of ESM software solutions. Again, the book tends to deal only with the ArcSight product, but the key feature breakdown is applicable to any system.
The book provides a number of case scenarios from a cross-section of industries and environments, detailing different types of insider threats and how they were detected (and sometimes mitigated). These case studies may shed light onto some of your own business practices and perhaps offer solutions for reducing the risk of insider attacks in your environment.
Price: $49.95.

Write to Toolbox
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 and methods to help make operations and development easier for IT professionals.


 SQL Q&amp;A: Inside Clustering, Mysterious Hangs, the SA Account, and More
SQL Q&A
Inside Clustering, Mysterious Hangs, the SA Account, and More
Edited by Nancy Michell

Q I need to gain a better understanding of how clustering works. Our environment will consist of 64-bit Windows Server® 2003 running SQL Server™ 2005, a SQL Server Reporting Services (SSRS) Web farm (a report server scale-out deployment), an SSRS TempDB Catalog server and SQL Server that pumps data from a third-party database via a linked server and will store the data for SSRS.
We want a 3-node active/active/passive cluster. Node1 would be active and would store the data pumped from the third-party database. Node2 would be active and would store the SSRS Catalog. Node3 would be passive and be a failover for either Node1 or Node2. Can you help?

A Unfortunately, too many people are misled by the terms active/active and active/passive in reference to SQL Server clustering. They think that SQL clustering may support "scale out" of one database or SQL instance across multiple servers. That's just not the case. On SQL Server, there is no such thing as an active/active database or instance. An "instance" is an installation of SQL Server with corresponding databases. Our clustering per SQL Server instance is active (1) to passive (n) always (note that the value of n is anywhere from 1 to 7 depending on your version of SQL Server). That's why it's called failover clustering.
Once that is understood, people can start to consider installing multiple instances of failover clustering on a set of nodes. For example three physical servers all using shared disks could have one instance that is active by default on Node 1 and a second instance that is active by default on Node 2, and both can fail to Node 3. The instances are completely separate; they do not share data and are not active/active. They are both active/passive and both share the same failover instance. If both instances fail to Node 3, then the challenge over time is knowing whether it will buckle under the load. By design, failover is intended to rely on equal processing power for the failover. If peak load requires two nodes for processing under normal operation, it is unlikely that Node 3 would survive under the peak load normally assigned to two nodes.
That said, given the relative cost of hardware capable of running a cluster, we understand how people would weigh the likelihood of both principal nodes failing simultaneously and forcing the entire load to one node. With that consideration in mind, they may make the business decision to assume the risk rather than purchase 100 percent failover capacity.
Fortunately, there's some good news: SQL Server 2005 offers many more options for high availability (HA), including alternatives that can fail over more quickly than a cluster and can even mean duplicate copies of data (clustering relies on a single SAN). The options include mirroring, peer-to-peer replication, and more. With those new alternatives, we have a lot more options to satisfy all sorts of needs, including some that may combine a number of HA features.
The Microsoft® Cluster Configuration Validation Wizard (ClusPrep), now available for download, replaces what used to be the Hardware Certification List (HCL) testing, which could take months to validate a complete configuration to deem it "supportable" under clustering. This puts the hardware validation tool into the hands of the DBA, further driving down the cost (in dollars and time) of getting certified hardware in place. It may even make it possible to validate and deploy heterogeneous hardware within one cluster node set.

Q A delete procedure on one of my machines appears to be hanging after 12 hours. It's not blocked. Looking at the slowest query plan reveals a trigger running for 87,327 seconds, so I assume the procedure is hanging in that trigger. How can I see exactly which statement is hanging?

A It is quite possible that a loop within the trigger is not exiting for a variety of reasons. If you're hanging for a long time and you want to see which statement is executing, run the code in Figure 1. It will tell you which statement is currently running, and this should be the one that is causing your machine to hang.
Figure 1 Find currently executing statement (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT 'Handle not found in cache'
ELSE
   SELECT 'Current Statement'= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

Q I need to support transactional replication through a firewall. The publisher and distributor are on the outside of the firewall and the subscriber is on the inside. The subscriber is set to listen on 1433 and these are my machine names: Publisher: PUBMACHINE, Distributor: DISTMACHINE, Subscriber: SUBMACHINE. What ports do I need to open to allow the initial snapshot and the publication push to succeed?

A If you are using a push subscription, opening the SQL Server port (1433 in your case) should be sufficient as the distribution agent will be running on the distributor machine (outside the firewall) and will likely have local access to the snapshot files generated by the snapshot agent. But if you are using a pull subscription, the distribution agent running on the subscriber machine will need to access the snapshot files through the firewall somehow. Here are the options that you can consider.
Assuming that the snapshot files are already accessible from a file share outside of the firewall, you can open up the Windows® file sharing port(s) through the firewall so the distribution agent running inside the firewall can access the snapshot files located outside (though beware of the security implications that this may have for other parts of your infrastructure). Note that if you have configured a local path as the default snapshot location (SSMS default), you may need to use the /AltSnapshotFolder option of the distribution agent to override the snapshot file pickup location.
You can also configure replication to use FTP for transferring snapshot files (and you would need to open up port 21 for that).

Q I'd like to know if there are any drawbacks to disabling the SA account in SQL Server 2005 and if disabling SA adds true security value. Is there a whitepaper on this question?

A On a new SQL Server 2005 installation when Mixed Mode is not enabled, the SA account is disabled by default and a random password is generated for it. You can also disable it yourself. There isn't a whitepaper on it, but disabling and renaming logins is discussed in a best practices paper.
If you want to protect yourself from attempts to break the SA account, you can rename it as well. Just remember, if you enable a disabled account, you should set a new password for it.
To answer your question about whether this offers true security, remember that the added security of disabling the account comes from the fact that password guessing is futile while the account is disabled. No matter how much time a hacker or virus has, a brute force attack against a locked account will not succeed. Renaming or disabling SA will break applications that are dependent on using the SA account for their connectivity. Finding and then fixing or eliminating these applications should be considered as a priority anyway. As mentioned, the account cannot be used to connect to the database until it is reenabled. Plus, because the authentication process fails earlier, a failed attempt will take a lesser toll on the attacked system.

Q One of my larger online transaction processing (OLTP) databases has a log file that is twice the size of the data file. I've tried using the following commands to get the log file down to a reasonable size, but I need to reduce it further:
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

A You should change your backup database to a backup log statement. Alternatively you could put your database into simple recovery mode and issue the shrinkfile statement. After the shrink of the log is finished, set the database to its previous recovery model and back up the database. If it's still not shrinking, check to make sure you have no open transactions (use dbcc opentran). The following Knowledge Base article provides more information: support.microsoft.com/kb/907511.

Q If failover occurs during a scheduled SQL Server Agent job, what happens to that job after failover? Do I have to restart it manually?

A Yes, you will need to start it manually if you don't have some other process in place. If you don't want to have to restart jobs manually, you could write a script that updates a table upon job completion. If the value = 1, the job has been run; any other value indicates that the job was not completed and a second job will come in later and issue the start command. So while the job needs to be rerun if a failover occurs during its pass, by writing a script you can alleviate some of the worry for those crucial, middle-of-the-night jobs that absolutely must be completed before the next business day.
Tip: Upgrading and DBCC UPDATEUSAGE
Are you upgrading from SQL Server 2000 to SQL Server 2005?
If so, make sure you run DBCC UPDATEUSAGE right after your databases are upgraded.
DBCC UPDATEUSAGE reports and corrects pages and row count inaccuracies in the catalog views. These inaccuracies need to be corrected because they may cause incorrect space usage reports to be returned by the sp_spaceused system stored procedure. In SQL Server 2005, these values are always maintained correctly, so these databases should never experience incorrect counts. However, databases upgraded to SQL Server 2005 may contain invalid counts, so you should run DBCC UPDATEUSAGE after upgrading.
Here's how DBCC UPDATEUSAGE works. It corrects the rows, used pages, reserved pages, leaf pages, and data page counts for each partition in a table or index. If there are no inaccuracies in the system tables, DBCC UPDATEUSAGE returns no data. If inaccuracies are found and corrected and you have not used WITH NO_INFOMSGS, DBCC UPDATEUSAGE returns the rows and columns being updated in the system tables.
DBCC UPDATEUSAGE can also be used to synchronize space-usage counters. Because DBCC UPDATEUSAGE can take some time to run on large tables or databases, it should typically be used only when you suspect incorrect values are being returned by sp_spaceused. Note that sp_spaceused accepts an optional parameter to run DBCC UPDATEUSAGE before returning space information for the table or index.
DBCC CHECKDB has been enhanced in SQL Server 2005 to detect when page or row counts become negative. When negatives are detected, DBCC CHECKDB will output a warning and a recommendation to run DBCC UPDATEUSAGE to address the issue. Although it may appear as if upgrading the database to SQL Server 2005 caused this problem, be assured that the invalid counts existed before the upgrade procedure.
As an example, here's how you would update page or row counts or both for all objects in the current database. The following command specifies 0 for the database name and DBCC UPDATEUSAGE reports updated information for the current database:
DBCC UPDATEUSAGE (0);
GO
To update page or row counts or both for, say, AdventureWorks, and also to suppress informational messages, you would run a command similar the following, which specifies AdventureWorks as the database name and then suppresses all informational messages:
USE AdventureWorks;
GO
DBCC UPDATEUSAGE ('AdventureWorks') WITH NO_INFOMSGS; GO
For more information, search for DBCC UpdateUsage in SQL Server Books Online.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 Utility Spotlight: SMSMap
Utility Spotlight
SMSMap
Jeff Tondt
Download the code for this article: UtilitySpotlight2007_07.exe (2477KB)

A picture is worth a thousand words. This familiar proverb refers to the idea that complex stories can be told with just a single image, or that an image can be more influential than even a substantial amount of text. It also aptly characterizes the goals of visualization, where large amounts of data must be absorbed quickly.
To a System Management Server (SMS) geek like me, seeing the whole SMS hierarchy in one picture helps me understand how my infrastructure is laid out. You could use such a picture, perhaps, to show the before and after of an SMS migration plan to management. In certain troubleshooting cases, such a diagram could be very useful in finding a solution or at least in getting help from others. And, of course, as a responsible SMS administrator, you need to document your system hierarchy for all sorts of other reasons.

Getting the Picture
It’s not that you can’t draw such a diagram yourself. You can certainly roll up your sleeves, manually draw the SMS hierarchy, and document the site settings by hand. If you have Microsoft® Operations Manager (MOM) monitoring your SMS servers, you can have it diagram your hierarchy—though I should note that MOM is not exactly picture-friendly and it certainly doesn’t document your site settings. There may be other methods or handy tools, but I haven’t yet come across anything that adequately creates pretty pictures and helps document the site settings—at least not to my satisfaction.
So, I decided to roll my own. Thus SMSMap 1.0 was born. SMSMap is a Visual Basic® .NET application that uses the SMS managed libraries in the SMS SDK and automates Microsoft Visio® via COM. The utility queries a targeted SMS site server and then creates a visually appealing Visio diagram and exports site settings into an XML file. XML was selected as it is the most compatible way of documenting the site settings. I chose to show the SMS roles as well, not just the physical servers related to other SMS servers. This allows tinkering with the diagram via Visio layers to look at the SMS hierarchy from several viewpoints.
Figure 1 Radial format
Figure 1 Radial format
Currently, the program lets you select six different formats for the Visio diagram. For example, Figure 1 shows a very simple SMS hierarchy using the radial format, while Figure 2 shows the same hierarchy using the flow chart format. The utility works quite well with much larger hierarchies, but I wanted to keep things simple here.
Figure 2 Flow chart format
Figure 2 Flow chart format
At some point, SMSMap will likely evolve to document all site settings. Currently, it documents only the SMS site roles and all boundaries. With little effort, many more site settings could be exported into the XML file.

Using SMSMap
The source code and installation files for SMSMap are available on the TechNet Magazine Web site. To install it, simply execute SMSMapSetup.msi, which walks you through the installation. Remember, SMSMap uses Visio, so you must also have that installed already. After the installation, execute C:\Program Files\Microsoft\smsmap\smsmap.exe (unless you installed it in a different location from the default).
You can run SMSMap from any machine; you don’t have to run it from the site server (and it’s unlikely that many SMS site servers will have Visio installed). Enter the SMS Site Server name where you want the query to originate. This can be the central site if you want to query the whole hierarchy or it can be any child primary site server, but in that case you only get the hierarchy from that child primary site on down. Next, enter the account that has permission to query SMS using the format domain\username, and then the password for that account. (The password will not be displayed, so you can run this in front of others.)
Six radio buttons let you select the layout, and you can choose whether to allow or prevent SMS roles from appearing in the drawing. These check boxes are located under the Options tab. Pressing the Draw button starts the utility. It first checks to see if Visio is available, then queries the specified SMS primary site server and adds the objects to the Visio diagram. The Visio diagram may look ugly while SMSMap is dumping in objects, but at the end the utility organizes them into the format you specified at the beginning.
Diving Deeper
Now you’ve seen why and how to document your SMS hierarchy using SMSMap. For those who want to flex their developer muscles, let’s take a closer look at how the utility works.
SMSMap uses the Managed SMS Site Server Interfaces to gather the SMS information, and the Visio Primary Interop Assemblies to generate a Visio diagram that lays out all the necessary shapes. The SMS 2003 SDK Version 3.1 contains the latest release of the Managed SMS Site Server Interfaces. This set of managed interfaces lets you connect and configure an SMS Site Server through any Microsoft .NET Framework-enabled language or application.
These interfaces use the System.Management namespace to interact with an SMS provider through Windows® Management Instrumentation (WMI). To use the interfaces you must develop your application with a .NET-compatible language (for example, C#, Visual Basic .NET, and so forth) and reference the Microsoft.SystemsManagementServer.Automation.dll that the .NET assembly supplied with the SMS SDK.
The .NET Management classes clean up many of the idiosyncrasies of the WMI object model to present a consistent, object-oriented model. The basic tasks of WMI connection, object enumeration, method execution, object deletion, object retrieval and event capture can all be achieved through the .NET Management classes.

Visio Primary Interop Assemblies
A Primary Interop Assembly lets you use managed code to control COM apps like Visio programmatically. The Visio Primary Interop Assemblies allow you to integrate and extend Visio functionality into managed apps.
If you already have the .NET Framework installed on your computer, when you subsequently install Visio, the installer adds the Visio Primary Interop Assemblies to the Global Assembly Cache (GAC) on your computer. You can add a reference to the Visio Primary Interop Assemblies from your managed applications.
After adding the reference to the project, you can start working with Visio objects from your managed application. Visio has an extensive object model that provides a set of classes, interfaces, and enumerations so that you can create diagrams programmatically.

Program Flow
Now that I have described the main component interfaces for Visio and SMS, I will explain the flow of the utility itself.
The first step when using the managed interfaces is to connect to the SMS provider. This can be accomplished by creating a new instance of the SMSProvider class. Internally, this class will find the SMS provider for the specified site server and connect to it with a given set of credentials. If the provider is on the local machine, the currently logged-in credentials will be used instead of the supplied credentials when connecting to the provider. Although you can run SMSMap on the SMS server, I recommend running it on a separate workstation that has Visio installed. Most SMS site servers do not have Visio installed for obvious reasons.
When you access data on the SMS site through the SMSProvider class, security rights are treated as if you were using the SMS Administrators Console. This means, for instance, that if you try to configure the settings for a site server through an SMSProvider, the account you connect to the provider with must have the same set of rights as if you were using the administrator’s console.
The SMSProvider class supplies a GetSiteSettings method that allows you to get the site settings for the current site (which the provider belongs to) or for any site with a specific site code. The code snippet in Figure 3 shows how SMSMap connects to the provider for the targeted site server. The user credentials are expected to be passed in Domain\User format. You can also specify "." to indicate the current machine. Figure 3 also includes code that helps display the results in the UI and for logging.
Figure 3 GetSiteSettings snippet (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
The next step is to set up the XML file for gathering and recording the SMS information for the targeted site server, as shown in Figure 4.
Figure 4 Creating the XML file (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
Next, the targeted site needs to be drawn in the Visio diagram and updated in the UI and log, as you can see in Figure 5.
Figure 5 Drawing the site in Visio (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
To go through the entire hierarchy under the targeted site, the same basic code described above that queries SMS and draws in Visio is executed. This is a function named Level that is called recursively to ensure all child sites are queried no matter how large the hierarchy is. Level gathers the SMS site information and records it in XML, the UI, and the log for each child site under the targeted site. Finally, Figure 6 shows how the Visio diagram is formatted using the format selected when the utility starts. Then the XML and log files are closed.
Figure 6 Finishing Up (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

Just a Beginning
Of course, this is just a start and there are many possibilities for improvement. Device Management Points need to be investigated as I don’t see them in the SDK. A number of additional site settings could be added to fully document a site. Perhaps some more work needs to be done on adding a wider variety of Visio layout settings in order to help make small and large hierarchies look better. Each layout type poses its own difficulties when trying to create effective displays. And, of course, adding support for System Center Configuration Manager 2007 is a very important next step. But even this first version of SMSMap can help SMS administrators display the big picture and try some what-if scenarios with Visio layers and transparency.
If you download the source code, you can extend the utility to meet your own needs. I tested SMSMap on Windows XP SP2 with Visio 2003 and Windows Vista™ Enterprise with Visio 2007. If you have any suggestions on how to improve this utility, please e-mail me at jeff.tondt@microsoft.com.

Jeff Tondt is a Senior Consultant II for Microsoft Consulting Services. He focuses on the areas of systems management, automation, and patch management. He is an SMS subject matter expert and can be reached at jeff.tondt@microsoft.com.


 How IT Works: Troubleshooting RPC Errors
How IT Works
Troubleshooting RPC Errors
Zubair Alexander

If you’ve worked with Windows server platforms over the years, chances are you’ve seen remote procedure call (RPC) errors at one time or another. They tell you that the RPC server is unavailable, or that there are no more endpoints available, or provide some other cryptic warning. If you’re confused by these messages, read on. I will
look at some common errors, various techniques you can use to identify the RPC errors you see, and discuss some solutions to solve specific problems. But before I talk about the specific RPC errors and solutions, let’s get a solid grounding in RPC terminology.

What Is RPC?
RPC is an interprocess communication (IPC) method that is used by clients and servers to communicate with each other. Simply put, RPC is used by programs, typically on a client computer, to execute a program on a server computer. For example, Microsoft® Outlook® clients communicate with Microsoft Exchange Server using RPC. The client computer sends a message to the server computer with certain arguments. The server responds to the client with a message that contains the results of the executed program.
Integral to this process is the endpoint—the name, port, or group of ports on a computer that is monitored by a server for incoming client requests. More specifically, it is a network-specific address of a server process that is used for RPCs.
The Endpoint Mapper, which is part of the RPC subsystem, is responsible for responding to the clients’ requests to resolve dynamic endpoints. In some situations, Endpoint Mapper is also responsible for dynamically assigning endpoints to servers.
Another important RPC component is the Locator Service. It maintains a list of RPC services and servers on the network. A Windows® client connects to the domain controller over the Server Message Block (SMB) ports (TCP 139 and 445) and searches for RPC services or servers through the Locator Service.
Most built-in Windows services communicate with each other using RPC. For example, certificate services, DCOM, FRS, MSMQ, MAPI, and Active Directory® Replication Service use RPC for communication. Therefore, if the RPC service is not functioning properly on a network, you may experience any number of communication problems.

RPC Errors
Now let’s look at some of the errors you may encounter when the RPC service is failing. (This is by no means a complete list.)
When the File Replication Service (FRS) fails, it could be the dreaded "RPC Unavailable" error at work. If you try to map a drive, you may get the "Access denied" error. When using Active Directory Users and Computers, you may see the error that states, "The specified domain either does not exist or could not be contacted." Logging on to the domain may give you an error that claims, "The system cannot log you on to this domain because the system’s computer account in its primary domain is missing or the password on that account is incorrect."
When the Microsoft Outlook client tries to communicate with Exchange Server, RPC failures may give the client a misleading error such as, "Your logon information is incorrect," or "Outlook could not log on."
In addition to these errors, when the RPC service is not available, you may experience other problems. For instance, you may not be able to browse the domain in My Network Places, or you may not be able to open the Group Policy snap-in.
These are just some of the instances in which you may not have expected RPCs to cause problems. There are many more instances, and anytime you’re involved with remote processes, RPC issues may be the root cause of your difficulties. So how do you know for sure and, more importantly, how do you track down the precise error? Let’s find out.

Troubleshooting
If you suspect you are having problems with the RPC service, there are several tools you can use to diagnose the problems.
One choice is the Repadmin tool. This program is ordinarily used to monitor and troubleshoot Active Directory replication problems, but it can also be used to troubleshoot RPC Endpoint Mapper problems. To run it, at the command prompt, type repadmin /bind. If you are having RPC problems, you may see a message such as this: "There are no more endpoints available from the endpoint mapper." That’s your first clue that the problem is related to RPC.
Another option is using the Domain Controller diagnostic tool (DCDiag), a command-line program for diagnosing problems with domain controllers. If you see the error "Status is 1722: The RPC server is unavailable," you know you have an RPC problem that the Domain Controller diagnostic tool just happened to uncover.
There are times when you’re using Ntdsutil (a command-line tool used to manage Active Directory and perform numerous maintenance tasks) that you may experience RPC errors if you try to connect to the server. Most likely you’ll see one of the more common errors such as "There are no more endpoints available from the endpoint mapper." Again, this is a clue that there may be problems with the RPC service. The Gpotool tool, which checks the consistency of Group Policy objects on domain controllers, will also give you similar errors if RPC is to blame.
The Dcpromo.log that is generated when you promote a Windows 2000 Server or Windows Server® 2003 server to a doman controller using the Dcpromo tool can also reveal issues with RPC. For instance, if the promotion fails, take a look at the log. It’s located in the %windir%\debug folder. The errors listed will indicate something to the effect that the directory service failed to replicate the partition, or failed to create the object. At the end of the message there will be an error code. Here’s an example of the type of error message that you might see in the Dcpromo.log:

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
Notice the error code 1722, which occurs four times in this message and indicates that the RPC server is unavailable. Figure 1 lists some error codes and their descriptions, but many more can be found at msdn2.microsoft.com/ms681386.
Figure 1 Error codes and their descriptions (Close Figure 1)

Error Code | Description
58 | The specified server cannot perform the requested operation.
1721 | Not enough resources are available to complete this operation.
1722 | The RPC server is unavailable.
1723 | The RPC server is too busy to complete this operation.
1727 | The remote procedure call failed and did not execute.
1753 | There are no more endpoints available from the endpoint mapper.

Resolving RPC Errors
Now that you’ve seen how some of the RPC errors can be detected, let’s look at some of the solutions.
Microsoft clients connect to RPC Endpoint Mapper on port 135. Then the Endpoint Mapper tells the client which port a requested service is listening on. The port numbers are assigned dynamically and can be anywhere between 1024 and 65,535. When you see errors, such as 1753, that tell you that no more endpoints are available from the Endpoint Mapper, this means that the RPC Endpoint Mapper was unable to utilize a port greater than 1024 for a service. I’ll look at this topic more closely a little later.
The first thing you should do is check the status of the RPC service on the server. Depending on the type of server role, the RPC and the RPC Locator service should have the status listed in Figure 2. If either of the two services is not configured as shown in the figure, try to adjust the status, reboot your server, and then test to see if it resolves your problem.
Figure 2 Status of RPC service (Close Figure 2)

Server Role | RPC Service | RPC Locator Service
Windows Server 2003—Domain Controller | Started, Automatic | Stopped, Manual
Windows Server 2003—Member Server | Started, Automatic | Stopped, Manual
Windows Server 2003—Standalone Server | Started, Automatic | Stopped, Manual
Windows 2000 Server—Domain Controller | Started, Automatic | Stopped, Automatic
Windows 2000 Server —Member Server | Started, Automatic | Started, Manual
Windows 2000 Server—Standalone Server | Started, Automatic | Stopped, Manual
Verify that your client can successfully ping the server that is having connectivity problems. For example, if you are having problems communicating to a server called DC1 whose IP address is 192.168.1.200, use the following command at the command prompt to verify that DNS is properly resolving the host DC1:
Ping –a 192.168.1.200
Make sure you use the –a switch with the IP address, not the host name.
If everything is working fine, you should get a response from DC1 that looks something like the ping response in Figure 3. Notice that instead of simply resolving the IP address 192.168.1.200, Ping also resolved the host name dc1.contoso.com. This confirms that DNS name resolution is working properly and resolving to the host dc1.contoso.com exactly as expected.
Figure 3 Ping response (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
You should also ensure that the registry on your Windows XP or Windows 2000 client contains at least the four ClientProtocols listed in the right-hand pane in Figure 4.
Figure 4 RPC ClientProtocols listed in the registry
Figure 4 RPC ClientProtocols listed in the registry
If any of the entries are missing, add a new string value with the name and data type shown in Figure 4. By default, there’s a fifth entry called ncacn_nb_tcp, which is used to identify NetBIOS over TCP as the protocol family for the endpoint. Depending on your configuration, you may not have that entry listed under ClientProtocols and can manually add it to see if it resolves the RPC errors.
Notice the keys listed under the Rpc folder in the left pane in the figure, namely ClientProtocols, NameService, NetBios, and SecurityService. If you happen to see a key called Internet that has no values, try removing the key and restarting your computer. That may help solve your problem. As always, though, be sure to exercise caution when you’re modifying the Windows registry.
As mentioned earlier, RPC can use ports between 1024 and 65,535, so you need to make sure that these ports are not blocked by a firewall. The simplest way to ensure that a port is open is to use the Port Query tool. This tool comes in two flavors: a command-line version (PortQry) and a GUI version (PortQueryUI).
PortQry is available for download from the Microsoft Download Center. For additional information, check out the article "Description of the Portqry.exe Command-Line Utility". There you will find brief descriptions of PortQry status reports and examples of commands to use to resolve problems. Keep in mind that you can also use the GUI version, which is much simpler and can be downloaded at go.microsoft.com/fwlink/?LinkId=73740.
When using Port Query, you should be sure to run it on a computer that is not experiencing RPC errors and run it against a computer that is having problems with RPC. For example, if you want to verify that port 135—which is used by RPC Endpoint Mapper—is open, use PortQry at the command prompt as follows:
portqry -n [servername] -e 135
Whether you used PortQuery or PortQueryUI, you would get the results, like the following:
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
The last line shows that port 135 is open. Otherwise, the last line would have indicated NOT LISTENING.
To check for a range of ports, enter the range of port numbers separated by commas, such as "135,1024-5000".

Additional Solutions
If you’ve tried all the tricks listed so far and the problem is still unresolved, there are some additional options open to you. Depending on the specific problems in your environment, you might want to try one of the following modifications to the registry. (Wait! Before making any changes to the registry, it’s important to make sure you’ve backed up your system, especially the registry, so if things go wrong you have the ability to restore your computer to its previous state.)
One option is to adjust MaxUserPort to specify the highest port number that TCP can assign when an application requests an available user port from the system. By default, Windows Server 2003 sets the MaxUserPort value to 5000, which means it is using 5000 as the highest port number, even if the entry doesn’t exist. Depending on your configuration, you may not have this entry in the registry, in which case you can add this entry to the location shown in Figure 5.
Figure 5 MaxUserPort setting in the registry
Figure 5 MaxUserPort setting in the registry
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
When modifying the registry you need to be aware of any other potential side effects, which is not always easy. Modifying this entry may have an effect on Microsoft Exchange Server if the value is set to below 50,000. If the Exchange Server Best Practices Analyzer (BPA) finds the value of the MaxUserPort registry key to be less than 50,000, it displays a warning. Microsoft recommends that you set the value to 60,000; otherwise you may cause Name Service Provider Interface (NSPI) proxy warnings, such as Event 9040. For more information, see Microsoft’s document "MaxUserPort Value is Too Low".
You can also adjust TcpMaxDataRetransmissions. TCP packets expect an acknowledgment from the receiving end. If there’s no acknowledgment before the timer expires, then the packets are retransmitted, up to the TcpMaxDataRetransmissions times. The default value for this parameter is 5 but you may want to try a value of 4, or even 3. Do not use a value below 3.
If the TcpMaxDataRetransmissions registry entry does not exist, you can add it to the registry in the following location, like so:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
For more information on TcpMaxDataRetransmissions, check out Microsoft’s Knowledge Base article 170359, "How to Modify the TCP/IP Maximum Retransmission Timeout".
Another registry value that you may want to experiment with is TcpTimedWaitDelay. If a client uses too many ports, it is quite possible that it may run out of ports before TCP/IP releases closed connections. This is because TCP/IP doesn’t release the connection until two maximum segment lives (MSLs) have passed (this is referred to as time-wait state). Moreover, since each MSL is defined as 120 seconds and TCP/IP doesn’t release the connection until two MSLs have passed, it takes up to 240 seconds (4 minutes) for TCP/IP to release a closed connection. Note that this was a known problem in Windows NT® that was corrected with a service pack; as a result, you are far less likely to experience this problem today. However, Microsoft recommends adjusting this setting as one of the possible solutions to resolve the RPC Endpoint Mapper errors, as explained in the Knowledge Base article "How to Troubleshoot RPC Endpoint Mapper Errors".
The TcpTimedWaitDelay is added to the registry in the following location:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
For more information on TcpTimedWaitDelay, check out the Knowledge Base article "Windows NT Clients Run Out of Ports". Although the article does not recommend any specific numbers, you might want to try reducing TcpTimedWaitDelay to 60 (seconds) in decimal, which is 3c in hexadecimal.

Conclusion
RPC errors can be the root cause of numerous communication errors on your network. Luckily, there are several creative ways you can troubleshoot these elusive problems. Some of the tools I’ve suggested here are built in, while others are available in the Windows Server Resource Kit. Many are listed in Figure 6. You can use these tools to detect the cause and location of the RPC errors and then use one of the techniques listed in this article to resolve the errors.
Figure 6 RPC troubleshooting tools (Close Figure 6)

Tool | Description
DCDiag | Analyzes the state of domain controllers.
Event Viewer | Displays logged events.
Gpotool | Determines whether the policies are valid and consistent.
NetDiag | Used to test network connectivity.
Network Monitor | Monitors and captures network traffic.
Ntdsutil | Provides management facilities for Active Directory.
PortQry, PortQueryUI | Used for TCP/IP connectivity testing.
Repadmin | Diagnoses replication problems between Windows DCs.
RPCDump | Typically used together with Network Monitor.
RPCPing | Used to confirm RPC connectivity.

Zubair Alexander, MCSE, MCT, and Microsoft MVP, is the owner of SeattlePro Enterprises, an IT training and consulting business. His experience covers the spectrum of IT education: author, college instructor, consultant, network engineer, public speaker, security architect, systems administrator, technical editor, and trainer. Zubair may be reached at alexander@techgalaxy.net.


 The Cable Guy: IPv6 Traffic over VPN Connections
The Cable Guy
IPv6 Traffic over VPN Connections
Joseph Davies

As you begin to evaluate the role of Internet Protocol version 6 (IPv6) on your intranet and start planning for its deployment, you should understand how IPv6 traffic is supported over virtual private network (VPN) connections in Windows. With VPN connections, you can extend your network to include links across public
networks such as the Internet. VPN connections are protected by strong authentication protocols to validate the credentials of the connecting user, and encryption methods to provide data confidentiality.
Windows® XP and Windows Server® 2003 include an IPv6 protocol stack, but many core services and networking components do not support IPv6. Windows Vista™ and Windows Server 2008, formerly code-named "Longhorn," have full-featured support for IPv6, which is installed and enabled by default. In fact, almost all of the networking applications and services included with Windows Vista and Windows Server 2008 support IPv6. This month, I examine the support in Windows Vista, Windows Server 2008, Windows XP, and Windows Server 2003 for IPv6 traffic sent over VPN connections that are established across the Internet Protocol version 4 (IPv4) and IPv6 Internets.

VPN Connections across the IPv4 Internet
For most of today’s intranets, VPN connections are created across the IPv4 Internet. Figure 1 shows Windows-based components for VPN connections of this type. These components consist of the following:
Figure 1 Windows-based components for VPN connections across the IPv4 Internet
Figure 1 Windows-based components for VPN connections across the IPv4 Internet
VPN Client This is a computer that initiates a remote access VPN connection to a VPN server and communicates with intranet resources. A remote access VPN connection allows the VPN client to act as if it were directly connected to the intranet. A VPN client can run either client or server versions of Windows.
VPN Server This computer listens for remote VPN connection attempts, enforces authentication and connection requirements, and routes packets between VPN clients and intranet resources. A VPN server typically runs a server version of Windows with the Routing and Remote Access service.
VPN Router A VPN router is a computer that initiates or listens for site-to-site VPN connection attempts. A site-to-site VPN connection connects two portions of an intranet together. A VPN router runs a server version of Windows and the Routing and Remote Access service.
VPN Connection A VPN connection is the logical link between the VPN client and the VPN server or between VPN routers as defined by the encapsulation of a VPN protocol.
IPv6-Enabled Intranet This intranet can forward IPv6 traffic, either natively or tunneled as IPv4 packets.
IPv6/IPv4 Host This intranet node sends and receives IPv6 traffic, either natively or tunneled as IPv4 packets.
Windows-based VPN clients, servers, and routers can use the following VPN protocols to encapsulate the packets sent across the VPN connection: Point-to-Point Tunneling Protocol (PPTP), Layer Two Tunneling Protocol with Internet Protocol security (L2TP/IPsec), and Secure Socket Tunneling Protocol (SSTP). SSTP is only supported by Windows Server 2008.
For VPN connections across the IPv4 Internet, there are two methods that are used for sending IPv6: IPv6 packets tunneled as IPv4 packets, hereafter referred to as IPv6-over-IPv4 traffic, and native IPv6 traffic.
Throughout this column, support for IPv6 traffic across VPN connections is stated in terms of VPN protocols and versions of Windows. For remote access VPN connections, a given combination of VPN protocol and version of Windows implies support by both remote access client and remote access server components of Windows.

IPv6-over-IPv4 Traffic
In this method, a remote access client or an IPv6/IPv4 host on the intranet encapsulates IPv6 packets with an IPv4 header and sends the result as an IPv4 packet. For intranets, the IntraSite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 transition technology (RFC 4214) allows IPv6/IPv4 nodes to exchange IPv6 traffic across an IPv4-only intranet. With ISATAP, you can enable IPv6 connectivity on your IPv4-only intranet without having to configure or upgrade your existing routers to support native IPv6 addressing and forwarding. For more information about ISATAP, see "IPv6 Transition Technologies" at microsoft.com/technet/network/ipv6/ipv6coexist.mspx.
Figure 2 shows the general packet structure for VPN traffic when sending an IPv4 packet using a VPN connection across the IPv4 Internet. The IPv4 packet is encapsulated by the VPN protocol with a header and, depending on the VPN protocol, a trailer. The result is encapsulated with an IPv4 header that allows forwarding across the IPv4 Internet.
Figure 2 IPv4 packets using a VPN connection across the IPv4 Internet
Figure 2 IPv4 packets using a VPN connection across the IPv4 Internet
For IPv6-over-IPv4 traffic, the payload of the IPv4 packet sent across the VPN connection is an IPv6 packet. Figure 3 shows the general packet structure for VPN traffic when sending an IPv6-over-IPv4 packet using a VPN connection across the IPv4 Internet.
Figure 3 IPv6-over-IPv4 packets using a VPN connection across the IPv4 Internet
Figure 3 IPv6-over-IPv4 packets using a VPN connection across the IPv4 Internet
For remote access VPN connections, IPv6-over-IPv4 traffic across the IPv4 Internet is supported by PPTP and L2TP/IPsec in Windows Vista, Windows Server 2008, Windows XP SP1 or higher, and Windows Server 2003 and by SSTP in Windows Server 2008. For site-to-site VPN connections, IPv6-over-IPv4 traffic across the IPv4 Internet is supported by PPTP and L2TP/IPsec in Windows Server 2008 and Windows Server 2003.

Native IPv6 Traffic
For native IPv6 traffic, the VPN client, server, or router sends IPv6 packets across the VPN connection without the initial IPv4 encapsulation. This works for intranets that have native IPv6 connectivity and requires that the VPN clients, servers, and routers support the IPv6 Control Protocol (IPV6CP), RFC 2472, which defines how IPv6 nodes negotiate IPv6 configuration options for Point-to-Point Protocol (PPP)-based connections. Windows Vista and Windows Server 2008 support IPV6CP while Windows XP and Windows Server 2003 do not. Figure 4 shows the general packet structure for VPN traffic when sending a native IPv6 packet using a VPN connection across the IPv4 Internet.
Figure 4 Native IPv6 packets using a VPN connection across the IPv4 Internet
Figure 4 Native IPv6 packets using a VPN connection across the IPv4 Internet
For remote access VPN connections, native IPv6 traffic across the IPv4 Internet is supported by PPTP and L2TP/IPsec in Windows Vista and Windows Server 2008 and by SSTP in Windows Server 2008. For site-to-site VPN connections, native IPv6 traffic that travels across the IPv4 Internet is supported by PPTP and L2TP/IPsec in Windows Server 2008.

VPN Connections across the IPv6 Internet
You can also make VPN connections across the IPv6 Internet. Such VPN connections are uncommon now, but will become more prevalent as more Internet service providers offer IPv6 to their customers and more organizations include IPv6 Internet connectivity in their intranet edge networks.
In order to support VPN connections across the IPv6 Internet, the VPN protocols that are used must support connections over IPv6. In Windows Vista and Windows Server 2008, the L2TP/IPsec and SSTP VPN protocols support remote access VPN connections over IPv6. In Windows Server 2008, L2TP/IPsec supports site-to-site connections over IPv6. VPN connections across the IPv6 Internet use the same set of components as those for VPN connections across the IPv4 Internet for both remote access and site-to-site VPN connections.
There are also two ways of sending IPv6 packets over the IPv6 Internet: IPv6-over-IPv4 traffic and native IPv6 traffic. Figure 5 shows the general structure of IPv6-over-IPv4 packets when they are sent over a VPN connection across the IPv6 Internet.
Figure 5 IPv6-over-IPv4 packets using a VPN connection across the IPv6 Internet
Figure 5 IPv6-over-IPv4 packets using a VPN connection across the IPv6 Internet
For remote access VPN connections, IPv6-over-IPv4 traffic across the IPv6 Internet is supported by L2TP/IPsec in Windows Vista and Windows Server 2008 and by SSTP in Windows Server 2008. For site-to-site VPN connections, IPv6-over- IPv4 traffic across the IPv6 Internet is supported by L2TP/IPsec in Windows Server 2008. Just as for IPv6-over-IPv4 traffic over the IPv4 Internet, IPv6-over-IPv4 traffic over the IPv6 Internet requires the deployment of an IPv6 transition technology such as ISATAP on your intranet.
Figure 6 shows the general structure of native IPv6 packets when they are sent over a VPN connection across the IPv6 Internet. Just as for native IPv6 traffic over the IPv4 Internet, native IPv6 traffic over the IPv6 Internet requires IPV6CP support and the deployment of native IPv6 connectivity on your intranet.
Figure 6 Native IPv6 packets using a VPN connection across the IPv6 Internet
Figure 6 Native IPv6 packets using a VPN connection across the IPv6 Internet
For remote access VPN connections, native IPv6 traffic across the IPv6 Internet is supported by L2TP/IPsec in Windows Vista and Windows Server 2008 and by SSTP in Windows Server 2008. For site-to-site VPN connections, native IPv6 traffic across the IPv6 Internet is supported by L2TP/IPsec in Windows Server 2008.

Wrapping Up
Figure 7 shows the four methods for sending IPv6 traffic over VPN connections and the support in Windows for the two different types of VPN connections. In a nutshell, if you are using an IPv6 transition technology such as ISATAP on your intranet, you can send IPv6-over-IPv4 traffic over VPN connections across both IPv4 and IPv6 Internets. If your intranet supports native IPv6 connectivity, you can send native IPv6 traffic over VPN connections across both the IPv4 and IPv6 Internets with Windows Vista and Windows Server 2008.
Figure 7 Support for IPv6 traffic over VPN connections in Windows (Close Figure 7)

Method of Sending IPv6 Traffic | Remote Access VPN Connections | Site-to-Site VPN Connections
IPv6-over-IPv4 traffic over the IPv4 Internet | PPTP and L2TP/IPsec in Windows Vista, Windows Server 2008, Windows XP SP1 or higher, and Windows Server 2003 SSTP in Windows Vista SP1 and Windows Server 2008 | PPTP and L2TP/IPsec in Windows Server 2008 and Windows Server 2003
Native IPv6 traffic over the IPv4 Internet | PPTP and L2TP/IPsec in Windows Vista and Windows Server 2008 SSTP in Windows Vista SP1 and Windows Server 2008 | PPTP and L2TP/IPsec in Windows Server 2008
IPv6-over-IPv4 traffic over the IPv6 Internet | L2TP/IPsec in Windows Vista and Windows Server 2008 SSTP in Windows Vista SP1 and Windows Server 2008 | L2TP/IPsec in Windows Server 2008
Native IPv6 traffic over the IPv6 Internet | L2TP/IPsec in Windows Vista and Windows Server 2008 SSTP in Windows Vista SP1 and Windows Server 2008 | L2TP/IPsec in Windows Server 2008

Joseph Davies is a technical writer with Microsoft and has been teaching and writing about Windows networking topics since 1992. He has written five books for Microsoft Press and is the author of the monthly online TechNet Cable Guy column.


 Windows PowerShell: Rethinking the Pipeline
Windows PowerShell
Rethinking the Pipeline
Don Jones

Much has been said about how Windows PowerShell is different, new, and exciting—though it is based on command-line interface concepts that have been around for decades, primarily in UNIX and Linux-based operating systems. But the common terminology Windows PowerShell shares with its antecedents can make it easy to
overlook the real flexibility and uniqueness of Windows PowerShell™—and its eminent suitability for a Windows® environment.
One of the most often talked-about features of Windows PowerShell is its pipeline, but it’s also, unfortunately, one of the most misunderstood features. That’s because it relies on terminology that was defined during the early 1970s, which once represented entirely different and less-powerful functionality.

The Origin of Pipes
One of the first UNIX shells ever created was the Thompson shell, which was very primitive and featured only the most basic scripting language elements with no variables. The shell had a deliberately modest design as its only real purpose was to execute programs. However, it introduced a key concept that improved upon other shells of the time: pipes. By using the < and > symbols, the shell could be instructed to redirect input and output to and from different commands. A user was now able to, for example, redirect command output to a file.
This syntax was later expanded so that the output of one command could also be piped to the input of another command, allowing long sequences of commands to be chained together to accomplish more complicated tasks. By version 4 of the shell, the vertical line character "|" was adopted for piping and hence became known as the pipe character. Even the earliest versions of MS-DOS® implemented basic piping through these characters, allowing a user to, for example, pipe the output of the type command into the input of the more command, creating a one-page-at-a-time display for long text files.
Although the Thompson shell was widely regarded as inadequate by the time UNIX version 6 was released in 1975, the concept of pipes was well-embedded with shell developers and users and has been carried forward into a number of technologies in use today.

Piping Text
A limitation of almost all shells is their inherently text-based nature. In UNIX-based operating systems, this isn’t actually a limitation, but rather a reflection of how the OS itself works. Nearly any resource in UNIX can be represented as a file of some sort, meaning the ability to pipe text from one command to another provides a great deal of power and flexibility.
Text, however, is definitely limiting when it comes to management information. For example, if I were to present you with a list of services running on a Windows computer, you would almost certainly be able to make sense of it. Perhaps I’d place the service name in the first column and its startup mode in the second. Your powerful human brain would transparently and instantaneously parse, or translate, the text display into meaningful information that you could work with. Computers, though, aren’t nearly that smart: to have a computer do something meaningful with that list, you’d have to tell the computer that the first column consists of characters 1 through 20, perhaps, and that characters 22 through 40 make up the second column, and so on.
For ages, this type of text file parsing was the only way administrators had to chain multiple commands together. In fact, scripting languages such as VBScript and Perl excel at string manipulation primarily because they need to be able to accept text output from one program or command and then parse that output into some kind of useful data that can be used for some subsequent task. I’ve written VBScript jobs, for example, that accepted the text output of the Dir command, parsed the output for file names and dates, and then moved old, unused files to an archive location. String parsing is exceedingly tricky, because exceptions—variations in the input data—almost always occur, requiring you to redo the logic in the script to deal with all the possible permutations.
As a form of administrative scripting or automation in a Windows environment, string parsing is less useful. This is because Windows itself doesn’t store much information in an easy-to-access text format. Instead, it uses datacentric stores, such as Active Directory®, the Windows registry, and the certificate store, so that scripters have to use one tool first to generate some form of text output and then a script to parse that text and do something with it.

Objects Are Easier
Windows software developers have always had things a bit easier. Initially, Microsoft developed COM specifically to represent the complex internal workings of Windows in an easier-to-use fashion. Today, the Microsoft® .NET Framework carries on that same task—it represents the inner workings of software in a standardized fashion.
Generically, both COM and .NET expose items as objects. (A software developer might take exception to this simplification, but for the sake of our discussion, a simple term is sufficient.) These objects all have members of various types. For our purposes, the objects’ properties and methods are what we’re most interested in. A property essentially describes an object in some way, or it modifies the object or its behavior. For example, a service object might have a property that contains the service’s name and another property that contains the service’s startup mode. Methods cause an object to take some action. A service object might have methods named Stop, Start, Pause, and Resume, for example, representing the various actions you can take with a service.
From a programming—or scripting—perspective, an object’s members are referred to using a dotted notation. Objects are often assigned to variables, giving you a way to physically manipulate the object. For example, if I have a service assigned to the variable $service, I can stop that service using the syntax $service.Stop. Or I can retrieve the service’s display name by displaying $service.Name.

Objects in the Pipe
Because Windows is a large, complex operating system, and because it doesn’t store its management data in text-style representations, older shell techniques aren’t terribly suitable for it. For example, suppose I have a command-line tool, named SvcList.exe that produces a formatted list of services and their startup modes. In the Windows command line shell—a shell that has its roots firmly in the decades-old MS-DOS shell—I might run something like:
SvcList.exe | MyScript.vbs
This statement retrieves a list of services and pipes that list to a VBScript file. I’d have to write the VBScript file to parse the formatted list and do whatever I wanted it to do—perhaps output any services with a startup mode of Disabled. This task would be time-consuming. Ultimately, the problem is that SvcList.exe has an output that is unique—it doesn’t share a common format that other commands can easily consume to make use of its output.
Objects, however, can provide that common format and that’s why the Windows PowerShell pipeline works with entire objects, not just text. When you run a cmdlet like Get-WMIObject, you’re producing a group—or collection, in programmer terms—of objects. Each object comes complete with properties and methods that let you manipulate it. If I pipe the objects to the Where-Object cmdlet, I can filter them so that just the objects I want are displayed. Where-Object doesn’t need to parse any text because it isn’t receiving any text—it’s receiving objects. For example:
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
Or, if you prefer the shorter syntax available through aliases:
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
What’s interesting is that Windows PowerShell always passes objects down the pipeline. It isn’t until the end of the pipeline—when there’s nowhere else to pass the objects—that the shell generates a text representation of the objects using their built-in formatting rules. For example, consider this:
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
This set of three cmdlets retrieves all the services from my local computer, filters out all of them that don’t use the LocalSystem account to log on, and then passes the remainder on to the Select-Object cmdlet, which outputs only the two properties—Name and StartMode—that I’ve asked it to select. The result is a simple report of services that are logging on as LocalSystem (perhaps for security auditing purposes).
Since all of the cmdlets share a common data format—objects—they’re able to share data with one another without any complicated string parsing. And since Windows PowerShell has a native ability to create a text representation of an object, the end of this pipe is sure to be text output that I, a person, can read. Figure 1 shows an example of the output produced.
Figure 1 Text output produced by a series of piped cmdlets that pass along objects
Figure 1 Text output produced by a series of piped cmdlets that pass along objects

The Excitement of Pipes
The reason piping in Windows PowerShell is so amazing is that everything in Windows PowerShell is an object, complete with properties and methods that you can use. Even a text file is technically a collection of string objects, with each line in the file acting as a unique and independent string object. For example, create a text file (using Notepad) named C:\Computers.txt. Fill the file with text and then run the following in Windows PowerShell:
Get-Content C:\Computers.txt | Select-Object Length | Format-List
Or, again, if you prefer less typing, you can use aliases:
gc C:\Computers.txt | select Length | fl
This code provides a list that indicates how long each line of your text file is, in characters. Get-Content retrieves the string objects from the file, Select-Object grabs the Length property of each, and then Format-List creates the nice, readable text output for you. While this might not be a practical administrative tool to utilize, it illustrates that even something as simple as a line of text is an object in Windows PowerShell.
Being able to pipe objects from cmdlet to cmdlet—or even from cmdlet to script—enables the creation of incredibly powerful "one liners." These are simple strings of cmdlets attached in a long pipeline that further refine a set of objects to give you exactly what you want. With practically no scripting or programming of any kind, Windows PowerShell cmdlets—strung together in an appropriate pipeline—can achieve remarkable results.

Supporting Future Generations
The fact that future Microsoft server products are also being built on Windows PowerShell extends this functionality. When implementing a new Exchange Server 2007 machine, for example, you can use Windows PowerShell to retrieve all mailboxes, filter out all those not in the office where the new mail server will be located, and then move those mailboxes to the new server—all in a single line of text with no scripting. The Exchange Server 2007 team has published a lengthy list of powerful one-liners. These really demonstrate the power of the pipeline and the administrative tasks it is able to accomplish.
The trick with Windows PowerShell is to understand that, while it’s built on long-established principles and philosophies from the UNIX world, this new tool is uniquely suited for Windows administration. Don’t let any commonality of terminology fool you into thinking that Windows PowerShell is just a UNIX shell knockoff for Windows. Windows PowerShell contains brand new concepts that take advantage of the Windows platform, and it is tightly coupled to the Windows way of doing things.

Don Jones is a Windows PowerShell MVP and author of Windows PowerShell 101 (ScriptingTraining.com). You can contact Don at www.ScriptingAnswers.com.


 Hey, Scripting Guy!: In Scripts, as in Life, Looks Are Important
Hey, Scripting Guy!
In Scripts, as in Life, Looks Are Important
The Microsoft Scripting Guys

For hundreds, even thousands, of years, philosophers and sages have been telling us that we should look beyond physical appearance when judging someone or something. (Not that we should be judging people, mind you; after all, beauty is in the eye of the beholder.) You know what they say: True beauty comes from within, not from without, and who you are is far more important than what you look like.
To that, the Scripting Guys can only add one thing: hogwash.
That’s right, hogwash. The Scripting Guys are the first to admit that in a perfect world physical appearance would make no difference. However, we don’t live in a perfect world. If we did, then french fries and hot fudge sundaes would make up two of the major food groups. Like it or not, appearance is important. And that’s as true for your scripts as it is anything else.
The Scripting Guys are aware that few people are moved to tears by the sheer beauty of a VBScript script running in a command window. (Maybe Scripting Guy Dean Tsaltas is, but he’s the only one we can think of.)
On the other hand, it’s also true that in this high-tech world of ours, scripters are no longer limited to writing scripts that run in a command window. Thanks to HTML Applications (HTAs), scripters can call upon the power of DHTML to create GUIs for their scripts. These same HTML skills can be used to create Windows Vista™ gadgets, a new venue that has the potential to revolutionize system administration scripting as we know it. But guess what? As soon as you start talking about GUIs, any tired old notions about beauty being only skin deep immediately go out the door. For scripts running in a graphical environment, looks are every bit as important as function and performance.
And that’s a problem. After all, we’re scripters; what do we know about creating graphical user interfaces? Looks like we’re out of luck, aren’t we?
Maybe. But then again, maybe not. Did we just hear someone say, "Thank goodness for the Scripting Guys?"
No, really. Didn’t we just hear someone say that? Maybe they kind of mumbled it a little or something...
Well, it doesn’t matter. Someone should have said it because the Scripting Guys are here to help (whether you want our help our not).
To get you started in the wonderful world of GUIs, let’s take a look at the beginnings of a simple little HTA. (If you’d like more information on creating HTAs, see the HTA Developers Center.)
What we’ve got in Figure 1 is the first part of a fancy desktop information system. As you can see, we’ve started off by putting a nice little graphic in the upper right-hand corner of the HTA window. The idea is that when the HTA first loads up, it will retrieve the name of the logged-on user and then display his or her name and the computer name on top of this image. Later on we’ll add all sorts of other cool things to the HTA but, as they say, first things first.
Figure 1 The start of our really quite pretty HTA graphical interface
Figure 1 The start of our really quite pretty HTA graphical interface
No, we aren’t really sure who "they" is. Probably another one of those philosophers. Probably Voltaire. That sounds like the sort of thing Voltaire would say.
Granted, this is a pretty simple little application, and its...beauty...might not even move Scripting Guy Dean to tears. But it does serve as a useful demonstration tool, with a basic concept applicable to many different situations. After all, many of those high-falutin’ Windows Vista gadgets operate on a similar principle; they simply display a fancy graphic (say, a gauge or a dial) and then write some text over the top of that graphic. That makes it look as though you have a cool little gauge that displays available disk space when, as it turns out, all you really have is a generic graphic overlaid with some dynamic text.
OK, to tell you the truth that doesn’t make a lot of sense to us, either. But things should clear up a bit the further we get into this column.
There’s just one problem with the notion that we can display a graphic and then write text on top of that graphic: it doesn’t work. Instead, with basic HTML tagging we get something that looks like Figure 2. Not exactly what we had in mind. Maybe Nietzsche, who said that "human beings can never hope to place text over the top of a graphic, at least not in an HTA," was right.
Figure 2 A first attempt at overlaying text
Figure 2 A first attempt at overlaying text
Or maybe Nietzsche was wrong: did we just hear someone say—well, never mind. As it turns out, we can’t do what we want to using plain vanilla HTML; it just doesn’t work that way. Sure, in theory we could make our graphic a background graphic and then use tables and non-breaking spaces and all sorts of other little tricks to try to get the text to overlay the picture. But we say "in theory" for good reason; except for the simplest of cases, that strategy never works.
As it turns out, there’s a much better way to create fancy layouts in an HTA or Windows Vista gadget: Cascading Style Sheets, better known as CSS.
CSS is used to define the fonts, the margins and alignments, the colors, and other presentation aspects of a document. (This applies in particular to Web pages. However, because HTAs and gadgets are, at heart, nothing but Web pages, CSS applies equally well to them.) We can’t even begin to discuss all the possible things you can do with CSS, so for more information you might want to see the handy and thorough CSS reference documentation on MSDN®. For now, suffice it to say that we can use CSS to minutely control the layout of the HTA, including the ability to overlay one item (our text) onto another (our graphic).
We’ll explain how we do all of that. But before we launch into that explanation, let’s take a look at the code for a very simple HTA in Figure 3.
Figure 3 Finally, we get to the script... (Close Figure 3)
<SCRIPT LANGUAGE=”VBScript”>

Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub

</SCRIPT>

<img src=“test2.jpg“ align=“right“>
<span id=UserData style=“position:absolute;left:770px;top:150px“></span>
As you can see, there’s really not much to this. We have a Window_OnLoad subroutine that (based on the name) runs automatically each time our HTA is started or refreshed. We’ll talk about this subroutine in a minute. In addition, we have two HTML elements: our graphic and a span. As you doubtless know, we use this bit of tagging to insert the graphic, using the align attribute to make sure that the picture appears on the right-hand side of the window:
<img src=”test2.jpg” align=”right”>
That brings us to the HTML tagging for the span:
<span id=UserData style=”position:absolute;
left:770px;top:150px”></span>
OK, so we’ve used a span tag here. What the heck is a span tag? Well, for all intents and purposes a span is simply a named area of your HTA; it’s a "marked off" section of the HTA window that we can identify programmatically (mainly because we gave the span the ID UserData). Once we’ve set up a span, we can write a subroutine that assigns text or HTML coding to it. In fact, not only can we do that, in our HTA we did do that.
But, like we said, we’ll talk about that later. Before we do that we need to look at the style parameter added to the span tag:
style=”position:absolute;left:770px;top:150px”
This parameter, as you might suspect, is the key to successfully positioning our dynamic text on top of the graphic. We’re actually specifying three separate style attributes here.
Position We’ve told our HTA that we want the position of our span to be, well, absolute. That essentially means that we always want the span to be in the same place, even if that means—as it does in this case—that the text gets written over the top of another item (such as, say, a graphic).
Left This simply specifies the position of the span relative to the leftmost edge of the HTA window. In this case we want the span to begin 770 pixels (770px) in from the left.
Top This setting is quite similar to the Left attribute, except this time we’re specifying the position of the span relative to the top edge of the HTA window. In this case we want to start at the top of the window and count down 150 pixels (150px) before beginning the span.
How did we know that we wanted to set the left side of our span to 770 pixels and the top side to 150 pixels? Well, to tell you the truth, we didn’t. Instead, we guessed; we put the graphic on the page and assigned values to the span’s Left and Top attributes. We then opened the HTA and looked at the results. As you might expect, we were off a bit, so we adjusted the values, refreshed the HTA, and looked again. We did this a few times until, like Goldilocks, we found something that was just right.
Note: you know Goldilocks and the three bears, their beds and chairs, the porridge that was too hot or too cold, and so on. And no, we’re not sure whether Goldilocks could be considered a great philosopher or not. But you could argue that, seeing as how she had no problem breaking into someone’s house, eating their porridge, sitting in their chairs, and sleeping in their beds, she definitely had a unique philosophy all her own.
At any rate, Figure 4 shows what our HTA looks like now. Granted, it might not be a work of art, but then again, we’d like to see Picasso programmatically print information on top of a graphic.
Figure 4 Behold the power of style
Figure 4 Behold the power of style
Speaking of which, how did we programmatically print information on top of a graphic? Well, we have good news for you: at long last it’s time to talk about our Window_OnLoad subroutine, shown in Figure 5.
Figure 5 Window_OnLoad subroutine (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” & _
  strUser & “<br>” & strComputer & “</font></p>”
End Sub
You know, now that we look at this subroutine a little more closely, we see that there really isn’t that much to talk about, is there? As you can see, we start off by creating an instance of the Wscript.Network object. We then use these lines of code to retrieve the user name and domain and the computer name:
strUser = objNetwork.UserDomain & “\” & _
  objNetwork.UserName
strComputer= objNetwork.ComputerName
That, of course, just happens to be the information we want written to our HTA window. All we need to do is combine the variables strUser and strComputer with a little HTML tagging, then assign the resulting string to the InnerHTML property of our span:
UserData.InnerHTML = _
  “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” _
  & strUser & “<br>” & strComputer & _
  “</font></p>”
Yes, we know that it’s a complicated-looking bit of code. But it’s really not all that bad. It looks complicated simply because we’re combining several items into a single string. We start with an opening paragraph tag, which specifies that we want to center the text in the paragraph.
“<p align = ‘center’> “
Next up is an opening font tag, which specifies that we should use 18-point white text:
“<font style=’font-size:18pt;color:white’>”
strUser is the variable holding our user name, in the format Domain\UserName. "<br>" inserts a line break. We insert this so that the user name appears on one line and the computer name appears on a second line. strComputer is the variable holding the name of our computer. Finally, we add the closing font and paragraph tags:
“</font></p>”
When you look at the pieces individually you can see that the code is nowhere near as complicated as you might have guessed.
Incidentally, you can position pretty much any HTML element you feel like positioning. For example, suppose you’d like a button centered beneath the graphic. To do that, simply add this to your HTA code:
<input type=”button” value=”Test Button” style=”position:absolute;left:820px;top:300px”>
That should give you an HTA that looks like Figure 6.
Figure 6 Such a lovely button
Figure 6 Such a lovely button
Again, you’ll have to play around with this a little to get the button positioned just right, but that shouldn’t take too long. In fact, if you’re willing to do the math you can probably determine the correct positioning ahead of time. All you need to know are the width and height of each object—something you can specify using the style parameter—and the width and height of the HTA window. By default, at least on the Scripting Guys’ test computer, HTAs are approximately 1020 pixels wide by 685 pixels high (of course, results may vary). If nothing else, you can start with those figures and then adjust them to suit your requirements.
That’s obviously an all-too-brief introduction to CSS, but it should get you started along the path to making your scripts beautiful. Philosophers may pooh-pooh those efforts and tell you that the true beauty of a script comes from within, not from without. But look at it this way. Who are the greatest philosophers of all time? That’s right: Plato, Socrates, Aristotle, those guys. With that in mind we’d like to pose a question: have you ever seen a photograph of any of those philosophers? Don’t you find it interesting that no photographs exist of the people who say that beauty doesn’t matter? Does that seem odd to you? Something to think about.

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


 Exchange Queue &amp; A: Edge and Hub Transport Roles, Virtual Machines, and More
Exchange Queue & A
Edge and Hub Transport Roles, Virtual Machines, and More
KC Lemson and Nino Bilic

In the May 2007 installment of Exchange Queue & A, we talked about the problems with storing .pst files on network shares. The Windows Server performance team recently started a blog and they discussed
this topic in all its gory, gooey technical detail, so we wanted to pass along the link. Now let’s get to the questions.

Q Am I required to deploy the Edge server role if I want to deploy Microsoft Exchange Server 2007?

A No, you are not required to deploy Edge in order to deploy Exchange Server 2007. You can have a single machine running the core server roles (such as mailbox, client access, and hub transport) accepting Internet e-mail for your domain and running anti-spam and anti-virus programs.

Q What are the differences between the Edge and Hub Transport server roles? What do I miss out on if I don’t deploy Edge?

A The primary purpose of the Hub role is to route mail within the organization and to apply business policies to those messages. With the Hub role, transport rules are based on Active Directory® objects—users, distribution lists, and so forth. The Hub role also lets you add disclaimers to messages or to journal messages sent to groups of users because you’ll probably want to base those rules on Active Directory membership. For example, you might want to journal all messages sent to DLOfUsersOnLitigationHold or add disclaimers to outbound mail sent by DLOfMembersOfLegalTeam. Although it is possible to run anti-spam agents on the hub server, they are not enabled by default so you’ll need to install them manually by running the install-antispamagents script available in the \scripts directory on the server.
The primary purpose of the Edge role is to route mail into and out of the organization as well as perform message hygiene (anti-spam, anti-virus, content or attachment filtering, and so on) on those messages. The anti-spam functionality is enabled out of the box when you install an Edge server. One of the unique features of the Edge role is that there is no requirement for it to be joined to a Windows® domain—it can be run on a standalone Windows Server® installation that is not part of a Windows domain, but Edge can still be managed as part of the Exchange 2007 organization in your corporate forest.
This is particularly advantageous in a perimeter network where you may want the server to be in a workgroup, or you may have a separate forest explicitly for machines in the perimeter network. Conveniently, Edge servers deployed in this situation can perform all message hygiene and routing for mail between the corporate network and the Internet, while still being managed in a manner that is consistent with the rest of Exchange 2007 systems administration.
On an Edge server, transport rules are based on SMTP addresses, not Active Directory objects—but of course you can use the SMTP addresses of DLs or users in your Active Directory. For the most part, the Edge transport rules are a subset of the Hub transport rules, the exception being the quarantine action, which is only available on Edge servers.
Edge servers also have some functionality exposed through agents that are not available on the Hub transport server: attachment stripping and address rewrite. Attachment stripping is the ability to selectively remove potentially dangerous attachments with extensions such as .exe and .com. The address rewrite agent allows you to rewrite the headers of e-mail so that although your domain and default SMTP proxy addresses on user accounts might be @contoso.com, for example, messages outbound to the Internet will appear to come from @northwindtraders.com. Also, Edge servers only perform routing based on domain or address space, so if you share the same SMTP address space between Exchange and another e-mail system, you’ll need to either perform that routing on the Hub server or do it in concert with the address rewrite agent on the Edge server.
Another important consideration is whether or not an Exchange 2007 server is directly Internet facing (whether that be the Hub or Edge server role). In other words, are connections to port 25 on your domain’s MX record connected to Exchange 2007 in some fashion? You may already have an SMTP gateway, virus wall or other solution in place on the Internet that is accepting mail for your domain and then passing it along to Exchange inside the corporate network. If you deploy Edge or Hub servers to be Internet-facing, then you can take advantage of one of the niftiest features of Exchange 2007: safelist aggregation. With safelist aggregation, users who add senders to their safe list in Microsoft Outlook® (which they typically do for Internet newsletters or e-mail from retailers) will get those lists securely propagated to the Edge or Hub roles so that messages from those senders will bypass the content filtering. Of course, one user’s spam is another user’s valued newsletter, so the safelist aggregation happens on a per-user basis. You can read more about how this works in the Exchange 2007 documentation.
If you do end up with a deployment in which a server running with the Hub role is accepting Internet e-mail for your domain, there are a few things to keep in mind. Of course, first make sure that you have a good firewall or port filtering solution in place so that your server is only receiving connections on the necessary ports, such as port 25. Also remember that you’ll need to install the anti-spam agents because they are not installed or enabled by default. Because the Hub server’s most common deployment scenario is within the corporate network, it does not allow anonymous connections out of the box—you’ll need to check the AnonymousUsers permission group on the port 25 receive connector. You’ll also want to ensure that you enable safelist aggregation and schedule it to run periodically so that as users update the safelists on their mailboxes, mail to those users from their safe senders lists bypasses content filtering. More details are available on our blog.
The following code shows an AT command that updates all mailboxes daily at 11:00 P.M. on all the servers by using a batch file that is named SafeList.bat:
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
This code shows the contents of the SafeList.bat file:
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
If you need to verify that your settings are working properly, more information can be found in the Exchange 2007 documentation.

Q After I boot my Virtual PC image with Exchange on it, I keep having problems related to contacting the directory or LDAP server. Telnetting to 389 works and all services are running. Why is this?

A I had this problem myself last year at Tech•Ed. I had a copy of a Virtual PC on my laptop that I’d copied from a machine at work, and I was planning on using it to do demonstrations for members of the press who were publishing articles coinciding with the launch of Exchange 2007 Beta 2 the following month.
I’d done a million demos of the product and knew the build was solid, so I didn’t prepare extensively. You can imagine the sweat on my forehead when I booted up my Virtual PC on Monday morning, just hours before the first meeting, and every part of my build insisted it couldn’t contact a domain controller. Thanks to the high concentration of super-smart folks in the cabana, we were able to figure it out quickly.
The problem I had in the Tech•Ed debacle was the result of running Virtual PC on my super-slow laptop. At the root of the problem was a race condition with DNS and Active Directory. The DNS server on the image was configured to be integrated with Active Directory, but due to the sequence in which the services on the image were loaded (and the, shall we say, lack of zippiness of my laptop), the necessary directory services hadn’t started up by the time the DNS server tried to contact Active Directory.
This situation can happen on any server that has DC and Exchange on the same machine (it does not have to be a virtualized image), but it’s far more likely to occur in a virtualized environment where there’s an extra slowdown—particularly with a not-too-beefy laptop like mine.
I have also seen a similar problem happen with Virtual PC images that are copied between two machines, especially when one of those machines is on a different network. If this has happened to you, check the IP address of the OS in the image; it may have a stale IP address from the old network. Refresh it to get an IP from the new network and see if that helps.
To avoid these kinds of problems in the future, one alternative is to make the DNS server on the guest not be Active Directory-integrated as well as install DNS on both the host and the guest. Have the guest forward to the host for unknown records and have the host forward to its appropriate DNS server for unknown records as well. When your image boots and tries to update the DNS records, it will be less prone to failure.

Q It seems like Exchange 2007 setup is quite different than setup in earlier versions of Exchange. How does this thing work?

A Yes, indeed, there are several stages of Exchange 2007 setup. Here is a general overview of how the whole process works.

When you first run setup.exe, a process launches that gives you the links for most of the prerequisites that you need to install before you begin installation of actual server roles. Once you have installed all of those prerequisites, the Install Microsoft Exchange link becomes available for you to click on (see Figure 1).
Figure 1 Installation link available after general prerequisites are met
Figure 1 Installation link available after general prerequisites are met
If you ran setup.exe from the network and you clicked on the Install link, core setup files will be copied into the %TEMP%\ExchangeServerSetup\ folder on the local machine. The setup wizard then launches.
Setup wizard will walk you through the various choices such as license agreement, error reporting, and installation type (where you get to pick server roles you want to install). Wizard pages will vary based on the presence and state of the current Exchange organization (if any).
After that is complete, setup will run a readiness check—really a tweaked version of the Microsoft Exchange Server Best Practices Analyzer (BPA), which, by default, will connect to the Internet to download the latest prerequisite XML file. That presents an opportunity to update the prerequisites periodically or address any issues that the Exchange team has learned about since the product shipped. When the prerequisite check is complete, you will have a chance to review the results and continue; otherwise you will see any issues that you might need to address before continuing with setup. If your server fails a prerequisite check, the wizard will let you retry the check in most cases.
Once the prerequisite check has passed, you will actually get the Install button that will let you start the installation of any roles that you have chosen previously. Only the files for roles that you selected will be copied and installed.
At the very end of setup, you will get a chance to launch the Exchange Management Console as well as apply any Exchange 2007 updates that might be available.

KC Lemson is the User Experience Manager for Exchange Server. Her online banking account has been temporarily suspended.
Nino Bilic is a Supportability Program Manager for Exchange Server. He recently added a secondary e-mail address to his credit card.


 Security Watch: Tools for Managing ACLs
New information has been added to this article since publication.
Refer to the Editor's Update below.

Security Watch
Tools for Managing ACLs
Jesper M. Johansson

In Windows, access control lists (ACLs) give you extremely fine control over the ability of users and processes to use resources such as files and folders. Managing ACLs can be one of the more complicated tasks related to protecting the security of your users’ systems. Fortunately, there are a number of useful utilities
that help automate and simplify tasks surrounding permissions and ACLs.
Most readers are familiar with the venerable cacls.exe tool that has been in every version of Windows NT® since it first came out. If you run cacls.exe in Windows Vista™, you are greeted with this message:
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
In addition to updates to ACLs in Windows Vista (which I covered in the June 2007 issue of TechNet Magazine; see technetmagazine.com/issues/ 2007/06), Microsoft has also updated some of the tools that you use to manage ACLs. Interestingly, the most significant of these updates are command-line tools.
Icacls.exe is new in Windows Vista (and also down-level in Windows Server® 2003 Service Pack 2). It will eventually replace cacls.exe, which, as you may be aware, was never completely updated to support the more granular permissions introduced with Windows® 2000, making this an update that is about seven years overdue.
Surprisingly, in spite of being deprecated, cacls.exe does actually include some new features. First, it is aware of both junction points and symbolic links, and knows to traverse those. Second, it can both print and set an ACL using a Security Description Definition Language (SDDL) string.
However, in spite of the updates to cacls.exe, you really want the functionality available in icacls.exe.

Saving and Restoring ACLs
A constant wish— at least of mine—for the past 10 years has been the ability to save an ACL so that you can restore it at a later date. This turns out to be one of the most complicated operations you can perform on ACLs. Except in certain special cases, it is unlikely to get back to exactly where you would have been had you not ruined the ACLs in the first place. Nevertheless, this functionality can be quite useful.
Before I go into how to save or restore ACLs, let me first explore why it is so difficult. Let’s say you have a hierarchy containing user data for students at a local college. You save the ACL on February 1. On April 17 you discover that somehow the ACL has been corrupted and you go to restore it from the saved copy. What complications could there be with this operation?
First, the new quarter started on April 2. About 15 percent of your students graduated; consequently, their directories no longer exist. Thus, you have ACLs in the backup file that are invalid. You also have a batch of new students, another 15 percent, that started with the new quarter. They have home directories now, but no ACLs in the backup file. What should their ACLs be? Then of course you have the 70 percent that are still there, but they have created new files and folders and deleted others. You can ignore the deleted ones, but how do you configure the new folders they created? What if a student decided to share a folder with his friends on March 4? Will you break that when you restore the ACL?
Saving and restoring ACLs is not nearly as simple an operation as many people would have you believe. You need to tread extremely lightly when doing so. It is very possible, even likely, that you will have some undefined behavior as a result. Restoring ACLs is definitely a last resort; the longer it has been since you backed it up, the more likely it is that something will break when you restore it.
If you nevertheless wish to try this functionality, run icacls.exe with the /save switch:
icacls <target> /save acls.bin /t
This would save the ACLs to a file called acls.bin. The file will contain one line for each object with an ACL followed by one line specifying the ACL in SDDL. Using the /t switch the command will operate on the object you specified and all objects and containers underneath it.
The save functionality is a welcome addition to the toolkit, but it has a few flaws. For example, it only saves the discretionary access control list (DACL), not the system access control list (SACL). In fact, if there is a SACL, it saves a dummy value that indicates this, but it does not actually save any part of the SACL.
In addition, the way the ACL is saved creates an interesting problem. Before you open the saved ACL in your favorite text editor, remember:
Do Not Edit Your Saved ACL!
If you were to open the file containing your saved ACL in a text editor, you would find that it appears to be a Unicode (UTF-16) formatted text file. In fact, that is almost exactly what it is. This might lead you to think you could edit it and save it from a text editor. Don’t do it!
If you open the file that contains the saved ACLs in a text editor and then save it, you will not be able to restore the ACLs from that file. It turns out that it is not actually a Unicode text file after all. Such a file must begin with the 2 bytes 0xfffe. If you save the file with a text editor, such as Notepad, it will in fact put that flag into the file in the first 2 bytes. The icacls.exe tool, however, expects the ACL data to start at byte 0 in the file. Consequently, the tool will be unable to parse the ACLs in the file as it expects the first two bytes to be part of the string specifying the object to operate on. Your backup file will be unusable.
Microsoft is aware of this problem, but as it was only reported very late in the beta cycle for Windows Vista, this flaw was not fixed prior to release. At this point in time, we do not know when, or even whether, it will be fixed. So for now, the best advice is to not edit your saved ACLs. If you need to do so, save the file as a .bin file and use a hex editor, such as your favorite development environment.
Once you have saved an ACL using the /save switch, you can restore it using icacls.exe with the /restore switch. The restore command in its simplest form uses this syntax:
icacls <directory> /restore acls.bin
The restore procedure does not operate on files. To see this, look at the sequence of commands shown in Figure 1. Here I create a save file by pointing icacls.exe at a file. I then try to restore it by simply substituting /restore for /save. This fails because the restore command only operates on directories. The files it is supposed to modify are specified in the acls.bin file already. To restore the ACL, I point it at the directory instead of the file. This is what I do in the last command where I specify "." as the object to operate on.
Figure 1 Saving and restoring ACLs (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Note also that the restore command must run elevated! You can run the save command from a command prompt running as a low admin or even a standard user, so long as you have the right to read the ACL. However, to restore the ACL you need have a complete, unadulterated administrative token.

Substituting SIDs
Another feature that’s very useful in icacls.exe is the ability to replace the permissions for one user with permissions for a different user. This is done during restore using the /substitute switch. The documentation for the substitute switch says it needs an SID, but later it explains that this can actually also be a regular user name. Thus, the sequence shown in Figure 2 works.
Figure 2 Substituting SIDs during restore (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
As you can see, I end up with the same ACL I had before, but the ACE that used to specify permissions for foo now specifies them for bar instead.

Change Owner
The chown tool has been a staple on UNIX systems for years. Windows originally had no built-in way to change the owner of an object. Then came the setowner tool in the Resource Kit. Then we got the takeown.exe tool in Windows NT 4.0, but this utility only allowed you to take ownership, not grant it to others unless you had their password. Now icacls.exe gives you the built-in ability to set the owner of objects which you have permission to set the owner on:
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Unfortunately, icacls.exe can’t show you the owner of an object. There are, of course, other tools that can do that, including DIR /Q, subinacl, and fileacl, but it would have been logical for icacls to include the ability to show who the owner of an object is. Furthermore, if you save the ACL for an object, it does not save the owner of the object.
[ Editor's Update - 7/3/2007: This paragraph originally and inadvertently implied that there was no possible way to determine the owner of an object from the command line. Rather, there is simply no way to do so using icacls.exe.]
There is also a bug in icacls.exe in that it does not invoke SeTakeOwnershipPrivilege to change the owner. If you have the right to change the owner of an object based on the ACL, then icacls.exe works as it should. However, if you are an administrator, but you do not have permission to change the owner based on the object’s ACL, you cannot use icacls.exe to do so because of that bug. In that case, you need to use the takeown.exe tool, which does invoke the SeTakeOwnershipPrivilege, but can only change the owner to your account or the Administrators group, not to an arbitrary account:
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Of course, it should be noted that the subinacl tool, which is downloadable from the Microsoft Download center, also has a setowner switch. Subinacl actually works more intuitively than icacls in many cases, but it is also far more complicated to use.

Find Files for a Particular User
Icacls has another useful function: it can find files that have permissions for particular users. For example:
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
This could be helpful if you are trying to find out what a particular user might have access to.

Resetting and Changing ACLs
If an ACL has become corrupted or destroyed, icacls.exe has a way to reset it to inherit from its parent. This is something that would have been extremely useful during a zero-day security issue that hit in the fall of 2006. One method used to mitigate the issue in a Windows component was to deny Everyone access to the object. That part was easy, but removing that Access Control Entry (ACE) was nearly impossible using built-in tools in Windows XP and Windows Server 2003. However, in Windows Vista, you would simply run this command:
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
Icacls.exe, of course, has all the standard grant/deny/remove operations. The only really new item in that list is remove. Using this switch, you can remove all allow ACEs, all deny ACEs, or both for a given user from a specific object or hierarchy. Figure 3 shows examples of some different grant, remove, and deny operations.
Figure 3 Grant, deny, and remove operations (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
The ability to remove only the deny ACEs can be useful if you want to open access to an object up to a particular group or user.

Setting Integrity Levels
Icacls.exe also has the ability to display and set integrity levels. Windows Vista supports putting integrity labels on objects. Icacls.exe is the command line tool to use to do so:
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
Note that icacls.exe only displays an integrity label if an object has one explicitly set. Most files do not, so it is rare that you see one.
Finally, icacls.exe can verify that an object has a canonical ACL. As mentioned earlier, third-party tools have been known to put ACEs in the wrong order in ACLs. Icacls.exe can verify, and fix, those types of problems, as shown here:
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

ACL UI
ACL UI, or the ACL User Interface, has been modified slightly from the one in Windows XP. Figures 4 and 5 show the ACL UI dialog from Windows XP and Windows Vista, respectively.
Figure 4 ACL UI dialog in Windows XP
Figure 4 ACL UI dialog in Windows XP
Figure 5 ACL UI dialog in Windows Vista
Figure 5 ACL UI dialog in Windows Vista
As you can see, there are a few changes here. First, the dialog finally shows the object you are operating on very clearly, which can be useful if you are working on several objects at a time. Second, there is a hyperlink to some help at the bottom. However, the most notable change is in the removal of the Add and Remove buttons, replacing them with an Edit button that is largely present in support of the User Access Control (UAC) in Windows Vista. As you can see by the shield on the button, the user that launched this dialog does not have permission to edit the ACL, and therefore will require elevation before she can edit the permissions. Note that this would not be the default if you create a folder in the root of the C: drive and immediately check properties on it. As the owner of the folder you would have implicit permissions to edit the ACL and the shield would be missing. The shield signifies a COM Moniker, which is a mechanism used to launch an elevation prompt for a portion of a running process. If you click the Edit button, you get the familiar elevation dialog, and if you click Continue in the elevation dialog, you get a dialog that is almost identical to the one you get in Windows XP by clicking the Add button. The ACL UI follows this dual-dialog concept in several places; you get one dialog until you elevate, and once you do, you get the familiar old dialog from earlier versions of Windows.
If you click the Advanced button and then the Auditing tab, you will always get an elevation button, as shown in Figure 6. You cannot modify auditing without elevating, even if you have full control over the object and you are the owner. That’s because the ability to modify an object SACL is governed by the SE_SECURITY_NAME privilege, known as "Manage auditing and security log" in the GUI tools. Only administrators have that right by default. However, the privilege is removed from an administrator in admin approval mode (when UAC is enabled), necessitating the elevation even if you are an administrator.
Figure 6 Modifying the audit settings in Windows Vista always requires elevation
Figure 6 Modifying the audit settings in Windows Vista always requires elevation
One final note on elevation needs when you modify ACLs: all these statements are contingent on your not disabling UAC. If you disable UAC, all behavior reverts to what you had in Windows XP, with the exception of dialogs that look different. However, no elevation will be required, provided you log on as an administrator since your token will now have the Administrators SID in it all the time.

Other Tools
Icacls.exe is a very useful tool, and a grand improvement over cacls.exe, but it still suffers from some shortcomings. Perhaps the most notable is that it cannot manage access to any objects other than files and directories. Windows Vista makes sparse changes to the ACLs of other objects compared to Windows XP, but there are still occasions when you want to manage ACLs on a service, a registry key, or even an Active Directory® object.
If you are a command-line junkie, you need subinacl.exe to do this. Subinacl.exe is in the support tools, and is also available as a download.
I have to warn you though, subinacl.exe is not easy to use. In fact, it is downright obtuse at times. However, subinad.exe is an incredibly powerful tool for managing access control. Every power admin needs this tool.

Registry ACLs
The registry ACLs have undergone changes just like the file system ACLs. The changes are much smaller in scope than the changes to the file system, though. The most obvious difference from earlier versions of Windows is that, due to the deprecation of Power Users, almost all the Power User ACEs are gone. Power Users are not supposed to be any more powerful than any other users. It is a testament to just how complicated ACLs really are, though, that not all the ACEs for Power Users are actually gone. A few were, unfortunately, missed.
While you are looking at ACLs in the registry, in a few places you will see an ACE for a SID called RESTRICTED. This is not new to Windows Vista, but it is an interesting and not well understood SID. The RESTRICTED SID denotes any process that presents a restricted token. A restricted token is created by using a special feature of the CreateRestrictedToken API. Such a token has one or more restricting SIDs—SIDs that are used in a separate access check. Let’s say we have a process running with a restricted token. If that process attempts to access an object with an ACE for the RESTRICTED SID, Windows actually performs two access checks. The first is the normal access check. The second one works exactly like the first, but takes place only against the restricting SIDs in the token. Both access checks must pass.
Currently, there are several ACLs that use the RESTRICTED SID, particularly on the registry. A screen shot of such an ACL is shown in Figure 7.
Figure 7 The Registry ACLs include an ACE for RESTRICTED in several places
Figure 7 The Registry ACLs include an ACE for RESTRICTED in several places
At this time, few processes make use of the restricted token functionality, particularly with respect to restricting SIDs. One example of a process that does is the service process that hosts the Windows Firewall, the Base Filtering Engine, and the Diagnostic Policy Service. It also uses a write restricted token. Based on my findings, only nine services currently use RESTRICTED and write restricted tokens in Windows Vista.
As with recent previous versions of Windows, the best practice with respect to registry permissions is to tread very carefully. Except for in exceptional—and highly targeted—circumstances, do not modify permissions in the registry. Given the complicated inheritance model and the sensitive operations performed on the registry, you run an unacceptably high likelihood of fatal failure if you modify ACLs in the registry carelessly.

Summary
As with most versions of Windows, there are some subtle changes to access control in Windows Vista. However, unlike some of the other recent versions, there are actually a lot of minor changes that add up to a fairly significant change in behavior. UAC, in particular, required several changes, such as the integrity labels and modifications to the ACL UI. In addition, we have the first major clean-up of ACLs in recorded history.
In many ways, the default ACLs on Windows actually got simpler in Windows Vista, something that has never happened before. As with previous versions, however, you should really tread carefully around access control until you understand it thoroughly. This is especially true with new versions of the OS. Hopefully, using the tools outlined in this article, you will be able to make your exploration of ACLs far less painful.

Jesper M. Johansson is a Principal Security Engineer working on software security issues and is a contributing editor to TechNet Magazine. He holds a Ph.D in MIS and has over 20 years experience in computer security. This column is adapted from Roger Grimes and Jesper Johansson’s new book, Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley, 2007).


 The Desktop Files: The Microsoft Desktop Optimization Pack
The Desktop Files
The Microsoft Desktop Optimization Pack
Wes Miller
This column is based on prerelease elements of the Microsoft Desktop Optimization Pack. All information herein is subject to change.

Since the beginning of the Software Assurance (SA) licensing program several years ago, Microsoft has continuously sought to add features to SA so that customers would find increasing value over time. In addition to providing upgrades for Microsoft products included in the license, the company has sought to provide
products and technologies (Windows® PE was one of the first, for example) that can help an organization improve its experience with Windows, Office, and other Microsoft software.
The focus of many of these tools and programs has been for Microsoft to provide additional capabilities to reduce the overall cost of ownership of Windows, Office, and other Microsoft applications included in an organization’s SA coverage.
Microsoft acquired several companies in 2006 that all had similar agendas: to reduce the cost of ownership and complexity associated with managing and repairing Windows and Windows-based applications. Microsoft has combined a number of these newly acquired technologies into a new product offering, available as a value-add to customers who have SA. Technologies from Softricity, DesktopStandard, AssetMetrix, and Winternals Software will be available over the coming year as components of the Microsoft® Desktop Optimization Pack (MDOP). Additionally, MDOP will include a component that Microsoft built internally, called Microsoft System Center Desktop Error Monitoring.
As for savings, Microsoft estimates that MDOP can help save your organization anywhere from $100 to $500 per year per desktop, depending on the best practices you implement when using MDOP. More information about MDOP is available online at windowsvista.com/optimizeddesktop.

Goals of the Microsoft Desktop Optimization Pack
The main goal for MDOP is, in short, to allow Microsoft to provide new management technologies on a more agile schedule, rather than being tied to new operating system releases. Granted, Microsoft wants to ensure that the time gap that existed between Windows XP and Windows Vista™ doesn’t occur again. But by providing tools in a predictable timeframe between releases, MDOP will allow Microsoft to flexibly meet the needs of its users, and this will allow enterprise customers to maximize the value of their software investments.
To help enterprises become more agile, Microsoft has sought out a strategy that can help customers move to a more dynamic infrastructure—dynamic, that is, in the sense Microsoft defines with its Dynamic Systems Initiative (DSI). For more information on DSI, read the information available at microsoft.com/business/dsi.
But enough with the high-level strategy. Let’s take a look at each of the five technologies included in MDOP:
  • SoftGrid Application Virtualization
  • Asset Inventory Service
  • Diagnostics and Recovery Toolset
  • Advanced Group Policy Management
  • System Center Desktop Error Monitoring

SoftGrid Application Virtualization
SoftGrid Application Virtualization, which was acquired from Softricity, provides, as its name implies, application virtualization. When I first started digging into SoftGrid, I realized that it is what application publishing for Windows 2000 IntelliMirror® should have been. Why? Because applications aren’t published to clients, they are entirely virtualized. This allows applications to be easily made available on client (or Terminal Server) systems. Just as importantly, applications can be centrally managed and even recalled or updated as needed. Compared with the traditional model of MSIs and transforms, the SoftGrid model makes application deployment significantly less painful and less risky.
One way to think of SoftGrid is in the sense of a virtual image. You may be familiar with the concept of a disk image used to deploy Windows (and often applications within it) to systems. SoftGrid, in essence, takes the application and packages it into an application image, rather than an entire OS image.
SoftGrid Application Virtualization comprises three key components: application virtualization, application delivery, and central management console.
Application virtualization itself is composed of virtual representations of the Windows file system (including system files), the Windows registry, fonts, .ini files, COM/DCOM objects, services, kernel objects (semaphores, mutexes), named objects, and namespaces of all components.
It’s important that you don’t confuse SoftGrid virtualization with how Windows Vista UAC performs redirection. With UAC, when an application attempts to write to or modify protected areas of the registry or file system, it is redirected to a user-specific view of the registry and file system. SoftGrid, on the other hand, uses a concept of truly virtualizing the application to the operating system—including all registry and file system components that make it up. But the elegance of SoftGrid is that it isn’t a single blob that defines an application. Instead, it consists of:
  • An SFT file of up to 4GB. This contains one or more applications and all of their dependencies except Windows dependencies, which are expected to be on the destination systems.
  • An OSD file of approximately 2KB. This contains a definition of how the application can be requested and executed. You can think of the OSD file as an EXE.
  • An ICO file of about 24KB. This is effectively a shortcut to launch the application.
  • An SPRJ file of about 13KB. This is used by the sequencer (the core of SoftGrid) to publish, open, update, and repair existing packages.
A comprehensive diagram of how SoftGrid Application Virtualization works is available at the Web site softricity.com/ products/architecture.asp.
A huge advantage of the SoftGrid solution is that a central management console (see Figure 1) can be used to determine which applications are available for a given Active Directory® user or set of users. Those applications can then be quickly streamed to users on demand via an industry standard streaming protocol. Once installed, the applications behave as if they are locally installed, they honor user customizations (even via Roaming User Profiles), and they function even when clients are disconnected from the network. Administrators can even stop applications from being available—dynamically or automatically (after a set time, for example).
Figure 1 SoftGrid Management Console
Figure 1 SoftGrid Management Console
Most importantly, because of the way applications are deployed, an entire application does not need to be made available. Instead, only the pieces needed to run the application being used by the user are downloaded. Imagine a scenario where all of Microsoft Office is made available as a package. If a user only runs Word, only the necessary components to run it are downloaded—not the pieces needed to run Excel®, PowerPoint®, and so on. As soon as the user runs one of those applications—Excel, for example—its associated components are pulled down as needed.
What's in ERD?
  • Command prompt
  • Explorer
  • Search
  • Notepad
  • Solution Wizard
  • Administrative Tools: Autoruns, Disk Management, Event Viewer, Registry Editor, Services and Drivers, System Information
  • Networking Tools: File Sharing, Map Network Drive, TCP/IP Configuration
  • System Tools: Crash Analyzer, Disk Commander, DiskWipe, FileRestore, Hotfix Uninstall, Locksmith, System File Repair, System Restore

Another component of SoftGrid is its ability to do automatic metering and license checking. This helps you remain in compliance with your software licensing without needing additional software.
Almost any application can be virtualized. The key exceptions are Internet Explorer® and other Windows components (including hotfixes and service packs), antivirus software, and device drivers. If you are interested in digging deeper into how SoftGrid works and exploring what it can do, I recommend checking out the whitepaper available at Softricity.com.

Advanced Group Policy Management
DesktopStandard made a name for itself by developing tools that bridged some of the weak links in Group Policy. By offering the tool formerly known as GPOVault in MDOP—now known as Advanced Group Policy Management—Microsoft has provided customers with a great tool that can take GPO from powerful (and sometimes dangerous) to a much more refined and controlled process.
If you are familiar with the fundamentals of source control software, imagine Advanced Group Policy Management as source control for your Active Directory Group Policies. (See Figure 2 for a screenshot of the Advanced Group Policy Management console.) Administrators check out existing policy revisions, make changes, and check them back in, auditing the results using Group Policy Management Console-like reports. Once the administrator is satisfied that the desired policy state has been reached, he can commit the changes and make them live. Like good source control software, when something does go wrong, the changes can be quickly and safely rolled back to an earlier revision without any of the guesswork that would usually occur in such a process.
Figure 2 Advanced Group Policy Management console
Figure 2 Advanced Group Policy Management console
Another key aspect of this process is the ability to edit policies offline, rather than requiring changes to be made to all online, active systems. This allows for isolated testing of changes before changes are made across the domain or OU.
Finally, through a role-based model, Advanced Group Policy Management allows changes to be driven through a designed workflow process. By creating roles (such as editor, reviewer, and approver), an admin can ensure that a process is put in place that will allow changes to be made in a controlled manner. Thus, when the implementer believes that the change is ready to be committed, he can have a strong change-control mechanism to ensure that knee-jerk GPO changes do not occur without appropriate approval.

Asset Inventory Service
The Asset Inventory Service, composed of technology that Microsoft obtained through the acquisition of AssetMetrix, is a very powerful inventorying and asset management solution. Unlike the other components of MDOP, AIS employs a hosted Web model. AIS uses a very low-footprint, low-bandwidth agent, which can either run one time or at periodic intervals, allowing an administrator to look for applications by searching an incredibly extensive Microsoft-hosted database of over 400,000 applications to determine which are installed on client systems. AIS can then take this rolled-up data and reconcile it with your purchased licenses to ensure compliance and reduce waste due to license over-purchasing.
Some administrators may initially be hesitant to use AIS given that it is a hosted model outside of the firewall and it inventories internal systems for installed software. But it’s important to understand the extensive work that Microsoft has done to ensure organizational privacy, beginning with rewriting core components of the application that makes up AIS. There is no tying of individual computer data back to any organizational data. Microsoft will also be certifying the data transfer technology with a third party to ensure that customers are comfortable with the model being used by AIS.

Diagnostics and Recovery Toolset
As you may know (if you’ve ever read the bio on my columns over the past several months), I was a member of Winternals when it was acquired by Microsoft. I was the Product Manager over most of the Winternals products during my tenure there, including the Winternals Administrator’s Pak. This was the predecessor to the Microsoft Diagnostics and Recovery Toolset (DaRT). While some of the tools that previously existed in the Administrator’s Pak are not included in DaRT, the key components that comprised the ERD Commander product are still available.
The goal of DaRT is to provide a set of tools that can help you diagnose system problems—even if a system is not booting properly. And you can often repair those problems offline.
ERD Commander utilizes Windows PE to boot a system that is not booting or is not booting normally. Under a custom Windows Explorer-like user interface, a set of tools are available. Two of these tools, Crash Analyzer and FileRestore, are available for online use as well. However, these must be installed on every system that you wish to run them on if you are not using ERD Commander for offline diagnostics or recovery.
The DaRT version of ERD Commander is shown in Figure 3. A list of the tools included in the ERD Commander component can be found in the sidebar. With the exception of the Explorer tool, the first five tools listed are the same applications you would use on a normal Windows installation. Explorer is, as is the Start Menu application it is launched from, a specialized (smaller) version developed to be run under Windows PE.
Figure 3 ERD Commander
Figure 3 ERD Commander
Autoruns is a tool, derived from a Sysinternals tool of the same name, which lets you see all applications that are set to start when the system boots or a user logs on. Disk Management, Event Viewer, Services and Drivers, and System Information are tools that live within a common user interface and provide comparable experiences to similarly named tools under Windows. Services and Drivers is particularly useful in that it can help you get a system booting when the system is failing due to a device driver or service that is not working correctly. Finally, the Windows Registry Editor is included so that you can manipulate the registry of an offline system.
Networking is also available under ERD Commander. Though the system is automatically configured via DHCP, you can set a static IP address using the TCP/IP Configuration applet. Regardless of whether you use DHCP or static IP addressing, you can either map a network drive and copy files to or from the downed system or use File Sharing to turn the system into a file server so that you can then use a working system to copy files off of the failing system.
Finally, a collection of miscellaneous tools are also included. Crash Analyzer uses the Debugging Tools for Windows (which must be downloaded and installed separately—they are free, but are updated often) to diagnose the cause of a crash. You can either run it offline under ERD Commander if the system is not booting or copy a DMP file to a running system with DaRT installed and diagnose it there. Once pinned down, if the culprit is a new service or driver, you can use the Services and Drivers tool to disable it and see if the system returns to functioning normally.
Disk Commander can help you recover a partition that has been accidentally deleted or damaged as well as a group of files or a directory that has been deleted. On the opposite end of the spectrum, DiskWipe allows you to complete a DoD-compliant disk or volume erasure. FileRestore allows you to (either online or offline) recover a single file that may have been accidentally deleted. Bear in mind that the type of file and the time/disk activity since deletion will affect the recoverability, regardless of the tool you use.
In the event that a Windows hotfix or service pack prevents the system from booting normally, you can use Hotfix Uninstall to selectively uninstall one or more hotfixes or service packs. Rebooting is required to complete the process, as Windows doesn’t support the complete offline removal of applications. But it can often get you booting again.
Locksmith was one of the most popular tools included in the ERD Commander toolset at Winternals. It allows you to reset any local user’s password. It does not work on domain controllers and cannot reset any domain user’s password—it is generally used to reset the local administrator’s password when it has been forgotten or the user has left the organization. System File Repair will go through all protected system files and investigate them to see if any are corrupt and replace them as needed. System Restore, as the name implies, lets you roll back or forward to any Windows System Restore point on a Windows XP system. (Windows XP with pre-existing restore points is required to use this functionality.) I am among the many users who have been saved by this unique functionality.
The tools in ERD Commander and DaRT may seem somewhat random, but they are a powerful compilation of utilities that Winternals developed over time. I am sure you will see their value and find them useful in your recovery and troubleshooting tasks.

System Center Desktop Error Monitoring
System Center Desktop Error Monitoring (DEM) provides a fast and easy way for any organization to centralize and diagnose Windows crashes and application hangs. Instead of sending crash and hang reports to Microsoft, DEM uses Group Policy and the built-in Windows Error Reporting to send reports to a server you designate within your organization for diagnosis (and it doesn’t require an additional software agent). All DEM server data is stored in a SQL Server database, so you can easily query the collected data for your own internal applications and reporting. This allows you to diagnose problems within your organization proactively. Using this information, you can mandate reporting of such incidents, discover the most frequent causes of crashes and hangs, and ensure that Windows and application patches are prioritized to minimize or eliminate system downtime.
You can also configure your DEM server to upload the results to Microsoft, as well as to have DEM automatically download the latest troubleshooting data for Microsoft and third party applications. Additional data can be gathered from clients in the event of a crash or hang.

Licensing MDOP
The first requirement for a customer to license MDOP is an existing Microsoft SA agreement. Once in hand, the licensing costs begin at $7 to $10 per desktop. Volume discounts and educational pricing are available.
The MDOP is not available outside of the context of an SA agreement, with one exception: Customers who wish to use SoftGrid technologies with their Terminal Servers (see softricity.com/solutions/sbc.asp) or SMS (see softricity.com/products/softgrid-sms.asp) can do so, and AssetMetrix technologies will be made available in future SMS and System Center Configuration Manager releases.

Availability and Updates
The initial components of MDOP are available today. The components are shipping as follows:
  • SoftGrid has been available from Microsoft since early 2007.
  • The Microsoft DaRT has been available since May 2007.
  • The GPOVault technologies should be available in July 2007.
  • Desktop Error Monitoring should be available in MDOP in July 2007.
  • AssetMetrix technologies should be available in beta in July 2007 and will be available for release in August.
  • An update to the DaRT components is planned for late 2007, with the key enhancement being Windows Vista compatibility.
The plan for future releases of MDOP is to provide enhancements, upgrades, and new features twice yearly.

Direction for MDOP
As mentioned, key components of AssetMetrix technologies will be integrated into future versions of System Center Configuration Manager. In fact, you can expect that over time, as Microsoft evolves the MDOP functionality, some of it will trickle over into the baseline Microsoft deployment, management, and configuration technologies. New technologies (some created by Microsoft, some acquired from other companies), will then be made available in future versions of MDOP. In essence, MDOP will be an evolving package of cutting-edge management and configuration technologies.

Wes Miller is a Development Manager at Pluck in Austin, Texas. Previously, he worked at Winternals Software in Austin and at Microsoft as a Program Manager and Product Manager for Windows. Wes can be reached at technet@getwired.com.
I’d like to express my gratitude to Chad Jones and Gavriella Schuster, Product Managers for the Microsoft Desktop Optimization Pack, for assisting me with this column.


 Windows Confidential: The Healing Powers of Safe Mode
Windows Confidential
The Healing Powers of Safe Mode
Raymond Chen

When Windows safe mode (also known as the "oh no it’s all messed up please fix it" mode) was first developed for Windows® 95, it was intended to do more than just disable drivers. It was also meant to repair stuff that could be repaired automatically.
For example, when you start in safe mode, Windows Explorer checks the positions of all the icons on the desktop, making sure that they are all visible because it is possible to create a state where an icon is positioned off the screen.
If you want to see what I’m talking about, position two icons on the desktop, one at the left edge and one at the right edge. Use Ctrl+Click to select both of these icons, then grab the left one and drag it to the right-hand side of the screen. When you do this, the second icon will also move, keeping the same relative position to the icon you are dragging. And the second icon moves right off the screen.
Safe mode allows users to troubleshoot Windows
Safe mode allows users to troubleshoot Windows
If Windows Explorer didn’t repair icon positions in safe mode, troubleshooting instructions would be potentially more confusing than helpful:
  1. Start the computer in safe mode. (OK.)
  2. Double-click the My Computer icon. (Um, I don’t see a My Computer icon.)
  3. ...
Oops, the My Computer icon is offscreen or otherwise unavailable. You can’t even get past step two of the troubleshooter.
There have been complaints from some people saying "you shouldn’t have repaired the icons automatically. If a user calls tech support with the problem, the support engineer can simply tell the user to right-click on the desktop and select the option to Reset Icon Positions. Mission accomplished, and safe mode hasn’t messed with my icons."
First of all, you’ve already lost the game when you say "if a user calls tech support with the problem." If a user has to pick up the phone, you’ve failed.
Furthermore, this proposal misses the psychology of safe mode. Users boot into safe mode when things are not acting properly, although they don’t necessarily know what they’re going to do once they get there. What they are really doing is just seeing what will happen. "Something is wrong, let’s try safe mode." In Windows 95, we took advantage of this psychology by implementing various types of autorepair actions in safe mode. It worked quite well.
What’s more, if users call and you tell them, "boot into safe mode; that’ll fix it," they’ll say to themselves, "well, that was easy enough. I should have thought of that."
But if you give them a longer set of instructions, saying "boot into safe mode, right-click here, select this menu option, then click this box," the users will follow the instructions and the problem will be fixed, but this will have done nothing to make them feel more comfortable with computers. Instead, they will feel feeble and discouraged. Rather than being empowered, the users fall into a state of learned helplessness. "There’s no way I would have figured that out. Computers are so hard to use."

Raymond Chen’s Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. He prefers to run away before the fuse is lit.