main.html

Next Page
Windows Server 2008: The Definitive Guide
Windows Server 2008: The Definitive Guide
by Jonathan Hassell
Publisher: O'Reilly
Pub Date: March 15, 2008
Print ISBN-13: 978-0-59-651411-2
Pages: 492
Table of Contents
| Index
Overview

This practical guide has exactly what you need to work with Windows Server 2008. Inside, you'll find step-by-step procedures for using all of the major components, along with discussions on complex concepts such as Active Directory replication, DFS namespaces and replication, network access protection, the Server Core edition, Windows PowerShell, server clustering, and more. All of this with a more compact presentation and a tighter focus on tasks than you'll find in bulkier references. Windows Server 2008: The Definitive Guide takes a refreshing approach. You won't find the history of Windows NT, or discussions on the way things used to work. Instead, you get only the information you need to use this server. If you're a beginning or intermediate system administrator, you learn how the system works, and how to administer machines running it. The expert administrators among you discover new concepts and components outside of your realm of expertise. Simply put, this is the most thorough reference available for Windows Server 2008, with complete guides to:

  • Installing the server in a variety of different environments

  • File services and the Windows permission structure

  • How the domain name system (DNS) works

  • Active Directory, including its logical and physical structure, hierarchical components, scalability, and replication

  • Group Policy's structure and operation

  • Managing security policy with predefined templates and customized policy plans

  • Architectural improvements, new features, and daily administration of IIS 7

  • Terminal Services from both the administrator's user's point of view

  • Networking architecture including DNS, DHCP, VPN, RADIUS server, IAS, and IPSec

  • Windows clustering services --- applications, grouping machines, capacity and network planning, user account management

  • Windows PowerShell scripting and command-line technology

With Windows Server 2008: The Definitive Guide, you to come away with a firm understanding of what's happening under the hood, but without the sense that you're taking a graduate course in OS theory. If you intend to work with this server, this is the only book you need.

Next Page


toc.html

Windows Server 2008: The Definitive Guide
Windows Server 2008: The Definitive Guide
by Jonathan Hassell
Publisher: O'Reilly
Pub Date: March 15, 2008
Print ISBN-13: 978-0-59-651411-2
Pages: 492
Table of Contents
| Index
Preface
Chapter 1. Introducing Windows Server 2008
Section 1.1. The Biggest Changes
Section 1.2. Networking Improvements
Section 1.3. Security Improvements
Section 1.4. Manageability Improvements
Section 1.5. Performance and Reliability Upgrades
Section 1.6. Windows Server 2008 Editions
Section 1.7. Hardware Requirements
Section 1.8. The Last Word
Chapter 2. Installation and Deployment
Section 2.1. Installing Windows Server 2008
Section 2.2. Initial Configuration Tasks
Section 2.3. Deployment
Section 2.4. The Last Word
Chapter 3. File Services
Section 3.1. File and Print Server Features
Section 3.2. Setting Up File Sharing Services
Section 3.3. NTFS File and Folder Permissions
Section 3.4. The File Server Resource Manager
Section 3.5. Disk-Based Quotas
Section 3.6. Using Offline Files and Folders
Section 3.7. Using Previous Versions
Section 3.8. The Distributed File System
Section 3.9. Command-Line Utilities
Section 3.10. The Last Word
Chapter 4. Domain Name System
Section 4.1. Nuts and Bolts
Section 4.2. Zones Versus Domains
Section 4.3. Resource Records
Section 4.4. Using Primary and Secondary Nameservers
Section 4.5. Building a Nameserver
Section 4.6. Subdomains and Delegation
Section 4.7. Dynamic DNS
Section 4.8. Active Directory-Integrated Zones
Section 4.9. Forwarding
Section 4.10. The Split DNS Architecture
Section 4.11. Backup and Recovery
Section 4.12. Command-Line Utilities
Section 4.13. The Last Word
Chapter 5. Active Directory
Section 5.1. Active Directory Domain Services Objects and Concepts
Section 5.2. Building an AD DS Structure
Section 5.3. Understanding Operations Master Roles
Section 5.4. Understanding Directory Replication
Section 5.5. Active Directory Troubleshooting and Maintenance
Section 5.6. The Last Word
Chapter 6. Group Policy and IntelliMirror
Section 6.1. An Introduction to Group Policy
Section 6.2. Group Policy Implementation
Section 6.3. Local Group Policy
Section 6.4. Domain Group Policy
Section 6.5. Deployment Considerations
Section 6.6. Troubleshooting Group Policy
Section 6.7. Other Group Policy Management Tools
Section 6.8. Command-Line Utilities
Section 6.9. The Last Word
Chapter 7. Windows Security and Patch Management
Section 7.1. Understanding Security Considerations
Section 7.2. Locking Down Windows
Section 7.3. Using Auditing and the Event Log
Section 7.4. The Last Word
Chapter 8. Internet Information Services 7
Section 8.1. Major Improvements
Section 8.2. The New Architecture
Section 8.3. Roles
Section 8.4. Managing IIS Graphically
Section 8.5. Managing IIS from the Command Line
Section 8.6. The Last Word
Chapter 9. Windows Server 2008 Server Core
Section 9.1. The Lack of a Shell
Section 9.2. Realistic Deployment Scenarios
Section 9.3. No Managed Code
Section 9.4. Few Third-Party Software Applications
Section 9.5. Installation
Section 9.6. Initial Configuration
Section 9.7. Administering Windows Server 2008 Server Core Machines
Section 9.8. The Last Word
Chapter 10. Terminal Services
Section 10.1. The Remote Desktop Protocol
Section 10.2. Adding the Terminal Server Role
Section 10.3. Enabling Remote Desktop
Section 10.4. On the User's Side
Section 10.5. Terminal Services Administration
Section 10.6. Terminal Services RemoteApp
Section 10.7. Terminal Services Web Access
Section 10.8. Terminal Services Gateway
Section 10.9. Command-Line Utilities
Section 10.10. The Last Word
Chapter 11. DHCP and Network Access Protection
Section 11.1. Dynamic Host Configuration Protocol
Section 11.2. Network Access Protection
Section 11.3. The Last Word
Chapter 12. An Introduction to Clustering Technologies
Section 12.1. Network Load-Balancing Clusters
Section 12.2. Server Clustering
Section 12.3. Command-Line Utilities
Section 12.4. The Last Word
Chapter 13. PowerShell
Section 13.1. Why PowerShell?
Section 13.2. Installing PowerShell
Section 13.3. PowerShell and Security
Section 13.4. Starting Up PowerShell
Section 13.5. Cmdlets: The Heart of PowerShell
Section 13.6. Getting Help with PowerShell
Section 13.7. Using Data Stores and PowerShell Providers
Section 13.8. The Pipeline
Section 13.9. Formatting Basics
Section 13.10. Variables
Section 13.11. Writing Scripts
Section 13.12. Objects: .NET, WMI, and COM
Section 13.13. Advanced PowerShell
Section 13.14. Learning More About PowerShell
Section 13.15. The Last Word
Chapter 14. Hyper-V
Section 14.1. How It Works
Section 14.2. Getting Started with Hyper-V
Section 14.3. Virtualization Strategy
Section 14.4. The Last Word
Colophon
Index


preface.html

Windows Server 2008: The Definitive Guide

by Jonathan Hassell

Copyright © 2008 Jonathan Hassell. All rights reserved.

Printed in the United States of America.

Published by O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O'Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com.

Editor: | John Osborn
Production Editor: | Rachel Monaghan
Copyeditor: | Colleen Gorman
Proofreader: | Rachel Monaghan
Indexer: | Lucie Haskins
Cover Designer: | Karen Montgomery
Interior Designer: | David Futato
Illustrator: | Jessamyn Read

Printing History:

March 2008: First Edition.

Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks of O'Reilly Media, Inc. Windows Server 2008: The Definitive Guide, the image of an albatross, and related trade dress are trademarks of O'Reilly Media, Inc.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O'Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps.

While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

This book uses RepKover™, a durable and flexible lay-flat binding.

ISBN: 978-0-596-51411-2

[M]


preface-id1.html

Preface

Microsoft's server-oriented Windows operating systems have grown by leaps and bounds in capabilities, complexities, and sheer number of features since the release of Windows NT Server in the early 1990s. With each release, system administrators have found themselves grappling with new concepts, from domains, directory services, and virtual private networks, to client quarantining, disk quota, and universal groups. Just when you've mastered one set of changes, another comes along and suddenly you're scrambling once again to get up to speed. A vicious cycle this IT business is.

One source of help for the beleaguered administrator has always been the technical book market and its communities of authors, publishers, and user groups. Major releases of popular operating systems have always been accompanied by the publication of books written to support them, often encouraged by the software manufacturers. Some tout themselves as complete guides to their software compadres, while others approach their subject gingerly, as though their readers were of a questionable intellectual capacity. But over the years, many of these books have become as complex, and have accumulated as much detritus, as the operating systems they explain. You now see on the shelves of your friendly local bookstores 1,200-plus-page monstrosities that you might find useful, but only if you enjoy dealing with 30 pounds of paper in your lap or on your desk, and only if you find it productive to wade through references to "how things worked" four versions of Windows NT ago. After all, there's a limit to how many times you can revise something before it's best to simply start from scratch. Do you need all of that obsolete information to do your job efficiently?

I'm wagering that you don't (my luck in Las Vegas notwithstanding), and it was in that spirit that I set out to write Windows Server 2008: The Definitive Guide. I have trimmed the content of this volume to include just enough background on a subject for you to understand how different features and systems work in this version of Windows. I want you to come away from reading sections with a firm understanding of what's happening under the hood of the system, but without the sense that you're taking a graduate course in OS theory. Most of all, I want this book to be a practical guide that helps you get your work done—"here's how it works; here's how to do it."

The book you're either holding in your hands right now or reading online provides a more compact presentation, a lower price, and a tighter focus on tasks than other books on the market.

I hope that this work meets your expectations, and I hope you turn to it again and again when you need to understand the massive product that is Windows Server 2008.

P2.1. Audience

Beginning-to-intermediate system administrators will find this book a very helpful reference to learning how Windows Server 2008 works and the different ways to administer machines running that operating system. This book has step-by-step procedures, discussions of complex concepts such as Active Directory replication, DFS namespaces and replication, network access protection, the Server Core edition, Windows PowerShell, and server clustering. Although I've eliminated material that isn't relevant to day-to-day administration, you will still find the chapters full of useful information.

Advanced system administrators will also find this book useful for discovering new concepts and components outside of their realm of expertise. I've found that senior system administrators often focus on one or two specific areas of a product and are less familiar with other areas of the OS. This book provides a stepping-stone for further exploration and study of secondary parts of the operating system.

One other item to mention: throughout the book I've tried to highlight the use of the command line in addition to (or in some cases, as opposed to) graphical ways to accomplish tasks. Command lines, in my opinion, are fabulous for quickly and efficiently getting things done, and they provide a great basis for launching into scripting repetitive tasks. Microsoft has done an excellent job of integrating command-line functions into this revision of Windows, and I've attempted to do the effort justice within the text. But none of this should make you shy away from this book if you are a GUI aficionado: you'll still find everything you're accustomed to within this volume.

P2.2. Organization and Structure

In structuring the contents of this book I have tried to make a logical progression through the product, from a high-level overview through complete discussions and treatments of all its major components. Here's how this book is organized:

Chapter 1

Covers the product on a very general basis, from Microsoft's philosophy behind the product itself and the different versions of the product that are available, to an overview of the features in this release that are new or otherwise improved and a complete overview of the system design. This chapter is designed to give the administrator a complete and systematic overview of the product.

Chapter 2

Provides a detailed guide to installing the product in a variety of environments. I also include information on mass deployments using Windows Deployment Services, a vast improvement over previous image installation options offered in the box.

Chapter 3

Discusses the file services built into Windows Server 2008. The chapter begins with an overview of sharing and a guide to creating shares, publishing them to Active Directory, mapping drives, using the My Network Places applet, and accessing shares from the Start rightwards double arrow Run command and from within Internet Explorer. Then I dive into a detailed discussion of the Windows permission structure, including permission levels, "special" permissions, inheritance, and ownership. Here, you'll also find a guide to settings permissions. Also covered in this chapter is an overview of the Distributed File System (DFS), and how to set it up and manage it.

Chapter 4

Covers the domain name system, or DNS. Because DNS is such a fundamental component of Active Directory, I wanted to include a separate treatment of how it works, including a discussion of the different types of resource records and zone files supported, integration with Active Directory, the split DNS architecture, and backup and recovery of DNS data.

Chapter 5

Most installations of Windows Server 2008 will include installation of the Active Directory technology because so many products that require the server OS are tightly integrated with Active Directory. Chapter 5 provides a complete guide to the technical portion of Active Directory, including its logical and physical structure, hierarchical components (domains, trees, forests, and organizational units), scalability, and replication. Coverage of the LDAP standards is included, as well as a discussion of migration and security considerations. Then I move into planning strategies, installing Active Directory onto Windows Server, and the day-to-day administrative tools.

Chapter 6

Discusses Group Policy (GP), one of the most underappreciated management technologies in any server product. Chapter 6 is dedicated to introducing GP and its structure and operation. I begin with a survey of GP and Active Directory interaction, objects, and inheritance. Then I provide a practical guide to implementing GP through user and computer policies and administrative templates, installing software through GP, administration through scripting, and redirecting folders and other user interface elements. I also discuss IntelliMirror, a cool technology for application distribution (similar to ZENworks from Novell).

Chapter 7

Helps ensure that you are well versed in locking down your systems to protect both your own computers and the Internet community as a whole. I cover security policy, including ways to manage it using predefined templates and customized policy plans, and an overview of the Security Configuration and Analysis Tool, or SCAT. Then I provide a complete procedural guide to locking down both a Windows network server and a standard Windows client system (despite the fact that this is a server book, administrators often are responsible for the entire network, and client and server security go hand in hand).

Chapter 8

Covers the details of the major IIS revamp in this release. In version 7, IIS is arguably the best web server software available. I cover the architectural improvements and new features in this release, and then move on to a practical discussion of daily IIS administration.

Chapter 9

Covers the new Server Core editions of Windows Server 2008, including deployment, activation, and using these new GUI-less versions of the operating system.

Chapter 10

Provides a guide to Terminal Services, including an overview from the server administrator's perspective and a similar overview from a typical user's point of view. Then I cover how to install both Terminal Services itself and applications such as Microsoft Office and other tools inside the Terminal Services environment. A guide to configuring Terminal Services follows, including procedures for general configuration, remote control options, environment settings, logons, sessions, and permission control. Concluding the chapter is a guide to daily administration using Terminal Services Manager, the Active Directory user tools, Task Manager, and command-line utilities.

Chapter 11

Covers the standard networking architecture of the operating system, including addressing and routing issues. Then I move into a discussion of the various network subsystems: the Domain Name System (DNS), the Dynamic Host Configuration Protocol (DHCP), and a discussion of VPN connectivity, the different phases of VPN, tunneling and encryption, and the RADIUS server bundled with .NET Server, the Internet Authentication Service (IAS). Finishing up the chapter, I discuss IPSec, its support from within the OS, and how to install, configure, use, and administer it. Coverage of client quarantining is also included.

Chapter 12

Covers Windows clustering services. First, a discussion of the different types of clustering services is provided, and then I cover successfully planning a basic cluster and its different elements: the applications, how to group the machines, capacity and network planning, user account management, and the possible points of failure. A treatment of Network Load Balancing clusters follows, and I round out the chapter with a guide to creating and managing server clusters, as well as an overview of the administrative tools bundled with the OS.

Chapter 13

Discusses Windows PowerShell, the powerful object-based scripting and command-line technology now bundled with Windows Server 2008.

Chapter 14

Covers the fundamentals of Microsoft's currently prerelease virtualization solution called Hyper-V, including its structure, operation, and setup on Windows Server 2008. We'll also look at creating virtual machines, and we'll wrap up with what to expect upon Hyper-V's official release.

P2.3. Conventions Used in This Book

The following typographical conventions are used in this book.

Plain text

Indicates menu titles, menu options, menu buttons, and keyboard accelerators (such as Alt and Ctrl).

Italic

Indicates new terms, URLs, email addresses, filenames, file extensions, pathnames, directories, and command-line utilities.

Constant width

Indicates commands, options, switches, variables, attributes, keys, functions, types, classes, namespaces, methods, modules, properties, parameters, values, objects, events, event handlers, XML tags, HTML tags, macros, the contents of files, or the output from commands.

Constant width bold

Shows commands or other text that should be typed literally by the user.

Constant width italic

Shows text that should be replaced with user-supplied values.

This icon signifies a tip, suggestion, or general note.

This icon indicates a warning or caution.

P2.4. Using Code Examples

This book is here to help you get your job done. In general, you can use the code in this book in your programs and documentation. You do not need to contact O'Reilly for permission unless you're reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O'Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product's documentation does require permission.

O'Reilly appreciates, but does not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: "Windows Server 2008: The Definitive Guide by Jonathan Hassell. Copyright 2008 Jonathan Hassell, 978-0-596-51411-2."

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact O'Reilly at permissions@oreilly.com.

P2.5. We'd Like to Hear from You

Please address comments and questions concerning this book to the publisher:

O'Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (in the United States or Canada)
707-829-0515 (international or local)
707-829-0104 (fax)

O'Reilly has a web page for this book, where it lists errata, examples, and any additional information. You can access this page at:

http://www.oreilly.com/catalog/9780596514112

To comment or ask technical questions about this book, send email to:

bookquestions@oreilly.com

For more information about our books, conferences, Resource Centers, and the O'Reilly Network, see the O'Reilly web site at:

http://www.oreilly.com

P2.6. Safari® Books Online

When you see a Safari® Books Online icon on the cover of your favorite technology book, that means the book is available online through the O'Reilly Network Safari Bookshelf.

Safari offers a solution that's better than e-books. It's a virtual library that lets you easily search thousands of top tech books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://safari.oreilly.com.

P2.7. Acknowledgments

I've always liked the fact that the acknowledgments in technical books are typically in the front. That way, when you read the remainder of the book, you already know who to thank for it, unlike in a movie. So, without further ado:

John Osborn at O'Reilly was instrumental in getting this process organized and off the ground and provided very welcome guidance and feedback during the initial stages of writing this book.

Errors and shortcomings were dutifully found by the technical review team, which consisted of IT professionals Dan Green, Eric Rezabek, and Debbie Timmons.

Special thanks to the many folks at Microsoft and Waggener-Edstrom with whom I worked during the development of the book—their assistance and timely information was quite helpful in putting together this project.

Of course, my family is also to thank: particularly my wife, Lisa, who patiently accepted the insufficient answer of "not yet" repeatedly to her reasonable question of "Aren't you done with that book?"


introducing_windows_server_2008.html

Chapter 1. Introducing Windows Server 2008

It all started with Windows NT, Microsoft's first serious entry into the network server market. Versions 3.1 and 3.5 of Windows NT didn't garner very much attention in a NetWare-dominated world because they were sluggish and refused to play well with others. Along came Windows NT 4.0, which used the new Windows 95 interface (revolutionary only to those who didn't recognize Apple's Macintosh OS user interface) to put a friendlier face on some simple yet fundamental architectural improvements. With version 4.0, larger organizations saw that Microsoft was serious about entering the enterprise computing market, even if the product currently being offered was still limited in scalability and availability. For one, Microsoft made concessions to NetWare users, giving them an easy way to integrate with a new NT network. The company also included a revised security feature set, including finely grained permissions and domains, which signified that Microsoft considered enterprise computing an important part of Windows.

After a record six and one-half service packs, NT 4.0 is considered by some to be the most stable operating system ever to come out of Redmond. However, despite that, most administrators with Unix experience required an OS more credible in an enterprise environment—one that could compare to the enormous Unix machines that penetrated that market long ago and had unquestionably occupied it ever since. It wasn't until February 2000, when Windows 2000 Server was released, that these calls were answered. Windows 2000 was a complete revision of NT 4.0 and was designed with stability and scalability as first priorities.

However, something was still lacking. Sun and IBM included application server software and developer-centric capabilities with their industrial-strength operating systems, Solaris and AIX. Windows 2000 lacked this functionality. In addition, the infamous security problems associated with the bundled Windows 2000 web server, Internet Information Services (IIS), cast an ominous cloud over the thought that Windows could ever be a viable Internet-facing enterprise OS. Given that many saw Microsoft as "betting the company" on a web services initiative called .NET, it was critical that Microsoft save face and do it right the next time. It wasn't too late, but customers were very concerned about the numerous security vulnerabilities and the lack of a convenient patch management system to apply corrections to those vulnerabilities. Things had to change.

From stage left, enter Windows Server 2003. What distinguished the release other than a longer name and a three-year difference in release dates? Security, primarily. Windows Server 2003 came more secure out of the box and was heavily influenced by the month-long halt of new development in March 2002, referred to by Microsoft as the beginning of the Trustworthy Computing Initiative, wherein all developers and product managers did nothing but review existing source code for security flaws and attend training on new best practices for writing secure code. Performance was also improved in the Windows Server 2003 release, focus was put on making the operating system scalable, and in general enterprise administration was made more efficient and easier to automate. Microsoft also updated some bundled software via the Windows Server 2003 R2 release, making it more straightforward to manage identities over different directory services and security boundaries, distribute files and replicate directory structures among many servers, and more.

But as always, no software is perfect, and there's always room for improvement. As business requirements have changed, Microsoft developers worked in tandem on Windows Vista and the next release of Windows on the server. When Windows Vista was released to manufacturing, the teams split again, and the Windows Server 2008 group added a few new features and then focused on performance and reliability until the release.

1.1. The Biggest Changes

Unlike the transition from Windows 2000 Server to Windows Server 2003, which was a fairly minor "point"-style update, Windows Server 2008 is a radical revision to the core code base that makes up the Windows Server product. Windows Server 2008 shares quite a bit of fundamental code with Windows Vista, which was a product derived directly from the techniques of the secure development model (SDM)—sea change in programming methodologies at Microsoft that puts secure code at the forefront of all activity. Thus, a lot of new features and enhancements you will see in the product are a result of a more secure code base and an increased focus on system integrity and reliability.

The most radical changes to Windows Server 2008 include Server Core and the new Internet Information Services 7.0.

1.1.1. Server Core

Server Core is a minimal installation option for Windows Server 2008 that contains only a subset of executable files and server roles. Management is done through the command line or through an unattended configuration file. According to Microsoft:

Server Core is designed for use in organizations that either have many servers, some of which need only to perform dedicated tasks but with outstanding stability, or in environments where high security requirements require a minimal attack surface on the server.

Accordingly, there are limited roles that Core servers can perform. They are:

  • Dynamic Host Configuration Protocol (DHCP) server

  • Domain Name System (DNS) server

  • File server, including the file replication service, the Distributed File System (DFS), Distributed File System Replication (DFSR), the network filesystem, and single instance storage (SIS)

  • Print services

  • Domain controller, including a read-only domain controller

  • Active Directory Lightweight Directory Services (AD LDS) server

  • Windows Server Virtualization

  • IIS, although only with a portion of its normal abilities—namely only static HTML hosting, and no dynamic web application support

  • Windows Media Services (WMS)

Additionally, Server Core machines can participate in Microsoft clusters, use network load balancing, host Unix applications, encrypt their drives with Bitlocker, be remotely managed using Windows PowerShell on a client machine, and be monitored through Simple Network Management Protocol, or SNMP.

Most administrators will find placing Server Core machines in branch offices to perform domain controller functions is an excellent use of slightly older hardware that might otherwise be discarded. The smaller footprint of Server Core allows the OS to do more with fewer system resources, and the reduced attack surface and stability make it an excellent choice for an appliance-like machine. Plus, with a branch office, you can combine Server Core with the ability to deploy a read-only domain controller and encrypt everything with BitLocker, giving you a great, lightweight, and secure solution.

1.1.2. IIS Improvements

The venerable Microsoft web server has undergone quite a bit of revision in Windows Server 2008. IIS 7 is, for the first time, fully extensible and fully componentized—you only install what you want, so the service is lighter, more responsive, and less vulnerable to attack. The administrative interface for IIS has also been completely redesigned. Key improvements include:

Newly rearchitected componentized structure

For the first time in IIS history, administrators exercise complete control over exactly what pieces of IIS are installed and running at any given time. You can run the exact services you require—no more, no less. This is of course more secure, not to mention easier to manage and better performing.

Flexible extensibility model

IIS 7 allows developers to access a brand-new set of APIs that can interact with the IIS core directly, making module development and customization much easier than it ever has been. Developers can even hook into the configuration, scripting, event logging, and administration areas of IIS, which opens a lot of doors for enterprising administrators and third-party software vendors to extend IIS' capabilities sooner rather than later.

Simplified configuration and application deployment

Configuration can be accomplished entirely through XML files. Central IIS configuration can be spread across multiple files, allowing many sites and applications hosted by the same server to have independent but still easily managed configurations. One of Microsoft's favorite demos of IIS 7 is setting up a web farm with identically configured machines; as new members of the farm are brought online, the administrator simply uses XCOPY and moves existing configuration files over to the new server, and in a matter of seconds, the IIS setup on the new machine is identical to that on the existing machines. This is perhaps the most meaningful, and most welcome, change in IIS 7.

Delegated management

Much like Active Directory allows administrators to assign permissions to perform certain administrative functions to other users, IIS administrators can delegate control of some functions to other people, like site owners.

Efficient administration

IIS Manager has been completely redesigned and is joined by a new command-line administration utility, appcmd.exe.


the_biggest_changes.html

Chapter 1. Introducing Windows Server 2008

It all started with Windows NT, Microsoft's first serious entry into the network server market. Versions 3.1 and 3.5 of Windows NT didn't garner very much attention in a NetWare-dominated world because they were sluggish and refused to play well with others. Along came Windows NT 4.0, which used the new Windows 95 interface (revolutionary only to those who didn't recognize Apple's Macintosh OS user interface) to put a friendlier face on some simple yet fundamental architectural improvements. With version 4.0, larger organizations saw that Microsoft was serious about entering the enterprise computing market, even if the product currently being offered was still limited in scalability and availability. For one, Microsoft made concessions to NetWare users, giving them an easy way to integrate with a new NT network. The company also included a revised security feature set, including finely grained permissions and domains, which signified that Microsoft considered enterprise computing an important part of Windows.

After a record six and one-half service packs, NT 4.0 is considered by some to be the most stable operating system ever to come out of Redmond. However, despite that, most administrators with Unix experience required an OS more credible in an enterprise environment—one that could compare to the enormous Unix machines that penetrated that market long ago and had unquestionably occupied it ever since. It wasn't until February 2000, when Windows 2000 Server was released, that these calls were answered. Windows 2000 was a complete revision of NT 4.0 and was designed with stability and scalability as first priorities.

However, something was still lacking. Sun and IBM included application server software and developer-centric capabilities with their industrial-strength operating systems, Solaris and AIX. Windows 2000 lacked this functionality. In addition, the infamous security problems associated with the bundled Windows 2000 web server, Internet Information Services (IIS), cast an ominous cloud over the thought that Windows could ever be a viable Internet-facing enterprise OS. Given that many saw Microsoft as "betting the company" on a web services initiative called .NET, it was critical that Microsoft save face and do it right the next time. It wasn't too late, but customers were very concerned about the numerous security vulnerabilities and the lack of a convenient patch management system to apply corrections to those vulnerabilities. Things had to change.

From stage left, enter Windows Server 2003. What distinguished the release other than a longer name and a three-year difference in release dates? Security, primarily. Windows Server 2003 came more secure out of the box and was heavily influenced by the month-long halt of new development in March 2002, referred to by Microsoft as the beginning of the Trustworthy Computing Initiative, wherein all developers and product managers did nothing but review existing source code for security flaws and attend training on new best practices for writing secure code. Performance was also improved in the Windows Server 2003 release, focus was put on making the operating system scalable, and in general enterprise administration was made more efficient and easier to automate. Microsoft also updated some bundled software via the Windows Server 2003 R2 release, making it more straightforward to manage identities over different directory services and security boundaries, distribute files and replicate directory structures among many servers, and more.

But as always, no software is perfect, and there's always room for improvement. As business requirements have changed, Microsoft developers worked in tandem on Windows Vista and the next release of Windows on the server. When Windows Vista was released to manufacturing, the teams split again, and the Windows Server 2008 group added a few new features and then focused on performance and reliability until the release.

1.1. The Biggest Changes

Unlike the transition from Windows 2000 Server to Windows Server 2003, which was a fairly minor "point"-style update, Windows Server 2008 is a radical revision to the core code base that makes up the Windows Server product. Windows Server 2008 shares quite a bit of fundamental code with Windows Vista, which was a product derived directly from the techniques of the secure development model (SDM)—sea change in programming methodologies at Microsoft that puts secure code at the forefront of all activity. Thus, a lot of new features and enhancements you will see in the product are a result of a more secure code base and an increased focus on system integrity and reliability.

The most radical changes to Windows Server 2008 include Server Core and the new Internet Information Services 7.0.

1.1.1. Server Core

Server Core is a minimal installation option for Windows Server 2008 that contains only a subset of executable files and server roles. Management is done through the command line or through an unattended configuration file. According to Microsoft:

Server Core is designed for use in organizations that either have many servers, some of which need only to perform dedicated tasks but with outstanding stability, or in environments where high security requirements require a minimal attack surface on the server.

Accordingly, there are limited roles that Core servers can perform. They are:

  • Dynamic Host Configuration Protocol (DHCP) server

  • Domain Name System (DNS) server

  • File server, including the file replication service, the Distributed File System (DFS), Distributed File System Replication (DFSR), the network filesystem, and single instance storage (SIS)

  • Print services

  • Domain controller, including a read-only domain controller

  • Active Directory Lightweight Directory Services (AD LDS) server

  • Windows Server Virtualization

  • IIS, although only with a portion of its normal abilities—namely only static HTML hosting, and no dynamic web application support

  • Windows Media Services (WMS)

Additionally, Server Core machines can participate in Microsoft clusters, use network load balancing, host Unix applications, encrypt their drives with Bitlocker, be remotely managed using Windows PowerShell on a client machine, and be monitored through Simple Network Management Protocol, or SNMP.

Most administrators will find placing Server Core machines in branch offices to perform domain controller functions is an excellent use of slightly older hardware that might otherwise be discarded. The smaller footprint of Server Core allows the OS to do more with fewer system resources, and the reduced attack surface and stability make it an excellent choice for an appliance-like machine. Plus, with a branch office, you can combine Server Core with the ability to deploy a read-only domain controller and encrypt everything with BitLocker, giving you a great, lightweight, and secure solution.

1.1.2. IIS Improvements

The venerable Microsoft web server has undergone quite a bit of revision in Windows Server 2008. IIS 7 is, for the first time, fully extensible and fully componentized—you only install what you want, so the service is lighter, more responsive, and less vulnerable to attack. The administrative interface for IIS has also been completely redesigned. Key improvements include:

Newly rearchitected componentized structure

For the first time in IIS history, administrators exercise complete control over exactly what pieces of IIS are installed and running at any given time. You can run the exact services you require—no more, no less. This is of course more secure, not to mention easier to manage and better performing.

Flexible extensibility model

IIS 7 allows developers to access a brand-new set of APIs that can interact with the IIS core directly, making module development and customization much easier than it ever has been. Developers can even hook into the configuration, scripting, event logging, and administration areas of IIS, which opens a lot of doors for enterprising administrators and third-party software vendors to extend IIS' capabilities sooner rather than later.

Simplified configuration and application deployment

Configuration can be accomplished entirely through XML files. Central IIS configuration can be spread across multiple files, allowing many sites and applications hosted by the same server to have independent but still easily managed configurations. One of Microsoft's favorite demos of IIS 7 is setting up a web farm with identically configured machines; as new members of the farm are brought online, the administrator simply uses XCOPY and moves existing configuration files over to the new server, and in a matter of seconds, the IIS setup on the new machine is identical to that on the existing machines. This is perhaps the most meaningful, and most welcome, change in IIS 7.

Delegated management

Much like Active Directory allows administrators to assign permissions to perform certain administrative functions to other users, IIS administrators can delegate control of some functions to other people, like site owners.

Efficient administration

IIS Manager has been completely redesigned and is joined by a new command-line administration utility, appcmd.exe.


networking_improvements.html

1.2. Networking Improvements

The Windows Server 2008 team has made a special effort at improving network performance and efficiency. For the first time, there is a dual-IP layer architecture for native IPv4 and IPv6 support together, simultaneously. (If you've ever configured IPv4 and IPv6 on a Windows Server 2003 machine, you'll know what a pain it is to get them to interoperate without falling all over each other.) Communications security is enhanced through better IPsec integration throughout the various pieces of the TCP/IP stack. Hardware is used more efficiently and robustly to speed up performance of network transmissions, intelligent tuning and optimization algorithms run regularly to ensure efficient communication, and APIs to the network stack are more directly exposed, making it easier for developers to interact with the stack. Let's take a look at some of the improvements in what the team is calling Next Generation Networking.

1.2.1. TCP/IP Stack Enhancements

As I alluded to earlier, many changes in Windows Server 2008 were made to the TCP/IP stack itself. One such improvement is the auto-tuning TCP window size: Windows Server 2008 can automatically tune the size of the receive window by each individual connection, increasing the efficiency of large data transfers between machines on the same network. Microsoft quotes the following example: " ... on a 10 Gigabit Ethernet network, packet size can be negotiated up to 6 Megabytes in size."

The dead gateway detection algorithm present in Windows Server 2003 has been slightly improved: Windows Server 2008 now tries every so often to send TCP traffic through what it thinks to be a dead gateway. If the transmission doesn't error out, then Windows automatically changes the default gateway to the previously detected dead gateway, which is now live. And Windows Server 2008 supports offloading network processing functions from the CPU itself to the processing circuitry on the network interface card, freeing up the CPU to manage other processes.

There are also improvements to network scaling. For example, in previous versions of Windows Server, one NIC was associated with one single, physical processor. However, with the right network card, Windows Server 2008 supports scaling NICs and their associated traffic among multiple CPUs (a feature called receive-side scaling), permitting much higher amounts of traffic to be received by one NIC on a highly loaded server. This particularly benefits multiprocessor servers, since more scale can be added simply by adding processors or NICs and not by adding entirely new servers.

1.2.2. Changes to Terminal Services

Network applications are growing in popularity with each passing week. Windows Server 2008 sees more work in the Terminal Services/Remote Desktop area than might have been expected, and some of the new capabilities are very welcome improvements. Aside from the three new features, the team worked on improving the core processes that make TS tick, including single sign-on to Terminal Services sessions, monitor spanning and high-resolution support for sessions, integration with the Windows System Resource Manager to better monitor performance and resource usage, and themes that make TS sessions seamless to the client.

There are three key new features added in the Windows Server 2008 release. The first is Terminal Services RemoteApp. Like the functionality offered by Citrix MetaFrame years ago, Windows Server 2008 will support—out of the box—the ability to define programs to be run directly from a TS-enabled server but be integrated within the local copy of Windows, adding independent taskbar buttons, resizable application window areas, Alt-Tab switching functionality, remote population of system tray icons, and more. Users will have no idea that their application is hosted elsewhere, except for the occasional slow response because of network latency or server overload. It's also simple to enable this functionality: administrators create .RDP files, which are essentially text-based profiles of a Terminal Services connection that the client reads and uses to configure an RDP session for that particular program. They can also create .MSI files that can populate profiles; the main advantage here is that .MSI files are traditionally very easy to deploy via automated system management methods like Systems Management Server, Group Policy and IntelliMirror, and so on.

Next, there's the Terminal Services Gateway. This feature allows users to access Terminal Services-hosted applications from a web portal anywhere on the Internet, secured via an encrypted HTTPS channel. The gateway can send connections through firewalls and correctly navigate NAT translation situations that stymied the use of this technology before. This saves corporations from having to deploy VPN access to remote users for the sole purpose of accessing a Terminal Services machine; plus, since the data is sent over HTTPS, almost anyone can access the sessions, even at locations where the RDP protocol is blocked by the firewall. Administrators can set connection authorization policies, or CAPs, that define user groups that are permitted to access TS through the TS Gateway machine.

Finally, in conjunction with the Terminal Services RemoteApp feature, there is also in Windows Server 2008 the TS Web Access feature, which lets administrators publicly display available TS Remote Programs on a web page. Users can browse the list for the application they want to run, click on it, and then be seamlessly embedded in the application—using all the features of TS Remote Programs—while retaining the ability to launch other programs from the same Web Access site. The service is smart enough to know that multiple programs launched by the same user should reside in the same Terminal Services session, making resource management a bit simpler. And, you can even integrate TS Web Access within SharePoint sites using an included web part.

1.2.3. Active Directory: Read-Only Domain Controllers

Windows Server 2008 introduces the concept of a read-only domain controller (RODC), which is great for branch offices and other locations where the machines hosting the domain controller role can't be physically protected in the same way as a machine in a datacenter might be. RODCs hold a read-only copy of Active Directory, which allows for the immediate benefits of faster logons and quicker authentication turnaround times for other network resources, but also for the long-term security benefits. No attacker can create changes in an easily accessible DC in a branch office that will then replicate up to the main tree at the corporate office, since the DC is read-only. The RODC can also cache the credentials of branch office users and, with just one contact to a regular, writeable domain controller up the tree, can directly service users' logon requests. However, this caching is left off by default in the Password Replication Policy for security reasons.


security_improvements.html

1.3. Security Improvements

Security problems have plagued Microsoft since the Windows inception, but only in the last few years, as more people have become connected, have those flaws been exploited by malcontents. Indeed, some of the vulnerabilities in products that we see patches for on "Patch Tuesdays" are the results of poor design decisions. These types of flaws are the ones Microsoft is hoping to stamp out in the release of Windows Server 2008. You'll see quite a bit of change to the architecture of services in Windows Server 2008, including increasing the number of layers required to get to the kernel, segmenting services to reduce buffer overflows, and reducing the size of the high-risk, privileged layers to make the attack surface smaller.

While fundamentally changing the design of the operating system, the Windows Server 2008 team has also included several features designed to eliminate security breaches and malware infestations, as well as capabilities meant to protect corporate data from leakage and interception. Let's take a look at some of the improvements.

1.3.1. Operating System File Protection

A new feature currently known as operating system file protection ensures the integrity of the boot process for your servers. Windows Server 2008 creates a validation key based on the kernel file in use, a specific hardware abstraction layer (HAL) for your system, and drivers that start at boot time. If, at any subsequent boot after this key is created, these files change, the operating system will know and halt the boot process so you can repair the problem.

Operating system file protection also extends to each binary image that resides on the disk drive. OS file protection in this mode consists of a filesystem filter driver that reads every page that is loaded into memory, checking its hashes, and validating any image that attempts to load itself into a protected process (processes that are often the most sensitive to elevation attacks). These hashes are stored in a specific system catalog, or in an X.509 certificate embedded within a secure file on the drive. If any of these tests result in failure, OS file protection will halt the process to keep your machine secure. This is active protection against problematic malware.

1.3.2. BitLocker

The need for drive encryption has been a popular topic in a lot of security channels lately, and in both Windows Vista and Windows Server 2008 Microsoft has risen to the call by developing a feature called BitLocker. BitLocker is designed especially for scenarios where a thief may gain physical access to a hard drive. Without encryption, the hacker could simply boot another operating system or run a hacking tool and access files, completely bypassing the NTFS filesystem permissions. The Encrypting File System in Windows 2000 Server and Windows Server 2003 went a step farther, actually scrambling bits on the drive, but the keys to decrypt the files weren't as protected as they should have been. With BitLocker, the keys are stored within either a Trusted Platform Module (TPM) chip on board your system, or a USB flash drive that you insert upon boot up.

BitLocker is certainly complete: when enabled, the feature encrypts the entire Windows volume including both user data and system files, the hibernation file, the page file, and temporary files. The boot process itself is also protected by BitLocker—the feature creates a hash based on the properties of individual boot files, so if one is modified and replaced by, for example, a Trojan file, BitLocker will catch the problem and prevent the boot. It's definitely a step up from the limitations of EFS, and a significant improvement to system security over unencrypted drives.

1.3.3. Device Installation Control

Another security problem plaguing businesses everywhere is the proliferation of the USB thumb drive. No matter how securely you set your permissions on your file servers, no matter how finely tuned your document destruction capabilities are, and no matter what sort of internal controls you have on "eyes-only" documentation, a user can simply pop a thumb drive into any open USB port and copy data over, completely bypassing your physical security. These drives often contain very sensitive information that ideally should never leave the corporate campus, but they're just as often found on keychains that are lost, inside computer bags left unattended in an airport lounge, or in some equally dangerous location. The problem is significant enough that some business have taken to disabling USB ports by pouring hot glue into the actual ports. Effective, certainly, but also messy.

In Windows Server 2008, an administrator will have the ability to block all new device installs, including USB thumb drives, external hard drives, and other new devices. You can simply deploy a machine and allow no new devices to be installed. You'll also be able to set exceptions based on device class or device ID—for example, to allow keyboards and mice to be added, but nothing else. Or, you can allow specific device IDs, in case you've approved a certain brand of product to be installed, but no others. This is all configurable via Group Policy, and these policies are set at the computer level.

1.3.4. Windows Firewall with Advanced Security

The Windows Firewall version included with Windows Server 2003 Service Pack 1 was exactly the same as that included in Windows XP Service Pack 2. Microsoft bundled that firewall with Service Pack 1 as a stopgap measure—deploy this firewall now, Microsoft said, so you will be protected, and we will work to improve the firewall in the next version of Windows.

That time is here. The new Windows Firewall with Advanced Security combines firewall and IPsec management into one convenient MMC snap-in. The firewall engine itself has been rearchitected to reduce coordination overhead between filtering and IPsec. More rules functionality has been enabled, and you can specify explicit security requirements such as authentication and encryption very easily. Settings can be configured on a per-AD computer or user group basis. Outbound filtering has been enabled; there was nothing but internal filtering in the previous version of Windows Firewall. And finally, profile support has been improved as well—on a per-computer basis, there is now a profile for when a machine is connected to a domain, a profile for a private network connection, and a profile for a public network connection, such as a wireless hotspot. Policies can be imported and exported easily, making management of multiple computers' firewall configuration consistent and simple.

1.3.5. Network Access Protection

Viruses and malware are often stopped by software defenses before they can run within a user's session, but the ultimate protection would be if they never even got access to the network. In Windows Server 2008, Microsoft has created a platform whereby computers are examined against a baseline set by the administrator, and if a machine doesn't stack up in any way against that baseline, that system can be prevented from accessing the network—quarantined, as it were, from the healthy systems until the user is able to fix his broken machine. This functionality is called Network Access Protection.

NAP can be broken down into three key components:

Health policy validation

Validation is the process wherein the machine attempting to connect to the network is examined and checked against certain health criteria that an administrator sets.

Health policy compliance

Compliance policies can be set so that managed computers that fail the validation process can be automatically updated or fixed via Systems Management Server or some other management software, as well as by Microsoft Update or Windows Update.

Limited access

Access limiting can be the enforcement mechanism for NAP. It's possible to run NAP in monitoring-only mode—which logs the compliance and validation state of computers connecting to the network—but in active mode, computers that fail validations are put into a limited-access area of the network, which typically blocks almost all network access and restricts traffic to a set of specially hardened servers that contain the tools most commonly needed to get machines up to snuff.

Keep in mind that NAP is only a platform by which these checks can be made—pieces of the puzzle are still needed after deploying Windows Server 2008, including system health agents (SHAs) and system health validators (SHVs) that ensure the checks and validations are made on each individual client machine. Windows Vista ships with default SHAs and SHVs that can be customized.


manageability_improvements.html

1.4. Manageability Improvements

Servers are only effective if the administrator configures them properly. Windows Server products have traditionally been fairly simple to operate, but in Windows Server 2008 there are many improvements to the initial setup and configuration experience. Much of these details are still being worked out, and these elements may change as we draw nearer to the anticipated release date, but let's take a look anyway and see what Windows Server 2008 has to offer in terms of manageability enhancements.

1.4.1. Server Manager

Server Manager is a one-stop shop for viewing information on a server, looking at its stability and integrity, managing installed roles, and troubleshooting configuration issues that may arise. Server Manager replaces the Configure Your Server, Manage Your Server, and Security Configuration Wizard interfaces. It centralizes a variety of MMC 3.0 snap-ins, allowing you to see at a glance what roles and features are installed on any given machine, and giving you an easy jumping-off point to begin management of those pieces.

1.4.2. Windows Deployment Services

Many an administrator have come to love Remote Installation Services (RIS), the add-on to Windows 2000 Server and Windows Server 2003 that streamed an installation of client and server operating systems over the network and provided the ability to customize installations and set them off with just a few keystrokes. In Windows Server 2008, Microsoft has radically revised RIS and renamed it Windows Deployment Services (WDS). WDS still works using pre-boot execution environment (PXE) and trivial file transfer protocol (TFTP) to an OS, but it includes Windows PE, a graphical frontend to the installation process that replaces the ugly, less functional text-based blue screen setup phase that's plagued corporate Windows since NT 3.0.


performance_and_reliability_upgrades.html

1.5. Performance and Reliability Upgrades

Among the other enhancements in Windows Server 2008, work was done to improve overall system reliability and performance. For example, to view processes in previous versions of Windows Server, you had two basic tools, both of which were virtually unchanged from release to release—the Task Manager and the Performance Monitor. In Windows Server 2008, these tools have been combined into a single interface, called the Performance Diagnostics Console (which is also integrated into the aforementioned Server Manager), to make it easier to view statistics and alerts about how well your machine is handling its duties.

The Resource View is a simpler, but more powerful, view of how certain processes and services, among other metrics, are using the available resources on your machine. The Reliability Monitor shows a detailed view of exactly what events are occurring on a regular or intermittent basis to degrade the stability of your server. For example, you can see problems and degradations based on software installation activity, application failures, hardware missteps, Windows failures, and other, uncategorized problems. The Reliability Monitor generates a "stability index," which is a painfully arbitrary number supposedly representing, on a scale of 1 to 10, how pristine your system is.


windows_server_2008_editions.html

1.6. Windows Server 2008 Editions

As always, Microsoft has split up the various editions of Windows Server 2008 so that, in theory, each customer segment is served by the right product with the right feature set at the right price. Windows Server 2008 is available in the following editions:

Windows Web Server 2008

This version of Windows Server 2008 is optimized to host web sites using IIS and is therefore limited in its support of hardware and in its feature set. It's designed specifically as a web server, so you won't find many features enabled other than IIS, ASP.NET, and some other web hosting-specific capabilities. Avoid this edition unless you have machines whose sole purpose is serving web and other Internet content.

Standard Edition (SE)

This is the plain-vanilla version of Windows that most corporations likely will deploy. Included with it is support for up to two processors and 4 GB of memory. SE includes most of the features and support of the other editions, including the .NET Framework, IIS 7, Active Directory, the distributed and encrypting filesystems, and various management tools. You also receive Network Load Balancing (a feature previously reserved for the "premium editions" of the NT server product) and a simple Post Office Protocol 3 (POP3) server which, coupled with the existing Simple Mail Transfer Protocol (SMTP) server bundled with IIS, can turn your Windows Server 2003 machine into an Internet mail server.

Enterprise Edition (EE)

Aimed squarely at more demanding environments, EE adds clustering support, support for eight processors, 64 GB of RAM for x86-based systems and up to 2 TB of RAM for x64 systems, the ability to hot-add memory to a running server, and unlimited network connections, among other things.

Datacenter Edition (DE)

This performance- and scalability-enhanced Windows Server 2008 edition supports from 8 to 32 processors, hot-adding of processors and their replacement, and features the same memory support of the Enterprise Edition. With the exception of more extensive firewalling features and some increase in virtual machine licensing, DE is identical to EE.

For more information, visit the Microsoft web site at http://www.microsoft.com/windowsserver2008/en/us/editions-overview.aspx.


hardware_requirements.html

1.7. Hardware Requirements

Table 1-1 lists Microsoft's minimum and recommended system requirements for running Windows Server 2008.

Table 1-1. Minimum and recommended system requirements for Windows Server 2008
Requirements | Minimum | Recommended
Processor | 1 GHz (x86 processor) or 1.4 GHz (x64 processor) | 2 GHz or faster
Memory | 512 MB RAM | 2 GB RAM or greater
Available Disk Space | 10 GB | 40 GB or greater
Drive | DVD-ROM drive
Display | Super VGA (800 x 600) or higher resolution monitor
Other | Keyboard and Microsoft Mouse or compatible pointing device

However, anyone with prior experience with Windows operating systems is likely familiar with the simple fact that Microsoft's minimum system requirements (and often, the recommended requirements as well) are woefully inadequate for all but the most casual serving duties. Based on price and performance considerations as of this writing, I recommend the following specifications for any Windows Server 2008 version available through traditional channels. I'll refer to these as the "realistic minimums" from this point on in the book.

  • A Pentium III 1GHz processor

  • A server machine capable of using dual processors

  • At least 512 MB of RAM

  • At least 9 GB of disk space

In this day and age, PC hardware changes in value, speed, and availability on what seems like a daily basis. Unless your sole job is to continually specify the hardware platforms and configurations on which your client and server computers will run, it only takes missing a week's worth of developments to miss out on new processor speeds, chipset replacements or introductions, and hard-drive enhancements.

Of course, the methodology for selecting hardware for your servers remains true regardless of the operating system—disk speed is the single most prominent bottleneck in a fileserver, whereas an application server has performance obstacles in the processor and memory.


the_last_word.html

1.8. The Last Word

Windows Server 2008 presents an interesting set of features that result in tangible benefits for many administrators. The Server Core version of the product is perhaps the most useful new installation option of Windows on the server in quite a while, and it's appropriate for use in many situations where rock-solid servers are required. If your server farm hosts network-intensive applications, you'll find the changes to the TCP/IP stack and other network performance improvements tantalizing, and hardware assistance now makes network scaling much more cost effective by requiring fewer physical servers than before. Security is of course of paramount importance, and NAP alone is worth investing in Windows Server 2008. Management capabilities are improved as well.

Two general camps of people and their organizations will find compelling reasons to immediately upgrade to Windows Server 2008:

Those still running a version of Windows NT or Windows 2000 Server

NT Server 4.0 reached the end of its supportable life on December 31, 2004. Windows 2000 Server's mainstream support ended June 30, 2005, and while extended support will be available until July 13, 2010, it's smart to consider a move. Windows Server 2008, a fundamentally major release, provides a good jump up to new features, although it will likely require a hardware refresh if you are still running Windows NT or Windows 2000 in production.

Those with current Microsoft Select, Software Assurance, or Open License agreements that allow them to upgrade to the latest release at no additional cost

If there's no fee or additional monetary outlay for your upgrade, you can get the benefit of Windows Server 2008 for little overall monetary cost.

If you are not a member of either group, the value of upgrading to Windows Server 2008 is less clear, though a strong case could be made for moving up. If you're happily chugging away with Windows Server 2003 or R2, have read this chapter and don't see any features you absolutely must have now, and don't have an update agreement with Microsoft, you might want to skip this release and wait for Windows Server 2009 (or whatever the appropriate year might be).

For most corporations, it's a question of timing. Consider that the next radically different revision of Windows is about three years away on the desktop and four to five years away on the server. You'll have plenty of time to move to Windows Server 2008 in that window. For others, it's a question of finances: if you can't afford to upgrade to Windows Server 2008, then it's a dead end. If you are satisfied with Windows Server 2003, or the R2 edition, and have secured it properly, nothing in Windows Server 2008 is absolutely mandatory. The same goes with those running the original release of Windows Server 2003 with Service Pack 1 without a complimentary upgrade route to R2.


installation_and_deployment.html

Chapter 2. Installation and Deployment

Now that you've been thoroughly introduced to what's new, what's hot, and what's not in Windows Server 2008, the time has come to install the operating system on your machines. Installing Windows Server 2008 is easy: the fun comes in configuring and customizing the operating system. I'll begin by covering the installation process. Then I devote a large part of this chapter to unattended installations, automated deployment, and batch machine imaging, because you can gain a significant time savings by letting your computer handle as many of the tedious installation tasks as possible. So, let's jump in and get started.

2.1. Installing Windows Server 2008

It's a fairly effortless procedure to install Windows Server 2008 onto new systems. Here are the steps:

  1. Turn the system power on and insert the Windows Server 2008 DVD into the drive. If you receive a prompt asking you to select from what location to boot, choose the option to boot from the CD. The system will boot and begin the initial installation procedure. Figure 2-1 shows the beginning of this phase from the Install Windows screen. Choose the correct language, time and currency format, and keyboard input method, and then click Next.

    Figure 2-1. Beginning the Windows installation process

  2. Click the "Install now" button in the middle of the screen.

  3. When you click the next screen, shown in Figure 2-2, you are prompted for your product key. You do not have to enter the key now, but you will be required within a certain amount of time to enter a valid key once installation is complete. Enter your key if you wish and then click Next. Note that if you don't enter a key now, make sure that when you choose an edition to install (on the next screen), you choose the edition that corresponds to the key you will enter later; otherwise, you may need to reinstall.

    Figure 2-2. Entering the product key

  4. If you did not enter a key, the screen shown in Figure 2-3 will appear, asking you to select the edition of Windows that you purchased. (If you had entered a key, Windows would have automatically chosen the correct edition based on the contents of your key.) Choose which edition of the product—including the standard installation or the Server Core flavor—to install. Then, click Next.

    Figure 2-3. Selecting the edition of Windows Server 2008 to install

  5. Read the terms of the license agreement. If you accept (which, of course, you have to do to continue installation), check the box and click to continue.

  6. The "Which type of installation do you want?" screen appears, depicted in Figure 2-4. If you were running this installation from within Windows, the Upgrade selection would be enabled, allowing you to move to Windows Server 2008 with most of your programs, files, and settings intact. This is not the recommended path; here, in this example, we are completing a clean installation onto a formatted, blank disk. In this case, the only available option is Custom. Click "Custom (advanced)" to continue.

    Figure 2-4. Selecting an installation type

  7. A screen listing your current disk partitions will appear, as shown in Figure 2-5. You can delete, create, and format partitions to your heart's content here. Once you have at least one partition with 15 GB or more of disk space on it, you can click Next. If you haven't yet formatted, Setup will handle that.

    Figure 2-5. Deleting, creating, and formatting disk partitions

  8. Finally, files are copied and settings are finalized. This process can take a little while, up to 30 minutes, so feel free to step away (Figure 2-6).

Figure 2-6. Completing the installation process

Your installation will be complete once the system restarts a couple of times. The first screen you see will prompt you to add an administrator password; as you'll recall, nowhere during the setup process did you create a user account. Windows adds the administrator account automatically, and creates a complex temporary password to protect the account during installation and the initial boot process, but upon first logon you must change it.


installing_windows_server_2008.html

Chapter 2. Installation and Deployment

Now that you've been thoroughly introduced to what's new, what's hot, and what's not in Windows Server 2008, the time has come to install the operating system on your machines. Installing Windows Server 2008 is easy: the fun comes in configuring and customizing the operating system. I'll begin by covering the installation process. Then I devote a large part of this chapter to unattended installations, automated deployment, and batch machine imaging, because you can gain a significant time savings by letting your computer handle as many of the tedious installation tasks as possible. So, let's jump in and get started.

2.1. Installing Windows Server 2008

It's a fairly effortless procedure to install Windows Server 2008 onto new systems. Here are the steps:

  1. Turn the system power on and insert the Windows Server 2008 DVD into the drive. If you receive a prompt asking you to select from what location to boot, choose the option to boot from the CD. The system will boot and begin the initial installation procedure. Figure 2-1 shows the beginning of this phase from the Install Windows screen. Choose the correct language, time and currency format, and keyboard input method, and then click Next.

    Figure 2-1. Beginning the Windows installation process

  2. Click the "Install now" button in the middle of the screen.

  3. When you click the next screen, shown in Figure 2-2, you are prompted for your product key. You do not have to enter the key now, but you will be required within a certain amount of time to enter a valid key once installation is complete. Enter your key if you wish and then click Next. Note that if you don't enter a key now, make sure that when you choose an edition to install (on the next screen), you choose the edition that corresponds to the key you will enter later; otherwise, you may need to reinstall.

    Figure 2-2. Entering the product key

  4. If you did not enter a key, the screen shown in Figure 2-3 will appear, asking you to select the edition of Windows that you purchased. (If you had entered a key, Windows would have automatically chosen the correct edition based on the contents of your key.) Choose which edition of the product—including the standard installation or the Server Core flavor—to install. Then, click Next.

    Figure 2-3. Selecting the edition of Windows Server 2008 to install

  5. Read the terms of the license agreement. If you accept (which, of course, you have to do to continue installation), check the box and click to continue.

  6. The "Which type of installation do you want?" screen appears, depicted in Figure 2-4. If you were running this installation from within Windows, the Upgrade selection would be enabled, allowing you to move to Windows Server 2008 with most of your programs, files, and settings intact. This is not the recommended path; here, in this example, we are completing a clean installation onto a formatted, blank disk. In this case, the only available option is Custom. Click "Custom (advanced)" to continue.

    Figure 2-4. Selecting an installation type

  7. A screen listing your current disk partitions will appear, as shown in Figure 2-5. You can delete, create, and format partitions to your heart's content here. Once you have at least one partition with 15 GB or more of disk space on it, you can click Next. If you haven't yet formatted, Setup will handle that.

    Figure 2-5. Deleting, creating, and formatting disk partitions

  8. Finally, files are copied and settings are finalized. This process can take a little while, up to 30 minutes, so feel free to step away (Figure 2-6).

Figure 2-6. Completing the installation process

Your installation will be complete once the system restarts a couple of times. The first screen you see will prompt you to add an administrator password; as you'll recall, nowhere during the setup process did you create a user account. Windows adds the administrator account automatically, and creates a complex temporary password to protect the account during installation and the initial boot process, but upon first logon you must change it.


initial_configuration_tasks.html

2.2. Initial Configuration Tasks

After your password is changed, Windows Server 2008 logs you in as an administrator, and the Initial Configuration Tasks screen appears, as shown in Figure 2-7. On this screen, you can complete the numerous but sometimes tedious steps to configure a newly installed machine for daily use, like setting the time zone, adding IP addresses and configuring them, naming the computer and joining it to a workgroup or domain, updating, and so on.

Figure 2-7. The Initial Configuration Tasks screen

I strongly recommend that the first step you complete on this screen is to immediately click the "Download and install updates" link (assuming you have an active network connection that can route to the Internet) to apply the latest security fixes and service packs before placing the machine into production.

In today's hostile Internet environment, I strongly encourage you to perform your installation on a machine that is at least protected by a hardware firewall, and preferably on a machine that is completely disconnected from the network, unless you are using a network-based deployment method (more on this later in the chapter). While the Windows Server 2008 firewall is initially on upon first boot, I have never heard of a virus, worm, or Trojan entering a system from the network without that system having network access. And Linksys, D-Link, and other hardware firewalls are cheap, reusable, and can come in handy in a variety of scenarios. It's a simple step to take to prevent hours of headaches.

2.2.1. Understanding Product Activation

Retail copies of Windows Server 2008 have a feature known as activation, which is an antipiracy measure instituted by Microsoft. In essence, when you install Windows with a specific license key on a computer, a hash is created using the key and several attributes of hardware on the computer, including the network card's MAC address. (The exact way this hash is created is, of course, secret.) This hash can't uniquely identify a computer, but it identifies a specific installation of Windows. This hash is sent to Microsoft during the activation procedure. The theory is that if you later try to use the same product key for an installation on different hardware (for example, on another computer), the hash created would be different, and activation would fail because it's likely you are trying to use more than one copy of Windows when you're licensed for only a single installation.

You have 30 days to activate the product upon initial installation with a retail-purchased copy of Windows Server 2008. When you reach this deadline, you won't be able to log on to the system, though it will continue to run without console access until you reboot it.

The catch to activation is this: if you change enough hardware in the same system to change the hash, Windows will complain that you need to activate the software again. You might need to actually call a toll-free number to speak with a representative in this case to explain why your hardware changed. This service is available 24 hours a day, 7 days a week, but it's a pain to spend time pleading your case. The service is fast, and many users have reported that the staff running it is helpful and usually quite accommodating, but it's the principle of the situation.

There are two types of product keys that are issued for Windows Server 2008. The first type is what we just discussed, and that's the individual, one-machine license keys that are issued with new computers, retail copies of Windows Server 2008, and so on. (There are minor differences in those keys, such as the OEM-type keys that don't technically require user-initiated activation, but that's outside the scope of this discussion.) The second type is keys meant to unlock software licensed under corporate agreements. Unlike Volume Activation 1.0 (which you may have seen in action in Windows Server 2003), which produced keys that bypassed product activation, Volume Activation 2.0 still gives keys for bulk-licensed copies, but it doesn't disable activation. Instead, these keys have multiple allowed activations associated with them—hence their name, multiple activation keys, or MAKs. According to Microsoft, "computers can be activated on an individual basis or by a central computer" (see the next point) "which can activate multiple computers at a time."

You can manage these activations and individual computers' product keys over the network. The Key Management Service (KMS), which tackles this task, runs on Windows Server 2003 machines with Service Pack 1 or later, or Windows Server 2008. Machines running KMS can handle activations of internal machines that run Windows Vista Business, Windows Vista Enterprise, or any Windows Server 2008 edition without having to route requests to activate each of those computers to Microsoft's public activation service. While this might seem like a great loophole to get around activation, it's not quite set-and-forget; copies of the operating system activated through a business's KMS will be required to reactivate by connecting to machines running KMS at least once every 180 days. Additionally, you must have 25 or more physical Windows Vista machines, or 5 physical Windows Server 2008 machines, on the same network for KMS to function. The machine running KMS will of course need to activate itself using a KMS-specific key, which, once validated, authorizes that machine to activate its subordinates.

Interestingly, the default configuration of a Windows Server 2008 is to act as a KMS client, so with a properly deployed KMS structure, your new Windows Server 2008 installations should automatically detect the KMS servers on your network and activate themselves accordingly.


deployment.html

2.3. Deployment

The deployment story in Windows Server 2008 (and Windows Vista, for that matter) has radically changed. Windows Deployment Services (WDS) replaces the old Remote Installation Services (RIS) product that was included with Windows 2000 and Windows Server 2003. It has a number of enhancements, improvements, and new features, but perhaps the most important and the most useful of them is the ability for WDS to read, manage, and stream the new Windows Imaging Format (WIM). WIM support was first baked into Windows Vista and solves a number of problems that you may have stumbled on if you've worked with imaging products for Windows in the past. While WDS can still deploy what it calls "legacy" images—for example, Windows XP installations in the format you used to use in conjunction with Remote Installation Services—WDS shines when you set up different WIM files with boot and install images for different architectures and systems.

With some upfront grunt work (and that may be putting it mildly), you can significantly reduce the time it takes to achieve a complete deployment on machines that are of different types, architectures, and configurations. Let's take a look at some critical components of the deployment infrastructure under Windows Server 2008.

2.3.1. Windows Imaging Format

Windows Vista introduced the Windows Imaging Format, a hardware-independent format that stores images of the operating system. The premise of WIM is to make images many-to-one in nature; in other words, multiple images can be contained within one WIM file. Since Windows Vista was architected to be so modular, 95% of the base operating system can be replicated among any number of images; as a result, Microsoft itself can ship just one binary image for each processor architecture—x86 and x64—to everyone in the channel. Additionally, the sizes of each of the image files are reduced using single-instance storage techniques and enhanced compression. Further, you can create WIM files very easily for your own uses and modify them as well.

Perhaps the best usability improvement of the WIM format is the ability to edit images offline using standard file management tools like Windows Explorer. You can add files and folder to an image; for instance, instead of the painful driver addition process in Remote Installation Services, you can simply drop drivers directly into a WIM-based image and have them automatically present for future deployments. Best of all, you don't need to create independent images for each edit you make—the additions, modifications, and deletions you make can coexist in one image, reducing management burden.

2.3.2. Windows PE

Windows Pre Environment, or Windows PE, is an execution environment designed to assist in installing and troubleshooting operating system installations. Rather than the old blue-background, text-based installation screen with previous versions of NT, Windows PE comes in graphical format and contains a full complement of tools to assist with getting Windows Server 2008 and Windows Vista installed on a drive.

The big win with Windows PE is that standard Windows network drivers work with it out of the box—no hunting for special NDIS drivers only for network deployment use. Additionally, it has a built-in firewall to protect the operating system in its most vulnerable state, when it is partially installed, and the ability to insert drivers from any sort of removable media into the session. You might recall the frustration of only being able to add a driver by hitting F6 at the right moment of Setup and then having the driver only on a floppy disk. Windows PE eliminates this annoyance.

2.3.3. Windows Deployment Services

Windows Deployment Services is the next generation of Windows 2000 and Windows Server 2003's RIS. It released with Windows Server 2003 Service Pack 2 and is the only supported method of deploying Windows Vista over the network, so if you want to stream Vista images to desktops and notebooks over the Net, you'll need to upgrade your RIS servers to that service pack level and then deploy WDS. WDS supports both x86 and x64 images as well.

Like RIS, WDS uses the Preboot Execution Environment (PXE) capabilities of most modern BIOSes and network interface cards to load a session of Windows PE. Windows PE then presents a menu to the user consisting of all the appropriate image and configuration options available on the WDS machine. The user selects a target, and the image—in WIM format, of course—is laid onto the disk of the target machine. It's all very elegant when you have configured it properly, and it makes it possible to reimage a system—in some cases, with applications and configurations as well—in less than 30 minutes. Imagine the boon to your support department: instead of wasting hours tracking down some obscure problem, you simply stream a new image to a machine while the user is out to lunch, and voilà! Problem solved. True, that's a rosy case, but it's possible and realistic with WDS and WIM.

What's changed from RIS? Here's a quick rundown, courtesy of Microsoft:

  • The ability to deploy Windows Vista and Windows Server 2008 aside from simply Windows XP and the old NT-based operating systems

  • Windows PE can be used as a boot operating system, allowing for both deployment and troubleshooting

  • Support for WIM deployments

  • Ability to transmit data and images using multicast functionality, which allows the performance of deployment services over the network to scale significantly better and more efficiently

  • An enhanced PXE server stub

  • A new, more user-friendly boot menu format that is both easier to use and easier to configure

  • A new management console that helps you manage WDS servers on your networks, and the boot and install images contained thereon

There are two types of WDS servers that you can create: a transport server and a deployment server. The transport server only offers the core networking services; it doesn't give you all the functionality of WDS but is useful if you want to take advantage of the multicasting features in larger environments. A deployment server offers everything that WDS offers, including the transport components. For the purposes of this section of the chapter, we'll assume that we are working with a deployment server.

2.3.4. Installing and Configuring Windows Deployment Services

To install WDS, you need a Windows Server 2008 machine that is somehow joined to a domain. You'll also need DHCP working on your network, a valid DNS architecture, a partition formatted as NTFS, and a user account that is both a domain user and a local administrator on the server running WDS. If you meet all those requirements, you can install WDS by loading Server Manager, clicking Add Roles on the Roles Summary pane, and then selecting Windows Deployment Services.

Once you have added the role, it's time to configure the WDS server. There is a command-line utility, aptly named WDSUTIL, and there is the graphical component, which is an MMC snap-in. For this example, we'll walk through the graphical interface for WDS.

Your first steps should be as follows.

  1. We'll need to create a shared folder that stores the necessary programs and supporting files to enable PXE-based networking booting, the files for Windows PE which each machine will store in a dynamic RAM disk, the boot images for Windows PE itself so that it can fully run on your client machines, and the install images for your operating systems (these are the actual WIM files themselves that are meant to be deployed to your target machines).

  2. We then have to tell WDS how to answer PXE requests from the network, so that incoming client requests are answered or ignored depending on how security-conscious you want your deployment to be.

  3. Next, your DHCP settings should be changed, whether your DHCP service is hosted on a Windows Server 2008 machine or provided by some other network device. Specifically, all DHCP broadcasts on UDP port 67 by client computers should be forwarded directly to both the DHCP server and the Windows Deployment Services PXE server. Also, all traffic to UDP port 4011 from the client computers to the Windows Deployment Services PXE server should be routed appropriately. The WDS Configuration Wizard will take care of this step in most environments.

The Windows Deployment Services Configuration Wizard will handle a lot of these tasks for you, so let's load it and run through the wizard to get a baseline configuration prepared. If you haven't already, install the WDS role by using the Add Roles Wizard, which you can enter from the appropriate link at the bottom of the Initial Configuration Tasks page. Then, from the Administrative Tools submenu off the Start menu, select Windows Deployment Services. In the left pane, expand the server list, right-click on the current server, and select Configure Server. The wizard launches.

  1. On the Select Server Roles screen, shown in Figure 2-8, check the Windows Deployment Services box and click Next.

    Figure 2-8. The Select Server Roles screen

  2. The Overview of Windows Deployment Services screen appears, as shown in Figure 2-9. Read the overview and listing of requirements, and then click Next when you finish.

    Figure 2-9. The Overview of Windows Deployment Services screen

  3. The Select Role Services screen appears, depicted in Figure 2-10. Here, you select which of WDS's two roles you want to install, or you can opt for both. The Deployment Server role provides all of the functions and features of WDS and requires the components of the Transport Server role, which actually move the bits and bytes of your operating system images around the network. You can install the Transport Server role without the Deployment Server role, but you cannot have the Deployment Server role without the Transport Server role. Try it; the Add Roles Wizard will flash an error if you attempt the remove the latter and keep the former. For the purposes of our demonstration here, select both roles and click Next.

    Figure 2-10. The Select Role Services screen

  4. The Confirm Installation Selections screen appears. Verify the settings you've chosen in the wizard and then click the Install button. You may need to restart the machine you are using.

Once the WDS roles are installed, it is time to run the configuration wizard. The Welcome Page appears, as shown in Figure 2-11. Read the introduction and then click Next.

Figure 2-11. The Welcome Page of the Windows Deployment Services Configuration Wizard

The Remote Installation Folder Location screen appears, as shown in Figure 2-12. Here, you tell WDS where to store images to stream to clients. This folder must reside on a volume formatted by NTFS. It's recommended that you choose a volume that doesn't contain the Windows system files for best performance, although you won't be prevented from selecting the system disk—simply acknowledge the warning that will appear. Choose a path, and then click Next.

Figure 2-12. The Remote Installation Folder Location screen

The PXE Server Initial Settings screen appears, depicted in Figure 2-13. Here, you can establish whether your WDS machines will respond to clients who aren't made known to WDS before you begin their deployment. If you want any computer to be able to stream an image to its drive (subject to that user having appropriate permissions), then choose "Respond to all known and unknown client computers." You can also elect to have unknown clients make a request that can subsequently be approved by an administrator. To require that clients be prestaged within WDS, choose the second option, and to turn off WDS network booting completely, choose the first option. Click Finish to complete the wizard.

Figure 2-13. The PXE Server Initial Settings screen

The wizard will trundle for a while, completing the initial configuration steps, and then you will see the Configuration Complete screen, shown in Figure 2-14.

Figure 2-14. The Configuration Complete screen

Next up, you need to add the boot images. These are the images that download over the PXE-based network connection and set up the Windows PE-based environment in which all of the deployment magic happens. Expand the server to which you want to add the boot images, right-click on the Boot Images folder, and select Add Boot Image. Then, insert the operating system media into the local CD or DVD drive, and browse to the BOOT.WIM file (on the Windows Server 2008 DVD, it is located in the \Sources directory off of the root of the CD). Click Open, and then enter a friendly image name and description, click Next, and wait as the images are copied to the WDS machine's shared folder that you established during the configuration wizard.

Finally, you add the install images, which as you will recall are the actual target images streamed down over the network onto the machines on which you want an operating system installed. To get started, I recommend putting a default image of Windows Vista or Windows Server 2008 on your WDS machine. While this image won't come out of the box tweaked to your liking or with applications and settings preconfigured, I have found it useful to have the ability to install a vanilla Windows system over the network for other purposes as well. Additionally, you can start with these plain images, stream them to a system, customize them, capture the resulting image, and then re-upload it to the WDS machine, all without touching distribution media. To add a default install image of Windows Server 2008 onto your WDS machine:

  1. Click on the server that will store the install image and expand it to expose the tree of folders beneath it.

  2. Right-click on the Install Images folder in the left pane and select Add Install Image.

  3. The Image Group screen appears, as shown in Figure 2-15. Type a name for this image group—groups are simply ways to organize collections of images. For example, type in Windows Server 2008 Installations into the group name box. You can then add more images later and store them in this group to make it easy to administer them from the WDS MMC snap-in. Click Next.

    Figure 2-15. The Image Group screen

  4. The Image File screen appears. Browse the distribution media to find the INSTALL.WIM file located on the disc. For Windows Server 2008, you can find this image in the \Sources folder off the root of the media. Click Open.

  5. The List of Available Images screen is next (see Figure 2-16). Here, you select which of the editions of the product you would like to make available to installation clients. Clear the checkboxes of images that you would like to exclude from the WDS server, and then click Next.

    Figure 2-16. The List of Available Images screen

  6. The Summary screen shows Click Next to add the images to the store. This could take a while, as there is a lot to copy and manage.

Your boot and install images are now set up on the WDS server.

2.3.5. The Boot Menu

The Boot menu is a text-based screen that appears when WDS first begins loading after the PXE network environment has been established. The boot menu allows the user to choose between boot architectures—x86 clients can choose the right architecture, and there is a special boot version for x64 architectures as well—and further along in the process, it will dictate what choices appear in the installation menu.

WDS and 64-Bit Clients: A Quick Tip

You might find that some of your x64-based hardware isn't being detected correctly by your hardware and/or the PXE software. In this case, you may want to explicitly instruct WDS to show both x64 and x86 options on the boot menu. The simplest way to do this is from the command line, as follows:

WDSUTIL /Set-Server /Defaultx86x64ImageType:both

2.3.6. Creating and Modifying Images

Now that you have a sense of how to deploy WDS, and you have a few plain-vanilla install images on your server, you can set about creating custom images. You can create boot images and install images that are different from the defaults and suited to your requirements.

2.3.6.1. Creating and modifying boot images

You can create two different types of boot images for your needs: a capture image, which is what you boot a client computer into in order to capture an image of its hard drive for later deployment; and a discover image, which is used to install an operating system via WDS onto a computer that, for lack of hardware or software support, doesn't allow a PXE environment to be created.

Capture images automatically boot into the Windows Deployment Services Capture Utility in lieu of Setup. You use a capture image on a computer that is ready to be imaged, and once it is booted, a wizard creates an install image of the reference computer and saves it as a .wim file. You can then upload this WIM file onto your WDS server for deployment to other target machines. Alternatively, you can burn a CD or DVD that contains a capture image and the ImageX command-line utility. You can then boot the sourced system with the media, run ImageX to create the WIM-based image, and then connect over the network to a machine and upload that image for storage. I find it useful to have one of these capture image DVDs available, even if you choose not to make that method your standard way of capturing images.

To create a capture image:

  1. Open the Windows Deployment Services MMC snap-in.

  2. Expand Boot Images in the left pane.

  3. Right-click on an image to use it as the foundation for your capture image, and select Create Capture Boot Image.

  4. Enter a name, description, and the location to save the image.

  5. Finish out the wizard and then right-click the boot image folder and select Add Boot Image from the resulting menu.

  6. Browse to the new capture image you just created, and then click Next.

  7. Finish the addition wizard and close out. Your capture image is now ready to be deployed.

The second type of boot image you can create, a discover image, forces Setup.exe to launch in Windows Deployment Services mode and then ping around the network to find an active WDS machine. You can use these images on a CD or DVD to allow WDS to stream deployments to machines that don't or won't support PXE. To create a discover image, use the following procedure:

  1. Open the Windows Deployment Services MMC snap-in.

  2. Expand Boot Images in the left pane.

  3. Right-click on an image to use it as the foundation for your discover image, and select Create Discover Boot Image.

  4. Enter a name, description, and the location to save the image.

  5. Finish out the wizard and then right-click the boot image folder and select Add Boot Image from the resulting menu.

  6. Browse to the new discover image you just created, and then click Next.

  7. Finish the addition wizard and close out. Your discover image is now ready to be deployed.

If you are interested in creating hard media, such as a CD or DVD, to contain your discover image, you can download the Windows Automated Installation Kit from the Microsoft web site and install it. From that point, open a command prompt to the C:\Program Files\Windows AIK\Tools\PETools folder and commence the following procedure:

  1. Create a Windows PE build environment by entering CopyPE {arch} c:\WinPE, replacing the architecture of the boot image you'd like when issuing the command.

  2. Copy the discover image to a target directory using the following command:

    copy /y c:\boot.wim c:\winpe\iso\sources

  3. Go back to the PETools folder in step one, and create the bootable ISO image using the OSCDIMG utility that is bundled in the Windows Automated Installation Kit. Type the following:

    oscdimg -b -bc:\winpe\ISO\boot\etfsboot.com c:\windpe\ISO c:\winpe.sio

  4. Burn the resulting c:\winpe.iso file to a CD or DVD using your preferred burning and mastering software.

2.3.6.2. Creating install images

You can build custom install images (the images that consist of the actual operating system and any changes you want to bake into the package) from prepared computers and upload them for deployment to target machines. Generally, you boot the source computer normally, run the sysprep utility in most cases to strip out physical machine-specific information and security identifiers, then reboot into a WDS-based capture image, take a WIM-formatted image of the client, upload it somewhere else, and then reboot.

Specifically, after you have finished configuring the source (or reference, as Microsoft refers to it) computer the way you'd like it to be imaged, run the following from the command line:

sysprep /oobe /generalize /reboot

After the utility has finished and the computer has restarted, press F12 and select the capture image from the boot menu that will be displayed. Choose the drive that contains the operating system on which you just ran SYSPREP, provide a name and description for the image, and click Next to continue. Then browse to a location on the machine where you can store the resulting .WIM file, enter a name of the image file, and then click Save. Finally, click "Upload image to WDS Server," enter the name of your WDS machine, and click Connect, entering credentials if prompted or necessary. (Choose the correct image group along the way if you are so prompted.)

Click Finish, and your image will be created, prepared, and uploaded, and will be ready for deployment to your target machines.

2.3.6.3. Sysprep: the system preparation tool

The most common catch to any imaging solution is the need to identify and scrub security identifier (SID) information from your image. Deploying an image onto multiple computers, all with the same SID information, is an invitation to disaster. Sysprep is the answer to this problem.

Sysprep will not reimage a domain controller, a member of any cluster, or a machine functioning as a certificate server because of the inherent machine-specific characteristics of those services. However, after Sysprep has completed, these services are certainly supported and available to be installed.

Here's an overview of how Sysprep works:

  1. You generate a prototype image and configure everything on that system as needed.

  2. You then copy the profile of the account that has the settings and customizations you've been performing to the Default User profile, so that all future users of the system get those tweaks.

  3. Then you run Sysprep. This scrubs SIDs and personal information from your prototype and shuts down the machine.

  4. Next, you boot the computer from your WDS capture image and generate the WIM file. You can optionally upload that image as well.

  5. Finally, you reboot the computer without the floppy, and proceed through mini-Setup again so that all personal information can be restored and new SIDs can be generated. (You can script this process so that a mini-unattended installation is performed.)

2.3.7. Configuring and Performing Unattended Installations with Scripts

If you are interested in further automating the deployment of operating systems using WDS, look into using unattended installation scripts: not only can you kick off an OS deployment over the network, but you can customize the responses to setup prompts, installed programs, product keys that are configured, and more, so that even if you aren't using an imaged system, you achieve a consistent setup on all machines you roll out.

In Windows Server 2008 and Windows Deployment Services, there are essentially two different unattend files: a WDS client unattend file, which resides on the WDS server and directs the WDS client interface to install the right image and partition disks correctly; and the actual unattend file for the image itself, which is the type of unattend file with which you may be more familiar. This is stored in the $OEM$ structure common in the Windows 2000 and Windows Server 2003 days, or in the \Unattend directory in the image, and automates the remainder of the Setup process that the WDS unattend file can't address.

You'll find the Windows Automated Installation Kit will come in handy if you are creating more than the simplest unattend files—in particular, the Windows System Image Manager can walk you through creating an unattend file, which can then be assigned (associated, in effect) either to clients hitting a specific server or specific clients themselves, as well as different machines based on x86 and x64 architectures.

The format of the WDS client unattend file is easy to read, as it's in XML, which has a familiar syntax and structure. A sample follows.

Code View:
<?xml version="1.0" ?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
   <settings pass="windowsPE">
      <component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35"
language="neutral" versionScope="nonSxS" processorArchitecture="x86">
         <WindowsDeploymentServices>
            <Login>
               <WillShowUI>OnError</WillShowUI>
               <Credentials>
                     <Username>username</Username>
                     <Domain>domain</Domain>
                     <Password>password</Password>
                  </Credentials>
               </Login>
            <ImageSelection>
               <WillShowUI>OnError</WillShowUI>
               <InstallImage>
                  <ImageName>Windows Vista x86</ImageName>
                  <ImageGroup>Windows Vista</ImageGroup>
                  <Filename>Install.wim</Filename>
               </InstallImage>
                  <InstallTo>
                  <DiskID>0</DiskID>
                  <PartitionID>1</PartitionID>
               </InstallTo>
            </ImageSelection>
         </WindowsDeploymentServices>
         <DiskConfiguration>
            <WillShowUI>OnError</WillShowUI>
               <Disk>
                  <DiskID>0</DiskID>
                  <WillWipeDisk>false</WillWipeDisk>
                  <ModifyPartitions>
                     <ModifyPartition>
                        <Order>1</Order>
                        <PartitionID>1</PartitionID>
                        <Letter>C</Letter>
                        <Label>CLIENTMACHINE</Label>
                        <Format>NTFS</Format>
                        <Active>true</Active>
                        <Extend>false</Extend>
                     </ModifyPartition>
                  </ModifyPartitions>
            </Disk>
         </DiskConfiguration>
      </component>
      <component name="Microsoft-Windows-International-Core-WinPE"
publicKeyToken="31bf3856ad364e35"
language="neutral" versionScope="nonSxS" processorArchitecture="x86">
         <SetupUILanguage>
            <WillShowUI>OnError</WillShowUI>
            <UILanguage>en-US</UILanguage>
         </SetupUILanguage>
         <UILanguage>en-US</UILanguage>
      </component>
   </settings>
</unattend>

Here's the process to integrate unattend files with your WDS deployment. Start by associating the WDS unattend file to the appropriate image.

  1. Create your unattend.xml file for the WDS client. I suggest using the Windows System Image Manager, part of the Windows Automated Installation Kit.

  2. Once you've created the unattend.xml file, upload it to your WDS server at the \RemoteInstall\WDSClient\Unattend folder.

  3. Open Windows Deployment Services Manager.

  4. Right-click the WDS server that is hosting the image to which your new unattend file should be assigned, and click Properties.

  5. Navigate to the Client tab.

  6. Check the "Enable unattended installation" box, browse to your unattend file at \RemoteInstall\WDSClient\Unattend folder (use the full network path—don't go through the WDS server's local C: drive), and click Open.

  7. Click OK.

Next, you can associate the Windows Setup unattended file to the image for a full hands-off deployment. To do so:

  1. Open Windows Deployment Services Manager.

  2. Expand the image group that contains the image you want to use.

  3. Right-click the specific image and select Properties.

  4. Navigate to the General tab.

  5. Click "Allow image to install in unattend mode," and then click the Select file and browse to your Windows Setup unattend file. Click OK.

  6. Click OK to close out of the Properties sheet.


the_last_word-id1.html

2.4. The Last Word

In this chapter, I've covered quite a bit about the various methods to install Windows, how activation works, ways to recover from a bungled Setup, and what to do when Windows Server 2008 just won't boot. I've also looked at automated rollouts of the product and its client brethren.

In the next chapter, we'll step through in detail the file and print service functionality of Windows Server 2008.


file_services.html

Chapter 3. File Services

One of Windows Server 2008's primary functions within a typical organization is to serve files and connect multiple machines to a smaller number of printers. Windows Server 2008 enables you to create any number of shared folders that contain documents and programs that your users can access via such methods as Windows Explorer, Network Neighborhood, or mapped drives. The operating system also enables you to create a hierarchy of shared folders stored across multiple machines that can appear to end users as though they're stored on a single server.

Print services are simple to configure and manage. Windows Server 2008 enables you to share a printer connected either physically to the server, or to a print server device that is attached directly to the network. It can also host drivers for multiple operating systems and automatically distribute the correct drivers to client systems.

You'll need to be familiar with the following terminology to get the most from this chapter. Feel free to skip to the next section if you've been working with Windows for a while.

Disk

A disk is the actual, physical hard disk within the machine.

Drive

A drive is a logical object formatted for use with Windows. This can be either an entire physical disk or a partition.

Partition

A partition is a portion of a physical disk that can be used with volumes.

Volume

A volume is either a drive or a partition within Windows—it's a common term for both.

In this chapter, I'll discuss in depth all the file and print services Windows Server 2008 provides.

3.1. File and Print Server Features

Several features are present in Windows Server 2008 to enable faster, more seamless access to file and print services on your network. Although the infrastructure of the file and print systems has not been completely redesigned, it certainly has been modified to provide for ease-of-use enhancements, increased data integrity, automatic and assisted backup, and other key features, including the following:

Distributed File System (DFS)

DFS is a feature in Windows Server 2008 that permits an administrator to create one logical filesystem layout despite the fact that shares can be scattered across the network on different servers. This makes it easier for clients to find and store files consistently, and it allows for better equipment utilization. One server can host multiple DFS roots, which are "starting" points for a hierarchy of shared folders. In addition, a Windows Server 2008 server can use Active Directory site topology to route DFS requests from clients to the closest available server, increasing response time.

Encrypting File System (EFS)

Native encryption abilities are built into the NTFS filesystem used in Windows Server 2008. By simply checking a checkbox in the Properties sheet for a file, you can easily encrypt and decrypt files and folders to protect their integrity. This feature is particularly useful for mobile computers, which have a greater risk of data loss and capture than traditional corporate desktop machines.

Volume shadow copy

The volume shadow copy feature is perhaps one of the most useful features of Windows Server 2008. The server will take snapshots of files at specific periods during the day, thereby making available a library of previous versions of a file. If a user accidentally overwrites a file, saves an incorrect version, or somehow destroys the primary copy, he can simply click Previous Versions in the Explorer view of the folder and access a shadow copy version.

Windows Search Service

The Windows Search Service, new to Windows Server 2008, catalogs and indexes the contents of server hard disks, enabling users to search in files in different formats and languages for the data they need. The engine has been enhanced over several revisions of the product to accelerate the search process and to use less processor time when cataloging and indexing files.

In this chapter, you will find complete coverage of Windows Server 2008 file services—folder sharing, permissions, shadow copies, DFS, and backup strategies, techniques, and procedures. You will also become familiar with a user service known as roaming profiles, which allows your users' preferred desktop settings to travel with them to any workstation in the network they might be using.


file_and_print_server_features.html

Chapter 3. File Services

One of Windows Server 2008's primary functions within a typical organization is to serve files and connect multiple machines to a smaller number of printers. Windows Server 2008 enables you to create any number of shared folders that contain documents and programs that your users can access via such methods as Windows Explorer, Network Neighborhood, or mapped drives. The operating system also enables you to create a hierarchy of shared folders stored across multiple machines that can appear to end users as though they're stored on a single server.

Print services are simple to configure and manage. Windows Server 2008 enables you to share a printer connected either physically to the server, or to a print server device that is attached directly to the network. It can also host drivers for multiple operating systems and automatically distribute the correct drivers to client systems.

You'll need to be familiar with the following terminology to get the most from this chapter. Feel free to skip to the next section if you've been working with Windows for a while.

Disk

A disk is the actual, physical hard disk within the machine.

Drive

A drive is a logical object formatted for use with Windows. This can be either an entire physical disk or a partition.

Partition

A partition is a portion of a physical disk that can be used with volumes.

Volume

A volume is either a drive or a partition within Windows—it's a common term for both.

In this chapter, I'll discuss in depth all the file and print services Windows Server 2008 provides.

3.1. File and Print Server Features

Several features are present in Windows Server 2008 to enable faster, more seamless access to file and print services on your network. Although the infrastructure of the file and print systems has not been completely redesigned, it certainly has been modified to provide for ease-of-use enhancements, increased data integrity, automatic and assisted backup, and other key features, including the following:

Distributed File System (DFS)

DFS is a feature in Windows Server 2008 that permits an administrator to create one logical filesystem layout despite the fact that shares can be scattered across the network on different servers. This makes it easier for clients to find and store files consistently, and it allows for better equipment utilization. One server can host multiple DFS roots, which are "starting" points for a hierarchy of shared folders. In addition, a Windows Server 2008 server can use Active Directory site topology to route DFS requests from clients to the closest available server, increasing response time.

Encrypting File System (EFS)

Native encryption abilities are built into the NTFS filesystem used in Windows Server 2008. By simply checking a checkbox in the Properties sheet for a file, you can easily encrypt and decrypt files and folders to protect their integrity. This feature is particularly useful for mobile computers, which have a greater risk of data loss and capture than traditional corporate desktop machines.

Volume shadow copy

The volume shadow copy feature is perhaps one of the most useful features of Windows Server 2008. The server will take snapshots of files at specific periods during the day, thereby making available a library of previous versions of a file. If a user accidentally overwrites a file, saves an incorrect version, or somehow destroys the primary copy, he can simply click Previous Versions in the Explorer view of the folder and access a shadow copy version.

Windows Search Service

The Windows Search Service, new to Windows Server 2008, catalogs and indexes the contents of server hard disks, enabling users to search in files in different formats and languages for the data they need. The engine has been enhanced over several revisions of the product to accelerate the search process and to use less processor time when cataloging and indexing files.

In this chapter, you will find complete coverage of Windows Server 2008 file services—folder sharing, permissions, shadow copies, DFS, and backup strategies, techniques, and procedures. You will also become familiar with a user service known as roaming profiles, which allows your users' preferred desktop settings to travel with them to any workstation in the network they might be using.


setting_up_file_sharing_services.html

3.2. Setting Up File Sharing Services

Adding a file server role to a machine involves the following:

Configuring the machine as a file server

This process involves turning on file sharing and creating the first shared folder. Windows also creates a few of its own shares by default, which I'll discuss in more detail as the chapter progresses.

Establishing disk space limits by enabling disk quotas, if necessary

Disk quotas are a simple way to limit and control the amount of disk space your users take up with their data. Quotas monitor and limit a user's disk space on a per-partition or per-volume basis; quotas do not stretch across multiple disks. The wizard can configure Windows to apply default quota settings that you select to any new users of any NTFS filesystem. This step is not required to set up file sharing services, but you might find the feature useful. And there is another way of managing quotas—through the File Server Resource Manager, where you can enable per-folder quotas and further limiting by file-type filters.

Setting up Storage Utilization Monitoring

With Storage Utilization Monitoring, you can instruct Windows Server 2008 to keep tabs on how much disk capacity is being used on volumes and to generate reports to the administrator based on predefined thresholds. These reports can be simple alerts, or they can detail large files in order by owner, group, and so on, helping you pinpoint potential targets for archival or deletion in order to free up disk space.

Turning on the Windows Search Service

The Windows Search Service reads the contents of most files on the server and makes a catalog of their contents for easy search and retrieval at later points in time. Because the user interface for the Add Roles Wizard presents this option, I mention it here, but I cover it in detail in Chapter 13.

Installing management tools

The Add Roles Wizard will, when you first set up the file server role on each Windows Server 2008 machine, add the File Services component to Server Manager, allowing you easy access to share and storage management features and the classic Disk Management console.

Creating shared folders and setting share permissions for each folder

Finally, you'll want to create the shared folders and apply permissions to them. After all, that's why you started the process, right?

To configure a machine as a file server, open Server Manager from the Start menu, click Roles, select Add Roles from the right pane, and walk through the Add Roles Wizard. Click Next off the introductory screen, select File Services from the list of available roles, and click Next. You'll then see the Introduction to File Services wizard, as shown in Figure 3-1.

Figure 3-1. The Introduction to File Services screen

Once you click Next off this introductory screen, you'll be presented with the Select Role Services screen, as shown in Figure 3-2.

Figure 3-2. The Select Role Services screen

Here, you can select the different services that fall under the broad "role" definition of a file server. The File Server role at the top of the list is required; check that, and then select the various subcomponents that you need. Do note that the Indexing Service is a relic from Windows XP and Windows Server 2003 and should only be used in very specific scenarios; the new Windows Search Service has tremendously improved performance and search accuracy features and replaces the Indexing Service for most any search function that you will encounter. Finally, the Services for Network File System option installs NFS support, which is useful in a mixed environment where machines running Linux, any flavor of Unix, and in some cases, Mac OS X, need to access files stored on a network share.

You can't run the Indexing Service and the Windows Search Service on the same machine.

Once you have selected the subcomponents you want, click Next. (For the purposes of this walkthrough, select File Server, File Server Resource Manager, and Windows Search Service.) You'll then see the Configure Storage Utilization Monitoring screen, as shown in Figure 3-3.

Figure 3-3. The Configure Storage Utilization Monitoring screen

On this screen, you can take advantage of a new feature introduced in Windows Server 2003 R2 that allows you to ask Windows to proactively look at disk capacity and, specifically, the amount of free space available on a particular volume, analyze what is occupying the space that is used, and generate a preconfigured report to send to the administrator with this information. There will be more on this option later in this chapter as we delve into the File Server Resource Manager in detail; but for now, let's check the box to monitor drive C: and accept the default Files by Owner and Files by File group reports, and click Next.

The Set Reports Options screen appears, where you can choose where to receive the reports generated by the storage monitor. Just accept the defaults for now and click Next.

Now, you will see the Select Volumes to Index for Windows Search Service screen, as shown in Figure 3-4.

Figure 3-4. The Select Volumes to Index for Windows Search Service screen

On this last screen of the wizard, you select the disks or volumes that the Windows Search Service will index. Again, more on the Windows Search Service later in this chapter, but go ahead and select drive C: to index and click Next.

Finally, click the Install button on the confirmation screen, and the panel shown in Figure 3-5 will appear, letting you know Windows Server 2008 is installing the subcomponents of the File Server role as you requested.

Figure 3-5. The Installation Progress screen

3.2.1. Creating a Share Manually

Only members of the Administrators, Server Operators, or Power Users groups can authorize sharing folders by default, though the user interface will allow other users to try to share before presenting them with a User Account Control (UAC) prompt. However, you can configure network-based GP settings to restrict other users and groups from doing so as well. Shares created using Windows Server 2008 are, by default, configured to allow the Authenticated Users group—all users who logged into the machine or network—read-only access. In some previous releases of Windows Server, all users were allowed full control of a share by default, which made for some sticky situations on compromised machines.

Share permissions are different from file- and folder-level permissions, which are more granular. File- and folder-level permissions (also known as NTFS permissions) are covered later in this chapter. If you have a smaller business with fewer employees and less emphasis on security, you might find simple share-level permissions sufficient for protecting content that should be confidential. However, in larger organizations, share-level permissions often don't provide enough manageability and flexibility. Also, the storage and shared folder hierarchies in a large organization are often more complex than in smaller businesses, which makes administering share-level protection on lots of shares very tedious and unwieldy.

Some file sharing options might be limited if simple file sharing is enabled. When this option is enabled on workstations running Windows XP Professional, it is impossible to create, manage, and change permissions on shares remotely because all remote connections authenticate to that computer using the Guest account. It is recommended that, in a business networking environment, you disable simple file sharing. Consult a good Windows XP book for more information on simple file sharing under Windows XP.

You can create a share in three ways: using the Provision a Shared Folder Wizard, using the Explorer GUI, and using the command line. To share a folder using the Provision a Shared Folder Wizard, follow these steps:

  1. Open Server Manager, and in the left pane, expand Roles, File Services, and click on Share and Storage Management.

  2. In the right pane, click the Provision Share link to open the Provision a Shared Folder Wizard.

  3. On the Shared Folder Location page, shown in Figure 3-6, select the folder for sharing. Click Browse to access a directory tree. You can also click the Provision Storage button to launch the wizard to prepare volumes on the system that haven't yet been formatted or allocated, saving you the effort from switching in and out of wizards and control panels to get a drive reader. Once you have a satisfactory location, click Next.

    Figure 3-6. The Shared Folder Location page

  4. The NTFS Permissions page, shown in Figure 3-7, appears. Here, you can elect to change NTFS permissions—those permissions that are in effect on the filesystem level, not just enforced on individual shares—that are now on the object you selected, or to maintain the existing permissions. Select the appropriate radio button, click the Edit Permissions button to bring up the classic permissions assignment dialog if necessary, and then click Next. (There will be more detail on NTFS permissions later in this chapter.)

    Figure 3-7. The NTFS Permissions page

  5. The Share Protocols screen appears, depicted in Figure 3-8. Here, you can choose how the share will appear over the network to clients using various protocols, like SMB (the standard Windows file sharing protocol and the one used by some open source tools like Samba) and NFS (which, as discussed earlier, serves Linux and Unix). Enter the share name and verify the share path, which is denoted as a standard universal naming convention (UNC) path, reflects what you enter. If you didn't install NFS during the Add Roles Wizard, then the NFS option will be grayed out. Click Next when you are finished.

    Figure 3-8. The Share Protocols page

  6. The SMB Settings screen, shown in Figure 3-9, is displayed. The Share Path field is repeated from the previous screen for your reference. In Description (an optional field), type a description of the shared resource. Descriptions can help you as an administrator, as well as your users, understand the purpose of a share. Use something clear, such as "Accounting documents for Q3 1999" or "Inactive Proposals." Under Advanced Settings, you can set a user limit on the share, which is useful for enforcing a software license policy on older software running over the network; you can also decide whether access-based enumeration (ABE) is enabled, which lets you hide from a user shares to which he has no access, rather than displaying them and then throwing up a "deny" dialog box when he tries to access them; and you can choose offline settings. Click the Advanced button to change any of these settings. On the Caching tab of the Advanced dialog, you can configure how the contents in this share are made available to users not currently connected to the network. In Offline setting, specify how you want to make the contents of the shared folder available to users when they are not connected to the network. Click the button to make further tuning adjustments. The three options are fairly self-explanatory: the first option gives the user control over which documents are available offline, the second makes all documents available, and the third prevents any documents from being used offline. Note that checking the "Optimized for performance" checkbox automatically caches documents so that users can run them locally, which is helpful for busy application servers because it lowers overall traffic to and from the server. After you finish, click OK, and then click Next.

    Figure 3-9. The SMB Settings page

  7. The SMB Permissions screen (see Figure 3-10) appears. Here, you can set up the share-level permissions—not the filesystem permissions—that will be enforced for users browsing to the share over the network. Users at the console will still be able to look at the contents of the share unless file-level NTFS permissions restrict them from doing so. As the screen notes, the more restrictive of the share-level permissions and the NTFS permissions will apply.

    The available share-level permissions are as follows.

    All users have read-only access

    Both administrators and normal users will only be able to read files from this share; no writing or modification is allowed.

    Administrators have full access; other users have read-only access

    Members of the Administrators group retain full control over the share, including the ability to set new NTFS file permissions; everyone else has only read privileges. This is the best setting for a share that contains a program to be run over a network.

    Administrators have full access; other users have read and write access

    All users can read and write. Only members of the Administrators group retain the ability to change NTFS file permissions, however.

    Use custom share and folder permissions

    Using the custom permissions feature, you can assign specific permissions and deny permissions to users and groups. This is how a user would remove the default read-only access for all users, a wide-open door, in effect, that might not be desired for sensitive materials.

    Figure 3-10. The SMB Permissions page

  8. The Quota Policy screen, shown in Figure 3-11, appears. You can specify a quota that limits the maximum size that this folder will be allowed to reach. This quota is assigned at the local level—note that the path is now based off a drive local to your server, rather than the UNC network path as in the past few screens. To apply a quota, check the aptly named box, and then choose whether to simply create one quota on this path, or to use a quota template to create quotas on the folders currently in that path as well as any existing subfolders that are yet to be created. There will be more on quotas and quota templates later in this chapter; for the purposes of this demonstration, accept the default 100 MB Limit quota and click Next.

    Figure 3-11. The Quota Policy page

  9. The File Screen Policy screen appears, shown in Figure 3-12. A file screen allows you to prevent some types of files from being stored on a share, which is a great way to keep miscellaneous multimedia files from clogging up your server. In the case of a share that is storing accounting documents, there seems little reason to allow the hosting folder to contain audio and video files. To apply a file screen, check the "Apply file screen" box, and then choose a preconfigured file screen template from the drop-down box. There will be more on file screens and templates later in this chapter; for now, accept the default and click Next.

    Figure 3-12. The File Screen Policy page

  10. The DFS Namespace Publishing screen (shown in Figure 3-13) appears. Here, you can publish your new share to a DFS namespace. More on DFS later—click Next now to move through this screen to the final portion of the wizard.

    Figure 3-13. The DFS Namespace Publishing screen

  11. Finally, the Review Settings and Create Share screen is displayed, as shown in Figure 3-14. Verify the settings that you chose during the wizard and, if they all look good to you, click Create. After a moment, you should receive a green check on the confirmation screen indicating that your share has been successfully provisioned.

Figure 3-14. Review Settings and Create Share screen

3.2.2. Default Shares

Upon installation, Windows Server 2008 creates several default shares that serve various purposes. You can examine these using the Share and Storage Management feature of Server Manager. Open Server Manager, expand the File Services role, and click on Share and Storage Management. Figure 3-15 shows the default screen, which on the Shares tab shows the shares configured on a machine.

Figure 3-15. The Shares tab of Share and Storage Management

Let's step through the default shares and list their function and purpose.

C$ and other similar drive letters

These shares are known as administrative shares, and they provide a quick way for you to access a certain computer over the network and inspect the contents of the drive. Windows Server 2008 creates one of these administrative shares for each local drive in a system. You can't easily get rid of these shares permanently because they are re-created upon reboot if they are not present. You can't adjust the share permissions on them either. Still, they're a handy tool in your toolbox for remote management and troubleshooting.

ADMIN$

This also is an administrative share that maps directly to the location of the Windows Server 2008 system files; it is the same as the %systemroot% environment variable. This is useful for spreading out operating system updates, especially across different operating systems. Recall that Windows 2000 used \WINNT, whereas Windows Server 2008 uses good old \WINDOWS. If you write a script to pass a file to all of these servers, you don't have to account for this difference if you use ADMIN$ on each machine as the location.

IPC$

This share is part of Windows Server 2008's method of sharing resources, not files, with other machines. Any type of remote management function other than sharing files uses this share.

NETLOGON

Mandatory on domain controllers, this share is a place to put logon and logoff scripts, programs, and profile information for users to read and access before they are logged on to the network. It's located at %SystemRoot%\sysvol\domainname\SCRIPTS on the filesystem of the server.

PRINT$

Print drivers that are shared to the network, usually for previous versions of operating systems, are stored in this share and requested by clients at the time of printer installation on the clients. It's located at %SystemRoot%\System32\spool\drivers on the filesystem of the server.

SYSVOL

This is used for internal domain controller operations and shouldn't be modified or deleted. It's located at %SystemRoot%\Sysvol\Sysvol on the local filesystem of the server.

Creating a Hidden Share

You might need to share a resource but not make it publicly known. For example, the Payroll department might need its own file share, but the rest of the company doesn't require access to it, and in the interest of confidentiality, you might want to hide it from public display. You can do this by typing $ as the last character of the shared resource name. Users can map a drive to this shared resource by naming it explicitly (including the $ appended to the end), but the share is hidden in Explorer, in My Computer on the remote computer, and in the net view command on the remote computer.

3.2.3. Publishing Shares to Active Directory

By publishing shares to Active Directory, your users can use the Find feature on the Start menu on their Windows desktops to find remote shares based on their identifier or description. This is handy for using a new piece of simple software that's being run directly from the network. It is equally handy for retrieving an electronic PowerPoint presentation that might have been given earlier in the day. Note that you must use an account with domain administrator or enterprise administrator privileges to publish a share to Active Directory.

To publish a share, follow these steps:

  1. From the Administrative Tools applet in the Control Panel, open Active Directory Users and Computers.

  2. Right-click the appropriate organizational unit (OU).

  3. Select Shared Folder from the New menu.

  4. Enter a name and description of the share.

  5. Enter the path (network location) to the folder you want to share, and then click Finish.

The share has now been added to the directory.


ntfs_file_and_folder_permissions.html

3.3. NTFS File and Folder Permissions

File- and folder-level permissions are one of the most dreaded and tedious, but necessary, tasks of system administration. However, they are significant in terms of protecting data from unauthorized use on your network. If you have ever worked with Unix permissions, you know how difficult they are to understand and set: complex CHMOD-based commands, with numbers that represent bits of permission signatures—it's so easy to get lost in the confusion. Windows Server 2008, on the other hand, provides a remarkably robust and complete set of permissions, more than any common Unix or Linux variety available today. It's also true that no one would argue how much easier it is to set permissions in Windows than to set them in any other operating system. That's not to say, however, that Windows permissions are a cinch to grasp; there's quite a bit to them.

3.3.1. Standard and Special Permissions

Windows supports two different views of permissions: standard and special. Standard permissions are often sufficient to be applied to files and folders on a disk, whereas special permissions break standard permissions down into finer combinations and enable more control over who is allowed to do what functions to files and folders (called objects) on a disk. Coupled with Active Directory groups, Windows Server 2008 permissions are particularly powerful for dynamic management of access to resources by people other than the system administrator—for example, in the case of changing group membership. (You'll meet this feature of Active Directory, called delegation, in Chapter 5.)

Table 3-1 describes the standard permissions available in Windows.

Table 3-1. Windows Server 2008 standard permissions
Type | Description
Read (R) | Allows user or group to read the file.
Write (W) | Allows user or group to write to the contents of a file or folder and to create new files and folders. It is possible to have write permissions without read permissions.
Read and Execute (RX) | Allows user or group to read attributes of a file or folder, view its contents, and read files within a folder. Files inside folders with RX rights inherit the rights onto themselves.
List Folder Contents (L) | Similar to RX, but files within a folder with L rights will not inherit RX rights. New files, however, automatically get RX permissions.
Modify (M) | Allows user or group to read, write, execute, and delete the file or folder.
Full Control (FC) | Similar to M, but also allows user or group to take ownership and change permissions. Users or groups can delete files and subfolders within a folder if FC rights are applied to that folder.

The following key points should help you to understand how permissions work:

  • File permissions always take precedence over folder permissions. If a user can execute a program in a folder, she can do so even if she doesn't have read and execute permissions on the folder in which that program resides.

  • Similarly, a user can read a file for which he explicitly has permission, even if that file is in a folder for which he has no permission, by simply knowing the location of that file. For example, you can hide a file listing employee Social Security numbers in a protected folder in Payroll to which user Mark Jones has no folder permissions. However, if you explicitly give Mark read rights on that file, by knowing the full path to the file, he can open the file from a command line or from the Run command on the Start menu.

  • Permissions are cumulative: they "add up" based on the overall permissions a user gets as a result of her total group memberships.

  • Deny permissions always trump Allow permissions. This applies even if a user is added to a group that is denied access to a file or folder that the user was previously allowed to access through his other memberships.

Windows also has a bunch of permissions labeled special permissions, which, simply put, are very focused permissions that make up standard permissions. You can mix, match, and combine special permissions in certain ways to make standard permissions. Windows has "standard permissions" simply to facilitate the administration of common rights assignments.

There are 14 default special permissions, shown in Table 3-2. The table also shows how these default special permissions correlate to the standard permissions discussed earlier.

Table 3-2. Windows Server 2008 special permissions
Special permission | R | W | RX | L | M | FC
Traverse Folder/Execute File | X | X | X | X
List Folder/Read Data | X | X | X | X | X
Read Attributes | X | X | X | X | X
Read Extended Attributes | X | X | X | X | X
Create Files/Write Data | X | X | X
Create Folders/Append Data | X | X | X
Write Attributes | X | X | X
Write Extended Attributes | X | X | X
Delete Subfolders and Files | X
Delete | X | X
Read Permissions | X | X | X | X | X
Change Permissions | X
Take Ownership | X
Full Control | X | X | X | X | X | X

The default special permissions are further described in the following list.

Traverse Folder/Execute File

Traverse Folder allows you to access a folder nested within a tree even if parent folders in that tree deny a user access to the contents of those folders. Execute File allows you to run a program.

List Folder/Read Data

List Folder allows you to see file and folder names within a folder. Read Data allows you to open and view a file.

Read Attributes

Allows you to view basic attributes of an object (read-only, system, archive, and hidden).

Read Extended Attributes

Allows you to view the extended attributes of an object—for example, summary, author, title, and so on for a Word document. These attributes will vary from program to program.

Create Files/Write Data

Create Files allows you to create new objects within a folder; Write Data allows you to overwrite an existing file (this does not allow you to add data to existing objects in the folder).

Create Folders/Append Data

Create Folders allows you to nest folders. Append Data allows you to add data to an existing file, but not delete data within that file (a function based on file size), or delete the file itself.

Write Attributes

Allows you to change the basic attributes of a file.

Write Extended Attributes

Allows you to change the extended attributes of a file.

Delete Subfolders and Files

Allows you to delete the contents of a folder regardless of whether any individual file or folder within the folder in question explicitly grants or denies the Delete permission.

Delete

Allows you to delete a single file or folder, but not other files or folders within it.

Read Permissions

Allows you to view NTFS permissions on an object, but not to change them.

Change Permissions

Allows you to both view and change NTFS permissions on an object.

Take Ownership

Allows you to take ownership of a file or folder, which inherently allows the ability to change permissions on an object. This is granted to administrator-level users by default.

You also can create custom combinations of permissions, known as special permissions, other than those defined in Windows Server 2008 by default; I cover that procedure in detail later in this section.

3.3.2. Setting Permissions

Setting permissions is a fairly straightforward process that you can perform through the GUI. To set NTFS permissions on a file or folder, follow these steps:

  1. Open Computer or Windows Explorer and navigate to the file or folder on which you want to set permissions.

  2. Right-click the file or folder, and select Properties.

  3. Navigate to the Security tab.

  4. Click the Edit button to change permissions.

  5. In the top pane, add the users and groups for whom you want to set permissions. Then click each item, and in the bottom pane, grant or disallow the appropriate permissions.

Figure 3-16 shows the process of assigning write rights to user Jonathan Hassell for a specific file.

Figure 3-16. Granting permissions on a folder to a user

If a checkbox under Allow or Deny appears gray, this signifies one of two things: that the permissions displayed are inherited from a parent object (I discuss inheritance in more detail in the next section), or that further special permissions are defined that cannot be logically displayed in the basic Security tab user interface. To review and modify these special permissions, simply click the Advanced button. On this screen, by using the Add button, you can create your own special permissions other than those installed by default with Windows Server 2008. You also can view how permissions will flow down a tree by configuring a permission to affect only the current folder, all files and subfolders, or some combination thereof.

3.3.3. Inheritance and Ownership

Permissions also migrate from the top down in a process known as inheritance. This allows files and folders created within already existing folders to have a set of permissions automatically assigned to them. For example, if a folder has RX rights set, and you create another subfolder within that folder, users of the new subfolder will automatically encounter RX permissions when they try to access it. You can view the inheritance tree by clicking the Advanced button on the Security tab of any file or folder. This will bring up the screen shown in Figure 3-17, which clearly indicates the origin of rights inheritance in the Inherited From column.

Figure 3-17. Viewing the origin of permissions inheritance

You can block this process by clicking the Edit button and unchecking the "Include inheritable permissions from this object's parent" checkbox on the screen in Figure 3-17. Any children of the folder for which you've stopped inheritance will receive their permission from that folder, and not from further up the folder tree. Also, if you ever decide to revert to standard permissions inheritance on an object for which you've blocked the process, simply recheck the checkbox. Custom permissions that you've defined will remain, and all other permissions will automatically trickle down as usual.

There also is a concept of ownership. The specified "owner" of a file or folder has full control over the file or folder and therefore retains the ability to change permissions on it, regardless of the effect of other permissions on that file or folder. By default, the owner of the file or folder is the object that created it. Furthermore, there is a special permission called Take Ownership that an owner can assign to any other user or group; this allows that user or group to assume the role of owner and therefore assign permissions at will. The administrator account on a system has the Take Ownership permission by default, allowing IT representatives to unlock data files for terminated or otherwise unavailable employees who might have set permissions to deny access to others.

To view the owner of a file, click the Owner tab on the Advanced Permissions dialog box. The current owner is displayed in the first box. To change the owner—assuming you have sufficient permissions to do so—simply click Edit, acknowledge the UAC prompt, select a user from the white box at the bottom, and click OK. Should the user to whom you want to transfer ownership not appear in the white box, click Other Users and Groups, then click Add, and then search for the appropriate user. You also can elect to recursively change the owner on all objects beneath the current object in the filesystem hierarchy. This is useful in transferring ownership of data stored in a terminated employee's account. To do so, select the checkbox for "Replace owner on subcontainers and objects" at the bottom of the screen. Click OK when you've finished. (This operation can take a while.)

3.3.4. Determining Effective Permissions

As a result of Microsoft's inclusion of Resultant Set of Policy (RSoP) tools in Windows Server 2008, you can now use the Effective Permissions tab on the Advanced Permissions screen to view what permissions a user or group from within Active Directory, or a local user or group, would have over any object. Windows examines inheritance, explicit, implicit, and default access control lists (ACLs) for an object, calculates the access that a given user would have, and then enumerates each right in detail on the tab. Figure 3-18 demonstrates this.

Figure 3-18. The Effective Permissions tab

The Effective Permissions display has two primary limitations. First, it does not examine share permissions. It concerns itself only with NTFS filesystem-based ACLs, and therefore, only filesystem objects. And second, it functions only for users and groups in their individual accounts. It will not display correct permissions if a user is logged in through a remote access connection or through Terminal Services, and it also might display partially inaccurate results for users coming in through the local Network service account. Although these are reasonably significant limitations, using the Effective Permissions tool can save you hours of head scratching as to why a pesky Access Denied message continues to appear. It's also an excellent tool to test your knowledge of how permissions trickle down, and how allow and deny permissions override such inheritance at times.

3.3.5. Access-Based Enumeration

ABE is a great feature that is long overdue to be bundled with Windows Server. Essentially, this feature removes any access-denied errors for users by showing them only what they're allowed to access—if they don't have permission to use a file, browse a folder, or open a document, then it won't appear in whatever file management tool they're using at the time. This also closes an arguably significant security hole, in that if users can see folders they're not able to access, it might prompt hacking attempts or other tries to circumvent security, whereas one is less likely to hack what one doesn't know is there. Or so the theory goes.

It looks like the real drawbacks at this point are:

  • ABE only works when you're connecting via UNC to a network share. It won't work for local files. Of course, this doesn't seem like a terrible drawback since not many users are browsing locally on Windows Server 2008 machines, and those that are would hopefully be administrator-level people anyway.

  • You do need to be running Windows Server 2008 or Windows Server 2003 with Service Pack 1. Other server operating systems on the network won't be able to offer ABE, making for an inconsistent user experience.

To apply ABE to a shared folder, open Server Manager, expand Roles and File Services, and then click Share and Storage Manager. From the middle pane, double-click on the shared folder for which you want to enable ABE, click the Advanced button, and check the "Enable access-based enumeration" box.

After you do this, what will your users see? Nothing—that is, nothing that they don't have permission to access.

3.3.6. Auditing

Object access auditing is a way to log messages concerning the successful or unsuccessful use of permissions on an action against an object. Windows Server 2008 writes these messages to the Security Event Log, which you can view using the Event Viewer in the Administrative Tools applet inside the Control Panel. First, though, you must enable auditing at the server level and then enable it on the specific files and folders you want to monitor.

You can enable auditing overall in one of two ways—either on a system-by-system basis by editing the local system policy, or on selected machines (or all machines) participating in a domain through GP. In this section, I'll focus on editing local system policies. To begin, follow these steps:

  1. Select Start rightwards double arrow All Programs rightwards double arrow Administrative Tools, and click Local Security Policy.

  2. Expand Local Policies in the lefthand navigation pane, and click Audit Policy.

  3. Double-click Audit Object Access.

  4. To enable auditing, select which events—a successful access of a file or folder, an unsuccessful attempt, or both—to audit, and then click OK.

  5. Close the Local Security Policy box.

Audit events for the appropriate types of accesses will now be written to the Security event log as they happen.

Here is a quick summary of enabling auditing through domain-based GPs: create a new GPO linked to a selected container of machines, and navigate through Computer Configuration, Windows Settings, Security Settings, and Local Policies to Audit Policy. Select the appropriate events, and click OK. Give the domain controller a few minutes to replicate the policy to other domain controllers in the domain, and then refresh the policy on your client machines through gpupdate /force or by rebooting the machines.

Now, select the objects within the filesystem you want to audit and right-click them. Choose Properties and click the Security tab in the resulting dialog box. Then click Advanced and select the Auditing tab. You'll be presented with a screen much like that shown in Figure 3-19.

Figure 3-19. Enabling auditing on an object

Assigning audit objects in Windows is much like assigning permissions. Simply click Edit, and then click Add, and a dialog will appear where you can enter the users to audit. Note that audit instructions work for both users and groups, so although you might not care what members of the Administrators group do, those in Finance might need a little more monitoring. Click OK there, and then select which actions—a successful object access or a failed use—of an event should be written to the log. You can easily specify different auditing settings between the various permissions, saying that you don't want to know when someone fails to read this object but you want to know whenever someone adds to it. Once you're finished, click OK and then Apply to save the settings.

Auditing is a helpful way to keep track of what's happening on your file shares.


the_file_server_resource_manager.html

3.4. The File Server Resource Manager

Windows Server 2008 includes the File Server Resource Manager, an integrated console that contains various tools and reporting functions so that you can determine, control, and administer the amount and kind of data stored on your file servers. FSRM provides a single and convenient place for you to configure quotas on folders and volumes, screen for unacceptable types of files, and generate comprehensive reports on exactly where your disk space is going.

To access the FSRM, open Server Manager, expand the File Services role in the left pane, expand Share and Storage Management, and click File Server Resource Manager. The default screen is shown in Figure 3-20.

Figure 3-20. The File Server Resource Manager console

3.4.1. Configuring the FSRM

The first step in using the FSRM is configuring some options that will be used by the console. In the Actions pane, click the Configure Options link, and you'll see a screen like Figure 3-21.

Figure 3-21. Configuring FSRM options

The FSRM is designed to send email alerts and reports via email; on the Email notifications tab, enter the outgoing SMTP server (either through an installed SMTP service on the local machine or another mail server provided either by your organization or your ISP), and the To and From addresses. You can also choose to send a test email by clicking on that button.

Figure 3-22 shows the Notification Limits tab.

Figure 3-22. The Notification Limits tab

On this screen, you can set some limits as to how often the FSRM and Windows Server 2008 send notifications for similar events. If the FSRM detects, say, a quota exceeded event, and the user continues to try to exceed the quota, with these notification limits the FSRM will wait a certain amount of time before sending an email notification, writing an event log entry, and sending command and report notifications. Configure your limit, in minutes, for each of these notification types.

Figure 3-23 shows the Storage Reports tab.

Figure 3-23. The Storage Reports tab

On this tab, you can specify your preferences for each report that can be generated by the FSRM. For example, if you highlight the File Screening Audit report and click the Edit Parameters button, you'll be able to select which users are included in the report. To take a look at all of the parameters for the reports, click the Review Reports button. The defaults work pretty well here, but as you'll see as we dig further into the FSRM, you may want to alter them slightly to customize the reports for your environment.

Figure 3-24 shows the Report Locations tab.

Figure 3-24. The Report Locations tab

On this screen, choose where to save each type of report that the FSRM can generate. You can store them either on the local drive or on a network volume.

Figure 3-25 shows the File Screen Audit tab.

Figure 3-25. The File Screen Audit tab

Here, you can tell the FSRM whether to log screening activity in the auditing database. If you don't intend to use file screening reports, then clearing this checkbox will give you a slight performance improvement since the extra logging isn't required.

3.4.2. Configuring Quotas with the FSRM

It's more straightforward to configure quotas using the FSRM, as the interface is cleaner and the rules a bit more flexible. Using the FSRM, you can create quotas for specific folders or volumes and configure the notifications generated by Windows when those quotas are exceeded. FSRM improves on the disk-based quota feature, covered in the next major section in this chapter, and takes it a couple of steps further by allowing you to customize "auto quotas" that automatically apply to both existing and future folders, and define quota templates that can be used anywhere in an organization's IT infrastructure.

Let's start off with simply applying a quota to a single folder. To do so, within the FSRM, double-click the Quota Management item in the middle pane, and then double-click on Quotas. From the right pane, click the Create Quota link. You'll see a screen much like Figure 3-26.

Figure 3-26. The Create Quota screen

Enter the path to the folder in the top box, or click Browse to find it graphically. Select "Create quota on path," and then choose either a pre-existing template, which offers some preconfigured limits, or choose the "Define custom quota properties" option and click the Custom Properties button. If you select the latter option, you'll be prompted with the Quota Properties screen, where you can enter the space limit, define whether the quota is hard or soft, and add different notification thresholds. Click OK when you're done, and the summary window on the Create Quota screen will show your selections. If all looks good, then click Create, and the quota placement is complete.

That process works well for one-off quota needs, but suppose that you want to centralize quota management across all folders and volumes. The best way to do that is to use the quota template facility with FSRM. By applying quota templates to folders, you can simply make one change to the template's configuration, and all folders to which that template has been applied will reflect the change. Think of it as having a "group" of quotas to make administration simpler.

To make a quota template, double-click the Quota Management item in the middle pane of the FSRM and then double-click on Quota Templates. From the right pane, click the Create Quota Template link. You'll see a screen much like Figure 3-27.

Figure 3-27. The Create Quota Template screen

In the top drop-down box, you can select an existing template and copy the settings from it into the new template you're creating, which is a great timesaver when you need to make just a few minor changes. Otherwise, enter the template name, a friendly name if you wish, and then select the space limit and the severity of the limit. You can also configure the specific thresholds for notification when users hit a quota. Click Add to define a new notification; you will see the Add Threshold screen appear, as shown in Figure 3-28.

Figure 3-28. The Add Threshold screen

Note the first box, called "Generate notifications when usage reaches (%)." In this box, specify the actual threshold at which the action you're going to define on these screens will take place. Now, the most common notification administrators send is an email message, both to the user who exceeded the limit and to the administrator himself. On the E-mail Message tab, you can check to whom to send such messages, and also change the text of the message. On the Event Log tab, you can customize the text of a warning event that will be sent to the Event Log, and on the Command tab you can define a script or program that will be run when a user exceeds the threshold you set. Finally, on the Report tab, you can tell the FSRM to automatically generate a storage report (covered a bit later in this section) when the quota is exceeded. Each of these tabs has a straightforward interface. Click OK when you've finished, and then OK again to finish creating the template.

Once the template is in place, you can use it to apply quotas to specific folders. Then when you need to increase the quota on all folders using a given template, for example, you can simply edit the space limit field within the template definition, and all folders will then reflect the new limit.

3.4.3. Screening for File Types

Another useful capability of the FSRM is the ability to screen for certain file types and prevent them from being stored on your file servers. If your storage resources are limited and space is at a premium, there probably isn't a legitimate reason to store tons of MP3 and WMA files within your user's home directories. Even if you have plenty of "first line" space, these files are probably part of your backup set, and if they are you're likely needlessly wasting precious backup media storing the latest Mariah Carey CD in an off-site location in case disaster strikes. File screening can help keep this type of waste to a minimum.

FSRM is pretty flexible. For example, it allows for the following scenarios:

  • You can prevent all music files from being stored on a server, except for those files with specific filenames (your marketing theme, or a media file relating to an upcoming commercial) or files placed on the server by a certain person or group within your company.

  • You can get a pre-warning emailed to you whenever a suspicious script or EXE file is stored on a shared volume, thus alerting you to a possible security breach or virus infestation.

  • You can write notifications of screening alerts to the event log, so if you have an event log consolidation program running on all of your servers, you can see the screening reports directly from them.

Like quotas, the file screening feature offers the capability to create file groups, which are simply collections of file extensions with like characteristics (for example, a media file group would contain MP3, WMA, OGG, and others) that can be used to specify included or excluded files in a particular screen, and file screening templates, which are ready-to-use rules for screening different types of files. Again, by using templates extensively, you can make changes to all servers using file screening with just one or two modifications to the template.

3.4.3.1. Defining a file group

You can define a file group within the FSRM. To do so:

  1. In the right pane of Server Manager, expand Roles, File Services, Share and Storage Management, File Server Resources Manager, and File Screening Management.

  2. Right-click File Groups, and then click "Create file group."

  3. Type a name for the file group.

  4. In the "Files to include" box, enter a filename pattern (like *.exe) for files you'd like to include in the group, and click Add. In the "Files to exclude" box, enter a pattern for files you'd like to exclude.

  5. Click OK.

3.4.3.2. Creating a file screen

To create a single file screen:

  1. In File Screening Management, right-click File Screens, and then click "Create file screen."

  2. The Create File Screen box appears. Figure 3-29 shows this. Enter the path to which the file screen will apply (this includes subfolders of the specified folder by default).

    Figure 3-29. The Create File Screen dialog box

  3. Select the "Define custom file screen properties" option, and then click Custom Properties.

  4. The File Screen Properties screen appears. You can elect to use an existing template, or create a custom screen.

  5. Under "Screening type," select whether to apply active screening, which prevents users from saving files that are members of blocked file groups and generates notifications of such actions; or passive screening, which sends notifications but does not prevent users from saving blocked files.

  6. Under File Groups, select each file group that you want to include in the screen. To select the checkbox for the file group, click the file group label twice.

  7. To configure email notifications for the file screen, set the following options on the E-mail Message tab:

    • Select "Send email to the following administrators" in order to notify said persons when an attempt is made to save an unauthorized file, and enter the administrative accounts that will receive notifications. To enter multiple accounts, separate them with semicolons.

    • Select "Send email to the user who attempted to save an unauthorized file" if you want to alert the user that he almost breached policy.

    • You can also edit the subject line and message body. To insert additional variables in the text, click Insert Variable and then choose the appropriate variable as listed on the screen.

  8. On the Event Log tab, select the "Send warning to event log" checkbox, and edit the default log entry. Both of these tasks are optional. In addition, on the Command tab, you can tell Windows to run a program or script when a violation occurs, and on the Report tab, you can elect to automatically generate a report upon a violation.

  9. Click Create to save the file screen.

Note that when you're creating a "one-off" file screen, you have the option to save it as a file screen template, meaning that (a) it can be reused later if you need to apply the same settings to a different target, and (b) FSRM remembers the link between the target of your one-off screen and the newly created template—in essence, it creates the template and then applies the screen, so you get the advantages of template use.

3.4.3.3. Creating an exception to a screen

A file screen exception essentially overrides any screening that would otherwise apply to a folder and its subfolders—it basically blocks rules derived from a parent folder. You can't, however, apply an exception to a folder that already has a file screen applied: you need to either apply the exception to a subfolder or make changes to the existing screen.

To create an exception to a screen:

  1. In File Screening Management, right-click File Screens, and then click "Create file screen exception."

  2. This opens the Create File Screen Exception dialog box. Enter the path to which the exception will apply.

  3. Under "File groups," select each file group that you want to include in the exception.

  4. Click OK.

3.4.4. Generating Storage Reports

The FSRM includes a great facility to get a picture of exactly how your storage is behaving. You can look at trends in how your disk space is being occupied and see alerts and notifications of users who are going over quota or attempting to save files that are in violation of your file screening policies. You can schedule these reports to be generated automatically on a time rotation that you specify, or you can create ad hoc reports as you see fit.

The following reports are available out of the box:

  • Duplicate files

  • File screening audit

  • Files by file group

  • Files by owner

  • Large files

  • Least recently accessed files

  • Most recently accessed files

  • Quota usage

To generate an ad hoc report:

  1. Right-click the Storage Reports Management node under the FSRM entry in the left pane, and click "Generate reports now."

  2. The Storage Reports Task Properties dialog box appears as shown in Figure 3-30. Add each volume or folder that you want to report on to the Scope box, and in "Report data," select and format each report that you want to include. To edit the parameters of any particular report, highlight the report label and click the Edit Parameters button. When you finish editing the parameters, click OK.

  3. Back on the Storage Reports Task Properties screen, select each file format that you want to save the report in.

  4. The Delivery tab allows you to elect to have the report emailed to administrators once it has been generated. To enable this, check the "E-mail report to the following administrators" box and then enter each email address that you want the report delivered to. To enter multiple accounts, separate each with semicolons.

  5. Click OK when you're finished, and then choose whether to open the reports when they're finished or to look at them later.

Figure 3-30. The Storage Reports Task Properties screen

You can also schedule reports to be created, which allows you to monitor your storage resources on a regular schedule. To create a scheduled report:

  1. Right-click the Storage Reports Management node under the FSRM entry in the left pane, and click "Schedule a new report task."

  2. Follow steps two through four in the previous procedure to define the properties of the report.

  3. Click the Schedule tab, then the Create Schedule button, and then the New button on the resulting screen, to define a schedule. This is shown in Figure 3-31.

  4. Select the interval at which to generate the report (daily, weekly, monthly, or one-time reports are supported).

  5. The options below the interval box morph themselves depending on your selected interval. Enter this information as necessary.

  6. Enter the time of day to generate the report under "Start time."

  7. Click OK to save the schedule.

  8. Click OK to save the task.

Figure 3-31. Creating a scheduled report task


disk-based_quotas.html

3.5. Disk-Based Quotas

Windows 2000 first introduced the disk-based quota feature, allowing an administrator to define a limit or set of limits on the consumption of disk space by individual users. Windows Server 2008's quota management features some interesting properties:

  • Windows Server 2008 can distinguish between volumes, so you can set different quotas on different volumes to perhaps segregate types of data, or to offer a disk exclusively to a set of users for their daily work.

  • You can assign disk-based quotas on mapped drives as long as the physical volumes to which the mapped drives point were created with Windows 2000 Server or Windows Server 2003 or were upgraded to either of the later versions from Windows NT 4.0.

  • Unlike some third-party software programs, Windows Server 2008 does not allow grace writes. That is, some software allows a user to continue an operation—say, a file copy process—even if during the middle of that operation the disk-based quota is reached. Windows Server 2008 does not allow this; it will cut off the operation when the quota is reached.

As usual, though, neat features always contain weak points. First, quotas are supported only on disks formatted with the NTFS filesystem. This isn't too surprising because most progressive filesystem features aren't available under the various flavors of FAT. Second and perhaps more disturbing is that, due to an architectural limitation, disk-based quotas (those assigned on the volume level, that is) can be added only to individual users. This creates quite a headache, as most other network operating systems allow you to set a default quota based on group membership. In this manner, all normal users could have 500 MB, power users and executives could have 1.5 GB, and administrators could have unrestricted space. Alternatively, payroll users could have 250 MB, while the sales team with their myriad PowerPoint presentations might need 1 GB a piece. Alas, Windows Server 2008 doesn't support this by default out of the box at the disk level, but later in this section I'll show you a problematic but workable way around this limitation.

3.5.1. Setting Default Disk Quotas

To set up default disk quotas through Windows Explorer, follow these steps:

  1. Open Computer, right-click the drive for which you want to enable quota support, and select Properties.

  2. Navigate to the Quota tab.

  3. Make sure the "Enable quota management" checkbox is checked. If it's not, quota support is not enabled. If you want to continue, check this checkbox.

  4. Choose one or more of the following selections based on your needs:

    Deny disk space to users exceeding quota limit

    If you check this checkbox, when users reach their disk-based usage limit, Windows returns an "insufficient disk space" error, thereby preventing them from writing more data until they either change or remove files to make more space available. To individual application programs, where this behavior is handled in various ways, it appears that the volume is full. If the checkbox is not checked, users can exceed their disk-based quota limit, which makes this an effective way to simply track disk usage by user and not enforce limits on storage space use.

    Limit disk space to

    Here, specify the amount of space newly created users of the disk can fill, and the amount of space that can be used before alerts are recorded in the event log (known as the soft quota, or warning level). You can use decimal values and varying units to fine-tune your settings.

    Log event when a user exceeds his quota limit

    If quotas are enabled, disk event entries are recorded hourly in the system event log when a user reaches his hard quota, or official limit.

    Log event when a user exceeds her warning level

    If quotas are enabled, disk event entries are recorded hourly in the system event log when a user reaches her soft quota, or warning level.

3.5.2. Configuring Individual Quota Entries

You might find it useful to set individual disk-based quotas for specific users that exempt them from a more limiting default quota you might have configured. You can set these individual quota entries through the GUI by clicking the Quota Entries button on the Quota tab under the Properties sheet of the disk in question. In the Quota Entries for Drive box, select Quota from the pull-down menu and click New Quota. Figure 3-32 shows this.

Figure 3-32. Entering a new disk quota entry

Select the user to which to apply the new disk-based quota, and in the box, configure the restrictions on the user's space.


using_offline_files_and_folders.html

3.6. Using Offline Files and Folders

Offline Files and Folders is a neat feature, offered for the first time in Windows 2000 Professional, which synchronizes files and folders when you connect to and disconnect from the network. Similar to the Windows 95 Briefcase, except much more versatile and automated, Offline Files and Folders caches a copy of selected files and folders on a computer's hard drive. When that computer becomes disconnected from the network for any reason, Windows reads the cache on the machine and intercepts requests for files and folders inside the cache. The end user can still open, save, delete, and rename files on network shares because Windows is fooling him into thinking that everything is still on the network and not in the cache. Windows records all changes, and the next time an appropriate network connection is detected, the changes are uploaded to the network and the cache, and the actual network file stores are synchronized.

What happens when a common network share—call it Contracts—is modified by two different users while they're offline? In this instance, it's really a case of who gets connected first. User A will synchronize with the network, and his modified version of the file will be the one now stored live on the network volume. When User B attempts to synchronize, Windows will prompt him to choose whether to keep the existing version (the one that User A modified) or to overwrite it with the one that User B has worked on.

This has obvious advantages for mobile users. In fact, as I write this, I am sitting at a rest stop on Interstate 20 outside Augusta, Georgia, taking an extended break from a road trip. To open this file, I navigated through Windows Explorer to my regular network storage location for this book and its assorted files. I noticed no difference between my office and this car, at least as far as Windows' interface to the network was concerned. However, tomorrow, when I am back in my office, I will plug the Ethernet cable into my laptop, and Windows will synchronize any files I modified in that folder with the files on my servers in the office. Using this feature, I always have the latest file with me wherever I am, be it in the office or on the road, and I don't really have to consciously think about it. But there's also a plus side that you might not have considered: if you enable Offline Files on regular desktop machines, not just mobile laptops, you create a poor man's fault-tolerant network. (The price you pay for such fault tolerance is bandwidth.) That is, when the network connection disappears, Windows doesn't care if you are using a big mini-tower system or an ultra-thin notebook. So, your desktop users still can safely and happily use network resources, even if the network has disappeared, and you as the administrator can rest assured in knowing whatever the users do will be updated safely on the network when it reappears. Now, of course, this is no substitute for a well-planned network with quality components, but in a pinch, offline folders do well to reduce user panic and wasted help-desk calls.

3.6.1. Enabling Offline Files

To make a server's share contents available offline using the Control Panel, follow these steps:

  1. Open Server Manager.

  2. In the left pane, expand Roles, File Services; click Share and Storage Management.

  3. In the list of shares in the middle pane (make sure you've selected the Shares tab), right-click the share in question and select Properties.

  4. On the Sharing tab, look under the Offline Settings field to determine the current status of caching on this share. To change it, click the Advanced button, and click the Caching tab.

  5. Select the appropriate settings (described shortly), and then click OK twice when finished.

To make a share's contents available offline using Windows Explorer, follow these steps:

  1. Open Windows Explorer.

  2. Right-click the shared folder in question, and select Properties.

  3. Click the Sharing tab, and then click the Advanced Sharing button, acknowledging the UAC prompt if necessary.

  4. Click the Caching button.

  5. Select the appropriate settings, and then click OK when finished.

In both of these processes, the individual offline availability configuration settings are as follows:

  • The first option gives the user control over which documents are available offline.

  • The second option makes all documents available.

  • The third option prevents any documents from being used offline.

You can enable Offline Files and Folders on Windows 2000 and Windows XP clients by opening any folder and selecting Folder Options from the Tools menu. Then click the Offline Files tab, and select the checkbox called Enable Offline Files.

3.6.2. Points to Remember

Be careful to note that offline access is allowed by default when creating a new share. If you have sensitive data stored on a share accessible by mobile computers, that data can represent a real business intelligence risk if a mobile user's laptop is stolen or compromised. Consider disabling offline access for shares that contain potentially private corporate information not suitable for storage on computers that leave the corporate campus.

Also, beware of the false sense of security that Offline Files and Folders gives the user. If I were to go to the airport without plugging my laptop into the network right before I left, I certainly would not have the latest version of any files I had modified since I last connected the laptop to the network; I'm potentially missing many more files that perhaps had been added since that time as well. A good rule of thumb, even though it's low-tech, is to plug in the laptop right before you leave the office, and then disconnect the laptop and reboot. This enables you to synchronize for a final time and to verify that the utility is working correctly. It's a lot better than arriving at a conference without the PowerPoint slides that comprise a significant portion of your talk. (Not that I know from experience....)

Note that checking the Optimized for Performance checkbox in the Windows GUI automatically caches documents so that users can run them locally, which is helpful for busy application servers because it lowers overall traffic to and from the server.


using_previous_versions.html

3.7. Using Previous Versions

Previous versions (née shadow copies) are a relatively new technology within Windows products that enable a server to take snapshots of documents on a disk to record their states at certain points in time. If a user accidentally deletes or otherwise overwrites a file, she can open a version the server saved earlier in time, thereby eliminating the need to either re-create her work or contact the help desk to get them to restore the file from the most recent backup. When the previous versions feature is enabled on a disk, clients connecting to a share on that disk will be able to view and access previous point-in-time copies of either individual files or entire directories.

Further benefits lurk beneath the surface of this feature, however. The service behind shadow copies, called the Volume Shadow Copy Service (VSS), is actually responsible for a newly developed application programming interface (API) that allows server-based applications such as Exchange, SQL, and backup programs to take advantage of the benefits of shadow copies. Perhaps the most famous example is a backup that skips open files, either because they are currently open by a user or because they are locked by another process. In the past, this resulted in incomplete backups, either because the backup process halted in midstream because of this unrecoverable error, or because the process skipped the open file. If the open file is, say, your Exchange email database, that's not necessarily a good thing. But now, with volume shadow copies, the backup application can simply use an API to take a snapshot of any open files and back up that snapshot. Now you have an instant backup of a database at any point in time, with no interruption in availability to the user. This is a very nice feature.

You definitely can take advantage of previous versions in the user realm as well. Part of the volume shadow copy service is a piece of client software that Windows Vista and Windows XP Service Pack 2 clients have integrated into the product; no separate installation is needed. Windows 2000 clients can access the software at http://go.microsoft.com/fwlink/?LinkId=22346.

Once the user has this client, Windows adds a tab to the Properties sheet for any document. This is shown in Figure 3-33.

Figure 3-33. The Previous Versions screen

To restore a previous version of a file, all the user has to do is select the appropriate version and either copy it to a different location using the Copy button, or restore it to its location at the time the snapshot was taken by using the Restore button. (This will overwrite the newer version because it's assumed that when a user wants to restore a previous version, he doesn't want the current version.) Note that viewing an executable file will run that file.

To reduce confusion, when a user accesses the Previous Versions link in the Explorer view of a particular share, she is presented only with a list of unique copies—that is to say, a list of versions that differ from one another, a condition that indicates the file or folder changed. In addition, previous versions are read-only, in that users can copy, drag and drop, and perform any other function on them as usual except for overwriting or deleting them.

3.7.1. Enabling Previous Versions

The good news here: previous versions are enabled by default. Less for the administrator to do!

How does this work in terms of system resources required? By default, the system creates a folder on that volume called System Volume Information, where the actual snapshots and logfiles of the operations are stored. By default, this folder is allocated 10% of the volume's total disk space, much like the Recycle Bin default in Windows. You need at least 300 MB of disk space to actually create a previous versions snapshot.

When you first enable previous versions, a current snapshot of the volume is taken so that Windows can store a picture of the "state" of files on the disk. This state data is used to determine whether files have changed from the time at which the state information was recorded. For example, an administrative assistant is performing rudimentary formatting functions on an Excel spreadsheet and she leaves for the day. Overnight, the Windows Server 2008 machine on which the file share resides is configured to take a snapshot of all files—for this example, I will use 5:30 a.m. When this snapshot is taken, the state information for this Excel spreadsheet is copied into the System Volume Information folder. Now, when the administrative assistant arrives at the office and begins to work on the spreadsheet, she is using the same version as the one she saved the previous night; remember that this is also the one on which the snapshot is based. When she finishes with some formatting, she saves the spreadsheet before she attends the Tuesday morning meeting of all employees. The VSS service detects that the Excel file is one that already has state data, and it realizes that it has changed, so it immediately makes available the 5:30 a.m. version of the file—the previous version—under the appropriate tab in the Properties sheet for the Excel file. So now, when the administrative assistant comes back and realizes that she unintentionally removed an entire page from the workbook while she was formatting the file, she can retrieve the version from the previous night, and likely save some heartache.

You should, however, note three very important items concerning how previous versions might and (most notably) might not rescue you or your users from catastrophe:

  • You can only restore the shadow copy of a file that consisted of the oldest modification since the most recent snapshot. Even if multiple changes are made to a file throughout the day, the only previous version available for rollback is the one that was made directly after the most recent snapshot. This can be somewhat counterintuitive, but it's crucial that your users not rely on the previous versions feature as a crutch and that they learn to use it only when a major disaster strikes.

  • If you rename a file, you lose all access to previous versions of that file, even if some exist. VSS tracks exclusively by filename and state, so if the filename changes, VSS (at least at this stage) isn't smart enough to follow the rename.

3.7.2. Altering the Previous Versions Schedule

By default, previous version copies are scheduled to be made at 7:00 a.m. and at noon on weekdays. Server performance can be adversely affected if you schedule shadow copies to be taken more frequently than once every 60 minutes.

Because the times at which shadow copies are made can be far apart in the work day, it's best to remind users that the shadow copy functionality is not a crutch and that the best way to ensure that no data is lost is to save early and often.

Additionally, as soon as 64 shadow copies per volume are stored, the oldest will be deleted and become irretrievable as new shadow copies are made to replace them.

To change the shadow copy schedule, follow these steps:

  1. Open Computer and right-click on the volume for which you want to configure shadow copies.

  2. Navigate to the Shadow Copies tab.

  3. Select the disk on which to modify the shadow copy schedule, and then click the Settings button.

  4. Click the Schedule button in the box that appears next.

  5. Change the schedule as appropriate.


the_distributed_file_system.html

3.8. The Distributed File System

The Distributed File System (DFS) is a technology that allows several distinct filesystems, potentially on multiple servers, to be mounted from one place and appear in one logical representation. The different shared folders, which likely reside on different drives in different server machines, can all be accessed from one folder, known as the namespace. Folder targets serve to point from shared folder to shared folder to mimic a directory tree structure, which can be rearranged and altered according to a particular implementation's needs. DFS also allows the clients to know only the name of the share point and not the name of the server on which it resides, a big boon when you field help-desk calls asking, "What server is my last budget proposal located on?"

DFS namespaces come in two basic flavors: standalone namespaces, which store the folder topology information locally, and domain-based namespaces, which store the topology structure in Active Directory and thereby replicate that information to other domain controllers. In this case, if you have multiple namespaces, you might have multiple connections to the same data—it just so happens that they appear in different shared folders. You even can set up two different share points to the same data on two different physical servers, because DFS is intelligent enough to select the folder set that is geographically closest to the requesting client, saving network traffic and packet travel time.

DFS in Windows Server 2008 is, essentially, made of two components:

DFS namespaces

These allow you to group shared folders stored on different servers and present them to users in one coherent tree, making the actual location of the files and folders irrelevant to the end user.

DFS replication

This is a multimaster replication engine that supports scheduling, bandwidth throttling, and compression. Most notably, DFS Replication now uses an algorithm known as Remote Differential Compression (RDC), which efficiently updates files over a limited-bandwidth network by looking at insertions, removals, and rearrangements of data in files, and then replicating only the changed file blocks. There is substantial savings to this method.

Figure 3-34 shows a basic flow that DFS transactions proceed through in Windows Server 2008.

Figure 3-34. The basic flow of DFS in Windows Server 2008

Let's walk through this. When an end user wants to open a folder that is included within a DFS namespace, the client sends a message to the namespace server (which is simply a machine running the Windows Server 2008 or Windows Server 2003 R2 version of DFS). That machine will then refer the client to a list of servers that host copies of those shared folders (these copies are called folder targets). The client machine stores a copy of that referral in its cache and then goes down the referral list in order, which is automatically sorted by proximity so that a client is always using servers within his Active Directory site before traversing to machines located outside of his current location.

But let's crack the nut a little further and see where DFS replication comes into play. In a very basic scenario, you can store a folder on a server in New York and the same folder on a server in London, and replication will take care of keeping the copies of the folders synchronized. Users, of course, have no idea that these folders are kept in geographically disparate locations. However, the replication mechanism is incredibly optimized: it determines what has changed about two files and then, using remote differential compression, only sends the differences between the files and folders over the wire. Over slow WAN links and other bandwidth-metered lines, you'll see a real cost savings. You really see the benefits when relatively minor changes to large files are made. According to Microsoft, a change to a 2 MB PowerPoint presentation can result in only 60 KB being transmitted across the wire—which equates to a 97.7% savings in terms of amount of data sent. Delving a bit further, we get this explanation according to the product team, they "ran a test on a mix of 780 Office files (.doc, .ppt, and .xls) replicating from a source server to a target server using DFS Replication with RDC. The target server had version n of the files and the source server had version n+, and the two versions differed with significant edits. The percent savings in bytes transferred was on average 50 percent and significantly better for large files."

Of course, with DFS you also get the fault tolerance benefit of "failing over" to a functional server if a target on another server isn't responding. In previous versions of DFS in earlier releases of Windows Server, there wasn't a simple way for you to instruct clients, after a failure, to resume back to their local DFS servers once the machines came back online. Now you can specify that clients should fail back to a closer, less costly server when services are restored.

Although Windows Server 2008's DFS components are two separate technologies, when they're used in tandem, they solve some real problems companies face. Take branch office backup, for instance. Instead of tasking your administrators in these offices with tape drive maintenance, backing up, storing data off site, and everything else associated with disaster avoidance, simply configure DFS to replicate data from the servers in the branch office back up to a hub server in the home office or another data center. Then, run the backup from the central location. You are more efficient in three ways:

  • You save on tape hardware costs.

  • You save time through the efficiencies in DFS replication.

  • You save manpower costs because your IT workers at the branch offices can move on to other problems and not spend their time babysitting a backup process.

What about software distribution? DFS really excels at publishing documents, applications, and other files to users that are separated geographically. By using namespaces in conjunction with replication, you can store multiple copies of data and software at multiple locations throughout the world, better ensuring constant availability and good transfer performance while still making it transparent to users where they're getting their files from. DFS replication and namespaces automatically look at your AD site structure to determine the lowest cost link to use in the event that a local namespace server isn't available to respond to requests.

The UI for managing DFS has also improved over the more clunky and less put-together MMC snap-in in Windows 2000 and the original version of Windows Server 2003. The new snap-in offers you the ability to configure namespaces and other abilities that previously only existed through the command-line interface.

3.8.1.

3.8.1.1. Creating a namespace

In Server Manager, under the File Services role service node, the Namespaces node in the left pane contains any namespaces you may create as well as any existing namespaces you add to the console display. Beneath each namespace in the tree, you'll find a hierarchical view of folders. Folders with targets use a special icon to differentiate them from ordinary folders without targets. We'll use this UI to create a new namespace, add some folders and folder targets, and then eventually set up replication between two machines to demonstrate the functionality.

In order to create a new namespace, the following conditions must be met:

  • You need at least two servers, both running either Windows Server 2008 or Windows Server 2003 R2. You'll need the DFS system installed, which you can do through the Add Roles Wizard as described earlier in this chapter.

  • If you want an AD-integrated topology, you will need to have deployed Active Directory on your network. For the purposes of this exercise, I'll assume that you have not deployed AD yet, and we will focus on the non-AD specific DFS features.

To deploy a new namespace, right-click on the Namespace node in the left pane and select New Namespace from the context menu. Then:

  1. On the Namespace Server page, shown in Figure 3-35, enter the name of the server that will host the namespace. Then click Next.

    Figure 3-35. The Namespace Server screen

  2. On the Namespace Name and Settings page, enter a name for your new namespace. I've named my new namespace Files, as you can see in Figure 3-36.

    Figure 3-36. The Namespace Name and Settings screen

  3. The Namespace Type screen appears, as shown in Figure 3-37. Choose "Standalone namespace" from the list, and then click Next.

    Figure 3-37. The Namespace Type screen

  4. On the Review Settings and Create Namespace screen, depicted in Figure 3-38, verify the settings you've chosen and then click Next.

    Figure 3-38. The Review Settings and Create Namespace screen

  5. The Completion screen appears. Close the wizard after confirming that there were no errors during the completion process.

3.8.1.2. Adding and managing folders and folder targets in a namespace

It's very simple to add a folder to an already existing namespace. In the left pane, right-click on the name of the namespace and choose New Folder. You'll see the New Folder screen. Enter the name of the folder you'd like to add in the Name box.

If you'd like, you can go ahead and add some folder targets to this folder at the same time you're creating the folder. Recall that folder targets allow you to redirect a specific DFS namespace folder to a physical location on a shared folder structure. For example, if I wanted to have the Office folder appear in my DFS namespace structure, I could create a folder target, attached to a DFS folder, that pointed to the actual location where Office resides. Folder targets are just a way to clean up and simplify the appearance of files and folders within your network.

If you want to move or rename a particular folder, simply right-click on the folder within the left pane in the console, select Move or Rename, and complete the appropriate action. The DFS service handles the rest; moving is a particularly seamless action.

To add a folder target, click the Add button, and the Add Folder Target screen will appear. Enter the correct path to the location you want the folder target to reference, and then click OK.

You can add multiple folder targets to any one folder as a way of maintaining fault tolerance. That way, if a user is directed to a particular machine that is down, the client will work down the referral list it received from the namespace server and try another server that hosts a copy of the folder target. You can adjust how this referral is done, within or outside of a site, by right-clicking on the name of the namespace in the left pane of the console and selecting Properties. Navigate to the Referrals tab, and then select the appropriate option from the Ordering Method box. You can choose "lowest cost," which takes into account sites and site links as configured within Active Directory, "random order," which does exactly what it sounds like it does, or "exclude targets outside of the client's site," which simply removes the ability for clients to access targets exterior to their current site.

Note that when you try to add a target to a folder that already has just one target, the DFS MMC snap-in will prompt you and ask if you'd like to create a replication group to keep the two targets synchronized. And that's what the next section is all about.

3.8.1.3. Creating a replication group for a folder

Again, if you have more than one folder target for fault tolerance purposes, you'll want to configure a replication group so that the contents of the folders are kept synchronized and users have a transparent interface to the items contained therein. A replication group is a set of servers that sends or receives updates of replicated folders. When you enable DFS Replication on a folder with targets, the servers that host the folder targets are automatically made members of the replication group, and the folder targets are associated with the replicated folder. All other properties, like the name of the group and the name of the folder, are identical as well.

You can use DFS Replication in both standalone and domain-based namespaces. Therefore, you can complete this task regardless of the type of namespace you created in the previous section. You do, however, need to have Active Directory deployed, and you need to be a member of the Domain Administrators group. (I'll cover AD in Chapter 5; if you want to wait until you've read that chapter before continuing with this section and procedure, that's not a problem.) Note, however, that this requirement will hamper an attempt to delegate control of your DFS structure.

To create a replication group for a folder:

  1. In the left pane of the console, right-click on the folder in the namespace you created, and select Replicate Folder.

  2. The Replication Group and Replicated Folder Name screen appears. Enter a name for the replication group (most people keep this as the same name as the namespace folder path) and then also enter the name of the replicated folder. Click Next to continue.

  3. The Replication Eligibility screen appears. In this step, the Replicate Folder Wizard determines which, if any, folder targets are able to participate in replication. Make sure that at least two of these targets, located on different servers, are eligible, and then click Next.

  4. The Primary Folder Target screen appears. Here, specify the folder target that will be used as the primary member of the replication group, i.e., the member whose content is authoritative, the master copy of the content. Click Next to continue.

  5. The Topology Selection screen appears. On this screen, you can choose how the connections among the server members of the replication group will be deployed. If you have three or more members in your replication group, you can choose the hub and spoke methodology, in which hub members are connected to other members and data originates from the center and moves outward to the spokes. Your other choices are full mesh, in which each member replicates all data with all other members, and no topology, where you can create your own topology. For this example, choose "full mesh," and then click Next to continue.

  6. The Replication Group Schedule and Bandwidth screen appears. Here, you can choose whether to replicate full time (24 x 7) or on a specific schedule. To set the schedule, click the Edit Schedule button. You can also choose how much bandwidth to use during replication, which helps keep more bandwidth available for regular usage. You can choose Full from the list to drop all bandwidth concerns and replicate everything as fast as possible. Click Next to continue.

  7. The Review Settings and Create Replication Group screen appears. Verify all of the settings you have chosen; if you need to change something, click the Back button. Otherwise, click Next, and the wizard will set off creating your replication group.

  8. The Confirmation screen appears. Make sure there are no errors, and then click Close.

  9. The Replication Delay screen appears. This message appears to let you know that there may be an initial delay while the configuration of the replication group is propagated among all of the members of the group. Click OK to acknowledge.

Your replication group is now set up. If you add a file or make other changes to the folder target location on one machine, DFS Replication will pick up the change and replicate it to all of the other folder targets on the other machines within the replication group, thus enabling a seamless interface to files and folders for your users as long as they use Explorer to find files through the namespace you created.

From the Replication node, you can manage all of the properties and settings of DFS Replication, such as the schedule, bandwidth throttling, the topology, and others. On the Replicated Folders tab in the Details pane of the MMC console, you can also view the namespace path that corresponds to the replicated folder or folders.


command-line_utilities.html

3.9. Command-Line Utilities

In this section, I'll look at several ways you can manage file, print, and user services from the command line.

3.9.1. Using Shares

Sometimes it's inconvenient to use the Windows GUI to map a drive—this is a problem particularly in logon scripts. How do you use a batch file to tell the mouse pointer to move over to My Network Places? There's a better way. The net use command enables you to map any drive to any server on your network, and in some cases, outside networks, too. The syntax is:

net use drive \\server\share

Here are some common examples that you should find useful.

To map drive H: to Lisa Johnson's home directory on server MERCURY:

net use H: \\mercury\users\lmjohnson

To map the first available drive letter to the same directory:

net use * \\mercury\users\lmjohnson

Sometimes you might need to connect to a share on a domain that isn't trusted by your home domain. If you have an account on that domain, you can use it to connect, like so:

net use H:
\\foreignmachine\sharename
/user:foreigndomain\username

(If you need to use a password, you'll be prompted for it.)

If you need to terminate a connection or map to a server, use the /d switch:

net use \\mercury\users\lmjohnson /d

To disconnect all drive mappings on the local machinemaps:

net use * /d

To connect to a foreign machine (152.1.171.133, in this example) over the Internet or an intranet without relying on name resolution:

net use H:
\\152.1.171.133\c$

You also can use a different account with the IP address:

net use H:
\\152.1.171.133\c$
/user:hasselltech\hassell

And you can specify that this mapping is for the current session only and should not be restored upon logon. This is a feature that I call map persistency—keeping the same mappings across login sessions, a big timesaver for your users. To do so:

net use H:
\\152.1.171.133\c$
/persistent:no

3.9.2. FSUTIL

To set up default quotas and modify them using the command line, type the following at the prompt:

fsutil quota modify [VolumeOrDrive] [warninglevel] [hardquota] [username]

replacing the text in brackets with the appropriate information as specified in the following list:

VolumeOrDrive

The drive letter or volume name of the disk on which you want to modify a quota. Volume names are tricky to specify because you must do so using the globally unique identifier (GUID), which can be a long string of seemingly random numbers.

warninglevel

The amount of space at which warnings will be recorded in the system event log.

hardquota

The amount of space at which users will reach their maximum allowed disk space.

username

The user to which this quota specification applies.

Using fsutil.exe, you can create scripts to automatically set quota entries upon new-user creation to work around the limitation of assigning quotas to groups, as described earlier in this chapter. fsutil.exe can help you access functionality more quickly and efficiently than you can by using the GUI interface. The following examples, designed to run from a command line, illustrate the quota functionality available through fsutil.exe.

To disable quota support on drive C:

fsutil quota disable C:

To enable quota support on drive E:

fsutil quota enforce E:

To set a 250 MB quota for Lisa Johnson (user ID lmjohnson) on drive C:

fsutil quota modify C: 250000000 lmjohnson

To list the current quotas set on drive D:

fsutil quota query D:

To track the disk usage—in other words, to list which users are taking up what amount or portion of space—on drive F:

fsutil quota track F:

To list all users over quota on any volume on the server:

fsutil quota violations

3.9.3. Managing Offline Folders

To make a share's contents available offline from the command line, at a prompt, type:

net share
nameofshare
/CACHE:[manual | documents | programs | none]

/CACHE:manual enables manual client caching of programs and documents from this share. /CACHE: documents enables automatic caching of documents from this share. /CACHE:programs enables automatic caching of documents and programs (distinguished by their file extension) from this share. /CACHE:none disables caching from this share.

3.9.4. VSSADMIN

The GUI for managing shadow copies is somewhat complete; however, it lacks the ability to specify on which disk or volume shadow copies are stored. Also, an administrator cannot delete specific shadow copy files using the GUI. This might be needed if a user creates an incorrect version of a file, then leaves and another worker comes back the next day. An administrator might need to delete the previous version as soon as possible so that the new user doesn't inadvertently work from the incorrect version.

The vssadmin.exe command-line utility was created to offer administrators the ability to control these factors. I'll now walk through several examples.

vssadmin Add ShadowStorage /For=C: /On=D: /MaxSize=150MB

This command specifies that storage for shadow copies (known as an association) of drive C: will be stored on drive D:. If a value is not specified, there is no limit to the amount of space shadow copies can use. Shadow copies require at least 100 MB of space, and you can specify the maximum amount in KB, MB, GB, TB, PB, and EB, although it's assumed if you don't use a suffix, the value is in bytes.

vssadmin Create Shadow /For=E: /AutoRetry=2

This command creates a new shadow copy of drive E:. The /AutoRetry switch dictates that if another process is attempting to make shadow copies at the same time vssadmin is attempting to make them, the utility will keep trying for two minutes.

vssadmin Delete Shadows /For=C: /Oldest

This command deletes the oldest shadow copy on drive C:. You can use the /all switch to instead delete all shadow copies that can be deleted. You also can specify a specific shadow copy to delete by using /Shadow=ID, where ID is the hexadecimal number you obtain through the List Shadows command, covered later in this section.

vssadmin Delete ShadowStorage /For=C: /On=D:

This command deletes the storage space on drive D: that is used to store shadow copies of drive C:. If you leave off the /On switch, all shadow copy storage associations for drive C: will be deleted.

vssadmin Resize ShadowStorage /For=C: /On=D: /MaxSize=150MB

This command modifies the maximum size for a shadow copy storage association between drives C: and D:. Again, the maximum size has to be 100 MB or more. If you decrease the maximum size, older shadow copies can be deleted to make room for more recent shadow copies.

Other useful commands:

vssadmin List Providers

This command lists registered volume shadow copy providers.

vssadmin List Shadows

This command lists existing volume shadow copies and their ID numbers, for use with the Delete Shadows command.

vssadmin List ShadowStorage

This command shows the disks eligible to support shadow copy functionality.


the_last_word-id2.html

3.10. The Last Word

In this chapter, you've learned about all of Windows Server 2008's file, print, and user services. We began with an overview of sharing and a guide to creating shares, publishing them to Active Directory, and mapping drives, and then moved into a detailed discussion of the Windows permission structure, including permission levels, "special" permissions, inheritance, and ownership. You also saw an overview of the Distributed File System, how to set it up, and how to manage it, and how offline files and folders operate. Rounding out the chapter, you saw how to administer most of these services from the command line.

In the next chapter, I'll talk about the foundation of Windows Server 2008's Active Directory service—the domain name system, or DNS.


domain_name_system.html

Chapter 4. Domain Name System

The Domain Name System (DNS) is a staple of the public Internet and is the name resolution system of choice for both large and small networks. DNS is a directory of IP addresses and their corresponding hostnames, much like a phonebook in functionality. However, DNS is more complex than a phonebook and it stores many types of mappings as well as information on services provided by servers on your network.

Whereas Windows NT relied on the Windows Internet Naming Service (WINS) and NetBIOS for name resolution, Windows Server 2008 depends on DNS. In fact, DNS is required for anyone that wants to use Active Directory—DNS lies at the heart of Active Directory, and they're inseparable. WINS is obsolesced, at least in terms of pure Windows infrastructure if you have an Active Directory network with all machines running Windows 2000 or later and DNS-aware applications.

In this chapter, I'll discuss the fundamentals of DNS, its structure, and the various types of data it supports and requires, and then I'll proceed through installing and configuring a Windows DNS server and describe how you can integrate it with Active Directory.

4.1. Nuts and Bolts

Let's go through the basic building blocks of DNS first before we break into more advanced concepts. I'm going to provide you with a very fundamental, introductory look at DNS, and then in the following sections I'll break down each part with more detailed explanations and examples. Think of this as an abstract or executive summary, just so we're all on the same page before I move on to more technical topics.

The main premise of DNS is to provide name resolution services—that is, to resolve friendly textual hostnames to their associated IP addresses. DNS is the de facto standard for name resolution on the Internet and in modern networks that use TCP/IP as the transmission protocol. DNS is based on domains, which are simply textual names that refer to logical groupings of computers There are top-level domains (TLDs), including some that are probably familiar to you: .COM, .NET, .ORG, and the like. There are also second-level domains, which are less inclusive and usually take the form of name.tld. For example, my domain is jonathanhassell.com. O'Reilly has a domain name of oreilly.com. CNN's domain is cnn.com.

Politically, there is an organization called ICANN, short for the Internet Consortium of Assigned Names and Numbers, which tracks the top-level domains. This keeps utter confusion from breaking out when thousands upon thousands of top-level domains might be issued. Individuals and businesses are allowed to register second-level domain names beneath top-level domains—hasselltech.net, for example.

DNS resolves names based on zones. Zones contain information on computers, services, and IP addresses for a collection of computers. Zones typically correspond to DNS domains, but they certainly do not have to. The DNS server or servers in a zone that contain a readable and writable copy of the zone file (which contains all that information on computers, services, and addresses) is considered to be authoritative. You must have at least one authoritative server per zone for DNS to function. Any other DNS servers within this zone are considered to be secondary servers, meaning they hold a read-only copy of the DNS zone file.

Finally, there are two types of zones: forward lookup zones, which resolve hostnames to IP addresses, and reverse lookup zones, which do the opposite and resolve IP addresses to hostnames. Reverse lookup zones fall under a special top-level domain named in-addr.arpa, which ordinary users and clients never see in the course of their day-to-day work.

Now, let's take a closer look at these elements of DNS.


nuts_and_bolts.html

Chapter 4. Domain Name System

The Domain Name System (DNS) is a staple of the public Internet and is the name resolution system of choice for both large and small networks. DNS is a directory of IP addresses and their corresponding hostnames, much like a phonebook in functionality. However, DNS is more complex than a phonebook and it stores many types of mappings as well as information on services provided by servers on your network.

Whereas Windows NT relied on the Windows Internet Naming Service (WINS) and NetBIOS for name resolution, Windows Server 2008 depends on DNS. In fact, DNS is required for anyone that wants to use Active Directory—DNS lies at the heart of Active Directory, and they're inseparable. WINS is obsolesced, at least in terms of pure Windows infrastructure if you have an Active Directory network with all machines running Windows 2000 or later and DNS-aware applications.

In this chapter, I'll discuss the fundamentals of DNS, its structure, and the various types of data it supports and requires, and then I'll proceed through installing and configuring a Windows DNS server and describe how you can integrate it with Active Directory.

4.1. Nuts and Bolts

Let's go through the basic building blocks of DNS first before we break into more advanced concepts. I'm going to provide you with a very fundamental, introductory look at DNS, and then in the following sections I'll break down each part with more detailed explanations and examples. Think of this as an abstract or executive summary, just so we're all on the same page before I move on to more technical topics.

The main premise of DNS is to provide name resolution services—that is, to resolve friendly textual hostnames to their associated IP addresses. DNS is the de facto standard for name resolution on the Internet and in modern networks that use TCP/IP as the transmission protocol. DNS is based on domains, which are simply textual names that refer to logical groupings of computers There are top-level domains (TLDs), including some that are probably familiar to you: .COM, .NET, .ORG, and the like. There are also second-level domains, which are less inclusive and usually take the form of name.tld. For example, my domain is jonathanhassell.com. O'Reilly has a domain name of oreilly.com. CNN's domain is cnn.com.

Politically, there is an organization called ICANN, short for the Internet Consortium of Assigned Names and Numbers, which tracks the top-level domains. This keeps utter confusion from breaking out when thousands upon thousands of top-level domains might be issued. Individuals and businesses are allowed to register second-level domain names beneath top-level domains—hasselltech.net, for example.

DNS resolves names based on zones. Zones contain information on computers, services, and IP addresses for a collection of computers. Zones typically correspond to DNS domains, but they certainly do not have to. The DNS server or servers in a zone that contain a readable and writable copy of the zone file (which contains all that information on computers, services, and addresses) is considered to be authoritative. You must have at least one authoritative server per zone for DNS to function. Any other DNS servers within this zone are considered to be secondary servers, meaning they hold a read-only copy of the DNS zone file.

Finally, there are two types of zones: forward lookup zones, which resolve hostnames to IP addresses, and reverse lookup zones, which do the opposite and resolve IP addresses to hostnames. Reverse lookup zones fall under a special top-level domain named in-addr.arpa, which ordinary users and clients never see in the course of their day-to-day work.

Now, let's take a closer look at these elements of DNS.


zones_versus_domains.html

4.2. Zones Versus Domains

As you learned in the previous section, a DNS domain in its simplest form is a second-level name coupled with an ICANN-sponsored top-level domain—hasselltech.net, for example. In DNS parlance, a zone is the range of machines and addresses that a specific nameserver needs to be concerned about. Zones don't necessarily need to correspond to DNS domains, meaning that I can have multiple DNS zones for the single hasselltech.net domain. For example, I can have one zone for sales.hasselltech.net, another zone for billing.hasselltech.net, and yet another for hosting.hasselltech.net, all with separate nameservers but all within the control of the hasselltech.net domain.

Why would you want multiple DNS zones for a single DNS domain? To delegate administration is a common reason. If your organization is spread all over the country and you have an administrator for each office around the country, that administrator is likely best equipped and skilled to handle DNS configuration for his office—after all, he works with the individual computers more than a higher-level administrator at the home office does. So, the home office nameserver is configured to hold a few names and addresses for servers and machines there, and the branch office nameservers hold zones for their respective computers. In this configuration, when a computer comes to their servers and requests a name for an IP address associated with a branch office, the nameservers at the home office will refer the requesting computer to the nameserver at that branch office that holds the names and addresses for that zone, a process known as delegating name resolution to other servers. Additionally, the branch office server is authoritative for its zone, meaning that it holds the definitive name-to-address correspondence for computers in its zone.

Of course, domains aren't limited to just a second-level name plus an ICANN-approved extension. You also can have multiple levels of names: for example, customers.extranet.microsoft.com is a valid name, as is payjon.corp.hasselltech.net. As you read further into the chapter, you'll see situations in which a longer, more extended domain name would be appropriate.

4.2.1. Zone Files

Zone information is stored in zone files that, by default, are stored as ASCII test files in %SystemRoot%\system32\dns. The files are stored in the format <domain>.dns (e.g., hasselltech.net.dns). These ASCII files hold the different types of information contained within forward and reverse lookup zones, which we'll look at in just a bit.

DNS also can store zone information within Active Directory (as an application partition), an option I'll discuss in more detail later in this chapter. For now, we'll proceed on the assumption that zone files are stored in this location in ASCII format.

4.2.2. Forward and Reverse Lookup Zones

DNS handles forward lookups, which convert names to IP addresses, and the data is stored within a forward lookup zone. But DNS also handles reverse lookups, which convert IP addresses to names. There's also something called a reverse lookup zone, which does the opposite of a forward lookup zone—it catalogs all machines within a certain network range. You construct the name of a reverse lookup zone in a rather odd way. The easiest way to construct a reverse lookup zone name is to look at the range of IP addresses you've been assigned, drop the last dotted quad that contains the numbers you control, reverse the order of the remaining dotted quads, and then add .in-addr.arpa. For example, if your IP address is 64.246.42.130, the name of the associated reverse lookup zone is 42.246.64.in-addr.arpa.

Reverse lookup zones are constructed a bit differently, depending on whether you have a class A, B, or C IP address. Table 4-1 shows the respective ways to generate a reverse lookup zone name.

Table 4-1. Generating a reverse lookup zone name
Address class | Resulting zone name and method
Class A (12.0.0.0/8) | 12.in-addr.arpa Only the first quad is set, so only one quad needs to be in the reverse zone.
Class B (152.100.0.0/16) | 100.152.in-addr.arpa Because only two dotted quads are included, only two need to be noted in the reverse zone.
Class C (209.197.152.0/24) | 152.197.209.in-addr.arpa All dotted quads set in the IP address range need to be included in the reverse lookup zone name.

In practice, it's very likely that you don't need a reverse lookup zone for public-facing DNS servers, and it's equally likely that you would be prevented, on a technical basis, from creating one. (Internal DNS servers are another matter, which you'll see in a bit.) Although forward lookup zones concern hostnames and DNS domain names, which are under your control and management because you buy them from an accredited registrar, reverse lookup zones deal mainly with IP addresses and their owners, which probably are not under your control. Unless you have contacted the Internet Assigned Names Authority (IANA) and obtained a block of IP addresses specifically from them, it's probable that your ISP actually owns the addresses and therefore is the one tasked with maintaining reverse lookup zones.

There are really only a few reasons why it's advantageous to control your own reverse lookup zone. First and foremost, some mail servers will refuse to exchange Internet mail with your servers if their reverse lookups reveal that you're using a dynamically assigned IP address block of typical ISPs. This can be a real problem, but your ISP usually can help you out with this. Second, the nslookup command can return a nasty but harmless error message about being unable to find a server name for your current IP address, depending on how you are connected to the Internet. Although this is annoying, it's simply saying no appropriate reverse zone is configured for the current computer. So, when you've just installed Active Directory and you run nslookup to check things out, and you get no results, this is most likely because you haven't yet configured a reverse lookup zone.


resource_records.html

4.3. Resource Records

A DNS zone contains various types of entries, called resource records. Resource records are the meat of a DNS zone, providing information about hostnames, IP addresses, and in some cases the services offered by a particular machine. There are several different classes of record types, the most common of which I'll define now.

4.3.1. Host (A) Records

Host records, or A records, simply map a hostname to an IP address. You generally create host records for each machine in your network.

A sample A record looks like this in a zone file:

colossus A 192.168.0.10

Using host records, you can implement a load-balancing technique known as round-robin DNS. Round-robin DNS involves entering multiple A records, all configured with the same hostname, but with different IP addresses that correspond to different machines. This way, when computers contact a nameserver for a certain hostname, they have an equal chance of receiving any one of the number of machines with A records. For example, if I have a web site at www.hasselltech.net and I have three web servers at 192.168.0.50, 192.168.0.51, and 192.168.0.52, I can configure three A records, all named "www," but with the three IP addresses mentioned earlier. Now, when client computers come to the nameserver and ask for the IP address of www.hasselltech.net, they have a 33% chance of receiving 192.168.0.50 as the web server of choice, a 33% chance of receiving 192.168.0.51, and a 33% chance of receiving 192.168.0.52. It's a poor man's load-balancing system.

Let's get a bit more technical: in this scenario, Windows 2000 and Windows XP clients will continue to attempt a connection to the first web server that was originally resolved. A DNS cache timeout value on the client is set to 86,400 seconds (one day) by default. If you change this value on the client to one second, you have better odds of reaching your server. You can change this value in the Registry with the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

Change the MaxCacheEntryTtlLimit to the number of seconds desired.

If the group of machines that serve web sites are on different subnets, the DNS system can return the "proper" address from a round-robin record set—that is, the one that is closest to the client requesting it. This functionality is enabled by default. For example, if you have one A record set up for www.hasselltech.net on IP address 192.168.0.51, and another A record set up for the same hostname on IP address 10.0.0.25, a client computer located on the 10.0.0.0 subnet will receive the 10.0.0.25 A record from his request, and a client computer located on the 192.168.0.0 subnet will receive the 192.168.0.51 A record from his request.

Some advantages to round-robin DNS balancing include the following:

  • The price is right—it's free with any nameserver.

  • It's less complex than other, proprietary balancing systems.

  • It's easy to maintain. You can simply add and delete A records in the zone file for each host as they come and go to and from production service.

The disadvantages include the following:

  • It's less complex than other, proprietary balancing systems. Yes, this is an advantage and a disadvantage because a less complex system is less flexible than a proprietary solution.

  • If a web server goes down, DNS isn't aware of it. It simply will continue to dole out IP addresses regardless of whether the server is available.

  • It doesn't take into account the various capabilities and capacities of each system—it distributes the load fairly equally, whether your group of machines includes a Pentium 2 or a dual Pentium IV Xeon machine.

4.3.2. Canonical Name (CNAME) Records

CNAME, or canonical name, records allow you to give multiple hostnames to one IP address. Using CNAMEs, you can have a machine answering on one IP address but listening to several different hostnames—www.hasselltech.net, ftp.hasselltech.net, and mail.hasselltech.net all might be on one IP address, 192.168.1.2. CNAMEs effectively work as aliases.

However, there's a caveat to these records: you can't have multiple identical CNAMEs. For example, if you have a record for www-secure.hasselltech.net on 192.168.1.2, you can't have another CNAME record named www-secure.hasselltech.net for a different IP address. CNAMEs are only for multiple names to one IP address, not for multiple IP addresses to one name. Note that these names are zone-dependent, not server-dependent.

Sometimes Windows will refer to CNAME records as aliases, in a confusing mix of technical accuracy and common parlance.

A sample CNAME record in zone file format looks like this:

ftp CNAME colossus.hasselltech.net

4.3.3. Mail Exchanger (MX) Records

Mail exchanger, or MX, records identify the mail server or mail servers for a specific zone or domain. Very simply, they instruct connecting computers to send all mail destined for a domain to a specific machine configured to receive Internet email.

In practice, a specific DNS zone can have multiple MX records. Each MX record is also assigned a preference number, which simply indicates what steps the respective machines listed should take when receiving Internet email. Lower preference numbers have higher priority. For example, let's say I have the following MX records:

  • Hasselltech.net, MX preference 10, to mail.hasselltech.net

  • Hasselltech.net, MX preference 100, to queue.perigee.net

This instructs connecting computers to send Internet email destined to hasselltech.net to the machine mail.hasselltech.net. However, if that machine isn't answering requests, connecting computers are instructed to try the machine queue.perigee.net and deliver mail there because the preference number is higher (100) than that of the first machine, which is 10. MX preference numbers provide a bit of failover protection if your organization's mail server is on a flaky or nonpermanent connection.

Entering two MX records with the same preference number distributes the load between the two hosts roughly equally, much like round-robin DNS balancing using multiple A records.

Here is a sample MX record in zone file format:

@ MX 10 mail.hasselltech.net
@ MX 100 queue.perigee.net

4.3.4. Nameserver (NS) Records

Nameserver (NS) records define the nameservers that can answer queries for a specific domain. They also delegate the resolution duties for various subdomains to other zones. For example, you might configure an NS record for the "sales" subdomain to delegate name resolution duties to the salesns.hasselltech.net machine, which handles that zone, or an NS record for the "billing" subdomain to delegate duties to the billing-dns.hasselltech.net computer.

A sample NS record in zone file format looks like this:

@ NS colossus.hasselltech.net.
@ NS ns2.hasselltech.net.

4.3.5. Start of Authority (SOA) Records

The start of authority, or SOA, record for a zone names the primary nameservers that are authoritative for a particular zone and provides contact information for the primary administrator of the zone. It also controls how long a nonauthoritative nameserver can keep the information it retrieved in its own cache before needing to verify the data with the authoritative server again.

There are three important intervals to discuss at this point when it comes to SOA records:

Refresh interval

The refresh interval indicates to secondary nameservers how long they can keep their copies of the primary nameserver's zones before being required to request a refresh of the zone.

Retry interval

The retry interval indicates how long the secondary nameserver must wait before attempting to contact the primary nameserver again after a failed attempt to refresh its zones after the refresh interval has lapsed.

Minimum (default) TTL

This value indicates to other nameservers how long they can use information they've previously retrieved from this authoritative nameserver before being required to consult the authoritative server again for updated or refreshed information. This is, by default, 60 minutes. You also can set TTL values for individual records that override this minimum default setting for a zone.

A sample SOA record in zone file format looks like this:

@ IN SOA colossus.hasselltech.net. admin.hasselltech.net. (
200509171203; serial number
100; refresh
50; retry
86400 ; expire
3600 ) ; default TTL

4.3.6. Pointer (PTR) Records

Pointer (PTR) records work very similarly to A records, except they perform the function in reverse—PTR records point IP addresses to hostnames and reside in reverse lookup zones.

A sample PTR record in zone file format looks like this:

61.130.98.66.in-addr.arpa. IN PTR alpha.enablehosting.com

4.3.7. Service (SRV) Records

Service (SRV) records indicate the range and availability of services in a particular zone or domain. They catalog the protocols and services running on specific ports in a zone, creating a "Yellow Pages" of sorts for connecting computers to find machines in the zone that will handle their specific types of requests. Like MX records, SRV records have a preference number, so you can perform a kind of poor man's load balancing and fault tolerance with these as well.

SRV records require a bit more explanation because they are so important to Active Directory. Here is an example SRV record in zone file format:

_kerberos._tcp._sites.dc._msdcs 600 SRV 100 88 colossus.hasselltech.net.

The service—in this case, Kerberos—is the leftmost part of the record, and the _tcp refers to whether the service operates on the TCP or UDP transmission protocols. The rightmost part of the record—in this case, colossus.hasseltech.net—identifies the machine that is listening for requests for the service named in the record. The first number in the middle, 600, indicates the time to live (TTL) for that record, recorded in seconds. The rightmost number, 88, refers to the port number on which the service is listening. Finally, 100 refers to the preference number for the record—these work exactly like MX record preference numbers as described in the previous section.

Why are SRV records crucial to Active Directory? Because they indicate which domain machines are running what Active Directory services. Active Directory really looks for only four services to be advertised within SRV records:

_kerberos

To provide user and computer authentications using Kerberos Key Distribution Center (KDC) servers

_kpasswd

To provide a mechanism for changing Kerberos passwords securely

_ldap

For the Lightweight Directory Access Protocol, the way external programs communicate and exchange data with Active Directory

_gc

For the Global Catalog, which contains a subset of attributes for all the objects in an Active Directory forest

A warning that applies from this point forward: even though Microsoft has set up these entries with a leading underscore, you do not want to use either "-" or "_" as the first character in a DNS name, as it is not RFC-compliant. This will cause problems if you ever need to integrate or operate in conjunction with Unix-based BIND DNS servers.


using_primary_and_secondary_nameservers.html

4.4. Using Primary and Secondary Nameservers

DNS has built-in redundancy by allowing for multiple primary and secondary nameservers for a particular domain or zone. Each server, whether identified as primary or secondary, holds a copy of the zone file and acts on its contents. Secondary nameservers can answer queries without any sort of architectural limitation, just as primary nameservers can. However, the secondary nameservers must retrieve updates to zones from the primary nameserver on a regular basis to ensure their records are up-to-date.

Each zone can have only one primary nameserver, but can have as many secondary nameservers as is practical. All changes, deletions, and other modifications to a zone are made on the primary nameserver. However, nameservers designated as secondary nameservers hold read-only copies of the zone contents from their associated primary nameservers—zones can't be directly modified on secondary nameservers. The secondary nameserver will automatically determine the primary nameserver for a zone by examining the SOA records for that zone, and will contact that machine on a regular basis to force a zone file refresh.

Secondary nameservers are not limited to zone transfers from only a primary nameserver; they can accept transfers from other secondary nameservers as well.

Several mechanisms exist to force a zone transfer. For one, all of the secondary nameservers will query the primary nameserver for updates: these refreshes are generally "pull"-style updates, whereby machines fetch zones from a particular computer, rather than "push"-style updates. In addition, when a nameserver identified as secondary for any zone is rebooted or its DNS service is restarted, it will automatically query the primary server on record for an update. You also can force a zone transfer by simply right-clicking the zone inside the DNS Management snap-in on the secondary server and selecting "Transfer from Master" or "Reload from Master," to either refresh changes or refresh the entire zone file, respectively.

Transfers also are triggered by the expiration date and refresh interval, and, indirectly, by the retry interval for a particular zone. The secondary nameserver will query the primary at the time indicated by the refresh interval—this is generally 15 minutes by default, but you might find a compelling reason to change this depending on your network traffic and needs. If the serial number on the SOA record for a zone is higher on the primary nameserver than on the secondary nameserver's zone record, the transfer will take place. However, if the secondary nameserver can't contact the primary nameserver at the time the refresh interval has elapsed, the secondary nameserver will wait for the amount of time specified in the retry interval and then try again. If further attempts fail, at the time listed in the expiration date section of the record, the secondary nameserver will simply stop answering DNS requests, lest it give inaccurate and obsolete information to clients.

4.4.1. Full and Incremental Zone Transfers

A relatively new DNS RFC, 1995, now allows for incremental zone transfers (known in shorthand as IXFRs), which remove one of the largest stumbling blocks of DNS administration. It used to be that when a zone refresh was needed, DNS couldn't discriminate the changes made on the primary server: even if only one line of a 6,000-line zone file had changed, the entire zone needed to be transferred to the secondary machines in a process commonly referred to as a full zone transfer (or AXFR). Although that process wasn't a big deal if you had only one secondary nameserver, it became a large headache for organizations with tens or hundreds of secondary nameservers spread across the country or world. With the advent of RFC 1995, nameservers now have the ability to detect the differences between two zone files and transfer only the changed information—saving bandwidth, transfer time, and CPU power.


building_a_nameserver.html

4.5. Building a Nameserver

In this section, I'll guide you through the process of actually creating a nameserver, and then in the remainder of the chapter I'll add to the functionality of the nameserver to prepare it for use with Active Directory.

Nameservers need a constant connection to the Internet and a non-changing IP, either set statically on the server itself or delivered consistently through a DHCP reservation. The machine you're building out as a nameserver doesn't need to be that powerful; a fast Pentium III machine with 512 MB or so of RAM will be more than sufficient.

In the following examples, I will use the fictitious domain name hasselltech.net, with the also fictitious machine name "colossus" and IP address 192.168.0.5. You can, of course, replace these as appropriate when following along with your own computer.

The first step is to install the nameserver software onto your Windows Server 2008 computer. To do so, follow these steps:

  1. Open Server Manager.

  2. In the left pane, click Roles, and then in the right pane, click Add.

  3. Click Next in the Add Roles Wizard.

  4. Find DNS Server in the list, check its box, and click Next.

  5. Click Next on the "Introduction to DNS Server" screen.

  6. Click Install, wait for the process to complete, and then close the Add Server Roles box.

If you have your computer set up to receive an IP address via DHCP, the DNS Server role installation will complain loudly that DNS isn't intended to work on dynamically assigned IP addresses. For this example, we can acknowledge the warnings and continue. As mentioned previously, make sure nameservers that are actually in production—not a test environment—have a consistent, unchanging IP address.

Next, point your new nameserver to itself for name resolution so that when you run tests, you're not querying your ISP's nameservers. In fact, most nameservers point to themselves, rather than to other nameservers, for name resolution. I recommend setting this through the command line using the netsh command, like so:

netsh int ip set dns "Local Area Connection" static 192.168.0.5 primary

You can replace Local Area Connection with the name, as it appears in your network connection properties, of your network connection. Also, replace 192.168.0.5 with the local nameserver's IP.

Of course, you also can change the nameservers to use for name resolution through the Windows interface by following these steps:

  1. Inside the Control Panel, double-click the Network Connections applet.

  2. Inside the Network Connections dialog box, right-click the name of your network connection and choose Properties from the context menu.

  3. Navigate to the General tab, and then select Internet Protocol (TCP/IP).

  4. Click the Properties button.

  5. Click the "Use the following DNS server address" radio button, and then enter the nameserver's IP address into the box.

  6. Click OK.

Now that the DNS server software is installed, you need to start the DNS service. Select Start, then click Administrative Tools and select DNS. The DNS Management snap-in will appear, as shown in Figure 4-1 (although it will not have all of the Forest Lookup Zones shown in the figure).

Figure 4-1. The DNS Management snap-in

We'll manually set up DNS later in this chapter, so ignore the message to use the Configure Your DNS Server Wizard. At this point, you have a functional nameserver, which performs "caching-only" functions—that is, it doesn't hold any DNS information unique to itself, but it does know how to contact the 13 root servers as held by ICANN, the master of DNS on the Internet, and it can resolve Internet addresses by contacting them. Windows Server 2008's DNS software knows how to do this by default, without any configuration on your part.

4.5.1. Enabling Incremental Transfers

Windows Server 2008's DNS component is compliant with RFC 1995 and can do incremental transfers (as mentioned earlier, known as IXFRs in DNS parlance) with other Windows Server 2003 or Windows Server 2008 servers supporting the feature. It can also still do the old-style full zone transfers, referred to as AXFRs, with noncompliant nameservers and with non-Windows Server 2003 or Windows Server 2008 machines. There is no way to instruct Windows Server 2008 to always send full zone files to all servers, regardless of whether they are compliant. You can, however, tell Windows to send incremental zone transfers to all supporting servers, regardless of whether they run Windows Server 2003 or Windows Server 2008. Here's how:

  1. Open the DNS Management snap-in.

  2. Right-click your server and select Properties from the context menu.

  3. Navigate to the Advanced tab, and uncheck the box labeled BIND Secondaries.

  4. Click OK to finish.

Now the server will use incremental zone transfers to all supporting servers, not just to those running Windows Server 2003 or Windows Server 2008.

4.5.2. Creating a Forward Lookup Zone

Now, to further configure your server, let's create a forward lookup zone file. Inside the DNS snap-in, expand the server name in the lefthand pane. Then do the following:

  1. Right-click Forward Lookup Zones and select New Zone. The New Zone Wizard appears.

  2. Choose Primary Zone, and then click Next.

  3. Enter the zone name. In this example, I'll use hasselltech.net. Click Next to continue.

  4. Enter a name for the new zone file, which is stored in ASCII format. The default name is your domain with .DNS appended to the end—hasselltech.net.dns, for example. The zone files are stored in %SystemRoot%\system32\dns. Click Next.

  5. On the Dynamic Update screen, choose to allow both insecure and secure dynamic updates. I'll discuss dynamic DNS updating in a later section. Click Next.

  6. Click Finish to complete the zone creation process.

The hasselltech.net zone has now been created.

4.5.3. Entering A Records into a Zone

Inside the DNS snap-in, right-click the hasselltech.net node in the lefthand pane and choose New Host (A) from the context menu. The New Host dialog box appears, as shown in Figure 4-2.

Figure 4-2. Entering a new A record

Enter the hostname of the machine for which you're entering the record, and then enter the IP address of the machine. As you enter the hostname, the fully qualified domain name (FQDN) will adjust to show the full hostname, including the domain, to check your work. You also can check the "Create associated pointer (PTR)" record checkbox, which enters a PTR record into the reverse lookup zone, if one is currently configured. (If none is set up, the process will throw an error.) Click OK.

4.5.4. Controlling Round-Robin Balancing

You can enable or disable round-robin DNS balancing using the nameserver's Advanced Properties screen, which you'll find by right-clicking the nameserver name in the DNS Management Snap-in's lefthand pane and selecting Properties from the context menu. Figure 4-3 shows this screen, on the Advanced tab of the Properties sheet.

Figure 4-3. Advanced properties of a DNS server

Check "Enable round robin" in the "Server options" box to enable round robin, and uncheck it to disable it.

DNS round-robin functionality is enabled on a per-server level, not on a per-zone level.

Also, if you want to turn off the subnet mask ordering feature, uncheck "Enable netmask ordering" in the "Server options" box, which is on the Advanced Properties screen, as shown in Figure 4-3.

4.5.5. Entering and Editing SOA Records

A default SOA record is created when you create a new zone in Windows Server 2008. To modify an SOA record, double-click it in the DNS Management snap-in. The screen will look something like Figure 4-4.

Figure 4-4. SOA record properties for a zone

Here are descriptions of the various fields on this tab:

Serial number

The serial number indicates whether the SOA record has changed since the last update on the part of a nonauthoritative nameserver. If you want to change this number, click the Increment button; you can't simply edit the field.

Primary server

This field denotes the primary, authoritative nameserver for this zone.

Responsible person

This field indicates the administrator responsible for configuring and editing this zone. This is the administrator's email address, but with a period in place of the normal at sign (@) and a period appended to the end of the string. For example, if your administrator is hostmaster@hasselltech.net, in this field you would enter hostmaster.hasselltech.net.

Refresh interval

The refresh interval indicates to secondary nameservers how long they can keep their copies of the zones before being required to request a refresh.

Retry interval

The retry interval indicates how long the secondary nameserver must wait before attempting to contact the authoritative nameserver again after a failed attempt to refresh its zone after the refresh interval has lapsed.

Expires after

This value essentially indicates how long a zone file is valid for use in production environments. It dictates how long a secondary nameserver will continue attempting a zone transfer from its primary nameserver. When this expiration date is reached, the zone on the secondary nameserver expires, and that server stops responding to queries.

Minimum (default) TTL

This value indicates to other nameservers how long they can use information they've previously retrieved from this nameserver before being required to consult the authoritative server again for updated or refreshed information. This is, by default, 60 minutes. You also can set TTL values for individual records that override this minimum default setting for a zone.

TTL for this record

This value overrides the minimum (default) TTL as described earlier and is limited to only this SOA record.

4.5.6. Creating and Editing NS Records

NS records, as you learned earlier in this chapter, link the hostnames of nameservers to their IP addresses. To create these records, inside the DNS Management snap-in right-click the zone file in question and select Properties. Then select the Name Servers tab. You'll be greeted with the screen shown in Figure 4-5.

Figure 4-5. Editing NS records for a zone

The primary NS record is displayed, as it was created by default when you first constructed the zone. Click the Add button to insert a new NS record—for example, for a secondary nameserver. In the box that appears, type in the new machine's fully qualified domain name and click the Resolve button. Windows Server 2008 uses a reverse lookup to determine the IP address of the hostname you entered. If you agree with its finding, click the Add button beside the IP address and the NS record will be entered. Click OK twice to close.

4.5.7. Creating and Editing CNAME Records

Recall that CNAME records map different hostnames to pre-existing A records, allowing multiple DNS names for a host. To create these records, right-click the hasselltech.net node in the lefthand pane of the DNS Management snap-in and choose New Alias (CNAME) from the context menu. The New Resource Record dialog box appears, as shown in Figure 4-6.

Figure 4-6. Entering a new CNAME record

Enter the aliased name of the machine for which you're entering the record (this is the canonical name), and then enter the fully qualified domain name of the host you're aliasing. As you enter the CNAME, the fully qualified domain name field just below will adjust to show the full hostname, including the domain, to check your work.

Click OK to finish.

4.5.8. Creating and Editing MX Records

As you'll remember from earlier in this chapter, MX records dictate how mail is delivered to a specific DNS zone. To create these records, inside the DNS snap-in right-click the hasselltech.net node in the lefthand pane and choose New Mail Exchanger (MX) from the context menu. The New Resource Record dialog box appears, as shown in Figure 4-7.

Figure 4-7. Entering a new MX record

Enter the name of the domain or zone for which you're entering the record, and then enter the fully qualified domain name of the host to which mail for that domain or zone should be delivered. As you enter the CNAME, the fully qualified domain name field just below will adjust to show the full hostname, including the domain, to check your work. Finally, in the Mail server priority box, type the MX preference number that should apply to this record.

Click OK to close.

4.5.9. Generating a Reverse Lookup Zone

You learned earlier in this chapter that reverse lookup zones map IP addresses to their corresponding hostnames. To create these records, inside the DNS Management snap-in right-click the Reverse Lookup Zones folder and choose New Zone from the context menu. You'll be presented with the New Zone Wizard. Click Next to bypass the introductory screen, and you'll see Figure 4-8.

Figure 4-8. Creating a new reverse lookup zone

Then follow these steps:

  1. Choose "Primary zone," and click Next.

  2. Enter the network numbers for your network in the Network ID field—for example, 192.168.0.0—and then click Next.

  3. The Dynamic Updates page appears. Select to allow both insecure and secure updates, and then click Next.

  4. Click Finish to complete the wizard.

Your reverse lookup zone has been created.

4.5.10. Creating and Editing PTR Records

Remember that PTR records map IP addresses to their hostnames and are vital within a reverse lookup zone. To create these records, right-click the appropriate reverse lookup zone within the DNS Management snap-in and select New Pointer (PTR) from the context menu. The New Resource Record dialog will appear, as shown in Figure 4-9.

Figure 4-9. Entering a new PTR record

On this screen, all you need to do is enter the last dotted quad of a specific IP address, and then enter the hostname to which that address should refer. The FQDN for the reverse lookup record will fill in automatically.

Click OK to finish.

4.5.11. Configuring a Secondary Nameserver

In this section, I'll cover creating a secondary nameserver to serve a zone. Some preliminary steps are necessary, though: first, the machine should be running Windows Server 2008, and it should have the DNS service installed, as mentioned before. The machine's network connection should be configured so that its preferred nameserver is itself. (Also, for the purposes of this section, the secondary nameserver will be called ns2.hasselltech.net at IP address 192.168.0.6.)

To proceed:

  1. Open the DNS Management MMC snap-in.

  2. Right-click Forward Lookup Zones and select New Zone from the context menu. The New Zone Wizard will appear; click Next to skip the introductory screen.

  3. Choose Secondary to create a secondary lookup zone, which will indicate to Windows that this should be a secondary nameserver. Click Next.

  4. Enter the name of an existing zone on the Zone Name screen, and click Next.

  5. Specify the nameservers from which Windows can fetch the existing zone files. Simply enter the primary nameserver in the box, click Add, and then click Next, as shown in Figure 4-10.

  6. Click Finish to create the zone.

Figure 4-10. Specifying a primary DNS server for a secondary DNS zone

4.5.12. Upgrading a Secondary Nameserver to Primary

Perhaps you decide, upon acquiring a new business into your organization, that you need more horsepower in responding to DNS queries. Or, perhaps eventually you'd like to cluster your DNS servers. In these cases, you would want to promote some secondary nameservers to primary status. It's an easy process to promote an existing secondary nameserver to a primary nameserver.

  1. Open the DNS Management snap-in.

  2. Right-click the zone folder that you want to convert, and select Properties from the context menu.

  3. Navigate to the General tab, as shown in Figure 4-11.

    Figure 4-11. Promoting a DNS server

  4. To the right of the Type entry—it should now say either Primary or Secondary—click the Change button. The Change Zone Type screen will appear, as shown in Figure 4-12.

    Figure 4-12. Changing a server from primary to secondary

  5. Click the "Primary zone" radio button to perform the promotion.

  6. Click OK.

The server will now be a primary server for that zone.

4.5.13. Manually Editing Zone Files

All zone files are stored in %SystemRoot%\system32\dns. The files are stored in the format <domain>.dns (e.g., hasselltech.net.dns). You can edit them with your favorite text editor or with a script that you can write to perform large-scale and/or automated machine rollouts.

When you directly edit zone files, make sure you manually increment the serial number value in the zone's SOA record. You can increment by any value. Otherwise, the changes are likely to be missed by any secondary nameservers during a zone transfer.

4.5.14. Controlling the Zone Transfer Process

For obvious reasons, you'll find it necessary to control which machines can perform a zone transfer from nameservers—after all, users at large on the Internet have no legitimate need to retrieve a full copy of your zones, and having a full record of your connected machines is a rather significant security breach. In Longhorn Server, this process is locked down by default. To verify this, open the DNS Management snap-in and expand the nameserver's name. Find a zone under Forward Lookup Zones, right-click it, and choose Properties. Click over to the Zone Transfers tab. You'll see the screen depicted in Figure 4-13.

Figure 4-13. Controlling zone transfers

You see that you can disallow zone transfers wholesale by unchecking the box labeled "Allow zone transfers." However, if you choose to enable them to have secondary nameservers, you can lock down the access to those zone files a bit more granularly. The first option, "To any server," leaves the transfer process wide open. The second option, "Only to servers listed on the Name Servers tab," seems to be the most reasonable option by restricting transfer to the servers identified as authoritative for the domain on that tab. The third option, "Only to the following servers," can lock down that list even further. Simply select the option, enter an IP address into the box, and click Add when you're done. Make the list as long or short as it needs to be, and then finish the process by clicking OK.

Windows Server 2008 also supports a feature listed in RFC 1996 known as zone modification notification, which nearly contradicts what I wrote earlier about the zone transfer process being primarily a pull, rather than a push, process. Click the Notify button on the Zone Transfer tab to explore this feature; you'll be greeted with the screen in Figure 4-14.

Figure 4-14. Notify dialog screen

The notification feature will contact the servers listed on this Notify screen when changes are made to the zone file on the primary nameserver. You can have the server contact the authoritative nameservers for a zone or domain as listed on the Name Servers tab, or contact only the servers in the list that you create on this screen. (To create this list, simply enter an IP address and click Add. Repeat as necessary to build the list.) Click OK when you've configured or disabled this feature as you wish.


subdomains_and_delegation.html

4.6. Subdomains and Delegation

It's rare to find an organization running its own DNS that is small enough to not take advantage of subdomains and delegation. By delegation, I mean letting one group, whether logical or physical, administer a section of an organization's network. Let's take a look at an example.

Perhaps my company has two offices: one in Boston and the other in Charlotte, North Carolina. Although I have an overarching domain name, mycompany.com, I might want to delineate these two locations within my network—I can call all machines in Boston with the north.mycompany.com domain suffix and all machines in Charlotte with the south.mycompany.com domain suffix. Because the respective IT groups at each location have a better sense of which machines are going in and out of the network at their own offices than a central group of administrators at the headquarters site, the decision was made to let each office's group administer DNS within each subdomain. To make this happen, there are three steps to follow: first, the overarching domain's DNS zone needs to be told there will be a subdomain that will be administered elsewhere. Second, the overarching (in technical terms, the "root" but not the ultimate TLD-root) nameserver needs the address of the subdomain's nameserver for its records. And finally, the subdomain's nameserver needs to be installed and configured.

4.6.1. Delegating a Domain

Inside the DNS Management snap-in, right-click the zone that is the parent of the subdomain you want to create (e.g., mycompany.com), and select New Delegation from the pop-up menu. The New Delegation Wizard appears; click past the introductory screen to the Delegated Domain Name Screen. Here, simply enter the subdomain you want to create and delegate in the top box. The bottom box will expand to show the full domain name of what you entered. Click Next to move on. On the next screen, enter the name of the subdomain you'd like to delegate, and click Next.

The Name Servers screen appears, as shown in Figure 4-15.

Figure 4-15. Identifying delegated nameservers

On this page, insert the fully qualified domain name and IP address of the nameservers that will be responsible for the new domain. Just click Add to enter these on the New Resource Record screen that will appear. When you're finished, click OK, and then click Next. Click Finish to complete the wizard. The newly delegated domain will appear in the DNS Management snap-in, but it will be grayed out to indicate its delegated status.

How does this process modify the actual zone files within the DNS service? For one, it adds new NS records to the parent domain to indicate the server responsible for a particular subdomain. For example, if I were delegating the fully qualified subdomain north.mycompany.com with a nameserver at dns1.north.mycompany.com, the resulting record would look like this:

north NS dns1.north.mycompany.com

Next, the delegation wizard adds an A record to the parent zone so that it can find the new nameserver via its IP address, like this:

dns1.north A 192.168.1.105

This A record is known as a glue record because it is the only way DNS and requesting clients would know the IP address of the delegated nameserver—after all, the primary zone no longer holds information on and controls that zone. The A record eliminates that problem and provides a direct way to get in touch with that delegated nameserver.

When Delegation Goes Lame

Lame delegation is the condition when an NS record points to an incorrect machine. This can be caused when a zone is delegated to a server that has not been properly configured as an authoritative nameserver for that zone, or an authoritative nameserver for a zone has an NS record that points to another machine that is not authoritative for the zone.

When lame delegation occurs, these nameservers direct queries to servers that will not respond authoritatively, if at all. This causes unnecessary network traffic and extra work for servers. According to the Domain Health Survey, 25% of all zones have lame delegations.

I'll talk about a utility later in this chapter, called DNSLint, that can help you detect lame delegations and fix them.

4.6.2. Creating the Subdomain

Logically, creating the subdomain you've just delegated is very simple. From the delegated server, inside the DNS Management snap-in, you can right-click the Forward Lookup Zones folder and choose New Zone. From there, just follow the instructions in the "Creating a Forward Lookup Zone" section, earlier in this chapter.


dynamic_dns.html

4.7. Dynamic DNS

Dynamic DNS is Windows Server 2008's way of bringing together the one good feature of WINS—automatic machine registration and record updating—with the resiliency and open standards advantage of DNS, a staple of the Internet. With dynamic DNS, machines running Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2008 can register their presence automatically with the nameserver that controls the zone associated with their connection's DNS suffix. In the case of the examples so far in this chapter, if I have a machine named sales1.north.mycompany.com, this computer would automatically register an A record for that hostname and IP address with the nameserver that controls north.mycompany.com—a handy feature, indeed.

Figure 4-16 shows the actual flow of dynamic DNS registration when a workstation needs to register itself.

Figure 4-16. The flow of dynamic DNS registration

The process works a bit different when IP addresses are assigned by a Windows DHCP server. The client, when it receives its IP address from the DHCP server, only registers an A record in the nameserver's forward lookup zone. The DHCP server by default is responsible for registering the PTR records in the nameserver's reverse lookup zone, if one exists.

If you want to alter this behavior, you can configure the DHCP server to take care of both parts of the registration by looking on the properties sheet for the DHCP scope in question within the DHCP snap-in.

Open the DHCP snap-in, expand your machine in the left pane, and then click Scopes. In the right pane, select the scope you want to alter and then right-click it and select Properties. Now, navigate to the DNS tab and select Always Update DNS. The DHCP server will register A records in the forward lookup zone and PTR records in the reverse lookup zone for all clients leasing an address.

When does this registration take place? Five possible actions will trigger a DNS registration on the part of the client:

  • The computer has been restarted.

  • The computer's DHCP lease, if the machine uses a dynamic IP address, has just been renewed.

  • The computer's statically assigned IP address has been changed.

  • A full 24 hours have passed since the last DNS registration on record.

  • An administrator issues the ipconfig /registerdns command from the command line.

Although the default period for reregistering DNS dynamically is 24 hours, you can change this value inside the Registry on the client. On the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters key, add a new REG_DWORD entry called DefaultRegistrationRefreshInterval, and give it a value in seconds. (For reference, there are 86,400 seconds in a day.)

4.7.1. Scavenging

Obviously, with multiple machines registering DNS information periodically throughout the day, you need to clean up that information when it expires. The Windows Server 2008 DNS scavenging process finds the dynamically registered records that haven't been updated for some time, and then simply deletes them to ensure that after a delay for propagation between servers, the zone information contains the most up-to-date data on the machines and addresses therein.

Let's take a look at how scavenging is presented in the user interface and how you can best control it. To control scavenging for all zones on a particular nameserver, right-click the server's name from the DNS Management snap-in and select Set Aging/Scavenging for All Zones. The Server Aging/Scavenging Properties screen appears, as shown in Figure 4-17.

Figure 4-17. Setting dynamic DNS scavenging

At the top of the screen, you see the master switch to enable or disable scavenging. Additionally, you see two options. One of them is for the no-refresh interval, which is simply the time a dynamically registered record should be allowed to stay registered in a "read-only" fashion before the scavenger can take a look at it. This means client computers cannot reregister themselves during this period. The other option is for the refresh interval, which is the amount of time a record should remain and be allowed to be refreshed after the no-refresh interval has passed before the scavenger should remove it. In essence, the scavenger process is not allowed to touch a record unless both the no-refresh and the refresh intervals have passed in full.

To enable scavenging, check the top checkbox and click OK. If you have Active Directory-integrated zones, you'll be asked to confirm your choice for those as well. Click OK once again, and scavenging will be enabled. Another step remains—you need to enable scavenging on the nameserver, which you can do by right-clicking the server name inside DNS Management, selecting Properties, and clicking the Advanced tab. This is shown in Figure 4-18.

Figure 4-18. Setting up scavenging on the server

At the bottom of the screen, check the checkbox labeled "Enable automatic scavenging of stale records," and then enter a period of time after which the scavenger can automatically engage.

If you want to control scavenging and its associated intervals for an individual zone, right-click the zone inside DNS Management and select Properties. Then, navigate to the General tab and click the Aging button. The screen is identical to the server-wide scavenging control screen shown in Figure 4-17.

For the scavenging service to do the mathematics required to calculate these intervals, the DNS service adds a nonstandard bit of information to a resource record's zone information. For instance, an A record on a server or zone with scavenging enabled might look like this:

colossus [AGE:47363030] 36400 192.168.0.5

The AGE portion is the inception point of the record, measured in some small interval since a certain date. How that number is determined is unimportant; what matters is that with scavenging enabled, the AGE information is added to a DNS record so that the no-refresh and refresh intervals can be honored correctly. You can see that timestamp in a human-readable format by right-clicking any record in the DNS Management snap-in and selecting Properties. The Record timestamp field will show the date and time the record was created in DNS, as shown in Figure 4-19.

To view the record timestamp, select Advanced from the View menu of the console.

Figure 4-19. Viewing a record's timestamp in the GUI

4.7.2. Preventing Dynamic DNS Registration

If your organization hasn't deployed Active Directory yet, the dynamic DNS registration default settings that modern Windows client operating systems have can be aggravating to IT groups—your nameservers will be pelted, sometimes forcefully, with registration attempts from Windows systems that believe that for an Active Directory in your organization, they need to register themselves. Of course, that's not necessarily true, but it's the default behavior.

Fortunately, you can turn this off, either through a Registry change (to make the modification on a larger scale) or through the GUI. To do so through the GUI, follow these steps:

  1. Open the connection's properties.

  2. On the Network tab, select TCP/IP, and then click the Properties button.

  3. Navigate to the DNS tab.

  4. Uncheck "Register this connection's addresses in DNS."

  5. Click OK.

To do so through the Registry, open the Registry Editor, and then take the following steps:

  1. Navigate through HKEY_LOCAL_MACHINE\CurrentControlSet\Services\TcpIp.

  2. Click the Parameters key.

  3. Add a new value, of type REG_DWORD, called DisableDynamicUpdate.

  4. Set the value of the new entry to 1.

Alternatively, you can type the following at the command line:

reg add hklm\system\currentcontrolset\services\tcpip\parameters /v
DisableDynamicUpdate /t REG_DWORD /d 1 /f

You also can use Group Policy (GP) to deploy a policy that disables this to all machines in a domain, or to a subset of those machines, but GP in this case necessitates Active Directory. In any case, the proper object is under Computer Configuration/Administrative Templates/Network/DNS client. The object is called Dynamic Update, and to turn it off, change the state to Disabled. Chapter 6 covers GP in more detail.


active_directory-integrated_zones.html

4.8. Active Directory-Integrated Zones

Up to this point, I've treated the Windows Server 2008 DNS service as a traditional nameserver, mostly compliant with the relevant RFCs, which can act in both primary and secondary "modes" for a zone. However, Windows Server 2008 offers a third mode specific to Windows that, although not listed in an RFC, offers some distinct advantages if you've made an infrastructure investment in Active Directory and Windows.

The third mode, Active Directory-integrated DNS, offers two pluses over traditional zones. For one, the fault tolerance built into Active Directory eliminates the need for primary and secondary nameservers. Effectively, all nameservers using Active Directory-integrated zones are primary nameservers. This has a huge advantage for the use of dynamic DNS as well: namely, the wide availability of nameservers that can accept registrations. Recall that domain controllers and workstations register their locations and availability to the DNS zone using dynamic DNS. In a traditional DNS setup, only one type of nameserver can accept these registrations—the primary server, because it has the only read/write copy of a zone. By creating an Active Directory-integrated zone, all Windows Server 2008 nameservers that store their zone data in Active Directory can accept a dynamic registration, and the change will be propagated using Active Directory multimaster replication, something you'll learn about in Chapter 5. All you need to do to set up this scenario is install Windows Server 2008 on a machine, configure it as a domain controller, install the DNS service, and set up the zone. It's all automatic after that. Contrast this with the standard primary-secondary nameserver setup, where the primary server is likely to be very busy handling requests and zone transfers without worrying about the added load of dynamic DNS registrations. Active Directory-integrated zones relieve this load considerably. And to add to the benefits, Active Directory-integrated zones support compression of replication traffic between sites, which also makes it unnecessary to use the old-style "uncompressed" zone transfers.

As you read in the previous section, part of the dynamic DNS functionality provided in Windows Server 2008 is the scavenger process. Recall the no-refresh interval function, which was created to eliminate exorbitant amounts of traffic being passed between domain controllers for each DNS re-registration.

Active Directory-integrated zones also afford a big security advantage, in that they provide the capability to lock down dynamic DNS functionality by restricting the ability of users and computers to register records into the system—only computers that are members of the Active Directory domain that hosts the DNS records can add and update records dynamically to these zones. However, to have an Active Directory-integrated zone, your nameservers must be domain controllers for an Active Directory domain. If other nameservers are used that are not domain controllers, they can act only as traditional secondary nameservers, holding a read-only copy of the zone and replicating via the traditional zone transfer process.

If you're already running a nameserver that is a domain controller with an active zone in service, it's easy to convert that to an Active Directory-integrated zone. (And for that matter, it's easy to revert to a primary or secondary zone—this isn't a be-all and end-all.) Here's how to go forward:

  1. Open the DNS Management snap-in.

  2. Right-click the zone folder you want to convert, and select Properties from the context menu.

  3. Navigate to the General tab, as shown in Figure 4-20.

    Figure 4-20. Converting a zone to Active Directory-integrated mode

  4. To the right of the Type entry—it should now say either Primary or Secondary—click the Change button. The Change Zone Type screen will appear, as shown in Figure 4-21.

    Figure 4-21. Storing a zone in Active Directory

  5. Check the "Store the zone in Active Directory" checkbox.

  6. Click OK.

You'll note that your options expand once you've converted to Active Directory-integrated zones. Go back to the zone's properties, and on the General tab, note a couple of things:

  • The Dynamic Updates field now allows Secure Only updates.

  • You have options for replicating zone changes throughout all domain controllers in Active Directory.

Let's focus on the latter for a moment.

4.8.1. Replication Among Domain Controllers

Windows Server 2008 allows you to tune how Active Directory replicates DNS information to other domain controllers. (While I'll present AD in all of its glory in Chapter 5, I'll cover this briefly here.) Click the Change button beside the Replication field on the zone properties, and you'll be presented with the Change Zone Replication Scope screen, as shown in Figure 4-22.

Figure 4-22. Controlling DNS replication in Active Directory

The default setting is "To all domain controllers in the Active Directory domain," which instructs Windows to behave exactly as it did in Windows 2000 Server: replicate DNS information to all domain controllers in Active Directory, regardless of whether they're actually running the DNS service. Obviously, if you have 20 domain controllers in your domain, but only 3 domain controllers that run DNS, this is a lot of replication traffic that is just wasted. On this screen, you can select to replicate the DNS information only to domain controllers running DNS in either the forest or the domain. This is very helpful, and for large organizations, it should cut down on WAN traffic.


forwarding.html

4.9. Forwarding

Forwarding, in the simplest terms, is the process by which a nameserver passes on requests it cannot answer locally to another server. You can make forwarding work to your advantage so that you effectively combine the resolver caches for many nameservers into one. By doing this, you allow clients to resolve previously retrieved sites from that "mega-cache" before requiring a true refresh lookup of the information from authoritative nameservers on the public Internet.

Here's how it works. DNS behavior by default is to consult the preferred nameserver first to see whether it has the necessary zone information for which the client is searching. It doesn't matter to the client if the preferred nameserver has the zone information but isn't authoritative; having the information is enough for the client, and it takes the returned results and makes the connection. But if the server doesn't have the zone recorded in its files, it must go upstream, to the public Internet, to ask other nameservers for the zone information that's needed. This takes time because it adds a delay to the initial resolution while the preferred nameserver is searching the Internet for the answer. However, after the nameserver looks up the information once, it stores it in its cache of resolved names so that the next user looking for the same resolver information doesn't incur that delay: the preferred nameserver can simply answer out of its cache and return the data nearly instantaneously.

Forwarding takes this cache and expands it to multiple nameservers. Consider an organization with four or five nameservers. Clients likely will have different preferred nameservers, set to one of each of those four or five. So, when one client wants information that's not in her nameserver's cache, her preferred nameserver will search it out and return it, and all future users of that particular preferred nameserver will get information for that zone returned out of its cache. But the other users in the organization won't be able to take advantage of that cached entry because they're likely using other machines as their preferred nameservers.

A forwarder comes in and adds an extra step to this process: if the preferred nameserver doesn't have zone information in its cache, it will ask a separate server, known as the forwarder, if it has information on the requested zone. The forwarder is simply another nameserver that looks up zone information on the Internet and stores it in its own cache for easy reference. So, if all nameservers in an organization are configured to ask the same forwarder for cached information if it has some, all of those nameservers are taking advantage of the forwarder's cache and the near-instantaneous response the forwarder can give to resolution requests. Again, the forwarder acts like a regular nameserver in all respects; it's just that other nameservers in an organization are configured so that they can use the forwarder's cache. If, however, the forwarder machine takes too long to respond to a request, the original preferred nameserver can take over and make a request to the Internet itself, so you don't lose the ability to resolve DNS requests—you're only making it more efficient. You also can have more than one forwarder for your organization if you're worried about a single point of failure, but you lose a bit of the advantage because you're again using more than one cache database.

Now, to set up forwarding:

  1. Open the DNS Management snap-in on the machine you want to set up to forward requests elsewhere.

  2. Right-click the server name and choose Properties from the context menu.

  3. Navigate to the Forwarders tab, and then in the "Selected domain's forwarder IP address list" field, enter the IP address to which requests should be forwarded. This is shown in Figure 4-23.

    Figure 4-23. Setting up a forwarding DNS system

  4. Also as shown in Figure 4-23, enter "5" in the "Number of seconds before forward queries time out" field. Five seconds is a standard number that ensures efficient name resolution if the forwarders somehow fail at their task.

  5. Click Apply to complete the process.

4.9.1. Slaving

Slaving is a logical extension to the forwarding process. Servers slaved to a specific nameserver forward requests to that server and rely entirely on that server for resolution; in plain forwarding, on the other hand, the original nameserver can resolve the request itself after a timeout period by querying the root nameservers. With slaving, the upstream nameserver becomes the proxy through which all slaved nameservers make their requests.

This is useful mainly in situations where you need multiple nameservers within your organization to handle Active Directory- and internal-related tasks, but you want outside requests to stay outside the firewall. You can set up one very secure nameserver and place it outside your firewall and internal network, allowing it to service requests from the inside to the outside and from the outside to certain machines within the network. Then, you can slave the internal machines to the one machine outside the firewall, making them depend entirely on the machine in the hostile environment but keeping that environment out of your internal network and away from the many nameservers you administer locally. Because most firewalls are stateful inspection machines that only allow packets inside the firewall that are in response to communications initiated internally, and because your internal nameservers query only the external nameserver and not the Internet itself, the public has no reason to know that your internal nameservers exist, and no ability to get to them, either.

Setting up slaving, as opposed to forwarding, involves only one extra checkbox. To enable slaving, follow these steps:

  1. Open the DNS Management snap-in on the machine you want to set up to slave to another server.

  2. Right-click the server name and choose Properties from the context menu.

  3. Set up forwarding first. Navigate to the Forwarders tab, and then in the "Selected domain's forwarder IP address list" field, enter the IP address to which requests should be forwarded. This is shown in Figure 4-24.

    Figure 4-24. Setting up a slaved DNS system

  4. Also as shown in Figure 4-24, enter "5" in the "Number of seconds before forward queries time out" field. Five seconds is a standard number that ensures efficient name resolution if the forwarders somehow fail at their task.

  5. Now, check the "Do not use recursion for this domain box" at the bottom of the screen. This slaves the server to the forwarders listed in the box above.

  6. Click Apply, and then OK, to complete the process.

4.9.2. Conditional Forwarding

There might be occasions, especially when using the split DNS architecture technique that I'll cover in the next section, where you want to assign certain nameservers to answer queries for specific domains that your users ask for. Conditional forwarding can be useful for many reasons, including increasing the speed of name resolution for clients to effect a structural DNS change in a case of company acquisitions or divestitures.

Conditional forwarding is supported only in Windows Server 2003 and Windows Server 2008.

The Forwarders tab inside the DNS Management snap-in holds multiple lists of domains and their associated forwarders specifically to accommodate the conditional forwarding feature. To set up conditional forwarding, follow these steps:

  1. Open the DNS Management snap-in on the machine you want to set up for conditional forwarding.

  2. Right-click the server name and choose Properties from the context menu.

  3. Navigate to the Forwarders tab, and then click the New button to the right of the DNS domain box.

  4. In the New Forwarder box, enter the name of the DNS domain to configure forwarding for, and then press OK.

  5. Click the new domain within the DNS domain list, and then in the "Selected domain's forwarder IP address list" field, enter the IP address to which requests should be forwarded. This is shown in Figure 4-25.

  6. In the "Number of seconds before forward queries time out" field, enter "5".

    Figure 4-25. Setting up a conditionally forwarded DNS system

  7. Leave the "Do not use recursion for this domain box" at the bottom of the screen unchecked because you don't want to slave your nameserver permanently to a forwarder for only certain domains.

  8. Click Apply, and then OK, to complete the process.


the_split_dns_architecture.html

4.10. The Split DNS Architecture

Now that you have a good background on the special DNS techniques you can use, let's discuss a very common and fairly secure way to deploy DNS within your organization: using the split DNS architecture.

As I've briefly mentioned previously in this chapter, the split DNS architecture scenario consists of a set of internal nameservers that are used within the corporate computing environment in daily operations. There are also one or more nameservers facing externally to the Internet that outsiders use to connect to your corporation's electronic services, but that are separated from the internal nameservers for security purposes. Outsiders who query for information from your external nameservers won't be able to obtain information on your internal network structure and composition because the external nameserver is completely separate from the internal nameservers that hold this data. The external nameservers hold records only for externally facing servers and not for your entire internal domain. This technique is called the split DNS architecture because DNS information is split between the inside and the outside of an organization.

Split DNS is a great way to deploy Active Directory-compatible DNS services within your organization, but it isn't the only way to deploy DNS.

4.10.1. Stub Zones

Now is the time to introduce a new type of zone, introduced in Windows Server 2003, called the stub zone. Stub zones contain only a subset of the information contained in a regular forward or reverse lookup zone. Specifically, a stub zone contains the SOA record, any pertinent NS records, and the A records for the nameservers that are authoritative for that zone, and nothing more. Stub zones are useful for creating split DNS infrastructures, where internal machines service internal DNS requests and external DNS requests are serviced elsewhere, perhaps at a datacenter or Internet service provider.

Now, how do stub zones and conditional forwarding play into the split DNS architecture? In a couple of ways: for one, you might do business with an organization that occasionally needs to access systems that reside within your corporate firewall, not outside of it. Because the external nameservers have no information on your internal systems, there's no default way to use split DNS to allow outsiders to resolve canonical names within your firewall. To resolve this, you use stub zones, placed on the internal nameserver of the corporation with whom you're doing business, which again contain only NS and SOA records of your internal nameservers. That way, when people query for resources that you host, they go to their local nameservers, and their local nameservers see the stub zones placed there about your organization with the proper name and IP address for your nameservers. In essence, any organization that hosts a stub zone for your domain always will know the names and addresses of your nameservers. Best of all, regular zone transfers will make sure the information inside these stub zones is kept up-to-date, but of course you must have permission to conduct these zone transfers.

Conditional forwarding operates very similarly to stub zones, except that where stub zones simply contain information about a foreign domain's nameservers, conditional forwarding is used on the local nameserver to directly forward requests for information to the foreign nameserver. Unlike stub zones, conditional forwarders don't automatically update when information changes, so manual intervention is required if you need to change the addresses or names of the foreign nameserver; however, you don't need any special permissions on the foreign nameserver to use conditional forwarding because no zone transfers are involved. Some overhead is involved with conditional forwarding, however, if you have a large list of names to forward; the server has to check each and every request against this list, and if you have a large load on the server, this can slow down response time considerably for everyone hitting that particular server. For just a few zones, however, conditional forwarding can be the best solution, and it can be done without the foreign DNS hostmaster or administrator knowing or approving.

Both of these techniques are a major part of the split DNS architecture strategy. Let's take an example corporation—one that intends to use Active Directory and is deploying DNS with that in mind—with a primary and secondary nameserver for the external side of the infrastructure and a second set of primary and secondary nameservers for the internal side. A basic diagram of this infrastructure is shown in Figure 4-26.

Figure 4-26. How split DNS architecture is laid out

Note that the first set of primary and secondary nameservers is outside the corporate firewall, and they take care of any external requests that come for the domain. In fact, the registrar that has the corporation's domain registration lists these two nameservers as authoritative for that domain. However, the zone files on these servers are static—they list only a few, rarely changing items, which could be web, FTP, and mail servers. This is really all the public needs to know.

There are two points to note about this portion of the scenario:

  • The external nameservers are not authoritative for the internal, Active Directory-based DNS structure. They are authoritative only for external, Internet-based requests.

  • If your ISP has been providing hosting for your nameservers, there's no reason it can't continue doing so. In fact, this is simpler to administer than hosting both sets of nameservers on your own premises.

Now let's focus on the internal nameservers for this corporation. The primary nameserver on the internal side is configured as the primary nameserver for the internal zone and is instructed to accept dynamic DNS updates from internal workstations and servers. However, these internal servers are blind (at this point) to the fact that outside the firewall, another set of nameservers is holding the same zone name with different records. In addition, the workstations within the business are configured to think of the authoritative nameservers for the domain as the internal servers; this is where they will register themselves via dynamic DNS, and also where they will first look to resolve Internet names.

So, how do internal users resolve names on the Internet if they can't see the external set of nameservers? It's easy—the internal primary and secondary nameservers are configured to forward Internet requests to the external primary nameserver. So, if the address being requested by the client isn't in the internal nameserver's cache (meaning it hasn't been requested recently by another client), it will ask the external nameserver for the answer. No zone transfers are involved—it's just straight forwarding, as I covered earlier in this chapter. But how might external users resolve internal DNS names? The short answer is: they won't. That's a security feature. Because the external users know only about the external nameservers, and the external nameservers know only about themselves and not the internal nameservers, there's no way for the external nameservers to report any information about internal DNS records inside the firewall.

The only problem you might run into is when internal users attempt to access the company's own resources on the external side of the firewall; to allow this, simply add a static record to the internal nameservers that points to the correct external resource. You don't introduce any security problems that way because there's still no "window" for external users to see into your internal structure.

So, in essence, you have a DNS architecture "split" between internal and external nameservers. If you're looking to reproduce this architecture, the following summarizes the correct procedure:

  1. Create two sets of servers—one for in front of the firewall, and one for behind it. Install the DNS service on both.

  2. Make every nameserver point to itself for its own DNS information; you do this within the network card properties where you indicate the IP address. There's no need to configure a secondary nameserver for each of these.

  3. Copy any external records your internal users might need to the internal zone. This includes web, mail, and FTP servers. Remember, if you don't do this, your users won't be able to resolve the names of anything outside the firewall.

  4. Configure external forwarders—these are the machines to which your internal nameservers will forward requests so that your internal users can resolve Internet names.

  5. Slave the internal set of nameservers to these external forwarders you created in the previous step. This shields them from the Internet's blinding eye.

  6. Configure all machines on the internal network to use only the internal nameservers. This allows them to register with Active Directory if appropriate and to find internal resources, which they couldn't find if directed to the external nameservers outside the firewall.

4.10.2. Security Considerations

Split DNS architecture is implemented with security in mind, but you can always take more steps to harden those DNS systems. You've already taken two steps in this process: for one, slaving the internal nameservers to the external forwarders eliminates the possibility that if the firewall of some other transmission problem prevents the external forwarder from responding, the internal nameserver will conduct its own search of the Internet. You obviously don't want your internal nameservers touching anything on the outside of the firewall except those external forwarders.

The other step is the use of the firewall to separate the two sets of nameservers from each other. You need to ensure that the firewall that protects the perimeter of your corporate network from the Internet is configured correctly and locked down as tightly as possible. I recommend Building Internet Firewalls, Second Edition (O'Reilly), by Zwicky et al., for detailed and thorough guidance on this topic. You'll especially want to ensure that only a few ports—such as the DNS port, 53—are open.

Other than that, this architecture is fairly secure right after implementation.


backup_and_recovery.html

4.11. Backup and Recovery

If you thought configuring DNS in the first place was difficult, you'll find the backup and recovery procedures refreshingly simple. There are two locations in the Registry to back up the DNS service and one directory on the physical filesystem.

The following procedure won't work with Active Directory-integrated zones, as the zone files are within the directory service and are not available on the filesystem.

To back up a server that's hosting one or more primary or secondary DNS zones, follow these steps:

  1. On the nameserver, stop the DNS service using the Services applet in the Control Panel or through the command line.

  2. Open the Registry Editor (select Start/Run, type regedit, and press Enter).

  3. Navigate to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS key.

  4. Right-click the DNS folder, and from the context menu, choose Export.

  5. When prompted for a filename, enter DNS-CCS, and choose an appropriate location that is off the server.

  6. Now, navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS server key.

  7. Right-click the DNS Server folder, and from the context menu, choose Export.

  8. Name this file DNS-CV, and again choose a location that is not on the current server. These two files will be DNS-CCS.REG and DNS-CV.REG.

  9. Now, using Windows Explorer, navigate to the %SystemRoot%\System32\dns directory on the boot drive.

  10. Find all files with the .DNS extension, select them, and then copy them to the same location that you exported DNS-CCS.REG and DNS-CV.REG.

Your DNS service is now completely backed up. Restart the DNS service to continue using it.

To restore a set of DNS configuration files, install a Windows Server 2008 machine and use the same computer name, DNS suffix, and IP address. Be sure to install the DNS service. Then copy all of the .DNS files from your backup to the %SystemRoot%\System32\dns directory, and stop the DNS service. Double-click DNS-CCS.REG and confirm that you want its contents imported into the Registry; do the same for DNS-CV.REG. Finally, restart the DNS service, and your replacement server should function normally.

If you want to move only the primary role for a particular zone from one nameserver to another, simply copy the .DNS file for that zone to the target computer. Run the New Zone Wizard as described earlier in this chapter, and then instruct it to use a pre-existing zone file.


command-line_utilities-id1.html

4.12. Command-Line Utilities

In this section, I'll describe some useful programs designed to run from a command line that you can use to automate your DNS setup and configuration processes.

4.12.1. DNSCmd

The Windows Server 2008 Support Tools collection, described earlier in the book, contains the DNSCmd utility, which is a great way to access some command DNS configuration-related functions through the power and speed of the command prompt. To get to DNSCmd, look in the Support\Tools directory on the Windows Server 2008 distribution CD for the file support.cab. Inside, copy and paste DNSCmd to a convenient location.

DNSCmd displays and changes the properties of DNS servers, zones, and resource records. Some operations of this tool work at the DNS server level while others work at the zone level. You can use DNSCmd on any Windows 2000 or XP computer, as long as the user that is running the application is a member in the Administrators or Server Operators group on the target computer. Both the user account and the server computer must be members of the same domain or reside within trusted domains.

DNSCmd can be used in any of the following situations, in which you want to:

  • Retrieve information about a DNS server

  • Begin the scavenging process

  • View information and contents of a DNS zone

  • Create, remove, or "pause" zones

  • Change the properties of a zone

  • Add, delete, and enumerate records in a zone

You use DNSCmd simply by specifying attributes and their values as part of a command. For example, to create a new standard primary zone called corp.hasselltech.local on a server named dc1.corp.hasselltech.local and stored in corp.hasselltech.local.dns files, use the following syntax:

Code View:
dnscmd dc1.corp.hasselltech.local /ZoneAdd corp.hasselltech.local /Primary /file
corp.hasselltech.local.dns

I could have also chosen to make corp.hasselltech.local a secondary zone by replacing the /Primary switch with /Secondary.

To create a new A record, I could issue the following command, which adds a record for a machine named www to the zone with an IP address of 192.168.1.23 to the same DNS server as in the previous example:

Code View:
Dnscmd dc1.corp.hasselltech.local /RecordAdd corp.hasselltech.local www A 192.168.1.23

You can see all of the zones on a target server by entering the following command:

dnscmd dc1.corp.hasselltech.local /enumzones

If you're experiencing some problems with replication and want to trigger the process manually, you can start it with the following command (assuming you want to use the same server to begin the process as in the previous examples):

Dnscmd dc1.corp.hasselltech.local /ZoneRefresh corp.hasselltech.local

Likewise, you might find yourself needing to manually age all of the records on a particular machine. You can easily do so through DNSCmd using the following:

dnscmd corp.hasselltech.local /ageallrecords dc1.corp.hasselltech.local

You'll need to confirm your choice, and then the current time will be applied to all records on that machine.

You might also need to clear the DNS cache on a target server, which can be done using this command:

Dnscmd dc1.corp.hasselltech.local /clearcache

To quickly stop and start the DNS process on the target computer, use the following command:

Dnscmd dc1.corp.hasselltech.local /restart

If you want to export a particular zone to a file, you can issue the following command:

dnscmd /zoneexport corp.hasselltech.local corp.hasselltech.local.dns

And finally, to delete a zone from a target server, use the following command:

dnscmd dc1.corp.hasselltech.local /zonedelete corp.hasselltech.local

4.12.2. DNSLint

DNSLint is also on the distribution CD in support tools. DNSLint is a utility born out of the desire to automate the process of troubleshooting lame delegation issues and problems with AD replication because of faulty DNS records. DNSLint is a great tool to make sure that every DNS server that has records on your services has correct records and that there are no issues with those DNS servers' data. (And in case you're wondering, the name DNSLint comes from the idea that lint is something you find in your blue jeans after they come out of the dryer. When you find lint, it is useless and perhaps even embarrassing, meaning you probably quickly discard it. You should do the same with outdated or inaccurate DNS records for critical machines on your network.)

The best thing to do from the start is to create a standard report on any given DNS domain, using the following:

dnslint /d hasselltech.local /v

DNSLint produces an HTML-based report and then starts Internet Explorer to display the result. The results are color-coded with warnings in amber and errors in red for easy scanning. (You can elect to get a text-based report, if you prefer.) The report generated by the previous command will show a detailed listing of each DNS server for the corp.hasselltech.local domain and indicate whether the server responds to a query on port 53, which is the standard DNS port. It will tell you how it found each server, and it will also list each server that reports authoritatively. You will also see Mail Exchanger records in the zone, which is useful for troubleshooting SMTP routing problems.

If you are specifically having email difficulties, you can use DNSLint to determine whether a designated email server listens on the correct port. Use the following command:

dnslint /d domainname.tld /c

The report generated by that command lists whether a server indicated in an MX record is listening for SMTP, POP3, and IMAP4 requests, and will also show the SMTP header returned by the server to help in diagnostics.

To assist in troubleshooting, the following functions are available in DNSLint:

dnslint /d domainname

This diagnoses potential causes of "lame delegation," covered earlier in this chapter, and other related DNS problems. You'll receive an HTML-based report once the checking diagnosis is complete. Add /v for more information about how the DNS servers listed in the report were found. If you get errors saying that the domain specified is not listed with InterNIC, simply add the /s option.

dnslint /ql mylist.txt

This verifies a user-defined set of DNS records on multiple DNS servers. You can specify in a simple text file the sets of records you'd like to test. For example, the following tests A, PTR, CNAME, and MX records for the domain name and IP address of a fairly well-known company:

microsoft.com,a,r       ;A record
207.46.197.100,ptr,r    ;PTR record
microsoft.com,cname,r   ;CNAME record
microsoft.com,mx,r      ;MX record

dnslint /ad localhost

This verifies the DNS records on a specific host (in this case, the current machine) specifically used for Active Directory replication. If you get errors saying that the domain specified is not listed with InterNIC, simply add the /s option.


the_last_word-id3.html

4.13. The Last Word

In this chapter, you saw how DNS is crucial to network communications among machines, and particularly to those who participate in Windows domains. DNS is such a core component of Active Directory that it was important to learn about it in depth before introducing Active Directory itself. In the next chapter, I'll look at how Active Directory works and how it relies on DNS as its foundation.


active_directory.html

Chapter 5. Active Directory

In Windows NT, administrators were introduced to the concept of domains. Active Directory Domain Services (AD DS) builds on that concept by creating a dynamic, easily accessible structure through which directory and management information can be stored and accessed centrally throughout an organization. By using AD DS, you create a structure for managing your equipment and the people who use that equipment, which is a helpful feature for all but the smallest of operations.

By using Active Directory as a whole, you have access to several cool management tools, including Group Policy (GP), the ability to put groups inside groups multiple times, and an online directory of users, computers, printers, and contacts that you can access easily through the Windows user interface. Although you certainly can operate a Windows-based network without Active Directory deployed in some form, you lose out on a lot of functionality. You will learn about these tools in this chapter and the next.

In this chapter, I'll introduce you to Active Directory and its concepts, walk you through the process of building an AD DS domain and tree structure, guide you through the process of managing domain users and groups, and discuss in detail the process of directory content replication. I'll also discuss different roles that domain controllers take in an AD DS environment, the importance of time synchronization and how to accomplish it, and how to keep your AD DS deployment in tiptop shape through regular maintenance.

There's a lot to cover in this chapter, so let's dig in.

5.1. Active Directory Domain Services Objects and Concepts

First it's important to learn that you can divide AD DS components into two "states of being"—physical components, which include domain controllers, sites, and subnets; and logical components, which include forests, trees, domains, and organizational units. Physical and logical components of AD DS don't necessarily have to correlate with each other: for example, a domain controller can be a member of a forest based in Rome, while actually sitting in a machine room in Chicago.

Keep that frame of reference in mind. Now, before diving in any further, let me introduce a few common terms:

Directory

A directory is a single repository for information about users and resources within an organization. Active Directory is a type of directory that holds the properties and contact information for a variety of resources within a network so that users and administrators alike can find them with ease.

Domain

A domain is a collection of objects within the directory that forms a management boundary. Multiple domains can exist within a forest (defined later in this list), each with its own collection of objects and organizational units (also defined later in this list). Domains are named using the industry-standard DNS protocol, covered in detail in the previous chapter.

Domain controller

A domain controller holds the security information and directory object database for a particular domain and is responsible for authenticating objects within their sphere of control. Multiple domain controllers can be associated with a given domain, and each domain controller holds certain roles within the directory, although for all intents and purposes all domain controllers within a domain are "equal" in power. This is unlike the primary and backup labels assigned to domain controllers in Windows NT.

Forest

A forest is the largest logical container within AD DS and encompasses all domains within its purview, all linked together via transitive trusts that are constructed automatically. This way, all domains in a particular forest automatically trust all other domains within the forest.

Organizational unit

An organizational unit (OU) is a container with objects (discussed next) contained within it. You can arrange OUs in a hierarchical, tree-like fashion and design them in a structure that best fits your organization for boundary delineation or ease of administration.

Object

Within AD DS, an object is anything that can be part of the directory—that is, an object can be a user, a group, a shared folder, a printer, a contact, and even an OU. Objects are unique physical "things" within your directory and you can manage them directly.

Schema

The schema in AD DS is the actual structure of the database—the "fields," to use a not-quite-applicable analogy. The different types of information stored in AD DS are referred to as attributes. AD DS's schema also supports a standard set of classes, or types of objects. Classes describe an object and the associated properties that are required to create an instance of the object. For example, user objects are "instances" of the user class; computer objects are "instances" of the computer class; and so on. Think of classes as guideline templates describing different types of objects.

Site

A site is a collection of computers that are in distinct geographical locations—or at least are connected via a permanent, adequate-speed network link. Sites are generally used to determine how domain controllers are kept up-to-date; AD DS will select its methodology for distributing those updates (a process called replication) based on how you configure a site to keep traffic over an expensive WAN link down to a minimum.

Tree

A tree is simply a collection of domains that begins at a single root and branches out into peripheral, "child" domains. Trees can be linked together within forests as well, and trees also share an unbroken DNS namespace—that is, hasselltech.local and america.hasselltech.local are part of the same tree, but mycorp.com and hasselltech.local are not.

Trust

A trust in terms of AD DS is a secure method of communicating between domains, trees, and forests. Much like they worked in Windows NT, trusts allow users in one AD DS domain to authenticate to other domain controllers within another, distinct domain within the directory. Trusts can be one-way (A to B only, not B to A), transitive (A trusts B and B trusts C, so A trusts C), or cross-linked (A to C and B to D).

5.1.1. Domains

When examining AD DS for the first time, it's easiest to examine the domain first because so much of the basis of AD DS is derived from the domain. It's adequate to boil down the function of domains into three basic areas:

  • Consolidating lists of usernames and passwords for all machines within a domain and providing an infrastructure for using that consolidated list

  • Providing a method of subdividing objects within a domain for easier administration (into OUs, as described earlier)

  • Offering a centralized, searchable list of resources within the domain so that users and administrators can easily query that list to find objects they need

Domains, at a minimum, keep a list of all authorized users and their passwords on a machine or groups of machines called domain controllers. This list is stored in AD DS. However, many other objects are stored within the directory—which is actually a file on a domain controller's hard drive called NTDS.DIT—including sites, OUs, groups of users, groups of computers, GPOs (described in Chapter 6), and contacts, just to name a few.

The engine that drives this database of information is the same engine within Microsoft's powerhouse Exchange Server product, and it supports the transmission of database contents to multiple domain controllers over network links—a process called replication. Replication answers the question of how multiple domain controllers within a domain can contain the same information. For example, if you have a domain controller in Seattle and another in Charlotte, and you were to add a user in Charlotte, what if that user tried to log on to a computer in Seattle? How would the Seattle domain controller know about the user added in Charlotte? Replication allows AD DS to transmit changed data across a domain to all relevant domain controllers so that the contents of the directory are always up-to-date on each domain controller.

At this point, astute readers who are familiar with the domain structure of Microsoft's Windows NT products surely are asking, "What about PDCs and BDCs?" For the most part, Microsoft has removed that designation from domain controllers in AD DS environments, meaning that with only a couple of minor exceptions, all domain controllers are equal. This is referred to as a multimaster environment.

Because a domain controller holds a large database of information, AD DS has some interesting characteristics that weren't necessarily true of NT 4.0's Security Accounts Manager (SAM)-based list of accounts. For instance, programmers can write code to interface directly with AD DS and run queries to pull data from the database. These programmers can use either the Lightweight Directory Access Protocol (LDAP), an industry-standard protocol for accessing any sort of directory, or the Microsoft-specific Active Directory Services Interface (ADSI) for taking advantage of AD DS features not supported directly within the LDAP specification. Additionally, AD DS doesn't have the same size limitations that the SAM had. AD DS easily can handle up to a few million objects, as compared to the SAM's ability to handle no more than about 5,000 accounts. (That's scalability, folks!) AD DS is also fast when handling large amounts of data, so you won't get bogged down when your directory grows.

5.1.2. Organizational Units

A domain can be an awfully big, comprehensive unit to manage, and most environments benefit from some mechanism to separate that large, unitary domain into smaller, more manageable chunks. An organizational unit is AD DS's way of doing that. Organizational units, or OUs, act like folders on a regular client's operating system, containing every type of object that AD DS supports. You might choose to separate your domain into OUs in one of these ways:

  • A university might create a domain with a name corresponding to the entire university (ncsu.edu, for example), with each college in that institution getting an OU (biology, physics, mathematics, etc.).

  • A medium-size business might use one domain for all of its AD DS needs, but segregate objects into their geographical locations—an OU for the Los Angeles office, an OU for the Birmingham office, and an OU for the Richmond office.

  • Larger corporations might want to divide their domain by department. Within business.com, for example, an OU could be created each for Sales, Support, Marketing, Development, and Q/A.

  • An administrator also could decide to create OUs based on the type of objects contained therein—for example, a Computers OU, a Printers OU, and so on.

A particularly interesting feature of OUs is the ability to delegate administrative control over them to a subset of users in AD DS. Take, for instance, the third example in the previous list. Perhaps you, as the domain administrator, want to designate one technically savvy person in each department as the official Password Change Administrator, to reduce your administrative load. You can delegate the authority to modify users' passwords to each user over only their respective OU, thereby both allowing them power but finely controlling it over certain areas of your AD DS infrastructure. This ability is called delegation, and you'll find an entire section devoted to it later in this chapter.

OUs are designed to be containers in AD DS—their purpose is to hold objects and to have contents. You can apply GPs to the objects within a specific OU (as you'll see in Chapter 6), controlling users' desktops, locking them out of potentially dangerous system modification settings, and creating a consistent user experience across your domain.

5.1.3. Sites

Sites are great ways to manage the use of bandwidth for AD DS replication across WAN links. All domain controllers in an AD DS domain must stay in contact with one another at regular intervals to acquire and transmit the changes that have occurred to their databases since the last update. Otherwise, information becomes "stale" and the directory is no good to anyone. However, this replication traffic can be costly if you have domain controllers in different countries and you use slow WAN links to keep in contact with your various offices.

By designating different sites with AD DS, a process we'll cover later in the replication section of this chapter, you can tell AD DS to compress the replication traffic to allow it to be transmitted more quickly, and you can give preferences to certain WAN links over others by using the "cost" feature, specifying a higher value for a connection you want to use less often and a lower value for a connection you'd like to use the most often. It's a great way to manage your telecommunications expenses while still taking advantage of the better management features of AD DS.

In a domain environment, the Distributed File System, which you learned about in Chapter 3, also uses AD DS's site structure to control file replication traffic.

5.1.4. Groups

The point of groups is to make assigning attributes to larger sets of users easier on administrators. Picture a directory with 2,500 users. You create a new file share and need to give certain employees permissions to that file share—for example, all accounting users. Do you want to take a hard-copy list of all members of the accounting department and hand-pick the appropriate users from your list of 2,500? Of course you don't. Groups allow you to create an object called Accounting and insert all the appropriate users into that group. So, instead of selecting each individual user from a large list, you can pick the Accounting group, and all members of that group will have the same permissions on the file share.

There are four different scopes of groups within Windows Server 2008 and AD DS, and each scope can nest groups differently. Let's outline the group scopes first, and then bear with me as I explain the concepts of each:

Machine local groups

Machine local groups contain objects that pertain only to the local computer (or more specifically, to objects contained within the local computer's SAM database). These types of groups can have members that are global groups, domain local groups from their own domain, and universal or global groups from their own domain or any other domain that they trust.

Domain local groups

Domain local groups can be created only on a domain controller, so ordinary client computers or member servers of a domain cannot host domain local groups. Domain local groups can be put inside machine local groups within the same domain (this is a process called nesting). They can contain global groups from a domain that trusts the current domain and other domain local groups from the same domain. As you will see later in the chapter, they are of limited utility unless you are working in a larger, multidomain environment.

Domain global groups

Like domain local groups, domain global groups can be created only on a domain controller, but domain global groups can be put into any local group of any machine that is a member of the current domain or a trusted domain. Domain global groups can also be nested in other global groups; however, all nested domain global groups must be from the same domain. Domain global groups are great tools that contain all the functionality of domain local groups, and more, and they are the most common type of group used across a domain.

Universal groups

Universal groups are a sort of "do-it-all" type of group. Universal groups can contain global and universal groups, and those nested groups can be from any domain in your AD DS forest.

Briefly, I'll also mention that there are two types of groups: a security group is used for the purposes of assigning or denying rights and permissions, and a distribution group is used for the sole purpose of sending email. A security group, though, can also act as a distribution group.

5.1.4.1. Nesting

Nesting is a useful ability that has been around in limited form since Windows NT. By nesting groups, you achieve the ability to quickly and painlessly assign permissions and rights to different users. For example, let's say you have a resource called COLORLASER and you want all full-time employees to be able to access that resource. You don't have a group called FTEs that contains all your full-timers throughout your organization, but your departmental administrators have set up a structure wherein full-time employees are put into groups and part-timers are in another. To quickly create your overall FTE group, you can take your different groups of users from each department (ACCTG_FTE, ADMIN_FTE, PRODUCTION_FTE, and SALES_FTE, for example) and put them within a new group you create called ALL_FTE. Then, you can quickly assign access rights to COLORLASER by giving the ALL_FTE group permission to use the resource. You have "nested" the departmental groups within one big group.

Different types of groups, as you saw in the previous list of groups, support different methods of nesting. Table 5-1 shows the relationships between the types of groups and the respective abilities to nest.

Table 5-1. Nesting by group type
Type of nesting | Machine local | Domain local | Domain global | Universal
Within themselves | Yes | Yes (from the same domain) | Yes (from the same domain) | Yes
Within other types None Machine local Machine local

Domain local

Universal 		Machine local

Domain local

Domain global

You should remember a couple of important issues regarding backward compatibility with Windows NT 4.0 and Windows 2000 and the types of group capabilities available:

  • AD DS cannot support universal groups until you operate at least in Windows 2000 Native functional level, as NT 4.0 supports only one level of group nesting.

  • A group cannot have more than 5,000 members until your forest is operating in the Windows Server 2003 forest-functional level or higher. Functional levels are covered later in this chapter, but for now, be aware of this limitation.

5.1.5. Trees

Trees refer to the hierarchies of domains you create within AD DS. The first AD DS domain you create is automatically designated the root of your first tree, and any domains after that are considered child domains unless you choose to create a domain at the root of a new tree. Child domains always have the root domain in their name—for example, if I create the hasselltech.local domain, any child domains must be in the format of newdomainname.hasselltech.local. In effect, you are creating what are referred to as subdomains in DNS parlance. You can create as many child domain levels as you need; children can be children of other children of other children, and so on, as long as it makes sense to you.

A neat feature of AD DS is that it automatically creates two-way trust relationships between parent and child domains, so you don't need to manually trust the domains you create. As such, my new child domain from our earlier example will automatically trust its parent domain, hasselltech.local, and the parent will trust the child—the transitive trust is created automatically. This type of trust is passed along the child domain chain, so a domain like charlotte.eastcoast.us.northamerica.enterprise.com will automatically trust eastcoast.us.northamerica.enterprise.com, us.northamerica.enterprise.com, northamerica.enterprise.com, and enterprise.com.

5.1.6. Forests

Forests, in the simplest terms, are just groups of trees. All trees in a forest trust each other automatically. Think of a forest as an extended family, and individual domain trees as brothers. If you have five brothers in a family, each child of those brothers trusts his immediate brothers, and (usually!) each brother's family trusts the other brother's family—cousins typically get along. Forests just refer to collections of domain trees that trust one another.

There are two caveats, though, which are fairly significant and bear mentioning:

  • The only way to add a domain to a tree is to create it completely from scratch, adding it to an existing tree at that time. It's the same with trees—you can't directly add an existing tree to an existing forest without deleting and subsequently re-creating it.

  • Likewise, two existing, separate domains can't be linked together as parent and child. For example, hasselltech.local created on one network and charlotte.hasselltech.local created on another, separate network cannot be joined later as parent and child. The child would need to be re-created or migrated.

5.1.6.1. Transitive forest root trusts

The latter of the preceding two limitations might be frustrating for you, and you're not alone. Fortunately, what experts might term an "official hack" is available to effectively graft existing domains together into a tree-like structure so that trusts are established. Although it's not as easy and not as flexible as a forest—AD DS makes things slick and easy when you do things its way—it will work, with effort and maybe a bit of luck. The tool is called a transitive forest root trust, and with it, you can make two disparate forests trust each other.

Let's say I have a forest called businessone.com. Business One purchases another organization with an AD DS forest created already, known as businesstwo.net. Recall that I can't just graft businesstwo.net onto the already existing forest at Business One. However, with a transitive forest root trust, I can make it so that businessone.com trusts businesstwo.net, achieving some of the benefits of one unified forest. However, there are limitations and disadvantages:

  • Each forest must be operating in at least the Windows Server 2003 forest functional level. Although I will cover this later, suffice it to say that all domain controllers in each domain in each forest must be running Windows Server 2003, if not Windows Server 2008. This might be a prohibitive expense.

  • You'll learn more about this feature later in this chapter, but keep this in mind for now: a transitive forest root trust does not automatically make one, unified global catalog. Two separate forests still equals two separate global catalogs.

  • Transitive forest root trusts do not flow through. For example, businessone.com and businesstwo.net trust each other. But if businessone.com buys businessthree.org and a trust is set up there, businesstwo.net will not trust businessthree.org automatically—another trust will need to be set up. With that, we're back to the kludgy trust process found in Windows NT 4.0.

So, transitive forest root trusts aren't the answer to everything, but they are a reasonably effective way to create a "pseudoforest" within already existing trees.

5.1.6.2. The dedicated forest root model

You also can create a hedge against future AD DS changes if you are deploying Active Directory for the first time. If a department in your organization deploys AD DS ahead of other departments, as the other groups come on board, they effectively become subordinates of that first domain. How does a smart administrator get around that problem? The dedicated forest root model provides a way to maintain the autonomy of multiple domains that you create. Figure 5-1 shows how this is achieved.

Figure 5-1. How the dedicated forest root model enables separate NT domains to be separate in AD DS

A dedicated forest root domain can be either an "empty domain," which contains only a small number of universal users and resources, or a normal production domain that just happens to be at the root of a forest. The latter is not recommended. An empty forest root domain that does not serve as a production domain is advantageous for several reasons. For one, the domain administrators group in the root domain has power over the forest, which is something you might not want. Keeping the root empty allows you to delegate administrative authority to individual domains without giving everything away, a security protection that keeps honest administrators honest. It also helps you to structure your AD DS environment; a constant root makes further changes logical and easy to implement and manage—for instance, if you acquire a new company or build a new office. The forest root domain, if kept empty, is very easy to replicate and to back up. And if you ever make changes to the administrative authority in your business, you can transfer the keys to the kingdom to others without affecting the administrators' autonomy of your child domains.

You can name the empty forest root domain anything you want—even emptyroot.local. It is only a placeholder. However, most clients use a domain name based on their company's domain name.

However, the key to the empty root strategy is to keep the root empty: have it contain only one administrative account—the Enterprise Administrator, which is, of course, created by default when you create the first domain in a new forest—and use that only when absolutely necessary. Then, create all the domains you need under that first domain and you won't have one particular domain in your organization unnecessarily holding Enterprise Admin-style accounts.

Of course, this method has its downsides. Costs definitely are involved: for one, you need a separate license of Windows Server 2008 for your dedicated forest root domain controller, and you have the burden of administrative responsibility in ensuring that the root domain is kept up, patched, and the like. However, if you are in a high-growth industry and your organization is likely to make acquisitions and divestitures within the near future, it's best to use this method to hedge against major changes to AD DS structure.

5.1.7. Shared Folders and Printers

As you saw in Chapter 3, the concept of shared folders and printers within AD DS merely relates to a "pointer" residing within the directory, guiding users to the real location on a physical filesystem of a server for a particular shared directory, or the location of a print share on a print server. This process is known as publishing a share (or publishing a printer).

The point of publishing shares and printers in AD DS is to make them available for searching, either through AD DS Users and Computers for administrators or through Start rightwards double arrow Search or Start rightwards double arrow Find for client users. You can search for shared folder or printer names containing target keywords, and their locations will be populated within the results box.

5.1.8. Contacts

Contacts are simply objects in the directory that represent people and contain attributes with indicators as to how to contact them. Contacts neither represent users of any directory, nor convey any privileges to log on to the network or use any network or domain resources.

The point of the contacts object is to create within AD DS a phonebook of sorts, with names of vital business contacts that reside outside your organization—partners, customers, vendors, and the like. Because AD DS as a directory can be queried by the LDAP protocol, which most groupware applications support, the contents of contacts objects likely can be accessed directly within that application.

5.1.9. Global Catalog

The global catalog, in an AD DS environment, acts as a sort of subset directory that is passed among all domains in a particular forest. Consider that AD DS gives you the ability to connect to any computer in your particular AD DS tree. If you have a small organization, this isn't much of a problem, but in a large organization with many domains, can you imagine the performance lag while AD DS tries to (a) find the correct domain where your account resides, then (b) communicate with it, and finally (c) log you in? You would be waiting for a significant amount of time for all the pieces of the puzzle to come together in a complex AD DS implementation.

For that reason, AD DS constructs a subset of all the domains in a forest and puts it into what's called the global catalog (GC). The GC contains a list of all domains in the forest and a list of all the objects in those domains, but only a subset of the attributes for each object. This is a fairly small bit of information compared to the rest of the directory, and because of its reduced size, it is easy to pass on to given domain controllers in the forest. As a result, when a user connects to a computer in any given domain in a forest, the nearest domain controller checks the username against the GC and instantly finds the correct "home" domain for a user and the authentication process can begin. Think of the GC, therefore, as an index of your directory, much like the index of this book helps you to see which pages cover a topic in which you're interested.

The GC also contains the name of each global group for every domain in the forest, and it contains the name and the complete membership list of every universal group in the forest (recall that universal groups can contain users and other groups from any domain in the forest). So, limit your use of universal groups, lest you decrease the performance of your users' logins.


active_directory_domain_services_object.html

Chapter 5. Active Directory

In Windows NT, administrators were introduced to the concept of domains. Active Directory Domain Services (AD DS) builds on that concept by creating a dynamic, easily accessible structure through which directory and management information can be stored and accessed centrally throughout an organization. By using AD DS, you create a structure for managing your equipment and the people who use that equipment, which is a helpful feature for all but the smallest of operations.

By using Active Directory as a whole, you have access to several cool management tools, including Group Policy (GP), the ability to put groups inside groups multiple times, and an online directory of users, computers, printers, and contacts that you can access easily through the Windows user interface. Although you certainly can operate a Windows-based network without Active Directory deployed in some form, you lose out on a lot of functionality. You will learn about these tools in this chapter and the next.

In this chapter, I'll introduce you to Active Directory and its concepts, walk you through the process of building an AD DS domain and tree structure, guide you through the process of managing domain users and groups, and discuss in detail the process of directory content replication. I'll also discuss different roles that domain controllers take in an AD DS environment, the importance of time synchronization and how to accomplish it, and how to keep your AD DS deployment in tiptop shape through regular maintenance.

There's a lot to cover in this chapter, so let's dig in.

5.1. Active Directory Domain Services Objects and Concepts

First it's important to learn that you can divide AD DS components into two "states of being"—physical components, which include domain controllers, sites, and subnets; and logical components, which include forests, trees, domains, and organizational units. Physical and logical components of AD DS don't necessarily have to correlate with each other: for example, a domain controller can be a member of a forest based in Rome, while actually sitting in a machine room in Chicago.

Keep that frame of reference in mind. Now, before diving in any further, let me introduce a few common terms:

Directory

A directory is a single repository for information about users and resources within an organization. Active Directory is a type of directory that holds the properties and contact information for a variety of resources within a network so that users and administrators alike can find them with ease.

Domain

A domain is a collection of objects within the directory that forms a management boundary. Multiple domains can exist within a forest (defined later in this list), each with its own collection of objects and organizational units (also defined later in this list). Domains are named using the industry-standard DNS protocol, covered in detail in the previous chapter.

Domain controller

A domain controller holds the security information and directory object database for a particular domain and is responsible for authenticating objects within their sphere of control. Multiple domain controllers can be associated with a given domain, and each domain controller holds certain roles within the directory, although for all intents and purposes all domain controllers within a domain are "equal" in power. This is unlike the primary and backup labels assigned to domain controllers in Windows NT.

Forest

A forest is the largest logical container within AD DS and encompasses all domains within its purview, all linked together via transitive trusts that are constructed automatically. This way, all domains in a particular forest automatically trust all other domains within the forest.

Organizational unit

An organizational unit (OU) is a container with objects (discussed next) contained within it. You can arrange OUs in a hierarchical, tree-like fashion and design them in a structure that best fits your organization for boundary delineation or ease of administration.

Object

Within AD DS, an object is anything that can be part of the directory—that is, an object can be a user, a group, a shared folder, a printer, a contact, and even an OU. Objects are unique physical "things" within your directory and you can manage them directly.

Schema

The schema in AD DS is the actual structure of the database—the "fields," to use a not-quite-applicable analogy. The different types of information stored in AD DS are referred to as attributes. AD DS's schema also supports a standard set of classes, or types of objects. Classes describe an object and the associated properties that are required to create an instance of the object. For example, user objects are "instances" of the user class; computer objects are "instances" of the computer class; and so on. Think of classes as guideline templates describing different types of objects.

Site

A site is a collection of computers that are in distinct geographical locations—or at least are connected via a permanent, adequate-speed network link. Sites are generally used to determine how domain controllers are kept up-to-date; AD DS will select its methodology for distributing those updates (a process called replication) based on how you configure a site to keep traffic over an expensive WAN link down to a minimum.

Tree

A tree is simply a collection of domains that begins at a single root and branches out into peripheral, "child" domains. Trees can be linked together within forests as well, and trees also share an unbroken DNS namespace—that is, hasselltech.local and america.hasselltech.local are part of the same tree, but mycorp.com and hasselltech.local are not.

Trust

A trust in terms of AD DS is a secure method of communicating between domains, trees, and forests. Much like they worked in Windows NT, trusts allow users in one AD DS domain to authenticate to other domain controllers within another, distinct domain within the directory. Trusts can be one-way (A to B only, not B to A), transitive (A trusts B and B trusts C, so A trusts C), or cross-linked (A to C and B to D).

5.1.1. Domains

When examining AD DS for the first time, it's easiest to examine the domain first because so much of the basis of AD DS is derived from the domain. It's adequate to boil down the function of domains into three basic areas:

  • Consolidating lists of usernames and passwords for all machines within a domain and providing an infrastructure for using that consolidated list

  • Providing a method of subdividing objects within a domain for easier administration (into OUs, as described earlier)

  • Offering a centralized, searchable list of resources within the domain so that users and administrators can easily query that list to find objects they need

Domains, at a minimum, keep a list of all authorized users and their passwords on a machine or groups of machines called domain controllers. This list is stored in AD DS. However, many other objects are stored within the directory—which is actually a file on a domain controller's hard drive called NTDS.DIT—including sites, OUs, groups of users, groups of computers, GPOs (described in Chapter 6), and contacts, just to name a few.

The engine that drives this database of information is the same engine within Microsoft's powerhouse Exchange Server product, and it supports the transmission of database contents to multiple domain controllers over network links—a process called replication. Replication answers the question of how multiple domain controllers within a domain can contain the same information. For example, if you have a domain controller in Seattle and another in Charlotte, and you were to add a user in Charlotte, what if that user tried to log on to a computer in Seattle? How would the Seattle domain controller know about the user added in Charlotte? Replication allows AD DS to transmit changed data across a domain to all relevant domain controllers so that the contents of the directory are always up-to-date on each domain controller.

At this point, astute readers who are familiar with the domain structure of Microsoft's Windows NT products surely are asking, "What about PDCs and BDCs?" For the most part, Microsoft has removed that designation from domain controllers in AD DS environments, meaning that with only a couple of minor exceptions, all domain controllers are equal. This is referred to as a multimaster environment.

Because a domain controller holds a large database of information, AD DS has some interesting characteristics that weren't necessarily true of NT 4.0's Security Accounts Manager (SAM)-based list of accounts. For instance, programmers can write code to interface directly with AD DS and run queries to pull data from the database. These programmers can use either the Lightweight Directory Access Protocol (LDAP), an industry-standard protocol for accessing any sort of directory, or the Microsoft-specific Active Directory Services Interface (ADSI) for taking advantage of AD DS features not supported directly within the LDAP specification. Additionally, AD DS doesn't have the same size limitations that the SAM had. AD DS easily can handle up to a few million objects, as compared to the SAM's ability to handle no more than about 5,000 accounts. (That's scalability, folks!) AD DS is also fast when handling large amounts of data, so you won't get bogged down when your directory grows.

5.1.2. Organizational Units

A domain can be an awfully big, comprehensive unit to manage, and most environments benefit from some mechanism to separate that large, unitary domain into smaller, more manageable chunks. An organizational unit is AD DS's way of doing that. Organizational units, or OUs, act like folders on a regular client's operating system, containing every type of object that AD DS supports. You might choose to separate your domain into OUs in one of these ways:

  • A university might create a domain with a name corresponding to the entire university (ncsu.edu, for example), with each college in that institution getting an OU (biology, physics, mathematics, etc.).

  • A medium-size business might use one domain for all of its AD DS needs, but segregate objects into their geographical locations—an OU for the Los Angeles office, an OU for the Birmingham office, and an OU for the Richmond office.

  • Larger corporations might want to divide their domain by department. Within business.com, for example, an OU could be created each for Sales, Support, Marketing, Development, and Q/A.

  • An administrator also could decide to create OUs based on the type of objects contained therein—for example, a Computers OU, a Printers OU, and so on.

A particularly interesting feature of OUs is the ability to delegate administrative control over them to a subset of users in AD DS. Take, for instance, the third example in the previous list. Perhaps you, as the domain administrator, want to designate one technically savvy person in each department as the official Password Change Administrator, to reduce your administrative load. You can delegate the authority to modify users' passwords to each user over only their respective OU, thereby both allowing them power but finely controlling it over certain areas of your AD DS infrastructure. This ability is called delegation, and you'll find an entire section devoted to it later in this chapter.

OUs are designed to be containers in AD DS—their purpose is to hold objects and to have contents. You can apply GPs to the objects within a specific OU (as you'll see in Chapter 6), controlling users' desktops, locking them out of potentially dangerous system modification settings, and creating a consistent user experience across your domain.

5.1.3. Sites

Sites are great ways to manage the use of bandwidth for AD DS replication across WAN links. All domain controllers in an AD DS domain must stay in contact with one another at regular intervals to acquire and transmit the changes that have occurred to their databases since the last update. Otherwise, information becomes "stale" and the directory is no good to anyone. However, this replication traffic can be costly if you have domain controllers in different countries and you use slow WAN links to keep in contact with your various offices.

By designating different sites with AD DS, a process we'll cover later in the replication section of this chapter, you can tell AD DS to compress the replication traffic to allow it to be transmitted more quickly, and you can give preferences to certain WAN links over others by using the "cost" feature, specifying a higher value for a connection you want to use less often and a lower value for a connection you'd like to use the most often. It's a great way to manage your telecommunications expenses while still taking advantage of the better management features of AD DS.

In a domain environment, the Distributed File System, which you learned about in Chapter 3, also uses AD DS's site structure to control file replication traffic.

5.1.4. Groups

The point of groups is to make assigning attributes to larger sets of users easier on administrators. Picture a directory with 2,500 users. You create a new file share and need to give certain employees permissions to that file share—for example, all accounting users. Do you want to take a hard-copy list of all members of the accounting department and hand-pick the appropriate users from your list of 2,500? Of course you don't. Groups allow you to create an object called Accounting and insert all the appropriate users into that group. So, instead of selecting each individual user from a large list, you can pick the Accounting group, and all members of that group will have the same permissions on the file share.

There are four different scopes of groups within Windows Server 2008 and AD DS, and each scope can nest groups differently. Let's outline the group scopes first, and then bear with me as I explain the concepts of each:

Machine local groups

Machine local groups contain objects that pertain only to the local computer (or more specifically, to objects contained within the local computer's SAM database). These types of groups can have members that are global groups, domain local groups from their own domain, and universal or global groups from their own domain or any other domain that they trust.

Domain local groups

Domain local groups can be created only on a domain controller, so ordinary client computers or member servers of a domain cannot host domain local groups. Domain local groups can be put inside machine local groups within the same domain (this is a process called nesting). They can contain global groups from a domain that trusts the current domain and other domain local groups from the same domain. As you will see later in the chapter, they are of limited utility unless you are working in a larger, multidomain environment.

Domain global groups

Like domain local groups, domain global groups can be created only on a domain controller, but domain global groups can be put into any local group of any machine that is a member of the current domain or a trusted domain. Domain global groups can also be nested in other global groups; however, all nested domain global groups must be from the same domain. Domain global groups are great tools that contain all the functionality of domain local groups, and more, and they are the most common type of group used across a domain.

Universal groups

Universal groups are a sort of "do-it-all" type of group. Universal groups can contain global and universal groups, and those nested groups can be from any domain in your AD DS forest.

Briefly, I'll also mention that there are two types of groups: a security group is used for the purposes of assigning or denying rights and permissions, and a distribution group is used for the sole purpose of sending email. A security group, though, can also act as a distribution group.

5.1.4.1. Nesting

Nesting is a useful ability that has been around in limited form since Windows NT. By nesting groups, you achieve the ability to quickly and painlessly assign permissions and rights to different users. For example, let's say you have a resource called COLORLASER and you want all full-time employees to be able to access that resource. You don't have a group called FTEs that contains all your full-timers throughout your organization, but your departmental administrators have set up a structure wherein full-time employees are put into groups and part-timers are in another. To quickly create your overall FTE group, you can take your different groups of users from each department (ACCTG_FTE, ADMIN_FTE, PRODUCTION_FTE, and SALES_FTE, for example) and put them within a new group you create called ALL_FTE. Then, you can quickly assign access rights to COLORLASER by giving the ALL_FTE group permission to use the resource. You have "nested" the departmental groups within one big group.

Different types of groups, as you saw in the previous list of groups, support different methods of nesting. Table 5-1 shows the relationships between the types of groups and the respective abilities to nest.

Table 5-1. Nesting by group type
Type of nesting | Machine local | Domain local | Domain global | Universal
Within themselves | Yes | Yes (from the same domain) | Yes (from the same domain) | Yes
Within other types None Machine local Machine local

Domain local

Universal 		Machine local

Domain local

Domain global

You should remember a couple of important issues regarding backward compatibility with Windows NT 4.0 and Windows 2000 and the types of group capabilities available:

  • AD DS cannot support universal groups until you operate at least in Windows 2000 Native functional level, as NT 4.0 supports only one level of group nesting.

  • A group cannot have more than 5,000 members until your forest is operating in the Windows Server 2003 forest-functional level or higher. Functional levels are covered later in this chapter, but for now, be aware of this limitation.

5.1.5. Trees

Trees refer to the hierarchies of domains you create within AD DS. The first AD DS domain you create is automatically designated the root of your first tree, and any domains after that are considered child domains unless you choose to create a domain at the root of a new tree. Child domains always have the root domain in their name—for example, if I create the hasselltech.local domain, any child domains must be in the format of newdomainname.hasselltech.local. In effect, you are creating what are referred to as subdomains in DNS parlance. You can create as many child domain levels as you need; children can be children of other children of other children, and so on, as long as it makes sense to you.

A neat feature of AD DS is that it automatically creates two-way trust relationships between parent and child domains, so you don't need to manually trust the domains you create. As such, my new child domain from our earlier example will automatically trust its parent domain, hasselltech.local, and the parent will trust the child—the transitive trust is created automatically. This type of trust is passed along the child domain chain, so a domain like charlotte.eastcoast.us.northamerica.enterprise.com will automatically trust eastcoast.us.northamerica.enterprise.com, us.northamerica.enterprise.com, northamerica.enterprise.com, and enterprise.com.

5.1.6. Forests

Forests, in the simplest terms, are just groups of trees. All trees in a forest trust each other automatically. Think of a forest as an extended family, and individual domain trees as brothers. If you have five brothers in a family, each child of those brothers trusts his immediate brothers, and (usually!) each brother's family trusts the other brother's family—cousins typically get along. Forests just refer to collections of domain trees that trust one another.

There are two caveats, though, which are fairly significant and bear mentioning:

  • The only way to add a domain to a tree is to create it completely from scratch, adding it to an existing tree at that time. It's the same with trees—you can't directly add an existing tree to an existing forest without deleting and subsequently re-creating it.

  • Likewise, two existing, separate domains can't be linked together as parent and child. For example, hasselltech.local created on one network and charlotte.hasselltech.local created on another, separate network cannot be joined later as parent and child. The child would need to be re-created or migrated.

5.1.6.1. Transitive forest root trusts

The latter of the preceding two limitations might be frustrating for you, and you're not alone. Fortunately, what experts might term an "official hack" is available to effectively graft existing domains together into a tree-like structure so that trusts are established. Although it's not as easy and not as flexible as a forest—AD DS makes things slick and easy when you do things its way—it will work, with effort and maybe a bit of luck. The tool is called a transitive forest root trust, and with it, you can make two disparate forests trust each other.

Let's say I have a forest called businessone.com. Business One purchases another organization with an AD DS forest created already, known as businesstwo.net. Recall that I can't just graft businesstwo.net onto the already existing forest at Business One. However, with a transitive forest root trust, I can make it so that businessone.com trusts businesstwo.net, achieving some of the benefits of one unified forest. However, there are limitations and disadvantages:

  • Each forest must be operating in at least the Windows Server 2003 forest functional level. Although I will cover this later, suffice it to say that all domain controllers in each domain in each forest must be running Windows Server 2003, if not Windows Server 2008. This might be a prohibitive expense.

  • You'll learn more about this feature later in this chapter, but keep this in mind for now: a transitive forest root trust does not automatically make one, unified global catalog. Two separate forests still equals two separate global catalogs.

  • Transitive forest root trusts do not flow through. For example, businessone.com and businesstwo.net trust each other. But if businessone.com buys businessthree.org and a trust is set up there, businesstwo.net will not trust businessthree.org automatically—another trust will need to be set up. With that, we're back to the kludgy trust process found in Windows NT 4.0.

So, transitive forest root trusts aren't the answer to everything, but they are a reasonably effective way to create a "pseudoforest" within already existing trees.

5.1.6.2. The dedicated forest root model

You also can create a hedge against future AD DS changes if you are deploying Active Directory for the first time. If a department in your organization deploys AD DS ahead of other departments, as the other groups come on board, they effectively become subordinates of that first domain. How does a smart administrator get around that problem? The dedicated forest root model provides a way to maintain the autonomy of multiple domains that you create. Figure 5-1 shows how this is achieved.

Figure 5-1. How the dedicated forest root model enables separate NT domains to be separate in AD DS

A dedicated forest root domain can be either an "empty domain," which contains only a small number of universal users and resources, or a normal production domain that just happens to be at the root of a forest. The latter is not recommended. An empty forest root domain that does not serve as a production domain is advantageous for several reasons. For one, the domain administrators group in the root domain has power over the forest, which is something you might not want. Keeping the root empty allows you to delegate administrative authority to individual domains without giving everything away, a security protection that keeps honest administrators honest. It also helps you to structure your AD DS environment; a constant root makes further changes logical and easy to implement and manage—for instance, if you acquire a new company or build a new office. The forest root domain, if kept empty, is very easy to replicate and to back up. And if you ever make changes to the administrative authority in your business, you can transfer the keys to the kingdom to others without affecting the administrators' autonomy of your child domains.

You can name the empty forest root domain anything you want—even emptyroot.local. It is only a placeholder. However, most clients use a domain name based on their company's domain name.

However, the key to the empty root strategy is to keep the root empty: have it contain only one administrative account—the Enterprise Administrator, which is, of course, created by default when you create the first domain in a new forest—and use that only when absolutely necessary. Then, create all the domains you need under that first domain and you won't have one particular domain in your organization unnecessarily holding Enterprise Admin-style accounts.

Of course, this method has its downsides. Costs definitely are involved: for one, you need a separate license of Windows Server 2008 for your dedicated forest root domain controller, and you have the burden of administrative responsibility in ensuring that the root domain is kept up, patched, and the like. However, if you are in a high-growth industry and your organization is likely to make acquisitions and divestitures within the near future, it's best to use this method to hedge against major changes to AD DS structure.

5.1.7. Shared Folders and Printers

As you saw in Chapter 3, the concept of shared folders and printers within AD DS merely relates to a "pointer" residing within the directory, guiding users to the real location on a physical filesystem of a server for a particular shared directory, or the location of a print share on a print server. This process is known as publishing a share (or publishing a printer).

The point of publishing shares and printers in AD DS is to make them available for searching, either through AD DS Users and Computers for administrators or through Start rightwards double arrow Search or Start rightwards double arrow Find for client users. You can search for shared folder or printer names containing target keywords, and their locations will be populated within the results box.

5.1.8. Contacts

Contacts are simply objects in the directory that represent people and contain attributes with indicators as to how to contact them. Contacts neither represent users of any directory, nor convey any privileges to log on to the network or use any network or domain resources.

The point of the contacts object is to create within AD DS a phonebook of sorts, with names of vital business contacts that reside outside your organization—partners, customers, vendors, and the like. Because AD DS as a directory can be queried by the LDAP protocol, which most groupware applications support, the contents of contacts objects likely can be accessed directly within that application.

5.1.9. Global Catalog

The global catalog, in an AD DS environment, acts as a sort of subset directory that is passed among all domains in a particular forest. Consider that AD DS gives you the ability to connect to any computer in your particular AD DS tree. If you have a small organization, this isn't much of a problem, but in a large organization with many domains, can you imagine the performance lag while AD DS tries to (a) find the correct domain where your account resides, then (b) communicate with it, and finally (c) log you in? You would be waiting for a significant amount of time for all the pieces of the puzzle to come together in a complex AD DS implementation.

For that reason, AD DS constructs a subset of all the domains in a forest and puts it into what's called the global catalog (GC). The GC contains a list of all domains in the forest and a list of all the objects in those domains, but only a subset of the attributes for each object. This is a fairly small bit of information compared to the rest of the directory, and because of its reduced size, it is easy to pass on to given domain controllers in the forest. As a result, when a user connects to a computer in any given domain in a forest, the nearest domain controller checks the username against the GC and instantly finds the correct "home" domain for a user and the authentication process can begin. Think of the GC, therefore, as an index of your directory, much like the index of this book helps you to see which pages cover a topic in which you're interested.

The GC also contains the name of each global group for every domain in the forest, and it contains the name and the complete membership list of every universal group in the forest (recall that universal groups can contain users and other groups from any domain in the forest). So, limit your use of universal groups, lest you decrease the performance of your users' logins.


building_an_ad_ds_structure.html

5.2. Building an AD DS Structure

To get the best foundation for the rest of this chapter, much as we did in Chapter 4, let's actually build an AD DS forest, tree, and domain. In this section, I'll walk you through the process of creating a domain, promoting a domain controller, adding another domain controller to the domain, adding a second child domain, and then adding a few users and groups to the mix.

5.2.1. The First Domain

The first domain in an AD DS setup is special for a few reasons. For one, the setup process for a new domain automatically adds the first domain controller to that domain—the machine on which you run the Active Directory Domain Services Installation Wizard becomes the first domain controller for the new domain. Second, this new domain becomes the root of the entire forest, meaning that it has special powers over other domains you create within the forest, even if their names aren't the same. We'll go over that in a bit.

To start the process, from the machine you want to become the first domain controller for the new domain, select Run from the Start menu, type DCPROMO, and click OK. You might also access this screen after adding the AD DS role within Server Manager; there is a link on the final screen to launch wizard.

The Active Directory Domain Services Installation Wizard starts, as shown in Figure 5-2.

Figure 5-2. Beginning AD DS installation

Click Next, and you'll see the Choose a Deployment Configuration screen. Here, you can choose whether to install this machine as a domain controller in an existing forest by adding it to an existing domain or creating a new domain inside an existing forest, or to install this machine in a new domain in a new forest. For this example, select the latter option, and click Next.

You then see the Name the Forest Root Domain screen. Here, you type the fully qualified domain name of the forest root's domain. We'll use corp.windowsservernet.com here and click Next. The wizard will check to see whether the forest name is in use; if not, DCPROMO will continue.

The Set Forest Functional Level screen appears. Here, you can choose the compatibility level at which this new forest will function. There are several choices:

Windows 2000 forest functional level

This mode supports all types of domain controllers (NT, 2000, Windows Server 2003, and Windows Server 2008), supports only 5,000 members to a single, individual group, and only offers improved global catalog replication benefits when all domain controllers in the domain are running Windows Server 2003 or Windows Server 2008.

Windows Server 2003 forest functional level

In this level, you lose support for Windows NT and Windows 2000 domain controllers, but you gain support for renaming existing domains, more efficient AD DS replication, and transitive forest trusts.

Windows Server 2008 forest functional level

Curiously, this level doesn't actually provide any additional features over the Windows Server 2003 forest functional level, but it allows new domains in this forest to operate at the Windows Server 2008 domain functional level, which is indeed equipped with new capabilities.

Choose the option you desire; for our purposes, let's create a forest at the Windows Server 2008 level, so select the third option from the drop-down box and click Next.

DCPROMO will trundle for a while and look at the current machine's DNS configuration. If it doesn't detect a DNS service, it will prompt you to install one on the next screen you see, the Additional Domain Controller Options page. You can choose to install the DNS server, a global catalog server (more on this soon), and a read-only domain controller option (see later in the chapter for more on this option). DNS is required, and as this is the first server in a new forest, it is required to be a global catalog server and cannot be a read-only domain controller. Let's install DNS, so make sure the first box is selected and then click Next.

You may get a couple of warnings after moving to the next phase. First, Windows Server 2008 will alert you if your machine is currently configured to use a dynamic IP address. For best results, DNS servers should use static IP addresses, so it gives you a chance to use a static IP address. Next, you may get a warning about DNS not being able to find an authoritative parent zone. This is only relevant to you if you are installing a domain controller in an environment where DNS is already set up. Since we're installing DNS from scratch in this procedure, we can ignore it (as the message implies).

The Database and Log Folders screen appears, prompting you to choose where you want the AD DS database (recall that this is the NTDS.DIT file on all domain controllers' hard drives) and where you want the transaction log that keeps track of changes to the directory. If possible, place the database on one drive and the logfile on another drive. This ensures the best performance in production environments. You can use the Browse buttons to choose a location on the physical filesystem, or you can simply type a path into the boxes. Once you've finished choosing a location, click Next to continue.

The Directory Services Restore Mode Administrator Password screen appears. On this screen you can choose the password that will be required of anyone attempting to access the AD DS restore mode tools before Windows boots. Set this password to something that is secure and different from all your other administrator passwords, and then lock it away in a safe place. You probably won't need it very often. Once you've set the password, click Next.

Let me explain a bit about this special password. The AD DS Restore Mode password is actually a password that is stored in the SAM database for a domain controller, accessible only through specific methods, one being AD DS Restore Mode. Even more interesting, Directory Services Restore Mode is in fact a single-user mode of Windows Server 2008. So, the password for a directory services restore is not stored in the directory at all, meaning it is not replicated to other domain controllers.

Click Next to continue, and finally, the Summary screen appears. Ensure the choices you selected are the ones you wanted, and then click Next to begin the procedure to install AD DS and promote the current machine to a domain controller within your new domain. The installation process will trundle along, until you receive the success notification pictured in Figure 5-3.

Figure 5-3. Successful AD DS installation

Congratulations! You've built a new domain and promoted your machine to a domain controller. You'll need to restart your machine to continue.

5.2.2. Using AD DS Tools

Before we go any further, I'd like to discuss the three most common tools you will find yourself using as an AD DS administrator. All of these tools, of course, can be found in Server Manager under the appropriately named role.

The first of these tools is Active Directory Users and Computers, the tool that allows you to create your AD DS structure within a domain, add users and groups, adjust account properties, and generally administer the day-to-day operations of your directory. Figure 5-4 shows the default screen for Active Directory Users and Computers.

Figure 5-4. Active Directory Users and Computers

Next, there's Active Directory Domains and Trusts, a utility you can use to create trusts between domains and to eventually raise the domain functional level to enable new features for Active Directory. Figure 5-5 shows the default screen for Active Directory Domains and Trusts.

Figure 5-5. Active Directory Domains and Trusts

Finally, let's glance at Active Directory Sites and Services, a graphical tool that allows you to design your AD DS structure around how your business is geographically dispersed, making AD DS replication traffic go across links that cost the least and are the fastest. You can also delineate how your organization's computers are addressed via outlining different subnets, thereby increasing the likelihood that clients will log on to domain controllers that are the closest to them. Figure 5-6 shows the default screen for Active Directory Sites and Services.

Figure 5-6. Active Directory Sites and Services

We'll use each tool in time as we proceed through the remainder of this chapter. For now, let's move on.

5.2.3. Adding Another Domain Controller to a Domain

Promoting another machine to domain controller status within an existing domain is even easier than promoting the first machine in a new domain. You can use the DCPROMO Wizard to do the job for you in this case, as well.

To begin, start up DCPROMO as before, and on the screen asking you what action you want to perform, select "Additional domain controller for an existing domain," and click Next. The Network Credentials screen will appear, asking you to type in the username and password for a domain administrator account. Do so, and then click Next. Enter the full DNS canonical name of the domain for which you want this machine to become a domain controller, and then click Next. From there, proceed through the wizard starting from the Database and Log Files screen as indicated in the previous section. Once the wizard is finished and your machine has restarted, it is an official domain controller for your domain.

5.2.4. Adding Another Domain

Adding a child domain is equally simple: you use DCPROMO and you tell it to create a new domain, but not a new forest. This will add a subdomain to the existing domain tree. Then the Network Credentials screen will appear, asking for a domain administrator account for any domain located in the forest within which you want to set up the new domain. After that, the Name the New Domain screen will appear, as shown in Figure 5-7.

Figure 5-7. Providing a name for the new child domain

Here, you need to tell AD DS which domain you want to add on to, and then the name of the child domain to add on to the parent tree. You can use the Browse button to scroll around the directory or simply type the name in. In the second box, enter just the first portion of the new child domain's name. The box at the bottom will adjust automatically to show the full name of the new child domain. Click Next when finished.

Next, you might receive an error depending on the type of forest into which you are trying to install this new domain controller (see Figure 5-8). You may need to run the Active Directory preparation tool, which you can find on the Windows Server 2008 DVD in the \sources\adprep folder. Simply run adprep /forestprep at the command line and the script will automatically take care of any needed forest changes. Once the script completes, you can rerun DCPROMO, re-enter the domain information and new settings, and proceed through the wizard.

Figure 5-8. Error provided by the wizard indicating an unprepared forest

Now you can proceed through the wizard, as shown in the previous section. One note of interest, though: if the domain has a lot of information to replicate out to its new domain controller, this promotion process can take a long time. An option is available on the final screen of this wizard that allows you to finish replication later, and you might be tempted to take advantage of it. Although this option does decrease the amount of time it takes to bring a new domain controller in an existing domain online, I prefer to let replication happen immediately. The only instance in which I wouldn't want to do this is if I were bringing up a new domain controller in a branch office with a very slow connection to the home office. In that case, it's OK to wait until off hours and let the replication happen then. In all other cases, I recommend moving ahead with replication and simply waiting it out.

5.2.5. Managing Users and Groups

Of course, critical to a multiuser system are user accounts and groups, which you can create within AD DS using the Active Directory Users and Computers tool and which we previewed two sections ago. (In this section, I'll use the acronym ADUC to save me from having to type out Active Directory Users and Computers over and over.) Within ADUC, you can create, change, and delete user accounts; manage groups and their members; and configure Group Policies. The latter is a topic I'll save for Chapter 6.

5.2.5.1. Creating users and groups

Let's look at creating users and groups within ADUC. It's a simple process. First, you decide on a username or group name. You can select almost any username or group name for a particular person or group in Windows Server 2008, but you must keep these restrictions in mind:

  • The name must be unique within a domain (if you are creating a domain user) or on a machine (if you are creating a local user)

  • The name can be a maximum of 20 characters

  • The name cannot contain any of the following characters: " / \ [ ] : ; | = , + * ? < >

  • The name cannot consist of all spaces or all periods, though individual spaces or periods within a name are acceptable

Group names have the same restrictions.

Follow these steps to create a user:

  1. Open ADUC.

  2. In the left pane, select the container in which you want the new user to reside. Right-click it and select User from the New menu.

  3. The New Object - User screen appears, as shown in Figure 5-9. Enter the user's first name, middle name, and last name in the appropriate boxes, and the Full name field will populate automatically. Enter the user's preferred logon name in the "User logon name" box, and then click Next.

    Figure 5-9. Entering a new user

  4. The next screen is where you enter the user's initial password and a few properties for his account. This is shown in Figure 5-10. Enter and confirm the password, and then decide whether the new user will be prompted to change this password when he logs on, whether he can change his password at all, whether the password will follow the domain's expiration policy, and finally, whether the account is disabled. (Disabled accounts cannot log in.) Click Next.

    Figure 5-10. Entering a new user's password

  5. Confirm the information you have just entered, and click OK to create the user.

To create a new group, follow these steps:

  1. Open ADUC.

  2. In the left pane, select the container in which you want the new user to reside. Right-click it and select Group from the New menu.

  3. The New Object - Group screen appears, as shown in Figure 5-11. Enter a name from the group, its scope as a domain local, global, or universal group, and the type of group (either security or distribution). Click OK.

Figure 5-11. Creating a new group

That's it! You've created a new group.

If you are creating a user, your work is not done yet. You need to configure several additional properties before the user account is ready for use. Right-click the new user within ADUC and select Properties from the context menu. Here's a rundown of each option on the Properties sheet's various tabs.

General

On the General tab, you can input information such as the user's first, middle, and last name; a description of the user; and her office location, main telephone number, email address, and home page. The General tab is shown in Figure 5-12.

Figure 5-12. The General tab

Address

The Address tab allows you to enter the user's postal service address information and his geographic location. Figure 5-13 shows the Address tab.

Figure 5-13. The Address tab

Account

On the Account tab, you can modify the user's logon name, the suffix for her principal name (a concept which I'll explain in a bit), logon hours, and the workstations she is permitted to use. To set logon hours, click the Logon Hours button and then select the block of time you want to either permit or deny. To set permitted workstations, click the Logon To button—but note that you need to have the NetBIOS protocol on your network for that restriction to be enforced.

You also see several options. You can specify that a user must change her password the next time she logs in, that she cannot change her password, that her password never expires, that Windows should store her password using a weaker, reversible encryption scheme, that her account is disabled, that a smart card must be used in conjunction with her password to log on, that the account is to be used for a software service such as Exchange and ought to be able to access other system resources, that the account is not trusted, that DES encryption should be used for the account, or that an alternate implementation of the Kerberos protocol can be used.

The Account tab is shown in Figure 5-14.

Figure 5-14. The Account tab

Profile

On the Profile tab, you can specify the path to the user's profile. A user's profile contains the contents of his Desktop and Start menu and other customizations (such as wallpaper and color scheme). You can specify where that profile is stored with the Profile Path option. You also can designate the path to the user's home folder, which is the default location within most Windows applications for a particular user's data to be stored. Plus, you can choose to automatically map a specific drive letter to the user's home folder that you have set up. Figure 5-15 shows the Profile tab.

Figure 5-15. The Profile tab

Telephones

On the Telephones tab, you can enter different numbers corresponding to this particular user's home, pager, mobile, fax, and IP telephones. The Telephones tab is shown in Figure 5-16.

Figure 5-16. The Telephones tab

Organization

The Organization tab gives you a place to specify the user's official title, the department in which he works, the name of the company where he works, his direct reports, and his manager's name. The Organization tab is shown in Figure 5-17.

Figure 5-17. The Organization tab

Remote control

This tab specifies Terminal Services properties. See Chapter 9 for a detailed walkthrough of the options on this tab. The "Remote control" tab is shown in Figure 5-18.

Figure 5-18. The Remote control tab

Terminal Services Profile

This tab specifies Terminal Services properties. See Chapter 9 for a detailed walkthrough of the options on this tab. The Terminal Services Profile tab is shown in Figure 5-19.

Figure 5-19. The Terminal Services Profile tab

COM+

On the COM+ tab, you can assign users to applications on COM+ partitions that you have set up on different servers. The COM+ tab is shown in Figure 5-20.

Figure 5-20. The COM+ tab

Member Of

The Member Of tab shows a user's group memberships. By default, all users are members of the Domain Users group. You can click the Add button to add groups to which a user is a member. To remove a user from a current group membership, click Remove. The Member Of tab is shown in Figure 5-21.

Figure 5-21. The Member Of tab

Dial-in

The Dial-in tab is where you configure several remote access options and properties for the user. Routing and remote access are covered in detail in Chapter 11. The Dial-in tab is shown in Figure 5-22.

Figure 5-22. The Dial-in tab

Environment

This tab specifies Terminal Services properties. See Chapter 9 for a detailed walkthrough of the options on this tab. The Environment tab is shown in Figure 5-23.

Figure 5-23. The Environment tab

Sessions

This tab specifies Terminal Services properties. See Chapter 9 for a detailed walkthrough of the options on this tab. The Sessions tab is shown in Figure 5-24.

Figure 5-24. The Sessions tab

You have fewer properties to configure when you create a new group. Those group-specific properties are profiled in the next section.

General

On the General tab, you can specify the name of the group, a friendly description of it, its email address, its scope and type, and any notes you want to write to yourself or to other administrators. Figure 5-25 shows the General tab.

Figure 5-25. The General tab

Members

The Members tab shows the current members of the group. Click the Add and Remove buttons to add and remove members from the group, respectively. Figure 5-26 shows the Members tab.

Figure 5-26. The Members tab

5.2.5.2. Performing common administrative tasks

You can accomplish a couple of neat tricks using ADUC on multiple accounts at once, reducing some of the tedium involved in making repetitive changes. For one, you can select multiple accounts within ADUC by clicking one account and either:

  • Holding down the Shift key and selecting another account to completely select the range of accounts within your two initial selections

  • Holding down the Ctrl key and clicking individual accounts to select them independently

Then you can right-click the group of accounts and perform actions such as changing common properties or sending email. When you right-click multiple accounts and select Properties, the screen in Figure 5-27 appears.

Figure 5-27. Changing the properties of multiple accounts

On this screen, you can make changes to multiple accounts at the same time. A subset of the options available on individual accounts is accessible, but such common tasks as changing the UPN suffix of an account, specifying that a user must change her password, or requiring a smart card for logon are easy to accomplish with this screen.

5.2.5.3. Using LDAP to create users

LDAP is the foundation protocol for accessing and modifying the contents of AD DS. You can use LDAP-style strings in conjunction with a couple of command-line tools to automate the creation of users and groups.

First let's look at what makes an LDAP identifier. For instance, let's say my full name is Jonathan Hassell, and I'm in the container SBSUsers within the hasselltech.local domain. My LDAP name, therefore, is:

Cn="Jonathan Hassell",cn=SBSUsers,dc=hasselltech,dc=local

The abbreviation CN refers to the container, and DC refers to the components of a domain name. Likewise, Lisa Johnson in the Marketing container within the Charlotte container of enterprise.com would have an LDAP name of:

Cn="Lisa Johnson",cn=Marketing,cn=Charlotte,dc=enterprise,dc=com

Usernames in the directory are represented by a user principal name, or UPN. UPNs look like email addresses, and in some cases actually can be email addresses, but within the context of LDAP they serve to identify and select a specific user in the directory. So, if my username were jhassell, my UPN would be:

jhassell@hasselltech.local

And if Lisa Johnson's username were ljohnson, her UPN would be:

ljohnson@hasselltech.local

Now that we know how to specify some properties in LDAP, we can use the DSADD utility to create users from the command line. The advantage to using DSADD is that you can script these commands to automate the creation and provision of user accounts.

DSADD adds a user to AD DS. For example, to add a computer named JH-WXP-DSK to the Admin OU while authenticating as the domain administrator account, enter the following:

dsadd computer CN=JH-WXP-DSK,OU=Admin,DC=hasselltech,dc=local -u
administrator -p

You will be prompted for a password.

Here's another example: to add user sjohnson (for Scott Johnson, email address sjohnson@hasselltech.local with initial password "changeme") to the Sales OU and make him a member of the Presales group, use the following command:

dsadd user cn=sjohnson,ou=sales,dc=hasselltech,dc=local -upn

sjohnson@hasselltech.local -fn Scott -ln Johnson -display
"Scott Johnson" -password changeme -email
sjohnson@hasselltech.local

-memberof cn=presales,ou=sales,dc=hasselltech,dc=local

Again you will be prompted for a password.

You're getting the picture now. You can also add OUs with DSADD. To add an OU called "support," use this command:

dsadd ou cn=support,dc=hasselltech,dc=local

5.2.5.4. Delegation

One of the absolute best features within AD DS is the ability to allow other users to take partial administrative control over a subset of your directory—a process known as delegation. By delegating administrative authority, you can take some of the IT person's burden and place it elsewhere. For example, you might want to give one person in your department the power to reset passwords for other employees in a department. Or you might want to employ some part-time college students to staff a helpdesk and you want to give them the ability to create new users and to help other employees with lost passwords. You can accomplish this easily through AD DS delegation.

There's even a wizard to help you do it. The entire process works something like this:

  1. Choose an AD DS container over which you want to delegate administrative authority.

  2. Create a group of users (or identify an already existing one) that will have those new, delegated administrative powers.

  3. Use the Delegation of Control Wizard to actually grant the powers.

Let's get started. Within ADUC, select the organizational unit over which you want to delegate powers to others. Right-click it, and select Delegate Control from the pop-up context menu. The Delegation of Control Wizard appears. Click Next off the introductory screen, and the Users or Groups screen appears, as shown in Figure 5-28.

Figure 5-28. The Users or Groups screen

On this screen, click Add, and identify the users or groups to which you want to have the powers assigned. Click Next when you've added the users, and the Tasks to Delegate screen appears, as shown in Figure 5-29.

Figure 5-29. The Tasks to Delegate screen

This screen lists the most common tasks you want to delegate, including such options as managing user accounts, resetting passwords, managing groups, and administering GP. For our example, let's select the second option (to reset user passwords), and click Next.

On the final screen of the wizard, you're asked to confirm your choices. Click Finish to do so, and the delegation is complete.

Unfortunately, there is no mechanism to log what delegations have been configured. Be sure to keep a very detailed and accurate journal of the delegations you create, as there is no way to track this within the user interface.

However, the new DSREVOKE tool can offer a bit of assistance. This tool can report all permissions for a particular user or group on a set of OUs and, optionally, remove all permissions for that user or group from the ACLs on those OUs. This effectively provides the ability to revoke delegated administrative authority, although it's not as intuitive as a graphical utility might be. You can find more information at http://download.microsoft.com/download/b/1/f/b1f527a9-5980-41b0-b38e-6d1a52a93da5/Dsrevoke.doc.


understanding_operations_master_roles.html

5.3. Understanding Operations Master Roles

As I mentioned earlier, all domain controllers are nearly equal in AD DS—that is, any one of them can be updated and can replicate changes to the others. This decentralization is in direct contrast to Windows NT 4.0-style domains, which had only one PDC that accepted directory object modifications and any number of BDCs that held read-only copies of the accounts database. BDCs could authenticate users, but any changes to any attributes of domain accounts had to take place in direct communication with the PDC. Because the PDC pushed out copies of the accounts database, known as the SAM database, to the BDCs for a domain, this sort of replication was known as single-master replication because one master computer communicated changes to slaved, less-capable computers.

Enter AD DS onto the scene, where there are effectively no distinctions between domain controllers in most operations. Unless your domain is functioning at the NT interim functional level (more on that in the migration section later in this chapter), all domain controllers for a domain can accept changes for data in their domain, and domain controllers have peers to which they replicate changes to those objects. This sort of setup typically is called multimaster replication because each domain controller acts as a master, passing changes to other domain controllers until those changes are replicated fully.

Replication is covered in detail in the next section, but that introduction serves as an adequate segue to a fundamental issue: this decentralized approach has problems. Some actions taken within forests and domains could cause havoc if performed simultaneously on two separate domain controllers before replication has occurred. What if:

  • Two people made changes to the attributes of the AD DS schema on two separate domain controllers and created an attribute named CC—one person wanted that attribute to be for credit card numbers, and another wanted it to be for calling card numbers. Which would be which, and under what circumstances?

  • An administrator in one location, geographically separate from his company's headquarters, created a new domain, and then eight hours later at the headquarters complex (before replication took place) someone else created the same domain, thinking it hadn't been done yet. Which domain wins?

  • Two distinct domain controllers were doling out security IDs (SIDs) to new objects, and by chance one object on one domain controller was assigned the same SID as another object on the other domain controller. How would AD DS keep track of these two unique objects if they have the same SID?

  • You still have NT domain controllers acting as BDCs on your network. (This is very, very common now.) As you know, those NT domain controllers aren't capable of multimaster replication, so all of them need to agree on one place from which they can get updates to their SAMs. Which Windows Server 2008-based domain controller would perform this role?

  • You renamed a user or made a user a member of a certain group, and you were attached to one domain controller but that change needed to replicate to the domain controller that's local to the user whom you're administering. How might you speed up replication for those essential attributes—how can they take priority over, say, changes to phone numbers for a user in AD DS?

Clearly, some domain controllers need to have greater control over others, simply because sometimes, all computers need a bit of authority. AD DS is not entirely self-governing. Microsoft took care of this problem by implementing special roles for some domain controllers in AD DS, called operations master roles. (These roles can also be called flexible single master of operations roles, pronounced "fizz-moh," but the proper term is operations masters.) There are five specific operations master roles, listed here in the order in which each corresponds with the scenarios discussed earlier:

  • Schema master (one per forest)

  • Domain naming (one per forest)

  • RID pool (one per domain)

  • PDC emulator (one per domain)

  • Infrastructure (one per domain)

These roles are distributed one per domain, except for the schema and domain-naming roles, which are allotted one per forest. After all, schema changes affect the forest-wide AD DS, and you shouldn't have two domains named exactly the same thing within the same AD DS forest. However, RIDs are specific to domains, PDCs are specific to individual domains, and infrastructure masters account for changes within domains only, not the whole forest.

The first domain controller in a forest assumes all five roles simultaneously. The first domain controller in the second domain of a forest assumes all three domain-specific roles simultaneously. Organizations with only one domain controller have all five roles on that one domain controller.

5.3.1. Schema Master

The schema master in a forest carries out a very important function—ensuring that changes to the schema, or to the actual structure of the AD DS database, are made in a consistent manner. The schema master prevents change collisions across the forest, which is a bigger problem than you might imagine and one that grows with the size of your AD DS-based network. Although you might not think the schema would change often, a few operations actually do this: for one, installing Exchange 2000 or 2003 into a domain will extend the forest-wide schema even if some domains are not using Exchange. Other AD DS-aware applications are likely to modify the schema as well, such as Microsoft's ISA Server firewall and some network and user management applications, such as those from NetIQ.

Also remember that the forest AD DS schema and the global catalog are intertwined. Recall too that the global catalog contains a subset of information from all domains within a forest. If you added new attributes to the schema and wanted to include those in the global catalog, all your domain controllers that act as global catalog servers will need to receive the change. For Windows 2000-based domain controllers, the entire global catalog must be flushed and rebuilt on each domain controller; for Windows Server 2008-based domain controllers, only the change needs to be propagated. For large organizations, this is a big bandwidth saver if most of your GC-based domain controllers are on Windows Server 2008. It is just something to keep in mind.

To identify the schema master in Windows Server 2008, computers use the Schema Management console. You will find the DLL that enables the Schema MMC snap-in—called schmmgmt.dll—under the \WINDOWS\system32 directory. Open a command-line window, navigate to that directory, and then do the following:

  1. Register the COM object by running regsvr32 schmmgmt.dll. Once this has completed, Windows should raise a dialog box to notify you.

  2. Open the MMC—using the Run option on the Start menu and typing mmc always works if you don't have a shortcut handy.

  3. Select Add/Remove Snap-In from the File Menu.

  4. In the resulting dialog box, the list of available MMC snap-ins will appear. Select Active Directory Schema, and then click Add.

  5. Close the dialogs to apply changes.

  6. Right-click the root node of the MMC in the left pane, and then select Operations Master from the context menu.

  7. The Change Schema Master dialog box will appear, and on the first line the full name of the current schema master is revealed. In smaller domains, this will be the first domain controller installed, but in larger domains, someone could have moved the role to another domain controller. This is shown in Figure 5-30.

Figure 5-30. The Change Schema Master screen

To change the schema master (you must be a member of the Schema Admins group to do this) from within the Schema Management console you loaded in the previous procedure, right-click the root node labeled Active Directory Schema in the left pane, and select Change Domain Controller from the context menu. In the dialog box that appears, type the name of the domain controller to which you want to move the schema master role, and then click OK. Then, proceed from step 7 in the previous exercise, and click the Change button in the Change Schema Master dialog box. Confirm your choice, and once the processing is complete, click Close. The schema master role has been moved.

5.3.2. Domain Naming Master

The domain naming master role is one of the forest-specific roles, meaning that only one domain controller in the entire forest has this role. This role protects against the creation of identically named domains in the same forest—if this were to happen, AD DS could not cope with the same names and panic would result.

Keep in mind that this role is designed to be placed on a global catalog server, and not just a standalone server. It would seem that this role uses some information contained in the GC (excerpts of the directories of other domains in the forest) to fulfill its responsibilities. However, if you are operating in the Windows Server 2003 or Windows Server 2008 forest functional level, this placement is unnecessary.

To change the domain naming master role (you must be a member of the Enterprise Admins group to do this), use the Active Directory Domains and Trusts tool. Open it from the Administrative Tools menu and then:

  1. Right-click the root node in the left pane, and select Operations Master.

  2. Click Change to move the role.

5.3.3. RID Master

The RID master role handles the assignment and distribution of the latter portion of SIDs for objects within AD DS. You know that when an object is created in Windows, a unique SID is assigned to it. The SID comes in the form of S-1-5-21-A-B-C-RID, where the S-1-5-21 is common to all SIDs. The "A," "B," and "C" parts of the number are randomly generated 32-bit numbers that are specific to a domain, or to a particular machine (if AD DS is not installed on the server or if a workstation isn't joined to a domain). The RID, or relative identifier, part of the SID is another 32-bit number that is the unique part of the SID and identifies a distinct object in the directory.

The domain controller with the RID master role distributes groups of 500 unique RIDs to its brother and sister domain controllers with the domain, so that when they create unique objects, the SIDs they assign to those unique objects should also be unique. Much like DHCP ensures that no two workstations have the same IP address, distributing pools of RIDs in this way ensures that no two domain controllers have the same groups of RIDs to assign.

To move the RID master role to another domain controller in a domain, follow these steps:

  1. Open Active Directory Users and Computers.

  2. In the left pane, right-click the domain name, and then select Operations Masters.

  3. Click the RID tab, and note the name of the RID master. This is shown in Figure 5-31.

    Figure 5-31. Identifying the RID pool master

  4. Click Change to move the role.

5.3.4. PDC Emulator

The PDC emulator operations master role serves a very important function for mixed Windows NT Server, 2000 Server, Windows Server 2003, and Windows Server 2008 domains. As I mentioned at the beginning of this section, NT domain controllers—whether primary or backup—don't support multimaster replication, so if your PDC has been upgraded to Windows 2000 or Windows Server 2003, obviously there is no computer from which your BDCs can get updates, or at least none they can understand. Those of you familiar with Microsoft's older networking protocols know that the Master Browser service, the utility that populates Network Neighborhood and My Network Places on workstations and servers, typically runs on the PDC in an NT domain. System policies for Windows 95 are stored on the PDC, not on any BDCs. And trusts between NT domains and AD DS domains require a PDC, or a PDC emulator, because NT thinks only one computer has the read/write copy of the SAM database.

The PDC emulator runs on one domain controller in a domain to perform these functions. It also helps speed up propagation and replication of changes to two specific attributes of a user object in AD DS: the password and the account lockout attribute. Think about large organizations, and the time it can take for changes made at one domain controller to filter out. (I'll cover replication in a lot more detail in the next section, but know for now that replication can involve a considerable amount of time if you have many domain controllers handling AD DS responsibilities in your environment.) If a user called to reset a password and the help desk personnel responding to that call were in another site, the password change would take effect first on the domain controller local to the help desk personnel, not necessarily local to the person whose password was being changed. Do you really want to wait the hours it might take for that change to take effect? Of course not, so the domain controller for the help desk personnel immediately contacts the domain controller holding the PDC emulator role for the domain, and it gets that updated password, thus avoiding replication delays. So, although the local domain controller for the user might not have the new password, the local domain controller will look at the PDC emulator domain controller to check whether the password matches there. If it does, the user gets a green light to log in. (Of course, password changes aren't actually immediate—there is still lag time.)

This policy stretches to one other attribute as well. If you use account lockouts—when a password is entered incorrectly for x number of times, the account becomes temporarily disabled for a period of time—it probably wouldn't do a lot of good for only the password to be passed quickly to the PDC emulator role. The user would have the right password, but neither the PDC emulator nor the local domain controller for the user would know the account actually wasn't locked out anymore. So, the account lockout attribute is passed at the same time as a password reset, to make sure users aren't sitting, twiddling their thumbs without access to their domain user accounts while the domain controllers wait for replicated changes to arrive.

Finally, the PDC emulator handles time synchronization in a domain.

Ideally, the PDC emulator role should be on the same domain controller as the RID master role. To move the PDC emulator role, use Active Directory Users and Computers, as follows:

  1. Open Active Directory Users and Computers.

  2. In the left pane, right-click the domain name, and then select Connect to Domain Controller.

  3. Enter the name of the domain controller to which you want to switch the role.

  4. Then, right-click the domain name in the left pane again, and select Operations Masters from the context menu.

  5. Click the PDC tab, and note the name of the PDC emulator master. This is shown in Figure 5-32.

  6. Click Change to move the role.

Figure 5-32. Identifying the PDC emulation master

5.3.5. Infrastructure Master

The infrastructure master also helps to speed up propagation and replication of certain pieces of information among domain controllers. The infrastructure master role is designed to not be on a domain controller functioning as a GC server—that is, unless every domain controller in your domain is a GC server as well, or if you have only one domain.

To find out and change which domain controller holds the infrastructure master role, use the Active Directory Users and Computers tool. As before, if you have only one domain controller in your domain, that is obviously the infrastructure master. In larger domains, to identify and/or change this machine, follow these steps:

  1. Open Active Directory Users and Computers.

  2. In the left pane, right-click the domain name, and then select Connect to Domain Controller.

  3. Enter the name of the domain controller to which you want to switch the role.

  4. Then, right-click the domain name in the left pane again, and select Operations Masters from the context menu.

  5. Click the Infrastructure tab, and note the name of the infrastructure master. This is shown in Figure 5-33.

  6. Click Change to move the role to the domain controller of focus.

Figure 5-33. Changing the infrastructure master

5.3.6. Transferring and Seizing Roles Manually

Sometimes you might need to change the operations master roles that domain controllers are playing without necessarily using the graphical interface. It might be that you inadvertently unplugged and reformatted your first domain controller in your domain too early, without transferring its roles elsewhere. Or maybe your specific server is temporarily offline but you really need a role transferred as soon as possible.

If your PDC emulator domain controller or infrastructure masters are offline, it is OK to transfer these roles through the GUI using the aforementioned procedures. You'll need to confirm the offline transfer a couple of times before it will go through, but eventually it will succeed.

Windows Server 2008 comes with the NTDSUtil tool, a command-line utility that allows you to perform AD DS maintenance that goes above and beyond what the GUI tools allow. In this case, you might need to transfer the schema master, domain naming master, or RID master roles—or you might need to force that transfer if the original holder of those roles is unavailable.

To transfer a role using NTDSUtil, open a command prompt and run NTDSUTIL. Then follow these steps:

  1. Enter roles to switch into FSMO Maintenance mode.

  2. Enter connections to enter the Server Connections context.

  3. Enter connect to <targetcomputer>, where <targetcomputer> is the computer to which you want to transfer the role.

  4. Enter quit to leave the Server Connections context.

  5. Enter transfer schema master, transfer domain naming master, or transfer rid master, whichever is appropriate, to transfer the role you want. NTDSUtil will attempt to contact the current holder of that operations master role. If it can, and that machine approves the transfer, your operation is complete. However, if for some reason the utility can't contact that computer, error messages will result.

If you find error messages when you're simply attempting a transfer, you can force the role transfer by using the SEIZE command. After step 4 in the previous procedure, start the following:

  1. Enter seize schema master, seize domain naming master, or seize rid master to force the transfer of the role to the target computer.

  2. Type quit to leave NTDSUtil once the seizure is complete.

Once you have seized a role, never let the previous holder of that role back onto the network unless you've reformatted the machine. I repeat: never, ever do this. The previous holder doesn't know the roles were transferred and is not able to figure it out for itself. Picture a bitter custody battle.


understanding_directory_replication.html

5.4. Understanding Directory Replication

At its foundation, the replication process is simply an effort to keep the copy of the AD DS database identical on all domain controllers for a particular domain. For example, if an administrator removes a user from a group, the change is made on the domain controller that the administrator is currently logged into. For those few seconds after the change, that domain controller alone has the most current copy of the database. Eventually, though, after replication takes place, all domain controllers will have exact replicas of the database, including the change in group membership.

5.4.1. Within a Site: Loops and Meshes

AD DS replicates information between domain controllers using different methods, depending on the topology of your network—in particular, how many sites you have configured within AD DS. In a single-site situation, all domain controllers in a domain will discover one another through published records in both AD DS and the DNS system for the domain. But to cut down on network traffic, not every domain controller needs to actually replicate with every other domain controller. AD DS uses a "loop" method. Take, for instance, four domain controllers—A, B, C, and D, as shown in Figure 5-34.

Figure 5-34. Single site with four domain controllers

In this example, AD DS will replicate using two loops. Let's assume that a change was made on domain controller A. A will tell B and C that it has new information, and eventually B and C will ask A for that information. Once the information is received, both B and C will attempt to tell D about their new information. D will ask for the new information from the first domain controller that reaches it—there isn't a good way to determine whether that would be server B or C in our case—but when the second "message" telling D that it has new information arrives, server D will simply respond, acknowledging that it already has that information, and that will be the end of the transmissions because all domain controllers now have the most up-to-date information. In contrast, consider using only one loop and not two. In that case, A would tell B, B would tell C, C would tell D, and D would then tell A again. That doesn't happen. In the actual case, news is spread more quickly and network traffic is reduced, making the entire process more efficient. In fact, this entire process triggers every five minutes, and if there's new information, the process will engage. If there is no new information, the domain controllers won't transmit anything; however, if 60 minutes pass without any new information, each domain controller will send a message to its partners, making sure there's no new information.

In simple networks, you usually find each domain controller has two replication partners. However, in more complex environments, domain controllers can have more than two partners. To see a domain controller's replication partners, open Active Directory Sites and Services, expand the site in question in the left pane, and expand each domain controller's node. Click NTDS Settings in the left pane, and in the right pane, note the two servers listed in the From Server column.

You might wonder how this loop is designed. The Knowledge Consistency Checker, or KCC, wakes up approximately every 15 minutes and tries to detect changes in its idea of how many domain controllers there are and where they're located. The KCC will look at any changes that have occurred—you might have taken a domain controller offline for maintenance, for example, or even added a new domain controller for load control purposes. Then it adjusts the loop for best performance.

In larger sites, the KCC might find it necessary to add more than two replication partners for each domain controller, or it might do so for traffic control purposes. In still larger sites, even those with only two replication partners per domain controller, it can take more than three hops to transmit replication information completely. The KCC looks for this situation and, if it detects it, simply adds more links between domain controllers, changing the simple "loop" structure into more of a "mesh" structure.

5.4.2. Time Synchronization

For replication to function properly, it is crucial for all domain controllers in a domain and/or forest to be in sync in terms of the current time. The reason points to Kerberos, the underlying authentication scheme for the entire AD DS: if any domain controller is more than five minutes out of synchronization, authentication will fail.

The Windows Time Service is the tool Microsoft provides to consistently keep your entire domain or forest at the same moment in time. Windows Time Service offers a hierarchy for members of AD DS domains and forests, with the machine holding the PDC emulator operations master role as the "big kahuna" of sorts, holding the trusted time. The trusted time at the very top level does not need to be synchronized from anywhere—synchronization matters only within the domain, as all members must think it is the same time, regardless of whether that time is the actual time. In other words, everyone has to be the same, but it doesn't matter if everyone is wrong.

From the bottom up, the rest of the hierarchy looks something like this:

  • Workstations and servers that are not domain controllers will synchronize their time with the domain controller that logged them in.

  • Domain controllers will contact the domain controller for their domain with the PDC emulator operations master role for the current time.

  • Each domain in a forest with multiple domains will look to the PDC emulator operations master-holding domain controller in the forest root—the first domain in the forest—to keep the other PDC emulator domain controllers in other domains in check.

You can synchronize the domain controller at the PDC emulator operations master role in a few ways, through the command line. First, though, you must choose a time source. Microsoft provides the host time.windows.com, synchronized to the U.S. Army's Atomic Clock, which is as good a choice as any. Once you have selected a time source, run the following from the command line of the PDC emulator domain controller:

net time /setsntp:
<TIMESOURCE>

Replace <TIMESOURCE> with the full DNS name of the time source you have selected. For example, if I were using time.windows.com as my time source, I'd run:

net time /setsntp:time.windows.com

Once you have set the time source for the PDC emulator domain controller, it will attempt to synchronize its time with the time source. It will try once every 45 minutes until it has successfully synchronized three times in a row. Once it has done so, it pings the time server only once every eight hours. If you want to trigger time synchronization manually, run:

w32tm /resync

The Windows Time Service requires outbound UDP port 123 to be open on your firewall for time synchronizations to occur.

Time zones also play a role. Windows operates internally at Greenwich Mean Time, and although each server can be set to a different time zone depending upon either its physical location or the location of the administrator who manages the box, within Windows itself the current time is translated to GMT. Be wary of this, and ensure that time zones are set correctly on all your servers. The object is to get Windows' internal clocks to synchronize—even though the time might seem right to the naked eye, if the time zone is set incorrectly, Windows is unforgiving when it comes to AD DS operations in that state.

5.4.3. Replication Topologies

Loops and meshes are just two examples of what Microsoft terms replication topologies—essentially, maps of the ways domain controllers replicate to one another. And to confuse things, there is almost always more than one replication topology existing simultaneously within any particular forest. Let's take a closer look at that.

Four types of data need to be replicated among domain controllers:

  • Updates that stay within a particular domain—username and password changes, and other user account information

  • Updates to the schema naming context and configuration naming context, which are specific to all domains with a forest, as you saw previously in this chapter

  • Updates to the GC, which replicate to all domain controllers that function as GC servers

  • Updates to DNS partitions and custom application partitions

With many domain controllers in a forest, you can see where one replication topology might either not suffice or not be the most efficient way to transmit information between these selected subgroups of domain controllers. Figure 5-35 shows this scenario graphically.

Figure 5-35. Looking at all replication topologies in a forest

The Active Directory Sites and Services console again comes to your aid if you want to try to piece together all these replication topologies for your environment. Open the console, expand the site in question in the left pane, and expand each domain controller's node. Click NTDS Settings in the left pane, and in the right pane double-click the "<automatically generated>" objects.

If you see <Enterprise Configuration> in one of the fields at the bottom of the screen indicating replicated naming contexts, it shows that that particular link replicates the schema and configuration naming contexts. In the Partially Replicated Naming Context field, if you see a server name, this indicates that your server is a GC server and is receiving updates from the GC server listed in the field. It is perfectly acceptable for this field to be empty on servers not acting as GCs.

5.4.4. Handling Update Conflicts

Replication is great in and of itself, but there it has one major, inherent problem—each domain controller uses its own copy of the database and, no matter how often each copy is updated, for a few moments in time each copy is unaware of actions taken on other copies of the database around the network. How might this design situation manifest itself as a problem?

Consider a large site, with branch offices in Sydney, Boston, and Los Angeles. An employee, Robert Smith, is being transferred to the Sydney office from L.A. because of personnel reorganization. The company uses groups within AD DS, SYDUSERS and LAUSERS, for distribution list purposes and other security boundary assignments. On Robert's last day in the L.A. office, his manager changes Robert's group membership, moving him from LAUSERS to SYDUSERS in anticipation of his transfer. The Los Angeles domain controller notes this change and creates a record looking roughly like this:

Object: LAUSERS
Change: Remove RSMITH
Version: 1
Timestamp: 30 June 2004 5:30:01 PM GMT
Object: SYDUSERS
Change: Add RSMITH
Version: 1
Timestamp: 30 June 2004 5:30:02 PM GMT

Look closely at these records. They denote changes to attributes of objects—in this case, the member list is an attribute of a particular group object—not changes to the entire object. This is important for network traffic reduction reasons; if the LAUSERS group comprised 2,000 members, it's good to transmit only the removal of RSMITH and not the entire membership list. Also, note the version numbers: the field is very simple and is designed to be used whenever domain controllers update an attribute for a particular object. Each time a change is made to a particular object attribute, the numeral in the version number field is incremented by 1. So, one object can have many version numbers, each representing the attributes of that object.

With that background out of the way, let's return to our fictional situation. Perhaps there was a miscommunication between Robert's old manager in Los Angeles and his new manager in Sydney, and each incorrectly thought she was supposed to make the change in group membership with AD DS. So, at almost exactly the same time (we'll ignore time zone differences for the purposes of this demonstration), Robert's new manager makes the previously described change, which is recorded on the Sydney domain controller as follows:

Object: LAUSERS
Change: Remove RSMITH
Version: 1
Timestamp: 30 June 2004 5:32:08 PM GMT
Object: SYDUSERS
Change: Add RSMITH
Version: 1
Timestamp: 30 June 2004 5:32:10 PM PT

There are two things to note about this record: one is the closeness of the timestamps. They seem to indicate that the L.A. and Sydney domain controllers haven't replicated yet. The second item of interest is the version number field in each record, which does not appear to have been incremented. The reason for this is simple: version numbers are incremented on the local domain controller. If a domain controller doesn't know about any changes to an attribute, there is no need to further increment the version number on that record. Because L.A. and Sydney haven't passed changes between each other yet, the Sydney domain controller doesn't know that a similar change has processed on the L.A. domain controller and therefore doesn't know to increment the version number field from 1 to 2.

This situation might seem harmless because although the changes are different only in time, the net effect is the same; on both domain controllers, RSMITH is a member of the correct group and not a member of the former group. But in reality there are two changes. Which one is accepted by AD DS? And to ask a more specific question, when both the L.A. and Sydney domain controllers replicate to their partner, the Boston domain controller, which change will Boston accept?

When changes to the same object compete, the tie is broken two ways:

  • First, the attribute change with the highest version number is the change formally accepted.

  • If the version number of each attribute change is the same, the change made at the most recent time is accepted.

In our case, the change made on the Sydney domain controller would be the one formally accepted in AD DS, and the L.A. manager's modification, although its intent was the same, would be rejected because it was made at 5:30 p.m. and not at 5:32 p.m.

5.4.5. Update Sequence Numbers

Version numbers have siblings, called update sequence numbers (USNs), which measure the increments of every change to every attribute of every object within AD DS. That is to say, whenever any change is made within AD DS, a domain controller increments its current USN by 1. For example, if you have a pristine domain controller and you add a user with an initial password (update 1), change his password (update 2), add another user (update 3), create a new group (update 4), and put the first user in that group (update 5), the USN for that domain controller would be 5. Keep in mind that version numbers coexist with USNs; let's look at the information in Table 5-2 to see how USNs and version numbers interact in the preceding example. (Note that the table assumes we're talking about a domain with only one domain controller; it gets a bit more complicated when you add more domain controllers, and I'll discuss that later in this section.)

Table 5-2. Examining version numbers and USNs in AD DS
Action | Attribute version number | Update sequence number (USN)
Create New User | All attributes are 1 because the operation is seen as one cohesive change. | 0
Change Password | Password attribute for that user is 2. | 1
Create New User | All attributes are 1. | 2
Create New Group | All attributes are 1. | 3
Add User to Group | Group membership attribute is 2. | 4

From this table, you can glean that version numbers are incremented only when attributes change. We changed the password for our first user, so the version number for that attribute became 2, and we added that user to our newly created group, so the version number for the attribute containing the member list for that group increased to 2. But all the while, the USNs were incrementing because USNs measure every individual change. Our USNs went from 0 to 4 because (a) USNs start at 0, not 1, and (b) 5 individual changes were made.

Note that earlier I said this scenario revolved around a single domain controller. Let's change that now: if we were to add a domain controller to this example domain, the domain controllers would attempt to replicate with each other. Let's assume that once a domain controller is added, our two accounts and one group are transmitted immediately. The version numbers and USNs, as seen on the new domain controller, would shape up as shown in Table 5-3.

Table 5-3. Examining version numbers and USNs with two domain controllers
Object | Attribute version number | Update sequence number (USN)
User 1 | All attributes are 1 except for the Password attribute, which is 2. | 0
User 2 | All attributes are 1. | 1
Group | All attributes are 1 except for the membership list attribute, which is 2. | 2

We learn two things from this table:

  • Version numbers of attributes are retained across replications, so around the directory, no matter which domain controller you access, version numbers for attributes are the same. This is critical to the functioning of replication in AD DS.

  • USNs are independent to each domain controller. In our first example, there were five changes because we were adding and changing things individually on that first domain controller. Because the second domain controller was brand new, it created the user accounts and groups from the up-to-date and already changed information on the first domain controller; as a result, it needed to denote only three changes (the creation of each account and the creation of the group).

USNs really act as "signatures" showing the timeliness of information in each domain controller's copy of the directory, and essentially guide a domain controller's replication partners as to exactly how much updating is needed to fully replicate. Each domain controller tells its replication partners the USNs it has assigned to each piece of data, and the partner domain controllers keep track of that information. The partners then know that the last piece of data they received—for example, from domain controller X—had a USN of 6093, and they can then tell domain controller X upon the next replication to start transmitting data with a USN of 6094 (one number higher than the last USN) or more. There is no need to send USNs 1-6093 again, as they already possess that data. If the USNs haven't changed on domain controllers during the regular five-minute breaks from replication, domain controllers assume that no new information is available, and they go back to "sleep" for another five minutes. On the other hand, if domain controller X's replication partners contact domain controller X and ask for its highest USN, and it replies with 7000, the partners know they need the last six pieces of information, and those will then be replicated. Then the partners would make a note that domain controller X's highest USN is now 7000, and everyone is secure in the knowledge that they have the most current directory possible for at least the next five minutes.

So, let's return to the example and see where we are with version numbers and USNs. Table 5-4 sums that up.

Table 5-4. USNs and version numbers
Domain Controller 1 | Domain Controller 2
Object | Attribute version numbers | Highest USN | Object | Attribute version numbers | Highest USN
User 1 | All attributes are 1 except for the Password attribute, which is 2. | 4 | User 1 | All attributes are 1 except for the Password attribute, which is 2. | 2
User 2 | All attributes are 1. | User 2 | All attributes are 1.
Group | All attributes are 1 except for the membership list attribute, which is 2. | Group | All attributes are 1 except for the membership list attribute, which is 2.

Now consider this scenario: an administrator changes the password for User 2, and that administrator is currently using domain controller 1. That change would be assigned USN 5 because it's the sixth change that domain controller has seen. Five minutes later, replication is initiated, and domain controller 2 queries domain controller 1 for its highest USN, which it tells domain controller 2 is 5. Because domain controller 2 thinks the highest USN for domain controller 1 is 4, it knows it has missed a change, so it asks for the new information. The new password is pushed along, and the change on domain controller 2 is assigned a USN of 3 (it is a unique change, after all). Then domain controller 2 makes a note of domain controller 1's new highest USN, domain controller 2 is up-to-date, and everyone is happy.

They're happy, that is, until a few minutes later, when domain controller 1 asks domain controller 2 what its highest USN is. Domain controller 2 will faithfully reply that it is 3, and domain controller 1 will know that figure is higher than its recorded high USN for domain controller 2 (which is 2, as shown in Table 5-4). However, that change is the original change pushed through from domain controller 1 to domain controller 2. The domain controllers don't know that, however, just from looking at USNs, so they push through the replication, and domain controller 1's highest USN now becomes 6 because of this "change." Five minutes later, the entire process starts again, with this one change being propagated over and over and over again, in an infinite loop.

5.4.5.1. Breaking the loop: originating USNs and UTD vectors

Microsoft identified this problem and introduced two other values to the mix, called originating USNs and up-to-date vectors, specifically to prevent this situation from occurring. Originating USNs simply keep track of the domain controller from which a change was initially transmitted, and the USN on that domain controller. So, when we first introduced the brand-new domain controller into our example domain and a copy of the directory was first replicated, more information was transmitted than I discussed earlier. Table 5-5 contains a more detailed representation of the results of that replication than Table 5-4 does because it includes originating USNs.

Table 5-5. Examining version numbers, USNs, and originating USNs
Object | Attribute version number | Update sequence number (USN) | Originating domain controller | Originating domain controller's USN
User 1 | All attributes are 1 except for the Password attribute, which is 2. | 0 | Domain controller 1 | All attributes except for Password 0; Password 1.
User 2 | All attributes are 1. | 1 | Domain controller 1 | All attributes 2.
Group | All attributes are 1 except for the membership list attribute, which is 2. | 2 | Domain controller 1 | All attributes except for membership list 3; membership list 4.

In essence, originating USNs tell all domain controllers where information first came from and what USN that first domain controller assigned to each piece of data. But just as domain controllers keep track of the highest USNs for their replication partners, they also keep track of the highest originating USN they have ever come across from any and all domain controllers. This table of maximum originating USNs is known as the up-to-date vectors. Let's look at this more closely.

Our situation now is shown in Table 5-6.

Table 5-6. Example USNs, originating USNs, and UTD vectors
Domain controller | Highest USN | Partner's highest USN | Up-to-date vectors Self | Partner
1 | 4 | 2 | 4 (from domain controller 1) | 2 (from domain controller 2)
2 | 2 | 4 | 2 (from domain controller 2) | 4 (from domain controller 1)

I just formulated the up-to-date vectors shown in Table 5-6; all they represent is the latest originating USN that each domain controller knows from the other domain controller. Now, flip back a couple of pages and refresh yourself on the scenario that previously would have created an infinite loop: a change of User 2's password, made by an administrator attached to domain controller 1. Domain controller 1 gives this change a USN of 5, and consequently domain controller 1 updates its table of up-to-date vectors with the highest originating USN that it knows from itself—so, it changes from 1 (our arbitrary first number) to 5.

Replication is initiated once again, and domain controller 2 asks domain controller 1 if it has any new information higher than USN 4, which it knows is its partner's highest USN, and whether the originating USNs are higher than 1 for domain controller 1, and 1 for domain controller 2. Domain controller 1 checks its copy of the directory and finds the password change, and then sees that it originated the change itself, with an originating USN of 5. However, domain controller 2 asked for any information from domain controller 1 with an originating USN higher than 1, so now domain controller 1 knows that domain controller 2 has no idea of this new information and it passes it along. Domain controller 2 records the change and assigns a USN of 3, and then makes a note that its partner's highest USN is 5 and the highest originating USN it has seen from domain controller 1 is 5. Our values, after that process, are shown in Table 5-7.

Table 5-7. Example USNs, originating USNs, and UTD vectors after example replication
Domain controller | Highest USN | Partner's highest USN | Up-to-date vectors Self | Partner
1 | 5 | 2 | 5 (from domain controller 1) | 2 (from domain controller 2)
2 | 3 | 5 | 3 (from domain controller 2) | 5 (from domain controller 1)

Let's go a bit further. Replication kicks off again, and this time domain controller 1 contacts domain controller 2 and asks whether it has any new information higher than USN 2, which it knows is its partner's highest USN, and whether the originating USNs are higher than 5 for domain controller 1, and 2 for domain controller 2. Domain controller 2 checks its copy of the directory and sees that it has a change to which it assigned a USN of 3, but it also checks to see where that change came from—and it sees that the change came from domain controller 1 and that domain controller 1 assigned a USN of 5 to it. Domain controller 2 decides that even though the change was new to it, domain controller 1 clearly already knows about it and therefore doesn't need that change replicated. Domain controller 2 tells domain controller 1 about its currently highest USN (3), and domain controller 1 makes a note of that. What does this entire process accomplish? It ensures that a change is replicated only between partners, because each partner can figure out who knows about what changes and when they were made by looking at USNs and up-to-date vectors. So, now everyone is happy—really, this time—as shown in Table 5-8.

Table 5-8. Final replication results
Domain controller | Highest USN | Partner's highest USN | Up-to-date vectors Self | Partner
1 | 5 | 3 | 5 (from domain controller 1) | 2 (from domain controller 2)
2 | 3 | 5 | 3 (from domain controller 2) | 5 (from domain controller 1)

In summary, domain controllers use this up-to-date vector table and the originating USN data fundamentally to construct a more specific replication request. So, instead of simply asking a replication partner for any data higher than the highest USN a requestor knows, it asks for any data higher than the highest USN it knows is also higher than the ones for each domain controller in its up-to-date vector table.

5.4.6. Managing Replication Using REPADMIN

Replication Administrator, or REPADMIN, is a command-line utility that can control a lot of aspects and behaviors of AD DS replication. In case you're wondering why you've never seen the utility, REPADMIN is part of the Windows Server 2008 Resource Kit Tools—not the standard kit—and you can find it on the distribution CD within the SUPPTOOLS.MSI installer file in the \SUPPORT\TOOLS folder.

5.4.6.1. Running the KCC

Recall from earlier in this chapter that the KCC detects the network environment and adjusts the structure of replication partners among domain controllers. It does this by default every 15 minutes, but if you want it to update earlier, you can trigger the KCC manually from the command line by running repadmin /kcc.

5.4.6.2. Viewing up-to-date vectors

On production machines, you can view the up-to-date vectors on a particular machine using REPADMIN. From a command line, run repadmin /showutdvec servername <LDAP-naming-context>. To fill in the latter part of the command, examine the name of your AD DS structure, and divide the parts from each other and include "DC=" in front of each. Separate the DC parts with commas. For example, if I have a domain jonathanhassell.com, I would use DC=jonathanhassell,DC=com, and my REPADMIN command looking at a machine named SERVER1 would be:

repadmin /showutdvec server1 dc=jonathanhassell.com,dc=com

A sample result looks like the following:

Caching GUIDs.
..
Default-First-Site-Name\SERVER3 @ USN 8404 @ Time 2004-06-10 12:24:30
Default-First-Site-Name\SERVER2 @ USN 8038 @ Time 2004-06-10 11:12:57
Default-First-Site-Name\SERVER1 @ USN 9374 @ Time 2004-06-10 12:27:23

Of course, the numbers after the USN constitute the up-to-date vector for each listed domain controller.

5.4.6.3. Viewing replication partners

REPADMIN gives you a way to view replication partners outside of the GUI method discussed earlier in this section. Use the command repadmin /showrepl servername <LDAP-naming-context> to do so. For example:

repadmin /showrepl server1 dc=jonathanhassell.com,dc=com

5.4.6.4. Viewing highest USNs

By simply adding the /verbose switch to the command to view replication partners, you can see what the current server thinks is the highest USN for each partner. For example:

repadmin /showrepl /verbose server1 dc=jonathanhassell.com,dc=com

For each replication partner, the number before the /OU indicator is the highest USN from that particular partner that the current server has encountered.

5.4.6.5. Pressing the "Big Red Button"

If you want to replicate now, not later, you can use one of two options with REPADMIN. To force replication among any two domain controllers, use the command repadmin /replicate targetcomputer sourcecomputer <LDAP-naming-context>. For example, to force replication from SERVER3 to SERVER2, issue this command:

repadmin /replicate server2 server3 dc=jonathanhassell.com,dc=com

To initiate replication among all partners, use repadmin /syncall servername <LDAP-naming-context>. So, if I wanted to force replication among all SERVER2's partners in the jonathanhassell.com domain, I'd use the following command:

repadmin /syncall server2 dc=jonathanhassell,dc=com

5.4.7. Among Sites: Spanning Trees and Site Links

Although AD DS uses loops and meshes to create and manage replication topologies within a particular site, using that many links across an expensive WAN connection can cost you dearly as well as take a lot of time. For that reason, when AD DS replicates between sites, it uses a minimal spanning tree—in other words, a tree with as few branches as possible to span the link between multiple sites.

Let's use an example environment, with two servers in a site called MAIN (representing the headquarters in Charlotte) and a single domain controller in another site, called WEST (located in San Francisco). Recall that the KCC facility creates replication topologies within sites automatically—you, the administrator, do not have to intervene. Replication between sites isn't as simple; AD DS needs to know several things about your individual sites before it can figure out how to replicate traffic among them.

5.4.7.1. Site links

By creating site links, you give AD DS three key pieces of information it must have before it can determine the most efficient way to force replication traffic across your sites:

  • Which connection, if there is more than one, to use for replication to the destination site

  • The persistency of that connection

  • How the replication should take place—either using RPC in real time, or through SMTP

Let's discuss the third bit of information first: AD DS will allow you to create links based over IP (using RPC calls) or via SMTP for less reliable or less secure connections. Unfortunately, SMTP-based site links are extremely limited in functionality. For one, SMTP links will only transfer updates to the forest schema naming context and configuration naming context; it will not perform cross-site domain controller information updates. Also, you need a secure mail server, hardened against outside interception using encryption and certificates, to transfer even that bit of information. For these reasons, the vast majority of site links you create will be IP-based links.

Returning to our example, let's create a site link between MAIN and WEST. To do so, follow these steps:

  1. Open Active Directory Sites and Services.

  2. Expand the MAIN node in the left pane, and then expand the Inter-Site Transports folder.

  3. Right-click IP, and select Site Link from the New menu.

  4. The screen in Figure 5-36 appears.

    Figure 5-36. Configuring a new site link

  5. Enter a friendly name for the site in the Name box.

  6. Choose the sites you want to include in this link. A link must include two or more sites, and you can shift sites back and forth using the Add and Remove buttons in the middle of the screen. For our purposes, make sure MAIN and WEST are in the box labeled Sites in this site link. Click OK.

To further configure the site link, right-click the new link in the IP folder of the left pane of Active Directory Sites and Services. Choose Properties, and the screen in Figure 5-37 will appear.

Figure 5-37. Changing the schedule for a site link

This screen contains two critical items. First, the Cost field allows you to determine a cost quotient—in essence, an index of the expense of using a connection—for each site link you create. If you have more than one site link, AD DS will choose the lowest-cost link to perform the replication. Unfortunately, Microsoft doesn't give you much guidance on how to arrive at your cost quotient figure; I recommend taking into account the base link cost, rates for prime and overnight periods, traffic limits, and link availability. Second, the "Replicate every" box allows you to specify how often AD DS will attempt to initiate replication over this specific site link. You can set the shortest replication interval to 15 minutes, and there is no functional maximum value (although all AD DS sites must replicate at least once every 60 days). Click the Change Schedule button to see the screen depicted in Figure 5-38.

Figure 5-38. The Schedule for New Site Link screen

Use the mouse to select the hours during which the link will not be available; AD DS will use this information and not even attempt replication during that time period. Click OK to exit that dialog, and then click OK to finish configuring the link.

Once you have specified the information for the site, the Sites and Services equivalent of the KCC, called the Inter-Site Topology Generator (ISTG), will begin developing the minimal spanning tree needed to pass replication traffic among sites.

And that's a basic but thorough treatment of AD DS replication.

5.4.8. Read-Only Domain Controllers

Think back to the days of Windows NT 4.0, when there was one king of the hill, the primary domain controller (PDC), and then any number of subservient princes below that king on the same hill—the backup domain controllers, or BDCs. It was easy to see the flow of information—changes were made to the master copy of the domain security information on the PDC, and from there it flowed outward, unidirectionally, to the BDCs. When AD DS came around, however, this distinction was eliminated, and in practice a domain controller became equal to any other domain controller, without any designation of primary, backup, or so on. (Well, in actuality, some DCs are a little more equal than others when you factor operations master roles into the equation, but that's not relevant to this discussion.) While this new design increased the fault tolerance and distributed deployment capabilities of the operating system, it's somewhat of an issue if a domain controller anywhere on the network pushes corrupt or otherwise incorrect data to other DCs; how would you prevent that? In branch office scenarios, this issue is particularly serious, since the designated administrator in a branch office needs Domain Admin credentials to administer the DC in her office; this actually gives her the right to administer any DC, not just the one she's responsible for looking after. It's not the best security situation.

While this equality of domain controllers is still the case in Windows Server 2008's AD DS implementation, there is now the concept of a read-only domain controller. A read-only domain controller (RODC) is just that—it receives information replicated to it from full domain controllers, but it doesn't permit any changes to be made to its own copy of the directory database, and thus no information can be replicated back to the full DCs in the domain of which it's a member. This is a great win for branch offices whose companies are large enough to have a comprehensive AD DS structure. Now, you don't have to deploy a full-blown domain controller to your remote locations—you can simply place a RODC there. The benefits are significant and include the following:

  • You reduce the risk of someone attacking a branch office location and sending poisoned data throughout the entire AD DS database.

  • The RODC caches only the credentials of users and computers who have authenticated to the RODC and whom the Password Replication Policy allows to have credentials cached, which reduces the possibility that accounts can be cracked from a stolen branch office domain controller.

  • By default, the RODC does not cache domain administrator credentials, so the keys to the kingdom are more fully protected.

  • The Kerberos authentication tickets issued by the RODC will only be valid for systems within its scope, so it can't issue falsified tokens to get nefarious users onto the full network.

  • The RODC is a Server Core-designated role, which means there's hardly any need for administration locally. No GUI also means a smaller attack surface. To set up a read-only domain controller, run DCPROMO and select the option on the Additional Domain Controller Options screen to make your new domain controller a read-only domain controller.

5.4.8.1. DNS considerations for read-only domain controllers

During the Active Directory Domain Services Installation Wizard, when you're first deploying a RODC, DCPROMO recommends that you install a DNS server locally on the RODC. That server is fed zones from the AD DS infrastructure, and the process will add the RODC's local IP address to the RODC's local DNS client properties, so queries will be directed automatically to the AD-integrated zone on the machine itself.

However, for maximum fault tolerance, if there is only one DNS server and RODC (for instance, if the two services are running on the same machine) at a branch office, Microsoft recommends using the options in your DHCP scope—assuming you are using dynamic IP addresses at your branch office—to include not only the local RODC-based DNS server, but also a DNS server at the main office, where your other AD servers are centrally located. Make sure the local RODC-based DNS server is first on the list, so that only queries that fail to get a response from your local server are directed over the wire to your hub site.

If you have a larger branch office contingent, and you have multiple RODCs deployed at one branch office, you can install a DNS server instance on each RODC. Remember that since RODCs are indeed read-only, any dynamic update requests from your clients have to go directly to a writeable domain controller at your central office. The DNS server instances on RODCs will not attempt to replicate with one another; rather, they will receive all updates directly from the central AD DS infrastructure, so there may indeed be certain times wherein one local RODC has received an updated DNS entry for a client, but another has not. This issue resolves itself (no pun intended) within a replication cycle, but to avoid it, make sure the clients themselves have identical DNS server lists—use DHCP options to assist with this—and only install one DNS server instance per site.


active_directory_troubleshooting_and_ma.html

5.5. Active Directory Troubleshooting and Maintenance

Things will inevitably break in your network—this is a given. Additionally, you'll need to perform a few tasks on a regular basis to keep your AD DS installation running at maximum performance and efficiency. In this section, I'll take a look at troubleshooting and maintenance, and show you how to both keep your network in tip-top shape and how to figure out what's wrong when things go awry.

5.5.1. Auditing Activities in Active Directory Domain Services

Windows Server 2008 and AD DS include an improved auditing infrastructure that lets you more easily see the activities within your domain. By enabling auditing through Group Policy for your domain controllers, you can see success and failure attempts for specific objects within your directory tree when those objects try to access or change settings on your domain.

Auditing in Windows Server 2008's implementation of Active Directory has four subcategories:

Directory Service Access

The information in this audit event is essentially the same as what you received in Windows Server 2003, but the event ID changes to 4662.

Directory Service Changes

This event is new and records both the previous and the new, current value of whatever in the directory changed to the Security event log. Objects with properties that changed will have the old and new values logged (event 5136). New objects will have all of their initial settings logged (event 5137), and objects that are moved will have their old and current locations written to the event log (event 5139). Finally, undeleted objects will have their new destination logged as event 5138.

Directory Service Replication

This audits events regarding successes and failures with replication.

Detailed Directory Service Replication

This digs deeper into replication to provide other information (this is still up in the air and will flesh out during the beta period).

To enable auditing, first open Server Manager, and under Features, expand Group Policy Management, your forest, and the active domain. Click on Domain Controllers, and in the right pane, right-click on Default Domain Controller Policy and click Edit. Within the Group Policy Management Editor window that appears, drill down through Computer Configuration, Windows Settings, Security Settings, and Local Policy, and select Audit Policy. In the right pane, double-click on "Audit directory service access" to configure the policy. Check the "Define these policy settings" box, select whether to audit successes, failures, or both, and then click OK.

At this point, you have enabled the auditing policy. Now, you can specify what should be written on the ACLs of each object you want to audit. From Server Manager, drill down to Active Directory Users and Computers, and select Advanced Features from the View menu. Now, right-click on the organizational unit for which you want auditing to be configured, and select Properties. Navigate to the Security tab and click the Advanced button. On the Advanced Security Settings screen, navigate to the Audit tab, and click Add. Add your users as necessary, and then on the resulting Auditing Entry dialog box, select Descendant User Objects from the "Apply onto" drop-down list box; choose the fourth entry on the list, "Write all properties"; and select whether to audit upon success or failure in the respective columns. Click OK, and OK again, and go back to the Server Manager.

Auditing is now enabled on your domain controllers, and any change to the OU you selected will be logged to the Security event log.

5.5.2. Restarting AD Domain Services

Windows Server 2008 now allows you to restart AD DS without necessarily having to reboot your entire domain controller into Directory Services Restore Mode. This is possible because of a re-architecturing of AD services that allows the Domain Services component to have three possible states:

Started

The nominal state.

Stopped

A newly supported state that in effect turns a domain controller machine into a member server connected to a domain, but with the repair functionality of Directory Services Restore Mode, covered next.

Directory Services Restore Mode

Available after a reboot (strike the F8 key on your keyboard during boot and select this mode from the text-based startup menu) and allows you to perform offline maintenance on many aspects of the AD database, NTDS.DIT, itself. More on this mode later in this chapter.

You can simply stop the Domain Controller service through the Services console. Alternatively, try the following from the command line.

To stop AD DS, issue this command:

net stop ntds

To start AD DS, issue this command:

net start ntds

5.5.3. Troubleshooting AD with DNSLint

Recall DNSLint from Chapter 4? Well, since AD is based on DNS, there are some specific scenarios in which DNSLint can be a lifesaver in terms of identifying and solving a quirky problem with your AD infrastructure. In fact, DNS problems are the most common pitfalls that keep AD from working correctly.

DNSLint can help you figure out when the following issues are occurring:

  • A network adapter whose TCP/IP configuration doesn't refer to an authoritative DNS server for the zone that works with the AD domain.

  • A DNS zone file without a CNAME record with the globally unique identifier (GUID) of each domain controller along with the A records that act as glue records. (Check out Chapter 4 for a refresher on what those terms mean.)

  • Lame delegations to child zones where the NS records specified for the delegation either do not have corresponding glue records or point to servers that are offline or not responding.

  • The DNS zone corresponding to an AD domain does not contain the necessary SRV records, including the _ldap service on TCP port 389 and the _kerberos service on TCP and UDP port 88. GC servers need a SRV record for the _gc service on TCP port 3268.

  • The PDC Emulator FSMO role master does not have a required SRV record for the _ldap service.

Even better, you can use DNSLint with Dcdiag, another program that can be found in the Support Tools on the Windows Server 2008 CD, to perform many tests and checks prior to promoting a machine to a DC role. You can also probe a current DC just to make sure it's configured correctly. Specifically, the /dcpromo switch for Dcdiag tests to verify that you have the correct DNS settings for promoting a machine to a DC, and it will list the problems and solutions if there are any.

To check the machine JH-W2K3-DC2 to ensure that it's ready to be promoted to a DC in the corp.hasselltech.local domain, use the following command:

dcdiag /s:jh-w2k3-dc2 /dcpromo /dnsdomain:corp.hasselltech.local /replicadc

5.5.4. Offline Defragmenting of NTDS Database

Like a hard disk, the database containing all the objects and information within AD DS can become fragmented at times on domain controllers because different parts of the directory are being written to often, and other parts are being rearranged to be read less often. Although you might think that defragging your hard drive will defragment the NTDS.DIT file on your domain controller's hard disk automatically, this just isn't the case.

AD DS handles online defragmenting itself, and it does an adequate job. To really clean out the database, however, and defrag it for the maximum possible gain in efficiency, you need to take the domain controller offline so that the defragmenting process can have exclusive use of the database file. This requires four steps: first, reboot the domain controller in question and get it into directory services restore mode; second, perform the actual defragmentation; third, copy the defragmented database back into the production directory; and fourth, reboot the machine. (Replication to other domain controllers in AD DS won't be affected, as AD DS is smart enough to work around the downed domain controller. It will receive changes when it is brought back online.)

Let's go through these steps now:

  1. Reboot your domain controller.

  2. As the domain controller begins to boot, press F8 to make the Startup menu appear.

  3. Select Directory Services Restore Mode.

  4. When the system prompts you to log in, use the domain administrator account, but use the restore mode password you created when you first promoted this domain controller to a domain controller role.

  5. Open a command prompt.

  6. Enter ntdsutil at the command prompt to start the offline NTDSUtil tool.

  7. Enter file to enter the file maintenance context.

  8. Type compact to <location>, where <location> signifies the path to the place you want the defragmented copy of the directory stored. When defragmented, AD DS makes a copy of the database so that if something goes wrong, you haven't messed up the production copy of the directory.

  9. Look for the line "Operation completed successfully in x seconds." If you see this, type quit to exit NTDSUtil.

  10. At the regular command prompt, copy the file NTDS.DIT from the location you selected in step 8 to \Windows\NTDS. Feel free to overwrite the current file at that location—it is the fragmented version.

  11. Delete any files with the extension .LOG in that same directory.

  12. Restart your domain controller normally, and boot Windows Server 2003 as normal.

Your database is now defragmented.

5.5.5. Cleaning Directory Metadata

As your AD DS implementation ages, you'll probably be left with some junk: old computer accounts that refer to PCs you dumped a long time ago, domain controllers you removed from service without first decommissioning them within AD DS, and other detritus. Every so often, it's a good idea to clean out this old data so bugs that are hard to track (and therefore are hard to troubleshoot) don't pop up, and so future major AD DS actions, such as renaming or removing a domain, aren't held up because of a junked-up directory.

Let's say we have a child domain, called cluster.hasselltech.local, which we want removed. To do this, we again will use the NTDSUtil tool and its metadata cleanup feature. To begin, go to a domain controller and log in as an enterprise administrator. Then follow these steps:

  1. Open a command prompt.

  2. Type ntdsutil to open the program.

  3. Type metadata cleanup to enter that part of the program.

  4. Type connections to receive the Server Connections prompt.

  5. Enter connect to server localhost to initiate a connection with the current domain controller.

  6. Type quit to exit that module.

  7. Now, type select operation target and press Enter.

  8. Type list domains to get a list of domains.

  9. NTDSUtil will bring up a list of domains in your system. In our example, cluster.hasselltech.local comes up as domain 2. So, to set the domain in our sights to destroy, type select domain 2 and press Enter.

  10. Next, you'll need to determine the site in which cluster.hasselltech.local resides. Type list sites to bring up a list like you saw in steps 8 and 9.

  11. In our case, cluster.hasselltech.local resides in site CHARLOTTE, which comes up as site 3 in our list. So, type select site 3 and press Enter.

  12. Now you need to get rid of the domain controllers in that domain. Find out what those machines are by typing list servers for domain in site and pressing Enter.

  13. There are two domain controllers, numbered 0 and 1. You need to get rid of both, so type select server 0 and press Enter.

  14. Type quit, and then type remove selected server. Confirm your choice.

  15. Type select server 1 and press Enter.

  16. Type remove selected server, and again confirm your choice.

  17. Finally, type remove selected domain and press Enter.

  18. Type quit to exit out of NTDSUtil.


the_last_word-id4.html

5.6. The Last Word

We've covered a lot of material in this chapter—perhaps the most complex component of Windows Server 2008, Active Directory Domain Services. In the next chapter, we'll look at the wonderful component of Group Policy, which allows you to manage groups of systems with remarkable ease and consistency. GP's foundation is in Active Directory, as you will see.


group_policy_and_intellimirror.html

Chapter 6. Group Policy and IntelliMirror

Windows Server 2008 offers a marvelous command and control system for your organization's computers called Group Policy (GP). With GP, you can manage user- and computer-based configurations, which you can apply en masse to computers in a particular Active Directory site, OU, or domain.

In this chapter, I'll introduce you to GP and its features and functions. I'll take you through creating and editing GPs and expanding or refining their scope. I'll show you how inheritance and overriding work, and I'll look at using the Windows Management Instrumentation (WMI) interface and the new Resultant Set of Policy (RSoP) tools in Windows Server 2008 to filter and further granulate policy application. Then, you'll see the similarities and differences between local and domain GP. Finally, I'll review troubleshooting strategies and considerations for wide-scale GP deployment.

6.1. An Introduction to Group Policy

Group policies consist of five distinct components:

Administrative templates

Configure Registry-based policies. You'll see what this really entails in a bit.

Folder redirection

Alters the target location of various elements in the UI, such as My Documents, to other places on the network.

Scripts

Execute when computers are first booted and shut down. They also can run during user logon and logoff.

Security settings

Configure permissions, rights, and restrictions for computers, domains, and users.

Software policies

Assign application packages to users and computers.

The data for each component is stored in a Group Policy Object (GPO). In domain-based GPs, GPOs are stored at various levels in Active Directory, but they're always associated with a domain. GPOs are affiliated with a variety of objects within Active Directory, including sites, domains, domain controllers, and OUs, and they can be linked to multiple sites, to the domains themselves, and to OUs. For non-domain-based (i.e., local) GPs, you simply configure those settings on individual servers.

Local computer policies are stored in the %SystemRoot%\System32\GroupPolicy directory because they apply only to the computer on which they're stored and they need not be replicated. Local policies are also more limited in scope and ability, as you'll see later in this chapter.

When you first set up an Active Directory domain, two default GPOs are created: one that is linked to the domain itself, and therefore affects all users and computers within the domain; and one that is linked to the Domain Controllers OU, which affects all domain controllers within a domain.


an_introduction_to_group_policy.html

Chapter 6. Group Policy and IntelliMirror

Windows Server 2008 offers a marvelous command and control system for your organization's computers called Group Policy (GP). With GP, you can manage user- and computer-based configurations, which you can apply en masse to computers in a particular Active Directory site, OU, or domain.

In this chapter, I'll introduce you to GP and its features and functions. I'll take you through creating and editing GPs and expanding or refining their scope. I'll show you how inheritance and overriding work, and I'll look at using the Windows Management Instrumentation (WMI) interface and the new Resultant Set of Policy (RSoP) tools in Windows Server 2008 to filter and further granulate policy application. Then, you'll see the similarities and differences between local and domain GP. Finally, I'll review troubleshooting strategies and considerations for wide-scale GP deployment.

6.1. An Introduction to Group Policy

Group policies consist of five distinct components:

Administrative templates

Configure Registry-based policies. You'll see what this really entails in a bit.

Folder redirection

Alters the target location of various elements in the UI, such as My Documents, to other places on the network.

Scripts

Execute when computers are first booted and shut down. They also can run during user logon and logoff.

Security settings

Configure permissions, rights, and restrictions for computers, domains, and users.

Software policies

Assign application packages to users and computers.

The data for each component is stored in a Group Policy Object (GPO). In domain-based GPs, GPOs are stored at various levels in Active Directory, but they're always associated with a domain. GPOs are affiliated with a variety of objects within Active Directory, including sites, domains, domain controllers, and OUs, and they can be linked to multiple sites, to the domains themselves, and to OUs. For non-domain-based (i.e., local) GPs, you simply configure those settings on individual servers.

Local computer policies are stored in the %SystemRoot%\System32\GroupPolicy directory because they apply only to the computer on which they're stored and they need not be replicated. Local policies are also more limited in scope and ability, as you'll see later in this chapter.

When you first set up an Active Directory domain, two default GPOs are created: one that is linked to the domain itself, and therefore affects all users and computers within the domain; and one that is linked to the Domain Controllers OU, which affects all domain controllers within a domain.


group_policy_implementation.html

6.2. Group Policy Implementation

Now that you know the components of GP, let's look at how they are implemented. Like NTFS permissions, GPs are cumulative and inherited—cumulative in that the settings modified by a policy can build upon other policies and "amass" configuration changes, and inherited in that objects below other objects in Active Directory can have any GPs that are applied to their parent object be applied to themselves automatically.

GPOs are associated with, or linked, to any number of objects, either within a directory or local to a specific machine. To implement a GP on a specific type of object, follow these guidelines.

Local computer

Use the Local Security Policy snap-in inside Control Panel rightwards double arrow Administrative Tools. Or, for a more complete look, use Start rightwards double arrow Run rightwards double arrow gpedit.msc.

A specific computer

Load the MMC, and then select Add Snap-in from the File menu. Browse in the list and add the Group Policy Object Editor to the console. On the Select Group Policy Object screen, peruse the list to find the specific object you want.

Entire domain

Install and launch the Group Policy Management Console, and then right-click on the domain and create or edit a policy from there.

OU within Active Directory

Install and launch the Group Policy Management Console, right-click on the OU, and create or edit a policy from there.

Active Directory site

Launch Active Directory Sites and Services, right-click the site's name, and select Properties from the context menu. Navigate to the Group Policy tab, and create or edit a policy from there.

Windows applies GPs in the following order, which you can remember with the acronym of "LSDOU":

  1. Local GPOs

  2. Site-specific GPOs, in an order which the site administrator configures

  3. Domain-specific GPOs, in an order which the domain administrator configures

  4. OU-specific GPOs, from the parent OU down through the ranks to the child OU

The only exception to this rule occurs when you're using NT 4.0 system policies that are created and set with the NT System Policy Editor. Recall from NT administration days that the system policies are called NTCONFIG.POL, so if Windows finds that file present, it applies these policies before the local GPO. Of course, these policies can be overwritten by policies that come farther down in the application chain.

Here's an easy rule of thumb to remember: for domain-based GPs, the lowest-level Active Directory container has the last opportunity to override inherited policies. For example, a policy applied to a site will be overwritten by a policy applied to an OU, and a local policy will be overwritten by an Active Directory object-based policy.

6.2.1. Introducing the Group Policy Management Console

You'll find that GPOs themselves are much easier to create and edit using Microsoft's Group Policy Management Console (GPMC), a drop-in replacement for the more limited Group Policy Object Editor that you might know from previous versions of Windows Server. While it's certainly possible to perform the actions I'll describe in this chapter with the native Group Policy Object Editor, the tool has limitations: the biggest by far being the lack of ability to see the exact scope of a GPO's application, making troubleshooting very difficult. The GPMC fixes this and also offers a cleaner interface, scripting functionality, and enhancements to troubleshooting and modeling features.

Launch the Group Policy Management Console from the Server Manager; you'll see a screen much like Figure 6-1.

Figure 6-1. The Group Policy Management Console

To navigate around in the GPMC, you need to expand the forest you want to manage in the left pane. Then you can select specific domains and sites within that forest, and OUs within individual domains. When you expand, for example, a particular domain, links to the GPOs that exist are listed within their respective OUs. They also are listed under the Group Policy Objects folder. Clicking on a GPO brings up a four-tabbed screen in the right pane.

The first tab is the Scope tab, which examines how far-reaching the effects of this GPO are. Sites, domains, and OUs that are linked to the GPO you've selected are listed at the top of the window. You can change the listing of pertinent links using the drop-down box, where you can choose to list links at the current domain, the entire forest, or all sites. At the bottom of the window, any security filtering done by ACLs is listed. Clicking the Add button brings up the standard permissions window, as you would expect from the Group Policy Object Editor.

At the very bottom, you can see any WMI filters to which this GPO is linked. You can choose to open the WMI filter for editing by clicking the Open button. You can associate only one WMI filter with any particular GPO, and WMI filters work only with Windows XP, Windows Vista, Windows Server 2003, and Windows Server 2008. We'll get to these in a bit—for now, let's move on.

The next tab, Details, simply shows the domain in which the current GPO is located, the owner of the GPO, when the GPO was created and modified, the version numbers for the user and computer portions, the GUID of the object, and whether the GPO is fully enabled or fully disabled or whether just the computer or user configuration portions are enabled.

Of particular interest is the Settings tab, as shown in Figure 6-2.

Figure 6-2. Examining a standard GPO via the Settings tab

The Settings tab is one of the most useful tabs in the GPMC. The GPMC will generate HTML-based reports of all the settings in a particular GPO, and you can condense and expand portions of the report easily for uncluttered viewing. You can print the report for further reference, or save the report for posting to an internal web site for your IT administrators. It's a much, much easier way to discern which settings a GPO modifies than the Group Policy Object Editor. To edit the GPO that is displayed in the report, simply right-click it and select Edit. To print the HTML report, right-click it and select Print; to save the report, right-click it and select Save Report.

Finally, the Delegation tab lists in a tabular format the users and groups that have specific permissions for the selected GPO, what those permissions are, and whether they're inherited from a parent object. Clicking Add brings up the common Select User, Computer, or Group dialog box that you are familiar with from reading this chapter. You can remove a delegated permission by clicking the appropriate user or group in the list and then clicking the Remove button. The Properties button will bring up the standard Active Directory Users and Computers view of the selected user and group.

You'll see more of this interface in action as we proceed through the chapter.

6.2.1.1. Creating and editing Group Policy Objects

To start off, you need some GPOs to work with. Use the tree in the left pane to navigate through the various forests and domains on your network. Then, when you've settled on a location, right-click on that location and select "Create and Link a GPO Here." In the New GPO box, enter a name for the object, and then click OK. You'll see the new GPO listed in the righthand pane; the GPO creation process is finished.

To edit the object, right-click the object and select Edit. You're presented with a screen much like that shown in Figure 6-3.

Figure 6-3. The Group Policy Object Editor screen

You'll note that there are two branches to each GPO: Computer Configuration and User Configuration. Each contains the same subtrees under the Policies node: Software Settings, Windows Settings, and Administrative Templates. The Computer Configuration tree is used to customize machine-specific settings, which become effective when a computer first boots. These policies are applied across any users that log on to the system, independent of their own individual policies. Using computer policies, you can lock down a group of computers in a lab or kiosk situation while still maintaining an independent set of user policies. The User Configuration tree, as you might suspect, contains user-specific settings that apply only to that user regardless of where she is on the network.

6.2.1.2. Group Policy Preferences

You might have also noticed the Preferences node in the Group Policy Object Editor (see Figure 6-3 for a refresher). Windows Server 2008 incorporates a feature called Group Policy Preferences, which is essentially the old products PolicyMaker Standard Edition and Policy Share Manager in new form, directly into the Group Policy Management Console (GPMC). In a nutshell, preferences allow you to "suggest" an initial configuration to your users while still giving them the ability to change them. Let's delve a little deeper into this.

Group Policy itself was designed so that an administrator determines and sets up his mandatory environment, configures it appropriately for the organization's needs, and then leaves it up to Windows to strictly enforce those settings. GP generally overrides any user-provided settings in the event of a conflict, and it typically disables any user interface functions that could be used to change those settings. And while one can limit or otherwise affect the scope of a GPO, it essentially can touch every machine that is a member of any given Windows domain. Machines and settings controlled by Group Policy are termed "managed" machines and settings.

Group Policy preferences take a lighter approach. While GP preferences still are set up by an administrator and filter down to managed clients, GP writes preferences to the same places in the Registry where applications store their data about that specific setting. This lets GP address settings and switches in applications that don't by default know about Group Policy. In addition, there isn't a restriction on the user interface of the software, so if the administrator-defined preferences don't meet a user's working style or in some other way aren't what a user wishes, she is free to change them. You can also define the schedule at which Group Policy refreshes preference information—it can either be done at the same interval that GP refreshes policy (the mandatory settings), or you can set it once and then prohibit Windows from refreshing that preference again.

Supporting Group Policy preferences is also lightweight. You can create GPOs that contain preference information right out of the box. On the client, you'll need to install—via a separate download—a client-side extension; this will need to be deployed to any computer that is a target of your preference settings. The client-side extension will support Windows XP Service Pack 2 and later, Windows Vista, and Windows Server 2003 with Service Pack 1 and later. (If you install Windows Server 2008, you already get the CSE.)

You can create preference entries by right-clicking on the appropriate preference item in the left pane of the Group Policy Management Editor and selecting New from the context menu. The same breakdown for regular GPOs applies for GP preferences: Computer Configuration is used to customize machine-specific settings, which become effective when a computer first boots, and User Configuration is used to configure settings that apply only to that user regardless of where she is on the network.

6.2.1.3. Starter Group Policy Objects

Starter Group Policy Objects are designed to get you started deploying GPOs based on commonly used configurations. These starter objects have preconfigured settings that are well commented-upon within each setting, making it very easy to deploy a consistent set of baseline configurations. Think of starter GPOs as quick-start templates, which you can build on to create your custom set of GPOs specific to your environment.

You'll need to create the Starter GPOs folder in each domain; fortunately, this is an easy process. In the Group Policy Management Console, expand the appropriate forest and domain, click Starter GPOs, and in the right pane, click the Create Starter GPOs folder. You'll only need to do this once per domain. Essentially, this step creates a folder called StarterGPOs inside the SYSVOL folder at this path: \\domain.com\SYSVOL\domain.com\StarterGPOs.

To create a new starter GPO (akin to creating the "template" from which your future GPOs will originate), right-click on the Starter GPOs and choose New from the context menu. Enter a name for the GPO and a description, which will also migrate to future GPOs, and then click OK.

To create a GPO based on these starter GPOs, when you start to create a new GPO, choose the appropriate starter GPO from the "Source Starter GPO" list in the New Group Policy Object window. The settings will automatically drop down to your new GPO from the starter GPO at that point.

6.2.1.4. Filtering and commenting

The myriad amount of settings available in Group Policy can be overwhelming, and accordingly Windows Server 2008 now offers the ability to filter through the available switches in Group Policy to find the object you're looking for. In the toolbar, click the Filter button, or right-click on Administrative Templates under Computer Configuration or User Configuration and select Filter Options. You can choose to display any managed setting, settings that have already been configured, or settings that have an administrator-appended comment on them. You can also filter by keyword, like a Google search, or filter by system requirement—if you want to, for example, show settings that apply to systems with Internet Explorer 6.0.

Of course, if you work as a team of administrators lording over an enterprise-wide Group Policy deployment, you might want to comment or otherwise document directly in the system what certain configurations you've set up actually do. Enter the commenting feature, which allows you to document right on a setting what that function is intended to accomplish. Your peers can also search on your comments using the comment as the criteria in their query.

To enter a comment:

  1. Open the Group Policy Management Console.

  2. In the left pane, find the GPO in question and right-click on it to bring up the context menu; select Edit.

  3. Right-click on the very top-most node in the left pane (it should be the name of the GPO) and select Properties.

  4. Navigate to the Comment tab.

  5. Enter the comment as you wish, and then click OK.

6.2.1.5. Disabling portions of policies

A GPO has the potential to be large because it can contain numerous computer and user settings. If you don't intend to populate either your computer or user settings, you can disable that portion of the GPO. By doing this, you're speeding up propagation time over the network and processing time on the computers that need to load the settings in the object. So, if you have a GPO that applies only to computers, you can disable the user configuration branch of the policy and significantly improve the performance of your network. To do so, follow these steps:

  1. Open the Group Policy Management Console.

  2. In the left pane, find the GPO in question and click on it to select it.

  3. In the right pane, navigate to the Details tab, and under the GPO Status dropdown box (shown in Figure 6-4), select "User configuration settings disabled."

  4. Click OK.

Figure 6-4. Disabling a portion of a policy

The portion of the policy you selected is now disabled. (Of course, you can disable the computer portion of policies using the same method.)

6.2.1.6. Refreshing computer policies

Speaking of changes to policies, it can take some time for modifications to propagate across domain controllers within a domain and finally to the objects for which they're destined. Policies are refreshed on a client when the computer is turned on, a user logs on, an application requests a policy refresh, a user requests a policy refresh, or the interval between refreshes has elapsed. The latter part of that sentence is key: there's a GPO you can enable that will allow you to customize the interval at which computer and domain controller policies refresh. It's best to make this change at either a domain or OU level for consistency.

To enable the policy refresh interval, follow these steps (I'll assume you're changing this on a domain-wide basis):

  1. Within the Group Policy Management Console, find the Default Domain Policy in the left pane.

  2. Right-click on Default Domain Policy, and choose Edit.

  3. The Group Policy Object Editor window appears. In the Computer Configuration tree, navigate through Policies, Administrative Templates, and System.

  4. Click Group Policy.

  5. In the right pane, double-click the setting Group Policy refresh interval for computers, or Group Policy refresh interval for domain controllers, whichever is applicable.

  6. Select Enabled, and then enter an interval for the refresh. Be sure to make this a healthy interval; otherwise, you will degrade your network's performance with constant traffic updating policies across the domain. For smaller networks, 15 minutes should be an acceptable timeframe. Allow 30 to 45 minutes for larger networks.

  7. Click OK.

You also can also manually force a policy refresh from the command line on client computers with the gpupdate command. To refresh all parts of a policy, issue this command:

gpupdate /force

To refresh just the Computer Configuration node of the policy:

gpupdate /target:computer /force

To refresh just the User Configuration node of the policy:

gpupdate /target:user /force

Domain controllers make refresh requests every five minutes by default.

To manually refresh GPOs on Windows 2000, the syntax is a little different. To refresh only the computer policy:

secedit /refreshpolicy machine_policy

To refresh only the user policy:

secedit /refreshpolicy user_policy

You can force updates of objects, even if they haven't been modified since the last update, by adding the /enforce switch at the end of the command. Then Windows will enforce all policies, regardless of whether the actual policy objects have changed. This is useful if you are having network difficulties and want to ensure that every computer has a fresh application of policy, or if you have a large contingent of mobile users that connect to the network briefly and unpredictably.

For either clients or domain controllers, exercise extreme caution when modifying the default refresh interval. On large networks, altering the refresh interval can cause hellish amounts of traffic to be unleashed over your network—a costly move that's unnecessary for 95% of sites with domains installed. Although clients will pull down new policies only if those policies have changed, the increased traffic results from clients just contacting a domain controller every x minutes to get new policies and updates. There's very little reason to alter this value. Here's a good rule of thumb: if you don't know of a good justification to increase the refresh interval, it isn't necessary for your site.

Folder redirection and software installation policies are not processed during a background policy refresh.

If you want, you can also elect to disable background policy refreshing completely. You might do this if you're having trouble tracking down an intermittent GPO problem, or if you don't want to have a GP applied during the middle of a client session because it might disrupt an application. Again, it's best to do this on a domain-wide or OU-wide basis for consistency and best performance.

To disable background processing, follow these steps:

  1. Within the Group Policy Management Console, find the Default Domain Policy in the left pane.

  2. Right-click on Default Domain Policy, and choose Edit.

  3. The Group Policy Object Editor screen appears. In the Computer Configuration tree, navigate through Policies, Administrative Templates, and System.

  4. Click Group Policy.

  5. In the right pane, double-click the setting "Turn off background refresh of Group Policy."

  6. Select Enabled.

  7. Click OK.

In some situations, you might want a policy setting to be applied, even if no setting has changed. This goes against default GPO behavior because usually, only changes trigger a policy refresh and reapplication. For example, a user might change some Internet Explorer settings within his session. You might want that change to be reversed, but Windows won't trigger a refresh because the policy itself hasn't changed. To prevent this, you can use the configuration option called "Process even if the Group Policy Object has not changed." (This is like the /enforce switch described a bit earlier.) You've probably caught on by now that it's best to do this on a domain-wide or OU-wide basis for consistency and best performance.

To do so, follow these steps:

  1. Within the Group Policy Management Console, find the Default Domain Policy in the left pane.

  2. Right-click on the Default Domain Policy GPO and choose Edit.

  3. In the Computer Configuration tree, navigate through Policies, Administrative Templates, System, and Group Policy.

  4. You'll see a list of options ending in "policy processing," such as "Scripts policy processing" and "Wireless policy processing." These GPOs exist to allow you to tweak the functionality of these types of policies. Open the appropriate policy up (which one is best for you depends on the type of policy that you're trying to trigger to change) to view its Properties.

  5. Click the Enabled button.

  6. Finally, check the "Process even if the Group Policy Object has not changed" checkbox.

Checking the box in step 6 provides the same functionality as issuing the command gpupdate /enforce from the command line.

Policy settings related to computer security follow a refresh policy that is a bit different from normal GPOs. The client computer still refreshes security policy settings even if the GPO has not been changed or modified. There are Registry settings whose values indicate the maximum acceptable time a user or client computer can wait before reapplying GPOs, regardless of whether they are changed. They are as follows:

  • To change the refresh interval for computers, set HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTime. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 64,800.

  • To change the offset interval for computers, set HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTimeOffset. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 1,440.

  • To change the domain controller refresh interval, set HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTimeDC. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 64,800.

  • To change the domain controller offset interval, set HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTimeOffsetDC. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 1,440.

  • To change the refresh interval for users, set HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTime. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 64,800.

  • To change the offset interval for users, set HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTime. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 1,440.

6.2.1.7. Policy enforcement over slow network connections

Windows Server 2008 will detect the speed of a client's connection to the network and, based on its measurements, disable enforcement of certain policies that would bog down a slow connection. Policies that Windows will disable include disk quotas, folder redirection, scripts, and software installation and maintenance. By default, Windows considers a speed of less than 500 Kbps a slow link, but you can change this on a per-GPO basis.

To change the slow link threshold, follow these steps:

  1. Edit the GPO for which you want to change the threshold in the Group Policy Management Console.

  2. Navigate through Computer Configuration or User Configuration, as well as through Policies, Administrative Templates, System, and Group Policy.

  3. Double-click the Group Policy Slow Link Detection policy in the righthand pane.

  4. Click the Enabled option, and enter the connection speed you want to be the new threshold. Enter 0 to simply disable slow link detection.

  5. Click OK when you're finished.

6.2.2. The Scope of Group Policy Objects

So, how far do these GPOs go? What types of objects can GPOs affect? To deploy a GP to a set of users, you "associate" a GPO to a container within Active Directory that contains those users. By default, all objects within a container with an associated GPO have that GPO applied to them. If you have a large number of GPOs or Active Directory objects, it can be confusing to track the scope and application of GPOs. Luckily, you can find out which containers a specific policy is applied to by selecting the GPO in the Group Policy Management Console and looking in the right pane at the Scope tab. The Links section will reveal the sites, domains, and OUs that are affected by the GPO. To adjust the view of links, you can use the drop-down list box under the Links section and choose the sites and domains you wish to see. You can see this section in Figure 6-5.

Of course, in practice there are always exceptions to any rule; for example, most likely there will be some computers within a container that shouldn't have a policy applied to them. The most straightforward way to limit the scope of a GPO within a specific container is to create security groups that contain only the objects that are to be included in the policy application. Once you've created the necessary groups, follow these steps:

  1. Select the GPO you want to administer in the left pane of the Group Policy Management Console.

  2. On the Scope tab in the right pane, click the Add button under Security Filtering, and then add the groups that do not need the policy applied.

  3. Verify that the group was added to the Security Filtering list, as shown in Figure 6-5.

Figure 6-5. Enabling security group filtering

The GPMC makes it straightforward to limit the application of a GPO to a specific group, as you just saw. But what if you want more granular control than this? You also can play more tricks with groups and GPO ACLs to further limit the effects of policy application to objects, but you'll need to dive into the advanced security settings of the object itself to get more complex operations done. To get there, navigate to the Delegation tab in the right pane of the GPMC and click the Advanced button in the lower-right corner. The screen shown in Figure 6-6 will appear.

Figure 6-6. Manually setting security group filtering

The following is a list of appropriate ACL permissions to grant to obtain the desired result:

  • If you do not want the policy to be applied to all members of a certain security group, add all the members to a group, add the group to the ACL for the object, and set the following permissions for the group: Apply Group Policy, deny; Read, deny. All members of the group will not have the policy applied, regardless of their existing memberships to other groups.

  • If group membership (at least in a specific group) shouldn't play a part in the application of this policy, leave permissions alone.

6.2.3. Enforcement and Inheritance

Policies applied to parent objects are inherited automatically by child objects unless there are conflicts; if a child's directly applied policy conflicts with a general inherited policy from a parent, the child's policy will prevail, on the assumption that the administrator really wanted the result of the specifically applied policy and not one that is granted indirectly because of directory tree position. Policy settings that are currently disabled migrate to child objects in the disabled state as well, and policy settings that remain in the "not configured" state do not propagate at all. Additionally, if there are no conflicts, two policies can coexist peacefully, regardless of where the initial application occurred.

As with permissions, you can block GPO inheritance by using two options available within the user interface: Enforced, which instructs child containers to not replace any setting placed higher on the tree than they are; and Block Policy Inheritance, which simply eliminates any inheritance of parent object policies by child objects. If both of these options are set, the Enforced option always trumps the Block Policy Inheritance feature.

Explicit permissions, be they Allow or Deny permissions, will always trump inherited permissions, even if Deny permissions on an object are inherited from a parent. Explicitly granting access to an object cannot be overridden by an inherited denial.

To set a GPO to not override parent GPO settings, you need to set the GPO status to Enforced. Follow these steps:

  1. In the GPMC, select the domain in which the GPO resides in the left pane.

  2. In the right-pane, navigate to the Linked Group Policy Objects tab.

  3. Right-click the object and select Enforced from the pop-up context menu. You'll receive a confirmation notice, which is shown in Figure 6-7.

  4. Click OK to apply the changes.

Figure 6-7. Setting the Enforced option on a GPO

To block any inheritance of parent policy settings for the current administrative container, first double-click the forest containing the domain or organizational unit for which you want to block inheritance for GPOs, and then do one of the following:

  • To block inheritance of GPOs for an entire domain, double-click Domains, and then right-click the domain.

  • To block inheritance for an OU, double-click Domains, double-click the domain containing OU, and then right-click on the OU.

Finally, click Block Inheritance, as shown in Figure 6-8.

Figure 6-8. Setting the Block Inheritance option

You'll see a small blue exclamation point in the icon beside the domain or OU for which you've blocked inheritance, indicating the operation was successful. To remove the inheritance block, use the aforementioned procedure, and simply uncheck Block Inheritance on the context menu.

If multiple GPOs are assigned to an object, GPOs at the bottom of the list in the right pane of the GPMC are applied first, and objects at the top are applied last. Therefore, GPOs that are higher in the list have higher priorities.

6.2.4. WMI Filters

Windows Server 2008 can filter how Group Policy is applied based on Windows Management Instrumentation (WMI) data. Using WMI filters, you can construct a query with WMI Query Language (WQL) that will return various results onto which you can apply a GP. WMI allows you to pull various characteristics otherwise unavailable through the GPMC, such as a computer's manufacturer and model number, the installation of certain software packages, and other information. You might use WMI when applying policies using these criteria.

To create a WMI filter in the GPMC, right-click on the WMI Filters link in the left pane and select New. The New WMI Filter is shown, as depicted in Figure 6-9. Enter a name and description for the filter; then create the query that will represent the dataset against which the GPO will be filtered by clicking Add, selecting the namespace, and then entering the syntax of the query. Note that you can add more than one query to a filter. While constructing WMI queries is outside the scope of this book, you'll find that such queries are very similar in format to SQL queries. For this example, I'll use a simple query that retrieves machines running Windows XP on the network, as shown in the figure.

Figure 6-9. Creating a new WMI filter

Once you've entered the query and are satisfied with it, click Save.

To enable a WMI filter on a particular GPO, click the GPO in the GPMC and look at the bottom of the Scope tab in the right pane. There, you can select the WMI filter to apply to the GPO, as shown in Figure 6-10.

Figure 6-10. Adding a WMI filter to a GPO

Keep in mind that if you set a WMI filter for a GPO, it's an all-or-nothing affair: you can't individually select certain policy settings to apply only to the filtered objects. Either the entire policy applies to the list of filtered objects, or the entire policy doesn't apply. Unfortunately, this might result in an inordinate number of GPOs in your directory, each servicing a different list of filtered objects. Keep this in mind when structuring policies. Also be aware that you can apply only one WMI filter per GPO, although each WMI filter can contain multiple WMI queries, as I noted before.

If you're not familiar with WMI, Microsoft has provided a utility called Scriptomatic, which, although unsupported by Microsoft, helps you construct and use WMI queries for many different Windows administration tasks. You can find the Scriptomatic utility at http://www.microsoft.com/downloads/details.aspx?FamilyID=9ef05cbd-c1c5-41e7-9da8-212c414a7ab0&displaylang=en.

If you're curious, here is a brief sample WMI filter that can reside as a simple XML file on a hard drive; these types of filters use a .MOF extension. This will give you an idea of the structure of a filter and how to create one:

<?xml version="1.0" encoding="utf-8" ?>
<filters>
<filter>
<description>XP Machines</description>
<group>MYDOMAIN\Windows XP Computers</group>
<query namespace="ROOT\CIMv2">
SELECT * FROM Win32_OperatingSystem
WHERE Version =
5.1.2600
</query>
<!-- More queries -->
</filter>
<!-- More filters -->
</filters>

If you have a lot of WMI filters in separate files, you can import them by right-clicking on WMI Filters in the left pane of the GPMC and selecting Import. You can browse for your MOF files and then import them for use in filtering.

6.2.5. Resultant Set of Policy

In Windows 2000, there was no easy way to see all the policies applied to a specific object, nor was there a way to easily project the potential changes to an object that a policy modification would make. However, Windows Server 2008 includes the Resultant Set of Policy (RSoP) tool, which can enumerate the following situations:

  • Show policies in effect, in the "logging" mode. In the GPMC, this is called "results."

  • Show the results of a proposed policy addition or change, in the "planning" mode. In the GPMC, this is called "modeling."

You can access each using the Group Policy Modeling and Group Policy Results items in the left pane of the GPMC. Right-click on the appropriate item and select the option that runs each wizard.

6.2.5.1. Planning mode

In RSoP planning mode, accessed through Group Policy Modeling, you can simulate the effects of the deployment of GPOs, change the GPO in accordance with those results, and then re-test. You can specify a particular domain controller, users, security groups, and user memberships within, the location of a machine or site, and any applicable WMI filters, and then model the results of applying a specific GPO.

To get started in planning mode, right-click Group Policy Modeling and, from the context menu, select Group Policy Modeling Wizard. Click Next from the introductory screen. The Domain Controller Selection screen appears, as shown in Figure 6-11.

Figure 6-11. Modeling Group Policy: selecting a domain controller

Here, select the domain controller to use when processing the RSoP request. This domain controller must be running at least Windows Server 2003, if not Windows Server 2008. You can choose a specific domain controller from the list, or let Windows choose a domain controller. You can also select a given domain to use its respective domain controllers using the "Show domain controllers in this domain:" drop-down list. Click Next to continue.

The User and Computer Selection screen appears, as shown in Figure 6-12.

Figure 6-12. The User and Computer Selection screen

On this screen, you specify the user and computer settings you want to have analyzed when you apply GP. You can also choose a container if you want to analyze Group Policy objects that have been linked to a particular site, domain, or OU. Note also at the bottom of the screen the option to skip to the end of the wizard. If you have a simple query that is complete at any point during the wizard, simply select this option to bypass the remaining screens and go straight to the results of the query. Click Next to continue.

The Advanced Simulation Options screen appears, as shown in Figure 6-13.

Figure 6-13. The Advanced Simulation Options screen

On this screen, you can tell Windows to simulate a very slow link between domain controllers and clients, whether to merge or replace loopback processing, and the site to which these settings should apply. This is a very useful algorithm for testing real-world conditions. Click Next to continue.

You'll next see the Alternate Active Directory Paths screen, as shown in Figure 6-14.

Figure 6-14. The Alternate Active Directory Paths screen

On this screen, you can simulate the effects of moving your targets to different locations within your AD structure. You can use the default entries, which reflect the current location of the target objects, or change them using the Browse button to see what would happen if you moved the target to a new location. Click Next to continue.

Next comes the User Security Groups screen. On this screen, you can see the results of applying Group Policy if you change the existing user or computer's security group memberships. The current group memberships are listed in the box, and you can add and remove them using the Add and Remove buttons. To undo your changes, just click Restore Defaults. Click Next when you have the list as you want it.

If you have selected a computer or container of computers in the initial step of the wizard, the Computer Security Groups screen will appear next, as depicted in Figure 6-15. It operates exactly like the User Security Groups screen does, as just described. Click Next to continue.

Figure 6-15. The Computer Security Groups screen

The WMI Filters for Users (or Computers, depending on your initial RSoP query) screen appears next, as shown in Figure 6-16.

Figure 6-16. The WMI Filters for Computers screen

Here, you instruct Windows to assume that the user (or container of users) you've selected meets either all configured WMI filters or the specified WMI filter as shown in the box. Click Next when you've selected the appropriate filters.

The next screen is a summary of your selections. Confirm that all is well, and then click Next to begin the simulation. When the process is complete, the wizard will let you know. When you click Finish, the results will appear. A sample results screen is shown in Figure 6-17.

Figure 6-17. Group Policy Modeling results

The result is an HTML file that you can collapse and expand as needed. You can see each computer configuration and user configuration result, including GPOs that would be applied and denied, any WMI filters that would be used, how each GP component would survive the deployment, and general information about the query. You can right-click the report and either print or save it. And, if you change your GP settings and want to rerun the same query on the new settings, simply right-click the results page within the GPMC and select Rerun Query.

6.2.5.2. Logging mode

The RSoP logging mode with the GPMC, called Group Policy Results, operates in much the same way as the planning mode does. To get started, right-click Group Policy Results in the left pane of the GPMC and select Group Policy Results Wizard from the context menu.

Click away from the introductory screen in the wizard, and the Computer Selection screen appears, as shown in Figure 6-18.

Figure 6-18. The Computer Selection screen

Here, select the computer for which you want to obtain results. You can analyze the current computer or another computer on the network. You also can limit the results to only the User Configuration portion of GP using the checkbox in the middle of the screen. Click Next to continue.

The User Selection screen appears next. This is reproduced in Figure 6-19.

Figure 6-19. The User Selection screen

On this screen, you can select which user to report the results of the User Configuration section for. The list is limited to those who have logged on to the computer at some point in time and for whom you have permission to read the results. You also can limit the results displayed to computer configuration information only by using the radio button at the bottom of the screen. Click Next to continue.

The Summary of Selections screen appears. Confirm your choices, and click Next to perform the query. When the process is complete, the wizard will notify you. Click Finish to view the results; a sample result screen is shown in Figure 6-20.

Figure 6-20. Results from the Group Policy Results Wizard

Like the other GPMC reports, this one is HTML-based and can be saved and printed by right-clicking anywhere in the report and selecting the appropriate option. For each of the Computer Configuration and User Configuration portions of GP, the report shows the following:

  • General information about the query

  • GPOs that were applied and GPOs that were denied

  • The user and/or computer's membership in security groups when GP was applied

  • WMI filters that "catch" the user or computer

  • The status of each component of GP, including GPOs themselves, EFS recovery, the Registry, and security (permissions)

6.2.5.3. Using RSoP without the GUI

You also can script some functions using the RSoP APIs. The sample script provided in Example 6-1, courtesy of http://ActiveDir.org (with some modifications), logs the user and computer objects being applied to a particular set of objects within Active Directory. To use it, copy and paste the following text into your favorite text editor, and save it using a .vbs extension. Then, run it from the command line using the following:

Cscript filename.vbs

Example 6-1. Creating an RSoP report with VBScript

'------------------------------------------------------------------------
ComputerName = InputBox("Enter the name of a computer running " & _
"Windows XP, Windows Server 2003, or Windows Server 2008", _
"Information","")
UserName = InputBox("Enter a user name under which to run the report", _
"Information","")
resultpath = InputBox("Enter a location to store the report", _
"Information", "c:\temp")
resultpath = resultpath&"\"&UserName&".HTML"
Set GPMC = CreateObject("GPMgmt.GPM")
Set Constants = GPMC.GetConstants( )
Set RSOP= GPMC.GetRSOP(Constants.RSOPModeLogging,"",0)
RSOP.LoggingComputer=ComputerName
RSOP.LoggingUser=UserName
RSOP.CreateQueryResults( )
RSOP.GenerateReportToFile Constants.ReportHTML, resultpath
msgbox("RSoP report complete! A full report has been placed at " & _
resultpath)
'--
----------------------------------------------------------------------

You can retrieve information on the RSoP application in a few other ways as well. Microsoft includes a tool with the Windows 2000 Resource Kit, called GPRESULT.EXE, which you can run on a client computer. (Later versions of Windows have this utility installed by default.) GPRESULT will return a listing of all policies applied to a user and computer, the OUs in which the computer and user are located, the site they are in, and a lot more information. You can find the GPRESULT executable and technical information on the tool at http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpresult-o.asp. The remote computers need to run at least Windows XP or Server 2003, however, for GPRESULT to return accurate information.

For example, to get information for the user jhassell on the remote workstation JH-WNXP-LTP using GPRESULT, run:

gpresult /s JH-WNXP-LTP /USER jhassell

Likewise, to get information for the user ljohnson on the remote workstation LJ-WNXP-DSK, run:

gpresult /s LJ-WNXP-DSK /USER ljohnson

You also can add the /V option to enable verbose logging, which will display detailed information and not just a summary view, or /Z, to enable extended verbose logging (even more details). Use the /SCOPE MACHINE option with /Z to look at only computer configuration policies; similarly, use /SCOPE USER to look at user configuration policies. You can redirect the output of GPRESULT to a text file using the standard > DOS redirect operator.

The Windows Server 2003 Resource Kit contains WINPOLICIES.EXE, a system tray tool that can show and troubleshoot client-side GPO processing.

6.2.6. Other Administrative Tasks

The GPMC also supports a few more functions, which I'll describe in this section.

6.2.6.1. Searching for GPOs

Using the GPMC, you can search for specific GPOs or for the values of properties of some GPOs. To do so, right-click a forest in the lefthand pane of the GPMC and select Search from the context menu. The Search for Group Policy Objects screen appears, as shown in Figure 6-21.

Figure 6-21. Searching for GPOs

You can select the scope of your search to be all domains within a forest, or within a specific domain that you select from the drop-down list at the top of the screen.

Then you specify your search criteria by selecting the item to search, the condition to match, and the value that the condition should match. The possible search terms are:

  • GPO name "contains," "does not contain," or "is exactly" your value.

  • GPO links "exist in" or "do not exist in" certain sites or all sites.

  • Security group: you simply select one or more security groups using the standard selection dialog.

  • User configuration "contains" or "does not contain" folder redirection, Internet Explorer branding, Registry, scripts, or software installation values.

  • Computer configuration "contains" or "does not contain" EFS recovery, IP security, Microsoft disk quota, QoS packet scheduler, Registry, scripts, software installation, or wireless GP values.

  • GUID "equals" your value.

You can stack criteria to have multiple conditions in your search by selecting the appropriate query and clicking Add to add the current criteria to the query list. Then you can select more criteria and add them to create more complex searches. You can remove selected criteria from the query list by clicking the Remove button.

Click Search to start the search, and Stop Search to stop it before it has finished. The results of the search appear at the bottom of the screen. You can select a particular GPO that results from the search and go directly to editing it by selecting it and clicking the Edit button. You also can save the set of results by clicking the Save Results button, which puts the results in a text file of comma-separated values (CSVs). Finally, to clear the current results and perform a new search, click the Clear button.

6.2.6.2. Backing up, copying, importing, and exporting GPOs

The GPMC also supports copying, importing, backing up, and restoring GPO information. Previously, GPO backups were not possible unless you performed a system state backup of a domain controller. When you back up a GPO using the GPMC, only data pertinent to that particular GPO is backed up. Linked objects are not backed up because restoring that information becomes troublesome. However, when you restore, Windows automatically assigns the previous GUID of the backed-up GPO, which is wonderful for simply resurrecting an inadvertently deleted GPO.

It is not uncommon for administrators to spend a great deal of time configuring GPOs exactly as needed and then to find themselves having to repeat the process manually on several other OUs for which they are responsible. The GPMC can save hours upon hours with its copy capability. You can simply copy a GPO or set of GPOs and then paste them elsewhere into another OU. However, a copy isn't the same as a backup because the copy process doesn't replicate the information in a file that can be moved elsewhere for safekeeping. Also, a copy of a GPO has a different GUID than the original GPO. To perform a GPO copy, you need rights to create GPOs in the destination location and read access to the GPOs in the original location.

The GPMC also supports the ability to import and export GPOs—even to a separate domain with which no trust exists to the original domain. This is useful when you need to copy the same GPO settings to multiple domains or when moving between development and productions forests. You don't need to meticulously re-create all your GPOs on the other domains; simply export them using the GPMC and import them on the new domain. It's a faster and less error-prone procedure.

Importing GPOs across domains can be a bit complex because you'll need to create a migration table to specify how the GPMC should translate domain-specific data from one domain into the other. Most GPOs contain information such as users, groups, computers, and UNC paths that refer to objects available in a specific domain. These might not be applicable in the new domain, so you'll need to tell Windows how to translate these objects stored within the source GPO to other objects applicable to the destination GPO's location. Here's a more specific list of GPO aspects you can modify within the migration process:

  • Security policy settings, including user rights assignments, restricted groups, services, filesystem entries, and Registry keys and values

  • Advanced folder redirection policies

  • The ACL on a GPO itself, which can be preserved or discarded at your discretion

  • The ACL on software installation GPOs (software installation is covered later in this chapter), which relies on your selecting the option immediately preceding this one

Let's walk through several examples for backing up, copying, exporting, and importing GPOs with the GPMC. To back up a specific GPO, follow these steps:

  1. Open the GPMC.

  2. Expand the Forest and Domain trees in the left pane, and then select Group Policy Objects under your domain.

  3. In the right pane, select the GPO you want to back up.

  4. Right-click the GPO and select Back Up.

  5. The Back Up Group Policy Object dialog box appears, as shown in Figure 6-22. Enter the location where you want to store the backed-up GPO files in the first box, and then enter a helpful description for yourself so that you can identify the backed-up files later.

    Figure 6-22. Backing up GPOs

  6. A progress box will appear, indicating how far Windows has progressed in the backup procedure. A message in the Status box will appear noting a successful backup when the procedure is finished.

  7. Click OK to finish.

To copy a specific GPO, follow these steps:

  1. Open the GPMC.

  2. Expand the Forest and Domain trees in the left pane, and then select Group Policy Objects under your domain.

  3. In the right pane, select the GPO you want to copy.

  4. Right-click the GPO and select Copy.

  5. Find the OU within Active Directory to which you want to paste the copied GPO and select it.

  6. Right-click the OU and select Paste from the context menu. A message, shown in Figure 6-23, will appear asking you whether you want to link the GPOs you copied to the destination OU. Click OK to continue.

Figure 6-23. Copying GPOs

Your GPO has been copied.

To import a specific GPO, you need to create a new GPO in the location to which you want to import settings. For example, if you want to import the lockout policy from one domain into a new domain, you'll need to create a new GPO in the new domain. Then, follow these steps:

  1. Open the GPMC.

  2. Expand the Forest and Domain trees in the left pane, and then select Group Policy Objects under the new domain.

  3. In the right pane, select the GPO you want to use.

  4. Right-click the GPO and select Import Settings. The Import Settings Wizard appears.

  5. The wizard will prompt you to back up the settings currently within the destination GPO. Click the Backup button to do so, and follow the procedure earlier in this section to step through that process. When you are done, click Next.

  6. Select the location where the GPO that you want to import is located. Then, click Next.

  7. The Source GPO screen appears. All the GPOs that are stored in the location you input in step 6 are listed on this screen. You can select an individual GPO and click View Settings to refresh your memory as to the settings the GPO contains. Select the GPO you want to use, and then click Next.

  8. The Migrating References screen may appear (if not, skip to step 13). Depending on the settings contained within the GPO, you might need to "map" entries using a migration table. You can select to copy the existing entries directly from the source (using the first bulleted option), or you can create a new migration table by clicking New. This results in the Migration Table Editor window appearing.

  9. From the Tools menu, select "Populate from Backup," and then select the source GPO you are importing. Windows will populate the objects that need to be retranslated automatically.

  10. In the Destination Name column, simply enter the correct name for the source property in its new location. Be sure these properties already exist within the destination location; the GPMC can't create them on the fly. Also, if some properties don't need to be changed, simply enter <Same As Source> in the Destination Name column.

  11. You can save this migration table for use in other GPO import procedures by selecting Save from the File menu and specifying a location. This can be anywhere on your filesystem.

  12. Close the Migration Table Editor. The Migrating References screen will reappear, and the migration table you just created will appear. Click Next to continue.

  13. The "Completing the Import Settings Wizard" screen will appear. Confirm that your settings are correct, and then click Finish. Your settings will be imported.

6.2.6.3. Managing GP across multiple forests

Using the GPMC, you can quite easily browse and set up GPOs in several distinct forests and domains. In fact, even the default setup of the GPMC allows you to select Add Forest from the Action menu and then to type the name of a forest you want to manage. The GPMC will add that to the list of available forests in the left pane.

Managing GP for multiple forests comes with a few requirements:

  • To make everything work out of the box, you need to have a two-way trust between the target forest and the forest containing the machine on which you are running the GPMC.

  • If you have only a one-way trust, choose Options from the View menu, and then on the General Tab uncheck Enable Trust Delegation, a feature that allows permissions for managing GPOs to be assigned to the other forest for reciprocal management.

  • If you don't have a trust, you'll need to use the Stored User Names and Passwords applet in the Control Panel of Windows Server 2003 or the User Accounts applet in Windows XP to keep your login information for the remote forest.

  • Most likely you will need Enterprise Administrator credentials to manage GP in other forests.

6.2.6.4. Delegating administration of GPs

Windows 2000 introduced a feature that allowed you to delegate administrative authority for any number of privileges to certain users; this was an extremely useful and cost-effective way to spread out the workload and increase business unit responsibility for their own IT costs. Windows Server 2008 extends this ability to GPOs, allowing an administrator to extend supervisory privileges (to use old Netware terminology) over some actions with regard to GPOs. Here's how it works.

By default, the creation of GPOs is restricted to members of the Domain Administrators or Enterprise Administrators groups or to those users who belong to the Group Policy Creator Owners group. The key distinction between those security groups is that although those in an administrator group can create and edit any and all GPOs in a directory, the members of the Group Policy Creator Owners group (referred to from now on as the GPCO group) can edit only those policies they created themselves. (If you are familiar with LDAP terminology, this is the managedBy concept.) In addition, members of the GPCO group cannot link GPOs to containers within a directory unless a special permission, known as Manage Policy Links, has been explicitly granted to them.

If you take advantage of delegation in your organization and empower group or department managers to administer IT assets within their own scope of control, you might want to enable them to administer some GPOs for their group. It's likely that these managers aren't members of the Domain Administrators, Enterprise Administrators, or Group Policy Administrators groups, so you'll need to delegate individual privileges—either the ability to create and edit GPOs themselves, or the ability to link GPOs to objects within Active Directory. The two privileges are independent; they are not required in tandem.

To delegate the ability to create and edit GPOs to a user or group, follow these steps:

  1. Open the GPMC.

  2. In the Tree view, select Group Policy Objects.

  3. Navigate to the Delegation tab in the righthand pane.

  4. Add the user or group to whom you want to delegate the privilege.

To delegate the ability to link GPOs to objects, follow these steps:

  1. Open the GPMC.

  2. Select the OU or other object for which you want to give the ability to link GPOs.

  3. Navigate to the Delegation tab in the righthand pane.

  4. Add the user or group to whom you want to delegate the privilege.

If you prefer to do this via scripting, a couple of sample scripts are included with a default GPMC installation, located in the Program Files\Group Policy Management Console\Scripts directory, that can delegate these two abilities. You can delegate GPO creation and ownership with the SetGPOCreationPermissions.wsf script, and you can link with the SetSOMPermissions.wsf script.


local_group_policy.html

6.3. Local Group Policy

Now let's examine the two different types of GP, starting with local GP and moving to domain-based GP. Although local policies don't have the flexibility of domain-based GPs, as you will see, they are still a valuable tool for creating a deployable set of standards for computers in your organization. Local policies are most useful for creating a security configuration for either clients or servers that is appropriate for your company. With the Security Templates snap-in, you can create role-based templates that configure most security-related settings on your machines. And with the Security Configuration and Analysis Tool snap-in (covered in detail in Chapter 7), you can create a database of roles and policies for your organization's machines.

In this section, I'll look at local security policy and using the security templates features to create a consistent security configuration.

6.3.1. Security Templates

Microsoft wisely decided to ship Windows with a few predefined security settings files, hereafter referred to as "security templates." These files contain what are essentially recipes for configuring a machine's security policy based on its daily role. These templates, designed to be applied to new Windows installations that already have had a basic template applied, must be used on systems formatted with NTFS, at least on the boot partition (the one containing the operating system files). The incremental security templates are as follows:

  • For workstations or servers in which users ought to be prevented from being in the Power Users group, apply the compatws.inf template. This template compensates for the lack of additional privileges afforded to members of the Power Users group by relaxing the rights restrictions on the normal Users group. But be careful: you should only use this template if you're dealing with noncertified software (programs that don't have the Windows logo affixed to them) that won't otherwise run.

  • To further secure workstations or servers, the securews.inf template increases the overall security level of a machine by tightening areas of the OS not under the purvey of rights and restrictions. Areas that are more secure using this template include account policy settings, auditing controls, and Registry keys that are prominent in security policy. The appropriate version of this template for Windows domain controllers is securedc.inf.

  • For the ultra-paranoid and for those with the most stringent security requirements, the hisecws.inf (and for domain controllers, the hisecdc.inf file) can be used; however, because all network transmissions must be signed and encrypted by Windows machines, this template is appropriate only in pure Windows 2000 or greater environments.

  • Setup security.inf restores the security settings of a machine to their default, out-of-the-box configuration. Use this if you have made modifications and want to completely reverse them and "wipe the slate clean," as it were.

  • Rootsec.inf specifies the newer, more secure permissions for the root of the system drive. Most significantly, this removes the full control permissions from Everyone on the system drive. You also can use this template to reapply the more stringent root directory security on systems where the baseline security settings have been modified.

  • DC security.inf refers to the default security template for domain controllers, which imposes more stringent requirements on network transmissions and secures more portions of the filesystem and Registry. This template is created when a server is promoted to domain controller status.

  • Iesacls.inf provides a tighter security configuration for Internet Explorer, restricting scripting activity in certain untrusted zones and providing a more stringent, but secure, web browsing atmosphere.

These convenient templates are designed to be used with the Security Templates snap-in. Using the snap-in, you can apply the basic and incremental security templates included with the product, or you can modify the templates to create your own easily distributable templates.

To begin using the Security Templates snap-in, follow this procedure:

  1. Run mmc /s from a command line. This loads the MMC in author mode, allowing you to add a snap-in.

  2. From the Console menu, select Add/Remove Snap-in. Then select Add. This raises a dialog box entitled Add Standalone Snap-in.

  3. From the list, select Security Templates, click Add, and then click Close.

  4. Click OK in the next box to confirm the addition of the snap-in.

Now you have the Security Templates snap-in added to a console. From this snap-in, you can expand the Security Templates section in the console tree on the left, and then expand the C:\Windows\security\templates folder to view the predefined security templates discussed earlier.

6.3.2. Creating a Custom Security Template

You might want to make your own customized policy modifications that go above and beyond those made in the templates shipped with Windows. Creating a custom security template affords you an easy way to package, deploy, and apply these modifications with a minimum of administrative headache. Best of all, you can use these templates in conjunction with a utility called the Security Configuration and Analysis Tool to assess the overall "hardness," or state of security, of your machines.

To create your own security template, follow these steps:

  1. In the Security Templates console, expand Security Templates in the tree pane on the left, and right-click C:\Windows\security\templates (this is the default templates folder in the system).

  2. Select New Template from the context menu that appears.

Now you can make any policy modifications you want in any one of the policy areas supported by the tool: account policies, local policies, the event log, restricted groups, system services, the Registry, and the filesystem. Your additions, deletions, and other changes are saved directly into the template as they are made.

To take this one step further, you might decide to build on the basic policy settings provided by the basic and incremental templates shipped with Windows. In that case, it's quite simple to open the basic or incremental templates, resave to a different name, and make further modifications to create your own custom template. To do so, follow these steps:

  1. Select an existing template inside the Security Templates console. In this example, I'll use the securews.inf file.

  2. Right-click the existing template, and click Save as ... from the context menu.

  3. Give the new template a name.

  4. Click OK. The new template is created with the settings from the old basic template.

6.3.3. Compiling the Security Database

The next step is to compile your templates into a security database using the Security Configuration and Analysis (SCA) tool. From within the MMC, add the SCA tool to the console. Then do the following:

  1. Right-click Security Configuration and Analysis and select Open Database.

  2. From the Open Database dialog, type the name of a new database.

  3. Because no database exists with that name, you'll be prompted for the specific security template from which the database should be built. The choices in this box come from the C:\Windows\Security\Templates folder. Choose the template and click OK.

Although you won't get any confirmation from the user interface, the template has been added to the database. Now you can right-click the SCA tool in the left pane and choose either Analyze Computer Now or Configure Computer Now. When you select Analyze Computer Now, the SCA tool looks at the new security configuration within the database, compares it with the current state of the computer, and reports on the differences; the report also is saved to a logfile in \My Documents\Security\Logs. Alternatively, when you select Configure Computer Now, the changes will actually be committed to your system. You want to avoid using that option unless you're absolutely sure you want the results in production without seeing them first.

You also can script the application of templates across multiple computers, using a login script, Telnet server, or some other means, by taking advantage of the SECEDIT utility. SECEDIT takes a template file, adds it to the SCA database, and then applies the security settings to the machine on which SECEDIT is being run. To import a template named Hassell-secure.inf, compile it into SCA into a database called securepcs and overwrite any data already in the database, apply it to the current computer, and create a log for all of these actions named apply.log, for example, issue the following command:

secedit /configure /cfg Hassell-secure.inf /db securepcs /overwrite
/log apply.log

If you've already imported the template into SCA manually, and you just need to apply the settings to a computer, issue the following command:

secedit /configure /db securepcs /overwrite /log apply.log


domain_group_policy.html

6.4. Domain Group Policy

Domain-based GPs offer a much more flexible and configurable set of standards and settings for your organization than local GPs. In this section, I'll discuss the four most common methods of managing your IT assets centrally using domain GP: configuring a security standard, installing software using the IntelliMirror technology found in Windows Server 2008, redirecting folders present in the user interface to network locations, and writing and launching scripts triggered by events such as logons and logoffs.

6.4.1. Security Settings

As discussed earlier, one of the most useful aspects of GP is its ability to control security settings and configuration from a central location within the organization. Security policy comprises three key components: restricted groups, Registry settings, and filesystem settings. In this section, I'll take a look at each of them.

6.4.1.1. Restricted groups

The restricted groups option allows you to modify the current group configuration and membership on your client computers. When this policy is applied to workstations and servers, their individual group configurations are modified to match that configured inside the policy. The policy contains members and members of lists that overwrite any configuration on the target computers. For example, if you were to add the Administrator group to the policy but not add any users to the members of this group list, and then you applied the policy, Windows would remove any users currently in those groups on the client computers. However, the other facet of the policy, groups of which the added group is currently a member, is only additive: if the list is empty, no modifications are made to the client computers. Only additions are processed and changed.

Only the groups listed inside the Details window of the Restricted Groups policy branch can be modified using the policy, but it's a great way to keep individual users from modifying powerful groups on their own systems.

To modify the restricted groups policy, do the following:

  1. Launch the GPMC, and then right-click on your target GPO in the left pane and select Edit.

  2. Inside the Group Policy Object Editor, navigate through Computer Configuration, Policies, Windows Settings, and Security Settings.

  3. Right-click the Restricted Group branch and select Add Group from the context menu.

  4. Click the Browse button, and select any group currently inside your directory. Click OK.

  5. Now, right-click the newly added group, and select Properties from the context menu.

  6. Add the users that belong to this group to the "Members of this group" list, and add the groups within which this group is nested to the "This group is a member of" list. Use the Add button in both cases. Figure 6-24 shows this screen.

  7. When you're finished, click OK to close out the boxes.

Figure 6-24. The Restricted Groups list screen

6.4.1.2. Filesystem and Registry policy

You also can use GPs to configure permissions on filesystem objects and Registry keys. You can set entries on the ACLs of individual files, folders, and Registry keys from a central location. If you make this change at the domain-wide level—one of the few changes I recommend and endorse at that level—registries are protected against meddling users all over the enterprise, which is definitely a benefit.

To add a Registry key to be protected to a GPO, follow these steps:

  1. Launch the GPMC, and then right-click on your target GPO in the left pane and select Edit.

  2. Inside the Group Policy Object Editor, navigate through the Computer Configuration, Policies, Windows Settings, Security Settings, and Registry. Right-click Registry and select Add Key from the context menu.

  3. You can add one Registry key at a time, and you can selectively apply permissions to each key. Figure 6-25 shows the screen.

Figure 6-25. The Registry Key ACL editor screen

To add a file or folder to be protected to a GPO, follow these steps:

  1. Launch the GPMC, and then right-click on your target GPO in the left pane and select Edit.

  2. Inside the Group Policy Object Editor, navigate through the Computer Configuration, Policies, Windows Settings, Security Settings, and File System. Right-click File System and select Add File from the context menu.

  3. You can explore the entire directory structure, select a file, and then selectively assign permissions to files and folders. Figure 6-26 shows the screen.

Figure 6-26. The File System ACL editor screen

Once you've selected the objects in question, you'll be prompted for their permissions just like I discussed in Chapter 3. After you enter the appropriate permissions, you'll be prompted to configure the properties of inheritance for these new permissions. This is shown in Figure 6-27.

Figure 6-27. Configuring inheritance on protected filesystem or Registry objects

If you select the configure option, you also will need to select how permissions are applied. If you choose to apply inheritable security to this file or folder and to its subfolders, the new permissions are applied to all child objects that do not have a permission or ACL entry explicitly set. This preserves your custom permissions on a tree but also automatically overwrites permissions simply inherited by default. If you choose to replace existing security for this file or folder and its subfolders, you overwrite all permissions on any child folders, including those permissions explicitly set.

If you'd rather not have any of these methods used to apply permissions, simply choose the following option: "Prevent the application of security policies to this file or folder and its subfolders." Doing so will make child files and folders immune to the permissions assigned by this new policy.

6.4.2. IntelliMirror: Software Installation

In my opinion, software installation is one of the coolest and most useful features of GP, and I know many administrators who agree with me. Using Microsoft's IntelliMirror technology introduced in Windows 2000, administrators using GP can distribute software applications initially, using a push or pull method, and then upgrade, redeploy, or remove that software either wholesale or when certain conditions apply. IntelliMirror also offers intelligent application repair features so that when critical files for an application deployed through IntelliMirror are corrupted or deleted, Windows takes over and fixes the problem so that the application will still start and function correctly. This is a big timesaver.

You can distribute and install applications in your organization in two ways. You can assign a software package, which places a shortcut on the user's Start menu and loads the advertisement for the package into the computer's Registry. Or you can publish an application, which simply places the program with the Add/Remove Programs applet in the Control Panel. The user can elect to install the software at his discretion and at a convenient time.

You also can distribute applications via the assign and publish functionality to a computer or a user. If you assign a package to a user, the application is installed on the local system the first time the user runs the software. Incidentally, you can also elect to install such an application when the user logs on, although this can make for long boot times and calls to the help desk. These user-assigned applications follow a user around the network to each computer to ensure that she has all the applications she should on each computer. If you assign a package to a computer, the application is installed on that system when booted up, and the software is installed only on the computer defined in the policy. Applications don't necessarily follow a user around. If you use the publish functionality of IntelliMirror, you can publish to only a specific user because computers can't choose how and where to install software. Published applications also are not quite as robust as assigned applications, and the repair functionality of published applications is limited.

Software installation cannot be accomplished using local policies.

6.4.2.1. Packaging software

The easiest way to publish and assign software is with Microsoft Installer packages, or MSI files. Applications packaged in Installer format include a database of changes to make to files and Registry keys, instructions on removing previous or outdated version of software, and strategies to install on multiple versions of Windows within one file. MSI files also allow intelligent repair functionality for use if installations become corrupted on individual computers, and their rollback function for removing or redeploying an application is useful as well. IntelliMirror and GP-based software distribution are designed to work with applications that install using an MSI package.

But all is not lost if your software isn't offered in MSI format. First, you can use the ZAP file method. You can use a ZAP file when software isn't available with an MSI package to publish (but not assign) the application. A ZAP file is nothing more than a description of an application, its setup program, and any associated file extensions. A sample ZAP file for Adobe's Acrobat Reader 5.0 is shown here:

Line 1: [Application]
Line 2: FriendlyName = Adobe Acrobat Reader 5.0
Line 3: SetupCommand = \\deploy\adobe\rp505enu.exe
Line 4: DisplayVersion = 5.0
Line 5: Publisher = Adobe Corporation
Line 6: URL = http://www.adobe.com
Line 7:
Line 8: [Ext]
Line 9: PDF=

A few notes about this ZAP file: the FriendlyName section shows the application name, which will appear in the Add/Remove Programs applet within the Control Panel on the computers to which the package is published. It also contains the Setup directive, which tells Windows the network path of the file to install the package. The other tags, although offering more information on the version, manufacturer, and Internet address of the manufacturer, are optional. The Ext section lists file extensions to be associated with the program, each followed by an equals sign.

The ZAP file method has a few caveats. First and foremost, because ZAP file installations can only be published, you lose the robustness and intelligent repair features of software applications assigned to computers and users. You also can't set an application deployed via a ZAP file to install automatically on first use, and you can't upgrade or remove an application deployed via a ZAP file using a GPO. In addition, a specific user must have appropriate permissions to run the package's installer executable and to access the source files for the installation. And, the installation probably is not very automated, so the process likely would require user intervention to answer prompts such as the destination directory, installation options, and so forth, which is something we all try to avoid when possible. Finally, because the installer isn't granted sweeping administrative privileges during the setup process like an MSI installer is, you might have conflicts and problems to troubleshoot with a mass package deployment.

If a program you want to deploy uses the InstallShield installation software, you can run setup /r to automatically make a scripted installation file, called setup.iss. Copy the setup.iss file to whatever deployment share you have set up (more on that in a bit), and then modify the ZAP file to contain the following setup command:

setup /r /setup.iss

If the ZAP file method doesn't appeal to you, you can use a repacking tool, such as Veritas WinInstall LE or the InstallShield deployment tools. These tools will take a snapshot of your current system configuration and prompt you to install the software you want to package. Once the installation is complete, these tools will take another snapshot, record what changed on the filesystem and Registry, and prompt you with a list of what it detected. You go through the list, make sure the changes listed were due to installing the software and not to errant behavior on the part of Windows, and then confirm the list. The software will create an MSI with the program's installer and a database of filesystem and Registry changes.

Using this method, you gain the robustness and rollback features of using an MSI installer as opposed to ZAP files. However, the repackaging tools can tend to be a bit flaky, and sometimes you'll have difficulty installing them on multiple platforms. There's not a good way around that, other than obtaining an MSI directly from the software vendor, but it's somewhat of a middle ground between the inflexible ZAP files and a true MSI from the manufacturer.

If you still have a copy of a Windows 2000 distribution CD, you can find a limited version of WinInstall LE on that CD. However, for some reason Microsoft seems to have removed this program from the more recent versions of Windows, so if you don't have the Windows 2000 CD, you are unfortunately out of luck.

6.4.2.2. An example deployment

In this section, I'll step through an actual software deployment using GP, publishing an application for a user:

  1. Copy the MSI file and other necessary files to a network share. This might require an administrative installation, if your software has one available. Consult the documentation and deployment instructions for more on this.

    The network share should have these permissions:

    • Authenticated Users should have Read permissions.

    • Domain Computers should have Read permissions.

    • Administrators should have Read, Change, and Full Control permissions.

  2. Create a new GPO and open it, or edit an existing GPO that you've created for the purposes of distributing this software, using the Group Policy Management Console and Object Editor.

  3. Within the Group Policy Object Editor, navigate through the User Configuration, Policies, and Software Settings nodes in the left pane.

  4. Right-click Software Installation, and select Package from the New menu.

  5. In the Find File window, use the Browse button to find the package you copied to the network share. You can select either an MSI file or a ZAP file in this step; if you select a ZAP file, you need to ensure that its related installer file is located in the same folder as the ZAP file.

    If you are using a ZAP file, make sure the SetupCommand directive in the files points to the network path that contains the setup file and not to the local path. Otherwise, Windows won't translate the path to the file correctly, and if the software isn't present at the same local path on target systems, the installation will fail.

  6. On the Deploy Software screen, select whether to publish the software or assign the software. (Skip the Advanced Publish and Assign option at this point, which allows you to use transform files to modify the installation process for an application. This is covered a bit later in this chapter.) For this example, I'll publish the software.

  7. Click OK, and the software is added to the policy object and is saved to the directory.

Of course, to assign an application to a user, you can simply follow the preceding steps and select Assign instead of Publish in step 6. To assign an application to a computer, use the same process, but use Computer Configuration instead of User Configuration in step 3 and select Assign instead of Publish in step 6.

6.4.2.3. Deployment properties

You'll probably want to fine-tune the settings for deployment, and you can do this through the properties box for the software. Right-click the name of the software package inside the Group Policy Object Editor and then select Properties. The policy properties box contains the following six tabs:

General

On this tab, you can modify the name of the package that will be displayed in Add/Remove Programs. You also can view the version, publisher, language, and platform of the software. Figure 6-28 shows the General tab.

Figure 6-28. The General tab

Deployment

The Deployment tab lets you configure the deployment type and user interaction methods for the software. Under Deployment Type, you can select whether to publish or assign this software. Under Deployment Options, you can choose to "Auto-install this application by file extension activation," which prevents or allows application installation when a user attempts to open a file with an extension associated with the application. You also can elect to "Uninstall this application when it falls out of the scope of management," which dictates whether to remove the application when the user or computer leaves the scope of the current GPO. Additionally, you can choose "Do not display this package in the Add/Remove Programs control panel," which simply hides the application's availability. The application still will be installed when the user opens a file with the associated extension. The "Install this application at logon" option will allow applications assigned to computers to be installed once a user logs in to the computer and not during the computer's boot process, which is the default behavior. Finally, under the Installation user interface options, you can choose whether to eliminate most user intervention by installing the application using default values (with the Basic option) or to prompt the user for installation preferences and instructions (with the Maximum option). Figure 6-29 shows the Deployment tab.

Figure 6-29. The Deployment tab

Upgrades

On this tab you can specify that this new package will upgrade an existing installed package. You can make that mandatory by checking the "Required upgrade for existing packages" checkbox. To add a package to be upgraded, click the Add button and find the package to upgrade within the current object; alternatively, browse through your Active Directory structure by clicking "A specific GPO" and choosing a different GPO and software package. Then you can elect to uninstall the existing package and install the new package, or upgrade over the existing package. Figure 6-30 shows the Upgrades tab.

Figure 6-30. The Upgrades tab

Categories

In this tab you can create categories that will sort and filter the applications available through the Add/Remove Programs applet within the Control Panel. Users can more easily find the published application they want to install if they can click the type of software they need, rather than wading through a list of 100 possible applications. To add categories, simply click the Add button and enter a new category name. Once you've added the category, you can add packages under it. Choose a category from the Available categories pane and click Select to add the current package to it. Do this for each package you want to categorize. Figure 6-31 shows the Categories tab.

Figure 6-31. The Categories tab

Modifications

You can use a transform file (also called an MST file) to customize an MSI application's installation procedure; through the Modifications tab, you can use multiple MST files to ensure that various users, groups, and computers receive customized versions of a software package. To use a transform file for a particular GPO, click Add on this tab and browse on the filesystem for the MST file to apply. There are two caveats: you must have deployed an application using the "Advanced Publish or Assign" method, selected when creating the software installation GPO. Also, once an MST has been applied and the software has been deployed, modifications cannot be added or removed. Figure 6-32 shows the Modifications tab.

Figure 6-32. The Modifications tab

Security

The Security tab, very similar to other ACLs on other objects within Windows Server 2008, allows you to specify permissions on the software installation package portion of the GPO for users, computers, and groups. You can use this tab in conjunction with the security group filtering strategy, discussed earlier in this chapter, to limit the scope of an applied GPO. For example, one policy assigning Office to computers might apply only to sales, but a policy publishing Windows administrative tools might apply only to administrators. If you want to assign applications to computers, you need to add the Domain Computers group here, unless you already have a security group containing the computers you want. Figure 6-33 shows the Security tab.

Figure 6-33. The Security tab

Remember the following security setting guidelines when deploying software via security group filtering:

  • If you want the policy to be applied to all members of a certain security group, then create security groups that contain only the objects that are to be included in the policy application. Then select the GPO you want to administer in the left pane of the Group Policy Management Console. Next, on the Scope tab in the right pane, click the Add button under Security Filtering, and then add the groups that do not need the policy applied. Verify that the group was added to the Security Filtering list.

  • If you do not want the policy to be applied to all members of a certain security group, add all the members to a group, add the group to the ACL for the object by editing the GPO within the GPMC and accessing the ACL from within Group Policy Object Editor, and set the following permissions for the group: Apply Group Policy, deny; Read, deny. All members of the group will not have the policy applied, regardless of their existing memberships to other groups.

  • If group membership (at least in a specific group) shouldn't play a part in the application of this policy, leave permissions alone.

Look back earlier in this chapter to the section "Section 6.2.2" for a refresher on this.

You also can determine the order in which applications will be installed for a given file extension, a useful feature if your organization associates one file extension with multiple software packages. To do so, right-click the Software Installation node within the Group Policy Object Editor (in the lefthand pane) and select Properties. From there, navigate to the File Extensions tab. Select an extension from the drop-down list box, and then adjust the priority, from highest to lowest, of each application in the list box using the Up and Down buttons. If only one application in GP is associated with an extension, this feature will be grayed out because no priority needs to be established.

You can configure other deployment options on this property sheet, using these tabs:

General

Here, you can set the default action when adding new packages to this GPO—whether to assign them, publish them, or display a dialog asking which action to take. You can also set the default user interface options. Plus, you can indicate the path that will serve as the default location for new packages added to this GPO.

Advanced

On this tab, you can indicate that software packages should be uninstalled when they fall out of the scope of management. You also can allow 64-bit Windows client workstations to install 32-bit Windows applications, and extend this capability to applications deployed via a ZAP file.

Categories

The Categories tab was discussed a bit earlier in this section.

6.4.2.4. Redeploying and removing software

If you need to patch an existing software deployment that uses an MSI file, you can take advantage of the redeployment functionality of IntelliMirror. Simply copy the new MSI and associated files over the existing copies on the network share. Then, inside the GPO that contains the deployment configuration for the existing package, right-click the package in the details window inside the Group Policy Object Editor and select Redeploy from the All Tasks menu. Click the Yes button to confirm your choice. The first time the application is started on client computers, regardless of whether the package was assigned or published, the new MSI will be installed.

Along the same lines, if you need to remove installed software, you can right-click the package inside the Group Policy Object Editor and select Remove from the All Tasks menu. You'll be presented with the window shown in Figure 6-34.

Figure 6-34. The Remove Software dialog box

You can choose to either forcibly remove the software immediately, which will uninstall the application no matter what, or simply remove the software from the list of available software, which will allow current installations to continue to use the software, but will prevent new computers from obtaining the software through GP.

6.4.2.5. Deploying service packs using GP

You also can distribute service packs for Windows 2000, XP, Windows Server 2003, and Windows Server 2008 through the IntelliMirror software installation features of GPOs. Doing so can go a long way toward eliminating a tedious and time-consuming administrative task. You can assign the service pack to computers for mandatory deployment, or you can publish the service pack to a user so that he can choose to install it if his situation warrants it.

If you are assigning the service pack to computers, you can simply point a GPO to the UPDATE.MSI file included in the extracted portion of all current service packs from Microsoft. However, if you're publishing the service pack, you'll need to create a ZAP file and then point the software installation GPO to that ZAP file. Again, you can't publish MSI files.

To deploy a service pack using IntelliMirror, follow these steps:

  1. Create a distribution share for the service pack and extract its contents there. This process is described in Chapter 2, or you can consult the readme files within the service pack distribution file for information.

  2. If you are publishing the service pack to users, create a ZAP file pointing to UPDATE.EXE inside the folder containing the extracted service pack files.

  3. Create a new GPO for the service pack. This isn't required—you can assign the service pack as part of default domain policy or any other level of policy—but it's best to keep software installations to their own GPOs so that changes can be reversed easily.

  4. In the Group Policy Object Editor window for that GPO, navigate through Computer Configuration or User Configuration and then choose Policies, Software Installation.

  5. Right-click Software Installation and choose Package from the New menu.

  6. Find the network path to the service pack files and select either UPDATE.MSI if you're assigning to computers, or the UPDATE.ZAP file you created earlier if you're publishing to users.

  7. Choose Assigned or Published in the Deploy Software dialog box.

  8. Click OK.

The policy is set and the service pack will either be assigned or published, depending on your choices. Keep in mind that service packs are typically large files, so you should deploy them after considering the effect that process would have on both your network bandwidth and the time it would take to install locally on the client machines. Additionally, I would avoid automatically deploying service packs on your domain controllers. These machines are sensitive beasts that hold the keys to your Active Directory; manually install service packs on these machines one by one and test them to make sure there are no ill effects.

In environments where you have multiple file servers, it also makes sense to use DFS as a method to store software installation points. Not only do you get fault tolerance through the use of DFS, but you can also change the location of software installation points through DFS without needing to change the configuration of the GPO.

DFS is covered in detail in Chapter 3.

6.4.3. IntelliMirror: Folder Redirection

You can use the folder redirection functionality of GP to change the target location of many folders within a particular user's Windows interface. For example, you can specify custom locations for the Application Data, Desktop, Documents (including the Pictures, Music, and Videos subfolders), Favorites, Contacts, Downloads, Links, Searches, Saved Games, and Start Menu folders. Using folder redirection circumvents the nasty problem of roaming profiles: severe network traffic hikes caused by copying large My Documents and Desktop folders to workstations around the network when users log on. You also can back up the share where the folders are redirected using a normal network backup procedure, automatically protecting the contents.

To access the folder redirection functionality, launch the Group Policy Object Editor for a particular GPO and navigate through User Configuration, Policies, Windows Settings, and Folder Redirection. In the righthand pane, you'll see the folders you can redirect. Right-click each folder to bring up the Properties window. Figure 6-35 shows this screen.

Figure 6-35. The folder redirection interface

On the Target tab, you can choose the type of redirection for this policy. For this example, choose the basic method, which simply redirects all users' folders to the same location. Next, enter the target folder at the bottom of the screen under Root Path, and select the option to create a new folder for each user underneath the root path. Then, move to the Settings tab, and choose the following settings:

Grant the user exclusive rights to My Documents

If this setting is enabled, the user to whom the folder belongs and the local computer have administrative and exclusive rights to the folder, to the exclusion of all other objects. If this setting is disabled, the current permissions on the folder are kept.

Move the contents of My Documents to the new location

If this setting is enabled, everything in the current My Documents folder will be moved to the new, redirected location. If this option is disabled, nothing will be moved and the new My Documents folder will be empty.

Policy removal

You can adjust the Windows default setting, which is to leave the folder in the redirected location if the redirection policy itself is removed. You also can choose to move the folder back to its initial location.

My Pictures preferences

The default action for the My Pictures subfolder is to follow the My Documents folder to wherever it resides.

6.4.3.1. Redirecting folders based on group membership

If you want to redirect some profile folders to different locations based on the different groups to which a user belongs, you can use the Advanced method of redirection inside the redirect policy properties page, on the Target tab. When you select Advanced from the drop-down setting box indicating the type of redirection (shown in Figure 6-36), click the Add button. The Specify Group and Location box will appear.

Figure 6-36. Redirecting folders based on group membership

Enter the name of a security group, and then enter the network path to the folders. Always use a UNC path, even if the folders are local to your machine, so that users taking advantage of roaming profiles will see the correct folders in an absolute path and not wrongly translate a local, relative path. Click OK when you're done, and then repeat the process for as many groups as you need.

If your users are creatures of habit, you can even turn on the Offline Files and Folders feature on the share where you've stored the redirected folders. This way, Windows will continue to display and use a customized environment even when the network is down and the share can't be reached.

6.4.3.2. Removing a redirection policy

It can be a bit difficult to track what happens to redirected folders if you decide to remove a redirection policy. It really depends on the appropriate setting on the Settings tab of the redirected folder's policy properties sheet.

Folder Redirection and Windows Clients

As I pointed out earlier in this chapter, folder redirection policies are not updated in the background, for obvious reasons—for one, how would you feel if suddenly your My Documents folder pointed itself somewhere else? Folder redirection policies are updated asynchronously, according to Microsoft, and only synchronous updates are allowed in the background.

Microsoft introduced a feature in Windows XP called fast logon optimization, which allows the user to see a logon box much faster than with Windows 2000 clients. This is done by using a set of cached credentials and not waiting for a network connection to boot. When a connection is found, GPs are applied in the expected fashion, but this, too, is asynchronous updating—of course, this means folder redirection policies again will not be applied.

Fast logon optimization is designed to cause a normal reboot, without the optimization, if a GPO change is detected when the computer is logged on and connected to the domain within two reboots (for computer settings) or two logoffs (for user settings). However, you can turn off fast logon optimization to make an XP or Vista client mimic a Windows 2000 client by enabling the Computer Configuration\Policies\Administrative Templates\System\Logon\Always wait for the network at computer setting.

If you've elected to redirect the folder back to the local user profile when the policy is removed, and the option to move the contents of the local folder to a new location is enabled, the folder will return to its original location and the contents of the folder will be copied back to the original location but not deleted from the redirected location. If the option to move the contents of the folder to a new location is disabled, the folder will revert to its original location, but the contents of the folder will not be copied or moved to the original location. This means the user is unable to access the contents of the redirected folder from the special folder's UI within the shell, but using a UNC path, she still can access the redirected folder and retrieve its contents manually. If you've selected to leave the folder in the new location when the policy is removed, the folder and its contents will remain at the redirected location, and the user will have access to it, regardless of whether the option to move the contents of the folder to the new location is enabled or disabled.

It also is wise to use DFS in conjunction with folder redirection to make background changes to the location of files transparent to both the user and the GPO itself. DFS is covered in depth in Chapter 3.

6.4.4. Software Restriction Policies

Software Restriction Policies allow you to control the execution of certain programs. It's an excellent feature to use on terminal servers or machines serving as a public kiosk, so users are locked into one specific function and can't mess with administrative tools or Internet applications and utilities.

Windows can identify software to either restrict or allow in several different ways. For one, it can use hash rules, which are made by identifying characteristics of files and executables that come with a program and generating an algorithmic hash from them. Hashes are great for identifying specific versions of programs because the hash value would change when different files are used to compute the hash (which is a near certainty with newer version of a program). Certificate rules can identify software via a digital signature, which is a useful method to secure authorized scripts. Windows also can identify software via its path and the Internet zone (inside Internet Explorer) from which a particular piece of software is downloaded. Finally, Windows can create a rule that catches any software not explicitly identified either in a list or by any other rule. (Control for programs executed within a browser is lacking from the GP standpoint, but improvements to Internet Explorer in Windows XP Service Pack 2 pick up a bit of this slack.) Windows matches programs to rules in the order in which they're listed in the software restriction GPO, and if more than one rule identifies the same program, the rule that catches the program most specifically will trump any other rule.

You might be tempted to create a rule that disallows programs from running by default aside from those explicitly placed in an exception list. This seems like an easy way out, but it really can lobotomize a system unless you take great care to create an exception for every Windows executable a user might need, including his application programs. It can also step on the toes of any user logon scripts that might be necessary to create a secure environment. If you decide to go this route, it's imperative that you extensively test any restriction policies and exception lists in a lab. Also, when you do create the actual software restriction GPO, make sure to add the Domain Administrators group to the GPO's ACL and explicitly deny the Apply Group Policy permission to the GPO—this will enable an administrator to reverse the policy and not lock himself out.

Once you're ready to create the policy, follow this procedure:

  1. Create a new GPO for each restriction policy. This makes it easier to disable a policy that might be overly restrictive.

  2. Choose Computer Configuration or User Configuration to apply the restrictions to machines or users, and then navigate through Policies rightwards double arrow Windows Settings rightwards double arrow Security Settings rightwards double arrow Software Restriction Policies.

  3. Right-click Software Restriction Policies and choose New Software Restriction Policy from the context menu.

  4. Set a default identifier rule: in the left pane, click Security Levels, and then right-click a specific security level and choose Set as Default from the pop-up context menu.

  5. Now, create the actual rules that will catch software on which to enforce a restriction. Right-click Additional Rules in the lefthand pane. Choose New Certificate Rule and select the certificate to require or block, New Hash Rule and the file to allow or block, New Internet Zone Rule and the zone from which to allow or block programs, or New Path Rule and the file or Registry key to allow or restrict.

  6. In the righthand pane, double-click Enforcement. Here, indicate how these restrictions should be enforced. Use of the following options is recommended:

    • "All software files except libraries" will help you avoid blocking critical system and application function files.

    • "All users except local administrators" indicates that Windows should enforce the policy for everyone except those in the local administrator group.

  7. Next, in the righthand pane, double-click Designated File Types. On this sheet, review and add file extensions associated with applications included in the software restriction policies. The list should be fairly complete, but ensure that any scripting languages you use in your organization have their associated file extensions included.

  8. Finally, in the righthand pane, double-click Trusted Publishers. Here you can specify whether normal users, local administrators, or enterprise administrators are allowed to decide what certificates to trust when opening digitally signed programs and controls.

6.4.5. Scripts

Using GP, you can assign scripts to entire domains, organizational units, sites, and groups instead of repeatedly entering the same login script into multiple users' profiles. You can launch four types of scripts using a GPO: logon and logoff scripts, which apply to users, and startup and shutdown scripts, which apply to computers. Startup scripts are executed before logon scripts, and logoff scripts are executed before shutdown scripts.

You can write scripts in any number of languages. Windows Server 2008 is prepared to accept Jscript (.JS) and Visual Basic Scripting Edition (.VBS) files in addition to batch (.BAT), compiled command scripts (.COM), and application executables (.EXE). Scripts to be run through GP are stored on domain controllers in %SystemRoot%\SYSVOL\yourdomain.com\Policies\scripts, with yourdomain.com replaced with your fully qualified domain name.

You can assign startup and shutdown scripts in GP using the following procedure:

  1. In the Group Policy Object Editor, navigate in the lefthand pane through Computer Configuration, Policies, Windows Settings, and Scripts (Startup/Shutdown).

  2. In the righthand pane, click Startup and Shutdown to modify the scripts assigned to each.

You can assign logon and logoff scripts in GP using the following procedure:

  1. In the Group Policy Object Editor, navigate in the lefthand pane through User Configuration, Policies, Windows Settings, and Scripts (Logon/Logoff).

  2. In the righthand pane, click Logon and Logoff to modify the scripts assigned to each.

You can further define properties for these scripts under the Computer Configuration/Policies/Administrative Templates/System/Scripts and User Configuration/Administrative Templates/System/Scripts nodes in the Group Policy Object Editor. For users running scripts, you have the following options (see Figure 6-37):

  • "Run legacy logon scripts hidden" tells Windows not to display the DOS window when using a .COM or .BAT logon or logoff script.

  • "Run logoff scripts visible" indicates whether the actions and results of the logoff script's execution should be displayed to the user.

  • "Run logon scripts synchronously" allows you to specify multiple scripts and have them run at the same time rather than in sequence as the default dictates.

  • "Run logon scripts visible" indicates whether the actions and results of the logon script's execution should be displayed to the user.

Figure 6-37. Logon and logoff script options

For computers running scripts, you can configure the following options (see Figure 6-38):

  • "Allow logon scripts when NetBIOS or WINS is disabled" instructs Windows to either run or ignore logon scripts depending on where you have enabled the old legacy-compatible NetBIOS and WINS naming schemes.

  • "Maximum wait time for Group Policy scripts" sets a cutoff time for the execution of scripts specified in GP before Windows simply cuts them off and continues with the process at hand.

  • "Run logon scripts synchronously" allows you to specify multiple scripts and have them run at the same time, rather than in sequence as the default dictates, on a per-computer rather than a per-user basis.

  • "Run shutdown scripts visible" indicates whether the actions and results of the shutdown script's execution should be displayed to the user.

  • "Run startup scripts asynchronously" allows to you to specify multiple scripts and have them run in sequence, rather than at the same time, as the default dictates.

  • "Run startup scripts visible" indicates whether the actions and results of the startup script's execution should be displayed to the user.

Figure 6-38. Script options


deployment_considerations.html

6.5. Deployment Considerations

You've learned a lot in this chapter about GP and how it works. Along with the exact mechanisms behind GP's magic, there is also an art to properly deploying it. You must account for several issues when using GP. In this section, I'll take a look at some common issues, and I'll offer suggestions about how best to deploy (in general terms) GPs in your organization.

First, you should keep the Default Domain Policy GPO clear of special exceptions. Remember that this policy is meant only for domain-wide, all-computer settings, and is not meant as a launching point for myriad policies of your own. Don't apply different settings to this policy and expect to use the inheritance blocking and security group filtering capabilities to limit the scope of a setting located here. It's a recipe for a troubleshooting nightmare. Instead, create individual GPOs applied to different containers, where your changes, even if blocked by certain properties of the GPOs, aren't as widespread and sweeping.

Also, try to favor creating several smaller GPOs rather than fewer large GPOs. Although the processing time will suffer, it won't suffer much; the benefit is that a GPO's scope is much easier to identify on certain computers when you have smaller GPOs affecting only a few objects.

Construct a naming structure for your GPOs that is clear and descriptive. Hardly anything is worse, especially during GP troubleshooting, than seeing a GPO called "Office" and not knowing whether it defines who receives Microsoft Office through IntelliMirror, who doesn't get Office, or whether the GPO contains security settings for the office worker computers and not for the factory floor. Of course, you want to document this in a safe place, too. Memories tend to fail us at the most inopportune times.

Design your directory structure intelligently. Make separate OUs to contain objects performing similar roles, and make different OUs for different types of users on your network. Separate client workstations from server computers, and differentiate normal users from power users and administrators through a logical, flowing directory. This makes it much easier to deploy GPOs effectively without a lot of inheritance "black magic." By the same token, however, make sure you have room for exceptions to this scheme—some clients might be servers and some servers might be clients, so it's best to have a plan for these oddballs. And along the same lines, try to create a shallow Active Directory structure to eliminate many levels of policies being applied to nested OUs.

Also, when looking at your directory, assess how you can use groups placed in different OUs to further define GPO scope through the security group filtering function. Placing groups in certain OUs can more clearly identify their function and members, and can cut down on processing and application time because policy scope is more refined and less inclusive. At the same time, look at how WMI filtering can be used within the existing group and OU structure, and make modifications to streamline the effectiveness of RSoP and policy application functions.

Oh, and don't forget to document your GPOs and their links. What more needs to be said about that?


troubleshooting_group_policy.html

6.6. Troubleshooting Group Policy

The process of diagnosing what is going on with GP and why it's not doing what you want it to do can be infuriating at times. Use the steps recommended in the following sections to assist you in tracking down where your problem lies.

6.6.1. Resolving DNS Problems

DNS problems can plague your network and make it nearly impossible for GPOs to be applied. This problem manifests itself primarily in the requirements for logging on to a domain; without DNS, you still might be able to authenticate to a domain controller, but GPOs will simply break. That's because they require various types of DNS SRV records to know which computer has which service to manage. This is a good place to start looking if GP simply doesn't function.

6.6.2. Analyzing Inheritance

If you are a seasoned network professional, you'll be familiar with the concept of inheritance. This also can be a stumbling block with GP. Beware of a couple of options. The first is the No Override function, which does nothing more than cease the processing of any GPOs under the object on which the option is set. Conversely, also be wary of the Block Inheritance function, which stops the processing of GPOs that reside higher in the GPO processing hierarchy. This is a case of knowing what you set and properly documenting it, but it still can eat up hours upon hours of troubleshooting time.

6.6.3. GPO Distribution and Synchronization

Another issue you might see is that of GP distribution and synchronization. Distribution and synchronization both rely on a versioning system managed internally by Windows that keeps track of unique revisions of the two parts of a GPO: the GPC, which is associated with a particular organizational structure in Active Directory, and the Group Policy Template, which is a file located in the C:\WINDOWS\SYSVOL\Policies directory on domain controllers. Usually, these are pushed out from the domain controller that is in the PDC emulator role to all the other domain controllers in a given domain, but if the versioning system is wrong or somehow corrupted, this distribution might not finish completely, or it might not occur at all. Windows comes with a couple of tools that will help you fish out the nonstandard GPOs: GPOTOOL, REPLMON, and the GPMC, which I covered earlier. Look at logs on the affected domain controllers and see whether any errors can help you determine the cause. See the next section for more information on the GP logs.

Along the same lines is actually realizing when GPOs are distributed, retrieved, and applied. Earlier in this chapter I pointed out that the interval Windows Server 2008 uses to push out new GPOs is 90 minutes for workstations and regular member servers, and 5 minutes for domain controllers. But this is only for new or revised GPOs. If GP has not changed, nothing is pushed unless you manually push it, either from the command line or through another system-wide GPO that pushes policy regardless of whether a change has occurred. So, remember that GP won't necessarily correct local configuration changes unless the domain GPO changes or you force a refresh.

6.6.4. Getting More Detailed Logs

To troubleshoot GPOs more effectively, you can enable verbose logging, which will give you more data about how GPOs are retrieved and applied to a specific object. This does require a Registry change on the client you're troubleshooting. Inside a Registry editor, navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Select the value UserenvDebugLevel, of type REG_DWORD, and change the value of the key to 0x10002. Restart your system to make sure the change takes effect. Now, any GPO activities will be logged to a file called userenv.log in the %SystemRoot%\Debug\Usermode directory.

You also can enable direct logging to the application event log in much the same way. Inside your favorite Registry editor, navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics. Select the value RunDiagnosticLoggingGroupPolicy, of type DWORD, and change the value on the client you're troubleshooting of the key to 1. Restart to apply your changes, and GPO activities will be logged in the application log.

6.6.5. Identifying Client Side Extension GUIDs

To troubleshoot problems pertaining to folder redirection, software installation, and other client-side difficulties, it can be useful to determine the GUID of the client-side extensions (CSEs) on each computer. The CSEs are simply "categories" for GPOs pertaining to different areas of the user interface. You can view all of these in one place inside the Registry, under HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\WinLogon\GPExtensions.

For reference, some common GUIDs for CSEs are included in Table 6-1. You can use these to match up information that you find in logfiles.

Table 6-1. Common CSE GUIDs
CSE | GUID
Application Management | C6DC5466-785A-11D2-84D0-00C04FB169F7
Folder Redirection | 25537BA6-77A8-11D2-9B6C-0000F8080861
IP Security | E437BC1C-AA7D-11D2-A382-00C04F991E27
Scripts | 42B5FAAE-6536-11D2-AE5A-0000F87571E3
Security | 827D319E-6EAC-11D2-A4EA-00C04F79F83A

6.6.6. Locating GPT Files on Domain Controllers

For various reasons—for example, to diagnose a problem with available GPOs propagating in your domain to administrative workstations—you might want to inspect the directory structure of the GPTs for certain GPOs. First, you need to retrieve the specific GUID for the policy, and then you can find the folder that contains the hard files associated with that policy.

To actually match a specific policy within Active Directory to the specific GPT files on a domain controller inside its SYSVOL share, first you need to locate the GUID on the container in Active Directory where the GPO is applied. Using the GPMC, select the appropriate GPO, and then select the Details tab in the righthand pane. Copy the GUID from there. Then open Explorer and navigate to \\domainname.com\sysvol, which will open the SYSVOL share on the nearest domain controller. Open the Policies directory, and then open the folder whose name matches the GUID of the GPO you selected within the GPMC.

Luckily, you probably will not need to do this very often, as the interface and propagation techniques for GP in Windows Server 2008 are resilient and efficient. But the information is indeed here, just in case.


other_group_policy_management_tools.html

6.7. Other Group Policy Management Tools

It's important to note that there are several paid third-party tools available to help you manage GPOs, their scope and effect, and their application, including the following:

FAZAM

FAZAM tracks changes to GPOs, provides version control for GPOs, allows new or changed GPOs to move into production only after being tested and approved, eliminates the risk of making changes to a live production environment, handles multiple users making simultaneous changes, and enhances GPO administration delegation. However, there are reports that this tool does not work well with Windows 2000 and is fully functional only on Windows Server 2003 and later. FAZAM is available at http://www2.fullarmor.com/solutions/group.

NetIQ Group Policy Administrator

NetIQ Group Policy Administrator handles change and release management to keep better track of GPO modification, creation, and deletion, and enhances change simulation and analysis of hypothetical GPO deployments above and beyond what Windows Server 2008 provides. NetIQ Group Policy Administrator is available at http://www.netiq.com/products/gpa/default.asp.

Quest ActiveRoles

Quest ActiveRoles allows junior-level administrators to securely make changes to important elements of Active Directory, including GP. Quest ActiveRoles is available at http://www.quest.com/fastlane/activeroles/.


command-line_utilities-id2.html

6.8. Command-Line Utilities

Before we close up the chapter, I wanted to talk about the two most popular command-line management tools for GP. Although I've mentioned both of these utilities earlier in this chapter, I wanted to give each of them a thorough treatment in this section for easier reference and use.

6.8.1. GPUpdate

GPUPDATE will refresh Group Policy settings that are stored either on individual machines or through Active Directory. It's fairly straightforward to use.

To refresh the GP settings on the current workstation, just issue the GPUPDATE command itself:

gpupdate

You can target either computer or user settings using the /target switch. If the switch is omitted, both computer and user settings are refreshed. To refresh computer settings on the current machine:

gpupdate /target:computer

You can force the refresh of GP settings with the /force switch:

gpupdate /target:computer /force

Finally, you can force a logoff and/or a reboot with the /logoff and /boot switches, respectively:

gpupdate /logoff
gpupdate /boot

6.8.2. GPResult

GPRESULT will return a listing of all policies applied to a user and computer, the OUs in which the computer and user are located, the site they are in, and a lot more information. The remote computers need to run at least Windows XP or Server 2003 for GPRESULT to return accurate information.

You can return a simple report using the currently logged on user at your workstation by simply issuing the command itself without any switches:

gpresult

The following is a sample of the report you'll receive:

Code View:
Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
Copyright (C) Microsoft Corp. 1981-2001

Created On 5/9/2005 at 12:15:16 PM

RSOP data for R2TEST\Administrator on R2B2SRV1 : Logging Mode
--------------------------------------------------------------

OS Type:                     Microsoft(R) Windows(R) Server 2003, Enterprise Edition
OS Configuration:            Primary Domain Controller
OS Version:                  5.2.3790
Terminal Server Mode:        Remote Administration
Site Name:                   Default-First-Site-Name
Roaming Profile:
Local Profile:               C:\Documents and Settings\Administrator
Connected over a slow link?: No

COMPUTER SETTINGS
------------------
    CN=R2B2SRV1,OU=Domain Controllers,DC=r2test,DC=corp,DC=hasselltech,DC=local
    Last time Group Policy was applied: 5/9/2005 at 12:12:31 PM
    Group Policy was applied from:      r2b2srv1.r2test.corp.hasselltech.local
    Group Policy slow link threshold:   500 kbps
    Domain Name:                        R2TEST
    Domain Type:                        Windows 2000

    Applied Group Policy Objects
    -----------------------------
        Default Domain Controllers Policy
        Default Domain Policy

    The following GPOs were not applied because they were filtered out
    -------------------------------------------------------------------
        Local Group Policy
            Filtering:  Not Applied (Empty)

        Turn off System Restore
            Filtering:  Denied (Security)

    The computer is a part of the following security groups
    -------------------------------------------------------
        BUILTIN\Administrators
        Everyone
        BUILTIN\Pre-Windows 2000 Compatible Access
        BUILTIN\Users
        Windows Authorization Access Group
        NT AUTHORITY\NETWORK
        NT AUTHORITY\Authenticated Users
        This Organization
        R2B2SRV1$
        Domain Controllers
        NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS

USER SETTINGS
--------------
    CN=Administrator,CN=Users,DC=r2test,DC=corp,DC=hasselltech,DC=local
    Last time Group Policy was applied: 5/9/2005 at 12:02:32 PM
    Group Policy was applied from:      r2b2srv1.r2test.corp.hasselltech.local
    Group Policy slow link threshold:   500 kbps
    Domain Name:                        R2TEST
    Domain Type:                        Windows 2000
    Applied Group Policy Objects
    -----------------------------
        Default Domain Policy

    The following GPOs were not applied because they were filtered out
    -------------------------------------------------------------------
        Local Group Policy
            Filtering:  Not Applied (Empty)

        Turn off System Restore
            Filtering:  Disabled (GPO)

    The user is a part of the following security groups
    ---------------------------------------------------
        Domain Users
        Everyone
        BUILTIN\Administrators
        BUILTIN\Users
        BUILTIN\Pre-Windows 2000 Compatible Access
        NT AUTHORITY\INTERACTIVE
        NT AUTHORITY\Authenticated Users
        This Organization
        LOCAL
        Domain Admins
        Group Policy Creator Owners

To get information for the user jhassell on the remote workstation JH-WNXP-LTP using GPRESULT, run:

gpresult /s JH-WNXP-LTP /USER jhassell

Likewise, to get information for the user ljohnson in the domain R2TEST on the remote workstation 192.168.1.120, run:

gpresult /s 192.168.1.120 /USER R2TEST\ljohnson

You also can add the /V option to enable verbose logging, which will display detailed information and not just a summary view, or /Z, to enable extended verbose logging (even more details). Use the /SCOPE MACHINE option with /Z to look at only computer configuration policies; similarly, use /SCOPE USER to look at user configuration policies. You can redirect the output of GPRESULT to a text file using the standard > DOS redirect operator.


the_last_word-id5.html

6.9. The Last Word

GP offers a flexible, compatible, and centralized way to obtain a consistent security and shell configuration across your organization. Through the use of security policies and IntelliMirror technologies, all discussed in this chapter, you can reduce your administrative burden and achieve nirvana.

In the next chapter, I'll take an in-depth look at the most popular security options within Windows Server 2008 and discuss how to make your machines and network more hardened and secure against threats.


windows_security_and_patch_management.html

Chapter 7. Windows Security and Patch Management

Entire books are devoted to Windows security—how to secure Windows clients, servers, headless machines, terminals, web servers, and more. In this chapter, however, I've chosen to highlight some of the useful tools for managing and automating security on Windows Server 2008. I've also included some references to security policy settings that most organizations will find helpful.

In the interest of full disclosure, I must say I have not included an exhaustive reference to every security setting to be found in Windows. So many options are unique to different environments that I've found the best strategy for this particular book is to give a broad overview of security policy management tools, along with some general settings that can increase security greatly, and then let you explore the Windows security features yourself.

7.1. Understanding Security Considerations

Most small- and medium-size businesses have several issues to keep in mind when securing their configurations. Some of these might include the following:

  • The organization comprises multiple servers, and many have distinct and independent roles. It is difficult to be consistent and strict enough with a security policy when multiple machines are performing different functions, each with its own security requirements.

  • Older operating systems and applications are in use. Older programs and systems often use programming and communication techniques that, although secure enough when they were developed, can be exploited easily by today's automated attacks. It can be problematic to ensure that these older platforms are supported correctly and are protected adequately from a constant security threat.

  • In some markets and professions, you must deal with legal procedures, protections, and consequences. For instance, in the medical profession, the Health Insurance Portability and Accountability Act (HIPAA) has presented some challenges regarding data privacy and safekeeping that are making life more "interesting" (in the ancient-Chinese-curse sense of the term) for IT personnel. Such legislation and regulation can alter your security policy in specific situations.

  • There might be a lack of physical security at the site, which makes any computer-based security configurations you plan to make effective. After all, if someone can make off with your domain controller, all bets are off.

  • There might be a lack of security expertise among the technical employees at your company. Constructing and then implementing a security policy is a challenging task that requires patience and knowledge. Lacking these two qualities can make for a painful process. Of course, this chapter will help with the latter.

  • There might be threats—internal, external, or even accidental—that could damage your systems or harm the valuable data contained therein. Take a hurricane, for example. What happens when looters grab the backup tape from the regional bank whose walls have collapsed during the storm? What kinds of bad things might those thieves do with that information?

  • Finally, the most common scenario, there are limited resources—in terms of both money and labor—to implement secure solutions.

Of course, not all of these conditions apply to all businesses, but it's very likely that each is an obstacle that most organizations run into. In this chapter, I'll provide cost-effective ways to address some of these obstacles.

7.1.1. Principles of Server Security

Server security operates off the CIA principle, which is depicted in Figure 7-1.

Figure 7-1. The CIA principle of server security

CIA stands for confidentiality, integrity, and availability. Confidentiality is the concept that information access is protected and restricted to only those who should have access. Integrity is the concept that information is protected from being tampered with or otherwise modified without prior authorization. And availability refers to ensuring that access to the information is available at all times, or at least as often as possible.

Keeping the CIA framework in mind, you can take a number of different security approaches at the server level. One of the most successful methods of preserving confidentiality, integrity, and availability is the layered approach, which both reduces an attacker's chance of success and increases his risk of detection. The layered approach comprises seven layers, each with its own methods and mechanisms for protection:

Data level

The data level guards against malicious activity performed on the actual data. Protection at the data level includes ACLs and encrypting filesystems. Safeguards at this level cover the confidentiality and integrity levels of the CIA triangle.

Application level

Application-level security protects individual programs from attack. Security at this level can include hardening the applications themselves, installing security patches from the vendors, and activating antivirus software and performing regular scans. Safeguards at this level cover the integrity and availability levels of the CIA triangle.

Host level

Protection at the host level secures the computer and its operating system from attack, which nearly eliminates the potential for attack on the data and application levels. Protection at this level includes hardening the operating system itself (which is the primary focus of this chapter), managing security patches, authentication, authorization, and accounting, and host-based intrusion detection systems. Safeguards at this level cover the integrity and availability levels of the CIA triangle.

Internal network level

The organization's network is the next level, which protects against intruders entering at the perimeter and sniffing traffic, looking for keys to accessing levels higher than this one. Protection at this level includes segmenting your network into subnets, using IP Security (IPSec), and installing network intrusion detection systems. Safeguards at this level include all facets of the CIA triangle: confidentiality, integrity, and availability.

Perimeter level

The perimeter is where the internal network connects to other external networks, including those to other branches of the same corporation and connections to the Internet. Perimeter-level protections might include firewalls and quarantining virtual private network (VPN) and dial-up access. Safeguards at this level include all facets of the CIA triangle: confidentiality, integrity, and availability.

Physical security level

The physical security level involves protecting the real estate in which the business practices. Guards, locks, and tracking devices all comprise protection at this level. Safeguards at this level cover the confidentiality and integrity levels of the CIA triangle.

Policies, procedures, and awareness level

This level involves educating users as to best practices and acceptable and unacceptable methods of dealing with information technology. Safeguards at this level can include all facets of the CIA triangle: confidentiality, integrity, and availability.


understanding_security_considerations.html

Chapter 7. Windows Security and Patch Management

Entire books are devoted to Windows security—how to secure Windows clients, servers, headless machines, terminals, web servers, and more. In this chapter, however, I've chosen to highlight some of the useful tools for managing and automating security on Windows Server 2008. I've also included some references to security policy settings that most organizations will find helpful.

In the interest of full disclosure, I must say I have not included an exhaustive reference to every security setting to be found in Windows. So many options are unique to different environments that I've found the best strategy for this particular book is to give a broad overview of security policy management tools, along with some general settings that can increase security greatly, and then let you explore the Windows security features yourself.

7.1. Understanding Security Considerations

Most small- and medium-size businesses have several issues to keep in mind when securing their configurations. Some of these might include the following:

  • The organization comprises multiple servers, and many have distinct and independent roles. It is difficult to be consistent and strict enough with a security policy when multiple machines are performing different functions, each with its own security requirements.

  • Older operating systems and applications are in use. Older programs and systems often use programming and communication techniques that, although secure enough when they were developed, can be exploited easily by today's automated attacks. It can be problematic to ensure that these older platforms are supported correctly and are protected adequately from a constant security threat.

  • In some markets and professions, you must deal with legal procedures, protections, and consequences. For instance, in the medical profession, the Health Insurance Portability and Accountability Act (HIPAA) has presented some challenges regarding data privacy and safekeeping that are making life more "interesting" (in the ancient-Chinese-curse sense of the term) for IT personnel. Such legislation and regulation can alter your security policy in specific situations.

  • There might be a lack of physical security at the site, which makes any computer-based security configurations you plan to make effective. After all, if someone can make off with your domain controller, all bets are off.

  • There might be a lack of security expertise among the technical employees at your company. Constructing and then implementing a security policy is a challenging task that requires patience and knowledge. Lacking these two qualities can make for a painful process. Of course, this chapter will help with the latter.

  • There might be threats—internal, external, or even accidental—that could damage your systems or harm the valuable data contained therein. Take a hurricane, for example. What happens when looters grab the backup tape from the regional bank whose walls have collapsed during the storm? What kinds of bad things might those thieves do with that information?

  • Finally, the most common scenario, there are limited resources—in terms of both money and labor—to implement secure solutions.

Of course, not all of these conditions apply to all businesses, but it's very likely that each is an obstacle that most organizations run into. In this chapter, I'll provide cost-effective ways to address some of these obstacles.

7.1.1. Principles of Server Security

Server security operates off the CIA principle, which is depicted in Figure 7-1.

Figure 7-1. The CIA principle of server security

CIA stands for confidentiality, integrity, and availability. Confidentiality is the concept that information access is protected and restricted to only those who should have access. Integrity is the concept that information is protected from being tampered with or otherwise modified without prior authorization. And availability refers to ensuring that access to the information is available at all times, or at least as often as possible.

Keeping the CIA framework in mind, you can take a number of different security approaches at the server level. One of the most successful methods of preserving confidentiality, integrity, and availability is the layered approach, which both reduces an attacker's chance of success and increases his risk of detection. The layered approach comprises seven layers, each with its own methods and mechanisms for protection:

Data level

The data level guards against malicious activity performed on the actual data. Protection at the data level includes ACLs and encrypting filesystems. Safeguards at this level cover the confidentiality and integrity levels of the CIA triangle.

Application level

Application-level security protects individual programs from attack. Security at this level can include hardening the applications themselves, installing security patches from the vendors, and activating antivirus software and performing regular scans. Safeguards at this level cover the integrity and availability levels of the CIA triangle.

Host level

Protection at the host level secures the computer and its operating system from attack, which nearly eliminates the potential for attack on the data and application levels. Protection at this level includes hardening the operating system itself (which is the primary focus of this chapter), managing security patches, authentication, authorization, and accounting, and host-based intrusion detection systems. Safeguards at this level cover the integrity and availability levels of the CIA triangle.

Internal network level

The organization's network is the next level, which protects against intruders entering at the perimeter and sniffing traffic, looking for keys to accessing levels higher than this one. Protection at this level includes segmenting your network into subnets, using IP Security (IPSec), and installing network intrusion detection systems. Safeguards at this level include all facets of the CIA triangle: confidentiality, integrity, and availability.

Perimeter level

The perimeter is where the internal network connects to other external networks, including those to other branches of the same corporation and connections to the Internet. Perimeter-level protections might include firewalls and quarantining virtual private network (VPN) and dial-up access. Safeguards at this level include all facets of the CIA triangle: confidentiality, integrity, and availability.

Physical security level

The physical security level involves protecting the real estate in which the business practices. Guards, locks, and tracking devices all comprise protection at this level. Safeguards at this level cover the confidentiality and integrity levels of the CIA triangle.

Policies, procedures, and awareness level

This level involves educating users as to best practices and acceptable and unacceptable methods of dealing with information technology. Safeguards at this level can include all facets of the CIA triangle: confidentiality, integrity, and availability.


locking_down_windows.html

7.2. Locking Down Windows

Multiuser systems are security holes in and of themselves. The simplest systems—those used by only one person—are the easiest ones to secure because there's much less diversity and variance of usage on the part of one person than there is on the part of many. Unfortunately, most of our IT environments require multiple user accounts, so the following section focuses on some prudent ways to lock down Windows systems, including Windows Server 2008 machines and associated client workstation operating systems.

7.2.1. Password Policies

Long passwords are more secure, period. As you might suspect, there are more permutations and combinations to try when one is attempting to crack a machine via brute force, and common English words, on which a dictionary attack can be based, are generally shorter than eight characters in length. By the same token, passwords that have not been changed in a long time are also insecure. Although most users grudgingly change their passwords on a regular basis when encouraged by administrators, some accounts—namely the Administrator and Guest accounts—often have the same password for life, which makes them an easy target for attack.

To counter these threats, consider setting some basic requirements for passwords. To set these restrictions on individual workstations and Windows Server 2008 member servers, follow these steps:

  1. Open the MMC and navigate to the Local Security Policy snap-in. You usually access this by selecting Start rightwards double arrow All Programs rightwards double arrow Administrative Tools.

  2. Navigate down the tree, through Security Settings, to Account Policies.

  3. Click Password Policy.

  4. Enable the "Passwords must meet complexity requirements" setting.

  5. Change the "Minimum password length" to a decent length. I recommend eight characters. (I must note here that I prefer passwords longer than 14 characters, but I predict that you will encounter serious user resistance to such a move.)

  6. Change the "Maximum password age" setting to a conservative setting. I recommend 90 days.

You can accomplish the same through GP if you have a Windows domain by selecting an appropriate GPO and loading the Group Policy Object Editor, as explained in Chapter 6. Keep in mind that changes to the domain password policy will affect all machines within the scope of the GP. The configuration tree within the Group Policy Object Editor remains the same.

7.2.1.1. Granular password policies

New to Windows Server 2008 is the ability to define different password policies for different users. No longer do you have to set up distinct domains when you need different password policies to apply to specific users; with Windows Server 2008, you can apply specific password policies to users' accounts in global security groups.

To use this new feature, there are a few prerequisites software-wise. They include:

  • The domain functional level must be Windows Server 2008.

  • You must be a domain administrator to set a password policy. You can delegate this, however.

  • You must fully configure the password settings object, or PSO.

What is a PSO? The password settings object resides in the password settings container, which is unique to any given domain. The PSO has different attributes, which can in turn hold different values, for password and account lockout policies, like complexity and age requirements, maximum unsuccessful logon attempts before logout, and so on. The PSO can be linked to individual user accounts or groups, and these accounts can have multiple PSOs assigned to them.

The process to enable fine-grained password control and to enable access to PSO lacks a lot of finish; unfortunately, you have to go spelunking into the internals of Active Directory in order to enable this support. Before you embark on this procedure, I recommend generating a full backup of your system. Here is the process:

  1. From the Start menu, type adsiedit and then click the resulting link at the top of the window called ADSI Edit.

  2. Right-click on ADSI Edit in the right pane, and from the context menu, select "Connect to."

  3. Click OK in the Connection Settings screen.

  4. In the left pane of ADSI Edit, expand the "Default naming context" past the first node and click on the CN=System node.

  5. In the right pane, right-click on CN=Password Settings Container and from the New menu, choose Object.

  6. On the resulting Create Object screen, select the only class listed (msDS-PasswordSettings) and click Next.

  7. You'll be taken through a number of rather cryptic screens that contain attributes for which you need to provide values. For example, perhaps we want to create a special password policy that applies only to administrators. Table 7-1 shows these attributes, some suggested values that are relevant to our example, and an explanation of exactly what each value is. Continue through each of the steps, entering the values in the white box as requested.

  8. Click Finish on the confirmation dialog.

  9. If you expand the CN=System node in the left pane, and then click on CN=Password Settings Container, you'll now see the PasswordPolicyAdmins policy that we just created. This is your confirmation that the policy has been successfully created.

From this point all we have to do is to assign the new policy to most any combination of users and groups. To do so:

  1. Right-click the PSO from within ADSI Editor and select Properties, and on the resulting screen, click the Filter button.

  2. Select the following options: "Mandatory," "Optional," "Constructed," "Backlinks," and "System-only." Ensure that the "Show only attributes that have values" option is not selected.

  3. In the list on the Attibute Editor tab, navigate to msDS-PSOAppliesTo.

  4. Select msDS-PSOAppliesTo and click the Edit button at the bottom left of the screen.

  5. The "Multi-valued Distinguished Name with Security Principal Editor" window appears. Click the Add DN button and then enter the security group, user, or any combination thereof that should be affected by this new password settings policy. You'll need to use the distinguished name, which is the LDAP version of a container name. You can have as many entries on this screen as you like.

  6. Click OK.

Your new policy is now configured, deployed, and filtered on the appropriate security group (Table 7-1).

Table 7-1. Attributes, values, and descriptions (note minus signs)
Attribute | Value | Description
Cn | PasswordPolicyAdmins | The name of your policy; try to be descriptive.
msDS-PasswordSettings-Precedence | 10 | Like AD replication, this is a "cost" which is used to determine which password would win in the event of a conflict of these password policies (a lower number indicates a higher priority and higher possibility of winning a conflict).
msDS-PasswordReversible-EncryptionEnabled | False | Should passwords be stored with reversible encryption?
msDS-PasswordHistoryLength | 32 | The number of passwords Windows Server 2008 will remember.
msDS-PasswordComplexityEnabled | True | Should users be required to have a password that Windows Server 2008 considers complex?
msDS-MinimumPasswordLength | 16 | Minimum number of characters in a password.
msDS-MinimumPasswordAge | -864000000000 | Minimum age of the password. The value is 1 day.
msDS-MaximumPasswordAge | -36288000000000 | Maximum tolerable age of a single password. The value is 42 days, or 6 weeks.
msDS-LockoutThreshold | 30 | Specifies the number of attempts a user can make with an invalid password before the account will be temporarily disabled.
msDS-LockoutObservationWindow | -18000000000 | Specifies how long the system should wait before resetting the counter that monitors invalid access attempts. (The value is 6 minutes.)
msDS-LockoutDuration | -18000000000 | Specifies how long a user should be locked out if a password is incorrectly entered. (The value is 6 minutes.)

One final note on passwords: encourage your users to use passphrases and not just passwords. This is a great way to enforce a 14-character minimum password length while still making it easy for your users to remember their codes. For example, suggest that they use something such as "My dog is named Molly!" as a password instead of something such as "jsx8q6sv8qtr3r". Tell your users to type their passwords in the password entry box as though they were typing into Microsoft Word or another common word processing program. Windows can accept it, and your users are more likely to remember it.

7.2.2. Account Lockout Policies

Three old-fashioned methods of gaining unauthorized access to a system are to attempt authentication using the following:

  • A well-known username (e.g., administrator)

  • A username not known but derived logically (e.g., admin)

  • A different password for the username on each attempt, repeating as often as possible

Windows can thwart these styles of attack using an account lockout policy, which will disable an account for a specified period after a certain number of unsuccessful logon attempts.

To set the account lockout policy, follow these steps:

  1. Open the MMC and load the Group Policy Object Editor for an appropriate GPO, or navigate to the Local Security Policy snap-in.

  2. Navigate down the tree, through Security Settings, to Account Policies.

  3. Click Account Lockout Policy.

  4. Set the "Account lockout threshold" to a reasonably small number. I recommend three bad login attempts.

  5. Set both the "Account lockout duration" and the "Reset account lockout after" options to 15 minutes. This setting resists attack while not seriously imposing on users who just suffer from "typo syndrome."

As with password policy, you can configure account lockout policy at the local computer or domain level. However, because the password policies are domain dependent, the "local" level is in effect only when the computer is not logged on to the domain.

7.2.3. Local Options

In addition to securing local accounts, the newer Windows platforms give you the ability to lock down certain rights and configurations on the local computer in addition to any domain security policy that might be configured. Several of the available options do little to thwart attacks, so in this section I'll cover the six most effective changes you can make to your local security policy.

You can enable all of the hardening suggestions in this section through the Security Options section of the Local Security Policy snap-in to the MMC. You can usually find this snap-in under Start, All Programs, and Administrative Tools. To get to the appropriate section, navigate the snap-in tree by selecting Computer Configuration, Windows Settings, Security Settings, and Local Policies. Then click Security Options, and the different configuration switches will appear in the righthand pane.

The instructions in this section assume that you have already loaded the snap-in and navigated to the appropriate section.

7.2.3.1. Anonymous access

Windows allows access by an anonymous user to many shares and files using a null user account; this is a security hazard, of course. You still can enable anonymous access to files and directories by explicitly granting rights to the ANONYMOUS USER account in Windows inside the appropriate ACL. This setting merely disables that access by default, so you know exactly where connections are being made.

To fix this hazard, set Additional Restrictions for Anonymous Connections to "No access without explicit anonymous permissions."

7.2.3.2. Shutdown without logon

Windows 2000 and Windows XP Professional machines come in a default configuration that allows you to shut down the system using the Shutdown ... button on the logon screen, so you might be familiar with this feature. However, Windows 2000 Server and Windows Server 2008 machines disable this out of the box. Despite the convenience factor of this feature, it's best to leave rebooting a machine to administrators.

Change "Allow system to shut down without having to log on" to Disabled to secure this.

7.2.3.3. Automatic logoff

Some users log on to the network and then don't log off for months. This is a prominent security hole, as when that user leaves her desk, she still is authenticated to the network with her credentials. Malicious people can use this to do destructive things: delete and transfer files, plant a "root kit" or backdoor program, or change passwords.

You can make automatic logoff work in two ways: first, each valid user needs to have a time when she is not permitted to log on. This can be sometime in the early morning, perhaps 3:00 to 3:30 a.m. Then, a change to the local security policy needs to be made so that when the user's logon time expires, she is not permitted to log on.

To set up a logon time restriction on a domain controller for an Active Directory-enabled domain, follow these steps:

  1. Go to the Active Directory Users and Computers snap-in.

  2. Expand the icon for your domain and click the Users container.

  3. Right-click a user and select Properties.

  4. Click the Account tab, and then click the Logon Hours ... button.

  5. Select the appropriate region of time in the calendar block, and click the radio buttons to the right to either permit or deny logons during that time.

  6. Click OK, and then OK once more to exit the user property sheet.

This option is available only for members of an Active Directory domain.

Now, make the change to the computer's local security policy. Inside the Local Computer Policy snap-in, change "Automatically log off users when logon time expires" to Enabled. If you do not have a domain, instead change "Automatically log off users when logon time expires (local)" to Enabled. This will work even if users have locked their workstations.

7.2.3.4. Digitally signing communication

It's a good idea these days for a computer to authenticate itself to other computers during a communication. Otherwise, a technique called "spoofing" can be used, and a cracker's computer can pose as the remote end of a connection and receive potentially sensitive information. You can prevent this by using digital signatures. However, these are not pervasive; Windows compensates for this limited use by providing two options in the local policy: require it when possible, or require it, period.

I recommend requiring the signatures when possible on both ends of a connection (the RPC protocol refers to the requesting end as the "client" and the responding end as the "server," regardless of the systems' usual roles). Unsigned transmissions should occur only when signatures are not available, supported, or possible.

Be aware that this setting will probably break communications between Windows Server 2008 and Windows Server 2003 machines and older, less secure client operating systems, including Windows 95, Windows 98, and Windows ME. The SCW will set this policy for you and warn you of this.

To require digitally signed communication when possible, change "Digitally sign client communication (when possible)" to Enabled and "Digitally sign server communication (when possible)" to Enabled.

7.2.3.5. Requiring the three-keystroke salute at logon

The logon screen is one of the most trusted aspects of a computer to a normal user. He trusts it enough that he gives his password and username, and then the computer trusts him, too, if all of that is correct and verified. A cracker can take advantage of this mutual trust by writing a program that runs as a system service—in other words, it doesn't need user privileges. The program will mimic the logon box, grab the user's input, and do something with it such as email the password to the cracker, save the credentials to a backdoor program data file, or any number of other nefarious things. However, pressing Ctrl-Alt-Del brings Windows to attention, and you get the authentic Windows logon and not a shell of one that a cracker creates. This easy step makes your system much more secure.

To require this keystroke to begin, change "Disable CTRL+ALT+Delete requirement for logon" to Disabled. (Yes, that's right. Microsoft uses some questionable terminology.)

7.2.3.6. Last username display

By default, Windows displays the username of the last successfully authenticated person to use that particular system on the logon screen. This is giving away needless information, although some of your users are probably accustomed to it.

To disable the last username from being displayed, change the "Do not display last user name in logon screen" setting to Enabled.

7.2.3.7. Password expiration prompt

Earlier in this chapter, I discussed setting password policies to prevent brute force attacks. Of course, changing passwords is a problem for some users who'd rather not be bothered with IS minutiae and simply would like to use their computers to be productive. With this policy setting, you can tell the system to automatically remind a user when his password will expire and prompt him to change it. Setting this value to 14 days gives a user ample opportunity to change his password because that is in excess of most scheduled vacations and business trips.

To enable the password expiration prompt, change the "Prompt user to change password before expiration" setting to 14 days at minimum.

7.2.4. Network Options Via Group Policy

Windows Server 2008 and GP allow you to configure security options that reside inside GPOs that will apply to groups of computers. GP can manage security settings throughout an Active Directory environment in seven areas. They are shown in Table 7-2.

Table 7-2. GP areas and descriptions
Area | Description
Account area | This area applies security configuration to user accounts, including passwords, account lockouts, and Kerberos ticket policies. Password and account lockout policies apply to workstations and servers; Kerberos ticket policies apply only to domain controllers.
Local policies | This area allows you to set auditing and event logging policies, user rights assignments, and Registry keys that directly affect system security. Settings in this area apply to all Windows 2000 or later systems.
Restricted groups | This particularly useful group allows you to define policies regarding a user's membership into security groups that allow elevated privileges. It's simple to define a policy where domain users can never be members of the local Administrators group; other policies are equally easy.
System services | Here, you can set startup options for services and access controls on them.
Registry | In this area, you can configure access permissions on specific keys in the Registry.
Public key policies | Here, you can establish settings for encrypted recovery agents for the Windows EFS, certificate authorities for a specific Windows domain, trusted certificate authorities, and other public cryptography options.
IPSec policies on Active Directory | This area allows you to define IPSec configurations for any given unit in your Active Directory.

7.2.4.1. Viewing the default domain policy

When you install Windows Server 2008, a default domain security policy is created. The default domain security policy is simply a set of configurations that apply certain security settings to all members of the domain: these can include security settings for displaying the username of the last user that logged on to a system, how long a password should be, whether workstations should digitally sign transmissions to and from a server, and so on. It's a simple task to use this default policy as a base and customize settings based on your individual implementation. Let's look at this default policy first, and then work through customizing it.

To view the default domain security policy, follow these steps:

  1. Open the Group Policy Management Console.

  2. Expand the tree in the left pane through your forest, Domains, your domain, Group Policy Objects, and find Default Domain Policy.

  3. Right-click on Default Domain Policy and select Edit.

  4. To view each default domain policy, drill down through Computer Configuration, Policies, Windows Settings, and Security Settings, and click Account Policies.

  5. Look at the right pane. You'll see Password Policy, Account Lockout Policy, and Kerberos Policy. By clicking each, you can view or change its default configuration.

Figure 7-2 shows the default domain policy on a standard, out-of-the-box installation of Windows Server 2008.

Figure 7-2. Default domain policy in Windows Server 2008

7.2.4.2. Viewing the default domain controller security policies

The default domain controller security policy, like the default domain security policy, applies a common configuration to a group of computers, but this time the focus is only on domain controllers. Domain controllers often have special security considerations that ought to be addressed separately, and this default policy does that. Follow these steps:

  1. Open the Group Policy Management Console.

  2. Expand the tree in the left pane through your forest, Domains, your domain, Group Policy Objects, and find Default Domain Controllers Policy.

  3. Right-click on Default Domain Controllers Policy and select Edit.

  4. Drill down through Computer Configuration, Policies, Windows Settings, and Security Settings, and click Account Policies.

  5. Look at the right pane. You'll see Password Policy, Account Lockout Policy, and Kerberos Policy. By clicking each, you can view or change its default configuration.

Figure 7-3 shows the default domain controller security policy on a standard, out-of-the-box installation of Windows Server 2008.

Figure 7-3. Default domain controller security policy in Windows Server 2008

There is a special way in which account policies are distributed to domain controllers that deserves comment. All domain controllers in a specific domain will apply security policies established at the domain level regardless of where the actual computer object for that domain controller resides in Active Directory. This helps to ensure that consistent account policies apply to any domain account. All other policies are applied at the normal hierarchical level, both to domain controllers and to other workstations and servers in the domain. Only domain controllers are affected by this special exception. This is just a tip to remember when you're planning account policy distribution among your organizational units.

7.2.4.3. Viewing a domain controller's effective security policy

To view the effective security policy from a domain controller, complete these steps:

  1. Choose Start, click Run, and type GPEdit.msc. The Group Policy Object Editor will open.

  2. In the left pane, drill down through Computer Configuration rightwards double arrow Windows Settings rightwards double arrow Security Settings, and click Local Policies.

Now you can view the domain controller's effective security policy. When you're finished, close the Group Policy/Local Computer Policy snap-in. (When prompted to save console settings, click No, unless you've done something you want to hold on to.)

At this point, you have all the tools you need to begin pushing automated security configurations to clients running Windows 2000 and later. Note that all settings covered in this book, unless noted at the time each is presented, are fair game for distribution under GP.

7.2.4.4. Final words: organizing policy layout

With power comes complexity, and GP is no exception. Windows administrators have squandered away many hours of their lives on basic GP troubleshooting. Answers to quandaries such as, "Why isn't this policy in effect on this system?" or "I thought I turned off IPSec!" can be difficult to track down if your Active Directory is full of GPOs that are applied inconsistently, redundantly, and inappropriately.

To curtail your security policies and make them easier to locate, disable, change, and apply, try to follow these guidelines.

Organize your policies logically and define boundaries to contain them

Although your Active Directory might be organized by geographic location, your system management needs might revolve around a different paradigm: for instance, you might need IPSec for all company executives' laptops, but they might not all be in your New York office. Or all middle managers in your corporation might require a customized version of Internet Explorer that doesn't lock them out from accessing the Internet, which might be the default configuration for all computers in the domain. The idea is to map out the kinds of restrictions you need, and then define boundaries to which those policies apply. This will make it easier to apply them to the target users and computers even if the geographical and managerial boundaries do not match.

Inside those boundaries, configure policies that represent common values in your organization

Do you usually configure workstations in your finance department to lock a computer after three unsuccessful logon attempts? Does a particular domain in your forest need additional desktop restrictions—should they not be allowed to run the Control Panel, for instance? Change their wallpaper? Install software on their own? These are the kinds of policy sets that likely sound familiar. Group these together and create GPOs for each of these like sets of policy settings.

Configure organizational units inside Active Directory that contain machines grouped according to similar roles or functions within an organization

This gets further into the granularity of your security policies. For example, Windows comes by default with domain controllers residing in a separate organizational unit in Active Directory. You might consider putting desktops, laptops, and servers into their own organizational units, which makes it easier to apply policies, such as requiring use of the EFS, only to laptops.

Now I'll present an understatement: it can require some work to configure GP correctly and effectively. The most difficult parts of the process are planning and laying out the policy settings; Windows takes care of the actual deployment to client computers, which is one of the features that makes GP a compelling management tool. This ease of deployment is a double-edged sword, however: it is equally simple to misconfigure an ACL or change a setting (anybody who has played with the "require signed communications" settings knows this all too well) and wreak utter havoc on your domain. The process also is made more difficult by the lack of an API, so you can't write simple automation programs to help you out. You have to go the long way.

Even more difficult sometimes is getting the big picture. That is to say, it is hard to see how your Active Directory layout and structure—which logically and traditionally have likely mimicked your organization's hierarchical personnel structure—can co-exist with GPOs, which seem to cross hierarchy boundaries and rely on other scopes of application. With careful planning, however, GP can overlay your existing directory structure and complement it with its own management boundaries.

GP configuration, structure, and operation are covered in detail in Chapter 6.


using_auditing_and_the_event_log.html

7.3. Using Auditing and the Event Log

Keeping track of what your system is doing is one of the most important, but tedious, processes of good IT security management. In this section, I'll look at the tools to audit events that happen on your system and the utilities used to view them.

Auditing controls and properties are modified through GPOs in Windows 2000, Windows XP, and Windows Server 2008. Assuming your computer is participating in an Active Directory domain, you can find the domain auditing policy inside the Default Domain Policy, in the Computer Configuration rightwards double arrow Windows Settings rightwards double arrow Security Settings rightwards double arrow Local Policies rightwards double arrow Audit Policies tree. Otherwise, you can view the Local Security Policy through the Administrative Tools applet in the Control Panel.

The settings for each GPO indicate on what type of events and on what type of result a log entry will be written. Here are the options for auditing policies:

Audit account logon events

Writes an entry when domain users authenticate against a domain controller

Audit account management

Indicates when user accounts are added, modified, or deleted

Audit directory service access

Audits when queries and other communications with Active Directory are made

Audit logon events

Writes an entry when local users access a resource on a particular computer

Audit object access

Indicates when certain files, folders, or other system objects are opened, closed, or otherwise "touched"

Audit policy change

Audits when local policies (such as the Local Security Policy) and their associated objects are changed

Audit privilege use

Writes an entry when users make use of privileges assigned to them (such as "Take Ownership")

Audit process tracking

Tracks program activation, when programs close, and other events that programs cause

Audit system events

Audits when a user restarts a computer or when events are written to the security log or otherwise affect system security

You can configure individual objects to be audited by editing the system access control list (SACL) for any given object, which is much like assigning permissions, except it is indicating to Windows on what type of access an event log entry should be writing. You can access the SACL for an object by clicking the Advanced button on the Security tab of the object's properties sheet. On the Auditing tab, after clicking Edit to make the sheet active, you can click Add to include new auditing events for an object, or click View/Edit to modify an existing auditing event. Figure 7-4 shows the SACL for an object.

Figure 7-4. The SACL for an object

Only NTFS files and folders can be audited. FAT partitions do not contain the necessary permission information to support auditing events.

7.3.1. Recommended Items to Audit

You'll want to take particular note of the following items from your event logs:

  • Logon and logoff events are tracked by the "Audit account logon events" setting, which can indicate repeated logon failures and point to a particular user account that is being used for an attack.

  • Account management is tracked by the "Audit account management" setting, which indicates users who have tried to use, or used, their granted user and computer administration power.

  • Startup and shutdown events are tracked by the "Audit system event" setting, which shows that a user has tried to shut down a system as well as what services might not have started up properly upon reboot.

  • Policy changes are tracked by the "Audit policy change" setting, which can indicate users tampering with security settings.

  • Privilege use events are tracked by the "Audit privilege use" setting, which can show attempts to change permissions to certain objects.

You should be aware of a couple of things. First, too much auditing consumes large amounts of resources. Entries will be written every time a user moves a mouse (OK, that's an exaggeration, but not much of one). Second, too much auditing also tends to be overwhelming, and because auditing in general will do nothing for you if you don't view the audit entries ... can you see a loop forming? You don't want to look at audits because there is so much to wade through, so effectively you're wasting resources and gaining no security advantage from it. Be aware.

7.3.2. Event Logs

Similar to auditing policies, the policies for configuring the event logs are found inside the Default Domain Policy, in the Computer Configuration rightwards double arrow Policies rightwards double arrow Windows Settings rightwards double arrow Security Settings rightwards double arrow Event Log tree. Here are the options for event log policies:

Maximum application log size

Sets the maximum size the log is allowed to reach before the oldest events in the log will be purged.

Maximum security log size

Does the same as the previous item but pertains to the security log.

Maximum system log size

Does the same as the previous two items but pertains to the system log.

Prevent local guests group from accessing application log

Disallows access to the application log from users logged on to the Guest account.

Prevent local guests group from accessing security log

Disallows access to the security log from users logged on to the Guest account.

Prevent local guests group from accessing to system log

Disallows access to the system log from users logged on to the Guest account.

Retain application log

Specifies whether to overwrite events or save them when the application logfile reaches the maximum size.

Retain security log

Specifies whether to overwrite events or save them when the security logfile reaches the maximum size.

Retain system log

Specifies whether to overwrite events or save them when the system logfile reaches the maximum size.

Retention method for application log

Specifies whether Windows should overwrite old application log events as it sees fit or only those older than n days; you also can choose to simply not overwrite files and clear the logs manually.

Retention method for security log

Specifies whether Windows should overwrite old security log events as it sees fit or only those older than n days; you also can choose to simply not overwrite files and clear the logs manually.

Retention method for system log

Specifies whether Windows should overwrite old system log events as it sees fit or only those older than n days; you also can choose to simply not overwrite files and clear the logs manually.

To configure the event logs locally on a computer that does not participate in a domain, load the Event Viewer console (which is within the Control Panel and Administrative Tools) and then right-click each log in the left pane. You can set the log size options on this screen, including the maximum size and the actions Windows should take when that limit is reached.

7.3.2.1. The Event Viewer

The Event Viewer allows you to look at events in many different event logs by default. Other applications can add their own logs into the Event Viewer console. Figure 7-5 shows a typical Event Viewer console.

Figure 7-5. An Event Viewer console

This Event Viewer console may look different to you over previous versions, and that's because its layout has been refined and enhanced. You can see a summary on the opening screen of a variety of administrative events that may need your attention; this is a "custom view" built by Microsoft and shipped in the box with the product and usually covers the majority of sources that would generate an error that needs your attention.

You can access all of the event logs available in the left pane. Here's a summary of what is available.

Application Log

Logs messages, warnings, and errors generated by individual applications (programs). You'll find this log in raw format at %SystemRoot%\System32\Winevt\Logs\Application.evtx.

Forwarded Events Log

Logs events sent to the current machine from other servers. You can find this log in raw format at %SystemRoot%\System32\Config\ForwardedEvents.evtx.

Security Log

Logs events generated by the auditing configuration you have set up (see earlier in this chapter for more information on setting up auditing). You'll see this log in raw format at %SystemRoot%\System32\Winevt\Logs\Security.evtx.

Setup Log

Logs events generated by Windows Server 2008 itself during installation and other setup periods; can be found in %SystemRoot%\System32\Winevt\Logs\Setup.evtx.

System Log

Logs events generated by Windows Server 2008 during normal operation. This will normally be full of service information, such as warnings and failures. You will see this log in raw format at %SystemRoot%\System32\Winevt\Logs\System.evtx.

DFS Replication Log

Logs replication activities through the DFS (Distributed File System) functionality; see Chapter 3 for more information on DFS.

Directory Service Log

Logs events encountered by Active Directory Domain Services (AD DS) and its counterparts; see Chapter 5 for more information on AD DS.

DNS Server Log

Logs DNS queries, responses, and other messages and errors encountered by the service. See Chapter 4 for more information on DNS.

File Replication Service Log

Logs messages generated by the old, pre-Windows Server 2008 File Replication Service. In pure Windows Server 2008 environments, you can ignore this log.

Hardware Events Log

Logs errors, information, and warnings generated by drivers for hardware elements on your system.

Microsoft\Windows Logs

This folder and its subfolders relate to individual Windows features and services and are the place to look for errors, warnings, and informational events generated by some Windows features.

To make it easier for you to see the events you're most interested in, you may wish to create a custom view that will filter the event log to events matching certain criteria. To do so, open Event Viewer and then, from the right pane, click the Create Custom View link. The resulting screen, shown in Figure 7-6, allows you to set the criteria by which events will be filtered.

Figure 7-6. Creating a custom view in the Event Viewer

Select the properties of the events you'd like to view, and then click OK. The custom view will be saved and you can always access an updated custom view, fresh with the latest events, from the Custom Views node in the left pane of the Event Viewer console.

To clear events from your Event Viewer console, right-click on the log for which you want to delete events and choose Clear Log from the context menu.


the_last_word-id6.html

7.4. The Last Word

In this chapter, I've taken you through the various considerations of security in a network environment and then shown you how to implement a basic layer of security using tools built in to Windows Server 2008 or that are freely available. Recall that I mentioned in the introductory section of this chapter that I didn't intend to present an exhaustive list of tweaks and settings to adjust to allow Windows Server 2008 to be at its most secure. Rather, I've given you a comprehensive foundation so that you can build on the concepts and procedures you learned in this chapter to create a secure infrastructure around your servers.


internet_information_services_7.html

Chapter 8. Internet Information Services 7

One of the major bundled applications with any version of Windows on the server is Internet Information Services (IIS). And what a long road it's been since IIS 4, in Windows NT Server 4.0. The product has been redesigned with security in mind, made capable of running server-side applications with the help of Microsoft's .NET programming languages, and turned from a boutique-style Internet server into a world-class set of code capable of running the most intense Internet-facing applications.

So, what improvements will IIS 7, included in the upcoming Longhorn Server, bring to the table? Let's take a look at five major enhancements to IIS and what they mean for you.

8.1. Major Improvements

First off, and perhaps most importantly, IIS is completely modular. If you're familiar with the popular Apache web server software, you know that perhaps its biggest strength is that Apache can run on a bare-bones installation. You can configure it to serve just static HTML and nothing else, or you can dynamically load modules that enable different types of content to be processed and served. You can compile a custom Apache installation that does only what you want it to. IIS has never really had the ability to pick and choose from its features and abilities, which had two significant drawbacks: for one, its performance somewhat suffered because the code was busy hosting features and supporting content that you may have never intended to use, and two, security was a problem in that the surface area of the product was made larger by default, even if you had no use for some features. In IIS 7, however, features operate modularly, in that you can load them in any combination and with no dependencies and really create a lean, mean server that does what you want it to do very well, and nothing else. You also gain the benefit of IIS 7's extensibility: it's easier than ever to write a custom module that plugs directly into the IIS core to enable special functionality for your operation.

Additionally, just about every setting and choice in IIS 7 can be configured from a text file. Taking another page from Apache's playbook, each setting in any site configured within IIS can be edited directly from the web.config file. Aside from the obvious convenience, this is a boon for firms that host large amounts of web sites—it's now trivial to deploy an identical configuration across thousands of sites in seconds; you just copy web.config to each site and you are finished. You can also delegate administration of certain sections of web.config to other people, so that a bit of control is available for, say, individual site owners while not necessarily requiring everyone to contact the IIS administrator for any changes to be made. Version control is equally simple—just make several different versions of a text file, store them in some organized fashion, and retrieve when necessary. Very cool.

Also, the management interface for IIS 7 has been completely redesigned and is now more task-oriented. IIS throws away the sometimes confusing, cluttered interface that plagued IIS 4, 5, 6, and 7 and offers a brand-new console look designed to expose more features in a manner sensible to the user while making rapid, large-scale administration across hundreds or thousands of sites quite simple. As with most everything else about IIS 7, the new interface is extensible as well, so you can create custom plug-ins that work directly within the IIS 7 Management Console.

Security has been continually enhanced and improved in IIS 7, even over and above that in IIS 6. Compared to IIS 5, which came with Windows 2000, IIS 6 was light years ahead in the security area. (In fact, for years I called IIS 5 Swiss cheese.) As web applications proliferate and the popularity of .NET-based web sites continues to increase, you'll find IIS taking an even more prominent role in corporate networks, and security is more important than ever given that many of these applications process and store sensitive information. In IIS 7, .NET applications are run directly within the IIS core itself and not sent to the Internet Services Application Programming Interface (ISAPI) extension. Essentially, the .NET runtime environment becomes one as the distinction among ASP, .NET code, and IIS blurs. You also get the benefit of forms authentication for any type of content, so you can authenticate against a database for just about any page or piece of web content, not just .NET code. Additionally, the IUSR_machine account prevalent in previous versions of IIS has been replaced with the built-in IUSR account, which can't be used to log on interactively to the server and also has identical SIDs across all machines using the same version of the operating system. This means that your Deny permissions will work no matter which machine they were originally created on and applied to.

FastCGI support allows you to run applications based on dynamic languages that heretofore have not traditionally been used in the context of Windows-based web serving. This support effectively means you can run PHP, Perl, Ruby, and other applications on IIS—and best of all, you'll get a performance benefit, too, as FastCGI recycles processes for faster service. So, now you can get the advantages of Apache (modularity and security, primarily), with the extensiblity of Windows-based hosting, all without having to rewrite your business applications in an IIS-compatible language. That's a big win for a lot of IT shops.

And finally, you can use the Windows PowerShell administration environment to administer IIS 7. While PowerShell will also support administering Windows Server 2003 machines running IIS 6, IIS 7 was designed to be managed from the command line with PowerShell. Also included is the new APPCMD utility, which runs from the standard command line, and allows you to create and configure sites, settings, and more. APPCMD can be especially useful if you have scripts to programmatically manage your environment.


major_improvements.html

Chapter 8. Internet Information Services 7

One of the major bundled applications with any version of Windows on the server is Internet Information Services (IIS). And what a long road it's been since IIS 4, in Windows NT Server 4.0. The product has been redesigned with security in mind, made capable of running server-side applications with the help of Microsoft's .NET programming languages, and turned from a boutique-style Internet server into a world-class set of code capable of running the most intense Internet-facing applications.

So, what improvements will IIS 7, included in the upcoming Longhorn Server, bring to the table? Let's take a look at five major enhancements to IIS and what they mean for you.

8.1. Major Improvements

First off, and perhaps most importantly, IIS is completely modular. If you're familiar with the popular Apache web server software, you know that perhaps its biggest strength is that Apache can run on a bare-bones installation. You can configure it to serve just static HTML and nothing else, or you can dynamically load modules that enable different types of content to be processed and served. You can compile a custom Apache installation that does only what you want it to. IIS has never really had the ability to pick and choose from its features and abilities, which had two significant drawbacks: for one, its performance somewhat suffered because the code was busy hosting features and supporting content that you may have never intended to use, and two, security was a problem in that the surface area of the product was made larger by default, even if you had no use for some features. In IIS 7, however, features operate modularly, in that you can load them in any combination and with no dependencies and really create a lean, mean server that does what you want it to do very well, and nothing else. You also gain the benefit of IIS 7's extensibility: it's easier than ever to write a custom module that plugs directly into the IIS core to enable special functionality for your operation.

Additionally, just about every setting and choice in IIS 7 can be configured from a text file. Taking another page from Apache's playbook, each setting in any site configured within IIS can be edited directly from the web.config file. Aside from the obvious convenience, this is a boon for firms that host large amounts of web sites—it's now trivial to deploy an identical configuration across thousands of sites in seconds; you just copy web.config to each site and you are finished. You can also delegate administration of certain sections of web.config to other people, so that a bit of control is available for, say, individual site owners while not necessarily requiring everyone to contact the IIS administrator for any changes to be made. Version control is equally simple—just make several different versions of a text file, store them in some organized fashion, and retrieve when necessary. Very cool.

Also, the management interface for IIS 7 has been completely redesigned and is now more task-oriented. IIS throws away the sometimes confusing, cluttered interface that plagued IIS 4, 5, 6, and 7 and offers a brand-new console look designed to expose more features in a manner sensible to the user while making rapid, large-scale administration across hundreds or thousands of sites quite simple. As with most everything else about IIS 7, the new interface is extensible as well, so you can create custom plug-ins that work directly within the IIS 7 Management Console.

Security has been continually enhanced and improved in IIS 7, even over and above that in IIS 6. Compared to IIS 5, which came with Windows 2000, IIS 6 was light years ahead in the security area. (In fact, for years I called IIS 5 Swiss cheese.) As web applications proliferate and the popularity of .NET-based web sites continues to increase, you'll find IIS taking an even more prominent role in corporate networks, and security is more important than ever given that many of these applications process and store sensitive information. In IIS 7, .NET applications are run directly within the IIS core itself and not sent to the Internet Services Application Programming Interface (ISAPI) extension. Essentially, the .NET runtime environment becomes one as the distinction among ASP, .NET code, and IIS blurs. You also get the benefit of forms authentication for any type of content, so you can authenticate against a database for just about any page or piece of web content, not just .NET code. Additionally, the IUSR_machine account prevalent in previous versions of IIS has been replaced with the built-in IUSR account, which can't be used to log on interactively to the server and also has identical SIDs across all machines using the same version of the operating system. This means that your Deny permissions will work no matter which machine they were originally created on and applied to.

FastCGI support allows you to run applications based on dynamic languages that heretofore have not traditionally been used in the context of Windows-based web serving. This support effectively means you can run PHP, Perl, Ruby, and other applications on IIS—and best of all, you'll get a performance benefit, too, as FastCGI recycles processes for faster service. So, now you can get the advantages of Apache (modularity and security, primarily), with the extensiblity of Windows-based hosting, all without having to rewrite your business applications in an IIS-compatible language. That's a big win for a lot of IT shops.

And finally, you can use the Windows PowerShell administration environment to administer IIS 7. While PowerShell will also support administering Windows Server 2003 machines running IIS 6, IIS 7 was designed to be managed from the command line with PowerShell. Also included is the new APPCMD utility, which runs from the standard command line, and allows you to create and configure sites, settings, and more. APPCMD can be especially useful if you have scripts to programmatically manage your environment.


the_new_architecture.html

8.2. The New Architecture

Modularity is the key word and was the ultimate design concept surrounding the complete redevelopment of the request processing pipeline in IIS 7.

There are 40 different modules that make up the feature set of IIS, divided into eight categories. These modules are individually listed here, so you can see how different modules make up the functional stack that is IIS 7.

Common HTTP Web Server Components

  • StaticFileModule

  • DefaultDocumentModule

  • DirectoryListingModule

  • HttpRedirect

  • CustomErrorModule

Windows Process Activation Service

  • ProcessModel

  • NetFxEnvironment

  • ConfigurationAPI

Security

  • BasicAuthModule

  • DigestAuthModule

  • WindowsAuthModule

  • CertificateAuthModule

  • AnonymousAuthModule

  • IPSecurityModule

  • UrlAuthorizationModule

  • RequestFilteringModule

Health and Diagnostics

  • HttpLoggingModule

  • CustomLoggingModule

  • RequestMonitorModule

  • HTTPTracingModule

  • ODBCLogging

  • LoggingLibraries

Performance

  • HTTPStaticCompression

  • HTTPDynamicCompression

Management

  • ManagementConsole

  • ManagementScripting

  • ManagementService

  • Metabase

  • WMICompatibility

  • LegacyScripts

  • LegacySnap-in

Application Development

  • NetFxExtensibility

  • ISAPIModule

  • ISAPIFilterModule

  • CGIModule

  • ServerSideIncludeModule

  • ASP

  • ASP.NET

FTP Publishing

  • FTPServer

  • FTPManagement

8.2.1. New: The Windows Process Activation Service

All installations of IIS 7 require a service new to Windows Server 2008, known as the Windows Process Activation Service, or WPAS. WPAS essentially maintains and administers all worker processes and application pools for IIS on any given machine, listening for new requests and either assigning them to existing processes or starting new work processes and marshalling the request to that process. WPAS also acts as a clearinghouse for configuration information for sites, application pools, and overarching web applications running on the machine.


roles.html

8.3. Roles

As with any other enhanced functionality of Windows Server 2008, web server service is provided through a role. Interestingly, as discussed in the introductory section of this chapter, the modularity of IIS has resulted in a significantly scaled-back initial installation of IIS—in fact, if you choose to install the Web Server role, which is the most basic way to get IIS code on your Windows Server 2008 machine, you receive only the following pieces of the web server software (aside from the Windows Process Activation Service):

  • Common HTTP services, including stubs to host static content, choose a default document for unspecific requests, browsing directories via text, and recording errors

  • Health and diagnostic functionality, including logging and request monitoring

  • Security code, including request filtering functionality (this is the old URLScan utility, which is now baked into the final release of IIS 7)

  • Performance tools, including Gzip-based static content compression technology

  • The IIS Management Console

That's it. You don't get any sort of dynamic hosting functionality with the basic Web Server role; you're limited to hosting text and simple HTML. This is the way systems will be going forward: you install a minimal set of functionalities and layer only what you require in specific scenarios on top of that base installation. This reduces overhead, improves security, and minimizes the potential attack surface of public-facing code.

But not everyone can only host static HTML content. The Application Server role takes IIS to another level and enables dynamic web content to be served from the web service. Since IIS has been scaled down in this release to its bare minimum parts, you have to add the application server role in order to access functionality like ASP.NET, .NET Framework applications, and applications based on dynamic web technologies like CardSpace, Windows Communication Foundation, Windows Presentation Foundation, and Windows Workflow Foundation.

To install the web server role:

  1. Open Server Manager.

  2. Click Roles in the left pane, and then click the Add Roles link in the right pane.

  3. Click Next off the "Before You Begin" page.

  4. On the page listing roles available for installation, select Web Server (IIS). You will then get a pop-up window explaining that you also need the Windows Process Activation Service, as shown in Figure 8-1. Click Add Required Features to continue, and then click Next.

    Figure 8-1. Installing the Windows Process Activation Service with IIS

  5. Read the overview of the role, and then click Next to continue.

  6. On the Select Role Services screen, shown in Figure 8-2, select the modules you would like to install along with the core IIS code. Click Next to continue.

    Figure 8-2. Selecting modules to install along with the core IIS functionality

  7. Confirm the choices you made during the wizard, and then click Install to commence setting up the web server service.

To install the application server role:

  1. Open Server Manager.

  2. Click Roles in the left pane, and then click the Add Roles link in the right pane.

  3. Click Next off the "Before You Begin" page.

  4. On the page listing roles available for installation, select Application Server. You will then get a pop-up window explaining that you also need the .NET Framework 3.0 and a stub supporting that framework for the Windows Process Activation Service, as shown in Figure 8-3. Click Add Required Features to continue, and then click Next.

    Figure 8-3. Setting up the application server role

  5. Read the overview of the role, and then click Next to continue.

  6. On the Select Role Services screen, shown in Figure 8-4, select the modules you would like to install along with the application server functionality. Click Next to continue.

    Figure 8-4. Installing supporting modules for the application server role

  7. Confirm the choices you made during the wizard, and then click Install to commence setting up the web server service.


managing_iis_graphically.html

8.4. Managing IIS Graphically

The graphical management utility for IIS, called Internet Information Services Manager, has been radically redesigned from the tools and consoles available in IIS 6 and Windows Server 2003. Figure 8-5 illustrates the new appearance of this tool. Here's a quick tour of what to notice:

Figure 8-5. An introduction to the redesigned IIS Manager in Windows Server 2008

  • Note the presence of an address bar, like the one in Internet Explorer, when you first open IIS Manager. You can see a breadcrumb-like trail of your progress through the various screens, helping you find where you are and how you arrived there.

  • On the home page, you'll see the feature list occupying the menu pane. This list, which is dynamically generated, shows context-specific features that you may want to configure.

  • Instead of the tab-frenzy feel of IIS 6, you get three types of pages in IIS Manager 7: list pages, where you can generally sort by a variety of fields; the task pane, which automatically changes and presents the most popular and/or likely options for your current context; and a property grid, which lists the attributes associated with any given object or feature in IIS Manager.

For now, let's step through creating a new web site, adjusting its properties, adding a virtual directory for an application, and creating a new application pool.

8.4.1. Creating a Site

Creating a new web site is one of the core responsibilities of an IIS administrator. You can add a new site to a machine with IIS 7 installed in just a couple of clicks. To do so:

  1. Open IIS Manager.

  2. Expand the server list in the left pane.

  3. Right-click on the server and select Add Web Site from the pop-up context menu. This is shown in Figure 8-6.

    Figure 8-6. Creating a new site

  4. Enter a site name and the application pool this site will use.

  5. Enter the path to the content that IIS will serve for this site. This can be either a local path or a network path, named via UNC conventions. If you need to enter credentials to access that path, click the "Connect as" button and enter them there.

  6. Under Binding, select the protocol, IP address, and port number under which IIS should listen for requests to this site. You can also enter a hostname if you want to host multiple sites on one IP address; IIS will look at the host header to determine from which site to service that request.

  7. Click OK to confirm the web site's creation.

8.4.2. Adjusting Site Properties

You'll see that in IIS 7, you adjust site properties through a new property grid view rather than the tab maze that was IIS Manager in Windows Server 2003. The Advanced Settings dialog, which is shown in Figure 8-7, walks you through the attributes assigned to a site, including its application pool, bindings, physical path, connection limits, protocols, and failed request tracking.

Figure 8-7. The Advanced Settings dialog for an IIS web site

You can adjust other properties using those that are listed on the features page. Note that once you select a site in the left pane of IIS Manager, the features list in the middle pane changes. If you switch the grouping option under "Group by:" to "area," you can get a list of features and properties that you can adjust per IIS area—properties specific to ASP.NET, and properties specific to IIS. Table 8-1 lists the IIS-specific properties.

Table 8-1. Features available for modification on an IIS 7 web site
Feature | Description
Authentication | Configures the methods of authentication used on a site. Allows for anonymous, ASP.NET impersonation, basic, digest, forms, and Windows authentication. To use digest authentication, the IIS machine must be a member of a domain.
Authorization Rules | Specifies rules for allowing users to access sites. You can set up allow or deny-based rules, based on a user's identity, role, group, or the verbs used in the original request (POST, GET, etc.).
Compression | Allows you to enable static and dynamic content compression, which can enhance the "perceived performance" of a web site.
Default Document | Specifies the default file that will be served when no specific page is requested by the originator.
Directory Browsing | Configures how directory listings are sent to the requestor's browser, including what fields (time, size, extension, date) are presented.
Error Pages | Sets the path to custom error pages for a site. You can add pages based on the HTTP status code.
Failed Request Tracing Rules | Configures tracing for failed requests. (You must activate failed request tracing, on the main page of IIS Manager in the action pane, before you can adjust the properties herein.) You can elect to trace specific types of content that generate specific failure codes, and assign them to trace providers that can interpret the results.
Handler Mappings | Specifies the DLLs and managed code add-ins that handle specific requests from the Internet.
HTTP Redirect | Configures rules for redirecting requests for a site to another file or URL. Click the checkbox to enable and enter the target path. You can also elect to control the redirect behavior to the entire site or just a directory, and adjust the HTTP status code returned to the requester that corresponds with the redirection.
HTTP Response Headers | Adds headers to responses from the web server. In regular operations, you may not find a lot of use for this capability.
IPv4 Address and Domain Restrictions | Allows you to ban or allow access to content hosted by IIS based on the IP address of the requester. The listings here are in order of priority.
ISAPI Filters | Configures ISAPI filters that process dynamic requests to the web server. This is mainly for backward compatibility with older web applications.
Logging | Tweaks how IIS logs requests on the server. You can select the logfile path, the type of entries written, and how log rollover will be scheduled and executed.
MIME Types | Sets the list of filename extensions and corresponding types of content that are served as static files (in another words, are not interpreted dynamically).
Modules | Allows you to add a managed code-based module that will alter how IIS answers web requests; also lets you configure existing modules and activate them.
Output Caching | Configures caching of output, which can speed up response time when users ask for results of popular dynamically generated queries.
SSL Settings | Allows you to modify SSL requirements for a site or application, including how to handle client certificates.

8.4.3. Virtual Directories

Virtual directories are a great way to make a site's structure easy to navigate for your users, even if the actual content stored in physical disks is located in several different locations or on several different computers. Not only does a well-formed virtual directory structure make a site easy to use for a web surfer, but it increases the flexibility of management for the web developer. It also provides a layer of security through obscurity because the virtual directory need not correspond directly to a physical directory on a hard disk.

To add a new virtual directory to a web site:

  1. Open IIS Manager.

  2. In the left pane, expand the server list, click the appropriate server target, and select the appropriate web site.

  3. Right-click on that site, and select Add Virtual Directory. This is shown in Figure 8-8.

  4. Enter the alias that users will specify to refer to this virtual directory. This is the text that comes after the / in the URL.

  5. Specify the location of the content that will populate this virtual directory, either via a local path or an UNC-style path. If you need to enter credentials to access that location, click the "Connect as" button and enter them there.

  6. Click OK to confirm the creation of the virtual directory.

Figure 8-8. The Add Virtual Directory screen

You can adjust the properties of the virtual directory much like a web site itself, right from the middle pane with all of the features and their icons listed. These are functionally equivalent to the options covered in the previous section pertaining to web sites themselves.

8.4.4. Application Pools

Application pools provide a measure of stability and reliability for high-volume web applications hosted with IIS 7. Although they provide greater predictability in behavior and several other side benefits when it comes to hosting web applications in IIS, each application pool takes up a minimum of about 4 MB of memory on your IIS machine, so it's best to accurately configure your application pools if you're planning to have multiple pools on one machine.

New to IIS 7.0 is the ability to specify to IIS how to process requests that involve managed resources; you can do this via two modes, integrated mode or classic mode. In previous versions of IIS, this was a setting that you could configure only at the server-wide level, but now you can specify classic or integrated mode on a per-application pool basis.

In integrated mode, you are getting the full benefit of the new modular architecture and the reworked request pipeline found in IIS 7. When a worker process in an application pool receives a request, the request goes through a list of events ordered by priority, and each of those events loads the modules needed to deal with the request and form responses to it. Each event calls the necessary native and managed modules to process portions of the request and to generate the response. In this way, you get managed features for all applications and eliminate some of the duplicate processing that classic mode, by design, required.

In classic mode, requests go through the process that was found in IIS 6, wherein requests are natively processed by IIS, and then what's left is passed to an ISAPI DLL for processing, say, managed code or something that the core of IIS 6 wasn't able to natively handle. Then, responses are sent back to IIS to route to the original requestor, making for an added amount of processing time.

Only use classic mode if your web applications don't work in integrated mode.

First, let's take a look at the properties and settings for the "catch-all" application pool configured once you add the Application Server role. Open IIS Manager, expand the server list in the left pane, click your IIS server, and then click Application Pools. You should see "DefaultAppPool" in the main pane of the screen.

One of the main concepts to understand in conjunction with application pools is recycling. Recycling is how IIS 7 ensures responsive processes by killing off old processes when they finish handling their requests and starting new ones to listen. You can configure how often this recycling occurs, whether at a certain cycle of time or at specific times throughout the day, and at what memory usage level (in terms of either total used memory or virtual user memory) a recycling will be triggered. To configure these settings, click Recycling in the action pane, and toggle the settings that present themselves.

If you have a dynamic web application, and you want to segregate its worker processes so that they do not overlap with those residing in the DefaultAppPool, you can create a new application pool. To add a new application pool, follow these steps:

  1. Open IIS Manager.

  2. In the left pane, expand the server list, click the appropriate server target, right-click on Application Pools, and select Add Application Pool. This is shown in Figure 8-9.

    Figure 8-9. Adding a new application pool to an IIS server

  3. Enter a name for the new pool, specify the version of the .NET Framework that this pool should use, select either classic or integrated mode (see earlier in this chapter for a description of how application pool requests are pipelined in each mode), and then click OK.

8.4.5. Enabling Centralized Configuration

Through the centralized configuration feature, you can set up one IIS machine as you want it, export that configuration to a file, and then direct other IIS machines to access that configuration file, making it easy to deploy a uniform configuration across multiple IIS servers. To effect centralized configuration, do the following:

  1. Open IIS Manager.

  2. Select the master server that contains the configuration you want to replicate in the left pane, and then click Shared Configuration in the right pane.

  3. In the task pad, click Export Configuration, and then enter the path to export the configuration files. Also, enter a password that will guard the encryption keys exported during this process as well.

  4. Now, back on the Shared Configuration page, click "Enable shared configuration" and check the box.

  5. Specify the path to the shared configuration file, click Apply, and then enter the password as prompted.

8.4.6. Using the Web Management Service

The web management service allows you to manage IIS remotely, from any computer connected to the Internet. The WMS sets up a secure HTTP/SSL-based connection, allowing you to manage and set configurations in a protected environment. To use the Web Management Service, you must first install the WMS subcomponent through the Add Roles Wizard in Server Manager.

Once you have WMS installed, you need to enable remote connections for management. From within IIS Manager, click the appropriate server in the left pane, open the Management Service feature in the right pane, and check the Enable Remote Management checkbox under Remote Connections, as shown in Figure 8-10.

Figure 8-10. Enabling the remote management service

From this page, you can also configure some optional settings, including which credentials (Windows or IIS Manager) should be accepted to allow access to remote management; what IP address, port, and SSL certificate should be used; where to log requests and connections; and white- and black-lists for IP addresses.

Be sure to take note of the port number assigned on the Management Service screen; you'll use that to actually connect to the web management service.


managing_iis_from_the_command_line.html

8.5. Managing IIS from the Command Line

In this section, we'll take a look at administering IIS 7 outside of IIS Manager. We'll start by examining some common administrative scenarios through the user of AppCmd.exe, and then look at the text-file configuration options that this new version of IIS presents to us.

8.5.1. AppCmd.exe: One-Stop Configuration

IIS 7 includes AppCmd.exe, which is a new, one-stop executable for administering essentially every function IIS provides. Through AppCmd, you can create and configure sites, application pools, and virtual directories; start, stop, and recycle sites and pools; examine current activities in the core of the web server service; and generally find, copy, and import configurations of both IIS itself and the ASP.NET subcomponent.

AppCmd takes a logical syntax: you perform an operation, or command, on a specific piece of IIS, or an object. For example, you can list sites (list being the command and site being the object), add applications, delete worker processes, or set configurations.

You can get a general sense of the scope of functions AppCmd supports by using the /? switch at a command line.

For example, we can list the sites that are stopped on a server by using the following command:

appcmd list sites /state:Stopped

We can add a completely new web site entirely from the command line. Let's add a site named "Booksite" that listens on port 81 and whose content is stored at c:\inetpub\wwwroot\booksite:

Code View:
appcmd add site /name:BookSite /id:2 /bindings:"http/*:81:" /physicalPath:"C:\inetpub\
wwwroot\booksite"

I can change the identifier for my new site to number 99 using the following command:

appcmd set site "BookSite" /id:99

I can delete the site that I just added as follows:

appcmd delete site "Booksite"

To create a backup, which will allow you to fix unwanted changes to server configuration and return to a configuration that, at one point, functioned correctly, it's a simple one-line command:

appcmd add backup 20071015

You can then display a list of available backups using the first command below, and then restore one of them using the second command (the restore command stops the server, adds the configuration from the backup, and then restarts the server):

appcmd list backups
appcmd restore backup "20071015"

If you start piping output of one command and feeding to another command, you can achieve some useful outcomes. For example, to recycle all application pools, you can use:

appcmd list apppool /xml | appcmd recycle apppool /in

You can also recycle application pools serving a specific web site; in this example, let's say "Company Web":

Code View:
appcmd list site "Company Web" /xml | appcmd list app /in /xml | appcmd list
apppool/in /xml | appcmd recycle apppool /in
appcmd list app /site.name:"Company Web" /xml | appcmd list apppool /in /xml | appcmd
recycle apppool /in

We can start all of the sites we stopped in the earlier example in this section with the following command:

appcmd list site /state:stopped /xml | appcmd start site /in

You can do directory or file maintenance on a certain directory safely by determining which sites read from a specific location, like C:\inetpub\wwwroot:

Code View:
appcmd list vdir /physicalPath:C\inetpub\wwwroot /xml | appcmd list app /xml /in |
appcmd list site /in

You can also see what applications are served by worker process 2450:

Code View:
appcmd list wp 2450 /xml | appcmd list apppool /xml /in | appcmd list app /in

And perhaps useful for a quick scan of serving problems, you can retrieve a list of all sites generating 404 errors, indicating that a page cannot be found by IIS:

appcmd list trace /statusCode:404 /xml | appcmd list site /in

8.5.2. XML Configuration

The old IIS metabase now takes on new life and a new format in applicationHost.config, which now forms the central configuration store for an IIS server. It defines all sites, applications, virtual directories, and application pools on a given machine. And, because of the delegated configuration abilities of IIS 7, you can choose from three ways of architecting configurations through text files in IIS 7:

Single configuration file

In this configuration, all settings are written to the applicationHost.config file. This type of configuration is most useful when an administrator wants 100% control over the settings and configuration of an IIS installation. To use this configuration, open IIS Manager, click on the appropriate web server, and navigate to Feature Delegation; then, set all features to Read Only (Figure 8-11). At that point, your changes can be made within the applicationHost.config file and that will be the master resource for your configuration.

Figure 8-11. Setting feature delegation

Delegated configuration

If you choose to delegate some features and configurations to individual sites or applications, you can use the delegated configuration architecture. In this configuration, delegated settings are written to the web.config file between the <system.webserver> entries. You can set up feature delegation from the appropriately named icon under IIS Manager—set the specific feature to Read/Write.

Shared configuration

In the shared configuration format, you can set up IIS on multiple machines and have each of the installations synchronized with the same settings by sharing a unified applicationHost.config file. This is a fantastic way to deploy a large number of web servers with uniform configurations, such as in a web farm scenario.

Let's take a look at a configuration file now. To do so:

  1. From the Start menu, point to All Programs and open the Accessories group.

  2. Right-click on Notepad, and from the pop-up context menu, choose Run As Administrator.

  3. Acknowledge the UAC prompt and continue.

  4. From the File menu, choose Open, change the filtered view to All Files, and then navigate to \Windows\System32\inetsrv\config, and open the file you'd like to view.

The configuration files are simple XML files that are easy to parse visually. Plus, with your text editor, you can use the find function in your software to go straight to a section you want to modify, as well as search and replace to change a configuration globally. Here's a sample from the applicationHost.config file on a plain vanilla Windows Server 2008 machine with the Web Server and Application Server roles installed (Example 8-1).

Example 8-1. A sample XML configuration file

Code View:
-->
    <configSections>
        <sectionGroup name="system.applicationHost">
            <section name="applicationPools" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
            <section name="configHistory" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
            <section name="customMetadata" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
            <section name="listenerAdapters" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
            <section name="log" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
            <section name="sites" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
            <section name="webLimits" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
        </sectionGroup>

        <sectionGroup name="system.webServer">
            <section name="asp" overrideModeDefault="Deny" />
            <section name="caching" overrideModeDefault="Allow" />
            <section name="cgi" overrideModeDefault="Deny" />
            <section name="defaultDocument" overrideModeDefault="Allow" />
            <section name="directoryBrowse" overrideModeDefault="Allow" />
            <section name="fastCgi" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
            <section name="globalModules" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
            <section name="handlers" overrideModeDefault="Deny" />
            <section name="httpCompression" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
            <section name="httpErrors" overrideModeDefault="Deny" />
            <section name="httpLogging" overrideModeDefault="Deny" />
            <section name="httpProtocol" overrideModeDefault="Allow" />
            <section name="httpRedirect" overrideModeDefault="Allow" />
            <section name="httpTracing" overrideModeDefault="Deny" />
            <section name="isapiFilters" allowDefinition="MachineToApplication"
overrideModeDefault="Deny" />
            <section name="modules" allowDefinition="MachineToApplication"
overrideModeDefault="Deny" />
            <section name="odbcLogging" overrideModeDefault="Deny" />
            <sectionGroup name="security">
                <section name="access" overrideModeDefault="Deny" />
                <section name="applicationDependencies" overrideModeDefault="Deny" />
                <sectionGroup name="authentication">
                    <section name="anonymousAuthentication"
overrideModeDefault="Deny" />
                    <section name="basicAuthentication" overrideModeDefault="Deny" />
                    <section name="clientCertificateMappingAuthentication"
overrideModeDefault="Deny" />
                    <section name="digestAuthentication" overrideModeDefault="Deny" />
                    <section name="iisClientCertificateMappingAuthentication"
overrideModeDefault="Deny" />
                    <section name="windowsAuthentication"
overrideModeDefault="Deny" />
                </sectionGroup>
                <section name="authorization" overrideModeDefault="Allow" />
                <section name="ipSecurity" overrideModeDefault="Deny" />
                <section name="isapiCgiRestriction" allowDefinition="AppHostOnly"
overrideModeDefault="Deny" />
                <section name="requestFiltering" overrideModeDefault="Allow" />
            </sectionGroup>
            <section name="serverRuntime" overrideModeDefault="Deny" />
            <section name="serverSideInclude" overrideModeDefault="Deny" />
            <section name="staticContent" overrideModeDefault="Allow" />
            <sectionGroup name="tracing">
                <section name="traceFailedRequests" overrideModeDefault="Allow" />
                <section name="traceProviderDefinitions" overrideModeDefault="Deny" />
            </sectionGroup>
            <section name="urlCompression" overrideModeDefault="Allow" />
            <section name="validation" overrideModeDefault="Allow" />
        </sectionGroup>
    </configSections>


the_last_word-id7.html

8.6. The Last Word

IIS 7 is a complex beast, and in this chapter we walked through its major and some of its more minor features. We looked at the new architecture, installing IIS, managing it graphically via the newly redesigned Internet Information Services Manager console and from the command line, and we examined how you can administer and configure IIS objects from its great XML-based configuration schemes. There's obviously much more to IIS than resides within the scope of this book, but you now have a good idea of what's new and improved in this version, and where the settings and switches reside.

The bottom line: IIS 7 represents a huge leap forward in the stability, performance, overhead use, and extensibility of hosting on the Windows platform. It truly is a next-generation web server product.


windows_server_2008_server_core.html

Chapter 9. Windows Server 2008 Server Core

Server Core? Is that like an apple (or Apple, natch) core? It depends on how you look at it, really: in the context of this book, it's Microsoft's great new addition to the Longhorn Server product. Essentially, Server Core is a slimmed-down, appliance-like version of Longhorn Server that functions in a couple of limited roles and does nothing else.

Server Core, as I see it, has two main advantages: it's extremely focused, which means it does what it does very well, resulting in better performance, resilience, and robustness than a full-fledged operating system. It also has limited dependencies on other pieces of the Windows puzzle, in that the Core is designed to work without a lot of other software installed; it can generally work by itself. In comparison, many of the previous Windows components aren't really necessary—like Windows Explorer or Internet Explorer, for example—which is something that can't be said for Windows Server 2003.

All of this translates into a far smaller attack surface than the standard Windows Server product, given all of the material that's been stripped out. But there are some aspects of Server Core with which you might not yet be familiar, as well as some interesting facts and limitations of the "core"-based approach to computing. We'll take a look at them here.

9.1. The Lack of a Shell

This is probably the most unsettling but, upon reflection, most interesting and welcome difference between Server Core and the traditional Windows server operating system. When you boot Server Core, you'll get a colored screen that looks like a single-color desktop, which might fool you into thinking that you installed the wrong version. But you'll quickly be corrected as you get a command-prompt window; when it appears, all activity stops. It looks a lot like regular Windows if you open Task Manager and kill the explorer.exe process. Figure 9-1 shows this.

Figure 9-1. The default environment when a user logs on interactively to a Server Core-based machine

Indeed, you can open Notepad—just about the only graphical application installed—but you can open it only from the command line, and you can't save as another file; there is no support for displaying those sorts of Explorer windows. In fact, those windows are generated by code called a "shim," which is essentially a programming stub that allows Notepad to display these Explorer-related dialog boxes without tying into Explorer itself.

Essentially, you'll need to think back to your DOS days to get accustomed to administering Server Core. The command line is very, very powerful—in many instances you can accomplish more with commands, options, and switches than you can with the GUI—but it can be intimidating to start.

Here are some other things you don't get with Windows Server 2008 Server Core:

  • No .NET Framework, or even the common language runtime (CLR)

  • No Microsoft Management Console, and no related snap-ins

  • The vast majority of Control Panel applets are not present

  • No Run box, and no Start menu to go with it


the_lack_of_a_shell.html

Chapter 9. Windows Server 2008 Server Core

Server Core? Is that like an apple (or Apple, natch) core? It depends on how you look at it, really: in the context of this book, it's Microsoft's great new addition to the Longhorn Server product. Essentially, Server Core is a slimmed-down, appliance-like version of Longhorn Server that functions in a couple of limited roles and does nothing else.

Server Core, as I see it, has two main advantages: it's extremely focused, which means it does what it does very well, resulting in better performance, resilience, and robustness than a full-fledged operating system. It also has limited dependencies on other pieces of the Windows puzzle, in that the Core is designed to work without a lot of other software installed; it can generally work by itself. In comparison, many of the previous Windows components aren't really necessary—like Windows Explorer or Internet Explorer, for example—which is something that can't be said for Windows Server 2003.

All of this translates into a far smaller attack surface than the standard Windows Server product, given all of the material that's been stripped out. But there are some aspects of Server Core with which you might not yet be familiar, as well as some interesting facts and limitations of the "core"-based approach to computing. We'll take a look at them here.

9.1. The Lack of a Shell

This is probably the most unsettling but, upon reflection, most interesting and welcome difference between Server Core and the traditional Windows server operating system. When you boot Server Core, you'll get a colored screen that looks like a single-color desktop, which might fool you into thinking that you installed the wrong version. But you'll quickly be corrected as you get a command-prompt window; when it appears, all activity stops. It looks a lot like regular Windows if you open Task Manager and kill the explorer.exe process. Figure 9-1 shows this.

Figure 9-1. The default environment when a user logs on interactively to a Server Core-based machine

Indeed, you can open Notepad—just about the only graphical application installed—but you can open it only from the command line, and you can't save as another file; there is no support for displaying those sorts of Explorer windows. In fact, those windows are generated by code called a "shim," which is essentially a programming stub that allows Notepad to display these Explorer-related dialog boxes without tying into Explorer itself.

Essentially, you'll need to think back to your DOS days to get accustomed to administering Server Core. The command line is very, very powerful—in many instances you can accomplish more with commands, options, and switches than you can with the GUI—but it can be intimidating to start.

Here are some other things you don't get with Windows Server 2008 Server Core:

  • No .NET Framework, or even the common language runtime (CLR)

  • No Microsoft Management Console, and no related snap-ins

  • The vast majority of Control Panel applets are not present

  • No Run box, and no Start menu to go with it


realistic_deployment_scenarios.html

9.2. Realistic Deployment Scenarios

At the most fundamental level, Server Core can only be a file server, print server, domain controller, an Active Directory Lightweight Directory Services (LDS) server, streaming media server, DHCP server, DNS server, or Windows Server Virtualization server. It can participate in clusters and network load-balancing groups, run the subsystem for Unix applications, perform backups using Server Core's improved capabilities, and be managed and report status through SNMP. There are a few other ancillary capabilities, but it's pretty stripped down and only appropriate at this point for the four basic roles I just delineated. Future releases might expand the roles in which core-based operating systems can run, but they are not available yet. Table 9-1 lists the roles and features that are included in the Server Core installation of Windows Server 2008.

Table 9-1. Available roles and features on Windows Server 2008 Server Core machines
Roles available in Server Core | Features available in Server Core
Active Directory and Active Directory Lightweight Domain Services (LDS) | BitLocker Drive Encryption
DHCP Server | Failover Clustering
DNS Server | Multipath I/O
File Services (including DFSR and NFS) | Removable Storage Management
Print Services | SNMP Services
Streaming Media Services | Subsystem for Unix-based Applications
Windows Server Virtualization | Telnet Client
Windows Server Backup
WINS Server


no_managed_code.html

9.3. No Managed Code

The code behind the .NET Framework is not modular enough to be broken up into just the components that Server Core will be able to run. (This might be added in future releases and looks to be reasonably high on the priority list.)

Not only does this mean you can't run any custom web applications you might have created, but you also lose access to some of the better management software that comes along with this generation of Windows, including Windows PowerShell (which used to go by the code name Monad). Server Core just isn't a .NET machine at this point, so for web applications and other custom software, you will need to deploy the regular, fully fleshed-out Longhorn Server edition of the operating system.


few_third-party_software_applications.html

9.4. Few Third-Party Software Applications

Mainly, you are going to encounter problems with software that is designed to display widgets in the system tray, like some antivirus and shell modification applications. You may also encounter some problems with management software, although typically these types of applications work in the background and don't display anything graphically. For example, agents from the SMS 2005 and MOM 2005 family of management products should work fine on Server Core boxes, as their operations are largely under the surface and not presented to the user in a graphical fashion.

Lastly, driver installation will be a sore point in a few instances, and you'll need to either use hardware with drivers bundled with the Server Core release or preload the appropriate drivers with the included Drvload utility. You might face driver signing issues as well, though these can be mitigated by actually touching the driver-signing policy on the Server Core machine through Group Policy—but of course, you have to do that remotely.


installation.html

9.5. Installation

Installing the Server Core edition of Windows Server 2008 isn't very different from installing a normal, full installation of Windows Server 2008. There is one key screen—the product selection dialog—wherein you elect to install the core versus the full installation. After that point, there is no difference installation-wise. This key screen is depicted in Figure 9-2.

Figure 9-2. Selecting the Server Core edition of Windows Server 2008 during installation

You will need 512 MB of RAM in your Server Core target machine during the installation process. Server Core itself, once installed, does not require that much memory, but the Setup process does. Disk space isn't as much of a problem: a typical Server Core installation requires only about 20% of the space of a standard Windows Server 2008 installation.

If you are using Windows Deployment Services in your organization, you can deploy Server Core machines through the automated system. Just select the Server Core option in the installation menu. See Chapter 2 for more information on Windows Deployment Services.


initial_configuration.html

9.6. Initial Configuration

Like most servers, you need to tweak some settings and add some information to the Server Core system before you can reasonably deploy it into production. In this section, let's step through some of the initial steps to set up a Windows Server 2008 Server Core box, including:

  • Changing the administrator password

  • Entering date, time, and time zone/location information

  • Setting up network connections

  • Establishing the name of the server and joining it to an existing domain

  • Enabling automatic updates, if necessary, and downloading available updates

  • Activating the server

9.6.1. Setting an Administrator Password

By default, Server Core installs itself with a built-in local administrator account that is enabled with no password, but that requires a password change (effectively establishing a password for the account itself) upon the first logon. This is great for the first logon, but there are two other ways in which you can change the password of an associated account:

  • You can use the venerable command line-based net user utility. For example, net user administrator * will ask you to type a new password for the administrator account.

  • You can hit Ctrl-Alt-Del (the three-keystroke salute) and click the Change Password option that appears. You'll need to enter the old password, the new password, and a confirmation entry. Click the right arrow to perform the change.

9.6.2. Configuring Date, Time, and Location Options

One of the only two Control Panel GUI-based dialog boxes that you can access is the Date and Time applet, which lets you additionally adjust the time zone, set reminders before Daylight Saving Time begins and ends, configure additional clocks (although there is no facility to actually view these additional clocks), and configure the server to synchronize automatically with Internet time servers. You can access this applet from the command line using the following entry, illustrated in Figure 9-3:

Figure 9-3. The Date and Time control panel option in Server Core, accessed from the command line

Control timedate.cpl

Similarly, the Regional and Language Options applet is available from the command line as follows:

Control intl.cpl

It brings up the applet shown in Figure 9-4.

Figure 9-4. The Regional and Language Options control panel screen, again accessed only from the command line

9.6.3. Installing and Applying Hardware Drivers

If you need to add new hardware to your server or update the drivers on your machine, you can do so via the command line. Server Core does include support for Plug and Play, so you won't have to spelunk through text-based configuration files or massage the Registry, but you will need to do the following:

  1. Manually copy the driver files from their original media to a location on the Server Core box.

  2. Run the pnputil command to install the driver.

  3. Reboot if necessary.

The syntax for the plug-and-play utility is:

pnputil -i -a driver.inf

9.6.4. Setting Up Network Connections

Since Windows Server 2008 Server Core has no shell, you'll have to configure your network connections via the command line. There is a robust set of command-line tools that are fairly easy to use. The first to acquaint yourself with is the "netsh interface ipv4" group of commands. Let's first examine what interfaces we have installed by default on our Server Core box. Use the following command to get a list of all configured network interfaces on the Server Core machine:

>netsh interface ipv4 show interfaces

Idx  Met  MTU         State        Name
---  ---  -----       -----------  -------------------
1    50   4294967295  connected    Loopback Pseudo-Interface 1
10   10   1500        connected    Local Area Connection

As you can see from the resulting output of the command, there are two network interfaces on this machine. The one most relevant to our scenario—named, as you might expect, Local Area Connection—has an "idx," or index number, of 10. This numerical value is important to the following commands, as it identifies which LAN adapter we're targeting in each command.

Now, let's set a static IP address of 192.168.0.99 to this machine, with the regular 255.255.255.0 network mask, and a gateway of 192.168.0.1. We can use the "set address" feature of the netsh command to get this assignment completed. Type in the following:

Code View:
Netsh interface ipv4 set address name="10" source=static address=192.168.0.99
mask=255.255.255.0 gateway=192.168.0.1

Now, let's also add a couple of DNS servers to the mix. Let's assign 24.25.5.150 as the first server (we'll assign the priority via the "index" switch, which is different than the "name" or "Idx" switches and attributes we've already seen), and 24.25.5.149 as the second DNS server.

Netsh interface ipv4 add dnsserver name="10" address=24.25.5.150 index=1
Netsh interface ipv4 add dnsserver name="10" address=24.25.5.149 index=2

If you didn't receive any errors back from those commands, then the reconfiguration completed successfully. You can check your results in a more convenient format by using the ipconfig /all command. Here is some sample output, the results of our configuration evidenced in all the right places:

Code View:
Windows IP Configuration

   Host Name . . . . . . . . . . . . : WIN-1UUMA7JYIC8
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
   Physical Address. . . . . . . . . : 00-0C-29-EA-A7-3D
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::2132:e6ca:f75a:2545%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.0.99(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.0.1
   DNS Servers . . . . . . . . . . . : 24.25.5.150
                                       24.25.5.149
   NetBIOS over Tcpip. . . . . . . . : Enabled
Tunnel adapter Local Area Connection* 8:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Local Area Connection* 9:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physical Address. . . . . . . . . : 02-00-54-55-4E-01
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:0:4136:e390:3020:8d1:3f57:ff9c(Preferred)
   Link-local IPv6 Address . . . . . : fe80::3020:8d1:3f57:ff9c%12(Preferred)
   Default Gateway . . . . . . . . . : ::
   NetBIOS over Tcpip. . . . . . . . : Disabled

9.6.5. Naming the Server and Joining a Domain

Upon installation, Windows Server 2008 Server Core assigns a random string to be the computer's name. While this is great at avoiding computer name conflicts on the network when you first bring up a new server, it's hardly a great name to keep as a permanent reference.

You can determine the current name of a Server Core machine using the following command:

>hostname
WIN-1UUMA7JYIC8

To rename that random string into something meaningful—say, WS08-CORE-1, use the netdom command and its associated switches as follows:

Code View:
>netdom renamecomputer WIN-1UUMA7JYIC8 /NewName:WS08-CORE-1
This operation will rename the computer WIN-1UUMA7JYIC8
to WS08-CORE-1.

Certain services, such as the Certificate Authority, rely on a fixed machine
name. If any services of this type are running on WIN-1UUMA7JYIC8,
then a computer name change would have an adverse impact.

Do you want to proceed (Y or N)?y
The computer needs to be restarted in order to complete the operation.

The command completed successfully.

Notice the computer needed to be restarted after the name change, which you may expect. After the server restarts, you may want to join the server to a domain. For instance, to join our newly named WS08-CORE-1 machine to the HASSELLTECH domain, use the command below. Make sure you add the extra ds as pictured to the userd and passwordd switches, as they indicate that you are providing the credentials with the permissions sufficient to add a machine to the given domain:

Code View:
>netdom join WS08-CORE-1 /domain:HASSELLTECH /userd:Administrator /passwordd:*
Type the password associated with the domain user:
The computer needs to be restarted in order to complete the operation.

The command completed successfully.

9.6.6. Enabling Automatic Updates

You can configure how automatic updates are handled by Windows Server 2008 Server Core through a special script called scregedit.wsf, which is unique to this edition of the operating system—it can't be found on a regular installation of Windows Server 2008. Using the scregedit.wsf script gives you the ability to massage a lot of settings, including how automatic Windows updates are handled, the settings for Windows Error Reporting, allowing Terminal Services Remote Administration connections and from what version of the RDP client such connections should be accepted, whether the IP Security (IPSEC) Monitor should be able to remotely management IPSEC, and various settings regarding the priority and weight of DNS SRV records (see Chapter 4 for more on SRV records).

Our focus in this section is on patching. To contact the system and determine the current Automatic Updates configuration, use the following command:

cscript scregedit.wsf /au /v

You can enable Automatic Updates, which in the context of Server Core means that Windows will download and install updates automatically (there is no facility by which you could be presented with a list of updates and approve them one by one), by using the following command:

cscript scregedit.wsf /au 4

And finally, to check for updates, use this command:

wuauclt /detectnow

9.6.7. Activating the Server

Another script you'll use to configure the server is the slmgr.vbs script, which—unlike scregedit.vbs—can be found on Windows Vista and Windows Server 2008 full installations. The slmgr script takes care of all licensing and activation tasks an administrator needs to complete on a Windows machine. There are four relevant options for a Server Core machine that you'll likely need to know. I present them here, in the order in which you would execute them to display and ultimately activate a license of Windows Server 2008 Server Core.

First, this installs a product key, in case you didn't enter a key during product setup:

cscript slmgr.vbs -ipk

This checks the status and expiration date of the current license on which the machine is activating, including the grace period before activation:

cscript slmgr.vbs -xpr

The next one performs the activation process:

cscript slmgr.vbs -ato

And finally, this resets the activation grace period. There is a limit on the number of times the re-arm procedure can be used. It is currently three times:

cscript slmgr.vbs -rearm

9.6.8. Enabling Remote Desktop Services

The final step to getting a machine configured initially is—if you so desire—to set up Remote Desktop connections, so you can at least perform command-line administration from the comfort of your office and not necessarily sitting with the machine in the datacenter. Again, we go back to the scregedit.wsf script to perform this function.

To enable Remote Desktop, issue this command:

cscript scregedit.wsf /ar 0

You might also want to let older RDP clients, without the newest security and authentication technologies, connect to your Server Core machine. In that case, toggle the security settings by entering the following at the command line:

cscript scregedit.wsf /cs 0

Once you are in a Terminal Services session, you might want to know how to log off a session, given there is no Start menu. Fortunately, there is a one-word command to end your session, versus simply clicking the close button in the RDP client, which only disconnects your graphical session (and doesn't end anything you have running):

logoff


administering_windows_server_2008_serve.html

9.7. Administering Windows Server 2008 Server Core Machines

Now that your machine has been more or less configured and is ready to be deployed, it's time to discuss how you go about preparing the server for installation in different scenarios. As you know from earlier in this book, Windows Server 2008 offers groups of services, and the associated software, wrapped in "roles" that correspond to the likely environments in which you will deploy a machine. On a full installation of Windows Server 2008, these roles are installed using the Server Manager MMC console. On a Server Core machine, that is obviously not possible, as the graphical shell largely doesn't exist.

There is a command-line utility called oclist that allows you to view available roles to install on a machine with Windows Server 2008 Server Core. Once you have run oclist and identified any given role name, you can use that name in conjunction with the ocsetup utility to install or uninstall that server role or optional feature.

Some sample output from oclist is shown in Figure 9-5.

Figure 9-5. The output of the oclist.exe command, shown from a Server Core session

Note that the DHCPServerCore role is listed as not installed. Let's say that we wanted our Server Core machine deployed as a headless, GUI-less, stripped-down DHCP server for our enterprise. To prepare the machine, we need to install the DHCP Server role. Using the name we obtained from the oclist command output, we can start the role installation process with the ocsetup command, as follows:

ocsetup DHCPServerCore

The system will trundle for a while, and the process should complete without errors. To verify that the role installation process is complete, run oclist again and then check to see whether the DHCPServerCore role is listed as "installed."

To uninstall a role, use the following command (in our case, should we want to uninstall the DHCP Server role):

ocsetup DHCPServerCore /uninstall

9.7.1. Installing Active Directory Domain Services on Server Core

One role that you would likely want to install on a Server Core machine is the domain controller role. Installation of this role on a Server Core machine is a bit different, because installing the role using ocsetup has a large dependency on the graphical shell—meaning that using that method of setup can result in a very unstable Server Core machine that thinks it's a domain controller in some ways, but in other ways it doesn't.

The only supported way to install the domain controller role on a Server Core machine is to use the dcpromo utility in unattended mode. Using unattended mode requires setting up a simple text file with some parameters that will allow dcpromo to proceed without needing to prompt the user for any information, and ultimately you will be able to successfully promote a Server Core member server to a domain controller.

You need, at a minimum, the following nine parameters in a file called unattend.txt (or anything you want, as long as you remember the name):

[DCInstall]
ReplicaOrNewDomain=Domain
NewDomain=Forest
NewDomainDNSName=hasselltech.local
AutoConfigDNS=Yes
DNSDelegation=Yes
DNSDelegationUserName=username
DNSDelegationPassword=password
RebootOnSuccess=NoAndNoPromptEither
SafeModeAdminPassword=breakincaseofemergency

For more information on these parameters, and others that you could include, see Chapter 5.

Then, to run the utility, just issue the following command:

dcpromo /unattend:unattend.txt

9.7.2. Windows Remote Shell

Included with Windows Vista and full installations of Windows Server 2008 is the Windows Remote Shell, or WinRS. You'll also find WinRS on installations of Windows Server 2003 R2. WinRS consists of a listener portion that runs on the Server Core machine itself, and the client software on other machines. The client software sends commands addressed to specific machines to the listener port on that machine, and the WinRS software on the Server Core machine receives the command, executes, and transmits the output back to the originating client machine.

First, you'll need to activate the WinRS listener on the Server Core machine. Use the following command:

WinRM quickconfig

The process is shown in Figure 9-6.

Figure 9-6. Setting up the Windows Remote Shell listener on the Server Core machine

Once the listener is configured, you can simply go to any Windows Vista or Windows Server 2008 (full edition) machine, and funnel your Server Core-destined commands through winrs. For example, to see the results of the oclist command, issue the following at a command line on a Vista machine:

winrs -r:WS08-CORE-1 "oclist"

9.7.3. Controlling Server Core Via Group Policy

Many administrators find setting up Server Core machines with a consistent configuration can be achieved most easily through the use of a targeted Group Policy attack. You can create a group policy object (GPO) that only applies to Server Core machines by limiting the application of the GPO's attributes via WMI to only machines operating with the Server Core SKU, or by creating an organizational unit (OU) within Active Directory Domain Services, placing only Server Core machines within that OU, and then linking the GPO to the newly created OU. I prefer the WMI method, as it doesn't force you to construct your AD hierarchy based on operating systems, although both methods ultimately work equally as well in terms of the desired effect.

To use the WMI method, filter the OperatingSystemSKU property under the Win32_OperatingSystem class. The applicable values are as follow: 12 represents the Datacenter Server Core edition, 13 represents the Standard Server Core edition, and 14 represents the Enterprise Server Core edition.

For more information on using WMI to filter the application of GPOs, see Chapter 6.


the_last_word-id8.html

9.8. The Last Word

In this chapter, I discussed the Server Core edition of Windows Server 2008. Since there is no graphical shell, all administration for Server Core is done through the command line. We discussed installation, initial configuration, and management and administration.

Since Server Core is so stripped down, there isn't a lot to cover. They are essentially set-and-forget machines, which is the original concept of Server Core: to become more appliance-like than a full Windows Server 2008 installation.


terminal_services.html

Chapter 10. Terminal Services

In the old days of mainframe computing, employees typically used terminal equipment to connect to a big machine in a white room that ran all their programs and calculations. The terminal only showed the user interface while processing keystrokes and responses from the user; the mainframe in the back actually executed the programs and displayed the results to the end user so that very little processor intelligence resided at the client equipment end. This is largely why these terminal systems were called "dumb."

Although the move into the personal computing and desktop computing era made large inroads into corporate America, there are still some uses for dumb terminal (or in more modern terminology, "thin client") functionality. Windows Terminal Services (TS) is a set of programs and utilities that enable this functionality on a more intelligent, contemporary level. In fact, you might already be familiar with Terminal Services in a scaled-down mode. Both Windows XP's Remote Assistance and Remote Desktop Connection utilities are examples of Terminal Services in action. Terminal Services passes only the user interface of a program running on a server to the client computer, which then passes back the appropriate keyboard strokes and mouse clicks. The server running Terminal Services, which many clients can access simultaneously, manages the connections and the active programs seamlessly. It appears to the user that he's using his own computer, rather than one servicing other active applications at the same time.

Why is this useful? Many corporations, in an effort to reduce desktop support responsibilities for their help desks as well as equipment acquisition costs, are deploying thin client computers with limited client-side functionality. These thin clients provide users with a window into a server that is running the applications they need. Microsoft Office, many accounting applications, and multitudes of other programs work effectively under a Terminal Services environment, and the reduced management headaches are worth the extra initial setup effort for some businesses. Think about the reduced cost of applying patches, upgrading software, or removing outdated programs. You apply, upgrade, or remove once, and bingo: your entire enterprise IT environment is updated. It's hard to argue with that. This specific mode of using Terminal Services is known, very simply, as Terminal Services.

Terminal Services has another common use: remote administration. This is a hassle-free way that you can connect to machines running a Terminal Services-compatible operating system and use the machine's interface almost exactly as if you were sitting in front of it. Windows 2000, XP, and Server 2003 and Server 2008 come bundled with a license to do this. This is quite a boon for administrators: you don't have to leave your cubicle to administer elements of Windows on servers in your machine room.

A Terminal Services connection uses TCP port 3389 to allow clients to log on to a session from their workstation. However, the Terminal Services Configuration applet and the Terminal Services Manager console, both of which I'll also cover in this chapter, enable you to change this port and a number of other properties about each connection.

Terminal Server has its own method for licensing clients that log on to terminal servers, separate from the licensing method for clients running one of the other flavors of Windows Server 2008. In addition to being enabled to use Terminal Services in their user account properties, clients must receive a valid license issued by a license server before they are allowed to log on to a terminal server. Later in this chapter I'll discuss in greater detail the subject of licensing issues when using Terminal Services.

Terminal Services support is not included in Windows Server 2008 Web Edition, although you can use the Remote Desktop Connection applet in the Control Panel to remotely administer the server.

10.1. The Remote Desktop Protocol

The Remote Desktop Protocol (RDP) is the protocol that drives Terminal Services. RDP is based on and is an extension of the T.120 protocol family of standards. It is a multichannel-capable protocol that allows for separate virtual channels for carrying device communication and presentation data from the server, as well as encrypted client mouse and keyboard data. RDP provides a very extensible base from which to build many additional capabilities, supporting up to 64,000 separate channels for data transmission as well as provisions for multipoint transmission.

Figure 10-1 illustrates the structure of RDP and its functionality from a high-level perspective.

Figure 10-1. An overview of RDP

The new Terminal Services client software included in Windows Server 2008 (Remote Desktop Connection, or RDC) uses RDP 6.0, and many local resources are available within the remote session: the client drives, smart cards, audio card, serial ports, printers (including network), and clipboard. Additionally, you can select color depth from 256 colors (8-bit) to True Color (24-bit) and resolution from 640 x 480 up to 1,600 x 1,200.

RDP basically takes instructions from a terminal server host machine on screen images and draws them onto a client's screen, refreshing that image about 20 times every second if there's activity on the client side. (To save bandwidth, if no activity is detected on the client side, it cuts the refresh rate in half.) It then notes any keyboard and mouse activity (among other things) and relays those signals to the terminal server host machine for processing. This two-way exchange of information is wrapped into what's called a session, which consists of the programs running on the host machine and the information being sent over RDP between the terminal server and the client machine.

Here's what's new in Remote Desktop Connection 6.0:

Network level authentication (NLA) and server authentication

NLA is a new way for the RDC client to authenticate the user, client machine, and server against one another, thus removing the authentication transaction from the RDP process. Server authentication uses Transport Layer Security, or TLS, to match a server's true identity against the one it's projecting. This way clients can be sure that they're indeed talking to a real server and not a malconfigured, "owned" machine that may be posing as the real server in order to receive sensitive data.

Display improvements

You'll find that now, RDP sessions can support a maximum resolution of 4,096 x 2,048 with additional support for widescreen monitor scenarios. You can also span a session across multiple monitors if you have the hardware installed, and on all of these sessions you can get 32-bit full color depth and ClearType font smoothing.

Display data prioritization

This allows RDP to give more priority to data used to draw your RDP display during bandwidth-intensive operations like transferring large files or printing a big document, eliminating the herky-jerky user experience found in previous versions of RDP while carrying out these operations. By default, 70% of available bandwidth is used for display data and 30% for the remainder of session data. You can change this in the Registry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TermDD; the two keys are FlowControlDisplayBandwidth for the display data and FlowControlChannelBandwidth for everything else.

Desktop experience and composition

This feature allows users to get the look and feel of a regular Windows Vista host, including various desktop themes and access to Windows Media Player, that were unavailable under previous versions of RDP and Terminal Services. You can access this feature and enable it by using the Add Feature selection in Server Manager; the correct entry to select is "Desktop Experience." This is entirely server-based, so no client configuration is necessary.

Plug and Play Device Redirection Framework

This feature allows you to redirect PnP device interaction from the local RDP client to the server-based session, so the user sees the same seamless user interface for these devices regardless of whether they run locally or remotely. PnP devices in a remote session are limited in scope so that they are only accessible to that session.

Terminal Services EasyPrint

TS EasyPrint removes the need to install printer drivers on the TS host in the vast majority of cases by taking advantage of the new XPS print path that was introduced in Windows Vista and Windows Server 2008, acting as a proxy and redirecting all calls for the user interface to the print driver installed on the client. Users printing from within a session will see printing progress as they expect and can even adjust printer properties as necessary.

Single Sign-On

New to Windows Server 2008, users that are logged on to a domain can gain access to a domain-joined Terminal Server machine without needing to enter credentials a second time. This feature, however, only works with the Windows Vista-Windows Server 2008 client-server duo.


the_remote_desktop_protocol.html

Chapter 10. Terminal Services

In the old days of mainframe computing, employees typically used terminal equipment to connect to a big machine in a white room that ran all their programs and calculations. The terminal only showed the user interface while processing keystrokes and responses from the user; the mainframe in the back actually executed the programs and displayed the results to the end user so that very little processor intelligence resided at the client equipment end. This is largely why these terminal systems were called "dumb."

Although the move into the personal computing and desktop computing era made large inroads into corporate America, there are still some uses for dumb terminal (or in more modern terminology, "thin client") functionality. Windows Terminal Services (TS) is a set of programs and utilities that enable this functionality on a more intelligent, contemporary level. In fact, you might already be familiar with Terminal Services in a scaled-down mode. Both Windows XP's Remote Assistance and Remote Desktop Connection utilities are examples of Terminal Services in action. Terminal Services passes only the user interface of a program running on a server to the client computer, which then passes back the appropriate keyboard strokes and mouse clicks. The server running Terminal Services, which many clients can access simultaneously, manages the connections and the active programs seamlessly. It appears to the user that he's using his own computer, rather than one servicing other active applications at the same time.

Why is this useful? Many corporations, in an effort to reduce desktop support responsibilities for their help desks as well as equipment acquisition costs, are deploying thin client computers with limited client-side functionality. These thin clients provide users with a window into a server that is running the applications they need. Microsoft Office, many accounting applications, and multitudes of other programs work effectively under a Terminal Services environment, and the reduced management headaches are worth the extra initial setup effort for some businesses. Think about the reduced cost of applying patches, upgrading software, or removing outdated programs. You apply, upgrade, or remove once, and bingo: your entire enterprise IT environment is updated. It's hard to argue with that. This specific mode of using Terminal Services is known, very simply, as Terminal Services.

Terminal Services has another common use: remote administration. This is a hassle-free way that you can connect to machines running a Terminal Services-compatible operating system and use the machine's interface almost exactly as if you were sitting in front of it. Windows 2000, XP, and Server 2003 and Server 2008 come bundled with a license to do this. This is quite a boon for administrators: you don't have to leave your cubicle to administer elements of Windows on servers in your machine room.

A Terminal Services connection uses TCP port 3389 to allow clients to log on to a session from their workstation. However, the Terminal Services Configuration applet and the Terminal Services Manager console, both of which I'll also cover in this chapter, enable you to change this port and a number of other properties about each connection.

Terminal Server has its own method for licensing clients that log on to terminal servers, separate from the licensing method for clients running one of the other flavors of Windows Server 2008. In addition to being enabled to use Terminal Services in their user account properties, clients must receive a valid license issued by a license server before they are allowed to log on to a terminal server. Later in this chapter I'll discuss in greater detail the subject of licensing issues when using Terminal Services.

Terminal Services support is not included in Windows Server 2008 Web Edition, although you can use the Remote Desktop Connection applet in the Control Panel to remotely administer the server.

10.1. The Remote Desktop Protocol

The Remote Desktop Protocol (RDP) is the protocol that drives Terminal Services. RDP is based on and is an extension of the T.120 protocol family of standards. It is a multichannel-capable protocol that allows for separate virtual channels for carrying device communication and presentation data from the server, as well as encrypted client mouse and keyboard data. RDP provides a very extensible base from which to build many additional capabilities, supporting up to 64,000 separate channels for data transmission as well as provisions for multipoint transmission.

Figure 10-1 illustrates the structure of RDP and its functionality from a high-level perspective.

Figure 10-1. An overview of RDP

The new Terminal Services client software included in Windows Server 2008 (Remote Desktop Connection, or RDC) uses RDP 6.0, and many local resources are available within the remote session: the client drives, smart cards, audio card, serial ports, printers (including network), and clipboard. Additionally, you can select color depth from 256 colors (8-bit) to True Color (24-bit) and resolution from 640 x 480 up to 1,600 x 1,200.

RDP basically takes instructions from a terminal server host machine on screen images and draws them onto a client's screen, refreshing that image about 20 times every second if there's activity on the client side. (To save bandwidth, if no activity is detected on the client side, it cuts the refresh rate in half.) It then notes any keyboard and mouse activity (among other things) and relays those signals to the terminal server host machine for processing. This two-way exchange of information is wrapped into what's called a session, which consists of the programs running on the host machine and the information being sent over RDP between the terminal server and the client machine.

Here's what's new in Remote Desktop Connection 6.0:

Network level authentication (NLA) and server authentication

NLA is a new way for the RDC client to authenticate the user, client machine, and server against one another, thus removing the authentication transaction from the RDP process. Server authentication uses Transport Layer Security, or TLS, to match a server's true identity against the one it's projecting. This way clients can be sure that they're indeed talking to a real server and not a malconfigured, "owned" machine that may be posing as the real server in order to receive sensitive data.

Display improvements

You'll find that now, RDP sessions can support a maximum resolution of 4,096 x 2,048 with additional support for widescreen monitor scenarios. You can also span a session across multiple monitors if you have the hardware installed, and on all of these sessions you can get 32-bit full color depth and ClearType font smoothing.

Display data prioritization

This allows RDP to give more priority to data used to draw your RDP display during bandwidth-intensive operations like transferring large files or printing a big document, eliminating the herky-jerky user experience found in previous versions of RDP while carrying out these operations. By default, 70% of available bandwidth is used for display data and 30% for the remainder of session data. You can change this in the Registry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TermDD; the two keys are FlowControlDisplayBandwidth for the display data and FlowControlChannelBandwidth for everything else.

Desktop experience and composition

This feature allows users to get the look and feel of a regular Windows Vista host, including various desktop themes and access to Windows Media Player, that were unavailable under previous versions of RDP and Terminal Services. You can access this feature and enable it by using the Add Feature selection in Server Manager; the correct entry to select is "Desktop Experience." This is entirely server-based, so no client configuration is necessary.

Plug and Play Device Redirection Framework

This feature allows you to redirect PnP device interaction from the local RDP client to the server-based session, so the user sees the same seamless user interface for these devices regardless of whether they run locally or remotely. PnP devices in a remote session are limited in scope so that they are only accessible to that session.

Terminal Services EasyPrint

TS EasyPrint removes the need to install printer drivers on the TS host in the vast majority of cases by taking advantage of the new XPS print path that was introduced in Windows Vista and Windows Server 2008, acting as a proxy and redirecting all calls for the user interface to the print driver installed on the client. Users printing from within a session will see printing progress as they expect and can even adjust printer properties as necessary.

Single Sign-On

New to Windows Server 2008, users that are logged on to a domain can gain access to a domain-joined Terminal Server machine without needing to enter credentials a second time. This feature, however, only works with the Windows Vista-Windows Server 2008 client-server duo.


adding_the_terminal_server_role.html

10.2. Adding the Terminal Server Role

You can use the Server Manager, as with other roles in Windows Server 2008, to install Terminal Services. When you use Server Manager to install Terminal Services, you can choose from five options:

Terminal Server

This installs the core of TS functionality, including the ability to just share one application with TS RemoteApp.

TS Licensing

Deploys a TS Licensing Server to manage client access licenses for TS clients.

TS Session Broker

Installs software that can allow sessions to spread against a farm of TS hosts.

TS Gateway

Installs the feature that allows TS clients to use HTTPS to begin, use, and end sessions over the Internet without needing to establish a VPN connection. When you choose this role, you will be prompted to install IIS and Network Policy and Access Services if you haven't already.

TS Web Access

Creates a "portal"-like environment where clients can choose applications and start TS sessions for those applications from within a web browser. When you choose this role, you will be prompted to install IIS if you haven't already.

The permissions to connect to a terminal server are simple to understand. Any user who wants to connect via Terminal Services must be a member of the Remote Desktop Users group on the computer she is connecting to. You can alter the access permissions, time-of-day requirements, and other properties for this group through the Active Directory Users and Computers snap-in as usual. (See Chapter 5 for more information on managing users and groups within Active Directory.) If your machine is not participating in an Active Directory environment, user accounts must be members of the Administrators group of the machine to which they're trying to connect.

You should install Terminal Services on an NTFS-formatted partition to take advantage of the superior security features of that filesystem.


enabling_remote_desktop.html

10.3. Enabling Remote Desktop

As I mentioned earlier in this chapter, Remote Desktop mode is a special Terminal Services feature that enables you to open an RDP session as a single user to a specific machine and use its interface as though you were directly in front of it. This is useful if you're not looking to host applications for multiuser access but simply want a way to avoid walking to the server closet.

Windows Server 2008 comes installed with everything you need to use RDP to administer a server remotely, but as a security precaution, the service is turned off. It's easy to turn it back on, and it follows the same pattern that you use to turn on Remote Desktop in Windows XP versions as well. To turn it back on, follow these steps:

  1. Open the System applet in the Control Panel.

  2. Click the Remote settings link, and acknowledge the UAC prompt if necessary.

  3. Under the section at the bottom called Remote Desktop, select the "Allow connections from computers running any version of Remote Desktop (less secure)" radio button for backward compatibility with all versions of the RDP client, or "Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure)" to limit connections to RDP 6.0 clients.

  4. Click Apply, and then click OK.

Windows will display a dialog box that reminds you that it disables RDP access to accounts that have no password. This is to protect your computer from being invaded by Internet crackers. If you're using a firewall, you might also want to ensure that port 3389 is open and port forwarding is configured if required by your router/firewall. Windows will remind you of this, too.

Once Remote Desktop mode is enabled, up to two administrative users can connect to the server simultaneously and use it as though they were sitting in front of it. The remainder of this chapter will focus on Terminal Services mode, where more users can connect and use the server as a true application server.


on_the_user_apostrophy_s_side.html

10.4. On the User's Side

In this section, I'll take a look at interacting with Terminal Services from the client's perspective.

10.4.1. Using the RDP Client

Windows XP and Windows Vista come with a built-in client that speaks RDP, called Remote Desktop Connection. You can find it by selecting Start rightwards double arrow All Programs rightwards double arrow Accessories rightwards double arrow Communications rightwards double arrow Remote Desktop Connection. Executing the program brings up a screen such as the one in Figure 10-2.

Figure 10-2. The basic Remote Desktop Connection screen

Enter a server name to establish a basic, no-frills connection to a machine. If you want to customize the environment you're working in, click the Options button at the lower right of the Remote Desktop Connection box. You're presented with a box with five tabs: General, Display, Local Resources, Programs, and Experience. Let's walk through each tab:

General

On the General tab, you can choose the Terminal Services machine to log on to. You also can save the current settings to an RDP file, which you can open later by clicking the Save As button, or you can open an existing RDP settings file by clicking Open.

Display

On the Display tab, you can select the resolution (up to full screen at your current resolution) in which the session window will be displayed. You also can choose your color depth. You must disconnect and then reconnect before changes to these settings will take effect. Finally, check the option to display the connection bar—a small panel centered at the top of the session window—during full-screen sessions. The connection bar provides an easy way to minimize, maximize, and disconnect from a session.

Local Resources

On the Local Resources tab, you can choose to redirect sound to the client machine, to not play sounds at all, or to play them on the remote machine (to the chuckle of some coworkers, perhaps). You also can set the application of standard Windows keyboard shortcuts—such as Alt-Tab, Ctrl-Esc, Ctrl-Alt-Del, and the like—to the local computer, the remote computer, or the remote computer only if the display is set to full-screen mode. Finally, you can choose whether to make disk drives, printers, and serial ports on the client machine available to the Terminal Services session.

Programs

On the Programs tab, you can select one specific executable that will run automatically upon connection. This means that as soon as the user closes the program, the connection is terminated; there is no shell access to the session. You might choose to lock down Human Resources users by specifying that they can run only a PeopleSoft application; if they close PeopleSoft, their connection to the Terminal Services host machine is closed. You also can specify a working directory that the Open and Save dialog boxes will default to while the program is running.

Experience

On the Experience tab, you can adjust Microsoft's guesses as to your link quality and how bandwidth is managed during the session. You can choose your appropriate connection speed, and you can explicitly allow or deny the following to be transmitted: the desktop background, font smoothing, desktop composition, the contents of windows while they're being moved, animations of windows and menus (the scroll and fade effects), Windows desktop themes, and the caching of bitmaps.

Advanced

On the Advanced tab, you can adjust the server authentication level so that you are warned if server authentication fails, you can connect no matter what the results of the authentication tests are, or you are not able to connect if authentication fails. You calso configure TS Gateway settings that will allow you to start sessions to hosts that reside behind firewalls.

10.4.2. Configuring a User's Environment

A few settings inside a user's Active Directory account can affect the behavior of a Terminal Services session. Open Active Directory Users and Computers and select a sample user from your directory. Right-click the user and select Properties. When the user's settings are opened, click the Sessions tab. You will see a box like the one in Figure 10-3.

Figure 10-3. User properties in Active Directory for Terminal Services

Using the Sessions tab, you can configure Terminal Services' behavior when a user's session becomes inactive for a certain period of time. You can set the server to automatically log off a session that is disconnected after a specified interval of time. You can also set a time limit on active sessions and idle sessions, and then configure the behavior when that limit is reached. (This is great if you have a central machine for checking email that's located in a kiosk or other publicly accessible location.) Finally, on this tab you can specify that reconnection to an existing session can occur either from any computer, or only from the computer that originated the session as an added security measure.

On the Environment tab, you can make many of the same modifications as on the Programs tab of Remote Desktop Connection. You can select one specific executable that will run automatically and exclusively upon connection. You can also specify a working directory that the Open and Save dialog boxes will default to while the program is running. Plus, you can map devices from the client machine to the Terminal Services session by default inside the user's properties, which will carry forward into any future sessions.

On the Remote Control tab, you can specify whether an administrator can remotely control or observe a user's session. You also can configure whether such an action requires a user's permission. Plus, you can delineate how much control over the session is allowed—can the administrator just view the session, or can he also interact with the session?

On the Terminal Services Profile tab, you can enter a user profile to be used when connecting to a session. If you want to use a mandatory profile, be sure to enumerate the full network path down to the individual profile folder for that user. You also can determine whether a drive is mapped to a user's home directory, which drive letter to use, and which network drive to map to. Finally, you can decide whether a specific user should be allowed to log in to a terminal server. This isn't the best place for this option, in my opinion, but we have a while to wait (until Longhorn Server is released) for this to be changed.

10.4.3. Alternative RDP Clients

You might wish to access TS sessions hosted on Windows 2000 Server and Windows Server 2008 machines from computers that run on alternative platforms, such as Linux or Mac OS X. In this section, I've compiled a brief list of available, reasonably robust RDP client utilities that are available for operating systems other than Windows:

rdesktop

rdesktop is an open RDP client, but unlike Citrix ICA, requires no server extensions. rdesktop currently runs on most Unix-based platforms with the X Window System. (This includes most commercially available Linux systems.) As of this writing, the latest stable version of rdesktop is 1.4.0. You can download rdesktop from http://www.rdesktop.org.

Remote Desktop Client for Mac

Microsoft itself has released the Remote Desktop Client for Mac, which allows users of Mac OS X to open a TS session to their Windows XP or Windows Server 2003 machines from the comfort of their own environment. Download the client from Microsoft's Mac-oriented web site, located at http://www.microsoft.com/mac/otherproducts/otherproducts.aspx?pid=remotedesktopclient.


terminal_services_administration.html

10.5. Terminal Services Administration

You can administer a Terminal Services machine from three points:

The Terminal Services Manager console within Server Manager

You can run this console to display and control Terminal Services connections on a network.

The Terminal Services Configuration console within Server Manager

This console adjusts the individual Terminal Services configurations on each TS host.

The Terminal Services Licensing console

This console manages licensing across all Terminal Services machines in a domain.

At press time, TS licensing policies were still being developed and thus I will not be covering licensing. Instead, in this section, I'll cover the basic administrative functions that the Terminal Services Manager applet can perform, and then I will focus on some common tasks using the Terminal Services Configuration applet.

10.5.1. Terminal Services Manager

Terminal Services Manager (TSM) is the focal point where all connections between client computers and Terminal Services machines come into view. Think of it as "mission control."

TSM's full functionality only works when you run the console from a machine connected to Terminal Services through a TS session. Running TSM locally on the machine running Terminal Services will limit the functionality available to you.

Figure 10-4 shows the basic TSM layout.

Figure 10-4. The default Terminal Services Manager window

By default, TSM shows all Terminal Services servers in your domain. You can connect to all of them at once if you so choose, but TSM looks at only one server at a time by default. To find servers, use the following procedures:

  • To find all Terminal Services servers in your domain, in the right pane click Refresh.

  • To connect to any particular server, right-click its name in any list and select Connect.

Using TSM, you can perform a variety of network- and domain-wide session management functions. You can monitor a session, disconnect it, log it off, send messages to users, and take control of a session, among many other things.

10.5.1.1. Connecting to a session

Connecting to another session on a server is a useful tool for an administrator working remotely, for example, to fix a problem with a user's configuration in Microsoft Office while the user is at lunch. You always can connect to any active session or to a session that is disconnected. You can also connect to a session that is logged on inside your current security context (meaning basically your username) or, if you have the appropriate permissions (Full Control or User Access permissions over Terminal Services sessions), you can connect to any session.

To connect to a session, follow these steps:

  1. Right-click the appropriate session in the middle pane of TSM on the Sessions tab. Alternatively, to connect to a session run by a user, right-click the appropriate user's name on the Users tab. Choose Connect in either case.

  2. You are prompted for a password if needed. Otherwise, control is switched to the new session, and the active session is disconnected.

10.5.1.2. Disconnecting a session

A session that is disconnected is unique, in that it continues to run on the server, but the actual network link between the client and the Terminal Services machine is severed. Using a disconnected session, a user can return to a previous session at any time by simply re-establishing the connection, alleviating the need for either logging off or logging on. The catch is, of course, that server resources are finite, and if all users leave their sessions disconnected, everybody's copy of Outlook is still receiving mail, and everyone's PowerPoint presentations are still open to be edited. But disconnecting a session is still a handy way to clear your screen to take off to lunch, knowing that when you come back your desktop will be as you left it. It's sometimes useful to disconnect a session when Remote Desktop fails to pick up your old connection.

A user can disconnect any session of his own, and an administrator can disconnect any session over which he has Full Control rights.

To disconnect a session, follow these steps:

  1. Right-click the appropriate session and choose Disconnect.

  2. You are prompted to confirm your choice. Click OK, and the session will be disconnected.

You can select multiple sessions at a time in the right pane by pressing and holding the Ctrl key and clicking each session that you want to disconnect.

10.5.1.3. Logging off a session

Logging off a session ends that particular user's session on a host, thereby making any RAM and CPU resources that the particular session was using available to other users. Users must then log on the next time they connect to the Terminal Services server. A user can log off any session of her own, and an administrator can log off any session over which she has Full Control rights.

To log off a session, follow these steps:

  1. Right-click the appropriate session in the right pane of TSM, and choose Log Off.

  2. You are prompted to confirm your choice. Click OK, and the session will be disconnected.

Keep in mind that forcibly logging off users will result in data loss for those users, so always make them aware of any automatic logoffs before they happen.

You also can log off a session by issuing the logoff command, followed by the session ID or name (which you can find inside TSM), at the terminal server's command prompt. To log off session number 8, for example, use the following command:

logoff 8

10.5.1.4. Resetting a session

When you reset a session, it forcibly terminates that session: programs are closed, open data is lost, and memory that those programs were occupying is immediately returned to the Terminal Services host. A user can reset any session of his own, and an administrator can reset any session over which he has Full Control rights.

To reset a session, follow these steps:

  1. Right-click the appropriate session and choose Reset.

  2. You are prompted to confirm your choice. Click OK, and the session will be reset.

You can select multiple sessions at a time in the right pane by pressing and holding the Ctrl key and clicking each session that you want to reset.

You also can reset a session by issuing the reset command, followed by the session ID or name, at the terminal server's command prompt. To reset session number 8, for example, use the following command:

reset session 8

10.5.1.5. Viewing session information

Using TSM, you can get a wealth of detail about any particular session on a Terminal Services host machine, including the following:

  • Originating computer

  • Running process

  • Session image resolution and color depth

  • Data encryption level

To view this information, find the session in the left pane of TSM, and select it. Then, to view currently running programs and services, click the Processes tab. You'll see a listing much like that found in the Windows Task Manager. On the Information tab in the same pane, you find a listing of the username, client name, data encryption level, originating computer, and more.

But let's say you want information on all sessions, including their processes and logged-on users, for a particular Terminal Services machine, domain, or even an entire network. This is possible with TSM: simply select the machine, domain, or network in the left pane of TSM and use the Users, Sessions, or Processes tabs in the right pane to control the display of information.

Figure 10-5 shows this in action.

Figure 10-5. Viewing information on multiple sessions in TSM

You also can view this information from the command line with the query process, query session, query termserver, and query user commands. These simple commands display a table or list of the desired information. Here is example output from the four commands:

Code View:
C:\>query process
USERNAME SESSIONNAME ID PID IMAGE
>administrator rdp-tcp#10 1 4900 rdpclip.exe
>administrator rdp-tcp#10 1 4980 explorer.exe
>administrator rdp-tcp#10 1 3488 ducontrol.exe
>administrator rdp-tcp#10 1 5780 ctfmon.exe
>administrator rdp-tcp#10 1 3308 sqlmangr.exe
>administrator rdp-tcp#10 1 5056 cmd.exe
>administrator rdp-tcp#10 1 3088 query.exe
>administrator rdp-tcp#10 1 5844 qprocess.exe
C:\>query session
SESSIONNAME USERNAME ID STATE TYPE DEVICE
console 0 Conn wdcon
rdp-tcp 65536 Listen rdpwd
>rdp-tcp#10 administrator 1 Active rdpwd
C:\>query user
USERNAME SESSIONNAME ID STATE IDLE TIME LOGON
>administrator rdp-tcp#10 1 Active .
7/15/2004 5:49 PM
C:\>query termserver
NETWORK NETWORK
mercury hasselltech.local

10.5.1.6. Sending a message to a user

Sometimes it's necessary to send a message to all users logged on to a specific host, whether to mention that there might be downtime that evening, or that a virus or worm (God forbid) has invaded the Terminal Services machine and it needs to be shut down immediately. To send a message to a user, follow these steps:

  1. In the middle pane of TSM, right-click either the sessions or users to whom you want to send a message, and select Send Message.

  2. In the Send Message dialog box, enter the text for your message. If you want to use separate lines, press Ctrl-Enter to begin a new line.

  3. Click OK when you've finished entering the message.

A notification will be sent to the appropriate people. A sample is shown in Figure 10-6.

Figure 10-6. User messaging with Terminal Services

You also can send a message via the command-line, which might be helpful if you are planning on scripting a message transmission that is triggered by a certain event. The msg command is used to send these messages; some examples are presented here:

  • To send a message to user lmjohnson on server WTS1:

    msg lmjohnson /server:WTS1 message

  • To send a message to a particular session name:

    msg RDP-tcp#4 message

  • To send a message that will display on a user's screen for 30 seconds:

    msg lmjohnson /server:WTS1 /time:30 message

For more information on the switches and arguments available with the msg command, type msg /? at any command prompt.

10.5.1.7. Taking control of a session

Have you ever been on a troubleshooting call that was an intensely frustrating exercise in walking a user through a procedure in, say, Excel or Access? What if the user could watch you perform the actions on his screen, and what if you could show the user the steps without leaving your desk? If the user has a session on a Terminal Services machine, you as the administrator can take control of his session and have full access to whatever the user's screen displays. The user can watch whatever you do in his session, making the tool wonderful for quick problem solving. The user also can control his session at the same time, so both sides can interact.

This is exactly like the Remote Assistance feature, which is available in Windows XP, Windows Vista, and Windows Server 2003 and Server 2008 but recommended for use only with client computers running Windows XP. You shouldn't use Remote Assistance on servers for security reasons; rely on the Terminal Services remote control feature instead.

To take control of a particular session, follow these steps:

  1. In the middle pane of TSM, right-click either the sessions or users from whom you want to take control, and select Remote Control.

  2. The Remote Control dialog appears. Here, select the appropriate key to be pressed along with the Ctrl key to end a remote control session.

  3. By default, when you select OK, the user is prompted inside his session with a box asking him to confirm your request to take over his session. The user must acknowledge this prompt before remote control can begin.

It's possible to turn off the aforementioned user confirmation requirement through the user's properties inside Active Directory Users and Computers. On the Remote Control tab, uncheck the "Require user's permission" checkbox, as shown in Figure 10-7.

Figure 10-7. Disabling the user notification requirement for remote control

Later in this chapter, I will discuss a way to turn this notification on and off on a per-server basis.

You can also remotely control a user's session from the command line using the SHADOW command. You must know the session's name or identification number. For example, to connect to session 3 on the current server, issue the following command:

shadow

To connect to session 2 on server WTS2 and have the SHADOW utility tell you exactly what it does, issue the following command:

shadow 2 /server:WTS2 /v

10.5.2. Terminal Services Configuration

The Terminal Services Configuration applet provides a way to configure settings that are relevant to a specific server. When you open Terminal Services Configuration, you'll note that the middle pane of the console has two sections: Connections and Edit Settings. Let's focus on the Edit Settings section in this part of the chapter.

You'll see that you are provided with either six or seven options in the Edit Settings section, depending on whether your terminal server machine is a member of a cluster. Here are the options and their intended purposes:

Delete temporary folders on exit

If this option is set to Yes, any temporary folders created by Windows will be deleted. If the option is set to No, all temporary folders will remain. The default is Yes.

Use temporary folders per session

If this option is set to Yes, each session will have its own set of temporary folders for its exclusive use. If this option is set to No, all sessions will use one set of server-based temporary folders. The default is Yes.

Restrict Each User to One Session

If this option is set to Yes, no user can log on more than once to a particular Terminal Services host machine. If this option is set to No, a user can log on multiple times to the same server. The default is Yes.

User logon mode

This option lets you allow all connections, allow just reconnections but prevent new logons, or allow reconnections but prohibit new logons until the server is restarted. This is useful for gradually downing servers for maintenance.

License server discovery mode

This option allows you to specify how license servers are used, whether Windows Server 2008 can automatically discover license servers, or whether you want to use specific license servers.

Terminal Services licensing mode

If this option is set to Per Device, Terminal Services CALs are given to each client computer that connects to the host. If this option is set to Per User, CALs are distributed to each user that connects to the host. The default is Per Device.

Member of farm in TS Session Broker

This option lets you join a session broker farm, participate in Session Broker load balancing, and use IP address redirection.

The following sections will take you through common administrative tasks using the Connections node inside Terminal Services Configuration.

10.5.2.1. Creating a new connection listener

Use the Terminal Services Configuration applet to create a new Terminal Services connection by following these steps:

  1. Open the Terminal Services Configuration applet within Server Manager.

  2. In the right pane, click Create New Connection.

  3. The configuration wizard starts. Follow the prompts on the wizard to configure your connection.

Windows permits only one RDP-based connection per network card in the machine running Terminal Services. Usually, administrators find that the preconfigured connection created when Terminal Services is installed is really the only one they need. However, if you need more RDP connections, you'll need to install an additional network adapter for each connection needed.

10.5.2.2. Restricting Terminal Services connections

You can restrict the total number of RDP connections to any given server, which can be helpful if you have bandwidth problems on your network or your Terminal Services server machine has limited hardware resources.

To restrict the total number of RDP connections to a server through the Terminal Services Configuration applet, follow these steps:

  1. Open the Terminal Services Configuration applet within Server Manager.

  2. In the middle pane, select the applicable connection, right-click it, and choose Properties.

  3. Move to the Network Adapter tab and click Maximum Connections.

  4. Enter the maximum number of sessions you want to connect to this server.

  5. Click Apply to finish.

To do so using GP, which overrides and takes precedence over the settings specified in Terminal Services Configuration, follow these steps:

  1. Open the Group Policy Object Editor snap-in.

  2. Navigate through Computer Configuration rightwards double arrow Administrative Templates rightwards double arrow Windows Components in the tree in the left pane.

  3. Select Terminal Services, and in the right pane, double-click the Limit Number of Connections setting.

  4. Click Enabled.

  5. Move to the "TS Maximum Connections allowed" box. In it, enter the maximum number of connections you want to allow, and then click OK.

You might want to restrict the number of Terminal Services sessions by server to improve performance and decrease load. This technique works especially well when you have a terminal server farm consisting of machines of various capabilities and configurations. You can adjust each server to the optimal number of connections to ensure a consistent response time across the farm for your users.

RDP connections, by default, are configured to allow an unlimited number of sessions on each server.

10.5.2.3. Encryption levels

Terminal Services supports multiple levels of encryption to secure communications between the client and the server. To change these levels through Terminal Services Configuration, follow these steps:

  1. Open the Terminal Services Configuration applet within Server Manager.

  2. In the middle pane, select the applicable connection, right-click it, and choose Properties.

  3. Navigate to the General tab, and select the encryption level that best suits your needs. (I provide a description of the levels shortly.)

You can also change the TS encryption level using Group Policy:

  1. Open the Group Policy applet.

  2. Navigate through Computer Configuration rightwards double arrow Administrative Templates rightwards double arrow Windows Components rightwards double arrow Terminal Services.

  3. Select Encryption and Security.

  4. In the right pane, double-click the Set Client Connection Encryption Level setting, and then click Enabled.

  5. In the Encryption Level list, click the desired security level.

  6. Click OK to finish the procedure.

Use this guide to determine which security setting is best for your environment:

FIPS Compliant

Encrypts client-to-server and server-to-client communications strongly enough to be in accordance with the Federal Information Processing Standard (FIPS). This method uses Microsoft-developed cryptographic modules.

If you have already established FIPS encryption through a system cryptography policy object or through the Terminal Services Set Client Encryption Level option, you cannot change the encryption level through the Terminal Services Configuration applet or through a GPO.

High

Encrypts client-to-server and server-to-client communications using strong 128-bit encryption; useful only when the terminal server resides in an environment composed of 128-bit compliant clients only (i.e., one of the Windows Server 2008 operating systems). Other clients using noncompliant OSes will not be able to connect unless they download a separate Terminal Services client that supports high encryption from Microsoft's web site at http://www.microsoft.com/downloads/details.aspx?FamilyID=33AD53D8-9ABC-4E15-A78F-EB2AABAD74B5&displaylang=en.

Client Compatible

Encrypts client-to-server and server-to-client communications at the maximum possible level (key strength) supported on the client end. This option is best when the terminal server resides in a mixed client environment.

Low

Encrypts client-to-server communications only, using 56-bit encryption.

It's also important to note that the aforementioned GP procedure will work for local security policy configurations. However, if you have a domain environment and want to push this policy onto an existing domain or organizational unit, you need to connect to the domain controller using an account with administrator rights. Then you need to make the change through the Group Policy Management Console.

Also be aware that data sent from the server to the client (and not vice versa) is not encrypted.

10.5.2.4. Remote control permissions

You can adjust how administrators will be able to "shadow" a Terminal Services session. You can restrict a user to viewing a session only, or allow him to have full control of the keyboard and mouse. To adjust these settings through Terminal Services Configuration, follow these steps:

  1. Open the Terminal Services Configuration applet within Server Manager.

  2. In the middle pane, select the applicable connection, right-click it, and choose Properties.

  3. Navigate to the Remote Control tab.

  4. Click "Use Remote Control with the Following Settings" to configure remote control for the connection. Or, to disallow remote control, click Do Not Allow Remote Control.

  5. To display a message on the client asking permission to view or take part in the session, check the "Require user's permission" checkbox.

  6. Under "Level of Control," click "View the Session" to specify that the user's session can be viewed only, or click "Interact with the Session" to specify that the user's session can be actively controlled with your keyboard and mouse.

  7. Click OK to complete the procedure.

To do so using GP, follow these steps:

  1. Open the Group Policy applet.

  2. Navigate through Computer Configuration rightwards double arrow Administrative Templates rightwards double arrow Windows Components.

  3. Select Terminal Services.

  4. In the righthand pane, double-click the "Set Rules for Remote Control of Terminal Services User Sessions" setting, and then click Enabled.

  5. In the Options box, click the desired remote control permissions as described previously. Or, to disallow remote control, click No Remote Control Allowed.

  6. Click OK to complete the procedure.

You should thoroughly test any changes you make to GP settings before applying them to users or computers. Use the RSoP tool to test new policy settings and confirm that they will be applied as you intend. Chapter 6 contains detailed discussions and procedures for using this tool.

The aforementioned GP procedure also will work for local system policies. If you're using an Active Directory-based domain, though, and you want to push this policy onto an existing domain or organizational unit, you need to connect to the domain controller using an account with administrator rights and then make the change through the Group Policy Management Console.

Policies in effect are applied to, and therefore are in full force for, every client that connects to the terminal server.


terminal_services_remoteapp.html

10.6. Terminal Services RemoteApp

Terminal Services RemoteApp lets you define programs to be run directly from a TS-enabled server but appear totally integrated within the local copy of Windows. The integration is nearly perfect, showing off a seamless independent taskbar button, resizable application window areas, Alt-Tab switching functionality, population of system tray icons where appropriate, and more.

Terminal Services RemoteApp is designed to remove from the user's mind the idea that he is using a hosted application; the only giveaway would be the ToolTip in the taskbar that indicates Terminal Services is in use, plus occasional slow response because of network latency or server overload. It will look just like the application is running locally.

It's very simple to deploy as well. You simply create .rdp files that act as formatted profiles of available hosted applications. You can deploy these RDP files however you like throughout the enterprise, through Group Policy or over a web site, or through email or a systems management tool, and so on.

In this example, let's configure Calculator—truly a complex application, of course—to be used with TS RemoteApp:

  1. Open Server Manager.

  2. Drill down through the Terminal Services node in the left pane to TS RemoteApp Manager.

  3. In the right pane, click Add RemoteApp Programs to launch the RemoteApp Wizard. Click Next off the introductory screen.

  4. The "Choose programs to add to the RemoteApp Programs list" screen appears. Here is where you add specific applications to the RemoteApp list. Click the box beside Calculator, and then click Next.

  5. Review your settings, and then click Finish.

  6. Back in the TS RemoteApp Manager console, scroll down if necessary to the RemoteApp Programs list in the middle pane. Right-click on the newly added Calculator applet and select Create Windows Installer Package.

  7. Click Next off the introductory screen.

  8. The Specify Package Settings screen appears. Here, enter the location to which this Windows Installer package will be deployed. Verify the terminal server settings, gateway settings, and any certificate settings, then click Next.

  9. The Configure Distribution Package screen appears. Here, you can choose where end users will see the appropriate shortcuts for this package and whether the package should take over client extensions for the application—only appropriate when users don't have a copy of this application installed locally. Click Next.

  10. Review your settings, and then click Finish.

Now we have configured the package. You can deploy this MSI file via Group Policy (see Chapter 6 for an extensive walkthrough of application deployment via Group Policy). Once the MSI file is deployed on each computer, the user will see a Paint icon under the RemoteApp program group in the Start menu. Selecting it brings up a trust dialog asking the user to ensure that the remote computer is trustworthy; acknowledging that dialog and allowing the connection will bring up a "Starting RemoteApp" dialog followed by the Paint application, in all of its classic-themed glory, right on your desktop.


terminal_services_web_access.html

10.7. Terminal Services Web Access

The Terminal Services Web Access feature lets administrators make Terminal Services RemoteApp-hosted applications available on a web page. Users can browse the list for the application they are looking for, select it, and then be seamlessly connected to the application. You can even integrate TS Web Access within SharePoint sites using an included web part, so users have access from their collaboration portal to various hosted applications.

Using TS Web Access is straightforward. By default, adding an application to TS RemoteApp, as we did with the Calculator earlier in this chapter, automatically makes the application available for users via the TS Web Access gateway. To check, open Internet Explorer and navigate to http://servername/ts. After authenticating to the server, you should see a RemoteApp Programs list with Paint populated in the middle of the screen. Clicking on it opens Paint, as you might expect. If you click Remote Desktop, you can automatically connect to any TS host to which you have access, much like the old /tsweb link in previous versions of Windows Server.

If you want to configure TS Web Access further, simply use the same URL as above, but authenticate using your administrator credentials, and then click the Configuration link in the bar at the top of the program list window.


terminal_services_gateway.html

10.8. Terminal Services Gateway

Terminal Services Gateway, useful for corporations where large numbers of remote users would still need to be able to take advantage of RDP-based application deployment, allows users to access hosted applications from a centralized web portal accessible over Port 443 (or any other port you choose) via an encrypted HTTPS channel.

To further control access, there are connection authorization policies, or CAPs, that administrators can create to define user groups that are permitted to access TS through the TS Gateway machine, and resource authorization policies, or RAPs, that grant access to resources like an application or a server to only certain groups. So, you can limit hosted application use to only those users that need it while still deploying full-client copies of your programs to users with desktops, laptops, and other devices that can support them.

When you add the TS Gateway role, you are prompted to choose certificates for SSL encryption—either one you already have, one that is created on the fly and self-signed, or one you may choose later. You'll also be asked what types of authorization policies you would like to create—you can defer this selection as well depending on your needs. You should create one of each type of policy in order to get the maximum effect from TS Gateway.

You can create CAPs and RAPs from with Server Manager. Here's how:

  1. Open Server Manager.

  2. Drill down through the Terminal Services node in the left pane to TS Gateway Manager.

  3. In the left pane, expand the server and the Policies node.

  4. Click Connection Authorization Policies and then in the right pane, click Create New Policy to create a new CAP.

  5. Click Resource Authorization Policies and then in the right pane, click Create New Policy to create a new RAP.

Due to time limitations in order to print this book by the official release of Windows Server 2008, we have kept coverage of TS Gateway to a minimum. For a complete walkthrough of creating CAPs and RAPs, visit the O'Reilly web site and the official page for this book. We will post a link to a more detailed walkthrough by press time.


command-line_utilities-id3.html

10.9. Command-Line Utilities

Several neat utilities that are sprinkled throughout this chapter, and some that I didn't cover in detail, enable you to perform much of the functionality you find in the graphical management interfaces for Terminal Services from the command line. I've collected them all in this final section of the chapter, as a quick reference of sorts:

change logon

Enables logons (using the /enable switch) or disables logons (using the /disable switch) to a specific server. Use /query to find out what mode a machine is currently in.

change port

Modifies serial port mappings for programs that operate in DOS compatibility mode. Use /query to find out the current mappings.

change user

Changes the mode in which a Terminal Services machine operates. Using /install switches the machine into install mode to add applications of multisession use, and using /execute disables the install mode for normal functionality. Use /query to determine the current mode. See earlier in this chapter for detailed information on this command.

cprofile

Cleans profiles for inefficient use of space, and removes from the Registry any file associations the user has configured. Profiles must not be in use to run this tool. Use /L to clean every local profile, /I to prompt you before cleaning each profile, and /V to display each action the program has taken.

flattemp

Enables flat temporary directories—that is, enables the redirection of temporary directories to a location other than the default. /enable enables these directories (obviously), /disable does the opposite, and /query displays the feature's current status.

Logoff

Logs off a session. Use logoff sessionname or logoff sessionid to identify the session to end, and specify a particular server using the /V switch if necessary. See earlier in this chapter for detailed information on this command.

msg

Sends a message. See earlier in this chapter for detailed information on this command.

query process

Displays a table listing processes by session. See earlier in this chapter for sample output of this command.

query session

Displays a table listing sessions on a specific server. See earlier in this chapter for sample output of this command.

query termserver

Displays a list of known terminal servers in a domain. See earlier in this chapter for sample output of this command.

query user

Displays a list of users currently logged on to terminal services sessions. See earlier in this chapter for sample output of this command.

register

Sets an application to operate as either a system global resource, with the /system switch, or a user global resource, with the /user switch. Include the executable file's name as an argument.

reset session

Resets a session. Use reset sessionname or reset sessionid to identify the session to end, and specify a particular server using the /V switch if necessary. See earlier in this chapter for detailed information on this command.

shadow

Views the display for another user's session. You must run this over a Terminal Services connection to the host machine. See earlier in this chapter for detailed information on this command.

tscon

Connects to another session running on a server. See earlier in this chapter for detailed information on this command.

tsdiscon

Disconnects from another session running on a server. See earlier in this chapter for detailed information on this command.

tskill

Kills a certain process. Use tskill processid or tskill processname. To specify a server, use the /server switch, and to specify a certain session under which a process is running, use /ID:sessionid. To end a process running under all sessions, issue the /a switch.

tsprof

Configures profiles for users connecting to a terminal server. See earlier in this chapter for detailed information on this command.

tsshutdn

Shuts down a terminal server. You can specify an amount of time to wait before shutting down the machine by adding the number as an argument after the command name (i.e., tsshutdn 120 to wait two minutes). You also can specify whether to simply restart the machine by using the /reboot switch, or to power it down completely with the /powerdown switch.


the_last_word-id9.html

10.10. The Last Word

Windows Terminal Services is a useful inclusion to Windows Server 2008, allowing administrators to manage their servers without having to be directly in front of the console, and also allowing corporations to centrally host applications to reduce total cost of ownership, management, and administrative requirements. In this chapter, I explored both the user and the administrator side of TS and how it can add value to the Windows infrastructure.


dhcp_and_network_access_protection.html

Chapter 11. DHCP and Network Access Protection

In this chapter, I'll take a look at two major communications and networking services that are commonly used in Windows Server 2008 installations: the Dynamic Host Configuration Protocol, which helps administrators with IP address management, and the Network Access Protection feature to protect your network from untrusted clients.

This chapter has a practical focus. Entire books can (and have) been written on each of these topics, so I cannot possibly cover all of them in depth. Because of the vast amount of resources already available, I've chosen to focus on providing instructions for configuring these protocols and services to work under Windows Server 2008 rather than overwhelm you with page after page of theory. I discuss the mechanics a bit, but I place more emphasis on hands-on activities.

11.1. Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) assists administrators by automatically configuring computers with IP addresses, saving the hassle of assigning and tracking static IP addresses among multiple machines. When DHCP is coupled with dynamic DNS, a technique you learned about in Chapter 4, a lot of administrative headaches formerly encountered by network administrators are reduced and, in some cases, even eliminated.

11.1.1. How It Works

The process is started by the client, which makes a request for an IP address to a DHCP server. If a client is new to the network, or currently has an invalid IP address, the client will broadcast a DHCPDISCOVER message over the local subnet. The responding DHCP server (or, in some cases, servers) will send an offer request in the form of a DHCPOFFER packet. Then the client will acknowledge receipt of that offer and officially ask for an address with a DHCPREQUEST packet. In return, the DHCP server will confirm the lease and send any additional options that are configured with the address inside a DHCPACK packet.

Leases are granted for a period of time known as the lease duration. After 50% of the lease duration has lapsed, the client will request an extension—officially, this is a lease renewal—from the DHCP server from which it originally obtained the lease. If the client doesn't receive a response from that server, it will wait until 87.5% of the lease duration to attempt to renew its current lease with any DHCP machine on the network. If no server honors the lease renewal request, the client will end its use of the current IP address and then behave like a new client, as described previously.

Options are attributes of a DHCP lease that define certain characteristics about the IP address and IP stack of the computer leasing the address. For example, DHCP options specify parameters such as the DNS connection suffix (e.g., client2.hasselltech.local), the default gateway for a particular computer (the router through which traffic outside the local subnet is sent), and other important traits of a connection. Using DHCP options saves you a lot of time in manually assigning these traits to all your client computers, and it adds the element of consistency—all your computers leasing addresses within a certain scope get the same options and not a hodgepodge of configurations.

A Windows feature called Automatic Private IP Addressing (APIPA) overlaps DHCP functionality and can either be your best friend or drive you to insanity. Microsoft implemented this feature so that if a client is unable to lease an IP address from a DHCP server, it will resort to using a randomly chosen IP address from Microsoft's own Class B range (169.254.0.0 with subnet 255.255.0.0 and no default gateway assigned). The address is verified using an ARP request broadcast out to the network to ensure that no other client is using that address.

This feature is meant for convenience because most small businesses and home networks don't want to offer DHCP services from Windows itself and would like their networks to just work. However, if you have connectivity problems, Automatic Client Configuration (ACC) can really get in the way of troubleshooting at times. It's best to understand ACC's behavior under the following circumstances:

  • If a client has a valid lease from a DHCP server but can't connect to that DHCP server, ACC will attempt to ping the default router/gateway entry defined by the lease. If the client receives a reply, ACC assumes the machine is still on the network where the original DHCP server is located, and it will continue to use its lease.

  • If a router isn't answering at the gateway address in the lease, ACC will release the current IP address and pick an automatic address from the 169.254.0.0 range.

  • In any event, when ACC is active, the client will continue to search every five minutes for a valid DHCP server to either renew its lease or obtain a new address and corresponding lease.

  • You can also specify that the client use an alternate address in the event that the machine can't get an IP address from the DHCP server. You can view the settings and configure this in the properties of the network connection off the Start menu.

11.1.2. Installing a DHCP Server

Now that you know a bit about how DHCP works, let's move to installing an actual DHCP server. It's a fairly easy process. From Server Manager, select Add Role, and then check the DHCP Server role. You'll be asked about the name of the parent domain that clients use for name resolution and the IP addresses of the DNS servers with which clients will resolve names. You also will have an opportunity to add a scope (though we will walk through that in the next section) and enable or disable DHCPv6 stateless mode, which is a sort of automatic self-addressing that clients can use. Finally, you'll be presented with the opportunity to authorize the server in Active Directory.

In terms of actually adding pools of addresses for the DHCP role to dole out, that's outlined in the next section, so let's go there now.

11.1.3. Creating a New DHCP Scope

Creating a new DHCP scope involves selecting the range of IP addresses you want to make available to be leased out to clients who request them. This set of IP addresses is known as the scope.

The New Scope Wizard appears both when you first install a DHCP server and whenever you invoke it through the DHCP administration console, which you find off the Administrative Tools menu on the Start menu. To create a new scope on your DHCP server, follow these steps:

  1. Open the DHCP administration console by selecting DHCP from the Administrative Tools folder.

  2. Right-click the appropriate DHCP server in the left pane, and select New Scope from the pop-up context menu.

  3. The New Scope Wizard appears. Click Next to move off the introductory screen.

  4. Enter a name and a friendly, useful description (for your purposes only) for the new scope and then click Next.

  5. The IP Address Range screen appears (see Figure 11-1). Enter a noninterrupted range of IP addresses that you want to offer to clients into the "Start IP address" and "End IP address" fields. Then, enter the subnet mask to identify the network or subnet addresses you're using. (In most cases, you can accept the defaults.) Click Next to continue.

    Figure 11-1. The IP Address Range screen

  6. The Add Exclusions page appears next, depicted in Figure 11-2. On this page, you can enter a single address or range of addresses within your scope that you want to exclude from client provisioning—for example, if you have a few servers with IP addresses within your chosen range, you can identify those addresses so DHCP won't give them out and cause a conflict. Click Next to continue when you've entered any relevant addresses.

    Figure 11-2. The Add Exclusions screen

  7. The Lease Duration screen appears, which allows you to specify how long a DHCP-assigned address will be valid for a given scope. This is shown in Figure 11-3. Desktop systems can keep an IP lease for a long time; laptops and other mobile computers, however, should be given short lease durations so that when they are inactive, their IP address becomes available to be reassigned to other machines. If you have a mix of both, I suggest favoring a shorter lease time. Adjust the time using the individual sliders for days, hours, and minutes, and then click Next when you're done.

    Figure 11-3. The Lease Duration screen

  8. The Configure DHCP Options screen appears. Here, you can specify whether to simply configure the scope with the options you've specified to this point, or further customize the data transmitted in response to each DHCP request. In this example, we'll proceed through the extended options to discuss each one. Select "Yes, I want to configure these options now," and then click Next to continue.

  9. The Router (Default Gateway) screen appears, as depicted in Figure 11-4. Here, you can specify a list of available network gateways or routers in your order of preference. Add them using the Add buttons and adjust the list as needed using the Remove, Up, and Down buttons. Click Next when you've finished entering gateways.

    Figure 11-4. The Router (Default Gateway) screen

  10. The Domain Name and DNS Servers screen appears, shown in Figure 11-5. On this screen, you can input the parent domain name that your client computers should use for this connection. You also can specify preferred DNS servers for your client computers. You can either input a fully qualified domain name and click the Resolve button to find out the IP address, or enter the IP address directly and click Add to insert a server into the list. Use the Remove, Up, and Down buttons to edit the list as needed. Click Next when you've finished.

    Figure 11-5. The Domain Name and DNS Servers screen

  11. The WINS Servers screen appears. This is shown in Figure 11-6. On this screen, enter the WINS servers for your enterprise that clients receiving addresses from this scope should use. You can either input a fully qualified domain name and click the Resolve button to find out the IP address, or enter the IP address directly and click Add to insert a server into the list. Use the Remove, Up, and Down buttons to edit the list as needed. Click Next when you've finished.

  12. Finally, the Activate Scope screen appears. When you activate a scope, you start DHCP service for it. Choose your preferred option, and then click Next.

Figure 11-6. The WINS Servers screen

Once inside the DHCP console, which is shown in Figure 11-7, under the specific scope you can view the address pool, add a new exclusion range, view current IP addresses, enter reservations (more on this later), and reconfigure options for the scope. To view the current set of leases, simply click Address Leases underneath the node that represents the scope in which you're interested.

Figure 11-7. The DHCP administration console

11.1.4. Authorizing a DHCP Server

Although you can install DHCP servers on any machine running Windows Server 2008, the first DHCP server you install must hook itself into Active Directory and needs to be on a machine that is a member of a domain. Authorized DHCP servers are listed within the directory, and each DHCP server in a domain checks this list to see whether it is authorized to provide service; if it doesn't find itself in that list, it will not respond to DHCP requests. DHCP servers on standalone servers that are not members of domains can respond to DHCP requests; they do not need to be authorized, although this can pose a security threat, since a rogue server could assist clients and route them to different servers.

If you have a DHCP server that is located on a domain member machine, you can authorize it by doing the following:

  1. Log on to the machine with an account that has Enterprise Administrator credentials.

  2. Open the DHCP administration console by selecting DHCP from the Administrative Tools folder.

  3. Right-click the appropriate DHCP server in the left pane and select "Manage authorized servers" from the pop-up context menu.

  4. The Manage Authorized Servers screen appears, as shown in Figure 11-8. The screen lists all previously authorized DHCP servers. Click Authorize to add the server to this list.

    Figure 11-8. The Manage Authorized Servers screen

  5. On the following screen, enter the fully qualified domain name for the DHCP server or its associated IP address. Press OK.

  6. Confirm your choice on the following dialog box.

Now the DHCP server is authorized and will begin serving IP addresses to clients who request them.

11.1.5. Reservations

Reservations allow you to effectively set static IP addresses through DHCP. Although a client using reservations still will be configured to obtain a dynamic IP address, the DHCP server has a reservation in its database for that client—which is identified using the MAC address of the network card—and thus will always receive the same IP address from the DHCP server.

To create a new reservation, right-click Reservations under the appropriate scope in the lefthand pane and select New Reservation. The New Reservation screen will appear. Here, enter a friendly name for this reservation as a reference, and then the IP address to reserve. Then, enter the MAC address of the network card inside the computer that you want to have the reserved address. (You can see this from the command line by issuing the ipconfig /all command and looking for the physical adapter address, or through the Control Panel and Network Connections by right-clicking the adapter and selecting Status.) Enter a description of the reservation if you want, and then click OK.

Figure 11-9 shows the reservations screen.

Figure 11-9. Making a DHCP reservation

11.1.6. Understanding Classes

Classes distinguish between different systems and users for the purposes of assigning or allowing different options. Two types of classes are available within DHCP: vendor classes, which are set by the manufacturer and cannot be edited; and user classes, which are set at the client level on client computers and can be edited and used by administrators. Vendor classes can be used to send all computers matching a certain class a specific set of DHCP options—for example, to configure members of that class with a different set of DNS servers or gateways. And with the Windows Server 2008 vendor classes, you can offer specific systems the option of disabling NetBIOS, releasing its lease upon shutdown, and defining a metric for routing requests quickly and efficiently to network gateways.

Vendors choose their own vendor classes, so you will need to consult with your vendor's documentation or support group to determine what vendor classes your adapters will listen for and respond to. Vendor classes can also represent the manufacturer of the network card and the manufacturer of the computer, whichever makes the most sense for your organization.

Microsoft has created the MSFT prefix to provide classification of its DHCP clients in Windows 98 and higher.

User classes are set by administrators and further define group users through means that aren't available via the vendor class. For example, you can set a user class for "Charlotte office" and another for "Raleigh office," to segregate the different groups to different IP resources. Identical classes need to be set on the client and on the DHCP server.

With user classes, it's possible to use predefined classes to support groups of clients with special needs, such as clients using the older BOOTP protocol, or clients connecting through the Routing and Remote Access Service. User classes really are meant for larger networks that need to manage DHCP option assignments based on different computer criteria, and that need to assign and override the standard option assignments at the server, scope, or reservation level.

To create a user class on the server, follow these steps:

  1. Open the DHCP administrator console.

  2. Right-click the DHCP server and select Define User Classes from the pop-up context menu.

  3. The DHCP User Classes dialog box appears. Click the Add button.

  4. The New Class box appears, as shown in Figure 11-10.

    Figure 11-10. The New Class box

  5. Enter a name for the new class; this should be identical to the name you will use on a client. Also, enter a friendly description for your purposes if you want.

  6. Enter the ASCII text of the class by clicking under the word ASCII and typing text. The binary version of what you type will be generated automatically.

  7. Click OK.

The new class has been created. Now, configure the DHCP options to send only to this class:

  1. Under the server node in the left pane on the DHCP administrator console, right-click Scope Options and select Configure Options.

  2. Navigate to the Advanced tab.

  3. Under User Class, select the new class ID you just configured.

  4. Finally, under Available Options, select the options you want to configure and enter the values for those options.

  5. Click OK when you've finished.

Now the scope is configured to send certain options to your new class. On each client computer that will be a member of that class, issue the following command:

ipconfig /setclassid "Local Area Connection" "Name of New User Class"

You will receive a message indicating that the assignment was successful.

11.1.7. Superscopes

A superscope is a collection of scopes that can service requests from clients from multiple subnets over the same physical layer medium. By configuring a DHCP server with a superscope that encompasses several smaller scopes, you can provide DHCP service to multiple subnets simultaneously. Use superscopes when you need to provide leases to clients on more than one subnet with one DHCP server.

To begin configuring a superscope, follow these steps:

  1. Load the DHCP administrator console.

  2. Then right-click the DHCP server node and select New Superscope from the pop-up context menu. Click Next off the introductory screen for the wizard.

  3. Enter the name of the new superscope you're creating, and then click Next.

  4. From the Available Scopes list, select the scopes to include in this new superscope. You can hold down the Ctrl button and click to select multiple scopes.

  5. Click Next and confirm your settings. Then, click Finish.

The superscope is now active.

11.1.8. Conflict Detection

To ensure that one IP address is not leased to two different clients, the Windows Server 2008 DHCP service includes a conflict detection mechanism, which involves a ping test to verify that an IP address isn't in use before it is leased to a client.

You can verify that this feature is enabled, which you might want to do if you need to rebuild your DHCP server and ensure that, when you bring the server back up, it won't lease IP addresses currently in use. To do so, right-click the server name in the DHCP management console, select Properties, and navigate to the Advanced tab. Find the option called Conflict Detections Attempt, and set it to any value greater than 0 but less than 2 (performance issues arise with greater values). This number specifies the number of ping attempts the DHCP server will make before issuing an address.

11.1.9. DHCP Implications for DNS

The Windows Server 2008 DNS service supports updates from DHCP clients so that name-to-IP mappings continue to be accurate through the release and renewal process. On clients, you can configure this behavior by opening the properties of the local area connection (on Windows XP, you can find a list of network connections from the "Connect to" menu on the Start menu; in Windows 2000, this is done through the Network & Dial-up Connections applet in the Control Panel). Once you are inside the properties sheet, navigate to the DNS tab. At the bottom of the screen, select the "Register this connection's addresses in DNS" option, as shown in Figure 11-11. This will instruct the client to transmit an updated A record to the primary DNS server.

Figure 11-11. Registering a DHCP-assigned client address in DNS

If you want the DHCP server to handle these updates instead of the client, the first step is to make your DHCP server computer object a member of the DnsUpdateProxy group within Active Directory. If you have gone through the process of authorizing your DHCP server (described earlier in this chapter), this step has been completed automatically. If you haven't gone through this process, look at the DHCP administrators' console—right-click the DHCP server node and click Properties. Navigate to the DNS tab, which is shown in Figure 11-12.

Figure 11-12. Configuring DHCP-based updates to DNS

Here, you can instruct the DHCP service to automatically update DNS records for its clients at all times or only in instances where the client requests the update be pushed to the DNS server. You also can tell the service to expire the A records for a client when its current lease expires, and you can enable updates for clients that are unable to dynamically update their own records in DHCP.


dynamic_host_configuration_protocol.html

Chapter 11. DHCP and Network Access Protection

In this chapter, I'll take a look at two major communications and networking services that are commonly used in Windows Server 2008 installations: the Dynamic Host Configuration Protocol, which helps administrators with IP address management, and the Network Access Protection feature to protect your network from untrusted clients.

This chapter has a practical focus. Entire books can (and have) been written on each of these topics, so I cannot possibly cover all of them in depth. Because of the vast amount of resources already available, I've chosen to focus on providing instructions for configuring these protocols and services to work under Windows Server 2008 rather than overwhelm you with page after page of theory. I discuss the mechanics a bit, but I place more emphasis on hands-on activities.

11.1. Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) assists administrators by automatically configuring computers with IP addresses, saving the hassle of assigning and tracking static IP addresses among multiple machines. When DHCP is coupled with dynamic DNS, a technique you learned about in Chapter 4, a lot of administrative headaches formerly encountered by network administrators are reduced and, in some cases, even eliminated.

11.1.1. How It Works

The process is started by the client, which makes a request for an IP address to a DHCP server. If a client is new to the network, or currently has an invalid IP address, the client will broadcast a DHCPDISCOVER message over the local subnet. The responding DHCP server (or, in some cases, servers) will send an offer request in the form of a DHCPOFFER packet. Then the client will acknowledge receipt of that offer and officially ask for an address with a DHCPREQUEST packet. In return, the DHCP server will confirm the lease and send any additional options that are configured with the address inside a DHCPACK packet.

Leases are granted for a period of time known as the lease duration. After 50% of the lease duration has lapsed, the client will request an extension—officially, this is a lease renewal—from the DHCP server from which it originally obtained the lease. If the client doesn't receive a response from that server, it will wait until 87.5% of the lease duration to attempt to renew its current lease with any DHCP machine on the network. If no server honors the lease renewal request, the client will end its use of the current IP address and then behave like a new client, as described previously.

Options are attributes of a DHCP lease that define certain characteristics about the IP address and IP stack of the computer leasing the address. For example, DHCP options specify parameters such as the DNS connection suffix (e.g., client2.hasselltech.local), the default gateway for a particular computer (the router through which traffic outside the local subnet is sent), and other important traits of a connection. Using DHCP options saves you a lot of time in manually assigning these traits to all your client computers, and it adds the element of consistency—all your computers leasing addresses within a certain scope get the same options and not a hodgepodge of configurations.

A Windows feature called Automatic Private IP Addressing (APIPA) overlaps DHCP functionality and can either be your best friend or drive you to insanity. Microsoft implemented this feature so that if a client is unable to lease an IP address from a DHCP server, it will resort to using a randomly chosen IP address from Microsoft's own Class B range (169.254.0.0 with subnet 255.255.0.0 and no default gateway assigned). The address is verified using an ARP request broadcast out to the network to ensure that no other client is using that address.

This feature is meant for convenience because most small businesses and home networks don't want to offer DHCP services from Windows itself and would like their networks to just work. However, if you have connectivity problems, Automatic Client Configuration (ACC) can really get in the way of troubleshooting at times. It's best to understand ACC's behavior under the following circumstances:

  • If a client has a valid lease from a DHCP server but can't connect to that DHCP server, ACC will attempt to ping the default router/gateway entry defined by the lease. If the client receives a reply, ACC assumes the machine is still on the network where the original DHCP server is located, and it will continue to use its lease.

  • If a router isn't answering at the gateway address in the lease, ACC will release the current IP address and pick an automatic address from the 169.254.0.0 range.

  • In any event, when ACC is active, the client will continue to search every five minutes for a valid DHCP server to either renew its lease or obtain a new address and corresponding lease.

  • You can also specify that the client use an alternate address in the event that the machine can't get an IP address from the DHCP server. You can view the settings and configure this in the properties of the network connection off the Start menu.

11.1.2. Installing a DHCP Server

Now that you know a bit about how DHCP works, let's move to installing an actual DHCP server. It's a fairly easy process. From Server Manager, select Add Role, and then check the DHCP Server role. You'll be asked about the name of the parent domain that clients use for name resolution and the IP addresses of the DNS servers with which clients will resolve names. You also will have an opportunity to add a scope (though we will walk through that in the next section) and enable or disable DHCPv6 stateless mode, which is a sort of automatic self-addressing that clients can use. Finally, you'll be presented with the opportunity to authorize the server in Active Directory.

In terms of actually adding pools of addresses for the DHCP role to dole out, that's outlined in the next section, so let's go there now.

11.1.3. Creating a New DHCP Scope

Creating a new DHCP scope involves selecting the range of IP addresses you want to make available to be leased out to clients who request them. This set of IP addresses is known as the scope.

The New Scope Wizard appears both when you first install a DHCP server and whenever you invoke it through the DHCP administration console, which you find off the Administrative Tools menu on the Start menu. To create a new scope on your DHCP server, follow these steps:

  1. Open the DHCP administration console by selecting DHCP from the Administrative Tools folder.

  2. Right-click the appropriate DHCP server in the left pane, and select New Scope from the pop-up context menu.

  3. The New Scope Wizard appears. Click Next to move off the introductory screen.

  4. Enter a name and a friendly, useful description (for your purposes only) for the new scope and then click Next.

  5. The IP Address Range screen appears (see Figure 11-1). Enter a noninterrupted range of IP addresses that you want to offer to clients into the "Start IP address" and "End IP address" fields. Then, enter the subnet mask to identify the network or subnet addresses you're using. (In most cases, you can accept the defaults.) Click Next to continue.

    Figure 11-1. The IP Address Range screen

  6. The Add Exclusions page appears next, depicted in Figure 11-2. On this page, you can enter a single address or range of addresses within your scope that you want to exclude from client provisioning—for example, if you have a few servers with IP addresses within your chosen range, you can identify those addresses so DHCP won't give them out and cause a conflict. Click Next to continue when you've entered any relevant addresses.

    Figure 11-2. The Add Exclusions screen

  7. The Lease Duration screen appears, which allows you to specify how long a DHCP-assigned address will be valid for a given scope. This is shown in Figure 11-3. Desktop systems can keep an IP lease for a long time; laptops and other mobile computers, however, should be given short lease durations so that when they are inactive, their IP address becomes available to be reassigned to other machines. If you have a mix of both, I suggest favoring a shorter lease time. Adjust the time using the individual sliders for days, hours, and minutes, and then click Next when you're done.

    Figure 11-3. The Lease Duration screen

  8. The Configure DHCP Options screen appears. Here, you can specify whether to simply configure the scope with the options you've specified to this point, or further customize the data transmitted in response to each DHCP request. In this example, we'll proceed through the extended options to discuss each one. Select "Yes, I want to configure these options now," and then click Next to continue.

  9. The Router (Default Gateway) screen appears, as depicted in Figure 11-4. Here, you can specify a list of available network gateways or routers in your order of preference. Add them using the Add buttons and adjust the list as needed using the Remove, Up, and Down buttons. Click Next when you've finished entering gateways.

    Figure 11-4. The Router (Default Gateway) screen

  10. The Domain Name and DNS Servers screen appears, shown in Figure 11-5. On this screen, you can input the parent domain name that your client computers should use for this connection. You also can specify preferred DNS servers for your client computers. You can either input a fully qualified domain name and click the Resolve button to find out the IP address, or enter the IP address directly and click Add to insert a server into the list. Use the Remove, Up, and Down buttons to edit the list as needed. Click Next when you've finished.

    Figure 11-5. The Domain Name and DNS Servers screen

  11. The WINS Servers screen appears. This is shown in Figure 11-6. On this screen, enter the WINS servers for your enterprise that clients receiving addresses from this scope should use. You can either input a fully qualified domain name and click the Resolve button to find out the IP address, or enter the IP address directly and click Add to insert a server into the list. Use the Remove, Up, and Down buttons to edit the list as needed. Click Next when you've finished.

  12. Finally, the Activate Scope screen appears. When you activate a scope, you start DHCP service for it. Choose your preferred option, and then click Next.

Figure 11-6. The WINS Servers screen

Once inside the DHCP console, which is shown in Figure 11-7, under the specific scope you can view the address pool, add a new exclusion range, view current IP addresses, enter reservations (more on this later), and reconfigure options for the scope. To view the current set of leases, simply click Address Leases underneath the node that represents the scope in which you're interested.

Figure 11-7. The DHCP administration console

11.1.4. Authorizing a DHCP Server

Although you can install DHCP servers on any machine running Windows Server 2008, the first DHCP server you install must hook itself into Active Directory and needs to be on a machine that is a member of a domain. Authorized DHCP servers are listed within the directory, and each DHCP server in a domain checks this list to see whether it is authorized to provide service; if it doesn't find itself in that list, it will not respond to DHCP requests. DHCP servers on standalone servers that are not members of domains can respond to DHCP requests; they do not need to be authorized, although this can pose a security threat, since a rogue server could assist clients and route them to different servers.

If you have a DHCP server that is located on a domain member machine, you can authorize it by doing the following:

  1. Log on to the machine with an account that has Enterprise Administrator credentials.

  2. Open the DHCP administration console by selecting DHCP from the Administrative Tools folder.

  3. Right-click the appropriate DHCP server in the left pane and select "Manage authorized servers" from the pop-up context menu.

  4. The Manage Authorized Servers screen appears, as shown in Figure 11-8. The screen lists all previously authorized DHCP servers. Click Authorize to add the server to this list.

    Figure 11-8. The Manage Authorized Servers screen

  5. On the following screen, enter the fully qualified domain name for the DHCP server or its associated IP address. Press OK.

  6. Confirm your choice on the following dialog box.

Now the DHCP server is authorized and will begin serving IP addresses to clients who request them.

11.1.5. Reservations

Reservations allow you to effectively set static IP addresses through DHCP. Although a client using reservations still will be configured to obtain a dynamic IP address, the DHCP server has a reservation in its database for that client—which is identified using the MAC address of the network card—and thus will always receive the same IP address from the DHCP server.

To create a new reservation, right-click Reservations under the appropriate scope in the lefthand pane and select New Reservation. The New Reservation screen will appear. Here, enter a friendly name for this reservation as a reference, and then the IP address to reserve. Then, enter the MAC address of the network card inside the computer that you want to have the reserved address. (You can see this from the command line by issuing the ipconfig /all command and looking for the physical adapter address, or through the Control Panel and Network Connections by right-clicking the adapter and selecting Status.) Enter a description of the reservation if you want, and then click OK.

Figure 11-9 shows the reservations screen.

Figure 11-9. Making a DHCP reservation

11.1.6. Understanding Classes

Classes distinguish between different systems and users for the purposes of assigning or allowing different options. Two types of classes are available within DHCP: vendor classes, which are set by the manufacturer and cannot be edited; and user classes, which are set at the client level on client computers and can be edited and used by administrators. Vendor classes can be used to send all computers matching a certain class a specific set of DHCP options—for example, to configure members of that class with a different set of DNS servers or gateways. And with the Windows Server 2008 vendor classes, you can offer specific systems the option of disabling NetBIOS, releasing its lease upon shutdown, and defining a metric for routing requests quickly and efficiently to network gateways.

Vendors choose their own vendor classes, so you will need to consult with your vendor's documentation or support group to determine what vendor classes your adapters will listen for and respond to. Vendor classes can also represent the manufacturer of the network card and the manufacturer of the computer, whichever makes the most sense for your organization.

Microsoft has created the MSFT prefix to provide classification of its DHCP clients in Windows 98 and higher.

User classes are set by administrators and further define group users through means that aren't available via the vendor class. For example, you can set a user class for "Charlotte office" and another for "Raleigh office," to segregate the different groups to different IP resources. Identical classes need to be set on the client and on the DHCP server.

With user classes, it's possible to use predefined classes to support groups of clients with special needs, such as clients using the older BOOTP protocol, or clients connecting through the Routing and Remote Access Service. User classes really are meant for larger networks that need to manage DHCP option assignments based on different computer criteria, and that need to assign and override the standard option assignments at the server, scope, or reservation level.

To create a user class on the server, follow these steps:

  1. Open the DHCP administrator console.

  2. Right-click the DHCP server and select Define User Classes from the pop-up context menu.

  3. The DHCP User Classes dialog box appears. Click the Add button.

  4. The New Class box appears, as shown in Figure 11-10.

    Figure 11-10. The New Class box

  5. Enter a name for the new class; this should be identical to the name you will use on a client. Also, enter a friendly description for your purposes if you want.

  6. Enter the ASCII text of the class by clicking under the word ASCII and typing text. The binary version of what you type will be generated automatically.

  7. Click OK.

The new class has been created. Now, configure the DHCP options to send only to this class:

  1. Under the server node in the left pane on the DHCP administrator console, right-click Scope Options and select Configure Options.

  2. Navigate to the Advanced tab.

  3. Under User Class, select the new class ID you just configured.

  4. Finally, under Available Options, select the options you want to configure and enter the values for those options.

  5. Click OK when you've finished.

Now the scope is configured to send certain options to your new class. On each client computer that will be a member of that class, issue the following command:

ipconfig /setclassid "Local Area Connection" "Name of New User Class"

You will receive a message indicating that the assignment was successful.

11.1.7. Superscopes

A superscope is a collection of scopes that can service requests from clients from multiple subnets over the same physical layer medium. By configuring a DHCP server with a superscope that encompasses several smaller scopes, you can provide DHCP service to multiple subnets simultaneously. Use superscopes when you need to provide leases to clients on more than one subnet with one DHCP server.

To begin configuring a superscope, follow these steps:

  1. Load the DHCP administrator console.

  2. Then right-click the DHCP server node and select New Superscope from the pop-up context menu. Click Next off the introductory screen for the wizard.

  3. Enter the name of the new superscope you're creating, and then click Next.

  4. From the Available Scopes list, select the scopes to include in this new superscope. You can hold down the Ctrl button and click to select multiple scopes.

  5. Click Next and confirm your settings. Then, click Finish.

The superscope is now active.

11.1.8. Conflict Detection

To ensure that one IP address is not leased to two different clients, the Windows Server 2008 DHCP service includes a conflict detection mechanism, which involves a ping test to verify that an IP address isn't in use before it is leased to a client.

You can verify that this feature is enabled, which you might want to do if you need to rebuild your DHCP server and ensure that, when you bring the server back up, it won't lease IP addresses currently in use. To do so, right-click the server name in the DHCP management console, select Properties, and navigate to the Advanced tab. Find the option called Conflict Detections Attempt, and set it to any value greater than 0 but less than 2 (performance issues arise with greater values). This number specifies the number of ping attempts the DHCP server will make before issuing an address.

11.1.9. DHCP Implications for DNS

The Windows Server 2008 DNS service supports updates from DHCP clients so that name-to-IP mappings continue to be accurate through the release and renewal process. On clients, you can configure this behavior by opening the properties of the local area connection (on Windows XP, you can find a list of network connections from the "Connect to" menu on the Start menu; in Windows 2000, this is done through the Network & Dial-up Connections applet in the Control Panel). Once you are inside the properties sheet, navigate to the DNS tab. At the bottom of the screen, select the "Register this connection's addresses in DNS" option, as shown in Figure 11-11. This will instruct the client to transmit an updated A record to the primary DNS server.

Figure 11-11. Registering a DHCP-assigned client address in DNS

If you want the DHCP server to handle these updates instead of the client, the first step is to make your DHCP server computer object a member of the DnsUpdateProxy group within Active Directory. If you have gone through the process of authorizing your DHCP server (described earlier in this chapter), this step has been completed automatically. If you haven't gone through this process, look at the DHCP administrators' console—right-click the DHCP server node and click Properties. Navigate to the DNS tab, which is shown in Figure 11-12.

Figure 11-12. Configuring DHCP-based updates to DNS

Here, you can instruct the DHCP service to automatically update DNS records for its clients at all times or only in instances where the client requests the update be pushed to the DNS server. You also can tell the service to expire the A records for a client when its current lease expires, and you can enable updates for clients that are unable to dynamically update their own records in DHCP.


network_access_protection-id1.html

11.2. Network Access Protection

Viruses and malware are often stopped by software defenses that run on the desktop; in fact, the antivirus, antispyware, and other security suite software business has rapidly become a very lucrative industry. As useful as those protections are, however, the best solution would be such threats never getting a chance to access the network—like the old saying goes, "The quickest way out of something is to never have been in it."

In Windows Server 2008, there is a technology that allows computers to be examined against a baseline set by an administrator, and if a machine doesn't stack up in any way against that baseline, the system can be prevented from accessing the network—quarantined, as it were, from the healthy systems until the user fixes his broken machine. This functionality is called Network Access Protection (NAP).

You might know of NAP's predecessor, Network Access Quarantine Control, or NAQC. It debuted in Windows Server 2003 as a more limited form of quarantine protection. NAQC is limited to protecting your corporate network against remote users: it prevents unhindered access to a network for a remote user until after his computer has been verified as meeting certain baselines set by a network administrator.

Under NAQC, when a client establishes a connection to a remote network's endpoint, the client will receive an IP address, but Internet Authentication Service establishes a quarantine mode that is lifted only after health verification is complete. While NAQC is useful, it requires programming a baseline script to set up; its management facilities are next to none; and most critically, it offers no safeguards against infected machines inside the corporate campus.

11.2.1. How It Works

NAP addresses these weaknesses and builds on the solid premise of NAQC—that stopping spyware and viruses dead, before they can ever reach the network, is the best line of defense. NAP in Windows Server 2008 can be considered in three different parts:

Health policy validation

Validation is the process where the machine attempting to connect to the network is examined and checked against certain health criteria that an administrator sets. This criteria can include patch state, service-pack level, presence of AV software and so on.

Health policy compliance

Compliance policies can be set so that managed computers that fail the validation process can be automatically updated or fixed via Systems Management Server or some other management software. This is an optional, but very useful, part of NAP. You can also set up mechanisms to ensure that compliance is ongoing and that machines are healthy for the entire time they're on the network.

Limited access

Access limiting can be the enforcement mechanism for NAP. It's possible to run NAP in monitoring-only mode, which logs the compliance and validation state of computers connecting to the network. But in active mode, computers that fail validations are put into a limited-access area of the network, which typically blocks almost all network access and restricts traffic to a set of specially hardened servers that contain the tools most commonly needed to get machines up to snuff.

Here's the basic process for a NAP session and the various bits and pieces that are involved:

  1. A client asks for access to the network and presents its current state of health to the Dynamic Host Configuration Protocol (DHCP) server, virtual private network (VPN) server, or a compatible switch or router.

  2. The DHCP/VPN server or router/switch sends the health status, as presented by the client, to the Microsoft Network Policy Server, which is a machine based on the RADIUS protocol that replaces the Internet Authentication Service you might know from Windows Server 2003.

  3. The Network Policy Server checks the health status against the criteria that the administrator sets and, based on the results of the check, does one of the following: if the machine does not comply with the IT policy, the client is put into a restricted virtual LAN; is disallowed, via IPsec rules or via 802.1x wire-level protection, from talking with healthy machines; or is given a very limited set of routes via DHCP. Regardless of the method of restriction, the unhealthy client can access a few (presumably specially hardened) servers that have the resources needed for a client to fix itself. Steps 1 through 3 are then repeated. If the machine complies with policy, the client is granted full access to the network.

  4. On the client side, system health agents (SHA) and system health validators (SHV) are small pieces of code that ensure that the checks and validations are made on each individual client machine as necessary, as mentioned in step 1. Windows Vista includes default SHAs and SHVs that can be customized. Additionally, the NAP agent client piece takes the health status information provided by the SHAs and hands them to enforcement clients, or ECs, that actually do the enforcement on clients (limiting the scope of a DHCP route, verifying packet filters, and so on) depending on which enforcement mechanism you choose.

Take a look at Figure 11-13, which shows how all of the pieces of NAP fit together regardless of the type of enforcement you choose.

Figure 11-13. The basic architecture of NAP

11.2.2. Enforcement Mechanisms

There are several ways that NAP enforces its access limiting capabilities with clients. Let's take a look at the five currently supported within Windows Server 2008.

Through DHCP-based enforcement, clients attempt to lease an IP address from a DHCP server with Windows Server 2008 and the Network Policy Server roles installed. That server checks the health of the client, and, if the client meets those requirements, issues a valid IP lease. If the client is judged to be unhealthy, the DHCP server issues a very limited lease that contains just an IP address, a subnet mask, and a set of host routes limited in scope to a few remediation servers on the restricted network. There is no default gateway. Once the client has been remediated, it pings the DHCP/NAP server to perform another round of checks and only at that point is a full DHCP lease issued.

With VPN enforcement, the behavior of NAP is more like its predecessor, NAQC. When the VPN client starts a connection with the VPN concentrator or server on your perimeter network, the VPN server (also running Network Policy Server) or another machine with those required roles checks the health of the potential client. If the client is healthy, it gets unfettered access to the network, but if it is not healthy, a set of packet filters is placed on the connection to limit access to only those servers that host the items needed to remediate the situation. The VPN server can later remove the packet filters once the client is deemed healthy by the appropriate host.

Via 802.1x enforcement, you get the advantages of NAP for hard-wired clients in a more tamper-proof way than with DHCP-based enforcement. 802.1x is the IEEE standard that defines behavior at a port-level, meaning the actual place that a network cable is plugged in. By authenticating devices at the port level, you achieve nearly instantaneous NAP enforcements and also enable any sort of device to be protected and enforced, depending on how you look at it, when on the network, and not just Windows clients or remote machines entering through a VPN. The drawback is that hardware compatible with enforcing NAP at the port level is expensive; the switch must be able to communicate with the Network Policy Server machine via an encrypted EAP session in order to learn whether or not transmissions capabilities on a certain port should be enabled when a device is detected.

IPsec enforcement is an interesting, and perhaps most realistic, mechanism of all of the ones we've discussed so far. For it to be effective, you must deploy IPsec policies to either all of your sensitive machines or all of the hosts on your network that limit them to accepting incoming communications only from machines that have a health certificate. Once the policies are in place, you can configure NAP simply to issue valid health certificates to healthy clients; those clients can then communicate with any host. But unhealthy clients aren't issued health certificates, and even though they (a) have a valid IP address, (b) have no scope-limited routes in place, and (c) there is no hardware mechanism for disabling their communications, because of the IPsec policies that are in place, machines will simply drop communications from that unhealthy client—fingers in the ears, if you will. To use this enforcement mechanism, you'll need the Health Registration Authority, which obtains health certificates for those healthy clients from a certification authority.

Finally, the TS Gateway mechanism allows you to place NAP enforcement for your remote Terminal Services clients, although you cannot currently autoremediate these types of clients.

11.2.3. Implementing NAP in Phases

Since NAP is so far-reaching and has the power to turn your network-connected machines into standalone, deaf PCs (which might limit productivity in more than a few scenarios), it's best to deploy NAP in phases, so that (a) your users know what's happening and aren't interrupted by its enforcement, and (b) you have a sense of the effects NAP will have on the machines on your network. Here's a sample progression that I recommend when introducing NAP into your network.

Phase 1: Reporting only

In this phase, everything NAP does—checking clients, the results of health tests, what enforcement would have been put into place—is logged centrally, but no remediation or quarantining is actually performed. In this phase, the goal is to get a sense of what portion of your clients is unhealthy, how many users your eventual enforcement policy would affect, and what types of unhealthy states your clients are in. No one is cut off from network access in this phase, but you get a decent diagnostic of the health of the machines on your network.

Phase 2: Reporting and remediation

After at least a month, and preferably more, in Phase 1, you can now enable remediation in addition to the reporting. This will probably fix a not-insignificant portion of the clients that were reporting as unhealthy in Phase 1, limiting the pool of machines that will be cut off to a smaller number, though they are still not completely quarantined from the network.

Phase 3: Delayed enforcement

Once you have configured autoremediation and have monitored the reporting logs for a while, you can set up NAP to allow unhealthy clients to access the network for a limited amount of time. This helps clients who need patches to have access to the corporate network for enough time to download those patches before they are cut off. You can set up the delayed enforcement length to anything you choose; I suggest a window no smaller than a day and no longer than a week, since you want to reinforce the importance of healthy clients to your users without berating them endlessly about patching on what may be a busy workday for them. (Some organizations may choose to leave NAP in this mode permanently. I don't recommend this approach, as malware often needs very little time to infect your network, and if you are infested with a virus or worm while NAP is in deferred enforcement mode, what is the point of having NAP deployed in the first place?)

Phase 4: Immediate enforcement

Finally, after everyone has patched up and all of your regular clients have had a chance to remediate themselves and get healthy, simply remove the grace period that Phase 3 allows and make NAP cut off unhealthy clients immediately if they cannot be autoremediated. Remember that NAP can automatically fix simple problems with a machine's state—if its firewall is off, for example—so in this sense you are only cutting off machines with more complex health state issues.

11.2.4. Configuring Network Access Protection

Any NAP deployment is centralized on the Network Policy Server, so let's start there and configure NAP with the 802.1X enforcement mechanism. Make sure that the Network Policy and Access Services role is installed on your machine before proceeding.

  1. From Administrative Tools off the Start menu, choose Network Policy Server.

  2. Let's get acquainted with this environment. In the left pane of the Network Policy server application, you'll see the Policies node and the Network Access Protection node, as shown in Figure 11-14. Under the Policies node, you can configure health policies that will be used as the baseline that clients must meet. You can configure the SHVs and any remediation servers under the Network Access Protection node. Additionally, we will need a RADIUS setup since we are demonstrating 802.1X authentication; the hardware switches we are using will be RADIUS clients.

    Figure 11-14. The Network Policy Server console

  3. Expand RADIUS Clients and Servers in the left pane, and right-click on RADIUS Clients; select New RADIUS Client from the pop-up context menu.

  4. The New RADIUS Client screen appears, as shown in Figure 11-15. Here, we'll configure the switch that we are using, giving it a friendly name of "switch" and its IP address. Also, click the Generate radio button to have a shared secret automatically generated. You will need to copy and paste this secret into the switch's configuration as well. Click OK when finished.

    Figure 11-15. The New RADIUS Client screen

  5. Expand Policies in the right pane, and right-click on Health Policies; choose New from the pop-up context menu.

  6. The Create New Health Policy screen appears, as shown in Figure 11-16. Here, you define what a healthy baseline is. You would create one policy for compliant computers, using the "Client passes all SHV checks" option and the Windows Security Health Validator SHV, and then another policy for noncompliant computers using any of the other options in the Client SHV Checks list.

    Figure 11-16. The Create New Health Policy screen

  7. Expand Policies in the left pane, and right-click on Network Policies; select New from the pop-up context menu.

  8. The New Network Policy screen appears, as shown in Figure 11-17. Here, you name a network policy, use an "unspecified" type of network access server, and click Next.

    Figure 11-17. The New Network Policy screen

  9. The Specify Conditions page appears. Click the Add button to display the "Select condition" dialog, as shown in Figure 11-18. The health policies you defined in step 6 are used as conditions here, meaning that if one of the conditions (the health policies) matches the criteria, that network policy will be enforced. So, you would add one network policy for compliant, or healthy, machines, and another for noncompliant, or unhealthy, machines. Click Next.

    Figure 11-18. The "Select condition" dialog

  10. The Specify Access Permission page appears. Here, you choose whether to grant or deny access if the conditions you configured in the previous step are matched. Click Next.

  11. The Configure Authentication Methods screen appears, as shown in Figure 11-19. For 802.1x NAP enforcement, you need to add the Microsoft: Protected EAP (PEAP) option to the EAP Types list, so click the Add button and select it from the list. You can also choose to enable or disable some of the less secure authentication methods. Click Next.

    Figure 11-19. The Configure Authentication Methods

  12. The Configure Constraints page appears, as shown on Figure 11-20. Here, you can configure additional items relating to the network policy; if these items aren't satisfied, the NPS rejects access to the potential client. You can set up maximum idle time, maximum session time, a specific MAC address (called a Called Station ID in RADIUS terms), day and time restrictions, and the type of device being used. Click Next.

    Figure 11-20. The Configure Constraints page

  13. The Configure Settings screen appears. Here, you set up the specifics of the policy. We're particularly interested in the NAP Enforcement page, so click that in the left part of the screen and look in the resulting right part, shown in Figure 11-21. Here, you can choose what "phase" of NAP implementation should be used in conjunction with this policy—either full access, deferred enforcement, or limited access. Remember that this setting only falls under the scope of the policy you're creating, so you would choose "allow full network access" for your compliant policy and one of the other two options for your noncompliant policy. Also, for your noncompliant policy, you can tick the box under the "Auto remediation" section to set up automatic fixups where possible. Click Next, and then Finish on the next page of the wizard.

    Figure 11-21. The NAP Enforcement section of the Configure Settings page

  14. Now that your network and health policies are configured, set up the checks that the Windows System Health Validator will make by expanding the Network Access Protection node, clicking on System Health Validators, and double-clicking on Windows Security Health Validator in the right pane.

  15. The Windows Security Health Validator Properties screen appears. Under the Error Code Resolution section, you can choose how the SHV will respond if certain conditions are met, including timeouts, connection difficulties, and error codes. At the top, the Configure button will take you to where you can set up the specific checks that are made for clients. Click Configure.

  16. The Windows Security Health Validator screen appears, as shown in Figure 11-22. There are two tabs, one for Windows Vista, and one for Windows XP (Figure 11-23). Here is where you choose what you desire for firewall configuration, virus protection, spyware protection (for Windows Vista only), automatic updating, security update protection, and so on. Configure as desired, and click OK and then OK again to close out.

Figure 11-22. The Windows Security Health Validator screen, on the Windows Vista tab

Figure 11-23. The Windows Security Health Validator screen, on the Windows XP tab

At this point, you have configured everything on the server end. Remember, you need two network policies—one for compliant machines, one for noncompliant machines—and two health policies—again, one for compliant and the other for noncompliant computers. Once you have those four policies, and have configured the Windows Security Health Validator with the appropriate security criteria, you just need to deploy a couple of settings to your clients. The simplest way to do this is via Group Policy—you'll find the required settings under Computer Configuration, Windows Settings, Security Settings, and Network Access Protection. Your options, shown in Figure 11-23, are:

  • DHCP Quarantine Enforcement Client

  • Remote Access Quarantine Enforcement Client

  • IPsec Relying Party

  • TS Gateway Quarantine Enforcement Client

  • EAP Quarantine Enforcement Client

Just choose the appropriate client, each of which corresponds to one of the enforcement mechanisms covered earlier in this chapter, and set it to enabled, and you are ready to deploy.

11.2.5. Benefits and Drawbacks

NAP is a truly great addition to Windows Server 2008. The advantages are numerous. You get very effective protection against malware before it can infiltrate your network, it is included in the licensing cost of the server product, and it presents another way for your users to take security seriously. If their systems aren't up to snuff, they can't get their work done, so system integrity becomes a unified priority across both IT and the user community alike.

That's not to say NAP is a golden ticket to security nirvana; there are indeed some disadvantages. One is that there are deployment scenarios that jeopardize the effectiveness of NAP. For example, DHCP-based protection (where few routes are assigned before health verification) is easily bypassed on the client—by users who know what they're doing—by simply entering a static IP address and DNS/router information.

Two, the element of detection of network devices coming online can be difficult to implement securely, particularly solutions that rely on detecting broadcast packets. And finally, the best deployment method—802.1x protection with compatible switch or router hardware—is expensive and requires a lot of time to test and bring online.

Can you rely on NAP? I think you certainly can, so long as it is deployed correctly and as part of a multilayered solution to security. Defense in depth still applies—NAP is not an end-all, be-all answer to your problems, in my opinion. But NAP can and should play a very central role to your approach to security.


the_last_word-id10.html

11.3. The Last Word

In this chapter, I've looked at a two networking systems and techniques. DHCP combines with DNS to provide an automatic and self-managing way to provide IP services to your network. NAP is a great way to assess the integrity and quality of remote client machines before they have a chance to potentially infect your network with malicious software.

In the next chapter, I discuss how to scale your network services using software to provide load balancing and fault tolerance.


an_introduction_to_clustering_technolog.html

Chapter 12. An Introduction to Clustering Technologies

Clusters work to provide fault tolerance to a group of systems so that the services they provide are always available—or are at least unavailable for the least possible amount of time. Clusters also provide a single public-facing presence for a set of systems, which means end users and others who take advantage of the resources the cluster members provide aren't aware that the cluster comprises more than one machine. They see only a single, unified presence on the network. The dirty work of spreading the load among multiple machines is done behind the scenes by clustering software.

Microsoft provides two distinct types of clustering with Windows Server 2008:

Network load-balancing (NLB) clusters

These types of clusters allow for the high availability of services that rely on the TCP/IP protocol. You can have up to 32 machines running any edition of Windows Server 2008, Windows Server 2003, and Windows 2000 Server (with one minor exception, covered later in this chapter) participating in an NLB cluster.

True server clusters

Server clusters are the "premium" variety of highly available machines and consist of servers that can share workloads and processes across all members of the cluster (with some exceptions, as you'll see later in this chapter). Failed members of the cluster are automatically detected and the work being performed on them is moved to other, functional members of the cluster. True server clusters are supported in only the Enterprise and Datacenter editions of Windows Server 2008.

Where might each type of cluster be useful? For one, NLB is a very inexpensive way to achieve high TCP/IP availability for servers that run web services or other intranet or Internet applications. In effect, NLB acts as a balancer, distributing the load equally among multiple machines running their own, independent, isolated copies of IIS. NLB only protects against a server going offline, in that if a copy of IIS on a machine fails, the load will be redistributed among the other servers in the NLB cluster. Dynamic web pages that maintain sessions don't receive much benefit from this type of clustering because members of the cluster are running independent, unconnected versions of IIS and therefore cannot continue sessions created on other machines. However, much web content is static, and some implementations of dynamic web sites do not use sessions. Thus, chances are that NLB can improve the reliability of a site in production. Other services that can take advantage of NLB are IP-based applications such as FTP and VPN.

If you have business-critical applications that must be available at all times, true server clustering is a better fit. In true server clusters, all members of the cluster are aware of all the other members' shared resources. The members also maintain a "heartbeat" pulse to monitor the availability of services on their fellow members' machines. In the event of a resource or machine failure, the Windows Server 2008 clustering service can automatically hand off jobs, processes, and sessions begun on one machine to another machine. That isn't to say this swapping is completely transparent. When the application is moved or falls to another member in the cluster, client sessions are actually broken and re-established on the new owners of the resources. Although this happens relatively quickly, depending on the nature of your application it probably will not go unnoticed by your users. Often, your clients will be asked to re-authenticate to the new cluster owner. However, the cluster effectively acts as one unit and is completely fault-tolerant, and if you design the structure of your cluster correctly, you can avoid any one single point of failure. This decreases the chance that a single failed hardware or software component will bring your entire business-critical application to its knees.

In this chapter, I'll deal with each type of clustering individually, introducing concepts and showing you how to accomplish the most common administrative tasks.

12.1. Network Load-Balancing Clusters

NLB in Windows Server 2008 is accomplished by a special network driver that works between the drivers for the physical network adapter and the TCP/IP stack. This driver communicates with the NLB program (called wlbs.exe, for the Windows Load Balancing Service) running at the application layer—the same layer in the OSI model as the application you are clustering. NLB can work over FDDI- or Ethernet-based networks—even wireless networks—at up to gigabit speeds.

Why would you choose NLB? For a few reasons:

  • NLB is an inexpensive way to make a TCP/IP-dependent application somewhat fault tolerant, without the expense of maintaining a true server cluster with fault-tolerant components. No special hardware is required to create an NLB cluster. It's also cheap hardware-wise because you need only two network adapters to mitigate a single point of failure.

  • The "shared nothing" approach—meaning each server owns its own resources and doesn't share them with the cluster for management purposes, so to speak—is easier to administer and less expensive to implement, although there is always some data lag between servers while information is transferred among the members. (This approach also has its drawbacks, however, because NLB can only direct clients to backend servers or to independently replicated data.)

  • Fault tolerance is provided at the network layer, ensuring that network connections are not directed to a server that is down.

  • Performance is improved for your web or FTP resource because load is distributed automatically among all members of the NLB cluster.

NLB works in a seemingly simple way: all computers in an NLB cluster have their own IP address just like all networked machines do these days, but they also share a single, cluster-aware IP address that allows each member to answer requests on that IP address. NLB takes care of the IP address conflict problem and allows clients who connect to that shared IP address to be directed automatically to one of the cluster members.

NLB clusters support a maximum of 32 cluster members, meaning that no more than 32 machines can participate in the load-balancing and sharing features. Most applications that have a load over and above what a single 32-member cluster can handle take advantage of multiple clusters and use some sort of DNS load-balancing technique or device to distribute requests to the multiple clusters individually.

When considering an NLB cluster for your application, ask yourself the following questions: how will failure affect application and other cluster members? If you are running a high-volume e-commerce site and one member of your cluster fails, are the other servers in the cluster adequately equipped to handle the extra traffic from the failed server? A lot of cluster implementations miss this important concept and later see the consequence—a cascading failure caused by a perpetually growing load failed over onto servers perpetually failing from overload. Such a scenario is very common and entirely defeats the true purpose of a cluster. Avoid this by ensuring that all cluster members have sufficient hardware specifications to handle additional traffic when necessary.

Also examine the kind of application you are planning on clustering. What types of resources does it use extensively? Different types of applications stretch different components of the systems participating in a cluster. Most enterprise applications have some sort of performance testing utility; take advantage of any that your application offers in a testing lab and determine where potential bottlenecks might lie.

Web applications, Terminal Services, and Microsoft's ISA Server 2004 product can take advantage of NLB clustering.

It's important to be aware that NLB is unable to detect whether a service on the server has crashed but not the machine itself, so it could direct a user to a system that can't offer the requested service.

12.1.1. NLB Terminology

Before we dig deeper into our coverage of NLB, let's discuss a few terms that you will see. Some of the most common NLB technical terms are as follows:

NLB driver

This driver resides in memory on all members of a cluster and is instrumental in choosing which cluster node will accept and process the packet. Coupled with port rules and client affinity (all defined on the following pages), the driver decides whether to send the packet up the TCP/IP stack to the application on the current machine, or to pass on the packet because another server in the cluster will handle it.

Unicast mode

In unicast mode, NLB hosts send packets to a single recipient.

Multicast mode

In multicast mode, NLB hosts send packets to multiple recipients at the same time.

Port rules

Port rules define the applications on which NLB will "work its magic," so to speak. Certain applications listen for packets sent to them on specific port numbers—for example, web servers usually listen for packets addressed to TCP port 80. You use port rules to instruct NLB to answer requests and load-balance them.

Affinity

Affinity is a setting that controls whether traffic that originated from a certain cluster member should be returned to that particular cluster node. Effectively, this controls which cluster nodes will accept what types of traffic.

12.1.2. NLB Operation Styles and Modes

An NLB cluster can operate in four different ways:

  • With a single network card in each server, using unicast mode

  • With multiple network cards in each server, using unicast mode

  • With a single network card in each server, using multicast mode

  • With multiple network cards in each server, using multicast mode

You cannot mix unicast and multicast modes among the members of your cluster. All members must be running either unicast or multicast mode, although the number of cards in each member can differ.

The following sections detail each mode of operation.

12.1.2.1. Single card in each server in unicast mode

A single network card in each server operating in unicast mode requires less hardware, so obviously it's less expensive than maintaining multiple NICs in each cluster member. However, network performance is reduced because of the overhead of using the NLB driver over only one network card—cluster traffic still has to pass through one adapter, which can be easily saturated, and is additionally run through the NLB driver for load balancing. This can create real hang-ups in network performance.

An additional drawback is that cluster hosts can't communicate with one another through the usual methods, such as pinging—it's not supported using just a single adapter in unicast mode. This has to do with MAC address problems and the Address Resolution Protocol (ARP). Similarly, NetBIOS isn't supported in this mode either.

This configuration is shown in Figure 12-1.

Figure 12-1. Single card in each server in unicast mode

12.1.2.2. Multiple cards in each server in unicast mode

This is usually the preferred configuration for NLB clusters because it enables the most functionality for the price in equipment. However, it is inherently more expensive because of the second network adapter in each cluster member. Having that second adapter, though, means that there are no limitations among regular communications between members of the NLB cluster. Additionally, NetBIOS is supported through the first configured network adapter for simpler name resolution. All types and brands of routers support this method, and having more than one adapter in a machine removes bottlenecks found with only one adapter.

This configuration is shown in Figure 12-2.

Figure 12-2. Multiple cards in each server in unicast mode

12.1.2.3. Single card in each server in multicast mode

Using a single card in multicast mode allows members of the cluster to communicate with one another normally, but network performance is still reduced because you are still using only a single network card. Router support might be spotty because of the need to support multicast MAC addresses, and NetBIOS isn't supported within the cluster.

This configuration is shown in Figure 12-3.

Figure 12-3. Single card in each server in multicast mode

12.1.2.4. Multiple cards in each server in multicast mode

This mode is used when some hosts have one network card and others have more than one, and all require regular communications among themselves. In this case, every host needs to be in multicast mode because all hosts in an NLB cluster must be running the same mode. You might run into problems with router support using this model, but with careful planning you can make it work.

This configuration is shown in Figure 12-4.

Figure 12-4. Multiple cards in each server in multicast mode

12.1.3. Port Rules

NLB clusters feature the ability to set port rules, which are simply ways to instruct Windows Server 2008 to handle each TCP/IP port's cluster network traffic. NLB does this filtering in three modes: disabled, where all network traffic for the associated port or ports will be blocked; single host mode, where network traffic from an associated port or ports should be handled by one specific machine in the cluster (still with fault tolerance features enabled); and multiple hosts mode (the default mode), where multiple hosts in the cluster can handle port traffic for a specific port or range of ports.

The rules contain the following parameters:

  • The virtual IP address to which the rule should be applied

  • The port range for which this rule should be applied

  • The protocols for which this rule should apply, including TCP, UDP, or both

  • The filtering mode that specifies how the cluster handles traffic described by the port range and protocols, as discussed just before this list

In addition, you can select one of three options for client affinity (which is, simply put, the types of clients from which the cluster will accept traffic): None, Single, and Class C. Single and Class C are used to ensure that all network traffic from a particular client is directed to the same cluster host. None indicates that there is no client affinity, and traffic can go to any cluster host.

When using port rules in an NLB cluster, it's important to remember that the number and content of port rules must match exactly on all members of the cluster. When joining a node to an NLB cluster, if the number or content of port rules on the joining node doesn't match the number or content of rules on the existing member nodes, the joining member will be denied membership to the cluster. You need to synchronize these port rules manually across all members of the NLB cluster.

12.1.4. Creating an NLB Cluster

To create a new NLB cluster, use the Network Load Balancing Manager and follow these instructions:

  1. From Server Manager, click on Features in the left pane, and then click Add Features in the main window.

  2. On the Select Features screen, check the Network Load Balancing box and click Next.

  3. On the confirmation screen, acknowledge the possible restart at the end of the setup procedure and then click Install.

  4. Once the installation is complete, from the Start menu, point to Administrative Tools and click on Network Load Balancing Manager.

  5. From the Cluster menu, select New.

  6. The New Cluster: Connect screen appears, as shown in Figure 12-5. Here, enter the IP address or DNS name of the host that will be added to the cluster first. Then click Connect. The list in the white box at the bottom of the screen will be populated with the network interfaces available for creating a cluster. Click the public interface, and click Next.

    Figure 12-5. The New Cluster: Connect screen

  7. The Host Parameters screen appears, as seen in Figure 12-6. On this screen, enter the priority for the host of the cluster, the dedicated IP that you'll use to connect to this specific member node, and the initial state of this host when you first boot up Windows Server 2008. Click Finish to complete the process.

    Figure 12-6. The Host Parameters screen

  8. The Cluster IP Addresses screen appears. Here, enter any additional IP addresses the cluster might need. You might want this for specific applications, but it's not required for a standard setup. Click Next when you've finished, or if there are no other IP addresses by which this cluster will be known.

  9. The Cluster Parameters screen appears, as shown in Figure 12-7. Here, you specify the name of the cluster and the IP address information by which other computers will address the cluster. Enter the IP address, subnet mask, and full Internet name (i.e., the canonical DNS name). Also choose unicast or multicast mode, as discussed in the previous section. Click Next to continue.

    Figure 12-7. The Cluster Parameters screen

    Enabling remote control of your cluster—meaning being able to load the NLB Manager client on other systems and connect remotely to the cluster—is not recommended because it is a large security risk. Avoid this unless absolutely necessary, and use other tools such as Terminal Services or Remote Desktop.

  10. The Port Rules screen appears, as shown in Figure 12-8. Enter and configure any port rules you'd like, as discussed in the previous section, and then click Next when you're done.

Figure 12-8. The Port Rules screen

The NLB cluster is created, and the first node is configured and added to the cluster.

12.1.5. Adding Other Nodes to the Cluster

Chances are good that you want to add another machine to the cluster to take advantage of load balancing. To add a new node to an existing cluster, use this procedure:

  1. From the Administrative Tools menu, open the Network Load Balancing Manager console.

  2. In the left pane, right-click the cluster to which you'd like to add a node, and then select "Add Host to Cluster" from the pop-up context menu.

  3. The Connect screen appears. Type in the DNS name or the IP address of the host to join to the cluster. Click the Connect button to populate the list of network interfaces on that host, and then select the card that will host public traffic and click Next.

  4. The Host Parameters screen appears. Enter the appropriate priority of the host (a setting that allows you to specify which machine should get the largest number of requests—useful if you have two machines in a cluster and one is more powerful than the other), the dedicated IP address of this member of the cluster, and the initial state of the potential member node when Windows Server 2008 first boots. You can set the initial state to Started, Stopped, or Suspended.

  5. Click Finish to complete the procedure.

The node is then added to the selected NLB cluster. You can tell the process is finished when the node's status, as indicated within the Network Load Balancing Manager console, says "Converged."

12.1.6. Removing Nodes from the Cluster

For various reasons, you might need to remove a joined node from the cluster—to perform system maintenance, for example, or to replace the node with a newer, fresher, more powerful machine. You must remove an NLB cluster member gracefully. To do so, perform the steps that follow.

  1. From the Administrative Tools menu, open the Network Load Balancing Manager console.

  2. Right-click Network Load Balancing Clusters in the left pane, and from the pop-up context menu, select "Connect to Existing."

  3. Enter the host to connect to and click Connect. Then, at the bottom of the Connect screen, select the cluster on the host, and click Next.

  4. Finally, back in the console, right-click the node you want to remove in the left pane, and select Delete Host from the pop-up context menu.

This removes the node.

If you are only upgrading a node of the cluster and don't want to permanently remove a node from a cluster, you can use a couple of techniques to gradually reduce traffic to the host and then make it available for upgrading. The first is to perform a drainstop on the cluster host to be upgraded. Drainstopping prevents new clients from accessing the cluster while allowing existing clients to continue until they have completed their current operations. After all current clients have finished their operations, cluster operations on that node cease.

To perform a drainstop, follow these steps:

  1. Open a command-line window.

  2. From the command line, type wlbs drainstop <IP Address>:<hostID>, replacing the variable with the cluster IP address and the HostID with the unique number set in the Host Parameters tab in NLB properties.

For example, if my cluster was located at 192.168.0.14 and I wanted to upgrade node 2, I would enter the following command:

Wlbs drainstop 192.168.0.14:2

In addition, you can configure the "Default state" of the "Initial host state" to Stopped as you learned in the previous section. This way, that particular node cannot rejoin the cluster during the upgrade process. Then you can verify that your upgrade was completed smoothly before the cluster is rejoined and clients begin accessing it.

12.1.7. Performance Optimization

NLB clusters often have problems with switches. Switches differ from hubs in that data transmission among client computers connected to a hub is point-to-point: the switch keeps a cache of the MAC address of all machines and sends traffic directly to its endpoint, whereas hubs simply broadcast all data to all connected machines and those machines must pick up their own data. However, switches work against NLB clusters because every packet of data sent to the cluster passes through all the ports on the switch to which members of the cluster are attached because all cluster members share the same IP address, as you've already learned. Obviously, this can be a problem.

To avert this problem, you can choose from a few workarounds:

  • Use a premium hub to connect the NICs of all cluster members, and then use the uplink feature on the hub to link the hub to the switch.

  • Enable unicast mode as opposed to multicast mode. Remember, you need to make this change on all members of the cluster.

  • If possible, have all hosts on the same subnet, and then connect them to an isolated switch or configure them to connect in a single VLAN if you have that capability.

  • Disable the source MAC masking feature in the Registry. The source MAC masking feature is used to change the MAC address of traffic originating from the cluster from the individual cluster node's MAC address to the MAC address of the server. In multicast mode in switching environments, this can flood switching ports, so disabling this feature will work around that problem. Change the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WLBS\Parameters\MaskSourceMAC Registry value from 1 to 0. Restart all members of the cluster after making this change.


network_load-balancing_clusters.html

Chapter 12. An Introduction to Clustering Technologies

Clusters work to provide fault tolerance to a group of systems so that the services they provide are always available—or are at least unavailable for the least possible amount of time. Clusters also provide a single public-facing presence for a set of systems, which means end users and others who take advantage of the resources the cluster members provide aren't aware that the cluster comprises more than one machine. They see only a single, unified presence on the network. The dirty work of spreading the load among multiple machines is done behind the scenes by clustering software.

Microsoft provides two distinct types of clustering with Windows Server 2008:

Network load-balancing (NLB) clusters

These types of clusters allow for the high availability of services that rely on the TCP/IP protocol. You can have up to 32 machines running any edition of Windows Server 2008, Windows Server 2003, and Windows 2000 Server (with one minor exception, covered later in this chapter) participating in an NLB cluster.

True server clusters

Server clusters are the "premium" variety of highly available machines and consist of servers that can share workloads and processes across all members of the cluster (with some exceptions, as you'll see later in this chapter). Failed members of the cluster are automatically detected and the work being performed on them is moved to other, functional members of the cluster. True server clusters are supported in only the Enterprise and Datacenter editions of Windows Server 2008.

Where might each type of cluster be useful? For one, NLB is a very inexpensive way to achieve high TCP/IP availability for servers that run web services or other intranet or Internet applications. In effect, NLB acts as a balancer, distributing the load equally among multiple machines running their own, independent, isolated copies of IIS. NLB only protects against a server going offline, in that if a copy of IIS on a machine fails, the load will be redistributed among the other servers in the NLB cluster. Dynamic web pages that maintain sessions don't receive much benefit from this type of clustering because members of the cluster are running independent, unconnected versions of IIS and therefore cannot continue sessions created on other machines. However, much web content is static, and some implementations of dynamic web sites do not use sessions. Thus, chances are that NLB can improve the reliability of a site in production. Other services that can take advantage of NLB are IP-based applications such as FTP and VPN.

If you have business-critical applications that must be available at all times, true server clustering is a better fit. In true server clusters, all members of the cluster are aware of all the other members' shared resources. The members also maintain a "heartbeat" pulse to monitor the availability of services on their fellow members' machines. In the event of a resource or machine failure, the Windows Server 2008 clustering service can automatically hand off jobs, processes, and sessions begun on one machine to another machine. That isn't to say this swapping is completely transparent. When the application is moved or falls to another member in the cluster, client sessions are actually broken and re-established on the new owners of the resources. Although this happens relatively quickly, depending on the nature of your application it probably will not go unnoticed by your users. Often, your clients will be asked to re-authenticate to the new cluster owner. However, the cluster effectively acts as one unit and is completely fault-tolerant, and if you design the structure of your cluster correctly, you can avoid any one single point of failure. This decreases the chance that a single failed hardware or software component will bring your entire business-critical application to its knees.

In this chapter, I'll deal with each type of clustering individually, introducing concepts and showing you how to accomplish the most common administrative tasks.

12.1. Network Load-Balancing Clusters

NLB in Windows Server 2008 is accomplished by a special network driver that works between the drivers for the physical network adapter and the TCP/IP stack. This driver communicates with the NLB program (called wlbs.exe, for the Windows Load Balancing Service) running at the application layer—the same layer in the OSI model as the application you are clustering. NLB can work over FDDI- or Ethernet-based networks—even wireless networks—at up to gigabit speeds.

Why would you choose NLB? For a few reasons:

  • NLB is an inexpensive way to make a TCP/IP-dependent application somewhat fault tolerant, without the expense of maintaining a true server cluster with fault-tolerant components. No special hardware is required to create an NLB cluster. It's also cheap hardware-wise because you need only two network adapters to mitigate a single point of failure.

  • The "shared nothing" approach—meaning each server owns its own resources and doesn't share them with the cluster for management purposes, so to speak—is easier to administer and less expensive to implement, although there is always some data lag between servers while information is transferred among the members. (This approach also has its drawbacks, however, because NLB can only direct clients to backend servers or to independently replicated data.)

  • Fault tolerance is provided at the network layer, ensuring that network connections are not directed to a server that is down.

  • Performance is improved for your web or FTP resource because load is distributed automatically among all members of the NLB cluster.

NLB works in a seemingly simple way: all computers in an NLB cluster have their own IP address just like all networked machines do these days, but they also share a single, cluster-aware IP address that allows each member to answer requests on that IP address. NLB takes care of the IP address conflict problem and allows clients who connect to that shared IP address to be directed automatically to one of the cluster members.

NLB clusters support a maximum of 32 cluster members, meaning that no more than 32 machines can participate in the load-balancing and sharing features. Most applications that have a load over and above what a single 32-member cluster can handle take advantage of multiple clusters and use some sort of DNS load-balancing technique or device to distribute requests to the multiple clusters individually.

When considering an NLB cluster for your application, ask yourself the following questions: how will failure affect application and other cluster members? If you are running a high-volume e-commerce site and one member of your cluster fails, are the other servers in the cluster adequately equipped to handle the extra traffic from the failed server? A lot of cluster implementations miss this important concept and later see the consequence—a cascading failure caused by a perpetually growing load failed over onto servers perpetually failing from overload. Such a scenario is very common and entirely defeats the true purpose of a cluster. Avoid this by ensuring that all cluster members have sufficient hardware specifications to handle additional traffic when necessary.

Also examine the kind of application you are planning on clustering. What types of resources does it use extensively? Different types of applications stretch different components of the systems participating in a cluster. Most enterprise applications have some sort of performance testing utility; take advantage of any that your application offers in a testing lab and determine where potential bottlenecks might lie.

Web applications, Terminal Services, and Microsoft's ISA Server 2004 product can take advantage of NLB clustering.

It's important to be aware that NLB is unable to detect whether a service on the server has crashed but not the machine itself, so it could direct a user to a system that can't offer the requested service.

12.1.1. NLB Terminology

Before we dig deeper into our coverage of NLB, let's discuss a few terms that you will see. Some of the most common NLB technical terms are as follows:

NLB driver

This driver resides in memory on all members of a cluster and is instrumental in choosing which cluster node will accept and process the packet. Coupled with port rules and client affinity (all defined on the following pages), the driver decides whether to send the packet up the TCP/IP stack to the application on the current machine, or to pass on the packet because another server in the cluster will handle it.

Unicast mode

In unicast mode, NLB hosts send packets to a single recipient.

Multicast mode

In multicast mode, NLB hosts send packets to multiple recipients at the same time.

Port rules

Port rules define the applications on which NLB will "work its magic," so to speak. Certain applications listen for packets sent to them on specific port numbers—for example, web servers usually listen for packets addressed to TCP port 80. You use port rules to instruct NLB to answer requests and load-balance them.

Affinity

Affinity is a setting that controls whether traffic that originated from a certain cluster member should be returned to that particular cluster node. Effectively, this controls which cluster nodes will accept what types of traffic.

12.1.2. NLB Operation Styles and Modes

An NLB cluster can operate in four different ways:

  • With a single network card in each server, using unicast mode

  • With multiple network cards in each server, using unicast mode

  • With a single network card in each server, using multicast mode

  • With multiple network cards in each server, using multicast mode

You cannot mix unicast and multicast modes among the members of your cluster. All members must be running either unicast or multicast mode, although the number of cards in each member can differ.

The following sections detail each mode of operation.

12.1.2.1. Single card in each server in unicast mode

A single network card in each server operating in unicast mode requires less hardware, so obviously it's less expensive than maintaining multiple NICs in each cluster member. However, network performance is reduced because of the overhead of using the NLB driver over only one network card—cluster traffic still has to pass through one adapter, which can be easily saturated, and is additionally run through the NLB driver for load balancing. This can create real hang-ups in network performance.

An additional drawback is that cluster hosts can't communicate with one another through the usual methods, such as pinging—it's not supported using just a single adapter in unicast mode. This has to do with MAC address problems and the Address Resolution Protocol (ARP). Similarly, NetBIOS isn't supported in this mode either.

This configuration is shown in Figure 12-1.

Figure 12-1. Single card in each server in unicast mode

12.1.2.2. Multiple cards in each server in unicast mode

This is usually the preferred configuration for NLB clusters because it enables the most functionality for the price in equipment. However, it is inherently more expensive because of the second network adapter in each cluster member. Having that second adapter, though, means that there are no limitations among regular communications between members of the NLB cluster. Additionally, NetBIOS is supported through the first configured network adapter for simpler name resolution. All types and brands of routers support this method, and having more than one adapter in a machine removes bottlenecks found with only one adapter.

This configuration is shown in Figure 12-2.

Figure 12-2. Multiple cards in each server in unicast mode

12.1.2.3. Single card in each server in multicast mode

Using a single card in multicast mode allows members of the cluster to communicate with one another normally, but network performance is still reduced because you are still using only a single network card. Router support might be spotty because of the need to support multicast MAC addresses, and NetBIOS isn't supported within the cluster.

This configuration is shown in Figure 12-3.

Figure 12-3. Single card in each server in multicast mode

12.1.2.4. Multiple cards in each server in multicast mode

This mode is used when some hosts have one network card and others have more than one, and all require regular communications among themselves. In this case, every host needs to be in multicast mode because all hosts in an NLB cluster must be running the same mode. You might run into problems with router support using this model, but with careful planning you can make it work.

This configuration is shown in Figure 12-4.

Figure 12-4. Multiple cards in each server in multicast mode

12.1.3. Port Rules

NLB clusters feature the ability to set port rules, which are simply ways to instruct Windows Server 2008 to handle each TCP/IP port's cluster network traffic. NLB does this filtering in three modes: disabled, where all network traffic for the associated port or ports will be blocked; single host mode, where network traffic from an associated port or ports should be handled by one specific machine in the cluster (still with fault tolerance features enabled); and multiple hosts mode (the default mode), where multiple hosts in the cluster can handle port traffic for a specific port or range of ports.

The rules contain the following parameters:

  • The virtual IP address to which the rule should be applied

  • The port range for which this rule should be applied

  • The protocols for which this rule should apply, including TCP, UDP, or both

  • The filtering mode that specifies how the cluster handles traffic described by the port range and protocols, as discussed just before this list

In addition, you can select one of three options for client affinity (which is, simply put, the types of clients from which the cluster will accept traffic): None, Single, and Class C. Single and Class C are used to ensure that all network traffic from a particular client is directed to the same cluster host. None indicates that there is no client affinity, and traffic can go to any cluster host.

When using port rules in an NLB cluster, it's important to remember that the number and content of port rules must match exactly on all members of the cluster. When joining a node to an NLB cluster, if the number or content of port rules on the joining node doesn't match the number or content of rules on the existing member nodes, the joining member will be denied membership to the cluster. You need to synchronize these port rules manually across all members of the NLB cluster.

12.1.4. Creating an NLB Cluster

To create a new NLB cluster, use the Network Load Balancing Manager and follow these instructions:

  1. From Server Manager, click on Features in the left pane, and then click Add Features in the main window.

  2. On the Select Features screen, check the Network Load Balancing box and click Next.

  3. On the confirmation screen, acknowledge the possible restart at the end of the setup procedure and then click Install.

  4. Once the installation is complete, from the Start menu, point to Administrative Tools and click on Network Load Balancing Manager.

  5. From the Cluster menu, select New.

  6. The New Cluster: Connect screen appears, as shown in Figure 12-5. Here, enter the IP address or DNS name of the host that will be added to the cluster first. Then click Connect. The list in the white box at the bottom of the screen will be populated with the network interfaces available for creating a cluster. Click the public interface, and click Next.

    Figure 12-5. The New Cluster: Connect screen

  7. The Host Parameters screen appears, as seen in Figure 12-6. On this screen, enter the priority for the host of the cluster, the dedicated IP that you'll use to connect to this specific member node, and the initial state of this host when you first boot up Windows Server 2008. Click Finish to complete the process.

    Figure 12-6. The Host Parameters screen

  8. The Cluster IP Addresses screen appears. Here, enter any additional IP addresses the cluster might need. You might want this for specific applications, but it's not required for a standard setup. Click Next when you've finished, or if there are no other IP addresses by which this cluster will be known.

  9. The Cluster Parameters screen appears, as shown in Figure 12-7. Here, you specify the name of the cluster and the IP address information by which other computers will address the cluster. Enter the IP address, subnet mask, and full Internet name (i.e., the canonical DNS name). Also choose unicast or multicast mode, as discussed in the previous section. Click Next to continue.

    Figure 12-7. The Cluster Parameters screen

    Enabling remote control of your cluster—meaning being able to load the NLB Manager client on other systems and connect remotely to the cluster—is not recommended because it is a large security risk. Avoid this unless absolutely necessary, and use other tools such as Terminal Services or Remote Desktop.

  10. The Port Rules screen appears, as shown in Figure 12-8. Enter and configure any port rules you'd like, as discussed in the previous section, and then click Next when you're done.

Figure 12-8. The Port Rules screen

The NLB cluster is created, and the first node is configured and added to the cluster.

12.1.5. Adding Other Nodes to the Cluster

Chances are good that you want to add another machine to the cluster to take advantage of load balancing. To add a new node to an existing cluster, use this procedure:

  1. From the Administrative Tools menu, open the Network Load Balancing Manager console.

  2. In the left pane, right-click the cluster to which you'd like to add a node, and then select "Add Host to Cluster" from the pop-up context menu.

  3. The Connect screen appears. Type in the DNS name or the IP address of the host to join to the cluster. Click the Connect button to populate the list of network interfaces on that host, and then select the card that will host public traffic and click Next.

  4. The Host Parameters screen appears. Enter the appropriate priority of the host (a setting that allows you to specify which machine should get the largest number of requests—useful if you have two machines in a cluster and one is more powerful than the other), the dedicated IP address of this member of the cluster, and the initial state of the potential member node when Windows Server 2008 first boots. You can set the initial state to Started, Stopped, or Suspended.

  5. Click Finish to complete the procedure.

The node is then added to the selected NLB cluster. You can tell the process is finished when the node's status, as indicated within the Network Load Balancing Manager console, says "Converged."

12.1.6. Removing Nodes from the Cluster

For various reasons, you might need to remove a joined node from the cluster—to perform system maintenance, for example, or to replace the node with a newer, fresher, more powerful machine. You must remove an NLB cluster member gracefully. To do so, perform the steps that follow.

  1. From the Administrative Tools menu, open the Network Load Balancing Manager console.

  2. Right-click Network Load Balancing Clusters in the left pane, and from the pop-up context menu, select "Connect to Existing."

  3. Enter the host to connect to and click Connect. Then, at the bottom of the Connect screen, select the cluster on the host, and click Next.

  4. Finally, back in the console, right-click the node you want to remove in the left pane, and select Delete Host from the pop-up context menu.

This removes the node.

If you are only upgrading a node of the cluster and don't want to permanently remove a node from a cluster, you can use a couple of techniques to gradually reduce traffic to the host and then make it available for upgrading. The first is to perform a drainstop on the cluster host to be upgraded. Drainstopping prevents new clients from accessing the cluster while allowing existing clients to continue until they have completed their current operations. After all current clients have finished their operations, cluster operations on that node cease.

To perform a drainstop, follow these steps:

  1. Open a command-line window.

  2. From the command line, type wlbs drainstop <IP Address>:<hostID>, replacing the variable with the cluster IP address and the HostID with the unique number set in the Host Parameters tab in NLB properties.

For example, if my cluster was located at 192.168.0.14 and I wanted to upgrade node 2, I would enter the following command:

Wlbs drainstop 192.168.0.14:2

In addition, you can configure the "Default state" of the "Initial host state" to Stopped as you learned in the previous section. This way, that particular node cannot rejoin the cluster during the upgrade process. Then you can verify that your upgrade was completed smoothly before the cluster is rejoined and clients begin accessing it.

12.1.7. Performance Optimization

NLB clusters often have problems with switches. Switches differ from hubs in that data transmission among client computers connected to a hub is point-to-point: the switch keeps a cache of the MAC address of all machines and sends traffic directly to its endpoint, whereas hubs simply broadcast all data to all connected machines and those machines must pick up their own data. However, switches work against NLB clusters because every packet of data sent to the cluster passes through all the ports on the switch to which members of the cluster are attached because all cluster members share the same IP address, as you've already learned. Obviously, this can be a problem.

To avert this problem, you can choose from a few workarounds:

  • Use a premium hub to connect the NICs of all cluster members, and then use the uplink feature on the hub to link the hub to the switch.

  • Enable unicast mode as opposed to multicast mode. Remember, you need to make this change on all members of the cluster.

  • If possible, have all hosts on the same subnet, and then connect them to an isolated switch or configure them to connect in a single VLAN if you have that capability.

  • Disable the source MAC masking feature in the Registry. The source MAC masking feature is used to change the MAC address of traffic originating from the cluster from the individual cluster node's MAC address to the MAC address of the server. In multicast mode in switching environments, this can flood switching ports, so disabling this feature will work around that problem. Change the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WLBS\Parameters\MaskSourceMAC Registry value from 1 to 0. Restart all members of the cluster after making this change.


server_clustering.html

12.2. Server Clustering

If an NLB cluster is too limited in functionality for you, investigate a true server cluster. In a true server cluster, a group of machines have a single identity and work in tandem to manage and, in the event of failure, migrate applications away from problematic nodes and onto functional nodes. The nodes of the cluster use a common, shared resource database and log storage facility provided by a physical storage device that is located on a hardware bus shared by all members of the cluster.

The shared data facility does not support IDE disks, software RAID (including Windows-based dynamic RAID), dynamic disks or volumes, the EFS, mounted volumes and reparse points, or remote storage devices such as tape backup drives.

Windows Server 2008 offers a single mixed-mode type of clustering that replaces the old quorum and majority node set clusters you might be familiar with from Windows Server 2003. In this new hybrid quorum model, there is a concept of "votes," and a cluster is by default designed to tolerate the loss of a single vote. Each node of a cluster gets a "vote," as does the storage source for a cluster; thus, if the quorum disk is lost, the cluster continues since only a single vote is no longer present. To re-create the old Windows Server 2003 model with a shared quorum disk as the absolute must-have resource for a cluster, you can simply assign a vote to the quorum disk (now called a witness disk) and no votes for each node of the cluster. Better still, the witness disk doesn't even have to be a physical disk at all: it can be a file share over a network, and one share can even function as a witness for multiple server clusters.

Essentially, the concept of votes was introduced, as you can see, to allow more flexibility in configuring clusters and their tolerance of failure than was previously possible.

Clusters manage failure using failover and failback policies (that is, unless you are using a single node cluster). Failover policies dictate the behavior of cluster resources when a failure occurs—which nodes the failed resources can migrate to, the timing of a failover after the failure, and other properties. A failback policy specifies what will happen when the failed node comes back online again. How quickly should the migrated resources and applications be returned to the original node? Should the migrated objects stay at their new home? Should the repaired node be ignored? You can specify all of this behavior through policies.

12.2.1. Cluster Terminology

A few terms have specific meanings when used in the context of clustering. They include:

Networks

Networks, also called interconnects, are the ways in which clusters communicate with other members (nodes) of the cluster and the public network. The network is the most common point of failure in cluster nodes; always make network cards redundant in a true server cluster.

Nodes

Nodes are the actual members of the cluster. The clustering service supports only member nodes running Windows Server 2008 Enterprise Edition or Datacenter Edition. Other requirements include the TCP/IP protocol, connection to a shared storage device, and at least one interconnect to other nodes.

Resources

Resources are simply anything that can be managed by the cluster service and that the cluster can use to provide a service to clients. Resources can be logical or physical and can represent real devices, network services, or filesystem objects. A special type of physical disk resource called the quorum disk provides a place for the cluster service to store recovery logs and its own database. I'll provide a list of some resources in the next section.

Groups

Resources can be collected into resource groups, which are simply units by which failover and failback policy can be specified. A group's resources all fail over and fail back according to a policy applied to the group, and all the resources move to other nodes together upon a failure.

Quorum

A quorum is the shared storage facility that keeps the cluster resource database and logs. As noted earlier in this section, this needs to be a SCSI-based real drive with no special software features.

12.2.2. Types of Services and Applications

A variety of services and applications can be clustered out of the box by the failover clustering service in Windows Server 2008. They include:

DFS Namespace Server

This role hosts DFS shared folders within a cluster. See Chapter 3 for more information on DFS.

DHCP

This type of resource manages the DHCP service, which can be used in a cluster to assure availability to client computers. The DHCP database must reside on the shared cluster storage device, otherwise known as the quorum disk.

Distributed Transaction Coordinator (DTC)

DTC coordinates disk and memory operations among applications that reside across multiple machines, most commonly in the context of database servers and applications.

File Share

Shares on servers can be made redundant and fault-tolerant aside from using the DFS service (covered in Chapter 3) by using the File Share resource inside a cluster. You can put shared files and folders into a cluster as a standard file share with only one level of folder visibility, as a shared subfolder system with the root folder and all immediate subfolders shared with distinct names.

Generic Application

Applications that are not cluster-aware (meaning they don't have their own fault-tolerance features that can hook into the cluster service) can be managed within a cluster using the Generic Application resource. Applications managed in this way must be able to store any data they create in a custom location, use TCP/IP to connect clients, and be able to receive clients attempting to reconnect in the event of a failure. You can install a cluster-unaware application onto the shared cluster storage device; that way, you need to install the program only once and then the entire cluster can use it.

Generic Script

This resource type is used to manage operating system scripts. You can cluster login scripts and account provisioning scripts, for example, if you regularly use those functions and need their continued availability even in the event of a machine failure. Hotmail's account provisioning functions, for instance, are a good fit for this feature, so users can sign up for the service at all hours of the day.

Generic Service

You can manage Windows Server 2008 core services, if you require them to be highly available, using the Generic Service resource type. Only the bundled services are supported.

Internet Storage Name Service (iSNS) Server

This service polls the network for iSCSI targets and populates a list of them for other computers.

Message Queuing

Message queuing allows applications that run across multiple machines to synchronize communications between computers and with machines that are on different networks or that are offline.

Other Server

This type of service provides an open access point for applications to talk to the cluster. You'll need to manually configure the application to be clustered after adding this service to the cluster.

Print Server

Print services can be clustered using the Print Server resource. This represents printers attached directly to the network, not printers attached directly to a cluster node's ports. Printers that are clustered appear normally to clients, but in the event that one node fails, print jobs on that node will be moved to another, functional node and then restarted. Clients that are sending print jobs to the queue when a failure occurs will be notified of the failure and asked to resubmit their print jobs.

WINS Server

The WINS resource type is associated with the Windows Internet Naming Service, which maps NetBIOS computer names to IP addresses. To use WINS and make it a clustered service, the WINS database needs to reside on the quorum disk.

12.2.3. Planning a Cluster Setup

Setting up a server cluster can be tricky, but you can take a lot of the guesswork out of the process with a clear plan of the goals you are attempting to accomplish. Are you interested in achieving fault tolerance and load balancing at the same time? Do you not care about balancing load but want your focus to be entirely on providing five-nines service? Or would you like to provide only critical fault tolerance and thereby reduce the expense involved in creating and deploying the cluster?

If you are interested in a balance between load balancing and high availability, you allow applications and resources in the cluster to "fail over," or migrate, to other nodes in the cluster in the event of a failure. The benefit of this setup is that the resources continue to operate and are accessible to clients, but they also increase the load among the remaining, functioning nodes of the cluster. This load can cause cascading failures—as nodes continually fail, the load on the remaining nodes increases to the point where their hardware or software is unable to handle the load, causing those nodes to fail, and the process continues until all nodes are dead—and that eventuality really makes your fault-tolerant cluster immaterial. The moral here is that you need to examine your application, and plan each node appropriately to handle an average load plus an "emergency reserve" that can handle increased loads in the event of failure. You also should have policies and procedures to manage loads quickly when nodes fail. This setup is shown in Figure 12-9.

Figure 12-9. A balance between load balancing and high availability

If your be-all and end-all goal is true high availability, consider running a cluster member as a hot spare, ready to take over operations if a node fails. In this case, you would specify that if you had n cluster nodes, the applications and resources in the cluster should run on n-1 nodes. Then, configure the one remaining node to be idle. In this scenario, the applications will migrate to the idle node and continue functioning when failures occur. A nice feature is that your hot spare node can change, meaning there's not necessarily a need to migrate failed-over processes to the previously failed node when it comes back up—it can remain idle as the new hot spare. This reduces your management responsibility a bit. This setup is shown in Figure 12-10.

Figure 12-10. A setup with only high availability in mind

Also consider a load-shedding setup. In load shedding, you specify a certain set of resources or applications as "critical" and those are automatically failed over when one of your cluster nodes breaks. However, you also specify another set of applications and resources as "noncritical." These do not fail over. This type of setup helps prevent cascading failures when the load is migrated between cluster nodes because you shed some of the processing time requirements in allowing noncritical applications and resources to simply fail. Once repairs have been made to the nonfunctional cluster node, you can bring up the noncritical applications and resources, and the situation will return to normal. This setup is shown in Figure 12-11.

Figure 12-11. A sample load-shedding setup

12.2.4. Creating a True Server Cluster

With the background out of the way, it's time to create your first server cluster. Creating a new cluster involves inspecting the potential members of the cluster to ensure that they meet a solid baseline configuration and then starting the cluster service on each so that resources are managed across the machines and not individually on each machine.

First, of course, you will need to install the Failover Clustering feature. From Server Manager, click Features in the left pane, and then click Add Features in the main window. The Add Features Wizard loads. On the Features page, check the Failover Clustering box and click Next, and then on the confirmation page, click the Install button. You'll be able to monitor the progress of the installation from there.

Next, you'll need to validate the hardware configuration you've selected for your cluster. The validation process examines the hardware on the servers that will make up the cluster, ensuring that they are set up to fail over correctly in the event of an error. To validate, you will need local administrator rights to each of the members of the cluster. To begin:

  1. Open Failover Cluster Management from the Administrative Tools menu off the Start menu, and then click "Validate a Configuration" in the Management section of the main window.

  2. Acknowledge the warnings on the first screen and click Next.

  3. Enter the names of the servers that will make up your cluster—one by one—and click Add. The names will appear in the white box. Once you have added all of the servers to the list, click Next.

  4. On the Testing Options screen, choose "Run all tests" to ensure maximum compatibility with your configuration, and then click Next.

  5. The Confirmation screen appears. Confirm the settings, which essentially list the workflow the validation wizard will go through to probe the compatibility of the potential server cluster members, and then click Next to begin the tests.

  6. The validation tests run. This can take around five minutes per server for reasonably powered machines, although your times will almost certainly differ. Once the tests are complete, you'll be presented with the Failover Cluster Validation Report, which lists the tests that were run and also properties of each of the potential members of the server cluster you want to create. You can view the report as a full HTML-based page by clicking the View Report button. Otherwise, click Finish.

Now, to create a true server cluster, follow these steps:

  1. Open Failover Cluster Management from the Administrative Tools menu off the Start menu, and then click "Create a Cluster" in the Management section of the main window.

  2. Acknowledge the warnings on the first screen and click Next.

  3. Enter the names of the servers that will make up your cluster—one by one—and click Add. The names will appear in the white box. Once you have added all of the servers to the list, click Next.

  4. On the "Access Point for Administering the Cluster" screen, enter the name you want to use to administer the cluster—for example, DCS for domain controllers, MAIL for your email servers, and so on. Click Next.

  5. The Confirmation screen appears. Here, verify your settings and then click Next.

  6. Once the creation of the server cluster is complete, the Summary screen will appear. You can click View Report for an extensive list of all actions the wizard took to configure the cluster. Click Finish to exit the wizard.

The new cluster is active, and the first member has been added to it. When the wizard exits, you're dumped back into the Failover Cluster Management console, this time populated with management options and the new cluster node in the left pane. Figure 12-12 shows a sample console.

Figure 12-12. A sample Cluster Administrator screen

12.2.5. Using the High Availability Wizard

You can use the High Availability Wizard to prepare your cluster for introducing an application. The wizard does all of the heavy lifting to ensure that if the service or application you're configuring for the server fails on one node, the application will automatically restart. If an entire node fails, the cluster service will move the application to another node in the cluster and ensure that it is as highly available as possible.

Let's step through the High Availability Wizard and configure our own fault-tolerant application, Notepad (after all, it's a very important application):

  1. From within the Failover Cluster Management console, select "Configure a Service or Application" from the Configure section. The High Availability Wizard will appear. Click Next off of the introductory screen.

  2. The "Select Service or Application" screen appears. Select Generic Application from the list and click Next.

  3. The Generic Application Settings screen appears. In the Command Line box, type %SystemRoot%\system32\notepad.exe. You can leave the Parameters box blank for this example. Click Next.

  4. The Client Access Point screen appears—here, simply enter a name clients can use when referring to this application. Type Notepad and click Next.

  5. The Select Storage screen appears. Select the shared volume this cluster will use for data, and then click Next.

  6. The Replicate Registry Settings screen appears. There are no relevant Registry settings that need to be migrated across cluster members, so we can skip this screen; click Next.

  7. The Confirmation screen appears. Confirm all settings, and then click Next.

The new virtual server and cluster resource is then created and shown within the Failover Cluster Management console. When you bring the group online in the console, you'll notice that a Notepad window is opened in the background. If you close Notepad, it will automatically relaunch itself. This is the power of the cluster, demonstrated in a simple form, of course.


command-line_utilities-id4.html

12.3. Command-Line Utilities

The cluster utility enables you to manage almost all of the functions and administrative needs of a server cluster from the command line, making it easy to integrate such functions into scripts and dynamic web pages you might create. In this section, I'll take a look at the various options available with cluster and what you can do with the utility.

A couple of notes before I begin: when using cluster, the locale settings for the user account under which you're logged in must match the system default locale on the computer used to manage the cluster. It's best to match the locales on all cluster nodes and all computers from which you will use the command-line utility.

With that out of the way, let's take a look at using the utility. You can create new clusters from the command line; for example, to create a new cluster called "testcluster" at the IP address 192.168.1.140 with the administrator account, use the following:

Code View:
cluster testcluster /create ipaddress:192.168.1.140 /pass:Password /user:HASSELLTECH\
admnistratior /verbose

The /verbose option outputs detailed information to the screen about the process of creating the cluster.

You can add a node or multiple node (as shown in the example below) by using the /add switch. In the next command, I'm adding three nodes, called test1, test2, and test3, respectively, to the testcluster cluster.

cluster testcluster /add:test1,test2,test3 /pass:Password /verbose

You might also wish to change the quorum resource via the command line. You can do so as follows:

cluster testcluster /quorum:disk2 /path:D:\

One thing to note in the preceding command: if you change the location of the quorum resource, do not omit the drive letter, the colon, or any backslashes. Write out the path name as if you were entering the full path at the command line.

12.3.1. Managing Individual Nodes

The node option in cluster allows you to check on the status of and administer a cluster node. Some example commands include:

cluster node test1 /status

This command displays the cluster node status (for example, if the node is up, down, or paused).

cluster node test1 /forcecleanup

This command manually restores the configuration of the cluster service on the specified node to its original state.

cluster node test1 /start (or /stop or /pause or /resume)

This command starts, stops, pauses, or resumes the cluster service on the specified node.

cluster node test1 /evict

This command evicts a node from a cluster.

cluster node test1 /listinterfaces

This command lists the node's network interfaces.

12.3.2. Managing the Cluster Service Itself

There is also a command, called clussvc, that allows you to take action against a few things that might cause the cluster service to present trouble. You should only use this command if the cluster service fails to start, and it should only be run locally from the node that is presenting problems.

To enable the debugging of the resource dynamic-link libraries (DLLs) that are loaded by the resource monitor process, use the following:

clussvc /debug /debugresmon

To allow the cluster service to start up, despite problems with the quorum device, issue the following command:

clussvc /debug /fixquorum

When the /fixquorum command is issued on a particular node, the cluster service starts, but all the resources, including the quorum resource, remain offline. This allows you to then manually bring the quorum resource online and more easily diagnose quorum device failures.

The new quorum file is created using information in the cluster database located in %systemroot%\cluster\CLUSDB. Be careful, however, as that information might be out of date; only use this if no backup is available.

Use the following command to disallow replication of event log entries:

clussvc /debug /norepevtlogging

This command is useful in reducing the amount of information displayed in the command window by filtering out events already recorded in the event log.

And in the event that nothing else works, you can use the following command to force a quorum between a list of cluster nodes for a majority node set cluster:

clussvc /debug /forcequorum node1,node2,node3

You might use that command in a case where all nodes in one location have lost the ability to communicate with nodes in another location.


the_last_word-id11.html

12.4. The Last Word

As you've learned in this chapter, Windows Server 2008 supports two distinct types of clustering: NLB clusters, which simply provide load distribution capabilities to certain IP-based applications; and true server clustering, which provides fault-tolerance capabilities to larger sets of machines.

NLB is quite useful if you have a web-based application and several machines that can be devoted to servicing that application. The hardware does not need to be terribly powerful, and NLB is a great way to put used machines into service while providing a faster end-user experience. True server clustering is a better fit for medium-size organizations that have business-critical applications that always have to be available, no questions asked. Of course, with the high availability aspect comes increased cost, and the hardware investment required for true fault-tolerant capabilities is significant and should not be overlooked.


powershell.html

Chapter 13. PowerShell

PowerShell is Microsoft's administrative scripting tool incorporated into Windows Server 2008. Windows administrators can learn PowerShell to script common management tasks. PowerShell is a download that is available for Windows XP, Server 2003, and Vista; it is included within Windows Server 2008 as a feature you add to the base OS. Under development for several years, the first public view of the product was at the Professional Developer's conference in September 2003. The first release (PowerShell on Windows XP and Windows 2003 Server) occurred in November 2006, with versions for Vista and Longhorn server coming during 2007.

PowerShell is a command shell, similar to Unix shells like C-shell and Bourne shell or Microsoft's CMD.EXE shell, focused on the administrator (as opposed to a programmer). With PowerShell, an administrator can enter interactive commands as well and run more detailed scripts. Scripts can take parameters and produce output in a variety of forms.

PowerShell has the composability of the best versions of Unix/Linux shells, with the programming power of Ruby or Perl. Finally, it's built on top of the .NET framework. This means you can access just about any .NET feature directly from PowerShell, as well as accessing COM and WMI objects.

In this chapter, we will first look at the background to PowerShell and why Microsoft developed it. Next, we'll examine how to install it, and use it both at the command line and as a scripting tool. Finally, we'll look at how you can extend it for your own use.

13.1. Why PowerShell?

Before delving into PowerShell itself, it's important to understand the reasons it was developed as well as the approaches the PowerShell development team took to the product. Ever since Microsoft got into the software business, administrators have been managing client and server systems using a huge array of semi ad-hoc tools. These include console tools like CMD.EXE and a wealth of command-line tools. In addition, there were GUI tools such as the Microsoft Management Console, Regedit.exe, Adsiedit, and LDP.

The problem was that those tools did not do "everything"—thus there was occasionally a need to use VBScript or even native APIs and C#/C++. Nor did these tools integrate well—there was no way to use the output of, say, LDP as input to Regedit. Since there was no single tool that did everything, administrators ended up needing to use a variety of disparate tools to solve administrative issues.

These individual tools were totally adequate for their original purpose. However, the scope and capability of each tool was not consistent. Each tool did only part of the task and provided little integration with other tools. As many admins discovered, they would start down one path, such as writing a batch script using OS provided tools, only to find that the tools don't quite do what was needed. This meant moving to a different tool (e.g., using VBScript and COM automation) and throwing away some or all of their earlier work.

With the more recent releases of Windows (e.g., Windows XP, Windows Server 2003, and now Windows Server 2008), Microsoft has made great strides, particularly with the command-line tools. While the coverage is greatly improved, more is needed. Microsoft's answer to these concerns is PowerShell.

There are three key aspects of PowerShell that are of interest to an admin:

  • It is focused on the administrator.

  • It is broad in scope and completeness.

  • It is highly extensible.

You can directly call into .NET, WMI, and COM to work with existing code. You can access just about any sort of data, and this includes PowerShell's native support for XML. And if that's not enough, you can write your own extensions—for example, to make PowerShell work with a custom-developed line of business applications.


why_powershell_question.html

Chapter 13. PowerShell

PowerShell is Microsoft's administrative scripting tool incorporated into Windows Server 2008. Windows administrators can learn PowerShell to script common management tasks. PowerShell is a download that is available for Windows XP, Server 2003, and Vista; it is included within Windows Server 2008 as a feature you add to the base OS. Under development for several years, the first public view of the product was at the Professional Developer's conference in September 2003. The first release (PowerShell on Windows XP and Windows 2003 Server) occurred in November 2006, with versions for Vista and Longhorn server coming during 2007.

PowerShell is a command shell, similar to Unix shells like C-shell and Bourne shell or Microsoft's CMD.EXE shell, focused on the administrator (as opposed to a programmer). With PowerShell, an administrator can enter interactive commands as well and run more detailed scripts. Scripts can take parameters and produce output in a variety of forms.

PowerShell has the composability of the best versions of Unix/Linux shells, with the programming power of Ruby or Perl. Finally, it's built on top of the .NET framework. This means you can access just about any .NET feature directly from PowerShell, as well as accessing COM and WMI objects.

In this chapter, we will first look at the background to PowerShell and why Microsoft developed it. Next, we'll examine how to install it, and use it both at the command line and as a scripting tool. Finally, we'll look at how you can extend it for your own use.

13.1. Why PowerShell?

Before delving into PowerShell itself, it's important to understand the reasons it was developed as well as the approaches the PowerShell development team took to the product. Ever since Microsoft got into the software business, administrators have been managing client and server systems using a huge array of semi ad-hoc tools. These include console tools like CMD.EXE and a wealth of command-line tools. In addition, there were GUI tools such as the Microsoft Management Console, Regedit.exe, Adsiedit, and LDP.

The problem was that those tools did not do "everything"—thus there was occasionally a need to use VBScript or even native APIs and C#/C++. Nor did these tools integrate well—there was no way to use the output of, say, LDP as input to Regedit. Since there was no single tool that did everything, administrators ended up needing to use a variety of disparate tools to solve administrative issues.

These individual tools were totally adequate for their original purpose. However, the scope and capability of each tool was not consistent. Each tool did only part of the task and provided little integration with other tools. As many admins discovered, they would start down one path, such as writing a batch script using OS provided tools, only to find that the tools don't quite do what was needed. This meant moving to a different tool (e.g., using VBScript and COM automation) and throwing away some or all of their earlier work.

With the more recent releases of Windows (e.g., Windows XP, Windows Server 2003, and now Windows Server 2008), Microsoft has made great strides, particularly with the command-line tools. While the coverage is greatly improved, more is needed. Microsoft's answer to these concerns is PowerShell.

There are three key aspects of PowerShell that are of interest to an admin:

  • It is focused on the administrator.

  • It is broad in scope and completeness.

  • It is highly extensible.

You can directly call into .NET, WMI, and COM to work with existing code. You can access just about any sort of data, and this includes PowerShell's native support for XML. And if that's not enough, you can write your own extensions—for example, to make PowerShell work with a custom-developed line of business applications.


installing_powershell.html

13.2. Installing PowerShell

PowerShell is not installed in any version of Windows by default. For earlier versions of Windows (Windows XP, Windows Server 2003), you needed to download software from Microsoft's web site. However, as PowerShell is included in the installation binaries, installing it on Windows Server 2008 is really very simple.

PowerShell has only one key dependency, the .NET Framework version 2.0, which needs to be installed before you can install PowerShell. In Windows Server 2008, the .NET Framework is installed by default. In Windows Server 2008, PowerShell is an optional feature that you can install either using Server Manager, or as part of an unattended installation.

Use the Server Manager to add the PowerShell feature as follows:

  1. Run Server Manager, and select the option to add a feature.

  2. Select the PowerShell feature and click Next.

  3. Sit back and watch the installation run.

As PowerShell is an OS feature, the installer places PowerShell's core components into the %systemroot%\system32\windowspowershell\v1.0 folder. The installer adds copy help files, formatting XML, some "getting started" documents, and a sample profile file to this location.

PowerShell is a managed application, based on the .NET Framework. To speed up load times, the PowerShell installer also installs PowerShell's core binaries into the .NET Global Assembly Cache.

Installing PowerShell also updates the Registry as follows:

  • Three new file types are added to HKEY_CLASSES_ROOT. They are .ps1 (PowerShell script files), .ps1xml (PowerShell display XML), and .psc1 (PowerShell Console).

  • The installation process also populates the Registry key: KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1.

  • The installer modifies the system path to include %systemroot%\system32\WindowsPowerShell\v1.0.

Once you have installed PowerShell, you can verify a successful installation by clicking Start, then Run, and then entering PowerShell and hitting Return.


powershell_and_security.html

13.3. PowerShell and Security

PowerShell, like any powerful admin tool, has the potential to do a lot of damage to a system if used incorrectly. You can use PowerShell to remove key files, remove or modify Registry settings, delete certificates, and so on—all of which can be dangerous.

To minimize the risks, the PowerShell team took the following steps:

  1. PowerShell is not installed by default—there's no "backdoor" installations that malware vendors could rely on.

  2. The PowerShell script file with the .PS1 extension is associated with Notepad rather than with PowerShell. Double-clicking on a script opens Notepad with the script to edit as opposed to executing script that could otherwise be malware.

  3. PowerShell's execution policy is set by default to "restricted". This means you cannot run any script from inside PowerShell. You can easily change this by using the set-executionpolicy cmdlet to a less secure setting.

  4. To stop local admins or users from setting the execution policy to unrestricted and running malevolent scripts, you can use Group Policy to set PowerShell's execution policy.

This level of security may seem like a lot of hassle for an administrator, but the approach goes a long way beyond reasonable means to avoid self-inflicted damage.


starting_up_powershell.html

13.4. Starting Up PowerShell

Once you complete the steps above, PowerShell is available on your system. You can run PowerShell by clicking on Start, then clicking on Run, entering PowerShell into the Open text box, and hitting OK or return. Up should come the default PowerShell screen.

When PowerShell starts up, it attempts to load and then execute four separate script files:

  • %ALLUSERSPROFILEe%\Documents\PSConfiguration\Profile.ps1

  • %ALLUSERSPROFILEe%\Documents\PSConfiguration\Microsoft.Powershell_Profile.ps1

  • %USERPROFILE%\My Documents\PSConfiguration\Profile.ps1

  • %USERPROFILE%\My Documents\PSConfiguration\Microsoft.Powershell_Profile.ps1

Each of these files is a PowerShell script file as described shortly. Having four profile files may seem excessive, but there is a good reason behind this approach. With PowerShell, you can use the product as installed but you can also create your own shells with private additional cmdlets (explained in the next section). An example of a custom shell is the Exchange 2007 Management shell.

The two profile.ps1 files are run by every PowerShell shell that would include the Exchange Management Shell. The two Microsoft.Powershell_Profile.ps1 files, however are only executed by PowerShell.exe. Likewise, you have both personal startup scripts and global startup scripts.

This gives you considerable flexibility in how you deploy PowerShell. Your enterprise functions, filters, and aliases could live in the All Users Profile.ps1. These are then available to all shells for all users. You can then place personal or private PowerShell functions and other definitions into a personal .PS1 file for your particular use.


cmdlets_colon_the_heart_of_powershell.html

13.5. Cmdlets: The Heart of PowerShell

At the heart of PowerShell is the cmdlet (pronounced "command-let"). It is the smallest bit of code you can run. A cmdlet is a block of code that you can run from the PowerShell prompt, or from a script, that does performs a function. Technically, a cmdlet is a .NET class that has been developed by either the PowerShell team or a third-party developer and incorporated into PowerShell.

To call a cmdlet, just type its name at the PowerShell prompt, as follows:

PSH [D:\foo]: Get-Process

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    112       5     1220       3640    32     0.06    436 alg
     42       2     1316       3424    29   199.19    576 ApntEx
     93       3     1740       5776    37   494.06   2456 Apoint
    267       7     4492      12140    64     1.61  47124 Connect
   1045       9     7220       7552    51   242.39   1680 csrss
     74       4     1284       4824    30     1.84   3864 ctfmon
    107       4     3624       7224    47     0.67   1016 DataServer
    142       6     4636       8472   179     1.09    372 EvtEng
... [output snipped]

In this example, the Get-Process cmdlet obtains the set of running processes on the computer and outputs a number of attributes. The attributes that are output by Get-Process (i.e., handle-count, non-paged kernel memory, paged kernel memory, working set, VM size, CPU time used, process-id, and process name), are output by default and are sorted based on process name.

Cmdlets can take parameters, as shown here:

PSH [D:\foo]: Get-Process notepad

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
     48       3     1392       1072    31     1.48   1544 notepad

PSH [D:\foo]: Get-process -Name notepad

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
     48       3     1392       1072    31     1.48   1544 notepad
PSH [D:\foo]:

This example shows the Get-Process called with the name of a process to output (Notepad). As this example demonstrates, parameters can be either positional, where the first value is assumed to be the first parameter, the second value specified the second parameter, etc.; or named, where the value is explicitly assigned to a particular parameter. Named parameters can be specified in any order, whereas positional parameters need to be specified in the order the cmdlet expects.

All parameter names begin with a - (minus) followed by the parameter name. One of the more important parameters that all cmdlets support is help or "-?". For example:

Code View:
PSH [D:\foo]: get-process -?

NAME
    Get-Process
SYNOPSIS
    Gets the processes that are running on the local computer.

SYNTAX
    Get-Process [[-name] <string[]>] [<CommonParameters>]
    Get-Process -id <Int32[]> [<CommonParameters>]

    Get-Process -inputObject <Process[]> [<CommonParameters>]

DETAILED DESCRIPTION
    The Get-Process cmdlet retrieves a process object for each process. Without
parameters, "Get-Process" gets all of the processes on the computer, as though you
typed "Get-Process *". You can also identify a particular process
by process name or process
ID (PID), or pass a process object through the pipeline to Get-Process.
For Get-Process, the default method is by process name.
For Stop-Process, the default method is by
process ID.

RELATED LINKS
    Stop-Process

REMARKS
    For more information, type: "get-help Get-Process -detailed".
    For technical information, type: "get-help Get-Process -full".

PSH [D:\foo]:


getting_help_with_powershell.html

13.6. Getting Help with PowerShell

Learning any new tool, program, or OS takes time—but some are easier to get to know than others. PowerShell was designed from the outset to be as discoverable as possible. Once you know a few small things, you can use that knowledge to learn more and to get up to speed.

There are two cmdlets that you will find helpful to get you started: Get-Help and Get-Command. The Get-Help cmdlet gets help about PowerShell cmdlets and key concepts. Get-Command gets basic information about cmdlets and other commands you can use from within PowerShell. Additionally, every PowerShell cmdlet supports the -? parameter to get help.

The Get-Help cmdlet takes a parameter to indicate what you want to get help on. One neat feature is that you can use wild cards in the parameter to get help about more than one thing, as shown here:

PSH [D:\foo]: get-help get-h*

Name        Category Synopsis
----        -------- --------
Get-Help    Cmdlet   Displays information about Windows PowerShell
                     cmdlets and concepts.
Get-History Cmdlet   Gets a list of the commands entered during the
                     current session.
Get-Host    Cmdlet   Gets a reference to the current console host
                     object. Displays Windows PowerShell version...
Get-Hash    Cmdlet   Gets the hash value for the specified file or
                     byte array via the pipeline.
Get-HTTP    Cmdlet   The get-http cmdlet can be used to retrieve
                     documents from the World Wide Web.

This example looked for help on Get-H* and that returned a synopsis of the five cmdlets on the system that match this wild card. Get-Help * would return a summary of everything that PowerShell could provide help about.

Another nice example of the discoverability that has been built into PowerShell is the help files. PowerShell comes with a number of small text files that describe key PowerShell concepts. You can view these by using the Get-Help cmdlet. To see all the help files, you type Get-Help about* and this returns the list of all the help files. Typing Get-Help about_if provides information about the if statement as shown here:

Code View:
PSH [D:\foo]: get-help about_if
TOPIC
    The if statement

SHORT DESCRIPTION
    A language command for running a command block or blocks based on the results of
one or more conditional tests

LONG DESCRIPTION
    You can use the if statement to run a code block if a specified
    conditional test evaluates to true. You can also specify one or
    more additional conditional tests to run if all prior tests
    evaluate to false. Finally, you can specify an additional code
    block that is run if no other prior conditional test evaluates to
    true.
{additional output not shown}


using_data_stores_and_powershell_provid.html

13.7. Using Data Stores and PowerShell Providers

Today's modern computing world makes use of a vast variety of data stores, including the file store, the certificate store, the Registry, etc. With previous tools, each of these data stores are accessed using different and incompatible tools, making it hard for the admin to learn, use, and master. PowerShell take a different approach through the use of providers and standard cmdlets.

A PowerShell provider is a software component that sits between the actual data store and the standard cmdlets. The standard cmdlets call into the provider to return the relevant data and present it in a admin-friendly way. To aid in conversion, PowerShell provides aliases for these standard cmdlets. The provider architecture is shown at http://msdn2.microsoft.com/en-us/library/ms714658.d2eb7674-3a27-4baf-91b7-b8eaf1e8ab2c(en-us,VS.85).gif.

To illustrate this, let's look at the two data stores, the filesystem and the Registry:

Code View:
PSH [D:\foo]: dir

    Directory: Microsoft.PowerShell.Core\FileSystem::D:\foo

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----        14/10/2007     12:04            bar

PSH [D:\foo]: cd bar
PSH [D:\foo\bar]: ls

    Directory: Microsoft.PowerShell.Core\FileSystem::D:\foo\bar

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        14/10/2007     12:04          8 foobar.txt

PSH [D:\foo\bar]: cd hklm:
PSH [HKLM:\]: ls

   Hive: Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE

SKC  VC Name                           Property
---  -- ----                           --------
  4   0 HARDWARE                       {}
 87   0 SOFTWARE                       {}
  8   0 SYSTEM                         {}

PSH [HKLM:\]: dir .\software\microsoft\powershell

   Hive: Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\software\microsoft\
powershell

SKC  VC Name                           Property
---  -- ----                           --------
  4   2 1                              {Install, PID}

In this example, we use both the Dir and LS aliases to examine two separate data stores: the filesystem and the Registry. Both aliases are to the Get-ChildItem standard cmdlet, which allows both Linux/Unix and Dos/Windows users to use familiar names to perform common and familiar operations. There are several more standard cmdlets:

Clear-Item

Deletes the contents of an item, but does not delete the item.

Clear-ItemProperty

Deletes the value of a property, but does not delete the property itself.

Copy-Item

Copies an item from one location to another within a namespace.

Copy-ItemProperty

Copies a property and value from a specified location to another location.

Get-ChildItem

Gets the items and child items in one or more specified locations.

Get-ItemProperty

Retrieves the properties of a specified item.

Get-Item

Gets the item at the specified location.

Invoke-Item

Invokes the provider-specific default action on the specified item.

Move-Item

Moves an item from one location to another.

New-Item

Creates a new item in a namespace.

Move-ItemProperty

Moves a property from one location to another.

Rename-Item

Renames an item in a Windows PowerShell provider namespace.

New-ItemProperty

Sets a new property of an item at a location.

Remove-Item

Deletes the specified items.

Remove-ItemProperty

Deletes the property and its value from an item.

Rename-ItemProperty

Renames a property of an item.

Set-Item

Changes the value of an item to the value specified in the command.

Set-ItemProperty

Sets the value of a property at the specified location.

This list represents a number of new cmdlets for the admin to learn. In order to minimise the learning curve, PowerShell provides common aliases for each of these standard cmdlet, e.g., Get-ChildItem is aliased to GCI, DIR, and LS. You can get a list of these aliases as follows:

Code View:
PSH [D:]: get-alias * | where {$_.definition -like "*item*"} | ft -auto

CommandType Name  Definition
---------- ----  ----------
Alias       cli   Clear-Item
Alias       clp   Clear-ItemProperty
Alias       cpi   Copy-Item
Alias       cpp   Copy-ItemProperty
Alias       gci   Get-ChildItem
Alias       gi    Get-Item
Alias       gp    Get-ItemProperty
Alias       ii    Invoke-Item
Alias       mi    Move-Item
Alias       mp    Move-ItemProperty
Alias       ni    New-Item
Alias       ri    Remove-Item
Alias       rni   Rename-Item
Alias       rnp   Rename-ItemProperty
Alias       rp    Remove-ItemProperty
Alias       si    Set-Item
Alias       sp    Set-ItemProperty
Alias       cp    Copy-Item
Alias       ls    Get-ChildItem
Alias       mv    Move-Item
Alias       rm    Remove-Item
Alias       rmdir Remove-Item
Alias       copy  Copy-Item
Alias       del   Remove-Item
Alias       erase Remove-Item
Alias       move  Move-Item
Alias       rd    Remove-Item
Alias       ren   Rename-Item

These aliases enable you to start using PowerShell and PowerShell providers straight away using the names of the DOS/Windows/Unix/Linux commands you are already familiar with. They also avoid you needing to learn new cmdlets in order to get any value from PowerShell.

The aliases and standard cmdlets call into a provider to obtain the relevant information (the contents of the current working file store folder, the current node in the Registry, etc.). PowerShell comes with several providers, and you can add more. Providers built into PowerShell include Alias, Environment, FileSystem, Function, Registry, Variable, and Certificate. Additional third-party providers include SQL Server, One-Note and Microsoft Compute Cluster.

With the provider, you can use the New-PSDrive to create new drives. These drives can then be used as normal drives in the standard cmdlets and related aliases. For example:

PSH [D:\foo]: New-PSDrive -name scripts -psProvider Filesystem -root d:\foo

Name       Provider      Root
----       --------      ----
scripts    FileSystem    D:\foo

PSH [D:\foo]: dir scripts:

    Directory: Microsoft.PowerShell.Core\FileSystem::D:\foo
Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----        14/10/2007     12:04            bar

In this manner, you can create new drives that are more meaningful than C: and D:. To see what drives are available, you can use the Get-PSDrive cmdlet as shown here (note the new scripts drive we created in the previous example):

Code View:
PSH [D:\foo]: Get-PSDrive

Name       Provider      Root
----       --------      ----
Alias      Alias
C          FileSystem    C:\
cert       Certificate   \
D          FileSystem    D:\
E          FileSystem    E:\
Env        Environment
F          FileSystem    F:\
Feed       FeedStore
Function   Function
HKCU       Registry      HKEY_CURRENT_USER
HKLM       Registry      HKEY_LOCAL_MACHINE
L          FileSystem    L:\
R          FileSystem    R:\
S          FileSystem    S:\
scripts    FileSystem    D:\foo
T          FileSystem    T:\
U          FileSystem    U:\
Variable   Variable
Y          FileSystem    Y:\

With these drives, you can perform actions like Dir ENV: to get a list of environment variables or dir Variable: to see a list of variables in use. For more help on providers, type Get-Help about_providers at the PowerShell prompt. And for more detailed information about providers and how to build one, see http://msdn2.microsoft.com/en-us/library/ms714636.aspx.


the_pipeline.html

13.8. The Pipeline

The pipeline is a feature of PowerShell that takes the output of one cmdlet and sends ("pipes") it to another cmdlet—as you may have noticed in some of the examples earlier in this chapter. The PowerShell pipeline is very similar to the Pipeline in Unix and Linux—and is perhaps one of PowerShell's more significant features. One major difference is that in Unix/Linux, what is usually sent between stages in the pipeline is raw text that then needs to be manipulated—often referred to as prayer-based parsing. For example, you could use the Unix command PS to get a list of processes; then you could send the text output to a formatting program to manipulate the output. PowerShell sends .NET (or other) objects between stages in the pipeline.

For example, you could pipe the output of the Get-Process cmdlet into the Sort-Object cmdlet as follows:

PSH [D:\foo]: get-process | sort-object handles

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
      0       0        0         28     0               0 Idle
     21       1      192        432     4     0.22   1568 smss
     31       3     1224       3072    32     0.05    968 shstat
     35       2     1040       3212    27     0.06   3940 Mctray
... {rest of table removed}

In this example, the Get-Process cmdlet obtains a set of process objects representing the processes running on the system, and sends them to the next stage of the pipeline. These process objects are then input to the Sort-Object cmdlet that sorts the process objects based on the number of active handles. This is then output to the console using the default formatter. Since PowerShell is passing objects between pipeline stages, the Sort-Object knows what is coming in and knows whether the objects have a handles property.

The pipeline can be several levels deep, as shown here:

Code View:
PSH [D:\foo]: Get-Process | Where-Object {$_.Handles -gt 500} | Sort-Object Handles
-Descending | Select-Object Processname, Id, Handles | Format-Table -Autosize

ProcessName      Id Handles
-----------      -- -------
OUTLOOK        2552    5729
svchost         320    2355
Quest.PowerGUI 5984    1839
searchindexer  2164    1563
PKTray         4632    1267
csrss          1684    1216
iexplore       2592    1044
msnmsgr        3912     982
firefox        4004     970
explorer       3192     951
WINWORD        5588     882
System            4     856
svchost        2024     841
POWERPNT       5876     817
lsass          1764     664
winlogon       1708     642
explorer       5940     571
services       1752     533

This example first retrieves all the processes running on your system using Get-Process. These processes then go to the Where-Object cmdlet, which discards any process whose handle count is less than or equal to 500. The list is then sorted in descending order, using Sort-Object. Next, the Select-Object cmdlet retrieves just three properties from the objects being passed. Finally, Format-Table formats those properties into a simple table with the minimum number of spaces between each column.

In this example, you see the cmdlet names spelled out in full. You could use the aliases for each cmdlet, to reduce the amount of typing you need to do, by specifying:

Code View:
gps | where {$_.handles -gt 500} | sort handles -desc | select processname, id,
handles | ft -a

You have the option of typing more or less depending on your needs. If you are entering these commands at the PowerShell prompt, then using aliases makes things easy for you. Alternatively, when developing production scripts, specifying the full names of cmdlets and parameter names is a very good idea.

To get more information about the pipeline, use Get-Help About_Pipeline.


formatting_basics.html

13.9. Formatting Basics

PowerShell was designed for use by administrators as opposed to programmers, unlike VBScript. PowerShell knows how to format the objects produced by cmdlets or to display variable and other data typed at the PowerShell prompt. As we have seen in this chapter thus far, you can simply enter a cmdlet or variable at the PowerShell prompt, and get nicely formatted output. You can also use four additional cmdlets, Format-Table, Format-List, Format-Wide, and Format-Custom to create different forms of output.

PowerShell provides you with a number of options for formatting. In most cases, you can just accept PowerShell's built-in formatting. Or, if you are so inclined, you can delve deeper into .NET for richer formatting features.

To illustrate PowerShell formatting, here is a simple command that uses a Get-WMI object to retrieve information about the memory devices in a computer:

Code View:
PSH [D:\foo]: Get-WMIObject -Class win32_memorydevice

_  _GENUS                     : 2
_  _CLASS                     : Win32_MemoryDevice
_  _SUPERCLASS                : Win32_SMBIOSMemory
_  _DYNASTY                   : CIM_ManagedSystemElement
_  _RELPATH                   : Win32_MemoryDevice.DeviceID="Memory Device 0"
_  _PROPERTY_COUNT            : 39
_  _SERVER                    : XP21
_  _NAMESPACE                 : root\cimv2
_  _PATH                      : \\XP21\root\cimv2:Win32_MemoryDevice.DeviceID="Memory
Device 0"
Access                      :
AdditionalErrorData         :
Availability                :
BlockSize                   :
Caption                     : Memory Device
ConfigManagerErrorCode      :
ConfigManagerUserConfig     :
CorrectableError            :
CreationClassName           : Win32_MemoryDevice
Description                 : Memory Device
DeviceID                    : Memory Device 0
EndingAddress               : 639
{ more details snipped}

In this simple example, PowerShell uses WMI to obtain memory device information from the computer and then outputs this information to the console using default formatting. If you'd like more information about this WMI object, see http://msdn2.microsoft.com/en-us/library/aa394197.aspx.

By default, PowerShell pipes all the output objects to the default formatter, the Out-Default cmdlet. This cmdlet then uses PowerShell's built-in display XML to format the objects. The default display XML is stored in %systemroot%\ system32\windowspowershell\v1.0 (the files have the extension .PS1XML).

You have several options for dealing with formatting. As just mentioned, you can use PowerShell's built-in default formatting, and often that's all you need. For example, if you enter DIR at the PowerShell prompt, you get a directory listing, which usually contains the information you require. As you can see from the Win32_MemoryDevice example, however, this default format may be more than you want.

To assist the admin, as noted earlier, PowerShell includes four formatting cmdlets you can use: Format-List (alias FL), Format-Table (alias FT), Format-Wide (FW), or Format-Custom (FC). You use these cmdlets in the last stage in the pipeline, to display a subset of properties. For example:

Code View:
PS C:\foo> get-wmiobject win32_memorydevice | format-list deviceid, startingaddress,
endingaddress

deviceid    : Memory Device 0
startingaddress : 0
endingaddress  : 639

deviceid    : Memory Device 1
startingaddress : 1024
endingaddress  : 1048575

deviceid    : Memory Device 2
startingaddress : 1048576
endingaddress  : 2097151

As an alternative, you could use the Format-Table cmdlet (along with the -autosize parameter) to produce a nice table:

Code View:
PS C:\foo> get-wmiobject win32_memorydevice | format-table deviceid, endingaddress,
startingaddress -autosize

deviceid        startingaddress endingaddress
--------        --------------- -------------
Memory Device 0               0           639
Memory Device 1            1024       1048575
Memory Device 2         1048576       2097151

The Format-* cmdlets enable you to override PowerShell's default formatter. You just pipe the output you want into one of these formatting cmdlets.

PowerShell uses some simple rules when formatting objects by default:

  • PowerShell first examines the format .ps1xml files, looking for a view for the object to be formatted. If the formatting XML files contain a view, PowerShell uses it to create the output. PowerShell comes with a number of objects that have defined views. You can easily adapt these as appropriate. You can also add your own definitions for any object, including the objects that do not have a default view defined and any custom objects you add to PowerShell.

  • If there is no defined view for the object, PowerShell examines the .ps1xml files to find a default set of display properties for the object being formatted. If one is found, PowerShell collects the properties named, and moves on to the next step. If there are no display properties defined, PowerShell collects all the properties and moves on.

  • Based on the previous step, PowerShell then calls either Format-Table to display the object or calls Format-List. PowerShell uses Format-Table if there are five or fewer properties to display; otherwise, it uses Format-List.

See http://blogs.msdn.com/powershell/archive/2006/04/30/586973.aspx for more information on PowerShell formatting.


variables.html

13.10. Variables

PowerShell allows you to assign the output of a cmdlet or a pipeline of cmdlets to a variable. A variable is a named object that can hold any sort of value, including a simple type (a number, string, Boolean value), an array, or a more complex type (such as an object). You can use variables to obtain individual properties of an object, or to hold values you use in a script.

Variable names begin with a $ (dollar sign), as shown here:

PSH [D:\foo]: $a = 1
PSH [D:\foo]: $b=12.123
PSH [D:\foo]: $c="this is a string"
PSH [D:\foo]: $a
1
PSH [D:\foo]: $b
12.123
PSH [D:\foo]: $c
this is a string

PowerShell automatically works out the variable type, although you can override this. In this example, $a is created as an integer, $b a double, and $c a string. And as discussed earlier, PowerShell used the data type to work out how to format the objects.

To determine the type of any variable, you can pipe the variable to the Get-Member cmdlet as shown here:

PSH [D:\foo]: $a | get-member

   TypeName: System.Int32

Name        MemberType Definition
----        ---------- ----------
CompareTo   Method     System.Int32 CompareTo(Int32 value), ...
Equals      Method     System.Boolean Equals(Object obj), ...
GetHashCode Method     System.Int32 GetHashCode(  )
GetType     Method     System.Type GetType(  )
GetTypeCode Method     System.TypeCode GetTypeCode(  )
ToString    Method     System.String ToString(  ), System.String
ToString (IFormatProvider provider), System.String ToS...

PSH [D:\foo]: $b| get-member

   TypeName: System.Double

Name        MemberType Definition
----        ---------- ----------
CompareTo   Method     System.Int32 CompareTo(Object value), ...
Equals      Method     System.Boolean Equals(Object obj),...
GetHashCode Method     System.Int32 GetHashCode(  )
GetType     Method     System.Type GetType(  )
GetTypeCode Method     System.TypeCode GetTypeCode(  )
ToString    Method     System.String ToString(String format, ...

You can also explicitly define a variable to be a specific type by including the type name before the variable as shown here:

Code View:
PSH [D:\foo]: [double] $a = 1
PSH [D:\foo]: $a
1
PSH [D:\foo]: $a | gm

   TypeName: System.Double

Name        MemberType Definition
----        ---------- ----------
CompareTo   Method     System.Int32 CompareTo(Object value), ... Equals      Method
     System.Boolean Equals(Object obj), System.Boolean ...
GetHashCode Method     System.Int32 GetHashCode(  )
GetType     Method     System.Type GetType(  )
GetTypeCode Method     System.TypeCode GetTypeCode(  )
ToString    Method     System.String ToString(String format,...

Variables can also hold objects and can be used in control statements in a script. For example, you could use the Get-WMIObject cmdlet to retrieve the BIOS information, and then perform some action if a particular value of the BIOS information exists, as shown here:

PSH [D:\foo]: $bios = Get-WMIObject Win32_Bios
PSH [D:\foo]: $bios

SMBIOSBIOSVersion : A04
Manufacturer      : Dell Inc.
Name              : Phoenix ROM BIOS PLUS Version 1.10 A04
SerialNumber      : DDC2H2J
Version           : DELL   - 27d60a0d
PSH [D:\foo]: $bios.SMBIOSBIOSVersion
A04
PSH [D:\foo]: $bv = $bios.SMBIOSBIOSVersion
PSH [D:\foo]: if ($bv -eq "A04") {write-host "Latest BIOS"}
Latest BIOS
PSH [D:\foo]:

In this example, WMI returns the BIOS information, from which the BIOS version ID is retrieved and output. The BIOS version ID string is then tested using the IF command and as you can see, since the BIOS version returned from WMI is "A04", the test is true and PowerShell prints out the message.

For more information on variables in PowerShell, see http://www.microsoft.com/technet/technetmag/issues/2007/03/PowerShell/default.aspx.


writing_scripts.html

13.11. Writing Scripts

While you can use the PowerShell prompt to run cmdlets, most Windows Server 2008 administrators will write their own scripts for performing tasks in their environment. For example, you could develop a script to ping remote systems to discover whether they are available, and report on those that are not. You could extend this to time how long a ping takes and report whether that time is outside of some previously established norm, or you could develop a script to add a user to your active directory, add the users to role-based security groups, enable the Exchange and Unified messaging mailboxes, and enable the user to use the Office Communications server.

A script is a text file with a PS1 extension that contains the commands you might type at the PowerShell prompt along with a variety of control statements to control the execution of your script. In general, there is nothing you can do in a script that you could not do at the PowerShell prompt—scripts just cut down on typing. This means you can try things out at the PowerShell prompt, and create your script from there—something not really possible in traditional scripting languages such as VBScript.

For added security, scripts can be digitally signed. When combined with PowerShell's execution policy, this enables you to restrict administrators to only running scripts specifically signed by your organization. For more information about signing PowerShell scripts, see http://www.hanselman.com/blog/SigningPowerShellScripts.aspx.

The world's shortest Hello World script would be a file, helloworld.ps1, as follows:

PSH [D:\foo]: cat helloworld.ps1
"Hello World"
PSH [D:\foo]: .\helloworld.ps1
Hello World
PSH [D:\foo]:

This very short script just displays the string "Hello World". It is not particularly useful. Production scripts tend to do more than just output "Hello World". Here's a more functional script that displays the size of each disk (including mapped network drives), along with the amount of free space available:

Code View:
PSH [D:\foo]: cat get-disksize.ps1
#get-disksize.ps1
#Thomas Lee tfl@psp.co.uk
Param ($Computer = "localhost")
#Get Disk info
$colDisks = get-wmiobject Win32_LogicalDisk -computer $computer
$Now display it
" Device ID    Type               Size(M)     Free Space(M)"
ForEach ($Disk in $colDisks)
{
 $drivetype=$disk.drivetype
 Switch ($drivetype)
 {
     2 {$drivetype="FDD"}
     3 {$drivetype="HDD"}
     4 {$drivetype="Net"}
     5 {$drivetype="CD "}
 }
"    {0}         {1}       {2,15:n}  {3,15:n}" -f $Disk.DeviceID, $drivetype,
$($disk.Size/1mb), $($disk.freespace/1mb)
}
""
PSH [D:\foo]: .\get-disksize.ps1
Device ID    Type               Size(M)     Free Space(M)
   C:         HDD             20,928.43         1,005.85
   D:         HDD             21,202.97         2,783.07
   E:         HDD             53,168.21         2,460.73
   F:         CD               4,270.18             0.00
   L:         Net          1,526,214.19       502,263.14
   R:         Net            675,402.00       556,902.56
   S:         Net             76,253.84        34,930.72
   T:         Net                  0.00             0.00
   U:         Net                  0.00             0.00
   Y:         Net             69,970.60         8,091.59

A rich set of control structures is available to you while you're writing scripts, including:

If-then-else

You can test some condition (e.g., whether a user exists in AD) and based on that test, carry out operations (e.g., add the user) if the test succeeds, or do something else (e.g., issue an error message) if it does not. For details on the syntax of this construct, type Get-Help About_If.

Switch

This evaluates an item against a set of possible values and takes the action based on that evaluation. You could, for example, obtain the BIOS version of a system, and then test for each possible value. For details on the syntax of switch construct, type Get-Help About_Switch.

Looping

There are three looping control structures: For, Do-Until, and While. Typing Get-Help about_while provides more information on the While statement.

For and For-each

These iterate through an array or a set of values. Type Get-Help About_For and Get-Help About_ForEach for more information about the For statements.

Throw and Trap

These generate and catch errors.

Unfortunately there is very little documentation within PowerShell on Throw and Trap, as noted in http://blogs.msdn.com/powershell/archive/2006/12/29/documenting-trap-and-throw.aspx. See http://huddledmasses.org/trap-exception-in-powershell/ for more details about Throw and Trap.


objects_colon_.net_comma_wmi_comma_and.html

13.12. Objects: .NET, WMI, and COM

PowerShell is an object-oriented product—all the language features and constructs are based on objects: cmdlets emit objects, variables are objects, and language constructs allow you to manipulate objects. You can use the properties of an object and can call methods an object contains. While some PowerShell users may not make much direct use of this object orientation, PowerShell is able to make use of .NET and WMI objects, both at the command line and in scripts. Like most of PowerShell's features, we could devote an entire book to the subject of objects in PowerShell.

PowerShell is built on the .NET Framework and enables you to access and use most of the classes within the framework. A restriction of PowerShell version 1 is that the asynchronous classes and methods are not supported.

Using .NET objects is pretty easy since much of it happens by default. You can either let PowerShell determine the .NET classes by default—for example, typing LS or DIR in a filesystem drive produces a set of file and directory objects. You can see this by piping the output of a command to the Get-Member cmdlet, as shown here:

Code View:
PSH [D:\foo]: ls

    Directory: Microsoft.PowerShell.Core\FileSystem::D:\foo

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----        14/10/2007     12:04            bar
-a---        09/09/2007     12:30          3 foo.txt
-a---        14/10/2007     19:42         13 helloworld.ps1
PSH [D:\foo]: dir | Get-Member

   TypeName: System.IO.DirectoryInfo

Name                      MemberType     Definition
----                      ----------     ----------
Create                    Method         System.Void Create(  ), System.Void
Create(DirectorySecurity
CreateObjRef              Method         System.Runtime.Remoting.ObjRef
CreateObjRef(Type requested

... output snipped for brevity

   TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText(  )
CopyTo                    Method         System.IO.FileInfo CopyTo(String dest
Create                    Method         System.IO.FileStream Create(  )
CreateObjRef              Method         System.Runtime.Remoting.ObjRef Create
CreateText                Method         System.IO.StreamWriter CreateText(  )
Decrypt                   Method         System.Void Decrypt(  )
Delete                    Method         System.Void Delete(  )
Encrypt                   Method         System.Void Encrypt(  )
Equals                    Method         System.Boolean Equals(Object obj)
... output snipped for brevity

In the above example, the LS command emitted System.IO.DirectoryInfo and System.IO.FileInfo objects. To many Windows admins not familiar with the .NET, this looks quite complex, but it does become second nature with a bit of practice. For more information on System.IO.DirectoryInfo objects, see http://msdn2.microsoft.com/en-us/library/system.io.directoryinfo.aspx and for more information on System.IO.FileInfo objects, see http://msdn2.microsoft.com/en-us/library/system.io.fileinfo.aspx.

You can also directly create .NET objects. For example, you could use the New-Object cmdlet as shown here to access .NET's random number class System.Random:

PSH [D:\foo]: $rand = New-Object  System.Random
PSH [D:\foo]: $rand.next(  )
92298896
PSH [D:\foo]: $rand.next(  )
1722419986
PSH [D:\foo]: $rand2 = New-Object System.Random
PSH [D:\foo]: $rand2.NextDouble(  )
0.370553521611986
PSH [D:\foo]: $rand2.nextdouble(  )
0.561135980561905

If you want to create random numbers that are between two other numbers (e.g., a random number between 1 and 10, or between 4 and 16), you can specify a bottom and top range in a call to .NEXT( ), as shown here:

PSH [D:\foo]: $rand = New-Object System.Random
PSH [D:\foo]: $rand.next(1,10)
7
PSH [D:\foo]: $rand.next(4,16)
14

WMI objects are created using the Get-WMIObject cmdlet. Like .NET objects, WMI objects have properties and methods you can call. Unlike normal .NET objects, you can access WMI objects remotely. There are a very large number of WMI classes, as shown at http://msdn2.microsoft.com/en-us/library/aa394554.aspx.

PowerShell can also access COM objects, which is useful for accessing legacy applications that expose them. An example of this is using WMI to examine the Vista Firewall:

With PowerShell, you can use the firewall COM object to obtain details of the Windows Firewall. Here's a simple example that shows how to get the Firewall COM object and the related Firewall profile, which you can then manipulate:

PSH [D:\foo]: $fw = new-object -com HNetCfg.FwMgr
PSH [D:\foo]: $profile = $fw.LocalPolicy.CurrentProfile

Once you get this object created, you can examine it and determine your firewall setup as follows:

Code View:
PSH [D:\foo]: # determine global open ports (NB there aren't any!)
PSH [D:\foo]: $profile.GloballyOpenPorts | ft name, port
PSH [D:\foo]: # determine authorized applications
PSH [D:\foo]: $profile.AuthorizedApplications | ? {$_.Enabled} | ft name

Name
----
localsrv
SMTPServer
Virtual PC 2007
WS_FTP 95
iTunes
Microsoft Office OneNote
Microsoft Office Groove
PSH [D:\foo]: # determine enabled services
PSH [D:\foo]: $profile.Services | ? {$_.Enabled} | ft name
Name
----
File and Printer Sharing
Network Discovery

PSH [D:\foo]: # determine enabled services (ports)
PSH [D:\foo]: $profile.Services | ? {$_.Enabled} | select -expand GloballyOpenPorts
Name : File and Printer Sharing (NB-Session-In)
IpVersion : 2
Protocol : 6
Port : 139
Scope : 1
RemoteAddresses : LocalSubnet
Enabled : True
BuiltIn : True
Name : File and Printer Sharing (SMB-In)
IpVersion : 2
Protocol : 6
Port : 445
Scope : 1
RemoteAddresses : LocalSubnet
Enabled : True
BuiltIn : True
{remainder of output snipped}


advanced_powershell.html

13.13. Advanced PowerShell

This chapter has given an overview of PowerShell and examined a number of key features. But there are so many more aspects of PowerShell; you could fill books with the information (and indeed several writers have).

Some of the more advanced tasks you can accomplish with PowerShell include:

Update formatting type information

If you are designing your own cmdlets, providers, or applications, you may want to define your new object types, extend existing object types, or modify how an object is displayed by the hosting application. You may also want to change PowerShell's default formatting to suit your own needs. See http://msdn2.microsoft.com/en-us/library/ms714665.aspx for more details on how to create new display XML files and incorporate them into your environment.

Host PowerShell in your own application

The Exchange 2008 management console is an example of this. The EMC natively hosts PowerShell and uses PowerShell to carry out the tasks specified in the GUI. For more information on hosting PowerShell in your own application, see http://msdn2.microsoft.com/en-us/library/ms714661.aspx.

Add or amend cmdlet help information

You can write help information for your own cmdlets or extend the help information for existing cmdlets. See http://msdn2.microsoft.com/en-us/library/aa965353.aspx for more information.

Write cmdlets in script

You can use PowerShell to write pipeline-aware functions, in effect cmdlets using scripts. For a good explanation of how to achieve this, see http://www.leeholmes.com/blog/AcceptingPipelineInputInPowerShellScriptsAndFunctions.aspx.

Extend PowerShell with additional snap-ins and new providers

If PowerShell cmdlets or providers do not provide you with what you need, or if you are creating your own LOB applications and want PowerShell support, you can easily add new cmdlets and providers. See http://msdn2.microsoft.com/en-us/library/ms714598.aspx for information on creating cmdlets and see http://msdn2.microsoft.com/en-us/library/ms714636.aspx for more details on writing your own providers.


learning_more_about_powershell.html

13.14. Learning More About PowerShell

PowerShell is a very rich and potentially complex product—or it can be, if you start to take into account some of the advanced options described in the previous list. There is a large amount of material available to help you learn more about PowerShell, including books, web sites/blogs, and training courses.

PowerShell-related books include:

  • Bruce Payette, Windows PowerShell in Action (Manning Publications)

  • Don Jones and Jeffrey Hicks, PowerShell: TFM (Sapien Press)

  • PowerShell e-book (http://download.microsoft.com/download/a/9/4/a94270c7-ed16-4c72-8280-658c66315719/Windows%20Powershell%20-%20EN.zip); samples of this e-book are available at http://download.microsoft.com/download/a/9/4/a94270c7-ed16-4c72-8280-658c66315719/PowerShell-Demofiles.zip

Here are some PowerShell-related web sites and blogs:

  • Windows PowerShell Team Blog (http://blogs.msdn.com/powershell/default.aspx)

  • The PowerShell Guy (http://thepowershellguy.com/blogs/posh/)

  • Keith Hill's blog (http://keithhill.spaces.live.com/)

  • Thomas Lee's Under The Stairs blog (http://tfl09.blogspot.com)

  • Reskit.net (http://www.reskit.net.powershell)

  • Microsoft's PowerShell Script repository (http://www.microsoft.com/technet/scriptcenter/scripts/msh/default.mspx?mfr=true)

There are also a number of training classes to consider. First, there's the Microsoft Official Course 6434, which is due for release early in 2008. This is a three-day, hands-on introduction to the fundamentals of PowerShell for Windows Server 2008 administrators.

Sapien Press has a set of three courses (PowerShell Fundamentals, a two-day class; PowerShell Intermediate, a one-day class; and PowerShell Advanced, a two-day class). These are run by a variety of providers worldwide, including Global Knowledge across Europe and the Middle East. There is also likely to be a variety of additional local courses you can find.

There is a wealth of functions, cmdlets, providers, and other tools you can download and use. Sources include:

Quest AD cmdlets

Quest has produced a set of free downloadable cmdlets you can use to access Active Directory. You can download these for free from http://www.quest.com/activeroles-server/arms.aspx.

PowerShell Community Extensions

Free extensions to PowerShell that provide a widely useful set of additional cmdlets, providers, aliases, filters, functions, and scripts. You can get these at http://www.codeplex.com/PowerShellCX.

Reskit.net

Some sample scripts and other reference material at http://www.reskit.net/powershell.

PowerGUI

A nice editing tool for developing PowerShell Scripts. This is free and can be found at http://powergui.org/downloads.jspa.


the_last_word-id12.html

13.15. The Last Word

PowerShell is an amazingly rich and useful product. It's aimed at administrators of all types and is designed to work with just about all current Microsoft and third-party applications. And if you don't find what you need, PowerShell enables you to add new functions and features relatively easily. In short: PowerShell rocks!


hyper-v.html

Chapter 14. Hyper-V

Companies of all sizes worldwide are looking to virtualization as a seemingly game-changing scenario. Server consolidation, energy efficiency, simpler management and deployment, and increased capacity are all tangible benefits to be gained from a move to virtual servers and virtually hosted services. Microsoft has seen the light and is here to help with Hyper-V (formerly known by its codename, "Viridian," or by the previous brand name, Windows Server Virtualization), which, according to the company, "is a next-generation Hypervisor-based virtualization platform integrated with the operating system that allows you to dynamically add physical and virtual resources."

You might know about virtualization in general, but you might not be familiar with what the buzz is about. Let's break Hyper-V down in this chapter: how it works, its major benefits, and when you can expect to be able to deploy this feature in production environments. I'll also present a virtualization strategy outline as you consider how to integrate Hyper-V or other virtualization technologies into your workflow.

The idea behind this chapter is to give you a fresh look at Hyper-V in its prerelease state as close to the release of Windows Server 2008 as possible. Some of the information and specific procedures in this chapter may change before Hyper-V is released to the public, but the architecture information and the general steps to manage Hyper-V should be very similar.

14.1. How It Works

To understand Hyper-V, consider its three main components: the hypervisor, the virtualization stack, and the new virtualized I/O model. The Windows hypervisor basically acts to create the different "partitions" that each virtualized instance of code will run within. The virtualization stack and the input/output (I/O) components provide interactivity with Windows itself and the various partitions that are created.

All three of these components work in tandem. Using servers with processors equipped with Intel VT or AMD-V enabled technology, Hyper-V interacts with Hypervisor, which is a very small layer of software that is present directly on the processor. This software offers hooks into the management of processes and threads on the processor that the host operating system can use to efficiently manage multiple virtual machines, and multiple virtual operating systems, running on a single physical processor. Since there are no third-party software products or drivers to install, you get nearly guaranteed compatibility without the difficult problems that software bugs can introduce into your system.

Along with efficient process management, you can hot-add resources to the machine hosting your virtualized services. From processors to memory to network cards to additional storage media, you can add these devices to the machine without needing to bring down any services and interrupt user sessions. You can also host 64-bit guest sessions, which is a big boon to organizations moving toward adoption of 64-bit software. You can virtualize your migration, save money on deployment costs, and then assess how many physical machines you'll need when you finish your migration.

14.1.1. High Availability

Part of the idea behind virtualization is not only to eliminate machine duplication and save on costs, but also to ensure that services are more available than they otherwise would be on unvirtualized servers. In that context, Hyper-V includes support for clustering across multiple guests. Additionally, you can cluster multiple physical machines running the Hyper-V component, so that virtualized instances can fail over to another host should something occur with the primary host. Finally, you can migrate virtualized guests from one physical host to another with no downtime, easing servicing, planning, and reorganization, while significantly limiting detrimental effects on production services. You can also take advantage of the new disk quorum features in Windows Server 2008, which allow you to have clusters in multiple locations—say, on both coasts of the U.S., or on different continents across the world—without necessarily having to have a single shared disk between them, something that's required for clustering using Windows Server 2003.

Additionally, you can install Hyper-V on a Server Core installation of Windows Server 2008 and take advantage of the stability and reduced overhead benefits (which are, of course, tangential with high availability objectives) of that style of deployment as well.


how_it_works-id2.html

Chapter 14. Hyper-V

Companies of all sizes worldwide are looking to virtualization as a seemingly game-changing scenario. Server consolidation, energy efficiency, simpler management and deployment, and increased capacity are all tangible benefits to be gained from a move to virtual servers and virtually hosted services. Microsoft has seen the light and is here to help with Hyper-V (formerly known by its codename, "Viridian," or by the previous brand name, Windows Server Virtualization), which, according to the company, "is a next-generation Hypervisor-based virtualization platform integrated with the operating system that allows you to dynamically add physical and virtual resources."

You might know about virtualization in general, but you might not be familiar with what the buzz is about. Let's break Hyper-V down in this chapter: how it works, its major benefits, and when you can expect to be able to deploy this feature in production environments. I'll also present a virtualization strategy outline as you consider how to integrate Hyper-V or other virtualization technologies into your workflow.

The idea behind this chapter is to give you a fresh look at Hyper-V in its prerelease state as close to the release of Windows Server 2008 as possible. Some of the information and specific procedures in this chapter may change before Hyper-V is released to the public, but the architecture information and the general steps to manage Hyper-V should be very similar.

14.1. How It Works

To understand Hyper-V, consider its three main components: the hypervisor, the virtualization stack, and the new virtualized I/O model. The Windows hypervisor basically acts to create the different "partitions" that each virtualized instance of code will run within. The virtualization stack and the input/output (I/O) components provide interactivity with Windows itself and the various partitions that are created.

All three of these components work in tandem. Using servers with processors equipped with Intel VT or AMD-V enabled technology, Hyper-V interacts with Hypervisor, which is a very small layer of software that is present directly on the processor. This software offers hooks into the management of processes and threads on the processor that the host operating system can use to efficiently manage multiple virtual machines, and multiple virtual operating systems, running on a single physical processor. Since there are no third-party software products or drivers to install, you get nearly guaranteed compatibility without the difficult problems that software bugs can introduce into your system.

Along with efficient process management, you can hot-add resources to the machine hosting your virtualized services. From processors to memory to network cards to additional storage media, you can add these devices to the machine without needing to bring down any services and interrupt user sessions. You can also host 64-bit guest sessions, which is a big boon to organizations moving toward adoption of 64-bit software. You can virtualize your migration, save money on deployment costs, and then assess how many physical machines you'll need when you finish your migration.

14.1.1. High Availability

Part of the idea behind virtualization is not only to eliminate machine duplication and save on costs, but also to ensure that services are more available than they otherwise would be on unvirtualized servers. In that context, Hyper-V includes support for clustering across multiple guests. Additionally, you can cluster multiple physical machines running the Hyper-V component, so that virtualized instances can fail over to another host should something occur with the primary host. Finally, you can migrate virtualized guests from one physical host to another with no downtime, easing servicing, planning, and reorganization, while significantly limiting detrimental effects on production services. You can also take advantage of the new disk quorum features in Windows Server 2008, which allow you to have clusters in multiple locations—say, on both coasts of the U.S., or on different continents across the world—without necessarily having to have a single shared disk between them, something that's required for clustering using Windows Server 2003.

Additionally, you can install Hyper-V on a Server Core installation of Windows Server 2008 and take advantage of the stability and reduced overhead benefits (which are, of course, tangential with high availability objectives) of that style of deployment as well.


getting_started_with_hyper-v.html

14.2. Getting Started with Hyper-V

To get started with Hyper-V, you'll need some hardware—specifically, a machine capable of supporting a 64-bit operating system. You need a clean installation of Windows Server 2008 Enterprise Edition in the 64-bit version, as it will not run within a virtual machine because of the need for hardware-assisted virtualization.

Once you have accumulated the hardware, take a few precautions, since you are working with prerelease software. Specifically:

  • Back up all data on your system.

  • Take an inventory of any virtual machines you are thinking of migrating to your Hyper-V machine, including all of their virtual hardware settings.

  • Back up any virtual hard disks (VHDs) that you may migrate as well.

  • Enable hardware-assisted virtualization. This is usually found in your computer's BIOS, and you may need to consult the manufacturer or the documentation that came with your machine to find the appropriate feature name and how to enable it.

  • Install Windows Server 2008. For our purposes, we'll be using the full installation option, although Hyper-V can be used on a Server Core installation.

  • Do not install another role onto the target machine. Hyper-V should be the only role used on a machine that will host virtual machines. In particular, with one build of Hyper-V prerelease, you receive a blue screen error if you try to start a virtual machine on a host with Active Directory Domain Services installed.

14.2.1. Installing the Hyper-V

Now that you're ready, let's install the Hyper-V role. Log in as an administrator and then do the following:

  1. Start Server Manager from the Administrative Tools menu off the Start menu.

  2. Under Roles Summary, click Add Roles, and then select Hyper-V.

  3. Follow the rest of the wizard. You do not have to allow virtual machines to access network resources, although one network card needs to be selected, so that it can be bound to a virtual switch. You'll also get a warning if your computer has only a single network adapter; two are recommended.

  4. Restart the computer once the wizard has completed.

  5. Once the system is restarted, reload Server Manager, expand Roles in the left pane, and choose Hyper-V.

  6. In the right pane, verify that "vhdsvc" and "vmms" are running. If they are, the installation of the Hyper-V role completed successfully.

If you are using the Server Core installation option, installation is very simple. Use the following command at the command line, and restart when prompted.

start /w ocsetup Microsoft-Hyper-V

14.2.2. Getting Acquainted with Hyper-V Management Tools

You can manage most of Hyper-V's settings and configuration from within the Hyper-V Manager MMC console. Figure 14-1 shows the Hyper-V Manager console, accessible in the Administrative Tools group off the Start menu.

Figure 14-1. The Hyper-V Manager console

The Hyper-V Manager console can be used to manage the Hyper-V role installed on the local computer or another, remote computer. During the prerelease stages, you're not able to use Hyper-V Manager over a Remote Desktop connection from another computer.

To create a new virtual machine:

  1. Launch the New Virtual Machine manager within the Hyper-V Manager console.

  2. The Before You Begin screen appears. You can create a virtual machine here without completing the rest of the wizard; if you click Finish, a new virtual machine will show up with a default configuration. Otherwise, click Next.

  3. The Specify Name and Location screen appears. Here, choose a name for your virtual machine and the path where it should be stored. Click Next.

  4. The Assign Memory screen appears. Make sure you specify an appropriate amount of memory to allocate to the VM. Click Next.

  5. The Configure Networking screen appears. You can connect this machine to virtual networks that you have created elsewhere, or you can leave the virtual machine disconnected. Click Next.

  6. The Connect Virtual Hard Disk screen appears. You can connect a new virtual hard disk or an existing one to this new virtual machine. Click Next.

  7. The Installation Options screen appears. If you want to install your guest OS just after completion of this wizard, specify the path to the installation disc for that OS here. Click Next.

  8. Click Finish after reviewing your settings to close the wizard.

When creating new virtual machines, there are some items to consider. For one, Hyper-V supports both 32- and 64-bit guest operating systems, and will support a variety of storage mechanisms, including iSCSI and SANs over fiber channel. You can allocate up to 64 GB of memory to any given virtual machine, and you can enable an integrated virtual switch to eliminate the need to traverse the virtual-physical-virtual layers in order to get network interface activity done.

If you are using the early prerelease version of Hyper-V, you'll get good results from using either Windows Server 2003 or Windows Server 2008. SUSE Enterprise Linux Server 10 with Service Pack 1 has also been tested and recommended for use. Other operating systems may work, but you may suffer performance and compatibility difficulties while running on a prerelease version of Hyper-V. You can also, on the prerelease version, only run four virtual processors with a guest copy of Windows Server 2008, or one virtual processor with any other guest operating system.

14.2.3. Removing Hyper-V

Removing Hyper-V at this stage is quite simple: simply load Server Manager, and in the right pane under Roles Summary, click Remove Roles. Then, select Hyper-V in the Remove Roles Wizard, and restart the system, and your installation is complete.

If you're a best practices follower, you can now install other roles onto this machine without necessarily having to blow away your current installation, although since Hyper-V is prerelease software that is installed in the most fundamental parts of your system, it might be smart not to trust production data to it.


virtualization_strategy.html

14.3. Virtualization Strategy

Virtualization—the move from real, physical hardware to virtual hardware—is seen as one of the "next big things" in IT. And Hyper-V is certainly fantastic software, even in its prerelease state. But if you're new to this party, you might not know how to get started.

A lot of professionals have asked me what a valid strategy is for introducing virtualization, in production, into their organization, and I've written about this in Computerworld. Here's a freshened version of the workflow and procedure I recommend for assessing whether virtualization is right for you and, if it is, for getting things moving.

  1. Determine whether your servers are ripe for consolidation. Consolidating hardware is the number one reason for considering virtualization. Aging hardware, bursting data centers, and burgeoning power needs have all played a part in the move to virtualization. Why should you continue to acquire distinct physical machines when you can move real servers to even bigger machines at ratios of 3-to-1 or even 10-to-1?

    The first step in virtualization is determining whether you have the right type of infrastructure to support it. Look for a lot of machines doing similar tasks and make sure you have more than 10 of them. For 10 or fewer, the payoff is questionable.

  2. Get the administrative headaches out of the way. Any complex move like server consolidation is likely to affect some internal processes. As in any major project, it's important to get stakeholder support and management buy-in. You'll most likely need to present a business case for moving to virtual services, including total financial outlay and money saved. You may also have to address staffing: as the number of physical servers is reduced, some budgets dictate that staff size must be reduced proportionally. You may be required to anticipate workloads and quantify the effect that fewer physical servers—but more virtual servers—would have on your department's overall workload.

    Also, examine your licensing needs. Depending on which software you'll be running on your virtual machines and what their configurations are, you may need to adjust licensing.

  3. Select your hardware and software. There are several choices at a variety of prices. It all comes down to whether you need simple server consolidation or advanced hosting and network configuration capabilities. Several vendors have starter kits that let you pilot and explore the technology for a relatively low cost.

  4. Start moving to virtualization. When the time comes to actually move from physical to virtual, there are some migration tools that can help. Microsoft will soon release tools that let you move a fully installed server running a supported version of Windows to a virtual hard-disk format that is fully supported by its Virtual Server product. VMware has a similar tool in the works. These migration utilities can save you hours, if not days, when you're performing the actual move. Other things to consider:

    • Take advantage of clustering capabilities. Using high-performance clusters gives your virtual machines higher availability and improved performance.

    • Think about management. How will your staff manage the virtual machines? What scripting languages and APIs does your virtual server software support? Are you able to access certain controls via the command line for simple remote-access-based administration?

    • Don't forget about storage. You'll need a very fast disk subsystem to get maximum performance from your virtualized servers. Typically, you'll find that iSCSI-based disk offerings are a good value. They are fast, reasonably priced, and have great configurability.

  5. Monitor, assess, tweak, and improve. When the final boot into the virtualized operating system is finished, your job still isn't over. Keep tabs on the project as you begin moving users and services to the new platform. Establish performance and usage guidelines and thresholds, monitor them, and tie those metrics to future enhancements. Consider tweaking hardware configurations and network setups or increasing bandwidth as needed.


the_last_word-id13.html

14.4. The Last Word

So, when can you get your hands on all of the features and benefits of Hyper-V? The good news is, you can get started exploring the product today: there is a beta release available right now, which you can download at Microsoft.com. Microsoft plans to sign off on the final build of Hyper-V within 180 days of the release to manufacturing of Windows Server 2008, and it will offer multiple SKUs of Windows Server 2008, with and without Hyper-V included in the box.

If you're concerned about the time and money you've invested in your virtualization infrastructure already, you'll be pleased to know that users of Microsoft Virtual Server 2005 can move relatively seamlessly over to Hyper-V when it's ready, without losing the effort put in to Virtual Server thus far. However, you may need some new hardware in some instances, as Hyper-V will require 64-bit hardware and will not be released in an x86 (32-bit) edition.

Hyper-V is the natural next step in Microsoft's virtualization story. With properly equipped hardware, you stand ready to enjoy a number of benefits that weren't possible before.


colophon.html

Appendix. Colophon

The animal on the cover of Windows Server 2008: The Definitive Guide is an albatross (Diomedeidae). Albatrosses are among the largest of the seabirds; the wandering albatross (Diomedea exulans) weighs up to 20 pounds and has a wingspan of almost 12 feet. Widely considered the most majestic of Antarctic birds, albatrosses have long, narrow wings and large heads with distinctive hooked bills. Though their coloring varies somewhat depending on species, albatrosses are typically white with gray, brown, or black accents.

Albatrosses are highly efficient gliders, effortlessly covering thousands of miles in a day as they forage for fish, squid, and krill. In fact, one grey-headed albatross (Diomedea chrysostoma) is on record as circumnavigating Antarctica in just 46 days. An albatross's wings have the unique ability to "lock" into an extended position, thereby reducing the strain of such long-distance travels. Albatrosses are best observed during rough weather, when high waves create powerful uplifting air currents that enable them to remain aloft with hardly a wing beat for several hours. Wandering albatrosses are known to follow visiting ships in the Southern Ocean, and indeed they have a long history with seafarers. In folklore, they were thought to carry the souls of dead mariners; should a sailor kill the bird, bad luck would fall upon him for the rest of his natural life.

Many albatross species are currently threatened. Biologists report that almost 100,000 of the birds are killed every year by fishing fleets, many of which are illegal. Wandering albatrosses get caught on baited long-line hooks set by tuna fisherman, and are pulled under the water and drowned. Fatal collisions with trawl net cables are also a factor in their steadily dwindling numbers. Governments, conservationists, and the fishing industry have worked together to develop solutions to combat this problem, such as weighted lines that sink quickly and are thus less visible to albatrosses, or brightly colored "tori" lines that startle the birds away from the vessels.

The cover image is from Wood's Animate Creation. The cover font is Adobe ITC Garamond. The text font is Linotype Birka; the heading font is Adobe Myriad Condensed; and the code font is LucasFont's TheSans Mono Condensed.


index.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]


SYMBOL.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

.NET Framework
application pools and
IIS support
PowerShell support 2nd 3rd
Server Core and
Windows Server 2008 support
.NET objects 2nd


A.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

A (host) records
DHCP and 2nd
DNSLint support
dynamic DNS and
entering into zones
functionality
glue records
ABE (access-based enumeration) 2nd
ACC (Automatic Client Configuration)
access-based enumeration (ABE) 2nd
account lockout policies 2nd 3rd
ACLs (access control lists)
anonymous users
effective permissions
GPO support 2nd
activation, product
Active Directory
auditing communications
creating namespaces
DHCP support
DNS support 2nd
domain controller replication
fault tolerance support
file services support
Group Policy network options
LDS feature 2nd 3rd
publishing shares 2nd
replication groups
RODC support
Server Core support 2nd
split DNS architecture
SRV records and
TS support 2nd
Windows Server 2008 support
Active Directory Domains and Trusts tool 2nd
Active Directory Services Interface (ADSI)
Active Directory Sites and Services tool
functionality
GP guidelines
replication topologies 2nd
site links
Active Directory Users and Computers (ADUC) tool
Account tab
Address tab
administrative tasks
auditing support
COM+ tab
configuring user environment 2nd
creating groups 2nd 3rd
creating users
Dial-in tab
Environment tab
functionality
General tab 2nd
infrastructure master role
logon time restriction
Member Of tab
Members tab
moving PDC emulator role
moving RID master role
Organization tab
Profile tab
Remote Control tab
Sessions tab
Telephones tab
Terminal Services Profile tab
TS support
Active Directory-integrated zones 2nd
AD DS (Active Directory Domain Services)
cleaning directory metadata 2nd
components supported
contacts
defragmenting NTDS database 2nd
delegation support
domain controllers
domains 2nd 3rd
event logs
forests
functionality
global catalog
groups 2nd 3rd
Hyper-V support
Installation Wizard
maintenance considerations
managing users
operations master roles
organizational units 2nd
restarting
Restore Mode password
RODC support
Server Core support 2nd
shared folders
shared printers
sites
tools supported 2nd 3rd
trees
troubleshooting
Add Features Wizard
Add Roles Wizard 2nd 3rd
ADMIN$ default share
administration utility 2nd 3rd
administrative shares
Administrative Tools applet
Administrator account 2nd 3rd
Administrators group
creating shared folders
DNSCmd utility
example deployment
Group Policy network options
NTFS permissions
adprep command
ADSI (Active Directory Services Interface)
ADSI Edit
affinity (NLB)
alerts (FSRM) 2nd
Alias provider (PowerShell)
aliases
cmdlet support 2nd
CNAME records as 2nd
virtual directories and
Allow permission
Deny permission and
inheritance and 2nd
ANONYMOUS USER account
Apache web server
APIPA (Automatic Private IP Addressing)
APIs (application programming interfaces)
ISAPI 2nd 3rd
RSoP support
VSS support
AppCmd.exe utility 2nd 3rd
Append Data special permission 2nd
Application log 2nd
application pools
Application Server role (IIS) 2nd
applicationHost.config file
applications
defining object types
server clustering and
Server Core support
server security and
web
Apply Group Policy permission
ASP.NET 2nd
associations 2nd
attributes
defined
DHCP options
domain controllers updating
group support
password policies
version numbers and
auditing
AD DS support 2nd
Group Policy network options
object access 2nd
options for policies
recommended items
Authenticated Users group
authentication
auditing support
automatic logoff and
IIS support
Kerberos protocol 2nd
logon process and
NAP support
network level authentication
spoofing and
unauthorized access and
Windows Firewall with Advanced Security
authoritative nameservers
defined 2nd
SOA records and 2nd
split DNS architecture
TTL default values
authorization
Automatic Client Configuration (ACC)
automatic logoff
Automatic Private IP Addressing (APIPA)
automatic updates
availability
Hyper-V and
server security and
AXFRs (full zone transfers) 2nd


B.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

backup domain controllers (BDCs) 2nd 3rd
backup procedure
DNS support 2nd
GPO support
shadow copy support
backward compatibility
BAT file extension
BDCs (backup domain controllers) 2nd 3rd
BIOS
PowerShell support
virtualization support
BitLocker feature
functionality
Server Core support 2nd
boot images
Boot menu
Bourne shell


C.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

C$ default share
C-shell
caching
IIS support
managing offline folders
RODC support 2nd
switches and
CAPs (connection authorization policies)
capture images 2nd
Capture Utility (WDS)
CardSpace web technology
centralized configuration
certificate authorities
Certificate provider (PowerShell)
change logon utility
Change Permissions permission 2nd
change port utility
change user utility
child domains
adding
cleaning directory metadata
trees and
child objects
CIA principle of server security
Class A address class
Class B address class 2nd
Class C address class
classes
defined 2nd
DHCP support
Clear-Item cmdlet
Clear-ItemProperty cmdlet
ClearType font
client side extensions (CSEs)
CLR (common language runtime)
clussvc command
cluster utility
clustering
command-line utilities
fault tolerance and
NLB support 2nd
server clusters 2nd
Server Core support 2nd
terminology 2nd 3rd
types supported
Windows Server 2008 support
CMD.EXE shell
cmdlets (PowerShell)
adding help information
defined
defining object types
downloadable
functionality
getting help 2nd
pipelines
script support 2nd
standard cmdlets listed
Cn attribute (password policy)
CNAME (canonical name) records
aliases and 2nd
DNSLint support
functionality
manipulating
COM file extension
COM objects
PowerShell support 2nd 3rd
registering
comma-separated values (CSVs)
command shells
command-line utilities
AD DS support 2nd 3rd
DNS support
file services
Group Policy support
IIS support 2nd
server cluster support
Server Core support
TS support
TSM support
commenting (GPMC)
common language runtime (CLR)
compliance policies 2nd
compression
computer policies
device installation control
GPO support
logon time restriction
managing firewalls
offset interval
refresh interval
refreshing
software installation
storage location
conditional forwarding
confidentiality, server security
configuration
centralized
disk quotas
file servers
FSRM 2nd
IIS improvements 2nd
initial installation tasks
NAP
script support
secondary nameservers 2nd
Server Core
WDS
Configure Your DNS Server Wizard
connection authorization policies (CAPs)
contacts, AD DS
Copy-Item cmdlet
Copy-ItemProperty cmdlet
cprofile utility
CPU speed requirements
Create Files special permission
Create Folders special permission 2nd
CSEs (client side extensions)
CSVs (comma-separated values)
Ctrl-Alt-Del combination


D.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

data stores
data-level security
Date and Time applet
DC security.inf file
dcpromo utility
adding domains
building first domain
RODC support
Server Core support
DCPROMO Wizard
dead gateway detection algorithm
dedicated forest root model 2nd
default domain controller policy 2nd
default domain policy 2nd 3rd
default shares
DefaultRegistrationRefreshInterval value (Registry)
defragmenting NTDS database
delegation
AD DS support
defined 2nd 3rd 4th
domains
Group Policy administration 2nd
lame 2nd
name resolution
organizational units and
Delegation of Control Wizard
Delete Shadows command
Delete special permission 2nd
Delete Subfolders and Files permission 2nd
Deny permission
Allow permission and
assigning
IIS support
inheritance and 2nd
deployment
example 2nd
fine-tuning properties
GP considerations 2nd
redeploying software
removing software
Server Core 2nd
services packs with GP
WDS support 2nd
WIM support
DES encryption
Detailed Directory Service Replication event
DFS (Distributed File System)
event logs
fault tolerance and
folder redirection and
functionality 2nd
replication support 2nd 3rd
Server Core support
DFS Namespace Server
DFS namespaces
adding folders
creating
functionality
publishing shares
DFS Replication log
DFSR (Distributed File System Replication) 2nd
DHCP (Dynamic Host Configuration Protocol)
authorizing servers
classes and
clustering support
conflict detection
creating new scope
DNS and
dynamic DNS and
functionality
installing servers
reservations
RODC support
Server Core support 2nd 3rd 4th
superscope
WDS requirements 2nd
DHCPACK packets
DHCPDISCOVER message
DHCPOFFER packets
DHCPREQUEST packets
DHCPServerCore role
digest authentication
digital signatures
recommendations
scripts and
security policies and
DIR command 2nd 3rd
directories
configuring listings
defined
virtual 2nd
Directory Service Access event
Directory Service Changes event
Directory Service log
Directory Service Replication event
Directory Services Restore Mode
DisableDynamicUpdate value (Registry)
discover images
disk partitions 2nd
disk quotas
configuring
enabling 2nd
feature functionality
fsutil.exe support 2nd
setting default
disks
defined
monitoring capacity 2nd
Offline Files and Folders support
Windows Server 2008 requirements
Distributed File System Replication (DFSR) 2nd
Distributed Transaction Coordinator (DTC)
distribution groups
DLLs (dynamic-link libraries)
DNS (Domain Name System)
Active Directory-integrated DNS
backup and recovery 2nd
building nameservers
command-line utilities
defined
delegation and
DHCP and
domain controller replication
dynamic DNS
forwarding support
functionality 2nd
nameservers
NLB support
resource records
RODC support
Server Core support 2nd
split architecture
subdomains and
troubleshooting GP
WDS requirements
zones versus domains
DNS Management snap-in
DNS Server log
DNSCmd utility 2nd
DNSLint utility
functionality
lame delegation
troubleshooting AD DS
DnsUpdateProxy group
$ (dollar sign) 2nd
dollar sign ($) 2nd
Domain Administrators group
Domain Computers group 2nd
domain controllers
AD DS support 2nd
adding
BDCs 2nd 3rd
default shares
defined
dynamic DNS
GPO support
GPT files
groups supported
logon time restrictions
managing policies
offset interval
operations master roles
originating USNs and 2nd
PDCs 2nd
refresh interval
replication among
RODC 2nd 3rd
script storage
security templates
Server Core support 2nd
updating attributes
USNs and 2nd
version numbers and 2nd
viewing security policies
domain global groups
domain local groups
domain naming master role
domain-based Group Policy
auditing support
deployment considerations
filesystem options
folder redirection
refreshing
Registry options
restricted groups options 2nd
service packs
software installation
domain-based namespaces 2nd
domains
AD DS support 2nd
adding
adding domain controllers
adding to trees
defined 2nd 3rd
delegating
empty domain model 2nd
expiration policy
GPO support
lockout policies
nameservers and
operations master roles
organizational units and 2nd
Server Core support
trees and
trusts and
viewing default policies
zones and
drainstopping
drives
administrative shares
defined
mapped
Drvload utility
DSADD utility 2nd
DSREVOKE tool
DTC (Distributed Transaction Coordinator)
dynamic DNS
domain controllers and
functionality
preventing registration 2nd
scavenging
triggering registration
dynamic-link libraries (DLLs)


E.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

EFS (Encrypting File System) 2nd 3rd
email notifications 2nd
EMC (Exchange Management Console)
empty domain model 2nd
Encrypting File System (EFS) 2nd 3rd
encryption
BitLocker support 2nd 3rd
EFS support 2nd 3rd
firewalls and
Group Policy network options
Server Core support
TS support
Enterprise Admins group
authorizing DHCP servers
delegating GP
domain naming master role
managing GP across forests
Environment provider (PowerShell)
event logs
detailed
disk-based quotas
Event Viewer
Group Policy network options
IIS support
options for policies 2nd
recommended audits
Event Viewer
Exchange Management Console (EMC)
Exchange Server (Microsoft)
EXE files 2nd
Execute File special permission
expiration date 2nd
Explorer GUI
exporting
GPOs
zones to files


F.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

failback policy 2nd
failed requests, tracing
Failover Cluster Management
Failover Cluster Validation Report
failover policy 2nd
fast logon optimization
FastCGI
FAT filesystem
auditing support
disk quotas
fault tolerance
Active Directory support
clustering and
DFS support
file servers
FAZAM tool
FC (Full Control) permission 2nd
FDDI protocol
Federal Information Processing Standard (FIPS)
file groups
File Replication Service log
file services
clustering support
command-line utilities
creating shares manually
default shares
DFS support 2nd 3rd
disk-based quotas
File Server Resource Manager
functionality
hidden shares
key features
NTFS permissions
Offline Files and Folders 2nd
previous versions
publishing shares 2nd
Server Core support 2nd
setting up file sharing
file sharing
creating shares manually
default shares
examples 2nd
hidden shares
offline files
permission considerations
publishing shares 2nd
setting up services
file types
FSRM screening support
PowerShell supported
file-level permissions
ABE support
auditing
defined
determining effective 2nd
functionality
inheritance/ownership
security and
setting
files
auditing access
exporting zones to
offline 2nd
renaming
FileSystem provider (PowerShell)
filesystems
auditing support
network environment
PowerShell example
security policies
filtering
firewalls and
GPMC support
WMI filters 2nd 3rd
FIPS (Federal Information Processing Standard)
firewalls
examining setup
installation considerations
schema master role and
slaving process and
split DNS architecture 2nd
Windows Firewall with Advanced Security
Windows Server 2008 support
flattemp utility
FlowControlChannelBandwidth value (Registry)
FlowControlDisplayBandwidth value (Registry)
folder redirection
functionality
groups and
IntelliMirror support
removing policies
folder-level permissions
ABE support
auditing
defined
determining effective 2nd
functionality
inheritance/ownership
security and
setting
folders
adding to namespaces
auditing access
creating replication groups
offline 2nd 3rd
shared
temporary
font smoothing 2nd
forests
dedicated root model 2nd
defined 2nd
group support
managing GPs across
transitive trusts
trees and 2nd
Format-Custom cmdlet 2nd
Format-List cmdlet 2nd 3rd
Format-Table cmdlet 2nd 3rd
Format-Wide cmdlet 2nd
forward lookup zones 2nd 3rd
Forwarded Events log
forwarding
conditional
defined
setting up
slaving and 2nd
FQDN (fully qualified domain name)
CNAME records
defined
delegating domains
MX records
NS records
PTR records
FSRM (File Server Resource Manager)
accessing
configuring
configuring quotas 2nd
functionality
screening file types
storage reports
fsutil.exe utility 2nd
Full Control (FC) permission 2nd
full zone transfers (AXFRs) 2nd
Function provider (PowerShell)


G.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

GCI command
Generic Service resource type
Get-ChildItem cmdlet 2nd
Get-Command cmdlet
Get-Hash cmdlet
Get-Help cmdlet 2nd 3rd 4th
Get-History cmdlet
Get-Host cmdlet
Get-HTTP cmdlet
Get-Item cmdlet
Get-ItemProperty cmdlet
Get-Member cmdlet 2nd
Get-Process cmdlet 2nd
Get-WMI cmdlet
Get-WMIObject cmdlet 2nd
Global Assembly Cache
global catalog (GC)
AD DS support
defined
domain naming master role
schema master role
SRV records and
globally unique identifier (GUID) 2nd 3rd
glue record
GPMC (Group Policy Management Console)
administrative tasks
commenting
controlling GPO scope
creating/editing GPOs 2nd
Delegation tab
Details tab
disabling portions of policies 2nd
filesystem and Registry policy
filtering
GP preferences
GPO inheritance
managing GP across forests
manipulating GPOs
navigating
policy enforcement over networks
refreshing policies
restricted groups policy
RSoP support
Scope tab
Settings tab
starter GPOs
troubleshooting with
WMI filters
GPOs (Group Policy Objects)
account lockout policies
backing up
Block Policy Inheritance option 2nd
controlling scope
copying
creating/editing 2nd
default
defined
deployment considerations
disabling portions 2nd
Enforced option
exporting
implementation guidelines
importing
inheritance and
managing security settings
modifying auditing properties
protected Registry keys
refreshing policies
searching for 2nd
Server Core support
software restriction policies
starter GPOs
transform files and
troubleshooting
WMI filters
GPOTOOL tool
GPRESULT tool 2nd
GPT file extension
GPUPDATE utility 2nd
grace writes
Greenwich Mean Time
Group Policy (GP)
Active Directory support
administrative tasks
ADUC support
auditing support 2nd
command-line utilities
components 2nd
Computer Configuration node
delegating administration 2nd
deploying service packs
deployment considerations 2nd
device installation control
disabling portions 2nd
dynamic DNS registration
enforcing
functionality
GPO inheritance
GPO scope
implementation guidelines
local GP
management tools
managing across forests
manipulating preferences
MSI file support
network security options
organizational units
organizing
password policies
PowerShell support
refreshing
RSoP support
script support
Server Core support 2nd
software restriction policies
troubleshooting
TS support
User Configuration node
WMI filters
Group Policy Creator Owners group
Group Policy Modeling Wizard
Group Policy Object Editor
Advanced tab
Categories tab
deployment properties
Deployment tab
example deployment
folder redirection 2nd
General tab 2nd
logon/logoff scripts
Modifications tab
patching deployment
Security tab 2nd
startup/shutdown scripts
Target tab
Upgrades tab
Group Policy Preferences feature
Group Policy Results Wizard
Group Policy Slow Link Detection policy
GroupPolicyRefreshTime value (Registry)
GroupPolicyRefreshTimeDC value (Registry)
GroupPolicyRefreshTimeOffset value (Registry)
GroupPolicyRefreshTimeOffsetDC value (Registry)
groups
AD DS support 2nd
administrative tasks
authorization rules
creating
defined
distribution
file
folder redirection and
forests as
nesting 2nd
replication
restricted 2nd 3rd
scopes listed 2nd
universal 2nd
user classes and
Guest account 2nd 3rd
GUID (globally unique identifier) 2nd 3rd


H.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

HAL (hardware abstraction layer)
hardware
detecting x64-based
device installation control
product activation and
Windows Server 2008 requirements
hardware abstraction layer (HAL)
Hardware Events log
Health Insurance Portability and Accountability Act (HIPAA)
health policies 2nd 3rd
Hello World script
Hicks, Jeffrey
High Availability Wizard
Hill, Keith
HIPAA (Health Insurance Portability and Accountability Act)
hisecdc.inf file
hisecws.inf file
host-level security
hostnames
entering records into zones
name resolution 2nd 3rd 4th
resource records and
reverse lookup zones
HTTP status code
HTTPS protocol 2nd 3rd
hubs, switches and
Hyper-V
basic architecture 2nd
components
high availability
installing
management tools
precautions starting
removing
Server Core support 2nd
hypervisor 2nd
- (hyphen) 2nd
hyphen (-) 2nd


I.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

IANA (Internet Assigned Names Authority)
ICANN (Internet Consortium of Assigned Names and Numbers)
IEEE 802.1x standard 2nd
iesacls.inf file
IIS (Internet Information Services)
adjusting web site properties
application pools
centralized configuration
clustering support
command-line utilities 2nd
creating web sites 2nd
graphical management utility
improvements 2nd
new architecture
roles
security problems
Server Core support
virtual directories 2nd
Web Management Service
Windows Server 2008 support
IIS Manager
adjusting web site properties
Advanced Settings dialog
application pools
centralized configuration
creating web sites 2nd
depicted 2nd
virtual directories 2nd
Web Management Service
Import Settings Wizard
importing GPOs
in-addr.arpa TLD 2nd
incremental zone transfers (IXFRs) 2nd
Indexing Service 2nd
infrastructure master role
inheritance
defined
GP support
GPOs and
permissions and 2nd
troubleshooting GP
install images 2nd 3rd
installation
AD DS on Server Core
device control
DHCP servers
event logs
Hyper-V
IIS Application Server role
IIS Web Server role
initial configuration tasks
nameserver software
PowerShell 2nd
product activation
script support
Server Core 2nd
software 2nd
steps in process
Terminal Services
unattended
WDS
InstallShield installation software
instances
integrity, server security
IntelliMirror
deploying service packs
folder redirection
MSI file support
software installation
Inter-Site Topology Generator (ISTG)
internal network-level security
Internet Assigned Names Authority (IANA)
Internet Authentication Service
Internet Consortium of Assigned Names and Numbers (ICANN)
Internet Services Application Programming Interface (ISAPI) 2nd 3rd
InterNIC
Introduction to File Services wizard
Invoke-Item cmdlet
IP addresses
DHCP support 2nd 3rd
dynamic DNS
entering records into zones
IIS support
name resolution 2nd 3rd 4th
NAP support
NLB support
resource records and
reverse lookup zones
IPC$ default share
ipconfig /all command
IPSec (IP Security)
firewall support
Group Policy network options
NAP support
networking improvements
Server Core support
server security and
IPv4 protocol
IPv6 protocol
ISA Server
ISAPI (Internet Services Application Programming Interface) 2nd 3rd
iSNS Server
ISTG (Inter-Site Topology Generator)
IUSR account
IXFRs (incremental zone transfers) 2nd


J.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

Jones, Don
JS file extension
Jscript language


K.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

KCC (Knowledge Consistency Checker) 2nd
Kerberos Key Distribution Center (KDC)
Kerberos protocol
AD DS support 2nd
authentication support 2nd
Group Policy network options
viewing security policies
Key Management Service (KMS) 2nd
keywords, filtering by
kiosks
KMS (Key Management Service) 2nd
Knowledge Consistency Checker (KCC) 2nd


L.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

L (List Folder Contents) permission 2nd
lame delegation 2nd
LDAP (Lightweight Directory Access Protocol)
AD DS support
creating users
managedBy concept
SRV records and
LDS (Lightweight Directory Services) 2nd 3rd
lease duration 2nd
Lee, Thomas
license keys 2nd
licensing
reading agreement
software policies and
Terminal Services Configuration
TS support 2nd
Lightweight Directory Services (LDS) 2nd 3rd
List Folder Contents (L) permission 2nd
List Folder special permission
List Shadows command
load balancing
MX records and
round-robin DNS 2nd 3rd 4th
Server Core support
SRV records and
local Group Policy
local security policy
account lockout policies
auditing support
automatic logoff
locking down Windows
password policies
locking down Windows
account lockout policies
local options
network options
password policies
logoff command
logoff process
logoff utility
logon process
auditing 2nd
Ctrl+Alt+Delete combination
displaying usernames
Terminal Services Configuration
loop replication method 2nd
LS command 2nd 3rd


M.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

M (Modify) permission 2nd
MAC addresses
caching
DHCP support
NAP support
product activation and
machine local groups
MAKs (multiple activation keys)
malware 2nd
Manage Policy Links permission
manageability improvements
managed resources 2nd
managedBy concept (LDAP)
map persistency feature
mapped drives
MaskSourceMAC value (Registry)
Master Browser service
MaxCacheEntryTtlLimit value (Registry)
memory
application pools and
Server Core requirements
Windows Server 2008 requirements
mesh replication method 2nd
message queuing
metadata, cleaning 2nd
Microsoft
Exchange Server
Hyper-V 2nd 3rd
PowerShell script repository
Microsoft Compute Cluster provider (PowerShell)
Microsoft Installer packages
Microsoft log
Microsoft Update
mmc command
Modify (M) permission 2nd
modularity, IIS 2nd 3rd
MOF file extension
Move-Item cmdlet
Move-ItemProperty cmdlet
msDS-LockoutDuration attribute
msDS-LockoutObservationWindow attribute
msDS-LockoutThreshold attribute
msDS-MaximumPasswordAge attribute
msDS-MinimumPasswordAge attribute
msDS-MinimumPasswordLength attribute
msDS-PasswordComplexityEnabled attribute
msDS-PasswordHistoryLength attribute
msDS-PasswordReversible-EncryptionEnabled attribute
msDS-PasswordSettings-Precedence attribute
msg command 2nd
MSI file extension
example deployment
packaging software
patching deployment
TS support
MST file extension
multicast mode (NLB) 2nd
multimaster environment
multimaster replication 2nd
multiple activation keys (MAKs)
MX (mail exchanger) records
DNSLint support 2nd
functionality
manipulating
My Documents folder
My Pictures subfolder


N.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

name resolution
changing nameservers
defined
delegating
pointing nameservers
resource records and
zones and 2nd 3rd
nameservers
Active Directory-integrated zones
authoritative 2nd 3rd 4th 5th
building
controlling zone transfers
editing zone files
entering records into zones
expiration date
forward lookup zones
forwarding support 2nd
functionality
incremental transfers
lame delegation
manipulating CNAME records
manipulating MX records 2nd
manipulating NS records
manipulating PTR records
manipulating SOA records
NS record support
refresh interval 2nd 3rd
retry interval 2nd
reverse lookup zones 2nd
round-robin balancing 2nd
slaving process and 2nd 3rd
split DNS architecture
TTL default value
namespaces
adding folders
creating
defined
DFS support
domain-based 2nd
NAP (Network Access Protection)
benefits/drawbacks 2nd
configuring
defined
enforcement mechanisms
functionality
health policy compliance 2nd
health policy validation 2nd 3rd
limiting access 2nd
phased implementation 2nd
processes for sessions
NAQC (Network Access Quarantine Control)
nesting process 2nd
net user utility
NetIQ Group Policy Administrator
NETLOGON default share
netsh command 2nd
netsh interface ipv4 command
Network Access Quarantine Control (NAQC)
network environment
clustering and
configuring security options
folder redirection
improvements
NLB support
policy enforcement
Server Core support
server security
TCP/IP stack enhancements
Terminal Services changes
network interface card (NIC) 2nd
network level authentication (NLA)
Network Load Balancing Manager 2nd
Network Policy and Access Services role
Network Policy Server 2nd
New Certificate Rule
New Delegation Wizard
New Hash Rule
New Internet Zone Rule
New Path Rule
New Scope Wizard
New Zone Wizard 2nd 3rd 4th
New-Item cmdlet
New-ItemProperty cmdlet
New-Object cmdlet
New-PSDrive cmdlet
Next Generation Networking
NFS protocol 2nd
NIC (network interface card) 2nd
NLA (network level authentication)
NLB (network load balancing)
clustering support 2nd
Server Core support 2nd
terminology
Windows Server 2008 support
NLB clusters
adding nodes 2nd
affinity
creating
multicast mode 2nd 3rd
NLB drivers
overview
performance optimization
port rules 2nd 3rd
removing nodes
unicast mode 2nd 3rd
NLB drivers
no-refresh interval
nodes
adding to clusters 2nd
defined
managing
removing from clusters
Notepad 2nd
notifications
FSRM support 2nd
sending via TSM 2nd
zone modification
NS (nameserver) records
delegating domains
functionality
lame delegation
manipulating
nslookup command
NTDS database, defragmenting
NTDSUtil tool 2nd
NTFS filesystem
auditing support
disk quotas
EFS support
enabling disk quotas
security templates
TS support
WDS requirements 2nd
NTFS permissions
ABE support
auditing
creating shares 2nd
defined
determining effective 2nd
functionality
inheritance/ownership
security and
setting


O.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

object access auditing 2nd
objects
defined 2nd
defining types
groups supported
instances of
permission inheritance
PowerShell support
oclist utility
ocsetup command
Offline Files and Folders 2nd
offset interval
One-Note provider (PowerShell)
operating system file protection
OperatingSystemSKU property
operations master roles
defined
domain naming master role
infrastructure master role
PDC emulator master role 2nd
RID master role
schema master role
transferring manually
options (DHCP)
originating USNs
OUs (organizational units)
AD DS support 2nd
adding
defined
deployment considerations
GPO support
publishing shares
Server Core support
Out-Default cmdlet
ownership, permissions and


P.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

parameters, cmdlet 2nd
parent objects
partitions, disk 2nd
passphrases
password management
AD DS support 2nd
Group Policy network options
password expiration prompt
password policies 2nd
Server Core support
Stored User Names and Passwords applet
Password Replication Policy 2nd
password settings object (PSO) 2nd
Payette, Bruce
PDC emulator master role 2nd
PDCs (primary domain controllers) 2nd
performance
IIS support 2nd
improvements 2nd 3rd
NLB clusters
Performance Diagnostics Console
Performance Monitor
perimeter-level security
permissions
ABE support
applying to shared folders
auditing
auditing changes
creating shares manually
determining effective 2nd
domain GPs
example deployment
filesystem and Registry policy
functionality
Group Policy network options
IIS support
inheritance/ownership 2nd
managing GPOs
NAP support
remote control
setting
physical security level
pipeline (PowerShell)
Plug and Play (PnP)
policies, procedures, and awareness-level security
POP3 (Post Office Protocol 3)
port rules (NLB) 2nd 3rd
Post Office Protocol 3 (POP3)
Power Users group 2nd
PowerGUI tool
PowerShell
additional resources 2nd
advanced tasks 2nd
background 2nd
changing formatting
cmdlet support
data stores
extending 2nd
formatting basics
functionality
getting help with 2nd
improvements
installing 2nd
object support
pipeline feature
script support 2nd 3rd
security and 2nd
Server Core and
starting up
variables and
PowerShell providers
pre-boot execution environment (PXE) 2nd 3rd
previous versions
altering schedules
enabling
functionality
restoring
vssadmin.exe support 2nd
primary domain controllers (PDCs) 2nd
primary nameservers
Active Directory-integrated zones
functionality
SOA records and
split DNS architecture
upgrading secondary to
zone transfers and
print services
functionality
key features
server clustering
Server Core support 2nd 3rd
PRINT$ default share
privileges, auditing use 2nd
product activation
product keys 2nd
Provision a Shared Folder Wizard
PS command (Unix)
PS1 file extension 2nd
PS1XML file extension 2nd
PSC1 file extension
PSO (password settings object) 2nd
PTR (pointer) records
DNSLint support
dynamic DNS and
entering records into zones
functionality
manipulating
public keys
PXE (pre-boot execution environment) 2nd 3rd


Q.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

query process command 2nd
query session command 2nd
query termserver command 2nd
query user command 2nd
Quest ActiveRoles tool
Quest.com
quorum
quorum disk 2nd


R.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

R (Read) permission 2nd 3rd
RADIUS protocol 2nd 3rd
random numbers
RDC (Remote Desktop Connection)
Advanced tab
Display tab
Experience tab
functionality
General tab
Hyper-V support
Local Resources tab
new features 2nd
Programs tab
RDP support
TS client-side considerations
RDC (Remote Differential Compression) 2nd
rdesktop RDP client
RDP (Remote Desktop Protocol)
creating connection listeners
restricting connections 2nd
Server Core support
TS support 2nd 3rd
RDP file extension
Read (R) permission 2nd 3rd
Read and Execute (RX) permission 2nd
Read Attributes permission
Read Data permission
Read Extended Attributes permission
Read Permissions permission 2nd
read-only domain controller (RODC) 2nd 3rd
receive-side scaling
recovery procedures 2nd
refresh interval
computer policies
defined
domain controllers
dynamic DNS
GP support
nameservers 2nd 3rd
user accounts
zone transfers
Regional and Language Options applet
register utility
Registry
backing up DNS services
DefaultRegistrationRefreshInterval value
DisableDynamicUpdate value
FlowControlChannelBandwidth value
FlowControlDisplayBandwidth value
Group Policy network options
GroupPolicyRefreshTime value
GroupPolicyRefreshTimeDC value
GroupPolicyRefreshTimeOffset value
GroupPolicyRefreshTimeOffsetDC value
MaskSourceMAC value
MaxCacheEntryTtlLimit value
PowerShell and 2nd
RunDiagnosticLoggingGroupPolicy value
security policies
software restriction policies
Registry provider (PowerShell)
regsvr32 command
relative identifier (RID)
reliability improvements
Reliability Monitor
remote administration
Server Core support
TS support
Remote Assistance utility 2nd
remote control
Active Directory support
NBL clusters
setting permissions
system policies
Terminal Services Configuration
Remote Desktop Client for Mac
Remote Desktop mode (TS)
enabling 2nd
new feature
Remote Desktop Users group
Remote Differential Compression (RDC) 2nd
Remote Installation Services (RIS) 2nd
Remove-Item cmdlet
Remove-ItemProperty cmdlet
Rename-Item cmdlet
Rename-ItemProperty cmdlet
renaming files
repacking tool
REPADMIN utility
Replicate Folder Wizard
replication groups
replication process
auditing
defined 2nd 3rd
forcing
handling update conflicts
loops and meshes 2nd
multimaster replication 2nd
originating USNs
REPADMIN support
single-master replication
site support
sites
time synchronization 2nd
USNs in
UTD vectors
replication topologies 2nd
REPLMON tool
reports
DNSLint support
Failover Cluster Validation Report
FSRM support 2nd 3rd
scheduling
reservations
reset command 2nd
Reskit.net 2nd
resource records
A records 2nd 3rd 4th 5th
CNAME records 2nd 3rd
defined
DNSCmd utility
host (A) records
MX records 2nd 3rd 4th
NS records 2nd 3rd 4th
PTR records 2nd 3rd 4th 5th
SOA records 2nd 3rd 4th 5th
SRV records 2nd
Resource View
resources
defined
groups of
managed 2nd
restore procedure
restricted groups 2nd 3rd
retry interval 2nd
reverse lookup zones
defined
entering records into
functionality 2nd
generating 2nd
stub zones and
RFC 1995 2nd
RFC 1996
RID (relative identifier)
RID master role
RIS (Remote Installation Services) 2nd
RODC (read-only domain controller) 2nd 3rd
roles
adding for TS 2nd
IIS support
operations master roles
Server Core support
web server services and
rootsec.inf file
round-robin DNS balancing 2nd 3rd 4th
Routing and Remote Access Service
RPC protocol 2nd
RSoP (Resultant Set of Policy)
defined
deployment considerations
effective permissions
logging mode
planning mode
without GUI
RunDiagnosticLoggingGroupPolicy value (Registry)
RX (Read and Execute) permission 2nd


S.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

SACL (system access control list)
SAM (Security Accounts Manager) 2nd 3rd
SCA (Security Configuration and Analysis) 2nd
scaling, NICs
scavenging process (DNS)
schema
Schema Admins group
Schema Management console
schema master role
schmmgmt.dll snap-in
scregedit.wsf script
Scriptomatic utility
scripts
cmdlets and 2nd
control structures
delegating GPO administration
Group Policy support 2nd
PowerShell repository
PowerShell support 2nd 3rd
server clustering and
Server Core support
unattended installation
SDM (secure development model)
searching for GPOs 2nd
SECEDIT utility
secondary nameservers
configuring 2nd
functionality
split DNS architecture
upgrading to primary
zone transfers and 2nd
secure development model (SDM)
Security Accounts Manager (SAM) 2nd 3rd
Security Configuration and Analysis (SCA) 2nd
security groups
defined
Group Policy network options
password policies 2nd
software deployment and 2nd
Security log 2nd 3rd
security management
application-level security
auditing support 2nd
BitLocker support
business considerations
CIA principle
device installation control
firewalls and
FSRM file screening
IIS problems
IIS support 2nd
improvements 2nd
layered approach
local options
NAP support
offline access and
OS file protection
PowerShell and 2nd
scripts and
Server Core support
split DNS architecture
TS support
security policies
account lockout policies
auditing support 2nd
automatic logoff and
CIA principle
considerations
event log support
filesystem settings
implementation guidelines
local options
migration process
network options
organizing
password policies
refreshing settings
Registry settings
restricted groups 2nd 3rd
security templates
viewing domain
viewing domain controller
security templates
Security Templates snap-in 2nd
SEIZE command
Select-Object cmdlet
server clusters
applications supported
command-line utilities
creating 2nd
defined
failure management 2nd
functionality
High Availability Wizard
planning setup
services supported
shared data facility
terminology 2nd
witness disk
Server Core
activating server 2nd
AD DS support
administering machines
advantages
automatic updates
command-line utilities
configuring options
deploying 2nd
enabling Remote Desktop
functionality
Group Policy support 2nd
hardware drivers
Hyper-V support 2nd
installing
joining domains
lack of shell 2nd
managed code and
network connections
Notepad support
RODC support
setting administrator password
third-party applications and
Windows Remote Shell 2nd
Server Manager
configuring file servers
creating namespaces
default shares
File Services component
functionality
GPMC support
Group Policy Management
installing Hyper-V
installing PowerShell
installing TS
installing WDS
Performance Diagnostics Console
removing Hyper-V
TS administration
Server Operators group 2nd
server security
service (SRV) records 2nd
service packs
sessions
connecting to
controlling
disconnecting
logging off
NAP process 2nd
resetting
restricting users
shadowing
temporary folder usage
viewing information 2nd
set-executionpolicy cmdlet
Set-Item cmdlet
Set-ItemProperty cmdlet
SetGPOCreationPermissions.wsf script
SetSOMPermissions.wsf script
Setup log
setup security.inf file
setup.iss file
SetupCommand directive
SHADOW command 2nd
shadow copies 2nd 3rd
Share and Storage Management
share permissions
shared folders
ABE support
AD DS support
creating 2nd
default shares
hidden shares
offline access
publishing shares 2nd
shared printers
SHAs (system health agents) 2nd
shutdown process 2nd
SHVs (system health validators)
configuring 2nd 3rd
defined
NAP limitations
SIDs (security identifiers)
IIS support
replication and
RID master role and
Sysprep support
Simple Mail Transfer Protocol (SMTP) 2nd 3rd
Simple Network Management Protocol (SNMP) 2nd 3rd
single instance storage (SIS)
single-master replication
SIS (single instance storage)
site links
sites
AD DS support
creating links
defined
GPO support
replicating
slaving 2nd 3rd
slow link threshold
SMB protocol
SMTP (Simple Mail Transfer Protocol) 2nd 3rd
SNMP (Simple Network Management Protocol) 2nd 3rd
SOA (start of authority) records
editing zone files
functionality
manipulating
nameservers and
stub zones and
software installation 2nd
software policies 2nd 3rd
software restriction policies
Sort-Object cmdlet
special permissions
split DNS architecture
spoofing technique
SQL Server provider (PowerShell)
SRV (service) records 2nd
standalone namespaces 2nd
standard permissions 2nd
starter GPOs
startup process 2nd 3rd
storage considerations
storage reports 2nd
Storage Utilization Monitoring
Stored User Names and Passwords applet
streaming media services 2nd
stub zones
subdomains 2nd
superscope
switches, hubs and
Sysprep tool 2nd
system access control list (SACL)
system health agents (SHAs) 2nd
System log 2nd 3rd
system policies
auditing support
overriding
remote control permissions
software installation
storage location
System Volume Information folder
System.IO.DirectoryInfo objects
System.IO.FileInfo objects
System.Random class
Systems Management Server 2nd
SYSVOL default share


T.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

Take Ownership permission 2nd 3rd
Task Manager
TCP/IP protocol
clustering support
name resolution
NLB support
node support
stack enhancements
Telnet protocol
templates
classes as
file screening via
Group Policy support
local Group Policy
security
temporary folders
Terminal Server role
Terminal Service Remote Programs
Terminal Services (TS)
AD DS support 2nd
adding roles 2nd
administering
client-side considerations
command-line utilities
enhancements
functionality
installing
permissions support
RDP support 2nd
software restriction policies
TCP port number
Terminal Services Configuration
administering TS
changing ports
creating connection listener
encryption support
functionality
remote control permissions
restricting connections 2nd
Terminal Services Licensing
Terminal Services Manager (TSM)
administering TS
changing ports
connecting to sessions
controlling sessions
disconnecting sessions
functionality
logging off sessions
resetting sessions
sending messages
viewing session information 2nd
TFTP (trivial file transfer protocol)
time synchronization 2nd 3rd
time to live (TTL) 2nd 3rd
timestamps
TLDs (top-level domains) 2nd
TLS (Transport Layer Security)
top-level domains (TLDs) 2nd
TPM (Trusted Platform Module)
tracing failed requests
transform files
transitive forest root trusts
transitive trusts 2nd
Transport Layer Security (TLS)
Traverse Folder special permission
trees 2nd
trivial file transfer protocol (TFTP)
troubleshooting
AD DS
adding domains
DNSLint support
Group Policy
Trusted Platform Module (TPM)
trusts
AD DS support
defined
transitive 2nd
Trustworthy Computing Initiative
TS EasyPrint
TS Gateway
functionality 2nd 3rd 4th
NAP support
TS Licensing
TS RemoteApp 2nd
TS Session Broker 2nd
TS Web Access 2nd 3rd
tscon utility
tsdiscon utility
tskill utility
tsprof utility
tsshutdn utility
TTL (time to live) 2nd 3rd


U.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

UAC (User Account Control)
UDP (User Datagram Protocol)
unattend file 2nd
unattended installation
PowerShell
script support
Server Core
UNC (universal naming convention) 2nd
_ (underscore) 2nd
underscore (_) 2nd
unicast mode (NLB) 2nd 3rd
universal groups 2nd
universal naming convention (UNC) 2nd
Unix PS command
up-to-date (UTD) vectors
update sequence numbers (USNs)
UPDATE.EXE tool
UPDATE.MSI file
UPDATE.ZAP file
UPNs (user principal names)
URLScan utility
USB flash drives
User Access permission
User Account Control (UAC)
user accounts
administrative tasks
anonymous users
auditing
configuring with TS
creating
creating with LDAP
disk-based quotas
installation process and
licensing TS
lockout policies 2nd 3rd
NTFS permissions
offset interval
refresh interval
WDS requirements
User Accounts applet
user classes
User Datagram Protocol (UDP)
user principal names (UPNs)
usernames
account lockout policies
AD DS support
displaying for logon
Stored User Names and Passwords applet
Users group
USNs (update sequence numbers)
UTD (up-to-date) vectors


V.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

validation key
Variable provider (PowerShell)
variables, PowerShell support
VBS file extension 2nd
VBScript language
vendor classes
Veritas WinInstall LE tool
version numbers
VHDs (virtual hard disks)
virtual directories
virtual hard disks (VHDs)
virtual machines, creating
virtual private networks (VPNs) 2nd 3rd
virtualization
defined
Hyper-V support 2nd 3rd
strategies
viruses 2nd
Visual Basic Scripting Edition
Volume Activation 1.0
Volume Activation 2.0
Volume Shadow Copy Service (VSS) 2nd 3rd
volumes 2nd
VPNs (virtual private networks) 2nd 3rd
VSS (Volume Shadow Copy Service) 2nd 3rd
vssadmin.exe utility 2nd


W.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

W (Write) permission 2nd
WDS (Windows Deployment Services)
Boot menu
Capture Utility
configuring
creating images
functionality 2nd
installing
modifying images
RIS replacement 2nd
Server Core and
unattended installations
WIM support
Windows PE support 2nd 3rd
WDS client unattend file
WDS Configuration Wizard 2nd
WDSUTIL utility 2nd
web applications
application pools and 2nd
NLB clustering
Web Management Service (WMS)
Web Server role (IIS)
web sites
adding virtual directories
adjusting properties
creating 2nd
web.config file
Where-Object cmdlet
WIM (Windows Imaging Format)
Win32_OperatingSystem class
Windows Automated Installation Kit 2nd
Windows Communication Foundation
Windows Error Reporting
Windows Firewall with Advanced Security
Windows Imaging Format (WIM)
Windows Internet Naming Service (WINS) 2nd 3rd
Windows Load Balancing Service
Windows log
Windows Media Player
Windows Media Services (WMS)
Windows PE (Pre Environment) 2nd 3rd
Windows Presentation Foundation
Windows Process Activation Service (WPAS) 2nd
Windows Remote Shell (WinRS) 2nd
Windows Search Service 2nd 3rd
Windows Server 2008
assessing release
editions supported
hardware requirements
IIS improvements
manageability improvements
networking improvements
performance improvements 2nd 3rd
reliability improvements
Resource Kit Tools
SDM support
security improvements
Server Core support
Windows systems
account lockout policies
local options
network options
password policies
Windows Time Service 2nd
Windows Update
Windows Workflow Foundation
WINPOLICIES tool
WinRS (Windows Remote Shell) 2nd
WINS (Windows Internet Naming Service) 2nd 3rd
witness disk
wlbs drainstop command
wlbs.exe program
WMI (Windows Management Instrumentation)
PowerShell support 2nd
Server Core support
WMI filters 2nd 3rd
WMI objects 2nd
WMI Query Language (WQL)
WMS (Web Management Service)
WMS (Windows Media Services
WPAS (Windows Process Activation Service) 2nd
WQL (WMI Query Language)
Write (W) permission 2nd
Write Attributes permission 2nd
Write Data special permission
Write Extended Attributes permission 2nd


X.html

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

X.509 certificates
XCOPY command
XML
applicationHost.config file
PowerShell support
WDS client unattend file
XPS print path


Z.html

Previous Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

ZAP file method 2nd 3rd
zone files
backup limitations
CNAME record format
defined
editing
host record format
MX record format
nameservers and
NS record format
PTR record format
SOA record format
SRV record format
zone modification notification
zone transfers
Active Directory-integrated zones and
controlling process
expiration date
forcing
full 2nd
incremental 2nd
nameservers and
refresh interval
secondary nameservers and
zones
Active Directory-integrated DNS
defined
DNSCmd utility
domains and
entering records into
exporting to files
nameservers and
resource records
stub

Previous Page