How to Manage Your Exchange Server infrastructure Safely

Transcription

1

2 PUBLISHED BY Microsoft Press A Division of Microsoft Corporation One Microsoft Way Redmond, Washington Copyright 2005 by Microsoft Corporation. All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher. Printed and bound in the United States of America QWE Distributed in Canada by H.B. Fenn and Company Ltd. A CIP catalogue record for this book is available from the British Library. Microsoft Press books are available through booksellers and distributors worldwide. For further information about international editions, contact your local Microsoft Corporation office or contact Microsoft Press International directly at fax (425) Visit our Web site at Send comments to [email protected]. Microsoft, Active Directory, ActiveSync, ActiveX, FrontPage, MSDN, Outlook, SharePoint, Visio, Visual SourceSafe, Windows, Windows NT, Windows Server, and Windows Server System are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The example companies, organizations, products, domain names, addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, address, logo, person, place, or event is intended or should be inferred. This book expresses the author s views and opinions. The information contained in this book is provided without any express, statutory, or implied warranties. Neither the authors, Microsoft Corporation, nor its resellers, or distributors will be held liable for any damages caused or alleged to be caused either directly or indirectly by this book. Acquisitions Editor: Martin DelRe Production: Online Training Solutions, Inc. (OTSI) Body Part No. X

3 Table of Contents Introduction xiii 1 Planning and Implementing Migration Strategies Pilot Plan Initial Pilot Rollout Firewall (ISA Server) Core Network Services Active Directory Messaging (Exchange Server 2003) File Services Testing the Medium IT Solution Pilot Rollout Pilot Acceptance and Full Rollout Core Network Services Active Directory Internet and Security Acceleration (ISA) Server Messaging (Exchange Server 2003) File Services Testing the Medium IT Solution Full Rollout Pilot Rejection and Rollback Deploying Core Infrastructure Services with Microsoft Windows Server 2003 Recommended Network Topologies for Medium-Sized Businesses Building and Deploying the Medium Business IT Architecture Building Core Infrastructure Servers Performing Final Security Configuration Validation Testing the Services Backing Up the System and Verifying the Backup Installing and Configuring Firewalls ISA Server Intrusion Detection Application Filtering What do you think of this book? We want to hear from you! Microsoft is interested in hearing your feedback about this publication so we can continually improve our books and learning resources for you. To participate in a brief online survey, please visit: iii

4 iv Table of Contents Web Proxy Web Caching Logging, Monitoring, and Reporting Placement of a Firewall Server Firewall Policy Firewall Client Computer Configuration Antivirus Software and Other Security Measures Installation and Configuration Installing Microsoft Windows Server 2003 or Windows 2000 Before ISA Server Installing and Backing Up ISA Server Configuring ISA Server Configuring SMTP Filtering Publishing Internal Web Sites to the Internet Publishing Internal Resources to the Internet Installing a Wildcard Certificate on ISA Server Configuring ISA Server to Publish the Exchange OWA Site, Extranet Site, and TSWeb Web Site Configuring Firewall Client Configuring Internet Explorer Configuring Logging, Monitoring, and Reporting Deploying the Firewall Server Moving to the Production Network Testing Services Backing Up the System and Verifying the Backup Releasing the System to Users Managing the Firewall Server Remote Management Update Management Data Backup and Restoration Monitoring and Alerting References The ISA Server 2004 Help File The Microsoft ISA Server 2004 Web Site The Microsoft ISA Server 2004 Newsgroups The ISAserver.org Web Site Security and Antivirus References

5 Table of Contents v 4 Installing and Configuring Microsoft Exchange Server Messaging Services Deployment Design Deployment Choices Recommendations Upgrading from Exchange Server Hardware Recommendations Building/Upgrading Exchange Server Exchange Server Deployment Tools Active Directory and Exchange Server 5.5 Considerations Active Directory Connector System-Wide Requirements for Exchange Server Installing and Enabling Windows 2000 or Windows Server 2003 Services Moving Exchange Server 5.5 Mailbox and Public Folder Contents Switching from Mixed Mode to Native Mode Removing Exchange 5.5 Servers Removing the Last Exchange 5.5 Server Removing Site Replication Service Configuring the Messaging Services Installing and Configuring Prerequisites for Exchange Installation Installing Exchange Installing Exchange System Management Tools Installing Updates and Service Packs Backing Up the IIS Configuration Configuring Forms-Based Authentication Configuring a Certificate on the Server for SSL Communication Configuring DNS Records for mail.businessname.com Configuring a Web Site to Redirect Requests to mail.businessname.com Downloading and Running URLScan 2.5 to Secure the Server Configuring FQDN on SMTP Virtual Server Configuring the Proper DNS Records with the ISP Publishing the SMTP Service Publishing the Internal SMTP Server to the Internet Defining an Access Rule to Allow Outbound SMTP Traffic to the Internet Publishing the OWA Site Publishing an OWA Site as an HTTP Site Publishing an OWA Site as an HTTPS Site Configuring for Client Access

6 vi Table of Contents Performing Final Security Configuration Validation Testing the Services Backing Up the System and Verifying the Backup Deploying and Operating References Installing and Configuring Windows Server Update Services Planning WSUS Deployment Using Computer Groups Choosing the Database Used for WSUS Determining Where to Store Updates Determining Bandwidth Options to Use for Deployment Determining Capacity Requirements Installing WSUS Configuring the Firewall Between the WSUS Server and the Internet Software Requirements Disk Requirements and Recommendations Automatic Updates Requirements Installing WSUS on Your Server Configuring WSUS Server Synchronizing the WSUS Server Configuring Advanced Synchronization Options Updating and Configuring Automatic Updates Creating a Computer Group Deploying WSUS Securing Your WSUS Deployment Operating WSUS Setting Up and Running Synchronizations Managing Computers and Computer Groups Managing Updates Viewing Updates Approving Updates Approving Office Updates Testing Updates Backing Up Windows Server Update Services Monitoring Windows Server Update Services Running Reports Troubleshooting WSUS

7 Table of Contents vii Additional WSUS Resources Windows Server Update Services Communities References Installing and Maintaining Microsoft Operations Manager Workgroup Edition Planning MOM Deployment Software Requirements Hardware Requirements Preparing to Deploy MOM 2005 Workgroup Edition Building and Deploying MOM Installing MOM 2005 Workgroup Edition Installing MOM 2005 Workgroup Edition Components Configuration Best Practices Setting Up Additional MOM Administrator Consoles and Operator Consoles Configuring MOM 2005 Workgroup Edition Configuring the Management Server Configuring Automatic Agent Installation Configuring Mutual Authentication Configuring for Manually Installed Agents Initial Management Mode Applying Computer Discovery Rules to Domain Controllers Choosing Which Agent Installation Wizard to Use Running the Install/Uninstall Agents Wizard Using the Computer Discovery Rule Property Dialog Box Processing Computers in the Pending Actions Folder Installing Agents by Using the Install Agent Wizard Using the Install Agent Wizard with Alternative Accounts Installing Agents Manually Running the Agent Setup Wizard Manual Agent Properties Management Packs Microsoft Management Packs Third-Party and Custom Management Packs Management Packs Included with MOM 2005 Workgroup Edition Importing Management Packs Implementation Checklist

8 viii Table of Contents Operating MOM Processing Flow References Installing and Configuring File Sharing and Print Services Planning File Sharing and Print Services Choices File Services Configuration Deploying File Sharing and Print Services Configuring File Service Technologies Configuring DFS Configuring Shadow Copies of Shared Folders Configuring Folder Redirection Configuring Disk Quotas on the Primary Infrastructure Server Configuring Windows Storage Server Validating the File Server Security Configuration Configuring Printers That Connect to the LAN Configuring the Print Server Adding Printers Connected to Client Computers Configuring Client Computers to Access Network Printers Directly by Using TCP/IP Configuring Directly Attached Printers Sharing the Directly Attached Printers Restricting Access to Printers Publishing Printers Implementing Group Policy Related to Printers Validating Print Services Testing the Network Configuration Testing the Network Printer Configuration Backing Up the Print Server Configuration Installing and Configuring Microsoft Windows SharePoint Services Installing SharePoint Preparing the Server Installing Windows SharePoint Services with WMSDE Installing Windows SharePoint Services to Use SQL Server Extending a Virtual Server with Windows SharePoint Services

9 Table of Contents ix Creating and Managing Sites and Subsites Creating Top-Level Web Sites for Users Creating Subsites Managing Sites and Subsites by Using HTML Administration Pages Security and Self-Service Site Creation Managed Paths and Self-Service Site Creation Enabling Self-Service Site Creation Managing Users and Cross-Site Groups About Domain Account Mode About Active Directory Account Creation Mode Using HTML Administration Pages to Manage Users and Cross-Site Groups Managing Users in a Site Collection Managing Users from SharePoint Central Administration Backup and Restore Options for Windows SharePoint Services References Managing Desktops by Using Group Policy Organizational Unit Design Designing the Organizational Unit Group Policy Design Basic Guidelines for Implementing Group Policy General Recommendations Folder Redirection Software Installation Wireless Configuration Software Update Services Roaming Profiles Configuring and Implementing Group Policies to Manage Desktops Configuring the OU Structures Moving Objects into the OU Configuring Group Policy Objects Configuring Folder Redirection (Optional) Configuring Software Installation (Optional) Configuring Wireless Settings (Optional) Configuring SUS (Optional) Configuring Roaming Profiles (Optional) Configuring Branch Office Policy Settings (Optional)

10 x Table of Contents Performing Final Security Configuration Validation Deploying and Operating References Enabling Remote User Access Remote Connection Infrastructure Design Choosing a Remote Connection Method Choosing an Authentication Technique and VPN Protocol VPN Service Deployment Design VPN Client Software Installation and Configuration IP Address Allotment to VPN Clients Configuring VPN Services Configuring Remote Access Through VPN Configuring Remote Access Through Terminal Services References Managing the Network Planning the Monitoring Environment Configuring the Monitoring Environment Adding Users to MOM Local Groups Adding Operators Creating Notification Groups Creating New Computer Groups Associating Rule Groups with Computer Groups Creating New Tasks Adding or Modifying Rule Groups and Rules Working with Alerts Using the Web Console Using the Alerts View Additional Resources Index What do you think of this book? We want to hear from you! Microsoft is interested in hearing your feedback about this publication so we can continually improve our books and learning resources for you. To participate in a brief online survey, please visit:

11 Acknowledgments : Introduction xi The Microsoft Windows Server System team would like to thank all of the contributors who made this book possible. First and foremost, the bulk of the technical content came from the great work of the Core Infrastructure Solutions team at Microsoft and is based on their original work on the Medium Business IT Solutions Series. Special thanks to Kalpesh Patel, Osman Mohiuddin, Paul Pottorff, Perry Owen, Raj Nath, Rajshree Sharma, and Stewart MacLeod for their huge contributions, without which this book would not have been possible. Thank you also to Saskia Schott of SQLSoft+ for her keen editing and writing, and to the editing and production team at Online Training Solutions, Inc. for their quick turnaround and eye for detail. Martin DelRe and Chris Nelson from Microsoft Learning deserve special thanks for guiding us through the publishing process. And thanks also to Veronica Olocco from the Microsoft Operations Manager product team and Kevin Lisota from the Microsoft Windows Server product team for their technical guidance.

12

13 Introduction : Introduction xiii Microsoft defines midsize businesses as companies or organizations that have client computers. IT departments of midsize businesses face unique challenges when deploying or managing Microsoft technologies. Frequently, IT staff resources are constrained, and one or two people have to manage all of the company s computers, servers, Web sites, telephone and security systems, and other technologies. It can be difficult to find the time to sift through the wealth of technical information available about Microsoft products. Microsoft Windows Server System Deployment Guide for Midsize Businesses was written with the needs of midsize business system administrators in mind. Specifically, this book was written to give technical guidance and recommended network topologies for use when deploying essential Microsoft Windows Server System products in organizations with computers. The goal of this book is provide step-by-step deployment instructions for the Microsoft server products that are most relevant to a midsize business, in one easy-to-read format. These recommendations are based on our experience when deploying systems of similar size and scope in our test lab environment. To some extent, the definition of a midsize business is an arbitrary one based on the number of client computers in an organization. In fact, the term midsize business can be a difficult one, as many companies don t refer to themselves that way. A manufacturer with 200 computers might consider itself a small manufacturer, while a law firm with 200 lawyers might consider itself a large law firm. However, the server scalability and configuration needs are similar for both types of firms. It is also difficult to define an exact boundary for where the technical guidance in this book is appropriate. While we ve optimized our recommendations for computers, many of the configurations described will be equally valid if your environment has 35 or 300 computers. However, as you move farther away from that range, the technical guidance in this book becomes less relevant, in terms of both scalability and manageability. About the Windows Server System Many companies today are looking for the easiest way to achieve a secure and well-managed IT infrastructure. The Windows Server System is a family of Microsoft server products that, when deployed, can make your IT systems more secure and easier to manage. In addition, once your server infrastructure has been upgraded to the latest versions of Windows Server System products, great benefits can be achieved by using the integrated functionality available in desktop operating systems such as Microsoft Windows XP and business productivity applications such as Microsoft Office After the server infrastructure is in place, you will also be able to take advantage of many new technologies, such as team collaboration using Windows SharePoint Services; remote access using Outlook Web Access and Exchange ActiveSync; desktop lockdown and management using Group Policy Objects; and automated

14 xiv Microsoft Windows Server System Deployment Guide for Midsize Businesses desktop patching using Windows Server Update Services (WSUS). Ultimately, many of these technologies will save you time and allow you to gain greater business value from your IT investments. Who Is This Book For? This book was written for system administrators, network administrators, and IT staff planning to deploy a new Windows Server System infrastructure in a midsize business, or to migrate an existing system from Windows NT 4.0. This book will also be useful for consultants and vendors who serve the IT needs of midsize businesses. Essentially, if you are tasked with building, upgrading, or managing information systems, we hope that this information will prove useful. This book does assume a basic knowledge of networking and IT concepts, as well as a basic familiarity with Microsoft server products, technologies, and terminology. What Is Inside? This book contains practical strategies and procedures for installing, configuring, and managing the core networking, messaging, and security infrastructure of a midsize business. We recommend a deployment of three or four servers to meet these needs, running a combination of the following Microsoft server products: Microsoft Windows Server 2003 Microsoft Exchange Server 2003 Microsoft Operations Manager 2005 Workgroup Edition Microsoft Internet Security and Acceleration (ISA) Server 2004 The book also contains details about configuring and deploying a variety of technologies that are included with the server products, such as: Active Directory Group Policy Objects (GPO) Dynamic Host Configuration Protocol (DHCP) Domain Name System (DNS) Windows Internet Naming Service (WINS) Windows Server Update Services (WSUS) Windows SharePoint Services Outlook Web Access (OWA) Distributed File System (DFS)

15 : Introduction xv Each server and technology is covered in its own chapter, roughly in the order that most customers will choose to install these technologies. However, most chapters can also be used independently to address a single technology or server deployment. Where Can I Find More Information? The Microsoft TechNet website at technet.microsoft.com is a comprehensive technical resource for IT professionals, systems administrators, and network administrators. The Midsize Business IT Center Web site at consolidates technical information specifically intended for the needs of midsize businesses. This is an excellent resource for information about effectively deploying and managing Microsoft servers, operating systems, security technologies, and applications.

16

17 Chapter 1 Planning and Implementing Migration Strategies Pilot Plan This chapter provides guidance and recommendations on pilot migration from an existing information technology (IT) environment to a new medium business IT environment. Specifically, it provides guidance on rolling out the following services in a phased manner: Core network services: These include Microsoft Windows Server 2003-based Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and Windows Internet Naming Service (WINS). This chapter addresses concerns such as redundancy, rollout when these services already exist in the environment, and the removal of the existing network services. Directory services: These include initially creating Active Directory directory services and upgrading an existing Active Directory domain. File services: This chapter discusses the options for integrating existing file shares within the pilot environment and provides a roadmap for the full migration of data to the new environment. Messaging services: Various initial states are addressed and guidance provided to implement Exchange Server 2003 in conjunction with the existing mail system, with the final goal of replacing the existing mail system with Exchange Server 2003, if the pilot is successful. Desktop upgrades: The process for creating a standard desktop configuration and upgrading clients to Windows XP with Service Pack 2 (SP2) is addressed. This section provides guidance on designing the pilot implementation of the medium business IT environment for each of the areas of change, divided into three phases: Initial pilot rollout: Most of the following guidance focuses on this phase. It discusses choices to be made in implementing the pilot in different network configurations. 1

18 2 Microsoft Windows Server System Deployment Guide for Midsize Businesses Pilot acceptance and full rollout: This section provides guidance on continuing on to the full rollout of the new environment. It discusses choices to be made in decommissioning the existing network and integrating resources into the new medium business IT environment. Pilot rejection and rollback: There is a brief discussion of the rollback process, in case the new environment causes serious problems that require the removal of the deployed servers and technologies. Initial Pilot Rollout For each of the technology areas concerned, planning has to include which technology to roll out first, and how to perform that rollout without negatively affecting the existing environment. The following sections deal with each of the technology areas that are being upgraded, including some discussion of the challenges presented and the choices that can be made to minimize the impact on the existing production environment. Since one of the highest priorities during any deployment is the maintenance of a secure environment, the first pilot rollout is that of the firewall server: Internet Security and Acceleration (ISA) Server. Having increased the security of the pilot/production environment, the next services to be piloted would be the core network services. Firewall (ISA Server) Installing ISA server in the existing environment can be done in a number of ways. ISA can be deployed in a side-by-side installation, behind the existing firewall, or in place of the existing firewall; or ISA could be excluded from the pilot. The method of deployment following pilot acceptance, might be different from the method used for pilot testing. In the medium business IT environment, the following deployment methods were considered. Side-by-Side Installation A side-by-side installation offers many benefits, including the following: It has no effect on the existing environment. It enables more comprehensive testing during the pilot. By using this method, you can explore the full feature set of ISA while leaving the existing network untouched. This method requires the use of a second public IP address.

19 Installation Behind Existing Firewall Chapter 1: Planning and Implementing Migration Strategies 3 Installing ISA Server behind the existing firewall offers the following benefits: It has no impact on the existing environment. It does not require a public IP address. The disadvantage of this type of installation is the risk of masking problems with the ISA Server configuration because the existing firewall rules might be compensating or blocking access before packets reach the ISA Server being tested. In this case, it might appear that ISA Server is functioning appropriately, even though it might not be configured to provide the observed behavior. Installation in Place of the Existing Firewall Replacing the existing firewall has the greatest effect on the existing environment. This method might require loading the ISA client on non-pilot workstations to accommodate third party applications that require direct access to the Internet. Exclusion of ISA Server from the Pilot An organization can choose to leave the existing firewall in place and not deploy ISA as part of the pilot. This choice would have a minimal effect on the existing environment; however, it also results in a significant loss of functionality for the pilot. In this scenario, none of the ISA features are available, so either these features must come from another source or they are omitted altogether from the environment. This choice also affects the pilot because many of the ISA features that the solution depends on will not be available. In addition, significant portions of the pilot environment are at risk of exposure or compromise, because the core set of services is designed with the assumption that ISA will be used. Organizations will have to ensure that they have thoroughly considered and properly mitigated any risks associated with this option during the pilot. Finally, if ISA is to be part of the final deployed solution, it must be included in the pilot in order to validate functionality. A side-by-side installation is recommended during the pilot phase to allow for comprehensive testing of the ISA Server feature set. Real World Lucerne Publishing was already using Microsoft Proxy Server behind a hardware firewall. They had already opted to replace Microsoft Proxy Server with ISA Server. They decided to follow the guidance and deployed ISA Server side-by-side with their hardware firewall. After fully testing the capabilities of ISA Server, Lucerne Publishing decided to keep ISA Server as the front line firewall and retire their aging hardware firewall.

20 4 Microsoft Windows Server System Deployment Guide for Midsize Businesses To install ISA Server 1. Join ISA Server to the domain as per the guidance provided in Chapter 3, Installing and Configuring Firewalls. Configure a second public IP address on the ISA Server external network adapter to be used for the pilot only. Connect the external network adapter to the router or other device that provides the Internet connection to the existing firewall. If the device has only one port (which is currently used by the existing hardware firewall), place a small switch between the device and the existing firewall, and then connect all devices to the switch. 2. Set up a new A record for Outlook Web Access (OWA) testing. 3. Set the default gateway on all pilot computers, using static IP configurations, to the IP address of the ISA Server, instead of the standard default gateway. 4. Configure the ISA Server computer s default gateway to the IP address of the existing firewall. Core Network Services Core network services consist of the following technologies: DHCP WINS DNS These services form the backbone of network services and can be implemented on a single server, spread out among different servers, or duplicated on several servers for redundancy. DHCP Implementing DHCP requires the assignment of an IP addressing scheme that, at the minimum, has as many IP addresses as the number of devices currently in the organization. For more information, refer to Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server There are a number of factors to consider before deciding to change the existing IP addressing scheme to the recommended IP addressing scheme. These considerations include: To provide full redundancy of an IP Scope, the subnet needs to be divided among multiple DHCP servers. Organizations using a x.x scope can serve a maximum of only 127 devices (in addition to branch offices), if the scope is divided between two servers. The existing hardware, such as copiers and printers, might present a challenge when switching to a new IP addressing scheme. The existing hardware might not support DHCP, or it might not be possible to reconfigure the device. Consult with the manufacturer to determine whether the devices are compatible with DHCP and what is required to change the IP address.

21 Chapter 1: Planning and Implementing Migration Strategies 5 Applications might be tied to an existing IP address. Poorly written programs are often prone to such limitations and care must be taken to ensure that such applications do not fail or function improperly if the IP address of the server or workstation changes. Switching IP address scopes also poses problems when a new DHCP server is being introduced into the existing environment. A newly activated DHCP server is able to service the clients as soon as the scope is activated. For the initial pilot rollout, this means that non-pilot workstations will be serviced by the pilot server, and because they have new address scopes, the production environment would be affected unless the pilot is performed in a single location. Organizations that do not currently use DHCP will find it much easier to roll out a new IP addressing scheme, because the new DHCP scope can be configured and activated without affecting any clients until the clients are configured to use DHCP. A change in IP addressing scheme to accommodate a handful of pilot users will create complexities that can be easily avoided. If a DHCP server is used in the existing environment, configure a DHCP scope on the infrastructure server; however, do not activate the scope during the pilot, so as to ensure that it does not conflict with the existing scope. When the pilot is accepted, the DHCP scope set up during this stage only needs to be activated on the new server and deactivated on the old server. On the computers identified for pilot users, manually configure the IP address, gateway, WINS, and DNS by using the IP addressing scheme recommended for the new environment. If the existing IP addressing scheme does not conform to the prescribed IP addressing scheme, it is recommended that you continue using the existing IP addressing scheme for the initial pilot rollout and skip the guidance on DHCP provided in Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server If the existing IP addressing scheme does match the prescribed IP addressing scheme and there are sufficient IP addresses available to divide the scope, it is recommended that you follow the guidance and implement DHCP on the infrastructure servers as prescribed in Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server Configure the pilot clients to obtain IP addresses and other IP configuration settings dynamically. Real World At Lucerne Publishing, the x IP addressing scheme was being used in the existing environment. For the pilot, the IT staff at Lucerne Publishing decided to split their active scope between two servers, the existing primary domain controller (PDC) and their new primary infrastructure server (MOCOR1). This would allow Lucerne Publishing to get an idea of how this configuration works, and also test the redundancy features offered by a split scope. They realized, however, that if they were to implement the guidance in full production, there were not enough IP addresses in their existing subnet to accommodate all the hosts in their environment. As a result, they planned that after pilot acceptance and after the secondary infrastructure server (MOCOR2) was brought online, they would move the scope settings from PDC to MOCOR1. Following pilot acceptance, the plan was to use a 10.0.x.x addressing scheme to take full advantage of DHCP redundancy. Because Lucerne Publishing was planning to configure all of the devices in the environment to get their IP configuration settings from DHCP, the expansion of the subnet mask was easy and was accomplished without having to visit and configure each network device.

22 6 Microsoft Windows Server System Deployment Guide for Midsize Businesses If DHCP is not used in the existing environment, set up DHCP as prescribed in Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server WINS WINS is the Microsoft implementation of a NetBIOS name service and maps NetBIOS names on the network to IP addresses. This mapping helps reduce the broadcast traffic, because when a computer has a NetBIOS name and needs the IP address, it can query the WINS server for the IP address rather than sending out a broadcast on the network. The two primary considerations while designing WINS are replication design and ensuring redundancy. During the pilot rollout, it is important to extend the existing WINS services, if they exist, into the pilot. As with DHCP, it is important in the medium business IT environment to create redundancy in critical services. It is also important to design a replication topology that will keep all WINS servers synchronized without creating excessive network traffic. The WINS service should be deployed across two servers for redundancy purposes. If the existing environment already has WINS servers, set up the new WINS server to be a replication partner with the existing WINS servers. Real World As with DHCP, Lucerne Publishing opted for fault tolerance with WINS. The WINS service was already configured on the existing PDC and BDC servers. MOCOR1 and MOCOR2 were configured as replication partners, and the IP addresses of these servers were added to the DHCP options provided to DHCP clients. DNS If you are migrating from Windows NT, the DNS service will automatically be installed when you configure the primary infrastructure server (MOCOR1). If you are migrating from Windows 2000, then DNS will already be in place. DNS will need to be manually installed on MOCOR1. Depending on the state of the existing environment, DNS could be in stand-alone or Active Directory Integrated mode. You will need to determine the mode in which DNS will operate during the time of the pilot. How to roll back the pilot with the least impact on the existing environment should be strongly considered. DNS zones can be reconfigured if necessary; however, this presents an additional administrative burden that can be avoided.

23 Consider the following recommendations: Chapter 1: Planning and Implementing Migration Strategies 7 In a Windows NT environment, if DNS is configured for resolution of the internal namespace, leave the existing DNS as it is. On the primary infrastructure server, set up the Windows NT 4.0 DNS servers as forwarders. If DNS is not currently configured, or in a Windows 2000 environment, configure DNS according to the guidance provided in Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server In the Windows 2000 environment, run DNS in the Active Directory Integrated mode. Real World Lucerne Publishing did not have DNS enabled in their Windows NT 4.0 domain. When they installed MOCOR1 as their primary infrastructure server, the Active Directory wizard automatically set up DNS. They then configured the server in the Active Directory Integrated mode. The DNS server IP addresses provided by the Internet service provider (ISP) were configured as forwarders. Lucerne Publishing then installed DNS on their secondary infrastructure server, MOCOR2. Because this server was a domain controller, it was automatically configured to replicate to MOCOR1. Active Directory Implementing Active Directory requires the installation of Windows Server Whether the existing environment is a workgroup, Windows NT domain, or Windows Server 2000 domain, some changes to the existing environment are unavoidable unless the pilot is rolled out parallel to the existing environment: Workgroup: Implementing the pilot in a workgroup environment is essentially the same as a new domain deployment; the lack of centralized security negates many of the concerns regarding integration with existing systems. The guidance in this book can be deployed and workstations joined to the domain without affecting the existing environment. Windows NT: To roll out the pilot in a Windows NT environment, Active Directory requires that the first domain controller to be upgraded must be the PDC. Care must be taken to preserve the existing environment to allow for rollback to the existing state, if the pilot is rejected or there is a problem with the installation. Windows 2000: Windows 2000 installations already have Active Directory installed. The schema will, however, need to be updated to allow Windows Server 2003 to function as a domain controller in the existing environment.

24 8 Microsoft Windows Server System Deployment Guide for Midsize Businesses The following are the considerations for implementing Active Directory. In-Place Upgrade An in-place upgrade greatly simplifies the migration to Active Directory. User and computer accounts will be migrated, thus reducing the administrative burden associated with the fullscale rollout following the pilot acceptance. The disadvantage of an in-place rollout is that it does affect the existing environment. Migrating a Windows NT domain requires the first Windows Server 2003 computer introduced as a domain controller to be the PDC. Upgrading the existing PDC is not recommended. It is preferred to introduce the new hardware into the existing environment as a backup domain controller (BDC), and then promote that new server to PDC to allow for installation of Windows Server This strategy has the added benefit of allowing the former PDC (now a BDC) to be taken offline during the upgrade, thus providing a fall-back mechanism if the installation fails or the pilot is rejected. In case rollback is required, Windows Server 2003 can simply be taken offline and the previous PDC promoted back to the PDC status. Having a domain controller that has been upgraded from Windows NT 4.0 to Windows Server 2003 is not considered the ideal configuration; it is desirable to have domain controllers that have had a pure Windows Server 2003 installation. A swing server can help overcome the technical limitations imposed by the Windows NT 4.0 to Windows 2003 upgrade process. A swing server is a temporary server used to introduce Windows Server 2003 into a domain so that other Windows Server 2003 servers can be introduced into the environment. Windows Server 2000 upgrades are more streamlined, because Windows 2003 can be installed immediately on the new hardware. The Active Directory schema will require an upgrade prior to the introduction of the first Windows Server 2003 domain controller. Upgrades to the Active Directory schema are permanent; there is no rollback procedure. This represents a minimal risk, because Windows Server 2000 can continue to function with the upgraded schema, even if no Windows Server 2003 servers are introduced. Parallel Pilot A parallel installation should be considered only if the existing domain is highly problematic. Consider a parallel installation where the existing domain structure is inappropriate or the new domain name will be different from the existing domain name. Also consider a parallel installation in IT environments where the health of the existing domain is questionable and there are concerns that introducing Windows Server 2003 into the environment will either further aggravate the problems or cause Windows 2003 to inherit the problems. Parallel installations increase the complexity of the deployment process. The foremost problem is that the domain name must change. A different domain name can present numerous challenges, including problems with access to resources in the existing domain during the pilot testing. Parallel installations also require the creation or migration of user accounts.

25 Chapter 1: Planning and Implementing Migration Strategies 9 In a Windows NT or Windows Server 2000 domain, an in-place upgrade is recommended because of the complexity of performing a parallel installation and the ability to fall back to a known state in case of pilot rejection. It is not recommended that you deploy domain-level Group Policy, because this would affect non-pilot users as well. In a Windows NT environment, use a swing server to upgrade the domain to Windows Server In a workgroup environment, deploy Active Directory, including the domain-level Group Policies, as recommended. In environments where a parallel installation is the only viable course of action, using the Active Directory Migration Tool (ADMT) to migrate user and computer accounts from the existing environment is recommended. ADMT will preserve user security identifier (SID) history, making access to resources and files on the old network less complicated. Real World Lucerne Publishing opted to use a swing server before bringing MOCOR1 online. Once the swing server was in place, they brought MOCOR1 online as a domain controller, and after waiting for replication to be completed, transferred all Flexible Single Master of Operations (FSMO) roles to it. The IT team at Lucerne Publishing then ran Dcpromo on the swing server to demote it, and permanently removed it from the domain. In a Windows NT 4.0 environment, in-place server operating system deployment involves the following procedures. To introduce the swing server 1. Install Windows NT 4.0 as BDC on the swing (temporary) server. 2. Upgrade the BDC to PDC. 3. Take the prior PDC offline before the upgrade. 4. Upgrade the PDC to Windows Server To introduce the medium IT primary infrastructure server (MOCOR1) into the environment 1. Install Windows Server 2003, and make it the Primary Domain Controller, 2. Transfer all five FSMO roles to MOCOR1 from the swing server. 3. Run Dcpromo on the swing server to demote it to a member server. 4. Remove the swing server, and delete its computer account from the domain. 5. Bring the previous PDC (the current BDC) back into the environment after both the pilot and full migration have been successful. In a Windows 2000 Server environment, in-place server operating system deployment involves the following steps: 1. Run the adprep/forestprep command on existing FSMO role holder.

26 10 Microsoft Windows Server System Deployment Guide for Midsize Businesses 2. Install the operating system on the primary infrastructure server (MOCOR1). 3. Join MOCOR1 to the existing domain. 4. Run Dcpromo on MOCOR1. 5. Configure DNS to run in Active Directory Integrated mode. Messaging (Exchange Server 2003) Although the messaging service is not part of the primary infrastructure server, it is still an essential service to evaluate in the context of a migration. This is especially important if the existing environment has Microsoft Exchange Server 5.5 installations because, unlike Exchange Server 2000, Exchange Server 5.5 is not an Active Directory-aware service. The considerations when deploying Microsoft Exchange Server 2003 are: Current state of the network Method of deployment Three initial states of environment are possible: Exchange Server 5.5 is present. Exchange 2000 Server is present. An old mail system or no mail system is present. Deploying Exchange Server as a member of the existing Exchange site will greatly reduce the complexity associated with server integration. By deploying in an existing site, mailboxes can be moved from the earlier version server to Exchange Server 2003 on MOCOR2 by using the Move Mailbox Wizard. All incoming mail continues to be directed to the existing server, without affecting the existing environment. Mail for pilot users is directed to the new server. If public folders are used, an installation to the existing Exchange site will enable the replication of public folders between existing and pilot servers. Public folder replication preserves security settings. For pilot users to be able to test OWA, a second public IP address must be assigned to direct pilot users to the OWA site running on MOCOR2. This will ensure that the process of accessing OWA in the existing environment will not change for the users. OWA in Exchange Server 2003 is a significant upgrade from previous versions of OWA. Pilot users should therefore test it thoroughly to experience the rich feature set. When deploying into an existing site, it is necessary to make Active Directory schema changes. These changes are permanent and cannot be rolled back, even if the pilot is rejected. The risk factor is minimal. If the pilot is deployed in a parallel installation or the initial environment included an older version mail system or no mail system, installation would be in the new Exchange site. A parallel installation presents the added challenges of requiring a second public IP address and a unique domain name to test the incoming mail and remote access.

27 Chapter 1: Planning and Implementing Migration Strategies 11 Another choice to be made is to whether to change the mode of Exchange Server from Mixed mode to Native mode. Mixed mode allows Exchange Server 5.5 to participate in the Exchange site. Environments running Exchange 2000 Server without Exchange Server 5.5 might already be operating in Native mode. Environments with Exchange Server 5.5 should be kept in this mode, in case of pilot rejection. Maintaining Mixed mode, in this case, will allow the system to be returned to its pre-pilot configuration. Exchange Server 5.5 installations running on Windows NT 4.0 or Windows 2000 Server will require the Active Directory Connector (ADC) to be installed. The ADC might already be present in the environment, but will need to be updated to the latest version. Exchange 2000 Server installations that were upgrades from Windows NT or Exchange Server 5.5 installations might also have the ADC installed. If the existing infrastructure is purely Windows Server 2000 and contains no Exchange Server 5.5, the ADC can be removed. Otherwise, it should be upgraded to the latest version. Older mail systems or POP-based mail systems present a greater challenge for migration and pilot testing. Microsoft has a number of synchronization and migration tools available for migrating from older mail systems, such as Lotus Notes and GroupWise. For information on additional migration scenarios, refer to the following URL: /techinfo/interop/default.asp. Some considerations in the installation in the existing Exchange site scenario are: It is easier to maintain. It is possible to move mailboxes and replicate public folders. It requires a new A record for OWA access. It has lasting impact on the schema, if the pilot needs to be rolled back. Antivirus software might require updating to run with Exchange Server Anti-spam software might require updating to run with Exchange Server During migration, a separate URL is required for accessing the OWA site. Security settings of public folders are maintained. It is possible to roll back to the pre-pilot state. Installation in a parallel environment requires a separate domain name and introduces added complexity. Traffic for port 25 will need to be managed for the existing network and the pilot. If the pilot is rejected, there is no effect on the existing environment when the pilot is rolled back. To reduce complexity and maintain the ability to roll back to the current state with minimal impact, installing and integrating Exchange Server 2003 in the current Exchange site is recommended. With this method of deployment, all incoming mail will continue to flow without

28 12 Microsoft Windows Server System Deployment Guide for Midsize Businesses interruption. Mailboxes can be moved from server to server without the need to export the accounts, and pilot users addresses can remain the same. In environments where there is an older system or no system, it is recommended that you follow the guidance provided in Chapter 4, Installing and Configuring Microsoft Exchange Server Real World Lucerne Publishing installed Exchange Server 2003 on MOCOR2 in the same site as Exchange Server 5.5. They were able to thoroughly test Exchange Server 2003 by moving the mailboxes of a few pilot users with the Move Mailbox Wizard. After pilot testing, the Move Mailbox Wizard was used again to move the remaining mailboxes to the new server and retire Exchange Server 5.5. An outline of the procedures in each of the three scenarios follows. To integrate Exchange Server Install or upgrade ADC on the Exchange Server Check for User Account Synchronization, and resolve errors. 3. Run Exchange Setup with the ForestPrep and DomainPrep switches on the primary infrastructure server. 4. Install Exchange Server 2003 on the secondary infrastructure server (MOCOR2) according to the guidance provided in Chapter 4, Installing and Configuring Microsoft Exchange Server When prompted to create a new site or join an existing site, select the option to join the existing site/organization. 5. Establish public folder replication between the existing Exchange Server installation and Exchange Server Move the pilot mailboxes to MOCOR2. 7. Upgrade the pilot clients to Microsoft Outlook Reconfigure the pilot clients with new Outlook profiles pointing to MOCOR2. To integrate Exchange 2000 Server 1. Upgrade ADC, if it is present on the Exchange 2000 Server. 2. Check for User Account Synchronization, and resolve errors. 3. Run Exchange Setup with the ForestPrep and DomainPrep switches. 4. Install Exchange Server 2003 on the secondary infrastructure server (MOCOR2) according to the guidance provided in Chapter 4, Installing and Configuring Microsoft Exchange Server When prompted to create a new site or join an existing site, select the option to join the existing site/organization. 5. Establish public folder replication between the existing Exchange Server installation and Exchange Server 2003.

29 Chapter 1: Planning and Implementing Migration Strategies Move the pilot mailboxes to MOCOR2. 7. Upgrade the pilot clients to Microsoft Outlook Reconfigure the pilot clients with new Microsoft Outlook profiles pointing to MOCOR2. Old Mail System The following two scenarios might exist if the existing environment has an older mail system. To integrate a server-based mail system 1. Install Exchange Server 2003 on MOCOR2 according to the guidance provided in Chapter 4, Installing and Configuring Microsoft Exchange Server Upgrade the pilot clients to Microsoft Outlook Reconfigure the pilot clients with new Microsoft Outlook profiles pointing to MOCOR2. To integrate a POP-based mail system 1. Install Exchange Server 2003 on MOCOR2 according to the guidance provided in Chapter 4, Installing and Configuring Microsoft Exchange Server Upgrade the pilot clients to Microsoft Outlook Reconfigure the pilot clients with new Microsoft Outlook profiles pointing to MOCOR2. 4. Modify the Outlook profile for the pilot users, and add a POP account to access the users current POP accounts. File Services File services are an essential part of the medium business IT environment. Distributed File System (DFS) and Shadow Copy Services are used for implementing the file services. DFS provides a unified file structure by bringing together file shares from multiple servers in an organized directory structure. Shadow Copy Services allows users to instantly access previous versions of modified or deleted files, thus reducing the need to restore files from removable backup media, but without any versioning controls. To use the Shadow Copy Services features, client workstations will need the Shadow Copy Services client to be installed locally. In the pilot implementation, there are three choices for implementing file services: migrate existing files and shares, leave the current shares intact, or set up DFS and point it to the existing shares on the existing servers. In deciding which path to choose, consider the following: Migrating existing shares greatly affects the existing environment, including configuration of any existing backup software. Installing DFS and pointing it to the existing shares allows for verification of the file services in the pilot without affecting the existing environment and backup configuration.

30 14 Microsoft Windows Server System Deployment Guide for Midsize Businesses Testing file services in the pilot environment by implementing DFS and linking to existing server shares is recommended. This ensures that non-pilot users are not affected by the pilot program, and backup schedules don't need to be modified. It is also recommended that you create a Shadow Copy Volume according to the guidance provided in Chapter 7, Installing and Configuring File Sharing and Print Services. Real World Although Lucerne Publishing had DFS installed on two servers, the two servers hosted their own DFS roots. It was an administrative nightmare. They stopped using DFS, and reverted to shared folders, which they knew how to manage. When Lucerne Publishing piloted the medium business IT environment, they decided to use DFS again. They set up all the existing shared folders in their new DFS root. This made management a lot easier and removed DFS from the Windows 2000 Server-based file and print server, which was not slated for replacement for another three months. DFS on the existing PDC was abandoned, and the pilot users reported no problems in accessing resources on the old servers. Lucerne Publishing s IT team decided to get all users up and running on the new DFS root before fully migrating the new medium IT network. They changed the DFS links to any shares that were moved from the old server to new servers, and the old servers were retired. To implement the file service in the pilot environment 1. Create a DFS root on the primary infrastructure server according to the guidance provided in Chapter 7, Installing and Configuring File Sharing and Print Services. 2. Create a DFS link to all shares in the existing environment. 3. Remap clients in the pilot environment to the DFS share. 4. Manually install the Shadow Copy Services client on the pilot workstations, unless they are already running Windows XP SP2 or later, which has the Shadow Copy Services client installed by default. For more detailed instructions on configuring the DFS root and creating links, refer to Chapter 7, Installing and Configuring File Sharing and Print Services. Testing the Medium IT Solution Pilot Rollout The true test of a pilot rollout is the day-to-day operation supporting the pilot clients. By performing daily tasks, users identify areas that need attention and help discover issues that were unforeseen. However, the following general tasks need to be performed to validate the core requirements of the pilot: Test client sign in. Verify that Group Policies have been applied. Perform DNS queries. Test NetBIOS name resolution. Send and receive .

31 Chapter 1: Planning and Implementing Migration Strategies 15 Verify Internet connectivity. Verify file access through DFS. Verify line of business (LOB) application functionality. Pilot Acceptance and Full Rollout Throughout the pilot testing, feedback should be collected from the pilot testers. Corrective actions should be taken, wherever needed, to ensure a satisfactory implementation of the pilot environment. Risks associated with widespread rollout should be analyzed, and the decision needs to be made to perform a full-scale rollout or to remove the pilot systems and return to the previous state. If technical difficulties are resolved during the initial pilot rollout, the decision should be clear to move forward with a full implementation of the medium IT strategy. This section discusses choices to be made for decommissioning the existing network and integrating resources into the new medium business IT environment, for full implementation following the acceptance of the pilot. Core Network Services Core network services consist of the following technologies: DHCP WINS DNS DHCP Following the acceptance of the pilot, consider moving to the medium IT IP addressing scheme. Redundancy and a well-designed IP addressing scheme are the primary reasons to consider migrating to the prescribed IP addressing scheme. As previously discussed, there are a number of mitigating factors to consider before making such a change. Factors to be considered include: Complexity Number of host addresses needed Applications (running on older systems) using statically mapped IP addresses Statically mapped printers Hardware issues Sufficient scope for redundancy Multiple subnets required for branch offices Other core services

32 16 Microsoft Windows Server System Deployment Guide for Midsize Businesses If the existing scheme does not provide the redundancy and feature set required in the medium business IT environment, it is recommended that you extend the existing scheme to provide these features. If considerations do not warrant switching, or if there are problems in deployment, such as the inability of hardware to support new subnets or legacy LOB applications that require the existing subnet, then maintain the existing IP addressing scheme. Where it is required for redundancy or branch office use, switch to a new scheme at the conclusion of the pilot. Real World Lucerne Publishing had already configured their secondary infrastructure server, MOCOR2, with the same DHCP scope options as were on the former PDC. The IT team disabled the scope on the former PDC and enabled the scope of MOCOR2. To migrate to the new IP addressing scheme 1. Configure DHCP with the new scope. 2. Coordinate scope activation with deactivating the older scope on the former servers. 3. On the new DHCP server, configure scope options, such as static reservations for existing devices, and assign the medium IT DNS server in DHCP options. 4. On the new DHCP server, configure the WINS scope options to point only to MOCOR1 and MOCOR2. WINS Because the existing WINS service has been extended to serve the entire network (including the pilot) and because it is running on MOCOR1 and MOCOR2 as well as the old NT4.0 domain controllers, the remaining steps are as follows: 1. Remove the old Windows NT 4.0 WINS servers as replication partners from MOCOR1 and MOCOR2. 2. Decommission the old WINS servers. This can be done when the old PDC and BDC are removed from the network, or the WINS service can be turned off on these servers before they are removed from the domain. DNS Switching DNS to Active Directory Integrated mode adds support for secure dynamic updates, which allow you to control access for updating DNS. Active Directory Integrated zones also simplify Active Directory replication, because DNS is able to use the replication service of Active Directory. This eliminates the need to design a separate replication technology. Replacing the older DNS servers with Dynamic DNS servers is preferred.

33 Chapter 1: Planning and Implementing Migration Strategies 17 As with other core services, when considering changes to DNS, it is important to consider redundancy. Active Directory Integrated DNS offers advantages with DNS replication and enhanced security with Secure Updates. Consider the following recommendations: Switch to Active Directory Integrated mode, and allow dynamic updates. Retire former DNS servers, and remove older DNS servers from the forwarders list on the medium IT DNS servers. Real World Lucerne Publishing was not using DNS prior to the pilot; therefore, they installed DNS and set it to Active Directory Integrated mode during the pilot phase of implementation. The following is an outline of the tasks for implementing DNS in the environment: Switching DNS to Active Directory Integrated mode: Depending on the initial state prior to the pilot, DNS might already be in Active Directory Integrated mode. If it is, nothing needs to be done. If it isn t, switch DNS to Active Directory Integrated mode. If there was an existing DNS server for resolving internal DNS names, create the corresponding DNS records by using the DNS Administration tools. Removing former DNS servers from the medium IT DNS server forwarders list: You will need to remove the former DNS server from the medium IT DNS server forwarder list and add the appropriate ISP-provided DNS server entries as forwarders. Active Directory At the conclusion of the pilot, there are a number of choices to make regarding the following: Retiring old domain controllers. Decommissioning hardware. Switching the domain functional level. Restructuring domains. Aligning organizational unit (OU) structure with the OU structure recommended in Chapter 9, Managing Desktops by Using Group Policy. Consider retiring old domain controllers after the pilot acceptance. Old domain controllers do not have some of the more advanced feature sets of Windows Server For example, maintaining a Windows NT BDC prevents switching DNS to Active Directory Integrated mode, which supports secure dynamic updates.

34 18 Microsoft Windows Server System Deployment Guide for Midsize Businesses When retiring old domain controllers, or any other hardware for that matter, evaluate their potential for redeployment in the new environment. Consider moving all services off the old servers so that the servers can be decommissioned, reformatted, and reinstalled as new Windows Server 2003 servers. Upgrading components, such as CPU or RAM, might extend the life span of the old hardware without incurring the full cost of a new server. When all domain controllers are running Windows 2003 Active Directory, consider switching the domain functional level. However, exercise caution when switching to this mode, because you cannot revert back. Native mode does not support Windows NT 4.0 BDCs. Note that Windows NT 4.0 and Windows 2000 member servers are still supported in this mode. Under Windows Server 2003 Active Directory, you can choose from the following four domain modes, depending on your domain controller configuration: Windows Server 2003: This mode requires that all domain controllers be Windows Server Windows Server 2003 Interim: This level supports Windows NT 4.0 servers and Windows Server 2003 (but not Windows 2000). It is used when you upgrade a Windows NT 4.0 PDC to Windows Server Windows 2000 Native: This level supports Windows 2000 Server and Windows Server 2003 (but does not support Windows NT 4.0). Windows 2000 Mixed: This level supports Windows NT 4.0 BDCs and Windows 2000 Server DCs. This is the default functional level because it supports all types of domain controllers. Switching the Windows Server 2003 functional level provides access to advanced features, such as: Domain rename: As the name implies, you can change the DNS domain name, Net- BIOS name, and the forest root domain. Domain Controller rename tool: You can rename domain controllers without running Dcpromo to demote the domain controllers first. Forest trusts: You can use forest trusts, which might be needed when merging with another company. Replication enhancements: You can replicate new user or group objects individually by using linked value replication without replicating the entire group membership. Global Catalog replication: This feature replicates less traffic when changes to the Global Catalog are made. Defunct schema objects: Administrators can deactivate classes or attributes from the schema if they are not being used.

35 Chapter 1: Planning and Implementing Migration Strategies 19 Depending on the existing number of domains, it might be desirable to change the domain structure. In the existing network, child domains might have been established over time for reasons such as politics and separation of administrative rights. In a Windows Server 2003 domain, OUs provide a mechanism for rights delegation, where previously a child domain might have been required. Furthermore, OUs simplify management through the use of Group Policy. In Windows NT domains, the domain represents the security boundary. In Windows Server 2003 networks, the forest is the true security boundary. Therefore, child domains created for the purpose of security might no longer serve a purpose. The existing Active Directory design based on Windows Server 2000 might not be optimized for Group Policy. The initial design might have been created when Active Directory was first introduced and knowledge about the technology was still uncommon. Aligning Active Directory with the recommendations in Chapter 9, Managing Desktops by Using Group Policy, can help to overcome some of the problems of the existing environment. It is recommended that you convert all domain controllers to Windows Server 2003 to take full advantage of Windows Server As domain controllers are retired and replaced with Windows Server 2003 domain controllers, analyze the hardware and redeploy wherever possible. For example, it might be possible to redeploy a server as a terminal server or an ISA server. Only two domain controllers are required in the medium business IT environment recommended in this book. Retire any old hardware that does not meet the minimum requirements for running Windows Service If feasible, it is recommended that you consolidate to a single domain. Consider using the Windows Resource Kit utility NETDOM to move computers to the new domain. NETDOM is easily scripted to enable automated movement of a few to a few hundred computers. Once the domain structure has been finalized, analyze the OU structure and determine whether it is optimized for the application of Group Policy. Migrate to the recommended OU structure for easy application of Group Policy and delegation of authority over more segregated containers than those provided by the default Active Directory structure. For more information on Group Policy, refer to Chapter 9, Managing Desktops by Using Group Policy. Real World Lucerne Publishing had one PDC and two BDC servers. At the completion of the pilot, they migrated all core services to the new Windows Server 2003 servers and then retired the old servers. The old servers were formatted and the hardware donated to a local charity, which used it for cross-training of the unemployed. Perform the following tasks to implement Active Directory in the new environment. To retire old Windows NT domain controllers 1. Install the new domain controllers. 2. Move core services from the old domain controllers to the new domain controllers.

36 20 Microsoft Windows Server System Deployment Guide for Midsize Businesses 3. Power down the old servers. 4. Remove the servers from the domain, and delete their computer accounts from Active Directory and DNS. To retire old Windows Server 2000 domain controllers 1. Install the new domain controllers. 2. Move core services from the old domain controllers to the new domain controllers. 3. Run Dcpromo to remove the old servers as domain controllers. 4. Remove the servers from the domain, and delete their computer accounts from Active Directory and DNS. To decommission the old hardware 1. Analyze the decommissioned hardware for redeployment eligibility. 2. Upgrade the hardware as necessary to effectively run Windows Server 2003 and any other services that might be run on it when it is reintroduced to the domain. 3. Delete the existing drive partitions, and install a fresh copy of Windows Server Rejoin the server to the domain as a member server. 5. Use the recycled hardware as a terminal server or other server role. Real World Lucerne Publishing analyzed their decommissioned hardware and determined that it could not be used for running Windows Server Therefore, they decided to donate the hardware to charity after they formatted the drives to remove all confidential business data. To restructure Windows NT domains 1. Use NETDOM to join the computers to the medium IT domain. 2. Move all services and resources from the domain controllers from the domain to be removed. 3. Power down the server and remove it from the domain. To restructure Windows Server 2000 domains 1. Use NETDOM to join computers to the medium IT domain. 2. Move all services and resources from the domain controllers. 3. Run Dcpromo to demote the servers. When you have demoted all but the last domain controller, choose the This server is the last domain controller in the domain option. To switch the domain functional level 1. Right-click the domain object in Active Directory Users and Computers.

37 Chapter 1: Planning and Implementing Migration Strategies Select the Raise Domain Functional Level option. 3. Select Windows Server Internet and Security Acceleration (ISA) Server ISA Server can be deployed in the following ways: Behind the existing firewall. In place of the existing firewall. Consider the following while deploying ISA Server: Desire to keep existing hardware firewall: Microsoft recognizes that organizations might prefer to keep the existing firewall hardware, because it might represent a significant investment and enjoy a level of trust from long-term experience. Port changes required on hardware firewall, if kept: Ports opened on ISA Server might need to be configured on the existing firewall. Features that cannot be replaced: ISA server offers several features that are not easily available from hardware firewalls, such as integration with Active Directory and application layer filtering. ISA Server provides a comprehensive solution in a single device. Single integrated solution: ISA Server offers a complete functional set, including features such as security, application layer filtering, caching, and reporting. Having the entire feature set in a single device can cut down on management overhead, and also decrease the requirement for training on a number of different vendor devices. If possible, replace all hardware firewalls. If the organization prefers to retain the existing hardware firewall, place ISA Server in the perimeter zone or behind the existing firewall. Real World Lucerne Publishing evaluated ISA Server and liked the features it offered. Although there was a learning curve for the IT staff, because they were familiar with the hardware firewall, they decided to replace the hardware device with the ISA Server. By switching to ISA Server, they were able to replace two devices with one, which in the long run meant less management and maintenance. The following section details the steps for deploying ISA Server in each of the two types of deployment scenarios. To position ISA Server behind the existing firewall 1. Install the ISA client. 2. Modify the default gateway on workstations (configured using DHCP), and manually change the default gateway on any statically configured servers.

38 22 Microsoft Windows Server System Deployment Guide for Midsize Businesses 3. Place the ISA Server behind the firewall, and connect the ISA Server to the Internet through the hardware firewall. Connect clients to the Internet through the ISA Server. 4. Ensure that all required ports (which have been opened on the ISA Server as part of the configuration) are opened on the hardware firewall and that traffic is passed to the ISA Server. To replace the existing firewall 1. Install the ISA client. 2. Modify the default gateway on workstations (configured through DHCP), and then manually change the default gateway on any statically configured servers. 3. Remove the old firewall. 4. Switch the public IP address on the external ISA Server interface. 5. Remove any temporary A records. Messaging (Exchange Server 2003) Following pilot acceptance, there are two main choices to consider for the Exchange infrastructure: first, whether or not to decommission the old Exchange servers and second, whether to move Exchange Server from Mixed mode to Native mode. Decommissioning servers is an important step in providing a unified experience for all network users. Without decommissioning and consolidating, organizations have to maintain two separate locations for users to access remotely using OWA. This creates unnecessary confusion and increases administrative overhead. Maintaining old systems also prevents Exchange Server from switching to Native mode. Switching to Native mode unlocks access to some new features of Exchange Server 2003, such as the following: Ability to rename the Exchange organization. Ability to consolidate administrative groups. Ability to move mailboxes between servers in different administrative groups. Ability to create query-based distribution groups. Ability to create the InetOrgPerson object used for mobile users migrating from another LDAP-based system. Ability to remove ADC. Retiring old servers as soon as users can be migrated from them is recommended. Consolidating accounts onto MOCOR2 streamlines administrative efforts while improving the experience of remote users by providing access to a more enhanced OWA. After all mail users have been migrated from the old server, the server can be decommissioned and redeployed, if the hardware meets the minimum requirements.

39 Chapter 1: Planning and Implementing Migration Strategies 23 After decommissioning all the old servers, switching Exchange Server to Native mode is recommended to enable access to the advanced feature set. Real World Lucerne Publishing was eager to get rid of Exchange Server 5.5. After users were shown the enhanced OWA that shipped with Exchange Server 2003, they decided to decommission the old server. Lucerne Publishing migrated all the users to the new Exchange Server 2003 on MOCOR2. After setting up the Virtual SMTP Server, they configured mail delivery to go to that server and then removed Exchange Server 5.5. To see the steps for removing Exchange Server 5.5, refer to the Microsoft Knowledge Base article How to Remove the Last Exchange Server 5.5 Computer from an Exchange Server 2003 Administrative Group, available atsupport.microsoft.com/?id= File Services Decommissioning Exchange Servers involves the following steps: 1. Move the remainder of the mailboxes to the new servers. 2. Break Public Folder Replica links. 3. Remove ADC. 4. Remove the old Internet mail connectors. 5. Configure the Virtual SMTP Server. 6. Redirect port 25 traffic through the ISA Server. 7. Remove the servers from the Exchange site list. 8. Use Exchange System Manager to switch to Native mode. At the acceptance of the medium IT pilot, the decision needs to be made whether to migrate all data shares to DFS in the medium business IT environment. Another decision to be made is whether to move the actual files and shares from the old servers. Migrating existing shares to DFS can help overcome many obstacles to migration. It is possible to first create links to all existing shares on the old servers. When this stage is completed, all client computers can be directed to the DFS share to access data. After this is accomplished, the data can be migrated from the legacy servers, and only the DFS link needs to be changed. All users will then continue to have access to the data. It is recommended that you fully implement the use of DFS for file access. Configure all nonpilot computers with access to DFS to ensure continued connectivity with data while computers are moved from the old network configuration to the new medium business IT environment. Finally, it is recommended that all shares be migrated from the old servers and the DFS links updated to point to the new location.

40 24 Microsoft Windows Server System Deployment Guide for Midsize Businesses Real World Lucerne Publishing found that implementing DFS made migration to the new medium business IT environment a simple solution. They opted to get all users up and running on the new DFS root prior to moving data from the old server to the new Windows Server 2003 servers. This allowed the IT team to move data as needed, and all they had to do was update the DFS link. Users never noticed that data was being migrated to different servers. To implement the file services 1. Inventory the old server and document shares. 2. Create links to shares within DFS. 3. Migrate data from the old network and change DFS links to follow the data. 4. Configure client workstations to point to DFS instead of the old network location. Testing the Medium IT Solution Full Rollout As with the initial pilot, the true test of the full-scale rollout is the day-to-day operation of clients in the new environment. At this point, the number of variables in the configuration has increased. It might be necessary to make changes to client workstations. Performing daily tasks will reveal areas that need attention and help discover issues that were unforeseen. A general round of tests should again be initiated to verify that core services are working as expected: Test client sign in. Verify that Group Policies have been applied. Perform DNS queries. Verify DHCP redundancy by shutting down each DHCP Server and having a client request an IP address. Test NetBIOS name resolution. Send and receive with both internal and external contacts. Verify Internet connectivity. Verify that any destination restrictions set within the ISA Server are functioning. Verify file access through DFS. Verify Shadow Copy restoration. Verify that all functionality prior to the full rollout continues to function.

41 Pilot Rejection and Rollback Chapter 1: Planning and Implementing Migration Strategies 25 If for some reason the business does not want to continue with the implementation, the following section describes how to perform the rollback. Rolling back to the original network state, or a state close to the original network state, is possible if the recommendations in this guide have been followed. The steps required for rollback will vary depending on the initial state and version of the operating system. To roll back a Windows NT-based environment 1. Windows NT rollback is accomplished by transitioning core services that were removed from the PDC back to that server, returning file and print services back to the server, and moving mailboxes back to the old servers. For example, if you removed WINS and DHCP, reinstall these services back on the old hardware. Disable any ADC connection agreements. 2. Uninstall the ISA client and Shadow Copy client from the pilot workstations. 3. Reset the pilot computers default Web page. 4. Use the Move Mailbox Wizard to return mailboxes to their original location on the old Exchange Server. Remove public folder replicas from MOCOR2. 5. If any files shares were moved, move them to the original location. 6. When the configuration of the server is returned to its original state, shut down the primary infrastructure server, and elevate the BDC to PDC by using Server Manager. 7. Restart all workstations to ensure that they receive DHCP addresses from the Windows NT Server. 8. Using Server Manager, remove computer accounts for the Windows Server 2003 server. 9. If DNS was used, remove any host entries for the Windows Server 2003 server from within DNS. To roll back a Windows 2000-based environment 1. Removing Windows 2003 and returning to a Windows 2000 environment is accomplished by returning all services and roles to the Windows 2000 domain controllers. 2. Uninstall the ISA client and Shadow Copy client from the pilot workstations. 3. Reset the pilot computers default Web page. 4. Use the Move Mailbox Wizard to return mailboxes to their original location on the old Exchange Server. Remove public folder replicas from MOCOR2. 5. If any files shares were moved, return them to the original location.

42 26 Microsoft Windows Server System Deployment Guide for Midsize Businesses 6. Transfer FSMO roles back to the Windows 2000 domain controllers. Ensure that Global Catalog status is returned to each of the Windows 2000 Servers that formerly held the Global Catalog role. 7. Run Dcpromo on the Windows Server 2003 primary infrastructure server. Remove Active Directory from the server, making it a member server. Remove the server from the domain, and delete the computer account for it from Active Directory and DNS. 8. Restart all workstations to ensure that they receive DHCP addresses from the Windows 2000 Server.

43 Chapter 2 Deploying Core Infrastructure Services with Microsoft Windows Server 2003 This chapter provides guidance that can be used to plan, build, deploy, and operate a standardized, pre-tested IT environment for medium-sized businesses. As defined in this book, this guidance is optimized for businesses with 50 to 250 client computers and 5 to 15 servers. Running an IT environment in a small business is often quite simple, with only one server running an operating system such as Windows Small Business Server There is little question of how many servers to purchase and which applications and services to deploy on which server, as there is only one in the environment. As businesses grow past 50 client PCs, multiple servers are most often required to address the additional scalability and storage requirements. Suddenly, the question of how many servers to purchase and which applications to deploy on which servers becomes a more complicated one. Additionally, mediumsized businesses are often able to consolidate multiple services onto single servers, thus reducing hardware requirements and taking advantage of available processing power and storage. This is in contrast to larger enterprises, who often have to dedicate single (or multiple) servers to single tasks due to scalability and storage concerns. The goal of this book is to provide guidance to medium-sized businesses about a recommended and tested network topology. We will attempt to address the question of how many servers to purchase and which applications/services to deploy on which servers to maximize performance, yet balance that performance by attempting to minimize hardware purchase requirements. There is no one perfect network topology that is appropriate in a multi-server environment such as this. Are there other topologies and configurations which would provide the required performance and reliability for a medium-sized business? Certainly. We will attempt to describe topology options you can employ, based on specific business needs or additional hardware requirements. However, most medium-sized businesses will be well served by the topologies recommended below. 27

44 28 Microsoft Windows Server System Deployment Guide for Midsize Businesses Recommended Network Topologies for Medium-Sized Businesses Medium-sized organization IT infrastructures have two typical implementations, or topologies. Figures 2-1 and 2-2 show the two topologies, including the recommended hardware for two scenarios. Scenario 1 uses a hardware router and firewall, and Scenario 2 uses ISA Server. Hardware Router and Firewall Internet Network Server Windows Server 2003 STD SP1 Core Services AD / GPO IAS DHCP DNS WINS IIS Cert Svc File/Print Branch Office Messaging Server Windows Server 2003 STD SP1 Core Services AD / GPO DHCP DNS WINS IIS Exchange 2003 STD SP2 - OWA - RPC/HTTP - OMA/EAS Recommended - IMF Hardware 2x2.4 Ghz - CPU 2GB RAM 2x36 GB OS 3x146GB Data 2x1Gb NIC Home Office LAN Recommended Hardware 2x2.4 Ghz - CPU 2GB RAM 2x36 GB OS 3x146GB Data 2x1Gb NIC Management Server Windows Server 2003 STD SP1 Core Services MOM2005WGE WSUS WSS SP1 RIS Software Distribution Recommended Hardware 2x2.4 Ghz - CPU 2GB RAM 2x36 GB OS 3x146GB Data 2x1Gb NIC Printer Desktop Desktop Laptop Laptop Tablet PC Windows XP Professional SP2, Office 2003 Pocket PC Wireless Access Point Figure 2-1 Scenario 1: Medium business IT infrastructure with hardware firewall

45 Chapter 2: Deploying Core Infrastructure Services with Microsoft Windows Server Internet Branch Office Edge Server Windows Server 2003 STD SP1 Core Services ISA 2004 STD SP1 VPN + Quarantines Proxy Firewall Cache Web Publishing Home Office Messaging Server Windows Server 2003 STD SP1 Recommended Core Services Hardware AD / GPO 2x2.4 Ghz - CPU DHCP 2GB RAM DNS 2x36 GB OS WINS 2x1Gb NIC IIS Exchange 2003 STD SP2 - OWA - RPC/HTTP - OMA/EAS - IMF Core Services AD / GPO IAS DHCP DNS WINS IIS Cert Svc File/Print Recommended Hardware 2x2.4 Ghz - CPU 2GB RAM 2x36 GB OS 3x146GB Data 2x1Gb NIC LAN Recommended Hardware 2x2.4 Ghz - CPU 2GB RAM 2x36 GB OS 3x146GB Data 2x1Gb NIC Management Server Windows Server 2003 STD SP1 Core Services MOM2005WGE WSUS WSS SP1 RIS Software Distribution Recommended Hardware 2x2.4 Ghz - CPU 2GB RAM 2x36 GB OS 3x146GB Data 2x1Gb NIC Printer Pocket PC Wireless Access Point Desktop Desktop Laptop Laptop Tablet PC Windows XP Professional SP2, Office 2003 Figure 2-2 Scenario 2: Medium business IT infrastructure with ISA Server

46 30 Microsoft Windows Server System Deployment Guide for Midsize Businesses Both topologies have core infrastructure servers on a LAN with a firewall providing routing, security, and possibly filtering of packets coming in from the Internet. With both topologies, branch offices are connected to the main office through VPN connections over the Internet. The difference between the two topologies is that for one the firewall is a hardware router and firewall and for the other a software firewall is used. The use of a software firewall, such as ISA Server, allows the additional filtering and examination of packets down to the application layer. Although it is clear that having two appropriately configured firewalls is more secure than having just one, the second topology assumes that a hardware firewall is not used. If an organization already has a hardware firewall, it could continue using this in parallel with ISA Server. Assuming that the additional security, management, and reporting features available with ISA Server are worth the investment, the following steps describe the setup and configuration of an ISA Server. Another assumption is that the existing and proposed topology includes an Ethernet network with both wired and wireless clients. The recommendation is to use a combination of Fast (100 Mbps) and Gigabit (1 Gbps) Ethernet LANs at both the main and branch offices because it is easy to implement, cost effective, and popular. The ISA Server will be the firewall for the main office; branch offices will use a hardware firewall router provided by the ISP, or the organization will purchase a hardware firewall. This book recommends deploying two redundant servers: a primary infrastructure server (MOCOR1) and a secondary infrastructure server (MOCOR2). Under normal conditions, the primary infrastructure server provides most of the network services because the majority of client requests are first directed to this server. In cases where this server fails to give a timely response, most requests are then directed to the secondary infrastructure server. The majority of client requests are directed to the secondary server only when the primary server does not respond in a timely manner. It is recommended to place Active Directory, DNS, DHCP and WINS on both the primary and secondary infrastructure servers for redundancy because of the criticality of these services. Table 2-1 presents the services hosted on the primary and secondary infrastructure servers. Table 2-1 Services Hosted on the Primary and Secondary Infrastructure Servers Service Primary Infrastructure Server Secondary Infrastructure Server Active Directory Holds all of the operations master roles (also known as flexible single master operations or FSMO). The first server in the forest and domain, and a Global Catalog server. Holds no operations master roles. A Global Catalog server.

47 Chapter 2: Deploying Core Infrastructure Services with Microsoft Windows Server Table 2-1 Service Primary Infrastructure Server Secondary Infrastructure Server DNS Configured as the primary DNS server on all clients. Configured as the secondary DNS server on all clients. Clients query this server only if the primary infrastructure server fails to respond in a timely manner. DHCP WINS Additional services Services Hosted on the Primary and Secondary Infrastructure Servers Configured with a scope to cover more than 250 clients, in addition to servers and other devices that require reserved address. Configured with scope options that designate the preferred and secondary DNS and WINS servers, default gateway, and proxy server information. Configured as the preferred WINS server, which resolves IP addresses for NetBIOS names. Optionally, this server might be configured to host services that are less resource-intensive, such as: CA IAS Windows Server Update Services (WSUS) File services Print services Same configuration as the primary infrastructure server. Shares the DHCP client request load with the primary infrastructure server. Configured as the secondary WINS server. Provides most network services only when the primary infrastructure server fails. Because this server is under less or no load at most times, it can be used to host services, such as messaging, that require a lot of server resources. Real World Lucerne Publishing opted to implement both the primary and the secondary servers after the introduction of a swing server in the environment. (For more information on the implementation of a swing server, refer to Chapter 1, Planning and Implementing Migration Strategies. ) Following the successful implementation of both the primary and the secondary infrastructure servers, Lucerne Publishing retired its old servers. Because the network services in a typical medium-sized business environment do not consume a lot of resources such as processors, memory, and storage, hosting additional services such as certificate services or file and print services on the infrastructure servers can also be beneficial. (Note that running file and print services would require additional storage space.) In addition, if cost is a factor, the secondary infrastructure server also can be used to host additional services such as messaging or collaboration. All of these core services are provided by Windows Server 2003, Standard Edition on the core infrastructure servers.

48 32 Microsoft Windows Server System Deployment Guide for Midsize Businesses If you are using Microsoft Internet and Security Acceleration (ISA) Server 2004, it is strongly recommended to not run any additional services on this server. Each service has its own vulnerability, and increasing the number of services running on the server therefore increases the number of vulnerabilities to which the server is exposed. Instead, you can host the virtual private network (VPN) service on the firewall server, unless you have a large number of remote users or branch offices. For messaging, if the business considers cost as the critical factor compared to performance, reliability, and security, you can host Exchange Server 2003, Standard Edition on the secondary infrastructure server, after adding additional storage to the server. The secondary infrastructure server is recommended because during normal operations, this server has the least load. Also, by hosting Active Directory on the same server as Exchange Server, Global Catalog lookups required by Exchange are expedited. If the messaging service is critical to the business and reliability, performance, and security are considered more important than cost, you can implement a dedicated server to host Exchange Server. If the business does not have large storage requirements, you can host file and storage services on the primary infrastructure server. To provide the required reliability and performance, store all the data in a separate volume created on a dedicated RAID 5 array. Choose appropriate disk size and quantity to meet the present and future storage requirements. If the business meets the following requirements, consider hosting file and storage services on a Windows Storage Server 2003 based, network-attached storage device: Storage requirement is high or is expected to grow, and a scalable storage solution is needed. Centralized storage is desired for easy backup and storage management. In addition, consider the requirements for the print service because file and print services are usually hosted together on the same server or device. The third server in this recommended topology (MOMGMT) is used to run management, monitoring, patch management, and any software distribution shares. This server will host Operations Manager 2005 Workgroup Edition (MOM WE), Windows Server Update Services (WSUS), and Windows SharePoint Services. Usually, the best place to host the backup and restore service is along with the file service, thus increasing the performance of the backup service because most of the files are then stored locally. Based on the placement of the file service, you can host the backup and restore service on either the primary infrastructure server or on the Windows Storage Server 2003 based, network-attached storage device. Running terminal services with other services might create additional security issues. Therefore, for greater performance and security, you can provide a terminal server on dedicated server hardware.

49 Chapter 2: Deploying Core Infrastructure Services with Microsoft Windows Server Publishing Internal Services to the Internet It is important to make the internal resources available to users on the LAN and on the Internet. This includes: Access to public Web servers for external users and e-business customers. Access to internal Web sites, which is required for access to OWA and Microsoft Windows SharePoint Services, for mobile users and business partners. To provide a network that is cost-effective and simple to build, deploy, and maintain, two networks are recommended: one for the internal network, and the other for connecting to the Internet through an Internet service provider (ISP) network. All the servers are placed in the internal networks and published to the Internet through ISA Server In this solution, the ISA Server provides the following two types of publishing: Server publishing: This type includes publishing the (SMTP) server and publishing the terminal server. Web publishing: This type includes publishing Web servers for public access (a public Web server) and publishing Web servers that host services such as OWA and SharePoint by using secured HTTP (HTTPS) for remote access by employees and business partners. Publishing the server enables the internal server to send Internet-bound messages through ISA Server to the Internet, and allows receipt of messages from the Internet server. Publishing terminal server through ISA Server enables remote users to access Internet applications that run on the internal terminal server securely from anywhere. In addition, mobile users can access their desktop systems located in their organization s internal network securely by using the Internet anytime. Publishing OWA allows the remote users to securely access servers from anywhere over the Internet. Similarly, publishing a SharePoint site allows the remote users and partners to securely create and access virtual workspaces and exchange documents securely over the Internet. Server Naming Conventions It is important to carefully consider the naming conventions for the IT environment. Computers should be named according to a standardized naming convention. A proper naming convention helps identify the role of a server or device on the network. Following the same

50 34 Microsoft Windows Server System Deployment Guide for Midsize Businesses naming convention across all devices in the network makes it easier to remember and manage the network. With a standardized naming convention, administrators and the support personnel can work in the environment with less confusion. In many cases, it is also helpful to include the purpose of a device or computer in the environment as part of the naming convention. For example, you might include DC in the name of a computer to signify that it is a domain controller. Table 2-2 lists the naming convention commonly used for servers and clients. Table 2-2 Device Server Client A Sample Naming Convention Naming <Role><UI> <OU><UI> The elements listed in Table 2-2 are defined as follows: <Role>: Role of the server. Examples include using DC for domain controller and EX for Exchange Server. <UI>: Unique Identifier. This field is used to differentiate between two computers with similar roles and operating systems. Examples might include using a number or an abbreviation, such as PRI and SEC, to differentiate between primary and secondary roles. For client computers, <UI> is usually a room number or extension number. <OU>: Organizational Unit. This field is used to designate the profit center or the group to which a client belongs. For example, use ACT or HR for the accounting or human resources departments, respectively. Real World The following table provides the naming convention used by Lucerne Publishing in its environment. Server Primary infrastructure server Secondary infrastructure server Firewall and VPN server Windows Storage Server 2003 based network-attached device Management server Terminal Server Server Name MOCOR1 MOCOR2 MOISA MONAS MOMGMT MOTS DNS Design To maintain simplicity in the environment, this book recommends using a single DNS namespace for both the internal and external DNS naming. There is no need or real advantage to using separate internal and external DNS namespaces in an IT environment of this size.

51 Chapter 2: Deploying Core Infrastructure Services with Microsoft Windows Server The registered domain name points to a DNS server that is authoritative for the DNS namespace. The organization needs to decide whether to use a public DNS server (owned by an ISP) as the authoritative DNS server, or to host its own DNS server that is authoritative for the DNS namespace. This book recommends using an ISP owned public DNS server as the authoritative DNS server for the DNS namespace of the organization because ISP DNS servers usually provide better availability. To host your DNS namespace on the DNS server of an ISP, you need to buy the services from an ISP. DNS hosting services typically can be bought from the DNS registrar or from the ISP that is providing the Internet connection, and are often included as part of a package when registering a domain or hosting a public Web site. The domain name registered with domain registrar, such as BusinessName.com, needs to point to the authoritative DNS server of the domain. The authoritative DNS server maintains all the DNS records for the DNS namespace, such as and remote.business- Name.com. The DNS records on the authoritative DNS server need to be maintained by the organization. Because the authoritative DNS server is owned by an ISP, the ISP needs to provide some mechanism to enable the organization to manage these records. In most cases, ISPs provide a Web-based utility and logon credentials to organizations when they buy the DNS hosting services. To enable access to services using the Internet, the organization needs to update or add DNS records on the public DNS server of the ISP. For more information, refer to the Installing and Configuring DNS section later in this chapter. Planning DHCP This book recommends the following for IP addresses: Use the private IP address range 10.x.x.x for the LAN at both the main office and branch offices. More specifically, consider the following: Use the /16 subnet at the main office. Use the /24 subnet for the first branch office. For additional branch offices, use the 10.n.0.0/24 subnet, where n is equal to 2 for the second branch office and increments by one for each additional branch office. Use public IP addresses on the external interface of the firewall at the main office and the multipurpose router at branch offices.

52 36 Microsoft Windows Server System Deployment Guide for Midsize Businesses Within these subnets, the addresses are further classified, as shown in Table 2-3. Examples are provided only for the first branch office. Table 2-3 IP Addressing Recommendations IP Address (or Range) Subnet Mask Location Used for to Main office Servers to Main office Remote management cards. (To get the card address for a server, add 20 to the last octet of the IP address of the server.) to Main office All other network devices that require static IP addresses (for example, printers, scanners, IP cameras, and switches) x Main office Assigned by the primary infrastructure server to DHCP clients at the main office x Main office Assigned by the secondary infrastructure server to DHCP clients at the main office Branch office to Branch office to Branch office Configure the public IP address, subnet mask, and default gateway provided by the ISP to the external interface of the firewall server at the main office. Use DHCP to assign all IP addresses on the medium IT network, both static and dynamic, with the exception for the following three servers: Primary and secondary infrastructure servers: These servers run the DNS service, which requires that a static IP address be assigned on the computer. Internet Security and Acceleration (ISA) Server: This server is directly connected to the Internet. Therefore, this server requires a gateway to be configured that is different from all other servers. Because the medium IT environment uses options, including default gateway, as part of the DHCP implementation, this server must be excluded from using DHCP. Use DHCP options to assign clients values for the following: Internal interface of the multipurpose router at the branch office. All other network devices that require static IP addresses (for example, printers and scanners). For DHCP clients at the branch office. Primary and secondary DNS servers Primary and secondary WINS servers Default gateway Domain suffix Web Proxy Auto Discovery Protocol (WPAD)

53 Chapter 2: Deploying Core Infrastructure Services with Microsoft Windows Server The external interface of the multipurpose branch office router should be configured with the IP configuration provided by the ISP. The multipurpose branch office router should also be configured as a DHCP server and should use the IP address range provided in Table 2-3. For more information on configuring the router, refer to the documentation provided by the manufacturer. Use the following DHCP options for branch offices: DNS servers: Most multipurpose routers that have DHCP capability allow configuring up to three entries for DNS servers and two entries for WINS servers. At least one internal DNS server and one external DNS server should be configured on the DHCP service on the branch office router. This is necessary so that the router is able to resolve host names for both internal and external hosts. Also ensure that the internal DNS servers are specified before the external DNS server in the list of servers, so that the router resolves host names by using the internal DNS server first. If the internal DNS server is unable to resolve the name, the router tries to resolve the name by using the external DNS server. If the order is reversed, the router sends requests to the public DNS server to resolve internal names, which is not recommended. Use the following values for DNS server IP configuration: First DNS server: IP address of internal primary DNS server. Second DNS server: IP address of internal secondary DNS server. Third DNS server: IP address of the public DNS server given by the ISP that provides Internet connection to the branch office. WINS servers: Use the IP address of the internal primary and secondary WINS servers. Default gateway: Use the IP address of the internal interface of the branch office router. Note When configuring the IP parameters of the primary and secondary infrastructure servers and the firewall server with static IP addresses, configure all the DHCP options that are configured for DHCP client devices. Both the infrastructure servers should have their primary DNS and WINS servers configured with their own IP addresses and should have their secondary DNS and WINS servers configured with the IP address of the other infrastructure server. The default gateway for both these servers should be (the IP address of the firewall server). On the firewall server, the primary DNS and WINS servers should be set to the IP address of the primary infrastructure server and the secondary DNS and WINS servers should be set to the IP address of the secondary infrastructure server; the gateway should be left blank.

54 38 Microsoft Windows Server System Deployment Guide for Midsize Businesses Real World Lucerne Publishing followed the recommendations in this book. The following table provides some examples of the IP addresses used by Lucerne Publishing. Device Type Name IP Address Firewall server (external interface) MOISA Public address from ISP Firewall server (internal interface) MOISA Primary infrastructure server MOCOR Secondary infrastructure server MOCOR Management server MOMGMT Directly attached hardware, such as LJ4KACCT, SCANRSLS printers and scanners Remote management cards server IP address Client devices FIN302, SAL Building and Deploying the Medium Business IT Architecture The guidelines in this section should be implemented in a planned and predictable manner to ensure that users have access to existing systems and that IT administrators have the ability to roll back and recover to an earlier known state, in case something goes wrong. For this reason, a well thought out pilot deployment and a detailed migration plan are essential. After planning is complete, the overall tasks include: Building the core infrastructure and performing the initial configuration: Guidelines are provided in this chapter for building and configuring the core infrastructure with the exception of firewalls and messaging, which will be covered in Chapter 3, Installing and Configuring Firewalls, and Chapter 4, Installing and Configuring Microsoft Exchange Server Building the supplementary services: Guidelines are included in this chapter for implementing collaboration service, remote connectivity, update services, operations management, and antivirus protection. Building Core Infrastructure Servers The following guidance briefly deals with hardware recommendations for servers; readers should refer to the hardware recommendations included in the two basic network configuration diagrams earlier in this chapter.

55 Chapter 2: Deploying Core Infrastructure Services with Microsoft Windows Server Hardware Recommendations When choosing hardware for the infrastructure servers, the critical factors to be considered are: Processor and random access memory (RAM) Storage configuration Processor and Random Access Memory (RAM) When selecting processors for the infrastructure servers, consider the tasks that the servers will perform when the environment is fully built. In the topology recommended above, it is not expected that the basic network services will place significant burden on the processors. Among all the additional services that are recommended to be hosted on the infrastructure servers, only the messaging service requires more processing power. Therefore, a faster processor should be used on the secondary infrastructure server if messaging services are hosted on it. In many cases, the guidelines for selecting RAM closely follow the guidelines for selecting the processor. For the basic infrastructure services and for providing additional services, such as file and print services, a large amount of RAM is not required. However, for messaging services, additional RAM can improve performance. Storage Configuration Direct-attached storage (DAS) is used on the infrastructure servers for storing the system files and data. When configuring RAID on the infrastructure servers, consider the following options: Configure all drives as a single partition on a RAID 5 array. Configure all drives as multiple partitions on a RAID 5 array. Configure a system partition on a RAID 1 array and a data partition on a RAID 5 array. Configuring all drives as a single partition on a RAID 5 array offers the advantage of simplicity. This configuration also avoids issues that might occur later where one partition becomes full while other partitions have a lot of free space. However, this configuration does not remain viable when partitions become very large, because performance suffers. In addition, with large partitions, certain features in the operating system no longer work. For example, you cannot use the built-in Windows backup utility to back up a partition to a file that is on the same partition. Configuring all drives as multiple partitions on a RAID 5 array with very large partitions gets rid of some of the performance-related issues. However, it creates additional issues, such as having to choose the partitions onto which services and data should be deployed. When the partitions become full, there is no easy way to move these services to a different location.

56 40 Microsoft Windows Server System Deployment Guide for Midsize Businesses Configuring the system partition on a RAID 1 array and the data partition on a separate RAID 5 array eliminates all the issues that are present in the two other options. In this configuration, the RAID 1 system partition uses only two disks and is a smaller partition. Only the operating system and other system files, such as updates and service packs, are placed on this drive. The RAID 5 partition is used for applications and data and is only required if the server hosts any of the following services: A file service A messaging service A collaboration service Installing and Configuring Active Directory Active Directory needs to be installed on both the infrastructure servers (MOCOR1 and MOCOR2). In most medium businesses that have an NT 4.0 domain, installing and configuring Active Directory is performed during the pilot as an upgrade of the existing Windows NT 4.0 domain, as discussed in Chapter 1, Planning and Implementing Migration Strategies. To reiterate, an additional swing server is used during the upgrade. After the upgrade of the swing server, MOCOR1 is converted into a Windows Server 2003 domain controller. The steps are as follows: 1. Add a swing server (SWING) as awindows NT 4.0 Backup Domain Controller (BDC). 2. Promote SWING to the Primary Domain Controller (PDC). 3. Install and configure DNS as discussed in the next section 4. Upgrade SWING to Windows Configure SWING as Active Directory Integrated DNS. 6. Install MOCOR1 and MOCOR2 as Windows 2003 DCs. 7. Make MOCOR1 and MOCOR2 Global Catalog servers. 8. Force replication. 9. Transfer FSMO roles to MOCOR Demote SWING to a member server. 11. Remove SWING from the domain and decommission it. Installing and Configuring DNS DNS should have been installed on SWING prior to promoting it to PDC. DNS must be installed and configured manually on MOCOR1, which involves the following tasks: 1. Install DNS. 2. Configure forwarders on both the DNS servers.

57 Chapter 2: Deploying Core Infrastructure Services with Microsoft Windows Server Enter the IP addresses of at least two public DNS servers in the order provided by your ISP. 4. Configure reverse lookup zones on the DNS servers. 5. Configure each zone created in DNS with the address of the responsible person for the zone. Configuring the Windows Time Service Configure the Windows Time Service on MOCOR1 by performing the following steps: 1. Open a command prompt window. 2. Type w32tm /config /manualpeerlist: time.windows.com tock.usno.navy.mil /syncfromflags:manual, and then press Enter. The message The command completed successfully should be displayed. 3. Type w32tm /config /update, and press Enter. The message The command completed successfully should be displayed. Installing and Configuring DHCP Installing and configuring DHCP involves the following tasks: 1. Install the DHCP service. 2. Authorize the DHCP servers. 3. Create a new scope on MOCOR1. 4. Create a new scope on MOCOR2. 5. Configure reservations for network devices requiring static IP addresses. 6. Enable dynamic updates by performing the following steps: a. Right-click the server name, and click Properties. b. Click the DNS tab. c. Select the following three check boxes on the DNS tab: Enable DNS dynamic updates according to the settings below Discard the A and PTR records when the lease is deleted Dynamically update the DNS A and PTR records for DHCP clients that do not request updates (for example, clients running Windows NT 4.0) 7. Enable server-side conflict detection on both servers by performing the following steps: a. Right-click the server name, and then click Properties. b. Click the Advanced tab. c. Set the Conflict Detection Attempts value to 2.

58 42 Microsoft Windows Server System Deployment Guide for Midsize Businesses Installing and Configuring WINS Installing and configuring WINS involves the following tasks: 1. Install the WINS service on both infrastructure servers. 2. Configure the WINS servers as replication partners. 3. Enable WINS forward lookup and reverse lookup on both servers. Installing and Configuring the Certification Authority Install and configure CA on MOCOR1 by performing the following steps: 1. Open Add or Remove Programs, and then click Add/Remove Windows Components. 2. In the Windows Components Wizard dialog box, select the Certificate Services check box, and when a message box displays a message that the computer cannot be renamed and cannot be added to or removed from a domain after certificate services are installed, click Yes. 3. Highlight Application Server (do not select the check box), and then click Details. 4. Select the Internet Information Services (IIS) check box, and then click OK. 5. Click Next. 6. On the CA Type page, select the Enterprise root CA option. 7. On the CA Identifying Information page, enter the following information: In the Common name for this CA field, enter the common name of the CA; for example, MyBusinessName CA. In the Validity period field, specify 10 years as the validity period for the root CA, and then click the Next button. Accept the default storage locations for the certificate database and the certificate database log. 8. Click the Next button. 9. Click Yes to the warning about installing Active Server Pages (ASPs). 10. Click Finish. 11. Verify that you can get to the Web enrollment page by opening Microsoft Internet Explorer and navigating to Ensure that Session State is enabled for successful CA enrollment through the certsrv Web site by following these steps: 1. Open Internet Information Services Manager from Administrative Tools.

59 Chapter 2: Deploying Core Infrastructure Services with Microsoft Windows Server Expand <servername>, and then expand Web Sites. Next, right-click Default Web Site, and then click Properties. 3. Click the Home Directory tab, and then under Application Settings, click Configuration. 4. On the Application Configuration page, click the Options tab, and then ensure that the Enable Session State check box is checked; if not, select it. 5. Click OK on all screens, and then close IIS Manager. 6. Restart IIS by typing iisreset at a command prompt. Performing Final Security Configuration Validation After completing the configuration of the two infrastructure servers, it is important to once again complete a full security audit on both the servers to ensure that they are completely secured. Begin by checking for any server and installed software updates, and then install any updates that are available. Next, run the MBSA tool against each domain controller (MOCOR1 and MOCOR2). For more information on running this tool, refer to the help files that are installed with the tool. Testing the Services This section discusses the tests that should be performed to verify the configuration of the network and directory services. These tests should be performed after the servers are moved into the production network, but before they are placed into service. Network Configuration Testing On both the infrastructure servers, perform the following steps to test the network configuration: 1. Use the ipconfig utility on the server to ensure that the network parameters are configured properly. 2. Use the ping command to check the network connectivity with other systems on the network. Ping the systems by name to ensure that DNS is working correctly. 3. Use the nslookup command for DNS name resolution of local and Internet systems. Active Directory Testing Perform the following steps to test the Active Directory: 1. Join a client computer to the new domain. 2. Verify that the computer account is created in Active Directory. 3. Verify that it is possible to log on to a client computer with the domain user privileges.

60 44 Microsoft Windows Server System Deployment Guide for Midsize Businesses DHCP Testing Perform the following steps to test DHCP: 1. Check the IP configuration of a hardware device, such as a printer. Ensure that the correct IP information was received from the reservation on the DHCP servers. 2. Turn on a client computer, and ensure that it receives proper IP information from DHCP. DNS Testing Perform the following steps to test DNS: 1. From each server, ping the other server by name, and ensure that the name resolves to the proper IP address. 2. Turn on a new client computer, and ensure that a proper resource record is created in the DNS console for the workstation. Redundancy Testing Perform the following steps to test for redundancy: 1. Shut down the primary infrastructure server, and perform all the tests mentioned earlier in this section to ensure proper operation of the core infrastructure services. 2. After all the tests have been performed, turn on the primary infrastructure server. 3. Shut down the secondary infrastructure server, and perform all the tests mentioned earlier in this section to ensure proper operation of the core infrastructure services. Backing Up the System and Verifying the Backup It is strongly recommended that you perform a full backup of both the servers, including the system state information, before releasing the system to users. In addition, verify and ensure that the backup does not have any problems. This way, if a server fails for any reason, the backup can be used to bring the system back to its original state. Use specific tapes for this backup and retain the tapes. Do not use the tapes as a part of the normal rotation schedule.

61 Chapter 3 Installing and Configuring Firewalls Implementing a firewall solution on your network is a critical step toward securing your network against outside intrusions and attacks. This chapter provides guidance about installing and configuring firewalls for medium-sized businesses, including discussions about configuring hardware firewalls and deploying Microsoft Internet Security and Acceleration (ISA) Server ISA Server 2004 ISA Server 2004 is an advanced stateful packet and application-layer inspection firewall, virtual private network (VPN), and Web cache solution that improves network security and performance. ISA Server 2004 is available in two versions: Standard Edition and Enterprise Edition. Medium-sized businesses wishing to use ISA Server should purchase Standard Edition. There are also a number of hardware manufacturers who make ISA Server appliances. These devices come with a preinstalled hardened version of Windows Server 2003 and ISA Server 2004, ready for deployment. Several hardware vendors have also added additional components and technology to their products such as protocol accelerators, antivirus gateways, and content filtering software to extend the value of ISA Server 2004 for your infrastructure. (Visit for more information.) ISA Server 2004 provides multiple benefits such as performing intrusion detection and application filtering. It also provides Web proxy services and Web caching, as well as logging, monitoring, and reporting services. Intrusion Detection Intrusion detection is a process that proactively detects inappropriate, incorrect, or anomalous activity from an external network (the Internet) against the IT infrastructure of an organization. Some of the popular intrusion methods include port scanning, WinNuke, DoS attacks, or ping of death, which a regular firewall cannot detect. The intrusion could be accidental or intended with the purpose of disrupting work or damaging the reputation of the organization. Unless these attacks are detected well in advance and appropriate actions taken, they can lead to financial losses and customer dissatisfaction. 45

62 46 Microsoft Windows Server System Deployment Guide for Midsize Businesses Many organizations sell intrusion-detection tools for an additional cost. ISA Server 2004 has an integrated basic intrusion detection tool licensed from Internet Security Systems (ISS) that provides a cost-effective intrusion-detection solution for any medium business. Application Filtering Application layer protocol traffic, such as SMTP, HTTP, DNS, Remote Procedure Call (RPC), PPTP, and FTP, can contain malicious codes and scripts, inappropriate commands, and binary files containing viruses. These codes, scripts, commands, and viruses can cause serious damage if they reach the internal network of the organization. Application filtering scans the traffic passing through the firewall and filters out packets that have malicious code, scripts, or viruses. Both inbound and outbound traffic should be scanned. Outgoing traffic is scanned to ensure that the organization is not spreading viruses and worms on the Internet. The firewall server should be able to provide application filtering for various application layer protocols. The following are examples of how application filtering can be used in an IT environment: SMTP filtering protects internal mail servers from security threats. These threats include buffer overflow attacks caused by malicious SMTP requests designed and sent by the attackers. HTTP (and HTTPS) filtering enables a device to scan the HTTP and tunneled FTP traffic for hidden security threats. Possible threats include: Malicious code, viruses, and worms, such as Code Red and Nimda viruses, in content that is downloaded from the Internet. Web requests containing malicious code inside the HTTP header or data, which can cause internal Web servers to malfunction and send malicious code to other systems on the network. Examples include directory traversal attacks, buffer overflow attacks, cross-site scripting attacks, and high-bit encoding attacks. Malicious code hidden inside a Secure Socket Layer (SSL) connection, sent by a client computer connecting to the internal secure Web sites. Web Proxy The Web proxy feature enables the firewall to provide proxy services to Web requests coming from the internal network behind the firewall or proxy server. The firewall or proxy server creates connections to the Web servers on the Internet on behalf of clients on the internal network. The firewall receives responses from the Web server, inspects the content for any vulnerability, and then forwards the responses to the client on the internal network that requested the connection.

63 Chapter 3: Installing and Configuring Firewalls 47 Web Caching Web caching improves performance for users who download content from HTTP or FTP sites. Caching also improves the response time for internal clients who access Internet Web servers, as well as for external Internet users accessing an internal Web server. When internal users request content from Web servers on the Internet for the first time, the content is cached by the Web cache. When the same content is requested again by an internal user, the content is served from the Web cache. This process provides the following benefits: Improved response time: Serving the content from the cache is much faster than downloading the content from the Web server on the Internet. Reduced Internet bandwidth consumption: Because the data is downloaded only once, the Internet bandwidth, which is expensive, is conserved. Data availability: If the Internet or the Web server is unavailable for some reason, data can still be served to users from the cache. A similar process of Web caching takes place when external users request content from the Web server on the internal network. The difference, however, is that the caching happens for outgoing traffic, and the benefits include the following: Reduced load on the Web server: The Web server does not need to serve the same content multiple times. Data availability: If the internal Web server is unavailable for some reason, data can still be served to external users from the cache. Logging, Monitoring, and Reporting It is important to enable logging, monitoring, and reporting for the traffic flowing through the firewall between the internal network and the Internet. ISA Server 2004 provides detailed security and access logs in standard data formats, such as delimited text files, Microsoft SQL Server databases, or SQL Server 2000 Desktop Engine (MSDE) databases. You can run scheduled built-in reports on Web usage, application usage, network traffic patterns, and security and you can automatically publish these reports to a local folder or a remote file share. Eventdriven alerts can trigger messages to administrators, start and stop firewall services, and take automated action based on alert criteria. The benefits of enabling logging, monitoring, and reporting on the firewall server include the following: IT infrastructure usage tracking: The organization can keep track of how the IT infrastructure is being used by users. Individual users logged activities can be used to detect and prove misconduct or unauthorized activities.

64 48 Microsoft Windows Server System Deployment Guide for Midsize Businesses Intrusion detection: A detailed examination of logs can reveal intrusion attempts through DoS or similar attacks. These logs serve as evidence to take legal actions against offenders. Internet traffic analysis: Examination of data logged over a period of time can reveal information about the Internet traffic pattern of the organization. This information can be used to fine-tune Internet performance by actions such as increasing Internet bandwidth. The information can also be used for better management of the existing bandwidth by restricting certain users or applications from accessing the Internet. Troubleshooting: Logged data can help IT staff or service providers troubleshoot problems. Placement of a Firewall Server The ISA Server based firewall server can be deployed in one of the following ways: Directly connected to the Internet: In this setup, the firewall server is directly connected to the Internet and is the only device protecting the LAN from Internet threats. This is the most cost-effective solution and provides adequate security. Behind a hardware firewall: In this setup, the firewall server is placed behind a hardware firewall, as shown in Figure 3-1. This setup is typically recommended for organizations that already have an existing hardware firewall. Instead of discarding the existing firewall, it can be implemented jointly with the ISA Server based firewall server to provide an additional layer of security. Hardware Firewall Perimeter Network Firewall Server LAN Primary Infrastructure Server Secondary Infrastructure Server Internal Network (LAN) Figure 3-1 Firewall server placed behind a hardware firewall

65 Chapter 3: Installing and Configuring Firewalls 49 In the second setup scenario, the hardware firewall can be used as a stateful packet filter to inspect the incoming and outgoing traffic. This way, the function of stateful packet filtering can be offloaded from the firewall server, and the firewall server can be better used for other services, such as application layer filtering, intrusion detection, authenticated access to resources, and Web caching. For this setup to work, the hardware firewall should be configured to enable the firewall server function. In addition, the hardware firewall should support Network Address Translation (NAT). Table 3-1 lists the port configuration that is required on the hardware firewall. Table 3-1 Port Configuration Required on the Hardware Firewall Application Ports Direction Web Service TCP 80 Both Web Service (Secured) TCP 443 Both Service TCP 25 Both VPN PPTP TCP 1723, Protocol 47 Both VPN L2TP UDP 1701 Both VPN IPSec 500, Protocol 50 & 51 Both NTP UDP Outgoing from internal network DNS UDP - 53 Outgoing from internal network FTP TCP 20, 21 Both RDP TCP Both Note The port configuration shown in the table is also required on the hardware firewall if the organization decides not to implement an ISA Server based firewall server but to instead use only a hardware firewall. Firewall Policy By default, ISA Server denies all traffic in both directions. A firewall policy needs to be defined to allow or deny specific kinds of traffic to pass through the firewall based on the requirements of the organization. Recommended Policy Outbound Traffic The easiest configuration for outbound traffic with ISA Server is to allow all outbound traffic. This approach is simple and minimizes configuration errors and effort because there is no need to define selective firewall policies in such a configuration. However, the more secure approach is to selectively allow and disallow specific types of outbound traffic based on the requirements of the organization.

66 50 Microsoft Windows Server System Deployment Guide for Midsize Businesses Inbound Traffic In many instances, it is desirable to disallow all inbound traffic to provide maximum network security. However, with the topology recommended by this book, it is not possible to deny all inbound network traffic, due to some of the network services being enabled for Internet access. ISA Server makes it easy to publish these internal network services in a secure manner, enabling access to them from the Internet. Table 3-2 lists the general rules that should be suitable for most medium-sized business environments. Table 3-2 Firewall Rules Protocol/ Port Details From To Users Authentication Permission DNS Main and Internet DNS Internal DNS server No Allow (UDP, 53) branch offices server (used by internal main office systems, VPN clients, and branch office systems) HTTP Main and Internet Internal users Yes Allow (TCP, 80) branch offices HTTPS Internet Microsoft Home and mobile users Yes Allow (TCP, 443) Windows and business partners SharePoint Services and TSWeb-based terminal services in the main office HTTPS Main and Internet Internal users in the No Allow (TCP, 443) branch offices main office and branch offices FTP Main and Internet Employees No Allow (TCP, 21) branch offices SMTP Internal SMTP Internet SMTP Internal and Internet No Allow (TCP, 25) server servers SMTP servers SMTP Internet SMTP Internal SMTP Internal and Internet No Allow (TCP, 25) servers server SMTP servers access using OWA and HTTPS (TCP, 445) Internet Internal server in the main office Home and mobile users Yes Allow

67 Table 3-2 VPN clients using PPTP (TCP, 1723) and IP Protocol 47 VPN clients using PPTP (TCP, 1723) and IP Protocol 47 IPSec VPN tunnel (UDP, 500) and IP Protocol 50 & 51) NTP (UDP, 123) RDP Terminal Services (TCP, 3389) All other traffic Firewall Rules Protocol/ Port Details From To Users Chapter 3: Installing and Configuring Firewalls 51 Internet Main office Home and mobile users and business partners Internal network Internet Home and mobile VPN client users No Internal domain controllers Authentication Yes Permission Allow Allow Branch offices Main office Users in branch offices No Allow Internal domain controllers Internet Internetbased time servers Internal terminal server No Allow Employees Yes Allow Anywhere Anywhere Any Not applicable Deny Real World Lucerne Publishing decided to use rules from Table 3-2 to define the firewall policies on their firewall server. Built-In Templates ISA Server provides a few built-in templates that can be used to define the firewall policy. With each template, you can define multiple firewall polices with minimal effort, compared to the option of manually defining a firewall policy for each type of traffic individually. For example, a firewall policy defined by using the Edge template configures the ISA Server to allow only selected traffic to pass through, which includes DNS for public domain name resolution, HTTP and HTTPS for outbound Web browsing, and FTP from the internal network to the Internet. In addition, it enables mobile and home users to establish client-to-site VPN connections from the Internet to the internal network.

68 52 Microsoft Windows Server System Deployment Guide for Midsize Businesses Network Time Protocol Policy A firewall policy needs to be defined to allow both the domain controllers, which are the primary and secondary infrastructure servers, to synchronize time with the external Network Time Protocol (NTP) time source. By default, the domain controllers are configured to synchronize time with the time.windows.com NTP server. Intrusion Detection ISA Server 2004 provides basic intrusion detection of attacks, such as ping of death, IP half scan, and Microsoft Windows out-of-band (OOB) DoS attacks. In addition, the intrusion detection feature detects DNS-based intrusion attacks against the network. By default, intrusion detection is enabled on ISA Server and requires no additional configuration. Application Filtering ISA Server 2004 provides various application filters, such as SMTP, HTTP, and RPC filters. When the SMTP server is published by the ISA Server, the SMTP filter is applied on the publishing rule, which protects the internal SMTP server from various commands, including buffer overflow attacks. Similarly, when Web sites are published by the ISA Server, the HTTP filter is applied, which protects the internal Web server from various attacks. Web Caching In the medium IT environment, consider the following best practices while configuring the Web caching feature of ISA Server 2004 on the firewall server: For best performance, use a separate storage volume from the one on which the operating system and ISA Server software are installed. Enable active caching for large objects that are accessed frequently to save network bandwidth and download time. If the source object content changes frequently, configure Web caching to compare the version of the object in the cache with the version of the object on the original server. If a valid version exists in the cache, serve the request from the cache; otherwise, route the request to the original server. If you have limited hardware resources on the Web caching server, which affects the server performance, then restrict the caching of large objects. If a large amount of content needs to be cached, schedule downloading of the content during off-peak hours. Create Web caching rules based on the content or the object type; for example, HTTP and FTP.

69 Chapter 3: Installing and Configuring Firewalls 53 Logging Logging can be configured for the following components of ISA Server: Firewall service Packet filters Web proxy service The following types of logging can be configured on ISA Server: Logging to a file: When logging to a file, you can choose to compress the log files and to specify the maximum number of log files for the ISA Server. A new log file is created at the beginning of each day. Logging to a database: Events can be logged to Open Database Connectivity (ODBC) compliant database, such as Microsoft Data Engine (MSDE) or SQL Server. A database provides improved performance and fast querying than a log file. You cannot set log file size limits for logs that are stored as rows in a SQL Server database. Logs stored in an MSDE database or in a file format can be a maximum of 2 GB. By default, the MSDE database logs are stored in the ISA Logs folder where the ISA Server 2004 application is installed. The log viewer can be used to monitor, analyze, and troubleshoot network activity. Live activities can be monitored by using the log viewer, regardless of whether the logs are stored in a database or in a file. To view the history, the log format should be MSDE. Likewise, for firewall and Web proxy logging, you should use the MSDE database format. ISA Server already runs MSDE database, and therefore no extra effort is required. The SQL Server database format can be used for remote logging if your organization has a SQL server already running in its environment. Logging on ISA Server can be configured to log only the events that match certain parameters and log only certain fields of each event. For example, logging can be configured to log only the following: Events from a specific service Specific fields of each event Packets from allow packet filters or deny packet filters One of the events that many medium IT environment administrators find useful is logging end-user information. The only way to ensure accountability is to enable user authentication for Web access and log the event. In situations such as users accessing inappropriate content, these logs provide the necessary evidence. Configure the log to record user information, including client IP address and client user name as well as the Web site visited. By default, these settings are included in the firewall and Web proxy logging.

70 54 Microsoft Windows Server System Deployment Guide for Midsize Businesses Consider the following recommendations while implementing logging on ISA Server: Store logs on a partition other than that of the operating system to avoid the logs growing to fill the system partition and destabilizing the firewall server. If the performance requirements are high and the cost of additional disks is acceptable, use a separate RAID volume for the partition that stores the logs. Configure ISA Server to remove the old log files if the logs exceed a specified size limit. ISA Server checks the log file size every 10 minutes. The size of the log file depends on the level of detail (list of fields) logged for each event and the number of events logged. Therefore, only the necessary level of details and types of events should be logged. For simplicity, better performance, easy manageability, and cost effectiveness, log data to the MSDE database. Logging data to a file does not provide easy analysis of data and has performance issues when log size grows. Enable the file format for storing the SMTP message screener log, because it can be saved only in a file format. Even though compressing log files provides additional disk space, do not compress the log files, because this affects the performance of the firewall server. Maintain the backup of the log data for at least a few months so that the backup can be used for analysis, if required. Monitoring and Alerting It is important to configure monitoring and alerting for critical events that seriously affect the business of an organization. This book recommends configuring the monitoring and alerting of critical events, such as failure of one or more services running on the ISA Server, DoS attacks, SMTP command violation, network intrusion, and port scanning. Alerts should be configured to notify the IT staff through or Windows event logging, or to run specific commands to take appropriate actions, such as shutting down the firewall service when serious network intrusion is detected. In addition, ISA Server should be configured to monitor LAN connections of other servers and network devices in the IT environment, such as the primary infrastructure server, and to send alert notifications to the IT staff in case of problems. Reporting ISA Server can be configured to generate recurring reports on a daily, weekly, monthly, or yearly basis. Configuring ISA Server to report information about Web usage content, application usage content, traffic and utilization information, security content, and summary content can be beneficial. The business can publish these reports to an intranet Web site for employees and management to view.

71 Chapter 3: Installing and Configuring Firewalls 55 Note that, by default, reports are generated every day at 1:00 A.M. and are about the events that occurred on the previous day. You cannot generate reports for events that occurred on the same day. Firewall Client Computer Configuration Client computers that are located at the main office should either install the ISA Server 2004 Firewall Client application or be configured as a Web Proxy or a SecureNAT client. This section provides guidance on choosing the right type of client and planning the configuration of the clients. The firewall server acts as a gateway for computers at the main office. The clients should be configured to send requests intended for the Internet to the firewall server, and the firewall server then forwards these requests to the Internet on behalf of the client. When the firewall server receives the response from the Internet, it inspects the response to ensure that there are no hidden threats, and then forwards the response back to the client computer. The difference between the client types is the mechanism they use to communicate with ISA Server. Client Choices ISA Server supports the following three types of clients: ISA Server firewall clients: Client computers that have the Firewall Client application installed. Firewall Client passes the authentication credentials of the user who is logged onto the client computer to ISA Server. After successful authentication, ISA Server permits the user to access the Internet. Web proxy clients: Client computers that have a Web browser, such as Microsoft Internet Explorer, configured to forward Web requests to the internal interface of the firewall server, which runs the ISA Server Web proxy. Secure Network Address Translation (SecureNAT) clients: Client computers that have the IP address of the firewall server configured as their default gateway. SecureNAT does not require any configuration on the client computer other than setting the default gateway of the client computer to the IP address of the internal interface of the ISA Server. This task is usually performed automatically by using a DHCP server. (In a subnetted environment, ISA Server does not need to be the default gateway, but the default route needs to go through the ISA Server.)

72 56 Microsoft Windows Server System Deployment Guide for Midsize Businesses Table 3-3 presents the advantages and disadvantages of these client types. Table 3-3 ISA Server firewall clients Web proxy clients SecureNAT clients Firewall Client Choices Access control: Provides user-based or group-based access control and logging on the ISA Server. No manual configuration required: The Firewall Client software is capable of auto-configuring. Enables use of Winsock applications: Other client types do not enable running Winsock client applications, such as Telnet and FTP. Widely supported: All Web browsers and operating systems support Web proxy configuration and Web proxy clients. Access control: Provides user-based or group-based access control and logging. No additional software required: Does not require installing any software. No additional software required: Does not require installing any software. No additional configuration required: Only requires the default gateway to be set to the firewall server. Recommendations for Using Firewall Client Runs on Windows-based computers only: Can only be installed on Windows operating systems. No 16-bit support: Cannot be installed on computers running 16-bit operating systems. Limited support: It only supports TCP and UDP protocols. Client application required: Installing the software on the client computers is required. Limited support: Supports only HTTP, HTTPS, and HTTP-tunneled FTP access. It does not support any other protocols. No access control: Access control is unavailable. Administrators cannot monitor which users are accessing which Internet resources. To maximize access control and minimize client configuration install the Firewall Client application on all desktop and portable computers at the main office that require access to the Internet. All the servers in the environment should be configured as Web proxy clients. Note Although it is recommended not to install the Firewall Client application on servers, servers running Winsock applications might require the Firewall Client application to be installed for the Winsock applications to function properly. Branch office computers should be configured as SecureNAT clients. This only requires configuring the default gateway of the branch office client computers to the IP address of the

73 Chapter 3: Installing and Configuring Firewalls 57 internal interface branch office firewall. This configuration is done automatically by the DHCP server, which provides the client computers with the IP configuration. No additional configuration is required. Planning for the Configuration of the Client Computers The following sections discuss the choices you must make when planning the installation and configuration of the Firewall Client application. Application Share The Firewall Client application must be deployed on a share so that it can be accessed and installed on all client computers at the main office, either manually or by using Group Policy Objects (GPOs). The application share is created automatically on the firewall server during the installation of ISA Server. By default, the ISA Server setup creates a network share called mspclnt on the firewall server. If you are using DFS-based file shares, create a DFS link pointing to the mspclnt network share so that the share can be easily located by using DFS. For information on the network share structure and steps for creating the DFS link, refer to Chapter 7, Installing and Configuring File Sharing and Print Services. Installation Method Firewall Client can be installed on client computers by using either of the following two methods: Manual installation: Users need to manually install the ISA Server Firewall Client application by using the setup software available at the DFS path. This method has many disadvantages, including the following: Users need to have local administrator privileges on the client computer. Users might not install the Firewall Client, in which case, their activities on the Internet cannot be monitored. In addition, if they use Winsock applications, these applications will fail to work because Firewall Client is necessary for Winsock applications to function. Configuration errors might be made. Significant time and effort is required. Group Policy: This method automatically installs the software on the client computer and offers the following advantages: No administrator or user intervention is required. The Firewall Client application is uniformly and consistently installed on all firewall client computers. The workload of IT staff is reduced. The chances of making configuration errors are reduced.

74 58 Microsoft Windows Server System Deployment Guide for Midsize Businesses Although it is recommended not to install Firewall Client on the servers, if a server requires Firewall Client (for example, to run Winsock applications), it should only be installed manually. Configuration Method The Firewall Client application installed on the firewall client computers can be configured in the following two ways: Manual configuration: Users manually configure the firewall client computer to connect to the firewall server and get the configuration script. Automatic configuration: The Firewall Client application automatically detects the firewall server and receives the configuration script. The automatic configuration method because it is simple, saves time, and eliminates errors that might occur with manual configuration. By default, when Firewall Client is installed, it is configured to automatically detect ISA Server. To explicitly enable automatic detection of ISA Server on client computers that are already configured as DHCP clients, the DHCP server should be configured to pass ISA Server information to the DHCP clients. For this setup, a Web Proxy Auto-Discovery (WPAD) DHCP option should be created on the DHCP scope defined for the local network. This option contains information on the location of ISA Server and the automatic configuration script. The information in the WPAD DHCP option enables the client computer to automatically detect ISA Server. With the exception of the primary and secondary infrastructure servers and the ISA server, all other servers are configured as DHCP clients, and therefore they also should be able to take advantage of WPAD. Antivirus Software and Other Security Measures No specific guidance is given in this book about the need for antivirus software or the steps for installing and updating such software. However, it is vitally important that antivirus software be installed and maintained on all servers, clients, and hardware in the infrastructure. In addition, IT personnel should check periodically to ensure that the appropriate updates and hot-fixes have been applied to client and server operating systems and applications. This check can be easily accomplished by using the Microsoft Baseline Security Analyzer (MBSA). MBSA analyzes the operating system for servers, clients, IIS, Internet Explorer, SQL Server, Microsoft Office, and many other components to see if the configuration is secure and if the latest security updates and hot-fixes have been applied. The MBSA tool can be run remotely against a single client or server, or against a subnet of machines. Results can be stored to enable reporting, analysis, management, and remedial action if necessary. For more detailed information and guidance, see References at the end of this chapter.

75 Installation and Configuration Chapter 3: Installing and Configuring Firewalls 59 This section provides prescriptive guidance on securing Internet connectivity, such as: Installing and configuring ISA Server 2004 to provide secure connectivity to the main office and additional features, such as Web caching and publishing of internal resources to the Internet. Configuring the internal clients at the main office as firewall clients. Installing and configuring the branch office router and home office router to provide secure connectivity to the clients connected to their respective router. Installing Microsoft Windows Server 2003 or Windows 2000 Before ISA Server The following sections provide an overview of the steps for implementing secure Internet connectivity in the medium IT environment. Note While running wizards, if the build steps do not specify the values to be used, use the default values provided by the wizard. Gathering Information for Initial Configuration Before you start building the firewall server, gather the information that will be needed at various stages of the build process. The following information is required to configure network services: A static public IP address and the related network configuration information to configure the external network adapter of the firewall server. IP configuration details of the internal interface of the firewall server. An IP address of internal DNS servers. There should be at least two internal DNS servers running in the main office LAN. A DNS domain name. The DNS domain name should be the same as the publicly registered domain name; that is, BusinessName.com. An Active Directory domain name and domain administrative privileges to join the firewall server to the domain. A network IP address scheme of all locations. A fully qualified host name and IP addresses of internal servers that need to be published, such as SMTP server.

76 60 Microsoft Windows Server System Deployment Guide for Midsize Businesses Details of public and internal DNS names of all internal services that need to be published, such as and collaboration services. A list of services or protocols that need to be allowed to flow between the internal network and the Internet as per the business requirements. The host name of the Certificate Authority (CA). To configure the hardware and install the operating system on the firewall server 1. Connect the LAN interface of the firewall server to a separate, isolated network where other build servers, if any, are installed. Ensure that this network is not connected to any other network, including the Internet and the production network. Do not connect the other network adapter interface that is identified as an external interface. Note Do not connect the external interface of the firewall server to the Internet unless the Windows Server 2003 operating system, the ISA Server 2004 software, and the relevant updates are installed on the server hardware. 2. Install the Windows Server 2003 operating system, and complete the network configuration of the firewall server, including joining the server into the Active Directory domain by using the guidance provided in Initial Server Configuration. The following information will be required to complete the configuration: Server name: MOISA The IP configuration for the internal network adapter of the firewall server: IP configuration Static IP address Subnet mask Default gateway None DNS server IP addresses and WINS server IP address and The IP configuration for the external network adapter of the firewall server: IP configuration IP address Subnet mask Default gateway DNS server IP addresses WINS server IP address Static Provided by the ISP Provided by the ISP Provided by the ISP None None

77 Chapter 3: Installing and Configuring Firewalls Disable NetBIOS over TCP/IP (NetBT) on the external network adapter. To do this, open the Internet Protocol (TCP/IP) Properties page of the external network adapter. Click Advanced, click WINS, and then select the Disable NetBIOS over TCP/IP option. Disk configuration is as follows: Two hard disks configured in RAID 1 with a single NTFS partition. (Optional) If you want to have data partition that is separate from the system partition for Web caching, logging, and other purposes, then configure three additional hard disks in RAID 5 with a single NTFS partition. Note After joining the firewall server into the Active Directory domain, perform all the installation and configuration tasks on the server by logging in as a domain administrator. Installing and Backing Up ISA Server 2004 This section provides the steps for performing the following tasks: Installing the ISA Server 2004 software on the firewall server (MOISA). Backing up ISA Server configuration. To install ISA Server 2004 software 1. Insert the ISA Server 2004 software media CD into the CD drive, and then click Install ISA Server Read the release notes. 2. On the Setup Type page, select Custom. 3. On the Custom Setup page, click Firewall Client Installation Share, and then click This feature will be installed on local hard drive. 4. Configure the Internal Network by following these steps: a. Click Add on the Internal Network page. b. Click Select Network Adapter. c. Clear the Add the following private IP ranges check box. d. Select the Add address ranges based on the Windows Routing Table check box. e. Select the network adapter that is connected to the internal network. f. When the message The Internal network was defined, based on the Windows routing table appears, click OK in the Setup Message dialog box. g. Verify that the IP address ranges of the internal network are displayed correctly. 5. Complete the software installation. 6. Restart the server after the software installation is complete.

78 62 Microsoft Windows Server System Deployment Guide for Midsize Businesses Backing Up the ISA Server Configuration Before making any changes on MOISA, it is recommended that you back up the working configuration. This enables you to revert to the working state in case the changes do not work as expected. Similarly, it is recommended that you back up the configuration after all configuration changes have been carried out. To back up the current configuration of ISA Server 1. On the ISA Server Management console, right-click MOISA, and then click Backup. 2. Provide a meaningful name for the backup file (for example, a file name that contains the date and time) and the destination location where you want to save the backup file. 3. Use a strong password to protect the exported file. Make sure that you remember the password because data might later need to be restored from this file. Configuring ISA Server The following procedures provide an overview of the steps for configuring ISA Server as part of the network topology recommended in this book. Initial configuration of ISA Server involves configuring the firewall policy by using the Edge template. To define a firewall rule by using the Edge template 1. Open the ISA Server Management console. 2. Expand Configuration, click Networks, and then click the Edge Firewall in the Templates tab in the right pane. 3. On the Welcome to the Network Template Wizard page, click Next. 4. On the Internal Network IP Addresses page, verify that the server has the correct internal IP address ranges. 5. On the Select Firewall Policy page, select Allow limited Web Access and access to ISP network services and complete the setup. 6. Click the Apply button to save the changes on MOISA. Note Before starting the NTP configuration, back up the present working configuration of ISA Server by following the steps provided in the Backing Up the ISA Server Configuration section earlier in this chapter.

79 Chapter 3: Installing and Configuring Firewalls 63 To allow the domain controllers to synchronize time with the time.windows.com NTP server 1. In the ISA Server Management console, click Firewall Policy in the left pane, and then click Create New Access Rule in the right pane under the Tasks tab. 2. On the Welcome to the New Access Rule Wizard page, provide a name for the access rule; for example, Allow DCs to time-synchronize with external NTP server. Click Next. 3. On the Rule Action page, click Allow. 4. On the Protocols page, click Selected Protocols on the This rule applies to: dropdown menu. Then, perform the following steps: a. Click Add. b. On the Add Protocols page, expand All Protocols. c. Select NTP (UDP). d. Click Add, and then click Close. 5. On the Protocols page, click Next. 6. On the Access Rule Sources page, click Add. 7. On the Add Network Entities page, expand Computers. If the names of the domain controllers the primary and secondary infrastructure servers (MOCOR1 and MOCOR2) are not listed, perform the following steps to add them: a. Click New, and then click Computer. b. On the New Computer Rule Element page, click Browse. c. On the Find Internal IP Address page, click Browse. d. On the Select Computer page, enter MOCOR1 in the Enter the object name to select (examples): text box, and click Check Names. Click OK. e. On the Find Internal IP Address page, click Find, and then click OK. f. On the New Computer Rule Element page, click OK. g. Repeat steps 1 through 7 to include MOCOR2. 8. On the Add Network Entries page, select MOCOR1.BusinessName.com, which is displayed under Computers, and click Add. Repeat the same steps to add MOCOR2.BusinessName.com. 9. Click Close. 10. On the Access Rule Sources page, click Next. 11. On the Access Rule Destinations page, click Add. 12. On the Add Network Entries page, expand Networks, select External, click Add, and then click Close.

80 64 Microsoft Windows Server System Deployment Guide for Midsize Businesses 13. On the Access Rule Sources page, click Next. 14. Complete the setup. 15. In the ISA Server Management console, click the Apply button to save the changes on MOISA. To configure intrusion detection filters By default, intrusion detection is enabled in ISA Server, which can be verified by performing the following steps: 1. In the ISA Server Management console, expand Configuration, click General, and then click Enable Intrusion Detection and DNS Attack Detection. 2. On the Intrusion Detection page, ensure that intrusion detection is enabled on the Common Attacks tab. 3. On the Intrusion Detection page, click Cancel if no setting changes are required. 4. Click OK if you have modified any of the settings as per the recommendation. 5. In the ISA Server Management console, click the Apply button to save the changes on MOISA if you have modified the settings. It is recommended that you configure alert notification to detect attacks so that immediate action can be taken before the attack seriously affects the business. Configuring SMTP Filtering Note Before starting the SMTP configuration, back up the present working configuration of ISA Server by following the steps provided in the Backing Up the ISA Server Configuration section earlier in this chapter. By default, SMTP filtering is enabled on the SMTP publishing rule. If there is any new exploitation of the SMTP command that is not in the current list, it is recommended that you add that command immediately into the list to stop hackers from exploiting vulnerabilities in the network. To add a new SMTP command 1. In the ISA Server Management console, expand MOISA. 2. Expand Configuration, click Add-ins, and then click Application Filters in the center pane. 3. Double-click the SMTP Filter. On the SMTP Filter Properties page, select the Enable this filter check box.

81 Chapter 3: Installing and Configuring Firewalls Add the new SMTP command and its buffer overflow threshold values under the SMTP Commands tab. 5. On the SMTP Filter Properties page, click OK. 6. Click the Apply button to save the changes on MOISA. SMTP filtering can be configured to send alerts to the administrator or to send a report to the event log when an SMTP filtering rule is violated by the network traffic. Note For this feature to work, the service should be set up and running in the organization. In addition, ISA Server should be configured to allow the traffic across the firewall. To configure alerts 1. In the ISA Server Management console, expand MOISA. 2. Click Monitoring, and then in the center pane, click Alerts. 3. On the Tasks tab in the right pane, click Configure Alert Definitions. 4. On the Alerts Properties page, select the SMTP Filter Event check box under Alert Definitions. 5. Click the Edit button. 6. Configure the SMTP filter event properties according to the security requirements of your organization. 7. Click the Apply button to save the changes on MOISA. To configure Web caching Note Before starting the Web caching configuration, back up the present working configuration of ISA Server by following the steps provided in the Backing Up the ISA Server Configuration section earlier in this chapter. 1. In the ISA Server Management console, expand Configuration, click Cache, in the center pane, click Cache Rules, and then in Tasks in the right pane, click Define Cache Drives. 2. On the Define Cache Drives page, select the drive to be used for caching, set Maximum Cache Size (MB) to 4000, and then click Set. If you have a lot of free disk space, consider allotting more disk space for caching. 3. Click OK to save the changes. 4. Click the Apply button to save the changes on MOISA. Note that when you enable caching, it enables both forward and reverse caching.

82 66 Microsoft Windows Server System Deployment Guide for Midsize Businesses To configure cache settings 1. In the ISA Server Management console, expand Configuration, click Cache, in the center pane click Cache Rules, and then in Tasks in the right pane, click Configure Cache Settings. 2. On the Cache Settings page, click the Active Caching tab, and then select the Enable Active Caching check box. 3. On the Cache Settings page, click the Advanced tab, and then enter 20 in the text box next to Percentage of free memory to use for caching. Note If you find that the performance of the firewall server is degrading to low memory, reduce the number entered in the text box to free up memory for other processes. 4. Click the Apply button to save the changes on MOISA. To create a Web caching rule 1. In the ISA Server Management console, expand Configuration, click Cache, in the center pane, click Cache Rules, and then in Tasks, click Create a Cache Rule. 2. On the Welcome to the New Cache Rule Wizard page, provide a name for the cache rule (for example, Web caching for internal users), and then click Next. 3. On the Cache Rule Destination page, click Add, expand the Networks group, and then add External network object by using Add Network Entities. This enables Web caching of requests that are sent to the Internet by internal users. 4. On the Cache Rule Destination page, click Next. 5. On the Content Retrieval page, click Next. 6. On the Cache Content page, click Next. 7. On the Cache Advanced Configuration page, clear the Cache SSL responses check box. For security reasons, it is recommended not to cache SSL contents on the firewall server. If you have limited disk space for Web caching, consider enabling the Do not cache objects larger than option and setting the maximum size for objects that you want to allow for caching. 8. Click Next. 9. On the HTTP Caching page, click Next. 10. On the FTP Caching page, click Next. 11. On the Completing the New Cache Rule Wizard page, click Finish. 12. Click the Apply button to save the changes on MOISA.

83 Chapter 3: Installing and Configuring Firewalls 67 Publishing Internal Web Sites to the Internet Publishing internal Web sites securely to the Internet involves the following tasks: Installing a wildcard certificate on ISA Server. Configuring Web Listener by using the wildcard certificate for HTTPS access. Configuring Web Listener for HTTP access. Configuring ISA Server to publish the Exchange OWA site, extranet site, and TSWeb Web site for secure access. Note It is assumed that the internal CA is installed on the primary infrastructure server and is running. It is not a prerequisite for configuring ISA Server to have the OWA, extranet, and TSWeb Web sites set up and running. However, if you want to test secure access to these sites from the Internet, they should be set up and running in the environment. Before starting the Web publishing configuration, back up the present working configuration on ISA Server by following the steps provided in the Backing Up the ISA Server Configuration section earlier in this chapter. Publishing Internal Resources to the Internet ISA Server allows the publishing of various internal services so that they can be accessed by users on the Internet. ISA Server can be used for the following two types of publishing: Server publishing: This type involves publishing the Microsoft Exchange Server (SMTP) server. Web publishing: This type involves publishing Exchange Server OWA Web sites, Microsoft Windows SharePoint Services-based extranet Web sites, and TSWeb Web sites for accessing the terminal server. Note It is not a prerequisite to have the OWA, extranet, and TSWeb Web sites set up and running before publishing them. If you want to test secure access to these sites from the Internet, they should be set up and running in the environment. Server Publishing The Exchange server running in the environment is published to the Internet through the ISA Server. For guidance on publishing the Exchange server through ISA Server, refer to Chapter 4, Installing and Configuring Microsoft Exchange Server 2003.

84 68 Microsoft Windows Server System Deployment Guide for Midsize Businesses Web Publishing Most medium businesses prefer to host their public Web sites at an ISP site and leave the administrative responsibility of the site to the ISP. This method is cost-effective, and the organizations do not need to worry about maintaining their Web sites. However, to provide access from the Internet to internal Web sites, such as an Exchange OWA Web site, an extranet Web site, and a TSWeb Terminal Services Web site, the internal Web sites need to be published through the ISA Server. ISA Server 2004 supports end-to-end SSLbased connections between the remote client on the Internet and the server that hosts the Web site, and therefore the entire communication channel is secure. When the firewall server is used to publish internal Web sites using HTTPS, ISA Server 2004 installed on the firewall server accepts the SSL connection from the client, decrypts the traffic, checks for malicious content hidden inside the traffic, and, after it is verified that the traffic is safe, forwards the traffic to the internal Web server. This way, an exploit that is encrypted and hidden in the HTTPS traffic cannot enter the internal LAN undetected. Issuing an SSL Certificate While publishing internal Web sites, the recommended approach is to implement end-to-end SSL connection between the remote client computer on the Internet and the internal Web sites that are published. Establishing an end-to-end SSL connection requires two steps: First, establish an SSL connection between the remote client computer and the firewall server. Second, establish an SSL connection between the firewall server and the internal Web server. When creating these SSL connections, the firewall server and each of the internal Web sites being published must have an SSL certificate installed on them. In addition, the client computer on the Internet should have installed the root certificate of the Certificate Authority (CA) that issued the SSL certificate to the firewall server. The SSL certificates can be issued by the internal CA of the organization or can be bought from a commercial CA. Buying an SSL certificate for the firewall server is recommended because this simplifies the configuring of client computers. Most client computers already have a database of root certificates of all the well-established and reputed CAs installed on them. Therefore, if the firewall server uses an SSL certificate from a commercial CA, the client computers already have the root certificate of the commercial CA installed, and no additional configuration is required on the client computer. SSL certificates issued by an internal CA are recommended for the internal Web Sites because only the firewall server establishes SSL connections with these Web sites. Therefore, the root certificate of the internal CA needs to be installed only on the firewall server.

85 Chapter 3: Installing and Configuring Firewalls 69 Configuring Wildcard Certificates and Publishing Multiple Secure Web Sites For publishing the various internal Web sites, such as a SharePoint site, an OWA site, and a terminal server TSWeb Web site, the most secure method is to use SSL certificates. This method of publishing enables Internet clients to use the HTTPS protocol to access these sites securely. The Web listener configured on the external interface of the firewall server listens for HTTPS requests from clients on the Internet and forwards the requests to the internal Web site after validating the request. The following two situations might exist: Multiple public IP addresses configured on the external interface of the firewall server: In this case, each internal Web site can have its own Web listener that is bound to a dedicated public IP address. Further, each Web listener can have its own SSL certificate that has its own common name. For example, the SharePoint site can have an SSL certificate with extranet.businessname.com as its common name, and the OWA site can have its own SSL certificate with mail.businessname.com as its common name. Only one public IP address configured on the external interface of the firewall server: In this case, ISA Server does not allow you to configure separate Web listeners for each Web site. Therefore, only one listener has to be configured for all HTTPS Web sites that need to be published. The problem, however, is that each internal Web site requires its own SSL certificate, and you cannot assign multiple SSL certificates to a single Web listener. A Web listener can have only one SSL certificate. The only workaround to this problem is configuring the Web listener with a wildcard certificate. The common name of a wildcard certificate has an asterisk (*) in place of the hostname; for example *.BusinessName.com. Web listeners configured with a wildcard certificate do not check the hostname portion specified in the HTTPS request and forward the requests to the internal Web site as long as the domain name is correct. For example, the Web listener does not consider the extranet or mail portion of the extranet.businessname.com and mail. BusinessName.com URLs, respectively. It checks only the BusinessName.com domain name. ISA Server uses other means to decide to which Internal Web server the request should be forwarded. In the topology recommended by this book, only a single public IP address is used and multiple HTTPS Web sites need to be published. Therefore, a wildcard certificate must be configured for the Web listener on the ISA Server. OWA and TSWeb URL Usability When the Exchange OWA site is published to the Internet with the default Web site configuration, the Internet user is required to enter as the URL in the Web browser. This method leads to several usability issues.

86 70 Microsoft Windows Server System Deployment Guide for Midsize Businesses The user must include in the URL. By default browsers append so if the user enters only mail.businessname.com/exchange, the browser attempts to open mail.businessname.com/exchange and fails. The user must append /exchange to the URL, which is cumbersome. To improve usability, the OWA site and ISA Server can be configured to automatically redirect the or mail.businessname.com URLs to Name.com/exchange. Similar configuration is recommended for the TSWeb Web site running on the terminal server, so that the URLs and remote.businessname.com are redirected to Setting up and configuring Microsoft Terminal Services and the TSWeb Web site is discussed in Configuring ISA Server to Publish the Exchange OWA Site, Extranet Site, and TSWeb Web Site later in this chapter. Installing a Wildcard Certificate on ISA Server Installing a wildcard certificate on ISA Server involves the following tasks: Configuring ISA Server to allow access to the Web enrollment Web site running on the primary infrastructure server. Installing the wildcard certificate. The following procedures provide the steps for performing the tasks. To configure ISA Server to allow access to the Web Enrollment Web site 1. In the ISA Server Management console, click Firewall Policy, and then in Tasks in the right pane, click the Create New Access Rule link. 2. On the wizard s Welcome page, provide a meaningful name for the firewall rule; for example, Allow access from ISA Server to the internal certificate server. 3. On the Rule Action page, select Allow. 4. On the Access Rule Sources page, add the ISA Server computer name. 5. On the Access Rule Destinations page, add the computer name of the internal certificate server, which is the primary infrastructure server (MOCOR1). 6. Complete the setup. 7. Click Apply in the ISA Server Management console to save the changes. To install the wildcard certificate 1. On the firewall server, open Internet Explorer, and then type /certsrv. 2. Log on to the server as domain administrator.

87 3. On the Welcome page, click the Request a Certificate link. Chapter 3: Installing and Configuring Firewalls On the Request a Certificate page, click the advanced certificate request link. 5. On the Advanced Certificate Request page, click the Create and submit a request to this CA link. 6. On the Advanced Certificate Request page, perform the following tasks: a. Click Web Server in the Certificate Template drop-down menu. b. Provide the following information under the Identifying Information For Offline Template: Name Company Department City State Country/Region *.BusinessName.com [email protected] BusinessName.com BusinessName.com Redmond Washington US c. Under Key Options, select the Store certificate in the local computer certificate store check box. d. Under Additional Options, in the Friendly Name: text box, provide a friendly name; for example, Wildcard Certificate. e. Click the Submit button. 7. In the Potential Scripting Violation pop-up message box, click Yes. 8. On the Certificate Issued page, click the Install this certificate link. 9. In the Potential Scripting Violation pop-up message box, click Yes. 10. On the Certificate Installed page, make sure that the system displays a message that says that the certificate has been installed successfully. To configuring Web Listener by using the wildcard certificate for HTTPS access 1. In the ISA Server Management console, click Firewall Policy, and then in the right pane of the console, click the Toolbox link. 2. Under ToolBox in the right pane, click Network Objects. 3. Right-click Web Listeners, and then click New Web Listener. 4. On the Welcome to the New Web Listener Wizard page, provide a meaningful name to the Web listener; for example, Web Listener using wildcard certificate for Publishing HTTPS Sites. 5. On the IP Addresses page, select External, and then click Next.

88 72 Microsoft Windows Server System Deployment Guide for Midsize Businesses 6. On the Port Specification page, clear Enable HTTP, and then select Enable SSL. Ensure that the SSL port is set to 443. Click Select. 7. On the Select Certificate page, highlight the wildcard certificate (*.BusinessName.com) that you previously installed on the local computer certificate store of the firewall server, click OK, and then finish the setup. 8. In the ISA Server Management console, click Apply to save the changes. To configure Web Listener for HTTP access 1. In the ISA Server Management console, click Firewall Policy, and then in the right pane of the console, click the Toolbox link. 2. In the right pane under ToolBox, click Network Objects. 3. Right-click Web Listeners, and then click New Web Listener. 4. On the Welcome to the New Web Listener Wizard page, provide a meaningful name to the Web listener; for example, Web Listener for Publishing HTTP Sites. 5. On the IP Addresses page, select External, and then finish the setup. 6. In the ISA Server Management console, click Apply to save the changes. Configuring ISA Server to Publish the Exchange OWA Site, Extranet Site, and TSWeb Web Site For secure access, ISA Server can be used to publish the following Web sites to the Internet: Exchange OWA site: An Exchange OWA site is published to the Internet as part of the implementation of messaging services. For steps for publishing the OWA site through ISA Server, refer to Chapter 4, Installing and Configuring Microsoft Exchange Server Extranet site: A Windows SharePoint Services based extranet site is published to the Internet as part of the implementation of collaboration services. Terminal server TSWeb Web site A terminal server TSWeb Web site is published to the Internet as part of the implementation of remote access services. For steps for publishing the terminal server TSWeb Web site through ISA Server, refer to Chapter 10, Enabling Remote User Access. Configuring Firewall Client This section includes the tasks related to configuring Firewall Client. To automate Firewall Client configuration 1. In the ISA Server Management console, expand MOISA.

89 Chapter 3: Installing and Configuring Firewalls Expand Configuration, click Networks, and then under Networks in the center pane, select Internal; for example, Internal with IP Address ranges ; Double-click Internal, and then define values on the Internal Properties page as follows: The Domains tab: Include the internal domain name; for example, *.Business- Name.com. The Auto Discovery tab: Select Publish automatic discovery information. 4. On the Internal Properties page, click OK. 5. Click the Apply button to save the changes on MOISA. To enable automatic discovery by Firewall Client, the WPAD server option needs to be defined. Perform the following steps on both the DHCP servers: 1. Open the DHCP management console. 2. Right-click the DHCP server name, and then click Set Predefined Options. 3. Click Add, and then in the Option Type dialog box, set the following values. Name WPAD Data Type String Code Click OK. 5. In the Predefined Options and Values page, type the following string value: of ISA_Server_Name:Auto_Discovery_Port/wpad.dat For example, 6. On the Predefined Options and Values page, click OK. 7. Right-click Server Options, and then click Configure Options. 8. On the Server Options page, on the General tab, select the 252 WPAD option, and then click OK. Configuring Internet Explorer After Web proxy configuration in ISA Server is performed, the Internet Explorer running on various systems in the internal IT environment should be set up as described in the following sections.

90 74 Microsoft Windows Server System Deployment Guide for Midsize Businesses Primary and Secondary Infrastructure Server Because these servers are configured with static IP addresses, Internet Explorer should be configured by following these steps: 1. In Internet Explorer, click Tools, and then click Internet Options. 2. On the Internet Options page, click the Connections tab, and then click the LAN settings button. 3. On the Local Area Network (LAN) Settings page, perform the following steps under Automatic configuration: a. Clear the Automatically Detect Settings check box. b. Select the Use Automatic Configuration Script check box. c. Type the following URL in the Address text box. of ISA Server:8080/array.dll?Get.Routing.Script For example, 4. Save the changes. Remaining Servers and Clients Because other systems are configured as DHCP clients, they should be able to get the Web proxy configuration script automatically by using WPAD configuration. To enable the Automatically Detect Settings option in Internet Explorer 1. In Internet Explorer, click Tools, and then click Internet Options. 2. On the Internet Options page, click the Connections tab, and then click the LAN settings button. 3. On the Local Area Network (LAN) Settings page, under Automatic configuration, select the Automatically Detect Settings check box. The easiest method to deploy this configuration for DHCP clients is via Group Policy. Installing Firewall Client Software This book recommends using GPOs to install the Firewall Client software on client computers that are located in the main office LAN. When you implement advanced Active Directory directory services as recommended in this book, the GPOs are configured to install Firewall Client on the internal client computers.

91 Chapter 3: Installing and Configuring Firewalls 75 Note The client computers might need to be restarted to enable the Group Policy to install the Firewall Client software on them. They should already be configured to be a part of the Active Directory domain. Perform the steps in this section to manually install Firewall Client only in the following cases: If you are not planning to implement the advanced Active Directory directory service guidance for deploying the Firewall Client using group policy. If you are installing Firewall Client on a server. To install the Firewall Client software manually 1. Log on as a domain administrator on the server on which the Firewall Client software needs to be installed. 2. Access the share (default share name mspclnt) on MOISA, and run the setup. 3. Use the default values, and then complete the installation. Configuring the Firewall Client Software Firewall Client should be configured on the following internal clients: Desktop and portable computers: Automatic configuration of firewall clients is easiest for DHCP clients on the main office LAN. For guidance on configuring the Firewall Client software on client computers such as desktops and portable computers in the network, refer to Chapter 9, Managing Desktops by Using Group Policy. Internal servers: If a server that has Firewall Client installed is a DHCP client (the server IP address is reserved on the DHCP server), the server should be able to detect the ISA Server based firewall server automatically once the Firewall Client software is enabled by using the WPAD protocol. Enable the firewall client software on the server by rightclicking the Firewall Client icon on the task bar and then clicking the Enable option. The server should then be able to detect ISA Server automatically. If the server is configured with a static IP address (for example, the primary infrastructure server, MOCOR1), after installation, the Firewall Client software should be configured manually to detect ISA Server by performing the following steps: 1. Right-click the Firewall Client icon on the taskbar, and then click Configure. 2. On the General tab, select the Enable Microsoft Firewall Client for ISA Server 2004 check box. 3. Select the Manually select ISA Server option, and then type the name of the firewall server (MOISA.BusinessName.com) in the text box, if required.

92 76 Microsoft Windows Server System Deployment Guide for Midsize Businesses 4. Click the Test Server button to ensure that the client computer is able to detect ISA Server. 5. Click OK to save the changes. Configuring Logging, Monitoring, and Reporting This section provides guidance on configuring logging, monitoring, and reporting features on ISA Server. Logging By default, the internal client information, such as client IP address, client user name, external URL accessed, and network ports used during Internet access, is included in the firewall and Web proxy logging. To ensure that these settings are enabled, verify the firewall and Web proxy logging configuration as follows: 1. In the ISA Server Management console, click Monitoring, click Logging, and then in Tasks in the right pane, click Configure Firewall Logging. 2. Click Fields on the Firewall Logging Properties page, and verify that Client IP and Port and Client Username are selected. 3. In Tasks in the right pane, click Configure Web Proxy Logging. 4. On the Web Proxy Logging Properties page, click Fields, and ensure that Client IP, Client Username, and URL are selected. After these settings are verified, the outgoing Web access rule should be modified to allow access only to the internal domain users. Perform the following steps: 1. In the ISA Server Management console, click the Firewall policy. 2. Double-click the Web access rule. (If Edge Template is used for firewall configuration, the name of the access rule is Web Access Only.) 3. On the Access Rule Properties page, click the Users tab, and then perform the following tasks to include the internal domain users: a. Select All Users, and then click Remove. b. Click Add. c. On the Add Users page, click New. d. On the Welcome page, provide a meaningful name to the user set; for example, Lucerne Internal Domain Users. e. On the Users page, click Add, and then click Windows users and groups. f. On the Select Users or Groups page, click Locations.

93 Chapter 3: Installing and Configuring Firewalls 77 g. On the Locations page, click Entire Directory, and then click OK. h. On the Select Users or Groups page, type Domain Users in the text box below Enter the object names to select (examples). i. Click OK. j. On the Users page, click Next, and then finish the setup. k. On the Add Users page, select Domain Users. l. Click Add, and then click Close. m. On the Access Rule Properties page, click OK. 4. Click the Apply button to save the changes on MOISA. When you configure logging as just described, Windows Update using Internet Explorer does not work with the authenticated domain user access enabled on ISA Server for outgoing HTTP or HTTPS connections. Therefore, you need to define a separate Web access policy to allow the internal systems at the main office to run the Windows updates successfully. This policy rule should be configured to allow unauthenticated Web access to the Web sites that are related to Windows Update only. ISA Server has a default Domain Name Set that includes these Web sites, which you can make use of for the configuration. Perform the following tasks on the firewall server: 1. In the ISA Server Management console, click the Firewall policy. 2. In the center pane, select the Web access rule that allows the outgoing HTTP and HTTPS connection that was defined earlier. If you have used the Edge template to define the access rule, the rule name should be Web Access Only. 3. Right-click the rule, and then click Copy. Right-click the same rule again, and then click Paste. This action should create a new rule named Web Access Only (1), above the original rule. 4. Double-click the new rule, Web Access Only (1). 5. On the Access Rule Properties page, on the General tab, clear the existing name, and enter a new name for the rule in the Name: text box; for example, Allow Windows Update. 6. Click the To tab. Under This rule applies to traffic sent to these destinations, select External, click Remove, and then click Add. 7. On the Add Network Entities page, expand Domain Name Sets, and then click System Policy Allowed Sites. 8. Click Add, and then click Close.

94 78 Microsoft Windows Server System Deployment Guide for Midsize Businesses 9. Click the Users tab. Under This rule applies to requests from the following user sets, select Domain Users, and then click Remove. 10. Click Add. On the Add Users page, select All Users, click Add, and then click Close. 11. On the Access Rule Properties page, click OK. 12. Click the Apply button to save the changes on MOISA. Monitoring and Alerting ISA Server can be configured to monitor various services running on it as well as other servers in the IT infrastructure. In addition, alerting can be configured so that alert notification can be sent out to the IT staff in case of problems; for example, when a critical service is down. As an example, the following steps show how ISA Server connectivity verifier can be configured to monitor MOCOR1 and send an alert notification to the administrator if the LAN connection of the primary infrastructure server fails. To configure connection verifier to monitor the primary infrastructure server 1. In the ISA Server Management console, click Monitoring, click Connectivity in the center pane, and then in Tasks in the right pane, click Create New Connectivity Verifier. 2. Provide a meaningful name on the Welcome page; for example, Primary Infrastructure Server Connectivity Verifier. 3. On the Connectivity Verification Details page, perform the following tasks: a. Provide the name of the primary infrastructure server; for example, MOCOR1. BusinessName.com. b. In the Group type used to categorize this connectivity verifier drop-down menu, click Others. c. In Verification method, click Send a Ping request. 4. Complete the configuration. 5. Click the Apply button to save the changes on MOISA. To configure alert notification 1. In the ISA Server Management console, click Monitoring, click Alerts, and then click Configure Alert Definitions. 2. On the Alert Properties page, under Alert Definitions, select No connectivity, and then click Edit. On the No connectivity Properties page, click the Actions tab. 3. Select the Send check box, and then configure the appropriate settings.

95 Chapter 3: Installing and Configuring Firewalls 79 Note that to make this configuration work, you should be running the service inside the network; for example: SMTP Server: MOCOR2.BusinessName.com From: From_ISA_Server To: 4. Complete the configuration. 5. Click the Apply button to save the changes on MOISA. Reporting The following steps show how to configure a recurring summary report on a daily basis on the ISA server to obtain an Internet usage report of the main office: 1. In the ISA Server Management console, click Monitoring, click Reports in the center pane, and then in Tasks in the right pane, click Create and Configure Report Jobs. 2. On the Report Jobs Properties page, click Add. 3. Provide a meaningful name for the report on the Welcome page; for example, Business- Name.com IT Network Usage Summary Report. 4. On the Report Content page, select the Summary check box, and then clear the other check boxes. If you need a more detailed report, select other options accordingly. 5. On the Report Job Schedule page, under Run this report job, select Daily. If you need weekly or monthly-based reports, select the appropriate option. 6. On the Report Publishing page, select Publish reports to a directory. 7. Create a directory on MOISA, and provide its path in the Published reports directory text box; for example, C:\ISARpt-Published. If you have hard disk space limitation on MOISA, consider storing the reports on the file server running in the environment. 8. Select Publish using this account. 9. Click Set account, and provide a user account name and password that is going to be used for publishing. For simplicity, the domain administrator account can be used. If you want to use a different account, ensure that the account has Write permission on the directory. 10. Complete the configuration. Note ISA Server is set to generate reports at 1:00 A.M. every day. Therefore, the report configured using the steps in this section cannot be viewed until 1:00 A.M. the next day.

96 80 Microsoft Windows Server System Deployment Guide for Midsize Businesses Deploying the Firewall Server After the ISA Server related configuration is complete, it is important to ensure that the firewall server is highly secure before moving it to the production network from the private network. The following actions are required to ensure that the server is secured properly: 1. Ensure that all of the latest Windows Server 2003 operating system updates are installed from Windows Update. 2. Install suitable antivirus software on the server, and ensure that it is up to date with the latest virus signature files. 3. Run the MBSA tool (from the primary infrastructure server on which it is installed, against the firewall server. Take appropriate action based on the result. 4. It is recommended that you download a reliable port scanning freeware tool from the Internet to a desktop or portable computer, and then run the tool against the external interface of the firewall server to ensure that all unwanted network service ports are closed. Moving to the Production Network After validation that the firewall server is secured properly, the server can be moved to the production environment along with other servers that were built in the private network. The process of moving the server from initial state environment to end state environment might take several hours depending on the number of additional services that need to be implemented on the firewall server and the number of problems that are encountered during the process. If the organization currently has an existing security service set up and running in a 24x7 environment and it cannot accept a long downtime, it is recommended that you do not disturb the existing security services setup. Instead, plan to deploy the new service during the weekend. Main Office Remove the existing Internet connection to the current firewall and VPN device, and connect to the external network adapter of the firewall server. For successful operation, it is recommended that you do not completely remove the existing firewall and VPN device (for example, do not disconnect and physically remove the existing firewall from the rack and related wiring) until the new setup is established and verified. After thorough verification that all the services are working as expected with the new ISA Server implementation, the old firewall and VPN device can be disconnected completely. During the deployment, the Firewall Client software might need to be installed and configured on the internal client computers, such as desktops and portable computers of the users as recommended by this book.

97 Chapter 3: Installing and Configuring Firewalls 81 Testing Services It is very important to test the configuration of the firewall server and the branch office devices to ensure that all services are working as expected. For testing various security services, it is recommended that you create two or more domain test users on the domain controller. Main Office From the internal network, try to access any publicly available HTTP-based and HTTPS-based Web sites by using Internet Explorer, and ensure that you are able to view the sites. By using the logging feature of ISA Server, you can monitor the connection of the internal clients who are accessing the Internet. Perform the following steps: 1. In the ISA Server Management console, click the Monitoring node, click the Details pane, and then click the Logging tab. 2. On the Logging tab, click the Start Query link, and look for the HTTP and HTTPS traffic that you want to monitor. As a test user from the firewall client system, browse a public Web site. On ISA Server, use the log viewer and ensure that the client name of the user, client IP address, and the URL of the public Web site that is being viewed are reported. Log on as administrator to the primary infrastructure server, and disable the active LAN interface. Make sure that an notification is sent to the configured account. Before disabling the LAN interface of the primary infrastructure server, it is important to ensure that no one is accessing the network. In addition, it is important to understand the risk involved in disabling the network adapter on the domain controller on a live network. To test reporting 1. In the ISA Server Management console, click Monitoring. 2. Click Reports, and then in Tasks, click Create and Configure Report Jobs. 3. Select the report that was previously created, and then click Run Now. 4. Verify that the published directory contains the summary report. Backing Up the System and Verifying the Backup Before releasing the system to users, it is strongly recommended that you perform a full backup of the entire system, including the state information of the operating system and configuration of ISA Server. In addition, it is important to test the backup to ensure that it does not have any problems. For example, try to restore a single file or folder from the tape to a test folder on the firewall server.

98 82 Microsoft Windows Server System Deployment Guide for Midsize Businesses Releasing the System to Users After the testing and backing up of the firewall server is complete and the configuration of the firewall and VPN router at the branch office is recorded, the system can be released to users for regular use. It might be necessary for the administrator to carry out the client-side configurations on the internal systems, such as installing the Firewall Client software. Managing the Firewall Server This section describes the process and tools available for managing the firewall server in the production environment on a day-to-day basis. Some of the management tasks include: Remote management. Update management. Data backup and restore. Monitoring and alerting. Remote Management The IT infrastructure sometimes needs to be managed remotely; for example, by in-house IT staff from home during off-business hours or by service providers from their offices. Some of the tasks that need to be managed remotely are: Troubleshooting problems due to failure of one or more services running on the firewall server or due to software or server hardware failure. Accessing firewall logs for troubleshooting based on an alert received during offhours. Managing firewall rules based on business requirements, such as defining a new firewall rule remotely to deny traffic originating from a computer on the Internet that performed unauthorized port scanning on the firewall server. Installing critical software updates. Note To provide access to the firewall server from a remote place for performing various management tasks, the firewall server should be configured as specified in Table 3-2. Update Management It is very important to keep the Windows Server 2003 operating system and the ISA Server 2004 software up to date with the latest service packs, critical updates, security patches, and other fixes. If the organization has an internal patch management infrastructure

99 Chapter 3: Installing and Configuring Firewalls 83 such as Windows Server Update Services (WSUS) as recommended by Patch Management With WSUS, the server should be configured to take advantage of that infrastructure. Otherwise, the server should be configured to automatically obtain the Windows Server 2003 operating system updates from the Internet. Data Backup and Restoration It is recommended that you back up the firewall server whenever there is a change in the ISA Server configuration, such as defining a new access rule; a change in software, such as installing operating system updates or ISA Server updates; or a change in the hardware configuration, such as installing an SSL card. In addition, it is recommended that you perform a full backup of the system volume, which holds the operating system, ISA Server software, and firewall logs. If the firewall logs are stored on a separate volume, that volume also needs to be backed up regularly, based on business requirements. It is also recommended that you back up data to tapes and store them at an off-site storage location so that data can be recovered even in the case of a disaster. Monitoring and Alerting ISA Server includes various tools and services that can be used to monitor and manage the server. The IT staff should monitor ISA Server by using these tools regularly and should take proactive actions. Some of the critical tasks are: Monitoring internal users network activity on the Internet. Monitoring inappropriate access attempts by Internet attackers, including port scanning. Performance monitoring of ISA Server. Viewing event logs for critical software and hardware errors and warnings. Analyzing the log database on a regular basis and, if possible, on a daily basis. ISA Server provides some monitoring and alerting tools that can be accessed by clicking Monitoring in the ISA Server Management console. These include: Services: To verify the status of all services related to ISA Server. Alerts: To view the alerts generated by the system. Sessions: To view all sessions by defining suitable filters, including VPN clients. Reports: To generate reports on various parameters like protocols, users, Web sites, and traffic. Logging: To configure and view ISA Server logging.

100 84 Microsoft Windows Server System Deployment Guide for Midsize Businesses Other tasks include: Troubleshooting Firewall Client software issues on user desktop computers. Installing Firewall Client software updates on user desktops. Monitoring disk space on the firewall server to ensure that firewall logs and other system logs do not fill up the system volume. Keeping the antivirus software and virus signature files installed on the firewall server up to date. References The following is a list of useful resources that will help you configure the advanced options of the ISA Server 2004 firewall: For information on how to deploy Microsoft Outlook Web Access in Exchange Server 2003, refer to the Exchange Server 2003 Deployment Guide, available for download at go.microsoft.com/fwlink/?linkid= For a product overview of ISA Server 2004, go to /evaluation/overview/default.asp. For information on upgrading ISA Server 2000, Standard Edition computers to ISA Server 2004, go to The ISA Server 2004 Help File The first place to look for help is the ISA Server 2004 Help File. The Help file contains a wealth of information about almost every component and feature included with ISA Server 2004 firewalls. Check the Help File first to see if it has the information you need. The Microsoft ISA Server 2004 Web Site The Microsoft official ISA Server 2004 Web site is located at Visit this site regularly for information about ISA Server 2004 and new documents that help make it even easier to set up and maintain your ISA Server 2004 firewall. The Microsoft ISA Server 2004 Newsgroups You can go to the Microsoft discussion groups to ask questions or read about the experiences of other ISA Server 2004 firewall owners. There are a number of people on these groups who help ISA Server 2004 firewall owners, and some of them are Microsoft Most Valuable Professionals (MVPs). This is a designation awarded to IT professionals who are ISA Server 2004 firewall experts. Visit the Official Microsoft discussion groups at /community/newsgroups/default.asp.

101 Chapter 3: Installing and Configuring Firewalls 85 The ISAserver.org Web Site The ISAServer.org Web site is an independent site dedicated to the ISA Server firewall community. The ISAServer.org site has hundreds of articles on ISA Server firewall configuration, maintenance, and management. The discussion boards on the site are very active and some of the foremost ISA Server firewall experts in the world are regular attendees of this highly interactive site. Visit the site at Security and Antivirus References For the most up-to-date security and virus information, visit the following Web sites: The Microsoft Trustworthy Computing: Security Web site at /security/default.mspx. The MBSA whitepaper at The Medium Business Guide for Antivirus at /details.aspx?familyid=82fcf08c-be7a-4caf-bb51-e8f20bf7f067&displaylang=en.

102

103 Chapter 4 Installing and Configuring Microsoft Exchange Server 2003 This chapter provides information on designing and implementing Microsoft Exchange Server 2003 to offer advanced messaging capabilities. The chapter also includes a description of the software installation and configuration recommended for a medium-sized business messaging service, and the processes and procedures to deploy, manage, and maintain such a service. Messaging Services Deployment Design Messaging services can be implemented in several ways, depending on the size and requirements of each environment. These services can be implemented on independent servers or as additional services on another server, such as the secondary infrastructure server, MOCOR2, especially in smaller IT environments. Deployment Choices Consider the following deployment designs: Secondary infrastructure server: The messaging service is deployed on the secondary infrastructure server. This option of installing Exchange on the secondary infrastructure server is appropriate for businesses where a heavy load is not anticipated on the messaging server during normal use, and where a messaging service is not critical to the business. Single stand-alone server: A single stand-alone server is used for deploying the messaging services. It is better suited for organizations with higher usage and reliance on messaging services. Dedicated server using a network-attached storage device: A dedicated server that uses a Microsoft Windows-powered network-attached storage device to store the messaging databases is ideal for larger organizations with high security requirements and a large messaging database. 87

104 88 Microsoft Windows Server System Deployment Guide for Midsize Businesses Table 4-1 presents the advantages and disadvantages of these choices. Table 4-1 Recommendations Messaging Services Deployment Choices Choice Advantages Disadvantages Secondary infrastructure server Single standalone server Dedicated server using networkattached storage device Cost: Inexpensive because the messaging services are hosted on the secondary infrastructure. Deployment and management costs are also low. Easy to deploy: This configuration is easy to deploy. Increased security: The messaging server is no longer on a domain controller. Therefore, external users do not directly access a domain controller, which is the case while using OWA, when the Exchange server is on the secondary infrastructure server. Slightly better performance: Performance is better because the hardware is dedicated to providing messaging services. Cost: Avoids the cost of directattached storage (DAS) of the messaging database. Storage: Gains the benefits offered by network-attached storage. Less reliable: If the server fails, there is an inevitable downtime. Less secure: This configuration increases security risk because of all the services run under the Local System account. Cost: The software costs involved are only slightly higher, but the hardware costs are more because an additional server is required. Cost: Might require a separate network to or from the network-attached storage device. Supports only WHQL-certified blockmode storage devices. For many medium-sized businesses, it is advantageous to run Exchange Server on your secondary infrastructure server, which achieves a balance of performance and cost when dedicated server hardware is not available. When implementing this solution, it is important to be aware of and consider all the implications of installing Exchange Server 2003 on a domain controller, including the following special points: This configuration increases security risk because all the services run under the Local- System account. If an exploit is discovered, in Active Directory directory services or Exchange Server, it could potentially be used to compromise the other services. The server will take much longer than normal to shut down. This book recommends Microsoft Windows Server 2003, Standard Edition as the operating system for the messaging server. The messaging server also requires Microsoft IIS 6.0, which

105 Chapter 4: Installing and Configuring Microsoft Exchange Server is one of the components of Windows Server The messaging server uses Exchange Server 2003 to provide and calendar services for users. The Web features of Exchange Server 2003 allow easy access to from many devices and locations. Upgrading from Exchange Server 5.5 When a Microsoft Windows NT 4.0 domain contains Exchange Server 5.5, you can use an Exchange Server 2003 standard deployment, given certain prerequisites. If your organization meets the following requirements, you can accelerate your upgrade by following the standard deployment method: The majority of user accounts and computers are members of a single Windows NT 4.0 domain. The organization has a single Microsoft Exchange Server 5.5 organization (multiple sites are okay). The organization plans to upgrade to a single Active Directory forest. The standard deployment method, as shown in Figure 4-1, includes: An in-place upgrade of Windows NT 4.0 domains to Windows Server 2003 Active Directory directory service domains. An upgrade from Exchange Server 5.5 to Exchange Server A migration of your mailboxes and public folders to Exchange Server Pre-upgrade Organization Upgrade/Implementation Organization Post-upgrade Organization Windows NT 4.0 Windows Server Upgrade to Windows Server 2003 Windows Server 2003 Exchange Server 5.5 Exchange Server 5.5 Active Directory Connector Exchange Server 2003 Exchange Server Install Active Directory Connector Install Exchange 3 Server 2003 on new hardware Move mailboxes 4 and public folders to Exchange Server 2003 Exchange Server 2003 Exchange Server Remove both servers running Exchange Server 5.5 Figure 4-1 Overview of the Exchange Server standard deployment method

106 90 Microsoft Windows Server System Deployment Guide for Midsize Businesses Because the scenario used in this book assumes migration from at most one Windows NT 4.0 domain, and also recommends an in-place upgrade of the existing domain, upgrade guidance for Exchange Server is provided in Building/Upgrading Exchange Server 5.5 later in this chapter. Should your IT infrastructure be moving from an infrastructure where you will not be migrating, omit the migration steps, and follow the guidance for building a messaging infrastructure beginning in System-Wide Requirements for Exchange Server 2003 later in this chapter. Hardware Recommendations In this book, the secondary infrastructure server is used for hosting the messaging services. In addition to the recommendations presented in that chapter, it is important to consider additional relevant factors when installing the messaging services on the secondary infrastructure server. Specifically, choosing among the following items when choosing the hardware is critical: Random Access Memory (RAM): Exchange Server makes use of as much RAM as is available on a server. As a result, the more RAM that a messaging server has, the better the performance of Exchange. Make sure to increase the recommended amount of 1 GB of RAM if you anticipate a large number of users or heavy usage of the messaging services. Processor: The hardware recommendations for a processor on the messaging server closely resemble recommendations for RAM. As with RAM, if you anticipate heavy usage of messaging services, purchase more processing capability for the server. Processing capability can be increased by adding additional processors, by purchasing processors with higher clock speeds, or by purchasing a higher capacity processor, such as a Xeon processor instead of a Pentium processor. Disk space: This book recommends configuring the server with a RAID 1 array for the operating system, and a separate RAID 5 array for data storage. When installing the messaging services on the secondary infrastructure server, ensure the RAID 5 partition has enough capacity to accommodate the Exchange Server software in addition to the messaging databases. Building/Upgrading Exchange Server 5.5 The majority of upgrades from Windows NT 4.0 and Exchange Server 5.5 to Windows Server 2003 Active Directory directory services and Exchange Server 2003 can be accomplished by using the standard deployment method. Companies with more complex enterprise environments might find that the standard deployment method is not an appropriate choice and will need to consider other upgrade methods. To determine if your company is a good candidate for the standard deployment method, refer to the flowchart in Figure 4-2.

107 Chapter 4: Installing and Configuring Microsoft Exchange Server Start Yes Yes Yes 1 No Are the majority of the user accounts in an existing Windows NT 4.0 domain? Yes No Is there a single Exchange organization? * No Yes Do you plan to upgrade to a single Active Directory forest? ** Yes Perform the upgrade using the standard deployment method discussed in this deployment kit. No Are there fewer than five domains in a location where more than 80% of the users exist? No Will you upgrade just one organization at this time and other organizations in the future? No Will you upgrade the majority of users to a single Active Directory forest? Will the other forest(s) involve specialty or isolated scenarios? See Designing and Deploying Security Services in the Windows Server 2003 Deployment Kit See Consolidating Sites in Exchange 2003 in the Exchange Server 2003 Deployment Guide See Inter-Organizational Migration and Synchronizing Multiple Exchange Forests in the Exchange Server 2003 Deployment Guide * It is okay if there are multiple sites. ** It is okay if there are multiple domains. Figure 4-2 Determining whether the standard deployment method is right for your organization If your answers to the flowchart questions led you to result number 1, the standard deployment method is appropriate for your project. Exchange Server Deployment Tools The Exchange Server Deployment Tools are tools and documentation that help with your migration and validate that your organization is prepared for the Exchange Server 2003 installation. To ensure that all of the required tools and services are installed and running properly, you are required to run Exchange Server 2003 Setup through the Exchange Server Deployment Tools. Note You need to download the latest version of the Exchange Server Deployment Tools before you run them. To get the latest version, see the Downloads for Exchange Server 2003 Web site at go.microsoft.com/fwlink/?linkid= To start the Microsoft Exchange Server 2003 Deployment Tools 1. Insert the Exchange Server 2003 CD into your CD-ROM drive.

108 92 Microsoft Windows Server System Deployment Guide for Midsize Businesses 2. On the Welcome to Exchange Server 2003 Setup page, click Exchange Deployment Tools. 3. If the Welcome to Exchange Server 2003 Setup page does not appear after you insert your CD, double-click Setup.exe, and then click Exchange Deployment Tools to begin. 4. Follow the step-by-step instructions in the Exchange Server Deployment Tools documentation. After you start the tools and specify that you want to follow the process for Coexistence with Exchange Server 5.5, you are provided with a checklist detailing the installation steps. This checklist is separated into the following three phases: Phase 1: Verify that your organization meets the specified requirements. Run the DCDiag tool. Run the NetDiag tool. Phase 2: Run ForestPrep. Run DomainPrep. Run Active Directory Connector Setup. Run Active Directory Connector tools. Phase 3: Run Exchange Server Setup. Important You should not run Exchange Server Setup until you have completed running the Exchange Server Deployment Tools. Before you can install your first Exchange Server 2003 server, Exchange Server Setup verifies that the tools are installed and your network is properly prepared for an Exchange Server installation. With the exception of running the DCDiag and NetDiag tools, each of these installation steps is detailed later in this chapter. (This book recommends that you run the DCDiag and Net- Diag tools on every server on which you plan to install Exchange Server 2003). The following sections provide information about the concepts and considerations involved in migrating from Exchange Server 5.5 to Exchange Server Active Directory and Exchange Server 5.5 Considerations Before installing Exchange Server 2003, you should familiarize yourself with certain Active Directory and Exchange Server 5.5 directory considerations. Specifically, this section contains information about migrating your Windows user accounts and synchronizing your Exchange Server 5.5 directory with Active Directory.

109 Chapter 4: Installing and Configuring Microsoft Exchange Server Exchange Server Directory Service and Windows NT User Accounts In Windows NT Server 4.0 and Exchange Server 5.5, when you create a user and assign that user a mailbox, you associate a Windows NT user account with a mailbox object in the Exchange directory. This association is made by a SID, which every computer and user account on a network running Windows NT has. Active Directory User Objects and Directory Synchronization Unlike earlier versions of Exchange Server and Windows NT, Active Directory contains a single object that has default user attributes and Exchange-specific attributes. When you populate Active Directory with user objects in an organization that includes an earlier version of Exchange Server, the user objects in Active Directory do not include Exchange-specific attributes. When you install Exchange Server 2003, Exchange extends user objects in Active Directory to include Exchange-specific attributes. Exchange Server 5.5 has its own directory service, which, by default, cannot communicate with Active Directory and Exchange Server Therefore, Exchange Server 2003 Active Directory Connector (ADC) is used to allow communication and synchronization between the Exchange Server 5.5 directory and Active Directory. ADC populates and synchronizes Active Directory with mailbox, custom recipient, distribution list, and public folder information from the Exchange Server 5.5 directory. Similarly, ADC also populates and synchronizes the Exchange Server 5.5 directory with user, contact, and group information from Active Directory. For more information about using ADC, see Active Directory Connector later in this chapter. Populating Active Directory Before synchronization can occur, you must populate Active Directory with user information from your existing directory service. Active Directory is populated when your Windows NT 4.0 user account information and Exchange-specific object information from your Exchange Server 5.5 directory service reside in Active Directory. Your deployment plan might require a combination of methods, such as one or both of the following: Upgrade existing Windows NT 4.0 user accounts to Active Directory user accounts: One method of populating Active Directory is to upgrade the Windows NT primary domain controller in the domain that contains your user accounts to a Windows 2000 or Windows Server 2003 domain controller. When you upgrade a Windows NT user account, you preserve all account information, including the SID. This is the method that this book assumes will be used. Use Active Directory Migration Tool to create cloned user accounts that preserve security information: Another method of populating Active Directory is to use Active Directory Migration Tool to clone the accounts in Active Directory. This creates a cloned account in the new domain with a different SID than in the original domain. A cloned account is

110 94 Microsoft Windows Server System Deployment Guide for Midsize Businesses a newly created account in a Windows 2000 or Windows Server 2003 domain that has been copied from a Windows NT 4.0 source account. Although the new user object has a different SID than the source account, you should ensure that the SID of the source account is copied to the new user object s SIDHistory attribute. Populating the SIDHistory attribute with the source account SID allows the new user account to access all network resources available to the source account, providing that a trust exists between resource domain and the new domain. When you run Active Directory Migration Tool, you specify a source Windows NT account (or domain) and a target container in Active Directory in which Active Directory Migration Tool creates cloned accounts. Note These methods provide a phased approach to populating Active Directory for Exchange Server Although the previous section discussed these methods briefly, a complete discussion about these methods is outside the scope of this book. How you formulate your deployment strategy depends on your domain structure, deployment timeline, Windows Server operating system upgrade plan, and business needs. Be sure to construct a thorough deployment plan before you implement any of the methods described. For conceptual and procedural information about upgrading user accounts, Active Directory Migration Tool, Windows NT 4.0, Windows 2000, and Windows Server 2003, see Windows Help, and the Microsoft Windows Web site at go.microsoft.com/fwlink/?linkid= Active Directory Connector After you populate Active Directory with Windows NT 4.0 user and group accounts, the next step in your migration is to connect your Exchange Server 5.5 directory to Active Directory. Specifically, you must use either ADC or the user domain upgrade method to add Exchange Server 5.5 mailbox attributes to the Active Directory users and groups that you copied to Active Directory. Synchronizing Active Directory with the Exchange Server 5.5 directory during the migration process is necessary because Exchange Server 2003 uses Active Directory as its directory service. ADC is a synchronization component that updates object changes between the Exchange Server 5.5 directory and Active Directory. ADC synchronizes current mailbox and distribution list information from the Exchange Server 5.5 directory to Active Directory user accounts and groups, thereby eliminating the need for re-entering this data in Active Directory. If ADC finds a recipient object in the Exchange directory that does not have a matching SID in Active Directory, ADC creates a user object in Active Directory and stores the existing SID in the msexchmasteraccountsid attribute of the new object. By default, ADC searches for the Windows NT user account SID before searching for a new object s SID history. However, ADC will not find a matching SID in Active Directory if ADC replicates before correctly upgrading your existing Windows NT 4.0 user accounts.

111 Chapter 4: Installing and Configuring Microsoft Exchange Server If your migrated users have problems logging on to their mailboxes after you use Active Directory Migration Tool and ADC, you can use the Exchange Server 2003 Active Directory Account Cleanup Wizard to merge the duplicate objects for mailbox logon purposes. To run Active Directory Account Cleanup Wizard 1. Click Start, point to All Programs, point to Microsoft Exchange, point to Deployment, and then click Active Directory Account Cleanup Wizard. 2. Follow the instructions in the wizard to merge your duplicate user objects. Note While your Exchange Server 2003 organization coexists with Exchange Server 5.5, you must use ADC to maintain directory synchronization. Installing Active Directory Connector To install the Exchange Server 2003 version of ADC, you must have at least one server in each Exchange site running Exchange Server 5.5 SP3. The account you use to install ADC must be a member of the Enterprise Administrator, Schema Administrator, and Domain Administrator groups. The account must also be a Local Machine Administrator on the local machine. To install Active Directory Connector 1. Insert the Exchange CD into your CD-ROM drive. You can install ADC on any computer in the Windows domain. 2. On the Start menu, click Run, and then type E:\adc\i386\setup, where E is your CD- ROM drive. 3. On the Welcome to the Active Directory Connector Installation Wizard page, click Next. 4. On the Component Selection page, select the Microsoft Active Directory Connector Service and the Microsoft Active Directory Connector Management components, and then click Next. 5. On the Install Location page, verify the folder location, and then click Next. 6. On the Service Account page, in the Account box, browse to the user or group that the ADC service will run as, and then click Next. Important The service account or group you chose must have Local Administrator and built-in Domain Administrator permissions. The account or group that you designate as the ADC service account will have full control of the Exchange organization. Therefore, you should ensure that it is a secure account or group. 7. On the Microsoft Active Directory Connector Setup page, click Finish.

112 96 Microsoft Windows Server System Deployment Guide for Midsize Businesses Using Active Directory Connector Tools ADC Tools lead you through the process of confirming that your Exchange Server 5.5 directory and mailboxes are ready for migration. The tools are a collection of wizards and utilities that help you set up and configure your connection agreements. They also ensure that replication between your Windows NT 4.0 organization and Windows 2000 or Windows Server 2003 is functioning properly. ADC Tools, as shown in Figure 4-3, are configured to check your organization s configuration and connection agreements, and provide a recommendation based on your configuration. It is strongly suggested that you accept the recommendation in the Active Directory Connector Tool. Figure 4-3 The Active Directory Connector Services Tools page To run ADC Tools 1. On your ADC server, click Start, point to All Programs, point to Microsoft Exchange, and then click Active Directory Connector. 2. In the console tree, click ADC Tools. 3. Follow the steps indicated in the ADC Tools details pane. Specifically, the ADC Tools lead you through the processes of scanning your directory, running Resource Mailbox Wizard, running Connection Agreement Wizard, and verifying synchronization.

113 Resource Mailbox Wizard Chapter 4: Installing and Configuring Microsoft Exchange Server The Resource Mailbox Wizard identifies Active Directory and Windows NT 4.0 accounts that match more than one Exchange Server 5.5 mailbox. In Windows NT 4.0 and Exchange Server 5.5, you could have a user account that corresponded to more than one mailbox. Using Active Directory and Exchange Server 2003, a user account can no longer have more than one mailbox. You can use the Resource Mailbox Wizard to match the appropriate primary mailbox to the Active Directory account and assign other mailboxes with the NTDSNoMatch value, which designates the mailboxes as resource mailboxes. You can either make these changes online by using the Resource Mailbox Wizard, or export to a comma-separated value (.csv) file that you can update and import into the Exchange Server 5.5 directory. Connection Agreement Wizard The Connection Agreement Wizard recommends public folder connection agreements and recipient connection agreements based on your Exchange Server 5.5 directory and Active Directory configuration. You can then review the recommended connection agreements, as shown in Figure 4-4, and select those that you want the wizard to create. There are three kinds of connection agreements: Recipient connection agreements: Recipient connection agreements replicate recipient objects and the data they contain between the Exchange directory and Active Directory. Public folder connection agreements: Public folder connection agreements replicate public folder directory objects between the Exchange Server 5.5 directory and Active Directory. Configuration connection agreements: Configuration connection agreements replicate Exchange-specific configuration information between the Exchange Server 5.5 directory and Active Directory. These agreements allow Exchange Server 2003 to coexist with Exchange Server 5.5. During your initial Exchange Server 2003 installation, Exchange Server 2003 Setup creates a configuration connection agreement between Active Directory and your Exchange Server 5.5 site. Figure 4-4 The Active Directory Connector Services page

114 98 Microsoft Windows Server System Deployment Guide for Midsize Businesses System-Wide Requirements for Exchange Server 2003 Before you migrate to Exchange Server 2003, ensure that your network and servers meet the following system-wide requirements: Windows 2000 Server Service Pack 3 (SP3) Active Directory or Windows Server 2003 Active Directory is installed. Each Exchange Server 2003 server has access to a Windows global catalog server that is no more than one Active Directory site away. DNS and WINS are configured correctly. NetBIOS, RPC, and TCP/IP connectivity has been established between your Exchange Server 5.5 organization and your Windows domain controllers. Exchange Server 5.5 databases and your servers running Windows 2000 or Windows Server 2003 are backed up. Each Exchange site running Exchange Server 5.5 SP3 has at least one server to allow synchronization between the Exchange Server 5.5 directory and Active Directory. Running Exchange Server 2003 ForestPrep Exchange Server 2003 ForestPrep extends the Active Directory schema to include classes and attributes specific to Exchange. ForestPrep also creates the container object for the Exchange organization in Active Directory. The schema extensions supplied with Exchange Server 2003 are a superset of those supplied with Exchange Server For information about the schema changes between Exchange Server 2000 and Exchange Server 2003, see Appendix: Exchange 2003 Schema Changes in the guide What s New in Exchange Server 2003 at go.microsoft.com/fwlink/?linkid= In the domain where the schema master resides, run ForestPrep once in the Active Directory forest. (By default, the schema master runs on the first Windows domain controller installed in a forest.) Exchange Setup verifies that you are running ForestPrep in the correct domain. If you are not in the correct domain, Setup informs you which domain contains the schema master. For information about how to determine which of your domain controllers is the schema master, see Windows 2000 Help or Windows Server 2003 Help. The account you use to run ForestPrep must be a member of the Enterprise Administrator and the Schema Administrator groups. While you are running ForestPrep, you designate an account or group that has Exchange Full Administrator permissions to the organization object. This account or group has the authority to install and manage Exchange Server 2003 throughout the forest. This account or group also has the authority to delegate additional Exchange Full Administrator permissions after the first server is installed.

115 Chapter 4: Installing and Configuring Microsoft Exchange Server Important When you delegate Exchange roles to a security group, this book recommends that you use Global or Universal security groups and not Domain Local security groups. Although Domain Local security groups can work, they are limited in scope to their own domain. In many scenarios, Exchange Setup needs to authenticate to other domains during the installation. Exchange Setup may fail in this case because of a lack of permissions to your external domains. Note To decrease replication time, run Exchange Server 2003 ForestPrep on a domain controller in your root domain. You can run Exchange 2003 ForestPrep from either the Exchange Server 2003 CD or from the Exchange Server Deployment Tools. For information about how to run Exchange ForestPrep from the Exchange Server Deployment Tools, see Exchange Server Deployment Tools earlier in this chapter. To run Exchange 2003 ForestPrep 1. Insert the Exchange CD into your CD-ROM drive. 2. On the Start menu, click Run, and then type E:\setup\i386\setup /ForestPrep, where E is your CD-ROM drive. 3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next. 4. On the License Agreement page, read the agreement. If you accept the terms, click I agree, and then click Next. 5. On the Product Identification page, type your 25-digit product key, and then click Next. 6. On the Component Selection page, ensure that Action is set to ForestPrep. If not, click the drop-down arrow, and then click ForestPrep. Click Next. Important If ForestPrep does not appear under Action, you may have misspelled the ForestPrep command in step 2. If this is the case, go back to step 2 and retype the command. 7. On the Microsoft Exchange Server Administrator Account page, in the Account box, type the name of the account or group that is responsible for installing Exchange Server. Note The account that you specify will also have permission to use the Exchange Administration Delegation Wizard to create other Exchange administrator accounts. For more information about the Exchange Administration Delegation Wizard, see the Exchange Server 2003 Administration Guide at go.microsoft.com/fwlink/?linkid=21769.

116 100 Microsoft Windows Server System Deployment Guide for Midsize Businesses 8. Click Next to start ForestPrep. After ForestPrep starts, you cannot cancel the process. Note Depending on your network topology and the speed of your Windows 2000 or Windows Server 2003 domain controller, ForestPrep might take a considerable amount of time to complete. 9. On the Completing the Microsoft Exchange Wizard page, click Finish. Running Exchange Server 2003 DomainPrep After you run ForestPrep and allow time for replication, you must run Exchange Server 2003 DomainPrep, which creates the groups and permissions necessary for Exchange servers to read and modify user attributes. The Exchange Server 2003 version of DomainPrep performs the following actions in the domain: Creates Exchange Domain Servers and Exchange Enterprise Servers groups. Nests the global Exchange Domain Servers into the Exchange Enterprise Servers local group. Creates the Exchange System Objects container, which is used for mail-enabled public folders. Sets permissions for the Exchange Enterprise Servers group at the root of the domain so that the Recipient Update Service has the appropriate access to process recipient objects. Modifies the AdminSdHolder template where Windows sets permissions for members of the local Domain Administrator group. Adds the local Exchange Domain Servers group to the Pre-Windows 2000 Compatible Access group. Performs Exchange Setup pre-installation checks. The account you use to run DomainPrep must be a member of the Domain Administrators group in the local domain and a local machine administrator. You must run DomainPrep in the following domains: The root domain. All domains that will contain Exchange Server 2003 servers. All domains that will contain Exchange Server 2003 mailbox-enabled objects, such as users and groups, even if no Exchange servers will be installed in these domains. All domains that contain global catalog servers that Exchange Server directory access components might potentially use.

117 Chapter 4: Installing and Configuring Microsoft Exchange Server All domains that will contain Exchange Server 2003 users and groups that you will use to manage your Exchange Server 2003 organization. Note Running DomainPrep does not require any Exchange permissions. Only Domain Administrator permissions are required in the local domain. You can run Exchange Server 2003 DomainPrep from either the Exchange Server Deployment Tools or from the Exchange 2003 CD. For information about how to run Exchange Server DomainPrep from the Exchange Server Deployment Tools, see Exchange Server Deployment Tools earlier in this chapter. To run Exchange 2003 DomainPrep 1. Insert the Exchange CD into your CD-ROM drive. You can run DomainPrep on any computer in the domain. 2. From a command prompt, type E:\setup\i386\setup /DomainPrep, where E is your CD-ROM drive. 3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next. 4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next. 5. On the Product Identification page, type your 25-digit product key, and then click Next. 6. On the Component Selection page, ensure that Action is set to DomainPrep. If not, click the drop-down arrow, and then click DomainPrep. Click Next. Important If DomainPrep does not appear in the Action list, you might have misspelled the DomainPrep command in step 2. If this is the case, go back to step 2 and retype the command. 7. On the Completing the Microsoft Exchange Wizard page, click Finish. Installing and Enabling Windows 2000 or Windows Server 2003 Services Exchange Server 2003 Setup requires that the following components and services be installed and enabled on the server: The.NET Framework ASP.NET

118 102 Microsoft Windows Server System Deployment Guide for Midsize Businesses IIS World Wide Web Publishing Service Simple Mail Transfer Protocol (SMTP) service Network News Transfer Protocol (NNTP) service If you are installing Exchange Server 2003 on a server running Windows 2000, Exchange Server Setup installs and enables the Microsoft.NET Framework and ASP.NET automatically. You must install the World Wide Web Publishing Service, SMTP service, and NNTP service before running Exchange Server 2003 Installation Wizard. Important When you install Exchange Server on a new server, only the required services are enabled. For example, Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), and Network News Transfer Protocol (NNTP) services are disabled by default on all of your Exchange 2003 servers. You should enable only services that are essential for performing Exchange Server 2003 tasks. To install services in Windows Click Start, point to Settings, and then click Control Panel. 2. Double-click Add/Remove Programs. 3. Click Add/Remove Windows Components. 4. Click Internet Information Services (IIS), and then click Details. 5. Select the NNTP Service, SMTP Service, and World Wide Web Service check boxes. 6. Click OK. 7. Click Next, and when the Windows Components Wizard completes, click Finish. Note Ensure that the Internet Information Services (IIS) check box is selected. To install services in Windows Server Click Start, point to Control Panel, and then click Add or Remove Programs. 2. In Add or Remove Programs, click Add/Remove Windows Components. 3. In Windows Component Wizard, on the Windows Components page, highlight Application Server, and then click Details. 4. In Application Server, select the ASP.NET check box. 5. Highlight Internet Information Services (IIS), and then click Details. 6. In Internet Information Services (IIS), select the NNTP Service, SMTP Service, and World Wide Web Service check boxes, and then click OK.

119 Chapter 4: Installing and Configuring Microsoft Exchange Server In Application Server, ensure that the Internet Information Services (IIS) check box is selected, and then click OK to install the components. Note Do not select the Services check box. 8. Click Next, and when the Windows Components Wizard completes, click Finish. 9. Perform the following steps to enable ASP.NET: a. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager. b. In the console tree, expand the local computer, and then click Web Service Extensions. c. In the details pane, click ASP.NET, and then click Allow.Running Exchange 2003 Setup. After planning and preparing your Exchange Server organization in accordance with the requirements and procedures listed in this article, you are ready to run Exchange Server 2003 Setup. When running Setup, it is recommended that you join your existing Exchange Server 5.5 organization. By joining your Exchange Server 5.5 organization, you can move your mailboxes and public folders more easily. To run Exchange 2003 Setup 1. Log on to the server on which you want to install Exchange. Insert the Exchange Server 2003 CD into your CD-ROM drive. 2. On the Start menu, click Run, and then type E:\setup\i386\setup.exe, where E is your CD-ROM drive. 3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next. 4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then click Next. 5. On the Product Identification page, type your 25-digit product key, and then click Next. 6. On the Component Selection page, in the Action column, use the drop-down arrows to specify the appropriate action for each component, and then click Next. Note It is recommended that you install the Microsoft Exchange Server 5.5 Administrator program on your Exchange 2003 server. Click and select Install on the Component Selection page. 7. On the Installation Type page, click Join or upgrade an existing 5.5 Exchange Organization, and then click Next.

120 104 Microsoft Windows Server System Deployment Guide for Midsize Businesses 8. On the Select a Server in an Exchange 5.5 Organization page, in the Exchange Server 5.5 Name box, type the name of an Exchange Server 5.5 SP3 server in the site you want to join, and then click Next. Note Before setup starts, Exchange Setup performs specific checks on your organization, including service pack versions, Windows 2000 version checks, and interoperability with Exchange Server 5.5. Therefore, all Exchange 5.5 servers in your administrative groups must be up and running before you start Exchange Setup. Exchange Setup also contacts the Exchange 5.5 server and performs checks against Active Directory. If Exchange Setup detects that you have not completed running the ADC Tools, Setup will stop. If you have not completed the ADC Tools, see Using Active Directory Connector Tools earlier in this chapter. 9. On the License Agreement page, read the agreement. If you agree to the terms, click I agree that I have read and will be bound by the license agreements for this product, and then click Next. 10. On the Service Account page, type the password for your Exchange Server 5.5 service account. 11. On the Installation Summary page, confirm that your Exchange installation choices are correct, and then click Next. (See Figure 4-5.) 12. On the Completing the Microsoft Exchange Wizard page, click Finish. Figure 4-5 The Installation Summary page

121 Chapter 4: Installing and Configuring Microsoft Exchange Server Moving Exchange Server 5.5 Mailbox and Public Folder Contents After you have populated Active Directory with Windows NT 4.0 objects, connected the Exchange Server 5.5 directory to Active Directory, and installed your first Exchange 2003 server into the Exchange Server 5.5 site, your next migration task is to move your Exchange Server 5.5 mailbox and public folder contents into the Exchange Server 2003 organization. Using Exchange Move Mailbox in Task Wizard Exchange Task Wizard provides an improved method for moving mailboxes. You can now select as many mailboxes as you want, and then using the task scheduler, schedule a move to occur at a specified time. You can also use the task scheduler to cancel any unfinished moves at a specified time. For example, you can schedule a large move to start at midnight on Friday and terminate automatically at 6:00 A.M. on Monday, thereby ensuring that your server s resources are not being used during regular business hours. Using the wizard s improved multithreaded capabilities, you can move as many as four mailboxes simultaneously. To run Exchange 2003 Task Wizard 1. On your Exchange Server 2003 computer, click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager. 2. In the console tree, expand Servers, expand the server from which you want to move mailboxes, expand the Storage Group from which you want to move mailboxes, expand the Mailbox Store you want, and then click Mailboxes. 3. In the details pane, right-click the user or users you want, and then click Exchange Tasks. 4. In Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next. 5. On the Move Mailbox page, to specify the new destination for the mailbox, in the Server list, select a server, and then in the Mailbox Store list, select a mailbox store. Click Next. 6. Under If corrupted messages are found, click the option you want, and then click Next. Note If you click Skip corrupted items and create a failure report, these items are lost permanently when the mailbox is moved. To avoid data loss, back up the source database before moving mailboxes. 7. On the Task Schedule page, in the Begin processing tasks at list, select the date and time for the move. If you want to cancel any unfinished moves at a specified time, in the

122 106 Microsoft Windows Server System Deployment Guide for Midsize Businesses Cancel tasks that are still running after list, select the date and time. Click Next to start the process. 8. On the Completing the Exchange Task Wizard page, verify that the information is correct, and then click Finish. Using Microsoft Exchange Service Public Folder Migration Tool The Microsoft Exchange Server Public Folder Migration Tool (PFMigrate) is a new tool that enables you to migrate both system folders and public folders to the new server. You can use PFMigrate to create system folder and public folder replicas on the new server and, after the folders have replicated, remove replicas from the source server. Unlike Exchange Server 5.5, you do not need to set a home server for a public folder in Exchange Server Any replica acts as the primary replica of the data it contains, and any public folder server can be removed from the replica list. To determine how many system folders or public folders need to be replicated, use PFMigrate to generate a report before you actually run the tool. To determine whether the folders replicated successfully, you can generate the same report after you run the tool. The PFMigrate tool is run from the Exchange Server Deployment Tools. For more information about how to start Exchange Server Deployment Tools, see Exchange Server Deployment Tools earlier in this chapter. To run PFMigrate 1. In Exchange Server Deployment Tools, on the Welcome to the Exchange Server Deployment Tools page, click Deploy the first Exchange 2003 server. 2. On the Deploy the First Exchange 2003 Server page, in the Follow this process column, click Coexistence with Exchange On the Coexistence with Exchange 5.5 page, click Phase On the Phase 3. Installing Exchange Server 2003 on the Initial Server page, click Next. 5. On the Install Exchange 2003 on Additional Servers page, click Next. 6. On the Post-Installation Steps page, under Moving System Folders and Public Folders, click move system folders and public folders, and then follow the steps listed to complete your public folder migration. Note After you run PFMigrate, only the hierarchy of the system folders and public folders is migrated immediately. You must wait for replication to complete for the contents of the system folders and public folders to be migrated. Depending on the size and number of system and public folders, as well as your network speed, replication could take a considerable amount of time.

123 Chapter 4: Installing and Configuring Microsoft Exchange Server Switching from Mixed Mode to Native Mode Because Exchange Server 2003 is structured to take advantage of Active Directory functionality, there are some limitations when Exchange Server 2003 coexists in the same organization with Exchange Server 5.5. When Exchange Server 2003 servers coexist with Exchange Server 5.5, your organization must run in mixed mode. Running in mixed mode limits the functionality of Exchange Server Therefore, after migrating from Exchange Server 5.5 to Exchange Server 2003, it is recommended that you switch from mixed mode to native mode. This section discusses the advantages of a native-mode Exchange Server organization and provides the steps to switch from mixed mode to native mode. Note After you switch your Exchange Server 2003 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode. Make sure that your Exchange Server 2003 organization will not have to interoperate with Exchange Server 5.5 in the future before you switch from mixed mode to native mode. You are ready to change your Exchange 2003 organization to native mode if: Your organization will never require interoperability between your Exchange 2003 servers and Exchange 5.5 servers in the same organization. Your Exchange 5.5 servers exist in an organization that is separate from your Exchange 2003 servers. First, you should determine in which mode your Exchange organization is currently running. To determine the operating mode of your Exchange organization 1. In Exchange System Manager, right-click the Exchange organization for which you want to determine the operating mode, and then click Properties. 2. On the General tab, under Operation mode, the operating mode of your organization is displayed. Exchange 2003 Considerations for Mixed and Native Mode As mentioned earlier, after you migrate from Exchange Server 5.5 to Exchange Server 2003, by default your organization runs in mixed mode. Running Exchange Server 2003 in mixed mode has the following disadvantages: Exchange Server 5.5 sites and administrative groups are mapped directly to each other. Routing group membership consists only of servers that are installed in the administrative groups. You cannot move Exchange 2003 servers between routing groups.

124 108 Microsoft Windows Server System Deployment Guide for Midsize Businesses Because many Exchange 2003 features are available only when you run your Exchange 2003 organization in native mode, it is recommended that you switch from mixed mode to native mode. Running Exchange 2003 in native mode has the following advantages: You can create query-based distribution groups, which provides the same functionality as a standard distribution group. However, instead of specifying static user memberships, with a query-based distribution group you can use an LDAP query to build membership in the distribution group dynamically. For more information about query-based distribution groups, see Managing Recipients and Recipient Policies in the Exchange Server 2003 Administration Guide at go.microsoft.com/fwlink/?linkid= Your routing bridgehead server pairs use 8BITMIME data transfers instead of converting down to 7-bit. This equates to a considerable bandwidth saving over routing group connectors. The Exchange store in Exchange 2003 ignores and removes zombie access control entries (ACEs) from the previous Exchange 5.5 servers in your organization automatically. These zombie ACEs are SIDs from previous Exchange 5.5 servers that have been removed from your organization. Routing groups can consist of servers from multiple administrative groups. You can move Exchange 2003 servers between routing groups. You can move mailboxes between administrative groups. SMTP is the default routing protocol. Removing Exchange 5.5 Servers Before you can switch from mixed mode to native mode, you must remove all Exchange 5.5 servers in your organization. Before you remove an Exchange 5.5 server from your site, verify that there are no mail connectors on the server. If there are, open a connector on another server in the site, and then verify mail flow. Next, remove the connectors on the server to be deleted, and then retest message flow. For more information about removing your Exchange 5.5 connectors, see the Exchange Server 5.5 Help. Note Ensure that the account to which you are logged on has Exchange Full Administrator permissions, as well as Exchange 5.5 service account administrator permissions for the site. To remove Exchange From the Exchange Server 5.5 CD, run Setup.exe. 2. On the Microsoft Exchange Server Setup page, click Remove All, and then click Yes to remove your Exchange server.

125 Chapter 4: Installing and Configuring Microsoft Exchange Server Use the Exchange 5.5 Administrator program to connect to another server within the same site. Make sure you are logged on using the Exchange service account or an account with equivalent permissions. 4. Select the server you want to delete. On the Edit menu, click Delete. Important If this is the first server in the site to be removed, see Microsoft Knowledge Base article , XADM: How to Remove the First Exchange Server in a Site at go.microsoft.com/fwlink/?linkid=3052&kbid= Removing the Last Exchange 5.5 Server Before you can switch from mixed mode to native mode, you must remove all Exchange 5.5 servers in your organization. This section guides you through the process of removing the last Exchange 5.5 server from your organization. To remove the last Exchange 5.5 server 1. In Exchange System Manager, in the console tree, expand Administrative Groups, expand the administrative group you want, expand Folders, and then click Public Folders. 2. Right-click Public Folders, and then click View System Folders. 3. Under System Folders, click to expand Offline Address Book. The offline address book should be in the following format: EX:/O=ORG/OU=Site. 4. Right-click the offline address book, click Properties, and then click the Replication tab. Verify that Replicate content to these Public Stores has an Exchange 2003 computer listed. If a replica does not exist on an Exchange 2003 computer, click the Add button to add a replica to an Exchange 2003 computer. 5. Repeat steps 3 and 4 for Schedule+ Free Busy Folder and Organization Forms. Note If Exchange 5.5 public folders are present on the computer running Exchange Server 5.5, you can use the PFMigrate tool that is available with the Exchange Deployment Tools to move your public folders to an Exchange 2003 server. For more information about migrating public folders, see Exchange Server Deployment Tools and Using Microsoft Exchange Public Folder Migration Tool earlier in this chapter. 6. Move any connectors (for example site connectors or directory replication connectors) on this computer to an SRS server in your site. 7. Wait for the public folder, Schedule+ Free Busy, and Organization Forms information to replicate before you begin the next steps. 8. From an Exchange 2003 or Exchange Server 5.5 computer, start the Exchange Server 5.5 administrator program. When you receive the prompt for a server to connect to, type the name of the Exchange 2003 SRS server for that administrative group.

126 110 Microsoft Windows Server System Deployment Guide for Midsize Businesses Note You cannot delete an Exchange 5.5 computer if you are connected to it with the Exchange administrator program. Make sure you are not connected to any Exchange 5.5 servers that you want to remove. 9. Under Configuration, click to expand the Servers node. Click the Exchange Server 5.5 computer that you want to remove from the administrative group, and then press Delete. 10. From the Active Directory Connector Tool MMC snap-in, right-click the Config_CA_SRS_Server_Name object, and then click Replicate Now. The Exchange administrator program also removes the Exchange Server 5.5 computer from the SRS database. The Config_CA object reads this delete, and then replicates it to Active Directory. Removing Site Replication Service Site Replication Service (SRS) is a component that exchanges configuration information between Active Directory and the directory in Exchange 5.5. In Exchange 5.5, SRS is necessary because Exchange 5.5 configuration information can only be exchanged between Exchange 5.5 servers and Exchange 5.5 directories not with Active Directory. SRS mimics an Exchange 5.5 directory so that other Exchange 5.5 servers can replicate information to it. Using the configuration connection agreement created by Exchange Setup, ADC replicates the configuration information in SRS into Active Directory. SRS runs only in a mixed-mode Exchange administrative group. SRS also performs additional functions, such as detecting and reacting to directory replication topology changes. You cannot switch from mixed mode to native mode until you have removed all instances of SRS. SRS is enabled automatically in the following two situations: On the first Exchange 2003 server you install in an Exchange 5.5 organization. When you upgrade to Exchange 2000 from an Exchange 5.5 server that is the directory replication bridgehead server for an organization. To remove Exchange SRS 1. From the Active Directory Connector Tool MMC snap-in, navigate to your recipient connection agreements. To remove any recipient connection agreements that exist in your Exchange organization, right-click the connection agreement, and then click Delete. You should also remove any public folder connection agreements. 2. Either from another Exchange 5.5 server, or directly from the Exchange 2003 server that is running SRS, open the Exchange 5.5 Administrator program. This is typically the first Exchange 2003 server installed in an Exchange 5.5 site. Click File, click Connect to Server, and then type the name of the Exchange 2003 server running SRS.

127 Chapter 4: Installing and Configuring Microsoft Exchange Server In the Exchange 5.5 Administrator program, expand the local site name (displayed in bold), expand Configuration, click Directory Replication Connectors, and then delete any directory replication connectors that exist. Important Do not delete the ADNAutoDRC connector listed under Directory Replication Connectors. Allow time for the changes that you made in Exchange Administrator to replicate to the configuration connection agreements (Config CAs) to Active Directory. 4. In Exchange System Manager, ensure that no Exchange 5.5 computers are displayed in any administrative groups. 5. In Exchange System Manager, expand Tools, and then click Site Replication Services. From the details pane right-click each SRS, and then click Delete. When you do so, the SRS and corresponding Config CA for that SRS are deleted. 6. After all instances of SRS are deleted, remove the ADC service. After you complete these steps, you can convert the Exchange organization to native mode. Switching to Native Mode Use the following procedure to switch your Exchange organization from mixed mode to native mode. Important After you switch your Exchange 2003 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode. Before you perform the following procedure, ensure that your Exchange 2003 organization will not have to interoperate with Exchange 5.5 in the future. To switch to native mode 1. Start Exchange System Manager: click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager. 2. In the console tree, right-click the organization that you want to switch to native mode, and then click Properties. 3. In <Organization Name> Properties, under Change operation mode, click Change Mode. 4. In the warning dialog box, click Yes if you are sure that you want to permanently switch to native mode. Click Apply to accept your new Exchange mode. To take full advantage of Exchange native mode, you must restart the Microsoft Exchange Information Store service on all of the Exchange servers in your organization. You do not need

128 112 Microsoft Windows Server System Deployment Guide for Midsize Businesses to restart all of the Microsoft Exchange Information Store services simultaneously, but you must restart the service on each server for the server to take advantage of all Exchange native mode features. Restart the service on your servers after the change to native mode has been replicated to your local Windows domain controller. To determine whether the changes have been replicated to your local domain controller, refer to the procedure To determine the operating mode of your Exchange organization in the section Switching from Mixed Mode to Native Mode earlier in this chapter. To restart the Microsoft Exchange Information Store service 1. On the Start menu, click Run, type services.msc, and then click OK. 2. In the Services (Local) pane, find the Microsoft Exchange Information Store service. 3. Right-click the service, and then click Restart. Note In the <Organization Name> Properties dialog box, the Change Mode button is unavailable if any Exchange 5.5 servers are present or SRS exists in the organization. The following steps provide an overview of the implementation of messaging services: Configuring the messaging services. Publishing the SMTP Service. Performing final security configuration validation. Publishing the Outlook Web Access (OWA) site. Configuring the Messaging Services This section guides you on the installation and configuration for messaging services. Prior to beginning the installation and configuration, make sure you have gathered the appropriate software, updates, utilities, and configuration information you will need. Note If the steps in this section do not specify the exact values to be used while running a wizard, use the default values provided by the wizard. Installing and Configuring Prerequisites for Exchange Installation 1. Install NNTP, SMTP, ASP.NET, and World Wide Web services. 2. Open Add/Remove Programs, and then click Add/Remove Windows Components. 3. Highlight Application Server (do not select the check box), and then click Details. 4. On the Application Server page, select the ASP.NET check box.

129 Chapter 4: Installing and Configuring Microsoft Exchange Server Highlight Internet Information Services (IIS) (do not select the check box) and then click Details. 6. On the Internet Information Services (IIS) page, select the NNTP Service, SMTP Service, and World Wide Web Service check boxes, and then click OK. 7. On the Application Server page, click OK. 8. Click Next to begin the installation. Run diagnostic tools to ensure that DNS and network connectivity are working properly: 1. Open the command prompt from Start>Programs>Windows Support Tools. 2. Run DCDiag /f:"c:\program files\support tools\dcdiag.txt" (to test network connectivity and DNS resolution). 3. Run NetDiag (to test network connectivity). Note It is important to create and carefully review the log files (dcdiag.txt and netdiag.log in the C:\Program Files\Support Tools directory) associated with the various diagnostic tools that are run as part of the checklist. If there are any failed tests in any of the log files (except the item listed in the next sentence), resolve them before proceeding. It is expected that the Default Gateway Test will fail because the ISA Server is blocking ICMP traffic, so this is the only failure that can be safely ignored. Perform the following steps to prepare the domain for installation of Exchange: 1. Move the Microsoft Exchange Server 2003 CD to the primary infrastructure server (MOCOR2). 2. Log on to MOCOR2 as administrator, click Start, click Run, and type D:\setup\i386\setup.exe /forestprep (where D is the drive letter of the CD-ROM drive with the Microsoft Exchange Server CD) and then click OK. Provide the Product ID when prompted in the Microsoft Exchange Installation Wizard. Accept the default choices on all other steps. 3. After the forestprep wizard completes, click Start, click Run, and type D:\setup\i386\setup.exe /domainprep (where D is the drive letter of the CD-ROM drive with the Microsoft Exchange Server CD) and then click OK. Provide the Product ID when prompted in the Microsoft Exchange Installation Wizard. Accept the default choices on all other steps. Note When running the DomainPrep utility, you will see a pop-up window warning you about an insecure domain. This message can be safely ignored.

130 114 Microsoft Windows Server System Deployment Guide for Midsize Businesses 4. After running the DomainPrep and ForestPrep utilities, wait for the full domain replication to be complete before proceeding. By default, the replication interval is 15 minutes. However, you might want to wait longer to ensure that all changes have been replicated properly. Note In larger environments, it might be necessary to wait longer depending on the topology and number of domain controllers. 5. To verify that the ForestPrep and DomainPrep replication have completed successfully, perform the following steps on both servers: Installing Exchange a. Verify that you received no error messages. b. Use Event Viewer to inspect the system log for errors or unexpected events. c. From the <systemdrive>:\program Files\Support Tools directory at the command prompt, run dcdiag /test:replications and ensure that all tests are passed. 1. Log on to MOCOR2 as administrator, click Start, click Run, type D:\setup\i386\setup.exe (where D is the drive letter of the CD-ROM drive with the Microsoft Exchange Server CD) and then click OK. 2. Click through the Microsoft Exchange Installation Wizard. 3. On the Component Selection page, change the drive letter of the top line item to the drive letter of the data partition on the server. 4. When prompted to create the folder, click Yes, and then click Next. 5. Complete the wizard. Installing Exchange System Management Tools 1. On the primary infrastructure server, run the Exchange Setup program. 2. On the Component Selection page, select Custom Installation, and install only Microsoft Exchange System Management Tools. Accept the default directory for installation. Note Although installing the Microsoft Exchange System Management Tools on MOCOR2 is not required, it is highly recommended. This step makes it easy to administer the Exchange server from MOCOR2, but most importantly it installs the extensions so that Exchange attributes show up on MOCOR2, such as in the Active Directory Users and Computers console.

131 Chapter 4: Installing and Configuring Microsoft Exchange Server Installing Updates and Service Packs Install all Microsoft Exchange service packs that were downloaded in the Gathering Information for Initial Configuration section in Chapter 3, Installing and Configuring Firewalls. Backing Up the IIS Configuration 1. From Administrative Tools, open Internet Information Services (IIS) Manager. 2. Right-click the server name (MOCOR2), click All Tasks, and then click Backup/ Restore Configuration. 3. Click Create Backup. 4. In the Configuration backup name, type Post Exchange Install. 5. Click Close. Note This IIS configuration is backed up at this point because the next several sections of the document make changes to IIS. Having a good backup of IIS before making such reconfigurations allows for a fallback strategy in case of error. Configuring Forms-Based Authentication 1. On MOCOR2, open the Exchange System Manager. 2. Expand Servers. 3. Expand the server name (MOCOR2), and then expand Protocols. 4. Click HTTP. 5. In the right pane, right-click Exchange Virtual Server, and then click Properties. 6. Click the Settings tab, and then select Enable Forms Based Authentication. 7. In the Compression drop-down box, click High. 8. When the warning dialog box related to SSL appears, click OK. Configuring a Certificate on the Server for SSL Communication 1. From Administrative Tools, open Internet Information Services (IIS) Manager. 2. Expand the server name (MOCOR2), and then expand Web Sites. 3. Right-click the Default Web Site, and then click Properties. 4. Click the Directory Security tab. 5. Click the Server Certificate button.

132 116 Microsoft Windows Server System Deployment Guide for Midsize Businesses 6. Go through the IIS Certificate Wizard and specify the following settings (accept the default choices if a setting value is not specified in the following steps): a. On the Delayed or Immediate Request Page, select Send the Request Immediately to an Online Certification Authority. b. In Name, type mail.businessname.com. c. In Organization and Organizational Unit, type the company name. d. In Common Name, type mail.businessname.com. e. Enter the Country, State, and City details. 7. After specifying the setting, in the Secure Communications section, on the Directory Security tab, click the Edit button. 8. Select the Require Secure Channel (SSL) and Require 128-bit encryption check boxes. 9. Click OK twice. 10. On the Inheritance Overrides screen, click Select All, and then click Exadmin to deselect it. 11. Click OK. Configuring DNS Records for mail.businessname.com 1. On the MOCOR2, open the DNS management console. 2. In the BusinessName.com zone, create a new alias (CNAME) record for mail.business- Name.com. The target host is MOCOR2.BusinessName.com. Note When creating the record, you only need to type the host name, for example, mail, because DNS will automatically append the parent domain name. Configuring a Web Site to Redirect Requests to mail.businessname.com 1. From Administrative Tools, open Internet Information Services (IIS) Manager. 2. Right-click Web Sites, and then select New->Web Site. 3. Run through the wizard and specify the following settings (accept the default choices if value for a setting is not specified in the following list): a. On the Web Site Description page, type mail.businessname.com.

133 Chapter 4: Installing and Configuring Microsoft Exchange Server b. On the IP Address and Port Settings page, type mail.businessname. c. At the Web Site Home Directory page, type C:\inetpub\wwwroot. 4. Right-click the site you just created, and then click Properties. 5. Click the Home Directory tab and select A redirection to a URL, and then type 6. Click OK. Note The result of performing these steps is that it enables users to simply direct their browsers to mail.businessname.com to access OWA. This is much easier for users to remember than After performing this configuration, users should be instructed to use only or mail.businessname.com (Internet Explorer will add the automatically.) Downloading and Running URLScan 2.5 to Secure the Server URLScan.exe screens all incoming HTTP requests to an IIS server and allows only those that comply with a specific rule set to pass. This helps ensure that the server responds only to valid requests, thereby significantly improving security. URLScan allows you to filter requests based on length, character set, content, and other factors. For more information about URLScan, including download and installation instructions, see the URLScan Security Tool Web site at go.microsoft.com/fwlink/?linkid= URLScan is configured manually by editing a configuration text file called urlscan.ini. After you install URLScan, this file is located in the following folder: <WinDir>\System32\Inetsrv\Urlscan. It is highly recommended that you configure URLScan according to the Microsoft Knowledge Base article Fine-tuning and known issues when you use the Urlscan utility in an Exchange 2003 environment at support.microsoft.com/?kbid= Configuring FQDN on SMTP Virtual Server 1. Open the Exchange System Manager. 2. Expand Servers, <MOCOR2>, and Protocols, and then click on the SMTP folder. 3. In the right pane, right-click the Default SMTP Virtual Server, and then select Properties.

134 118 Microsoft Windows Server System Deployment Guide for Midsize Businesses 4. Click the Delivery tab, and then click the Advanced button. 5. In the Fully-qualified domain name field, type mailbusinessname.com. Note Specifying the FQDN by using these steps is only intended for an environment with a single Exchange server. In environments with multiple Exchange servers, there are additional rules that apply, such as ensuring that the FQDN of each Exchange server is unique. There might also be other implications in a multi-exchange server environment that are beyond the scope of this solution. Configuring the Proper DNS Records with the ISP 1. Configure the DNS records shown in Table 4-2 with your ISP. Contact information and instructions for DNS record creation were included in the Gathering Information for Initial Configuration section in Chapter Test the configuration by opening You should be able to open OWA. Table 4-2 Records Configured on the ISP DNS Servers FQDN Record Type IP Address remote.businessname.com A Record Static IP address used on the ISA Server. mail.businessname.com CNAME Record remote.businessname.com BusinessName.com MX Record remote.businessname.com Note For the purpose of convenience, all the DNS records that need to be set up with the ISP are included here. This is simply for the reason that step 1 is to be performed only once. Some of the records set up in this table will not be usable until the remainder of the configuration steps in this solution are completed. In addition, wait 24 to 48 hours after setting up DNS records with your ISP before attempting to use them. There is a delay between the time when the records are set up and when they actually propagate across the Internet. Publishing the SMTP Service Note Before starting the SMTP service publishing configuration, back up the present working configuration of the ISA Server by using the steps provided in Backing Up the ISA Server Configuration in Chapter 3.

135 Chapter 4: Installing and Configuring Microsoft Exchange Server Publishing the SMTP service involves the following tasks: Publishing the internal SMTP server to the Internet: This task publishes the internal mail server on the external interface of the firewall server so that it can listen for incoming SMTP requests. Defining an access rule to allow outbound SMTP traffic to the Internet: This task configures the ISA Server to allow the Exchange server to communicate with the external public mail server for outgoing SMTP traffic. Publishing the Internal SMTP Server to the Internet 1. In the ISA Server Management console, click Firewall Policy, and then in Tasks in the right pane, click Publish a Mail Server. 2. On the Welcome page, type the name of the rule for mail server publishing (for example, Publish MS Exchange SMTP Mail Server). 3. On the Select Access Type page, select Server-to-server communication: SMTP, NNTP option. 4. On the Select Services page, select the SMTP check box. 5. On the Select Server page, type the IP address of the internal SMTP server (for example, , which is the IP address for the MOCOR2 messaging server in the test scenario). 6. On the IP Addresses page, select External in Listen for requests from these networks. 7. Complete the setup, and then click the Apply button to save changes. Defining an Access Rule to Allow Outbound SMTP Traffic to the Internet 1. In the ISA Server Management console, click Firewall Policy, and then in Tasks in the right-hand pane, click Create New Access Rule. 2. On the Welcome page, type the Access Rule name (for example, Allow outbound SMTP traffic to the Internet). 3. On the Rule Action page, select Allow. 4. On the Protocol page, from the This rule applies to drop-down menu, select Selected Protocols. 5. Click Add. 6. On the Add Protocols page, expand Mail, select SMTP, click Add, and then click Close. 7. Click Next. 8. On the Access Rule Sources page, click Add.

136 120 Microsoft Windows Server System Deployment Guide for Midsize Businesses 9. On the Add Network Entities page, expand Computers and check whether the host name of the server is already defined. If it is already defined, select the mail server name, click Add, and then click Close. If it is not defined, perform the following steps: 10. Click New in the Add Network Entities page and then click Computer. 11. Provide internal SMTP server host name and its IP address (for example, MOCOR2 and ). 12. Expand Computers object, select the server (for example, MOCOR2) and click Add. 13. Click Close. 14. On the Access Rule Destinations page, add External. Note External can be found by expanding Networks object. 15. On the User Sets page, select All Users. 16. Complete the setup, and then click the Apply button to save the changes. Publishing the OWA Site The following procedure allows securely publishing the OWA site running on the messaging server using HTTPS. Publishing the internal OWA site involves the following tasks: Publishing the OWA site as an HTTP site, which is required to enable users to use /mail.businessname.com or mail.businessname.com. Publishing the OWA site as an HTTPS site by using a wildcard certificate based Web listener. This is the secure site that will be redirected when a user types in mail.businessname.com or mail.businessname.com on the Web browser. Note Before configuring the ISA Server to publish the OWA site, back up the present working configuration of the ISA Server by using the steps provided in Backing Up the ISA Server Configuration in Chapter 3. Publishing an OWA Site as an HTTP Site To publish the OWA site as an HTTP site, perform the following steps on the ISA Server: 1. In the ISA Server Management console, click Firewall Policy, and then in the right pane, click Publish a Web Server in Tasks.

137 Chapter 4: Installing and Configuring Microsoft Exchange Server On the Welcome page, type the Web publishing rule name (for example, Publishing MS Exchange OWA site using HTTP). 3. On the Select Rule Action page, select Allow. 4. On the Define Website to Publish page, type the computer name of the internal Web server that is going to be published by the firewall server in Computer name or IP Address (for example, mail.businessname.com). For the internal and external DNS naming convention, refer to Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server Ensure that the firewall server is able to resolve mail.businessname.com to the IP address of the internal messaging server. 5. Select the Forward the original host header instead of the actual one (specified above) check box. Note The name used in an internal network as well as on the Internet is mail. At this point, mail refers to the internal name. Ensure that the firewall server is able to resolve mail.businessname.com to the IP address of the internal mail server internally by making appropriate entry in the DNS server. 6. On the Public Name Details page, select This domain name (type below) and then type the name that is going to be used by the Internet users in the text box (for example, mail.businessname.com). Ensure that the Internet system is able to resolve this name to the IP address of the external interface of the firewall server. 7. On the Select Web Listener page, from the Web Listener dropdown, select Web Listener for Publishing HTTP Sites. 8. Complete the configuration. 9. On the ISA Server Management console, click Apply to save the changes. Publishing an OWA Site as an HTTPS Site 1. On the ISA Server Management console, click Firewall Policy, and then in Tasks in the right pane, click Publish a Mail Server. 2. On the Welcome page, type a name for the rule (for example, Publishing MS Exchange OWA site using HTTPS). 3. On the Select Access Type page, select the Web client access: Outlook Web Access (OWA), Outlook Mobile Access, Exchange Server ActiveSync option. 4. On the Select Service page, select the Outlook Web Access check box. 5. On the Bridging Mode page, click the Secure connection to clients and mail server option.

138 122 Microsoft Windows Server System Deployment Guide for Midsize Businesses 6. On the Specify the Web Mail Server page, type the name of the internal OWA site (for example, mail.businessname.com). Note Ensure that mail.businessname.com is resolved internally by the firewall server. The original internal server host name can be used for redirection purpose. However, for security reasons, it is recommended not to expose the internal naming convention to the Internet and therefore, the name mail is used. 7. On the Select Public Name Details page, select This domain name (type below) and type the FQDN that is going to be used by the Internet used for accessing the OWA in the Public Name: text box (for example, mail.businessname.com). Ensure that the Internet system is able to resolve this name to the IP address of the external interface of the firewall server. 8. On the Select Web Listener page, from the Web Listener drop-down menu, select Web Listener using wildcard certificate for Publishing HTTPS Sites. 9. Finish the setup. 10. Double-click the previously created OWA publishing rule (for example, Publishing MS Exchange OWA site using HTTPS). On the Properties page, click the Traffic tab and select the Require 128-bit encryption for HTTPS traffic check box. 11. On the ISA Server Management console, click Apply to save your changes. Configuring for Client Access Configuring Exchange for client access involves configuring it to handle the protocols and clients that you want to support. The following section describes how to enable the client protocols supported by Exchange on the Exchange server. Configuring RPC over HTTP for Microsoft Outlook 2003 When you deploy RPC over HTTP in your corporate environment, you have two deployment options that are based on where you locate your RPC Proxy server: Option 1 (recommended): Deploy an advanced firewall server such as ISA Server in the perimeter network, and position your RPC Proxy server within the corporate network. Option 2: Position the Exchange 2003 front-end server acting as an RPC Proxy server in the perimeter network. Note When you use ISA Server as your advanced firewall server, you have several deployment options. For information about how to install ISA Server as an advanced firewall server, see Using Microsoft Exchange 2000 Front-End Servers at go.microsoft.com/fwlink /?linkid=14575.

139 Chapter 4: Installing and Configuring Microsoft Exchange Server For more information about these options, see Planning Your Exchange Infrastructure in the guide Planning an Exchange 2003 Messaging System at go.microsoft.com/fwlink /?linkid= To use RPC over HTTP, you must run Windows Server 2003 on the following computers: All Exchange 2003 servers that will be accessed with Outlook 2003 clients using RPC over HTTP. The Exchange 2003 front-end server acting as the RPC Proxy server. Exchange 2003 must be installed on all Exchange servers that are used by the computer designated as the RPC Proxy server. Additionally, all client computers running Outlook 2003 must also be running Windows XP SP1 or later with the Windows XP Patch: RPC Updates Needed for Exchange Server 2003 Beta update installed, which can be found at go.microsoft.com'fwlink/?linkid= Deploying RPC over HTTP This section provides detailed information about how to deploy RPC over HTTP in your Exchange 2003 organization. To deploy RPC over HTTP, complete the following steps: 1. Configure your Exchange front-end server to use RPC over HTTP. 2. Configure the RPC virtual directory in Internet Information Services (IIS). 3. Configure the RPC Proxy server to use specified ports. 4. Open the necessary ports on the internal firewall for RPC over HTTP, as well as the standard ports for Exchange front-end communication. 5. Create an Outlook profile for your users to use with RPC over HTTP. Each of these steps is detailed in the following sections. After you complete these steps, your users can begin using RPC over HTTP to access the Exchange front-end server. The RPC Proxy server processes the Outlook 2003 RPC requests that come in over the Internet. For the RPC Proxy server to successfully process the RPC over HTTP requests, you must install the Windows Server 2003 RPC over HTTP Proxy networking component on your Exchange front-end server. Note You can use any Web server to act as the RPC Proxy server. However, the recommended deployment scenario for RPC over HTTP is to use the Exchange front-end server as your RPC Proxy server. To configure your Exchange front-end server to use RPC over HTTP 1. On the Exchange front-end server running Windows Server 2003, in Add or Remove Programs, click Add/Remove Windows Components in the left pane.

140 124 Microsoft Windows Server System Deployment Guide for Midsize Businesses 2. In the Windows Components Wizard, on the Windows Components page, select Networking Services, and then click Details. 3. In Networking Services, select the RPC over HTTP Proxy check box, and then click OK. 4. On the Windows Components page, click Next to install the RPC over HTTP Proxy Windows component. After you configure your Exchange front-end server to use RPC over HTTP, you must configure the RPC virtual directory in IIS. Important SSL is required on the RPC virtual directory. To configure the RPC virtual directory 1. Start Internet Information Services (IIS) Manager. 2. In Internet Information Services (IIS) Manager, in the console tree, expand the server you want, expand Web Sites, expand Default Web Site, right-click the RPC virtual directory, and then click Properties. 3. In RPC Properties, on the Directory Security tab, in Authentication and access control, click Edit. Note RPC over HTTP does not allow anonymous access. 4. Under Authenticated access, select the Basic authentication (password is sent in clear text) check box, and then click OK. 5. To save your settings, click Apply, and then click OK. Your RPC virtual directory is now set to use Basic authentication. After you enable the RPC over HTTP networking component for IIS, you can configure the RPC Proxy server to use the specified ports to communicate with the servers in the corporate network. In this scenario, the RPC Proxy server is configured to use specified ports. The individual computers that the RPC Proxy server communicates with are also configured to use specified ports when receiving requests from the RPC Proxy server. When you run Exchange 2003 Setup, Exchange is configured automatically to use the ports listed in Table 4-3. Table 4-3 Default Required Ports for RPC over HTTP Server Ports Services Exchange back-end servers 6001 Store 6004 DS Proxy

141 Chapter 4: Installing and Configuring Microsoft Exchange Server Use the following procedures to configure the RPC Proxy server to use specified ports. Warning Incorrectly editing the registry can cause serious problems that might require you to reinstall your operating system. Problems resulting from editing the registry incorrectly might not be able to be resolved. Before editing the registry, back up any valuable data. To configure the RPC Proxy server to use the specified default ports for RPC over HTTP inside the corporate network 1. On the RPC Proxy server, start Registry Editor (regedit). 2. In the console tree, navigate to the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy 3. In the details pane, right-click the ValidPorts subkey, and then click Modify. 4. In Edit String, in the Value data box, type the following information: ExchangeServer:6001;ExchangeServerFQDN:6001;ExchangeServer:6004; ExchangeServerFQDN:6004; ExchangeServer is the NetBIOS name of your Exchange server and global catalog server. ExchangeServerFQDN is the fully qualified domain name (FQDN) of your Exchange server and Global Catalog server. 5. In the registry key, continue to list all servers in the corporate network with which the RPC Proxy server needs to communicate. Important To communicate with the RPC Proxy server, all servers accessed by the Outlook client must have set ports. If a server, such as an Exchange public folder server, has not been configured to use the specified ports for RPC over HTTP communication, the client will not be able to access the server. After you configure the servers for RPC over HTTP communication, you must open the necessary ports on your internal firewall, as represented in Table 4-4. Table 4-4 Required Ports for the Internal Firewall for RPC over HTTP Ports Services 6001 Exchange Information Store 6004 DS Proxy You enable RPC over HTTP by configuring your users profiles to allow RPC over HTTP communication. As an alternative to going to each user s computer, you can instruct your users about how to enable RPC over HTTP on their computer. These settings enable Secure Sockets

142 126 Microsoft Windows Server System Deployment Guide for Midsize Businesses Layer (SSL) communication with Basic authentication, which is necessary when using RPC over HTTP. Although optional, it is highly recommended that you use the Use Cached Exchange Mode option for all profiles that connect to Exchange using RPC over HTTP. To create an Outlook profile to use with RPC over HTTP 1. On the computer running Outlook 2003, in Control Panel, perform one of the following tasks: If you are using Category View, in the left pane, under See Also, click Other Control Panel Options, and then click Mail. If you are using Classic View, double-click Mail. 2. In Mail Setup, under Profiles, click Show Profiles. 3. In Mail, click Add. 4. In New Profile, in the Profile Name box, type a name for this profile, and then click OK. 5. In the Accounts wizard, click Add a new account, and then click Next. 6. On the Server Type page, click Microsoft Exchange Server, and then click Next. 7. On the Exchange Server Settings page, perform the following steps: a. In the Microsoft Exchange Server box, type the name of your back-end Exchange server where your mailbox resides. b. Select the Use Cached Exchange Mode check box (optional, but recommended). c. In the User Name box, type the user name. 8. Click More Settings. 9. On the Connection tab, in Exchange over the Internet, select the Connect to my Exchange mailbox using HTTP check box. 10. Click Exchange Proxy Settings. 11. On the Exchange Proxy Settings page, under Connections Settings, perform the following steps: a. Enter the fully qualified domain name (FQDN) of the RPC Proxy server in the Use this URL to connect to my proxy server for Exchange box. b. Select the Connect using SSL only check box. c. Select the Mutually authenticate the session when connecting with SSL check box. d. Enter the FQDN of the RPC Proxy server in the Principle name for proxy server box. Use the format: msstd:fqdn of RPC Proxy Server.

143 Chapter 4: Installing and Configuring Microsoft Exchange Server e. As an optional step, you can configure Outlook 2003 to connect to your Exchange server using RPC over HTTP by default. Select the On fast networks, connect to Exchange using HTTP first check box, and then connect by using TCP/IP. 12. On the Exchange Proxy Settings page, in the Proxy authentication settings window, in the Use this authentication when connecting to my proxy server for Exchange list, select Basic Authentication. 13. Click OK. 14. Repeat this procedure for each of your users computers. As an alternative, instruct your users about how to create their own profile. Your users are now configured to use RPC over HTTP. Configuring Outlook Web Access By default, OWA is enabled for all of your users after you install Exchange However, you can enable the following features for OWA: Forms-based authentication Outlook Web Access compression You can enable a new logon page for Outlook Web Access that stores the user's name and password in a cookie instead of in the browser. When a user closes his or her browser, the cookie is cleared. Additionally, after a period of inactivity, the cookie is cleared automatically. The new logon page requires users to enter either their domain, user name (in the format domain\username), and password, or their full user principal name (UPN) address and password to access their . To enable the OWA logon page, you must enable forms-based authentication on the server, as described in the following procedure. To enable forms-based authentication 1. Start Exchange System Manager. 2. In the console tree, expand Servers. 3. Expand the server for which you want to enable forms-based authentication, and then expand Protocols. 4. Expand HTTP, right-click Exchange Virtual Server, and then click Properties. 5. In Exchange Virtual Server Properties, on the Settings tab, select the Enable Forms Based Authentication for Outlook Web Access check box. 6. Click Apply, and then click OK.

144 128 Microsoft Windows Server System Deployment Guide for Midsize Businesses OWA supports data compression, which is optimal for slow network connections. Depending on the compression setting you use, OWA compresses static and/or dynamic Web pages. Table 4-5 lists the compression settings that are available in Exchange Server 2003 for OWA. Table 4-5 Compression Setting High Low None Available Compression Settings for OWA Description Compresses both static and dynamic pages. Compresses only static pages. No compression is used. When you use data compression, your users can see performance increases of as much as 50 percent on slower network connections, such as traditional dial-up access. Requirements for Outlook Web Access Compression To use data compression for OWA in Exchange Server 2003, you must verify that you have the following prerequisites: The Exchange server that users authenticate against for OWA must be running Windows Server Your users mailboxes must be on Exchange 2003 servers. (If you have a mixed deployment of Exchange mailboxes, you can create a separate virtual server on your Exchange server just for Exchange 2003 users and enable compression on it.) Client computers must be running Internet Explorer version 6 or later. The computers must also be running Windows XP or Windows 2000 and have installed on them the security update that is discussed in Microsoft Security Bulletin MS02-066, Cumulative Patch for Internet Explorer (Q328970), available at go.microsoft.com/fwlink /?linkid= Note If a user does not have a supported browser for compression, the client still behaves normally. You might need to enable HTTP 1.1 support through proxy servers for some dial-up connections. (HTTP 1.1 support is required for compression to function properly.) To enable data compression 1. Start Exchange System Manager. 2. In the details pane, expand Servers, expand the server you want, and then expand Protocols. 3. Expand HTTP, right-click Exchange Virtual Server, and then click Properties.

145 Chapter 4: Installing and Configuring Microsoft Exchange Server In Exchange Virtual Server Properties, on the Settings tab, under Outlook Web Access, use the Compression list to select the compression level you want (None, Low, or High). 5. Click Apply, and then click OK. Performing Final Security Configuration Validation After completing the configuration of the servers, it is important to once again complete a full security audit on the messaging server to ensure that the server is completely secured. Perform the following steps: 1. Check for any updates available for the server and installed software. Install any updates that are available. 2. Run the Microsoft Exchange Server Best Practices Analyzer Tool. Install any updates that are available and perform a baseline audit of the current environment. For more information on the ExBPA tool, see /exbpa/default.asp. 3. Run the MBSA tool on MOCOR2 against all servers on the network and resolve any security issues the tool discovers. 4. Perform a complete test on the firewall to ensure that configuration on the servers has not affected the security of the environment in any way. Testing the Services To test the messaging services implemented in the Building/Upgrading Exchange Server 5.5 section earlier in this chapter, perform the following tasks: Send and receive messages. Check shared calendar access. Check OWA. Backing Up the System and Verifying the Backup A full backup of all servers, including the system state information, is strongly recommended before releasing the system to users. In addition, verify the backup and confirm that it does not have any problems. If a server fails for any reason, the backup can be used to bring the system back to its original state. Use specific tapes for this backup, and do not make these tapes

146 130 Microsoft Windows Server System Deployment Guide for Midsize Businesses a part of the normal rotation schedule. In addition, some special considerations for the backup in the messaging environment are: Use backup software for the messaging component that will allow a full backup of messaging information while online. It is also important that the software allows restore of an entire messaging database as well as individual database objects, such as an , contact, or calendar item. Deploying and Operating After completing testing and backup, the system can be released to users for regular use. Clients will need a messaging program, such as Outlook 2003, installed to take full advantage of the new features and functionalities available with the messaging services. References This section provides references to important supplementary information and other background material relevant to the contents of this book. These references include: The Microsoft Exchange Server home page, available at /default.mspx The Exchange Server 2003 product information page, available at /exchange/evaluation/default.mspx Downloads for Exchange Server 2003, available at /downloads/2003/default.mspx For more information about Windows 2000 Server, Windows Server 2003, Active Directory, and DNS, see the following resources: Windows 2000 Help Windows Server 2003 Help Best Practice: Active Directory Design for Exchange 2000 at go.microsoft.com/fwlink /?linkid=17837 Planning an Exchange Server 2003 Messaging System at go.microsoft.com/fwlink /?linkid=21766

147 Chapter 5 Installing and Configuring Windows Server Update Services Microsoft Windows Server Update Services (WSUS) provides a comprehensive solution for managing updates within your network. Use the information in this chapter to plan, build, deploy, and operate WSUS. Although WSUS is a feature-rich update-management solution, this book offers only a single way to accomplish any of these tasks. When there are options to perform a task in different ways, a note calls out these choices and points to more comprehensive instructions in the Deploying Microsoft Windows Server Update Services white paper or the Microsoft Windows Server Update Services Operations Guide white paper. The latest versions of these documents are available on the Windows Server Update Services Web site at go.microsoft.com /fwlink/?linkid= This chapter assumes that you are not already running Software Update Services. For guidance on migrating from Software Update Services to Windows Server Update Services, see the Deploying Microsoft Windows Server Update Services white paper at go.microsoft.com /fwlink/?linkid= Planning WSUS Deployment In this section, the design for a simple WSUS deployment will be presented. The most basic deployment of WSUS involves setting up a server inside the corporate firewall to serve client computers on a private intranet, as shown in Figure 5-1 on the next page. The WSUS server connects to Microsoft Update to download updates. This is known as synchronization. During synchronization, WSUS determines if any new updates have been made available since the last time you synchronized. If it is your first time synchronizing WSUS, all updates are made available for approval. The WSUS server uses port 80 and port 443 to obtain updates from Microsoft. This is not configurable. If there is a corporate firewall between your network and the Internet, remember you might have to open port 80 for HTTP and port 443 for HTTPS. 131

148 132 Microsoft Windows Server System Deployment Guide for Midsize Businesses Microsoft Update Figure 5-1 Simple WSUS deployment WSUS Clients Automatic Updates is the client component of WSUS. Automatic Updates must use the port assigned to the WSUS Web site in Microsoft Internet Information Services (IIS). If there are no Web sites running on the server where you install WSUS, you have an option to use the default Web site or a custom Web site. If you set up WSUS on the default Web site, WSUS listens for Automatic Updates on port 80. If you use a custom Web site, WSUS listens on port This book assumes you will set up WSUS on the default Web site and does not discuss setting up a custom Web site. This book also assumes you will set up WSUS on the third server, the MOMGMT server, which will also be running Microsoft Operations Manager Workgroup Edition, Remote Installation Services, and Windows SharePoint Services. Using Computer Groups Computer groups are an important part of even a basic WSUS deployment. Computer groups enable you to target updates to specific computers. There are two default computer groups: All Computers and Unassigned Computers. When each client computer initially contacts the WSUS server, by default the server adds it to both these groups. You can move computers from the Unassigned Computers group to a group you create. You cannot remove computers from the All Computers group. The All Computers group enables you to quickly target updates to every computer on your network, regardless of group membership. The Unassigned Computers group permits you to target only computers that have not yet been assigned group membership. One benefit of creating computer groups is that it enables you to test updates. Figure 5-2 depicts two custom groups named Test group and Accounting group, as well as the All Computers group. The Test group contains a small number of computers representative of all the computers contained in the Accounting group. Updates are approved first for the Test group. If the testing goes well, you can roll out the updates to the Accounting group. There is no limit to the number of custom groups you can create. There are instructions for creating custom computer groups in Creating a Computer Group later in this chapter. Note Do not use WSUS to distribute updates to client computers that are not licensed for your organization. The WSUS license agreement specifically disallows this.

149 Chapter 5: Installing and Configuring Windows Server Update Services 133 Test Group Microsoft Update WSUS Accounting Group Figure 5-2 Simple WSUS deployment with computer groups Choosing the Database Used for WSUS You do not need to be a database administrator or purchase database software to use WSUS. No matter which version of Windows you install WSUS on, there is a free version of Microsoft SQL Server available. These free versions of SQL Server were designed to require very little management by the WSUS administrator. Of course, if you want more control over the database, you can also use the full version of SQL Server with WSUS. The WSUS database stores the following types of information: WSUS server configuration information Metadata that describes what each update is useful for Information about client computers, updates, and client interaction with updates Managing WSUS by accessing data directly in the database is not supported. You should not attempt to manage WSUS in this way. Manage WSUS manually, by using the WSUS console, or programmatically, by calling WSUS APIs. Each WSUS server requires its own database. If there are multiple WSUS servers in your environment, you must have multiple WSUS databases. WSUS does not support multiple WSUS databases on a single computer running SQL Server. Selecting a Database Use the following information and the recommendations in Table 5-1 on the next page to determine what database software is right for your organization. Once you have made a selection, see if there are any additional tasks you need to complete to set up the database software to work with WSUS. You can use database software that is 100 percent compatible with Microsoft SQL. There are three options that have been tested extensively for use with WSUS: Microsoft Windows SQL Server 2000 Desktop Engine (WMSDE): This ships with WSUS. It is available only if you install WSUS on a computer running Windows Server It

150 134 Microsoft Windows Server System Deployment Guide for Midsize Businesses is similar to the next option, SQL Server 2000 Desktop Engine (MSDE), but without limitations for database size or connections. Neither WMSDE nor MSDE has a user interface or tools. Administrators are meant to interact with these products through WSUS. This is the scenario that is described in this book. Microsoft SQL Server 2000 Desktop Engine (MSDE): This is available from Microsoft as a free download. It is based on SQL Server 2000, but has some built-in limitations that restrict performance and database size to 2 GB. Use MSDE if you are installing WSUS on a computer running Windows Microsoft SQL Server 2000: This is the full-featured database software from Microsoft. WSUS requires SQL Server 2000 with Service Pack 3a. If you use the full version of SQL Server, there are additional configuration considerations you must handle during planning. For the full deployment documentation, see the WSUS Web site at: Table 5-1 Operating System Windows Server 2003 Windows 2000 Server Database Software Recommendations by Operating System Database Authentication, Instance, and Database Name Regardless of which database software you use, you cannot use SQL authentication. WSUS supports only Windows authentication. If you choose WMSDE for the WSUS database, WSUS Setup creates an instance of SQL Server named server\wsus, where server is the actual name of the computer. With either database option, WSUS Setup creates a database named SUSDB. Determining Where to Store Updates Recommendation If you are installing WSUS on Windows Server 2003 and do not want to use SQL Server 2000, WMSDE is the recommended database software option. If you are installing WSUS on Windows 2000 and do not want to use SQL Server 2000, MSDE is the recommended database software option. Although metadata that describes what an update is useful for is stored in the WSUS database, the updates themselves are not. Think of updates as being logically divided into two parts: a metadata part that describes what the update is useful for, and the files required to install the update on a computer. Metadata includes end-user license agreements (EULAs) and is typically much smaller than the size of the actual update. Update storage is described in this section. You have two choices for where updates are stored. You can store updates on the local WSUS server or on Microsoft Update. The result for either option is outlined in the following sections.

151 Chapter 5: Installing and Configuring Windows Server Update Services 135 Local Storage You can store update files locally on the WSUS server. This saves bandwidth on your Internet connection, because client computers download updates directly from the WSUS server. This option requires enough disk space to store the updates you intend to download. There is a minimum requirement of 6 GB of hard disk space to store updates locally, but 30 GB is recommended. Local storage is the default option. This is the option used in the medium business IT scenario described in this book. Note The 30 GB recommendation is only an estimate based on a number of variables, such as the number of updates released by Microsoft for any given product, and how many products a WSUS administrator selects. Although 30 GB should work for most customers, a worstcase scenario might require more than 30 GB of disk space. If that should happen, the Microsoft Windows Server Update Services Operations Guide offers guidance on how to recover. This white paper is available on the Windows Server Update Services Web site at go.microsoft.com/fwlink/?linkid= Remote Storage If you want, you can store update files remotely on Microsoft servers. WSUS enables you to take advantage of Microsoft Update for the distribution of approved updates throughout your organization. This is particularly useful if most of the client computers connect to the WSUS server over a slow WAN connection but have high-bandwidth connections to the Internet, or if you have only a small number of client computers. Determining Bandwidth Options to Use for Deployment No matter the amount of network bandwidth available, WSUS offers features that allow you to shape the deployment to best fit your organization s needs. The decisions you make about how to synchronize with Microsoft Update have a dramatic effect on your bandwidth usage. Use the following sections to understand WSUS features for managing bandwidth. Deferring the Download of Updates WSUS offers you the ability to download update metadata at a different time from the update itself during synchronizations. In the configuration shown in Figure 5-3 on the next page, approving an update triggers the download of all the files used to install that particular update on a computer. This saves bandwidth and WSUS server disk space, because only updates that you approve for installation are downloaded in full to the WSUS server. You can test the files prior to deploying them on your network, and your client computers download the updates from the intranet. Microsoft recommends deferring the download of updates, because it makes optimal use of network bandwidth.

152 136 Microsoft Windows Server System Deployment Guide for Midsize Businesses Microsoft Update Figure Metadata downloaded on synchronize 2 Administrator approval 3 triggers download of updates Deferred downloads of updates WSUS Approved updates stored locally For bandwidth savings, deferring downloads is particularly useful in conjunction with a special approval setting that only detects whether client computers require an update. With this kind of approval, the WSUS server does not download the update, and clients do not install the update. Instead, clients just determine whether they need the update. If they do, they send an event to the WSUS server, which is recorded in a server report. If you see that your clients require updates that were approved for detection, you can then approve them for installation. This combination of deferring downloads and detection approvals allows an administrator to download only the updates required by the client computers that are connected to the WSUS server. WSUS allows you to automate this scenario by creating a rule on the WSUS server that automatically approves all new updates for detection. For more information about different types of approvals and creating automatic approval rules, see the Microsoft Windows Server Update Services Operations Guide. If you chose to store updates locally during the WSUS setup process, deferred downloads are enabled by default. You can change this option manually. Filtering Updates WSUS offers you the ability to choose only the updates your organization requires during synchronizations. You can limit synchronizations by language, product, and type of update. By default, WSUS downloads Critical and Security Updates for all Windows products in every language. Microsoft recommends that you limit languages to only those you need, to conserve bandwidth and disk space. To change product and update classification options, see Selecting Products and Classifications later in this chapter. Using Express Installation Files The express installation files feature is an update distribution mechanism. You can use express installation files to limit the bandwidth consumed on your local network, but at the cost of bandwidth consumption on your Internet connection. By default, WSUS does not use express installation files. To better understand the tradeoff, you first have to understand how WSUS updates client computers. Updates typically consist of new versions of files that already exist on the computer being updated. On a binary level, these existing files might not differ very much from updated versions. The express installation files feature is a way of identifying the exact bytes that change between different versions of files, creating and distributing updates that include just these

153 Chapter 5: Installing and Configuring Windows Server Update Services 137 differences, and then merging the original file with the update on the client computer. Sometimes this is called delta delivery because it downloads only the difference, or delta, between two versions of a file. When you distribute updates by using this method, it requires an initial investment in bandwidth. Express installation files are larger than the updates they are meant to distribute. This is because the express installation file must contain all the possible variations of each file it is meant to update. The upper part of Figure 5-4 depicts an update being distributed by using the express installation files feature; the lower part of the illustration depicts the same update being distributed without using the express installation files feature. With express installation files enabled, you incur an initial download three times the size of the update. However, this cost is mitigated by the reduced amount of bandwidth required to update client computers on the corporate network. With express installation files disabled, your initial download of updates is smaller, but whatever you download must then be distributed to each of the clients on your corporate network. Express installation files enabled Microsoft Update ~300mb WSUS ~30mb Express installation files disabled Microsoft Update ~100mb WSUS ~100mb Figure 5-4 Express installation files feature The file sizes in the Figure 5-4 are for illustrative purposes only. Each update and express installation file varies in size, depending on what files need to be updated. Further, the size of each file actually distributed to clients by using express installation files varies depending upon the state of the computer being updated. Important Although there are some variables with express installation files, there are also some things you can count on. For example, express installation files are always bigger in size than the updates they are meant to distribute. As far as bandwidth goes, it is always less expensive to distribute updates by using express installation files. Not all updates are good candidates for distribution through express installation files. If you select this option, you obtain express installation files for any updates being distributed this way. If you are not storing updates locally, you cannot use the express installation files feature. By default, WSUS does not use express installation files.

154 138 Microsoft Windows Server System Deployment Guide for Midsize Businesses Background Intelligent Transfer Service WSUS uses Background Intelligent Transfer Service 2.0 (BITS) for all its file-transfer tasks, including downloads to clients and server synchronizations. BITS is a Microsoft technology that allows programs to download files by using spare bandwidth. BITS maintains file transfers through network disconnections and computer restarts. For more information about BITS, see the BITS documentation on the MSDN site at go.microsoft.com/fwlink /?LinkId= Determining Capacity Requirements Hardware and database software requirements are driven by the number of client computers being updated in your organization. Table 5-2 offers guidelines for server hardware and database software, for 500 or fewer client computers. A WSUS server using the recommended hardware can support a maximum number of 15,000 clients. Table 5-2 Hardware Recommendations for 500 or Fewer Clients Requirement Minimum Recommended CPU 750 MHz 1 GHz or faster RAM 512 MB 1 GB Database WMSDE/MSDE WMSDE/MSDE Installing WSUS This section offers instruction for installing Microsoft Windows Server Update Services (WSUS) on Microsoft Windows Server 2003 operating systems (except for Web Edition and all 64-bit versions). If you have a server running Microsoft Windows 2000 Server and need more information, see the Deploying Microsoft Windows Server Update Services white paper at go.microsoft.com/fwlink/?linkid= Configuring the Firewall Between the WSUS Server and the Internet If there is a corporate firewall between WSUS and the Internet, you might need to configure that firewall to ensure that WSUS can obtain updates. To obtain updates from Microsoft Update, the WSUS server uses port 80 for HTTP and port 443 for HTTPS. This is not configurable. If your organization does not allow those ports and protocols to be open to all addresses, you can restrict access to only the following domains so that WSUS and Automatic Updates can communicate with Microsoft Update:

155 Chapter 5: Installing and Configuring Windows Server Update Services Note The previous steps for configuring the firewall are meant for a corporate firewall positioned between WSUS and the Internet. Because WSUS initiates all its network traffic, there is no need to configure Windows Firewall on the WSUS server. Although the connection between Microsoft Update and WSUS requires ports 80 and 443 to be open, you can configure multiple WSUS servers to synchronize with a custom port. The following are the baseline installation requirements for installations that use the default options. You can find hardware and software requirements for other installations in the Deploying Microsoft Windows Server Update Services white paper at go.microsoft.com /fwlink/?linkid= Software Requirements To install WSUS with default options, you must have the following installed on your computer: Microsoft Internet Information Services (IIS) 6.0. Microsoft.NET Framework 1.1 Service Pack 1 for Windows Server 2003 Background Intelligent Transfer Service (BITS) 2.0. BITS 2.0 for Windows Server 2003 is not available from the Download Center at this time. To obtain this software, go to the Microsoft Web site for Windows Server Update Services Open Evaluation at go.microsoft.com/fwlink/?linkid= Note Although database software is required to install WSUS, it is not listed here because the default WSUS installation on Windows Server 2003 includes Windows SQL Server 2000 Desktop Engine (WMSDE) database software.

156 140 Microsoft Windows Server System Deployment Guide for Midsize Businesses For more information about WSUS software requirements, see the Deploying Microsoft Windows Server Update Services white paper at go.microsoft.com/fwlink/?linkid= If any of these updates require restarting the computer when installation is completed, you should restart your server prior to installing WSUS. Installing and Configuring IIS Before installing WSUS, make sure you have Internet Information Services (IIS) installed. By default, WSUS uses the default Web site in IIS. WSUS Setup also gives you the option of creating a Web site on a custom port. If the IIS service (W3SVC) is stopped during WSUS installation, WSUS Setup starts the service. Likewise, if you install WSUS to the default Web site and the site is stopped, WSUS Setup starts it. To install IIS on Windows Server Click Start, point to Control Panel, and then click Add or Remove Programs. 2. Click Add/Remove Windows Components. 3. In the Components list, click Application Server. 4. Click OK, click Next, and then follow the instructions on the screen. IIS Lockdown Tool The information about the IIS Lockdown Tool can vary depending upon whether you are using Windows Server 2003 or Windows 2000 Server. No matter which operating system you use, if you decide to use the IIS Lockdown Tool on a server running WSUS and you use the URLScan tool, you must edit the Urlscan.ini file to allow *.exe requests. After you edit this file, you must restart both IIS and the WSUS server. You can find the Urlscan.ini file in the \WINNT\System32\Inetserv\Urlscan folder on the boot drive of your computer. To edit the Urlscan.ini file 1. Open Urlscan.ini in a text editor. 2. Remove exe from the [DenyExtensions] section. 3. Ensure that the following settings appear in the [AllowVerbs] section: GET HEAD POST OPTIONS

157 Chapter 5: Installing and Configuring Windows Server Update Services 141 Windows Server 2003 and IIS Lockdown Tool You do not need to run the IIS Lockdown Tool on computers running Windows Server 2003, because the functionality is built into that operating system. Windows 2000 Server and IIS Lockdown Tool If you are running IIS on a server running Windows 2000 Server, download and install the latest version of the IIS Lockdown Tool from Microsoft TechNet at go.microsoft.com/fwlink /?LinkId= WSUS Setup does not install this tool. Microsoft strongly recommends that you run the IIS Lockdown Wizard to help keep your servers running IIS secure. The IIS Lockdown Wizard turns off unnecessary features, thereby reducing vulnerability to attackers. If you install the IIS Lockdown Tool and the URLScan tool on a server running WSUS, you must also read and perform the steps in the following sections. When IIS Lockdown is installed on Windows 2000, it denies Execute permissions to %windir% folder, which then causes an error in the WSUS administrative console. To recover from this error, you must manually grant Read and Execute permissions to %windir%\microsoft.net\framework\v \csc.exe. For more information, see the Knowledge Base article on the Microsoft Support site at go.microsoft.com/fwlink/?linkid= Client Self-Update WSUS uses IIS to automatically update most client computers to the WSUS-compatible Automatic Updates software. To accomplish this, WSUS Setup creates a virtual directory named Selfupdate, under the Web site running on port 80 of the computer where you install WSUS. This virtual directory, called the self-update tree, contains the WSUS-compatible Automatic Updates software. The earlier Automatic Updates software included with SUS can only update itself if it finds the self-update tree on a Web server running on port 80. Disk Requirements and Recommendations To install WSUS, the file system of the server must meet the following requirements: Both the system partition and the partition on which you install WSUS must be formatted with the NTFS file system. A minimum of 1 GB free space is required for the system partition. A minimum of 6 GB free space is required for the volume where WSUS stores content; 30 GB is recommended. A minimum of 2 GB free space is required on the volume where WSUS Setup installs Windows SQL Server 2000 Desktop Engine (WMSDE).

158 142 Microsoft Windows Server System Deployment Guide for Midsize Businesses Automatic Updates Requirements Automatic Updates is the client component of WSUS. Automatic Updates has no hardware requirements other than being connected to the network. You can use Automatic Updates with WSUS on computers running any of the following operating systems: Microsoft Windows 2000 Professional with Service Pack 3 (SP3) or Service Pack 4 (SP4), Windows 2000 Server with SP3 or SP4, or Windows 2000 Advanced Server with SP3 or SP4 Microsoft Windows XP Professional, with or without Service Pack 1 or Service Pack 2 Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; or Windows Server 2003, Web Edition Installing WSUS on Your Server After reviewing the installation requirements, you are ready to install WSUS. You must log on to the server on which you plan to install WSUS with an account that is a member of the local Administrators group. Only members of the local Administrators group can install WSUS. The following procedure uses the default WSUS installation options for Windows Server 2003, which include installing Windows SQL Server 2000 Desktop Engine (WMSDE) for the WSUS database software, storing updates locally, and using the IIS default Web site on port 80. You can find procedures for custom installation options, such as using Windows 2000, different database software, or a Web site using a custom port number, or performing an unattended installation in the Deploying Microsoft Windows Server Update Services white paper at go.microsoft.com/fwlink/?linkid= Important Use Add or Remove Programs in Control Panel to remove any previous beta builds of Windows Update Services (WUS) before installing the latest beta build of Windows Server Update Services (WSUS). To install WSUS on Windows Server Double-click the installer file WSUSSetup.exe. Note The latest version of WSUSSetup.exe is available on the Microsoft Web site for Windows Server Update Services at go.microsoft.com/fwlink/?linkid= On the Welcome page of the wizard, click Next.

159 Chapter 5: Installing and Configuring Windows Server Update Services Read the terms of the license agreement carefully, click I accept the terms of the License Agreement, and then click Next. 4. On the Select Update Source page, you can specify where clients get updates. If you select the Store updates locally check box, updates are stored on the WSUS server and you select a location in the file system to store updates. If you do not store updates locally, client computers connect to Microsoft Update to get approved updates. 5. Keep the default options, and click Next. 6. On the Database Options page, you select the software used to manage the WSUS database. By default, WSUS Setup offers to install WMSDE if the computer you are installing to runs Windows Server If you cannot use WMSDE, you must provide a SQL Server instance for WSUS to use, by clicking Use an existing database server on this computer and typing the instance name in the SQL instance name box. For more information about database software options besides WMSDE, see the Deploying Microsoft Windows Server Update Services white paper at go.microsoft.com/fwlink/?linkid= Keep the default options, and click Next. 7. On the Web Site Selection page, you specify the Web site that WSUS will use. This page also lists two important URLs based on this selection: the URL to which you will point WSUS client computers to get updates, and the URL for the WSUS console where you will configure WSUS. If you already have a Web site on port 80, you might need to create the WSUS Web site on a custom port. For more information about running WSUS on a custom port, see the Deploying Microsoft Windows Server Update Services white paper at go.microsoft.com/fwlink/?linkid= Keep the default option, and click Next. 8. On the Mirror Update Settings page, you can specify the management role for this WSUS server. If this is the first WSUS server on your network or you want a distributed management topology, skip this screen. If you want a central management topology, and this is not the first WSUS server on your network, select the check box, and type the name of an additional WSUS server in the Server name box. For more information about management roles, see the Deploying Microsoft Windows Server Update Services white paper at go.microsoft.com/fwlink /?LinkId= Keep the default option, and click Next. 9. On the Ready to Install Windows Server Update Services page, review the selections and click Next. 10. If the final page of the wizard confirms that WSUS installation was successfully completed, click Finish.

160 144 Microsoft Windows Server System Deployment Guide for Midsize Businesses Configuring WSUS Server After installing WSUS, you are ready to access the WSUS console in order to configure WSUS and get started. By default, WSUS is configured to use Microsoft Update as the location to obtain updates. If you have a proxy server on your network, use the WSUS console to configure WSUS to use the proxy server. If there is a corporate firewall between WSUS and the Internet, you might need to configure the firewall to ensure that WSUS can obtain updates. Note Although you must have Internet connectivity to download updates from Microsoft Update, WSUS offers you the ability to import updates onto networks not connected to the Internet. For more information, see the Deploying Microsoft Windows Server Update Services white paper at go.microsoft.com/fwlink/?linkid= To open the WSUS console 1. On your WSUS server, click Start, point to All Programs, point to Administrative Tools, and then click Microsoft Windows Server Update Services. Note You must be a member of either the WSUS Administrators or the local Administrators security groups on the server on which WSUS is installed in order to use the WSUS console. 2. If you do not add Web site name> to the list of sites in the Local Intranet zone in Internet Explorer on Windows Server 2003, you might be prompted for credentials each time you open the WSUS console. 3. If you change the port assignment in IIS after you install WSUS, you need to manually update the shortcut on the Start menu. 4. You can also open the WSUS console from Internet Explorer on any server or computer on your network by entering the following URL: To specify a proxy server 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. In the Proxy server box, select the Use a proxy server when synchronizing check box, and then type the proxy server name and port number (port 80 by default) in the corresponding boxes.

161 Chapter 5: Installing and Configuring Windows Server Update Services If you want to connect to the proxy server by using specific user credentials, select the Use user credentials to connect to the proxy server check box, and then type the user name, domain, and password of the user in the corresponding boxes. If you want to enable basic authentication for the user connecting to the proxy server, select the Allow basic authentication (password in clear text) check box. 4. Under Tasks, click Save settings, and then click OK in the confirmation dialog box. Selecting Products and Classifications After you specify the proxy server, you are ready to select the products you want to update and the types of updates you want to download. There is a description of why you might want to do this in Filtering Updates, earlier in this chapter. To specify update products and classifications for synchronization 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. In the Products and Classifications box, under Products, click Change. 3. In the Add/Remove Products box, under Products, select the products or product families for the updates you want your WSUS server to download, and then click OK. 4. Under Update classifications, click Change. 5. In the Add/Remove Classifications box, under Classifications, select the update classifications for the updates you want your WSUS server to download, and then click OK. Note You might have to do an initial synchronization to get some products to appear in the list of product classifications. Synchronizing the WSUS Server After you select products and update classifications, you are ready to synchronize WSUS. The synchronization process involves downloading updates from Microsoft Update or another WSUS server. WSUS determines whether any new updates have been made available since the last time you synchronized. If this is the first time you are synchronizing the WSUS server, all of the updates are made available for approval. To synchronize your WSUS server 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. Under Tasks, click Synchronize now. After the synchronization is complete, you can click Updates on the WSUS console toolbar to view the list of updates.

162 146 Microsoft Windows Server System Deployment Guide for Midsize Businesses Configuring Advanced Synchronization Options Advanced synchronization features include various options to manage bandwidth and store updates. There is a description of each of these features, including reasons why these features are useful, and their limitations, in Determining Where to Store Updates and Determining Bandwidth Options to Use for Deployment earlier in this chapter. Update Storage Options Use the Update Files section to determine whether updates will be stored on WSUS or client computers will connect to the Internet to get updates. There is a description of this feature in Determining Where to Store Updates, earlier in this chapter. To specify where updates are stored 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. Under Update Files and Languages, click Advanced, read the warning, and click OK. 3. If you want to store updates in WSUS, in the Advanced Synchronization Options dialog box, under Update Files, click Store update files locally on this server. If you want clients to connect to the Internet to get updates, click Do not store updates locally; clients install updates from Microsoft Update. Deferred Downloads Options Use the Update Files section to determine whether updates should be downloaded during synchronization or when the update is approved. Find a description of this feature in Deferring the Download of Updates in Determine Bandwidth Options to Use for Deployment earlier in this chapter. To specify whether updates are downloaded during synchronization or when the update is approved 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. Under Update Files and Languages, click Advanced, read the warning, and then click OK. 3. If you want to download only metadata about the updates during synchronization, in the Advanced Synchronization Options dialog box, under Update Files, select the Download updates to this server only when updates are approved check box. If you want to update files and metadata during synchronization, clear the check box. Express Installation Files Options Use the Update Files section to determine whether express installation files should be downloaded during synchronization. This feature is described in Using Express Installation Files earlier in this chapter.

163 Chapter 5: Installing and Configuring Windows Server Update Services 147 To specify whether express installation files are downloaded during synchronization 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. Under Update Files and Languages, click Advanced, read the warning, and then click OK. 3. If you want to download express installation files, in the Advanced Synchronization Options dialog box, under Update Files, select the Download express installation files check box. If you do not want express installation files, clear the check box. Filtering Updates Options Use the Languages section to select the language of the updates to synchronize. There is a description of this feature in Filtering Updates in the Determining Bandwidth Options to Use for Deployment section earlier in this chapter. To specify language options 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. Under Update Files and Languages, click Advanced, read the warning, and then click OK. 3. In the Advanced Synchronization Options dialog box, under Languages, select one of the following language options, and then click OK. Download only those updates that match the locale of this server (Locale): where Locale is the name of the server locale. This means that only updates targeted to the locale of the server will be downloaded during synchronization. Download updates in all languages, including new languages: This means that all languages will be downloaded during synchronization. If a new language is added, it will be automatically downloaded. Download updates only in the selected languages: This means that only updates targeted to the languages you select will be downloaded during synchronization. If you choose this option, you must also choose each language you want from the list of those available. Note If you change language options on the WSUS server used to administer a group of replica WSUS servers, you can create a situation where the number of updates approved on the centrally managed server do not match the number of approved updates on the replica servers. This is by design. To avoid this situation, manually synchronize language options. Updating and Configuring Automatic Updates WSUS client computers require a compatible version of Automatic Updates. WSUS Setup automatically configures IIS to distribute the latest version of Automatic Updates to each client computer that contacts the WSUS server.

164 148 Microsoft Windows Server System Deployment Guide for Midsize Businesses Note Although most versions of Automatic Updates can be pointed to the WSUS server and they will automatically self-update to the WSUS-compatible version, the version of Automatic Updates included with Windows XP without any service packs cannot update itself automatically. If you have Windows XP without any service packs in your environment, and you have never used Software Update Services (SUS), see the Deploying Microsoft Windows Server Update Services white paper at go.microsoft.com/fwlink/?linkid=24384 for instruction. The best way to configure Automatic Updates depends upon your network environment. In an Active Directory environment, you can use an Active Directory-based Group Policy object (GPO). In a non-active Directory environment, use the Local Group Policy object. Whether you use the Local Group Policy object or a GPO stored on a domain controller, you must point your client computers to the WSUS server, and then configure Automatic Updates. The following instructions assume that your network runs Active Directory. These procedures also assume that you have already set up and are familiar with Group Policy and use it to manage your network. You need to create a new Group Policy object (GPO) for WSUS settings, and link the GPO on the domain level. For more information about Group Policy, see the Group Policy page at go.microsoft.com /fwlink/?linkid= For more detailed information about WSUS policies, see the section To configure the Automatic Updates Setting on the Domain Controller OU in Chapter 9. This section contains the following procedures: Load the WSUS Administrative Template. Configure Automatic Updates. Point client computers to your WSUS server. Manually initiate detection on the client computer. Perform the next three procedures on an Active Directory-based Group Policy object. To add the WSUS Administrative Template 1. In Group Policy Object Editor, click either of the Administrative Templates nodes. 2. On the Action menu, click Add/Remove Templates. 3. Click Add. 4. In the Policy Templates dialog box, click wuau.adm, and then click Open. 5. In the Add/Remove Templates dialog box, click Close. To configure the behavior of Automatic Updates 1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.

165 Chapter 5: Installing and Configuring Windows Server Update Services In the details pane, double-click Configure Automatic Updates. 3. Click Enabled, and then click one of the following options: Notify for download and notify for install: This option notifies a logged-on administrative user prior to the download and installation of the updates. Auto download and notify for install: This option automatically begins downloading updates and then notifies a logged-on administrative user prior to installing the updates. Auto download and schedule the install: If Automatic Updates is configured to perform a scheduled installation, you must also set the day and time for the recurring scheduled installation. Allow local admin to choose setting: With this option, the local administrators are allowed to use Automatic Updates in Control Panel to select a configuration option of their choice. For example, they can choose their own scheduled installation time. Local administrators are not allowed to disable Automatic Updates. 4. Click OK. Note The setting Allow local admin to choose setting only appears if Automatic Updates has updated itself to the version compatible with WSUS. To point the client computer to your WSUS server 1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update. 2. In the Details pane, double-click Specify intranet Microsoft update service location. 3. Click Enabled, and type the HTTP URL of the same WSUS server in the Set the intranet update service for detecting updates box and in the Set the intranet statistics server box. For example, type in both boxes. 4. Click OK. Note If you are using the Local Group Policy object to point this computer to WSUS, this setting takes effect immediately and this computer should appear in the WSUS administrative console in about 20 minutes. You can speed this process up by manually initiating a detection cycle. After you set up a client computer, it will take a few minutes before it appears on the Computers page in the WSUS console. For client computers configured with an Active Directorybased GPO, it will take about 20 minutes after Group Policy refreshes (that is, applies any new settings to the client computer). By default, Group Policy refreshes in the background every

166 150 Microsoft Windows Server System Deployment Guide for Midsize Businesses 90 minutes, with a random offset of 0 to 30 minutes. If you want to refresh Group Policy sooner, you can go to a command prompt on the client computer and type gpupdate /force. For client computers configured with the Local GPO, Group Policy is applied immediately. The process will take about 20 minutes. Once Group Policy is applied, you can initiate detection manually. If you perform this step, you do not have to wait 20 minutes for the client computer to contact WSUS. To manually initiate detection by the WSUS server 1. On the client computer click Start, and then click Run. 2. Type cmd, and then click OK. 3. At the command prompt, type wuauclt.exe /detectnow. This command-line option instructs Automatic Updates to contact the WSUS server immediately. Creating a Computer Group One benefit of creating computer groups is that it enables you to test updates before deploying them widely. If the testing goes well, you can roll out the updates to the All Computers group. There is no limit to the number of custom groups you can create. Setting up computer groups is a three-step process: Specify how you are going to assign computers to the computer groups. There are two options: server-side targeting and client-side targeting. Server-side targeting involves manually adding each computer to its group by using WSUS. Client-side targeting involves automatically adding the clients by using either Group Policy or registry keys. Create the computer group on WSUS. Move the computers into groups by using whichever method you chose in the first step. This paper explains how to use server-side targeting and manually move computers to their groups by using the WSUS console. If you had numerous client computers to assign to computer groups, you could use client-side targeting, which would automate moving computers into computer groups. You can use these steps to set up a Test group that contains at least one test computer.

167 Chapter 5: Installing and Configuring Windows Server Update Services 151 To specify the method for assigning computers to groups 1. On the WSUS console toolbar, click Options, and then click Computer Options. 2. In the Computer Options box, click Use the Move computers task in Windows Server Update Services. 3. Under Tasks, click Save settings, and then click OK when the confirmation dialog box appears. To create a group 1. On the WSUS console toolbar, click Computers. 2. Under Tasks, click Create a computer group. 3. In the Group name box, type Test, and then click OK. Use the next procedure to assign a client computer appropriate for testing to the test group. A client computer appropriate for testing is any computer with software and hardware similar to the majority of computers on your network, but not a computer assigned to a critical role. In this way, you can tell how well the computers comparable to the test computer will fare with the updates you approve. To manually add a computer to the Test group 1. On the WSUS console toolbar, click Computers. 2. In the Groups box, click the group of the computer you want to move. 3. In the list of computers, click the computer you want to move. 4. Under Tasks, click Move the selected computer. 5. In the Computer group list, select the group you want to move the computer to, and then click OK. Deploying WSUS In this section, you approve an update for any test client computers in the Test group. Computers in the group will check in with the WSUS server over the next 24 hours. After this period, you can use the WSUS reporting feature to determine whether those updates have been deployed to the computers. If testing goes well, you can then approve the same update for the rest of the computers in your organization.

168 152 Microsoft Windows Server System Deployment Guide for Midsize Businesses To approve and deploy an update 1. On the WSUS console toolbar, click Updates. By default, the list of updates is filtered to show only Critical and Security Updates that have been approved for detection on client computers. Use the default filter for this procedure. 2. On the list of updates, select the updates you want to approve for installation. Information about a selected update is available on the Details tab. To select multiple contiguous updates, press and hold down the SHIFT key while selecting; to select multiple noncontiguous updates, press and hold down the CTRL key while selecting. 3. Under Update Tasks, click Change approval. The Approve Updates dialog box appears. 4. In the Group approval settings for the selected updates list, click Install from the list in the Approval column for the Test group, and then click OK. Note There are many options associated with approving updates, such as setting deadlines and uninstalling updates. These are discussed in the Microsoft Windows Server Update Services Operations Guide white paper at go.microsoft.com/fwlink/?linkid= After 24 hours, you can use the WSUS reporting feature to determine whether those updates have been deployed to the computers. To check the Status of Updates report 1. On the WSUS console toolbar, click Reports. 2. On the Reports page, click Status of Updates. 3. If you want to filter the list of updates, under View, select the criteria you want to use, and then click Apply. 4. If you want to see the status of an update by computer group and then by computer, expand the view of the update as necessary. 5. If you want to print the Status of Updates report, under Tasks, click Print report. If the updates were successfully deployed to the Test group, you can approve the same updates for the rest of the computers in your organization. Securing Your WSUS Deployment You can use the Secure Sockets Layer (SSL) protocol to secure your WSUS deployment. WSUS uses SSL to allow client computers and downstream WSUS servers to authenticate the WSUS server. WSUS also uses SSL to encrypt metadata passed between clients and downstream WSUS servers. Note that WSUS uses SSL only for metadata. This is also the way Microsoft Update distributes updates.

169 Chapter 5: Installing and Configuring Windows Server Update Services 153 As discussed earlier in this guide, updates consist of two parts: metadata that describes what an update is useful for, and the files to install the update on a computer. Microsoft mitigates the risk of sending update files over an unencrypted channel by signing each update. In addition to signing each update, a hash is computed and sent with the metadata for each update. When an update is downloaded, WSUS checks the digital signature and hash. If the update has been tampered with, it is not installed. Limitations of WSUS SSL Deployments There are two limiting issues that administrators considering WSUS SSL deployments need to know about. Securing your WSUS deployment with SSL increases the workload of the server. You should plan for about a 10 percent loss of performance because of the additional cost of encrypting all metadata sent over the wire. If you are using remote SQL, the connection between the WSUS server and the server running the database is not secured with SSL. If the database connection must be secured, consider the following recommendations: Put the database on the WSUS server (the default WSUS configuration). Put the remote SQL server and the WSUS server on a private network. Deploy Internet Protocol security (IPsec) on your network to secure network traffic. The Overview of IPsec Deployment page on the Microsoft Web site at go.microsoft.com/fwlink /?LinkId=41455 offers guidance on how to deploy IPsec in your environment. About Certification Authorities Setting up a Certification Authority (CA), binding a certificate to the WSUS Web site, and then bootstrapping client computers to trust the certificate on the WSUS Web site are complex administrative tasks. The step-by-step procedures for each task are beyond the scope of this guide. However, several articles on the subject are available. For more information and instructions on how to install certificates and set up your environment, see the following articles on the Microsoft Web site: Windows Server 2003 PKI Operations Guide on TechNet at go.microsoft.com/fwlink /?LinkId=17807 provides a guide for administrators on how to configure and operate a Windows Certification Authority. How To Set Up SSL on a Web Server on MSDN at go.microsoft.com/fwlink /?LinkId=41454 offers step-by-step instruction on setting up SSL on a Web site.

170 154 Microsoft Windows Server System Deployment Guide for Midsize Businesses Certificate Autoenrollment in Windows Server 2003 on TechNet at go.microsoft.com /fwlink/?linkid=17801 offers instruction on how to automatically enroll Windows XP client computers in Windows Server 2003 Enterprise environments integrated with Active Directory. Advanced Certificate Enrollment and Management on TechNet at go.microsoft.com /fwlink/?linkid=36239 offers guidance on how to automatically enroll client computers in other environments. Operating WSUS In this section, the operation of a simple WSUS deployment will be presented. Setting Up and Running Synchronizations During synchronization, your server running Windows Server Update Services (WSUS) downloads updates (update metadata and files) from an update source. When your WSUS server synchronizes for the first time, it will download all of the updates you specified when you configured synchronization options. After the first synchronization, your WSUS server determines whether any new updates have been made available since the last time it made contact with the update source, and then downloads only new updates. The Synchronization Options page is the central access point in the WSUS console for customizing how your WSUS server synchronizes updates. On this page, you can specify which updates are synchronized automatically, where your server gets updates, what the connection settings are, and when synchronizations are scheduled. After you synchronize updates to your WSUS server, you must then approve them before the WSUS server can perform any action for them. The exceptions to this rule are updates classified as Critical Updates and Security Updates, which are automatically approved for detection. Note Because WSUS initiates all its network traffic, there is no need to configure Windows Firewall on a WSUS server connected directly to Microsoft Update. Synchronizing Updates by Product and Classification Your WSUS server downloads updates based on the products or product families (for example, Windows, or Windows Server 2003, Datacenter Edition) and classifications (for example, Critical Updates or Security Updates) that you specify. At the first synchronization, your WSUS server downloads all of the updates available in the categories you have specified. At subsequent synchronizations, your WSUS server downloads only the newest updates (or changes to the updates already available on your WSUS server) in the categories you specified.

171 Chapter 5: Installing and Configuring Windows Server Update Services 155 You specify update products and classifications on the Synchronization Options page under Products and Classifications. Products are grouped in a hierarchy, by product family. (For more information about product families, see Products Updated by WSUS later in this chapter.) For example, if you select Windows, you automatically select every product that falls under that product hierarchy. By selecting the parent check box, you select not only all the items under it, but all future releases too. Selecting the child check boxes will not select the parent check boxes. The default setting for Products is All Windows Products, and for Update classifications, the default setting is Critical Updates and Security Updates. You must specify update classifications individually. If your WSUS server is running in replica mode, you will not be able to perform this task. To specify update products and classifications for synchronization 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. Under Products and Classifications, under Products, click Change. 3. In the Add/Remove Products dialog box, under Products, select the products or product families for the updates you want your WSUS server to synchronize, and then click OK. 4. Under Products and Classifications, under Update classifications, click Change. 5. In the Add/Remove Classifications dialog box, in Classifications, select the update classifications for the updates you want your WSUS server to synchronize, and then click OK. 6. Under Tasks, click Save settings, and then click OK. Note If you want to stop synchronizing updates for one or more specific products or product families, clear the appropriate check boxes in the Add/Remove Products dialog box, and then click OK. Your WSUS server will stop synchronizing new updates for the products you have cleared. However, updates that were synchronized for those products before you cleared them will remain on your WSUS server and will be available on the Updates page. Configuring Proxy Server Settings You can configure your WSUS server to use a proxy server during synchronization with an upstream server or Microsoft Update. In addition, you can specify a port number and whether you want your server to connect to the proxy server by using specific user credentials. You specify proxy server settings on the Synchronization Options page, under Proxy server. This setting will apply only when your WSUS server runs synchronizations. By default, this option is not enabled, and your WSUS server will connect directly to the upstream server or Microsoft Update. By default, the proxy server option is not selected, which means that your WSUS server will attempt to connect directly to another WSUS server or Microsoft Update during synchronization.

172 156 Microsoft Windows Server System Deployment Guide for Midsize Businesses Because WSUS initiates all of its network traffic, you do not need to configure Windows Firewall on a WSUS server connected directly to Microsoft Update. To specify a proxy server for synchronization 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. Under Proxy server, select the Use a proxy server when synchronizing check box, and then type the server name and port number (port 80 is the default) of the proxy server. If you want to connect to the proxy server by using specific user credentials, select the Use user credentials to connect to the proxy server check box, and then enter the user name, domain, and password of the user in the corresponding boxes. If you want to enable basic authentication for the user connecting to the proxy server, select the Allow basic authentication (password in clear text) check box. 3. Under Tasks, click Save settings, and then click OK. Synchronizing Manually or Automatically You can either synchronize your WSUS server manually or specify a time for it to synchronize automatically on a daily basis. To synchronize your server manually 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. Under Schedule, click Synchronize manually. 3. Under Tasks, click Save settings, and then click OK. To synchronize your WSUS server immediately 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. Under Tasks, click Synchronize now. To set up an automatic synchronization schedule 1. On the WSUS console toolbar, click Options, and then click Synchronization Options. 2. Under Schedule, click Synchronize daily at, and then in the list, select the time you want synchronization to start each day. 3. Under Tasks, click Save settings, and then click OK. Managing Computers and Computer Groups In this section you will see how to manage client computers and computer groups.

173 Chapter 5: Installing and Configuring Windows Server Update Services 157 Managing Client Computers WSUS enables you to manage the entire process of updating your computers, including manually and automatically determining which updates they receive, specifying when the updates are installed, and monitoring the status of update deployment on your computers. The central access point in the WSUS console for managing computers is the Computers page, which displays a list of computers that have been configured to get updates from the WSUS server. The computers are displayed by computer group, and you can filter the computer list to a specific computer group. By selecting a computer in the list, you can view its properties, which include general details about the computer and the status of updates for it for example, the installation or detection status of an update for a particular computer. You can also manage computer groups on the Computers page, which includes creating the groups and assigning computers to them. For more information about managing computer groups, see Managing Computer Groups later in this chapter. Important You must first set up a client computer to contact the WSUS server before you can manage it from that server. Until you perform this task, your WSUS server will not recognize your client computer, and will not display it in the computer list on the Computers page. For more information about setting up a client computer, see Deploying Microsoft Windows Server Update Services at go.microsoft.com/fwlink/?linkid= Important A client computer can only be set to communicate with one WSUS server at a time. If you later change this setting and specify a different WSUS server, the client computer stops contacting the WSUS server specified earlier. However, the client computer will remain on the list of computers and in the computer groups specified on that earlier WSUS server. In addition, the original WSUS server will report the last time the client computer contacted it (which will be accurate it will be before the client computer stopped connecting to it). To stop the client computer from appearing on the WSUS server specified earlier, you must remove the computer from the WSUS server. Managing Computers on the Computers Page The following are common tasks you can perform on the Computers page. Before you can add a computer to a computer group, you must have created a computer group. For more information about creating computer groups, see Managing Computer Groups later in this chapter. To view the properties for a computer 1. On the WSUS console toolbar, click Computers. 2. In Groups, click the computer group to which the computer currently belongs. 3. In the list of computers, click the computer for which you want to view properties.

174 158 Microsoft Windows Server System Deployment Guide for Midsize Businesses 4. In the Properties pane, do either of the following: Click the Details tab for general information about the computer. Click the Status tab for approval and update status for the computer. To add a computer to a computer group 1. On the WSUS console toolbar, click Computers. 2. In Groups, click the computer group to which the computer currently belongs. 3. In the list of computers, click the computer that you want to move. 4. Under Tasks, click Move selected computer. 5. In the Computer group dialog box, click the computer group to which you want to move the computer, and then click OK. Note If your computer already belongs to a computer group, after you perform this task it will belong to the new computer group you specify and not to the earlier computer group. However, it will remain a member of the All Computers group. To remove a computer from a WSUS server 1. On the WSUS console toolbar, click Computers. 2. In Groups, click the computer group to which the computer currently belongs. 3. In the list of computers, click the computer you want to remove. 4. Under Tasks, click Remove the selected computer, and then click OK. Note After you perform this task, you will not be able to manage update distribution for the client computer on the WSUS console, nor will the client computer be able to receive updates from the WSUS server. Managing Computer Groups Windows Server Update Services (WSUS) enables you to target updates to groups of client computers. This capability can help you ensure that specific computers get the right updates at the most convenient times on an ongoing basis. For example, if all computers in one department of your organization have a specific configuration (such as all computers in the Accounting team), you can determine what updates those computers get, at what time, and then use WSUS reporting features to evaluate the success of update activity for that computer group. By default, each computer is already assigned to the All Computers group. Computers will also be assigned to the Unassigned Computers group until you assign them to another group.

175 Chapter 5: Installing and Configuring Windows Server Update Services 159 Regardless of the group to which you assign a computer, it will also remain in the All Computers group. A computer can be in only one other group in addition to the All Computers group. Depending on whether or not you want to automate the process, you can assign computers to computer groups by using one of two methods: server-side targeting or client-side targeting, depending on whether or not you want to automate the process. With server-side targeting, you use the Move the selected computer task on the Computers page to move one or more client computers to one computer group at a time. With client-side targeting, you use Group Policy or edit the registry settings on client computers to enable those computers to automatically add themselves into the computer groups. You must specify which method you will use by selecting one of the two options on the Computers Options page. Server-Side Targeting With server-side targeting, you use the WSUS console to both create groups and assign computers to the groups. Server-side targeting is an excellent option if you do not have many client computers to update and you want to move client computers into computer groups manually. To enable server-side targeting on your WSUS server, click the Use the Move computers task in Windows Server Update Services option on the Computers Options page. Client-Side Targeting With client-side targeting, you enable client-computers to add themselves to the computer groups you create in the WSUS console. You can enable client-side targeting through Group Policy (in an Active Directory network environment) or by editing registry entries (in a non- Active Directory network environment) for the client computers. When the client computers connect to the WSUS server, they will add themselves into the correct computer group. Client-side targeting is an excellent option if you have many client computers and want to automate the process of assigning them to computer groups. To enable client-side targeting on your WSUS server, click the Use Group Policy or registry settings on client computers option on the Computers Options page. To specify the method for assigning computers to groups 1. On the WSUS console toolbar, click Options, and then click Computer Options. 2. In Computer Options, do one of the following: If you want to create groups and assign computers through the WSUS console (server-side targeting), click Use the Move computers task in Windows Server Update Services. If you want to create groups and assign computers by using Group Policy or by editing registry settings on the client computer (client-side targeting), click Use Group Policy or registry settings on client computers. 3. Under Tasks, click Save settings, and then click OK.

176 160 Microsoft Windows Server System Deployment Guide for Midsize Businesses Managing Updates In this section you will see how to manage updates, including viewing and approving updates, testing and the storing of updates. Updates Overview An update is a patch or a full file replacement for software that is installed on a computer. Every update that is available on Microsoft Update is made up of two components: Metadata: Information about the update. For example, metadata supplies information for the properties of an update, thus enabling you to find out what the update is useful for. Metadata also includes end-user license agreements (EULAs). The metadata package downloaded for an update is typically much smaller than the actual update file package. Update files: The actual files required to install an update on a computer. How WSUS Stores Updates When updates are synchronized to your WSUS server, the metadata and update files are stored in two separate locations. Metadata is stored in the WSUS database. Update files can be stored either on your WSUS server or on Microsoft Update servers, depending on how you have configured your synchronization options. If you choose to store update files on Microsoft Update servers, only metadata is downloaded at the time of synchronization; you approve the updates through the WSUS console, and then client computers get the update files directly from Microsoft Update at the time of installation. For more information about your options for storing updates, see Deploying Microsoft Windows Server Update Services at go.microsoft.com/fwlink/?linkid= Managing Updates by Using WSUS The following is a general summary of how you manage updates by using WSUS. 1. Before configuring options in the WSUS console, determine an overall update management plan based on your network capabilities, company needs, and layout. Considerations might include the following: If and how you want to set up a hierarchy of WSUS servers. Which database to use to store update metadata (for example, MSDE, WMSDE, SQL Server 2000). What computer groups you want to create, and the method you will use to assign computers to them (for example, server-side or client-side targeting). Whether you want updates to synchronize automatically at a specific time.

177 Chapter 5: Installing and Configuring Windows Server Update Services Set synchronization options on the Options page, such as update source, product and update classification, language, connection settings, storage location, and automatic synchronization schedule. 3. Get the updates and associated metadata on your WSUS server through synchronization from either Microsoft Update or an upstream WSUS server, depending on the location you have specified for your update source. 4. Approve or decline updates by group from the Updates page. You can approve updates for either installation or detection only. For detection only, WSUS does not install updates, but instead checks computers in the groups you specified to see whether a specific update is needed. To get the result of the detection (or, in other words, to find out whether the update is needed), check the Status of Updates report. You can set a deadline for automatic installation or detection. For installation, you have the option of allowing users to install the updates themselves (if they are local administrators on their client computers). 5. Configure automatic approvals for either installation or detection (by classification and groups) in Options, on the Automatic Approvals page. If the installation and detection rules conflict, WSUS will use the installation rule. On this page, you can also configure whether you want to enable automatic approval of revisions to existing updates or approve revisions manually. If you choose to approve manually, your WSUS server will continue using the older version until you manually approve the revision. 6. Check the status of the updates on the Updates page or in the Status of Updates report. Update Products and Classifications Updates available on Microsoft Update are differentiated by product (or product family) and classification. Products Updated by WSUS A product is a specific edition of an operating system or application, for example Microsoft Windows Server 2003, Datacenter Edition. A product family is the base operating system or application from which the products are derived. An example of a product family is Microsoft Windows, of which Microsoft Windows Server 2003, Datacenter Edition is a member. On the Synchronization Options page under Products and Classifications, products are displayed in a hierarchy, under their product family. At this location on the WSUS console, you can select the products or product families for which you want your server to automatically synchronize updates. You can specify many products at once if they belong to the same product family, because by selecting a parent check box you also select all items under it. Selecting the child check boxes will not select the parent check boxes. For every selection, you also are automatically selecting future releases.

178 162 Microsoft Windows Server System Deployment Guide for Midsize Businesses Update Classifications Update classifications represent the type of update. For any given product or product family, updates could be available among multiple classifications (for example, Windows XP family Critical Updates and Security Updates). Table 5-3 lists examples of update classifications. Table 5-3 Update Classification Connectors Critical Updates Development Kits Drivers Feature Packs Guidance Security Updates Service Packs Tools Update Rollups Updates Viewing Updates Example of Update Classifications On the Updates page, you can do the following: Description Software components designed to support connection between software Broadly released fixes for specific problems addressing critical, nonsecurity related bugs Software to aid the writing of new applications that usually includes a visual builder, an editor, and a compiler Software components designed to support new hardware New feature releases usually rolled into products at the next release Scripts, sample code, and technical guidance designed to help in the deployment and use of a product or technology Broadly released fixes for specific products, addressing security issues Cumulative sets of all hotfixes, security updates, critical updates, and updates created since the release of the product Service packs might also contain a limited number of customer requested design changes or features. Utilities or features that aid in accomplishing a task or set of tasks. Cumulative set of hotfixes, security updates, critical updates, and updates packaged together for easy deployment A rollup generally targets a specific area, such as security, or a specific component, such as Internet Information Services (IIS). Broadly released fixes for specific problems addressing non-critical, non-security related bugs. View the list of updates. The list of updates displays updates that have been synchronized from the update source to your server running Windows Server Update Services (WSUS) and are available for approval. You can filter the list of updates by using criteria such as classifications and products, approval status, synchronization date, and text string. In addition, you can sort the list of updates by clicking the appropriate column heading in the list of updates title bar.

179 Chapter 5: Installing and Configuring Windows Server Update Services 163 View details, status, and revision history for each update. Approve updates for installation. Approve updates for detection. Decline updates. To view updates 1. On the WSUS console toolbar, click Updates. Updates are displayed in the list of updates. 2. To sort by additional information, download status, title, classification, release date, or approval status, click the appropriate column heading. To filter the list of updates displayed on the Updates page 1. On the WSUS console toolbar, click Updates. 2. Under View, select the appropriate criteria for your filter in the list boxes, and then click Apply. The list of updates will reflect your chosen criteria. The Text box, under View, enables you to enter text to search on the following criteria for an update: Title, Description, and Microsoft Knowledge Base (KB) article number. Each of these items is a property listed on the Details tab in the update properties. To view the properties for an update 1. On the WSUS console toolbar, click Updates. 2. In the list of updates, click the update for which you want to view properties. 3. In the Properties pane, click one of the tabs for the following information: The Details tab displays both general properties (for example, title, description, and release date) and installation information (for example, requirements for installation, including whether the update is uninstallable) about the update. In addition, the Details tab indicates whether the update supersedes or is superseded by another update. The Status tab displays download, approval, and installation status for the update by computer group. You can expand computer groups to see update status by computer. The Revisions tab displays revision information about the update, including general facts about the revision and approval status.

180 164 Microsoft Windows Server System Deployment Guide for Midsize Businesses Note You can perform this procedure on only one update at a time. If you select multiple updates, the first update selected will be displayed in the Properties pane. Approving Updates After updates have been synchronized to your server running Windows Update Server Services (WSUS), you must approve them to initiate a deployment action. When you approve an update, you are essentially telling WSUS what to do with it (your choices are Install, Detect only, Remove, or Decline). When approving an update, you specify a default approval setting for the All Computers group, and any necessary settings for each computer group in the Approve Updates dialog box. If you do not approve an update, its approval status remains Not approved and your WSUS server performs no action for the update. The exceptions to this are Critical Updates and Security Updates, which by default are automatically approved for detection after they are synchronized. The Updates page is the central access point in the WSUS console for approving updates. On the Updates page, you can specify the action you want WSUS to exercise for the update by computer group. You do this by selecting one of the options under Tasks. The following provides more information about the different approvals you can enable on the Updates page. If your WSUS server is running in replica mode, you will not be able to approve updates on your WSUS server. Approving Updates for Detection When you approve an update for detection, the update is not installed. Instead, WSUS checks whether the update is compliant with or needed by computers in the groups you specify for the Detect only approval option in the Approve Updates dialog box. The detection occurs at the scheduled time that the client computer communicates with the WSUS server. You can see the result of the detection either in the Status of Updates report or on the Updates page, by clicking the Status tab for a specific update. In either case, the information you need will appear in the Needed column, which represents the number of computers that have been detected as needing a particular update. If the client computer does not need the update, the number in Needed is zero. By default, Critical Updates and Security Updates are automatically approved for detection. To approve updates for detection 1. On the WSUS console toolbar, click Updates. 2. In the list of updates, click one or more updates that you want to approve for detection. 3. Under Update Tasks, click Change approval.

181 Chapter 5: Installing and Configuring Windows Server Update Services In the Approve Updates dialog box, verify that Approval is set to Detect only for the All Computers group. 5. If you want to set a different default approval setting for one or more groups, under Group approval settings for the selected updates, find the group(s) for which you want to set the special approval setting, and then, in the Approval column, select an approval setting. Approving Updates for Installation You can select one or multiple updates. If you select multiple updates, you can approve them for installation at once; you can also approve installation by computer group. This would be the Install approval option in the Approve Updates dialog box. In addition, when you specify this approval action, you can do one of the following: Use the settings on the client computers to determine when to install updates. When you select this option, users in the targeted computer group will receive a notification dialog box and an Automatic Updates icon on their taskbar when updates are ready to be installed on their computers. They can then install the updates immediately, or at a later time, by clicking the Automatic Updates icon. If you have configured Automatic Updates, either by Group Policy or locally, to notify the user before installation, these notifications will be offered to any non-administrator who logs onto the computer in the targeted computer group. Set a deadline for automatic installation. When you select this option, you set specific times and dates to install updates, overriding any settings on the client computers. In addition, you can specify a past date for the deadline if you want to run an approval action immediately (that is, when the client computers next contact the WSUS server). To approve updates for installation 1. On the WSUS console toolbar, click Updates. 2. In the list of updates, click one or more updates that you want to approve for installation. 3. Under Update Tasks, click Change approval. 4. In the Approve Updates dialog box, verify that Approve is set to Install for the All Computers group. 5. To specify how and when the update will be installed for computers in the computer group, next to Deadline, click None, and then click one of the following options: If you want to enable users to determine when to install the updates, click Let users choose when to install the updates, and then click OK. If you have configured Automatic Updates, either by Group Policy or locally, to notify the user before installation, these notifications will be offered to any non-administrator who logs onto the computer in the targeted computer group.

182 166 Microsoft Windows Server System Deployment Guide for Midsize Businesses If you want the update to be installed automatically, click Install the update by the selected date and time, specify the date and time of the deadline, and then click OK. If you want the install to occur immediately (that is, when the client computers next contact the WSUS server), you can specify a past date for the deadline. If you want to set a different default approval setting for one or more groups, under Group approval settings for the selected updates, find the group(s) for which you want to set the special approval setting, and then, in the Approval column, click an approval setting. Declining Updates This option is available as a task under Update Tasks on the Updates page. If you select this option, the update is removed from the list of available updates. Declined updates will appear in the updates list only if you select either Declined or All updates in the Approval list when specifying the filter for the update list under View. To decline updates 1. On the WSUS console toolbar, click Updates. 2. In the list of updates, click one or more updates that you want to decline. 3. In Update Tasks, click Decline update or Decline selected updates, depending on whether you have selected one or multiple updates to decline. Approving Updates for Removal You can approve an update for removal (that is, approve uninstalling the update). This option is only available if the update supports uninstalling, and you would choose the Remove approval option in the Approve Updates dialog box. You can specify a deadline for the update to be uninstalled, as well as specify a past date for the deadline if you want to run an approval action immediately (that is, when the client computers next contact the WSUS server). To approve updates for removal 1. On the WSUS console toolbar, click Updates. 2. In the list of updates, click one or more updates that you want to approve for removal. 3. Under Update Tasks, click Change approval. 4. In the Approve Updates dialog box, verify that Approve is set to Remove for the All Computers group. 5. If you want to set a deadline for the update(s) to be automatically detected, next to Deadline, click None, specify the date and time for the deadline, and then click OK. If you want the update removal to occur immediately (that is, when the client computers next contact the WSUS server), you can specify a past date for the deadline.

183 Chapter 5: Installing and Configuring Windows Server Update Services If you want to set a different default approval setting for one or more groups, under Group approval settings for the selected updates, find the group(s) for which you want to set the special approval setting, and then, in the Approval column, click an approval setting. Approving Updates Automatically On the Automatic Approval Options page, you can configure your WSUS server to automatically approve installation or detection for updates and associated metadata when they are downloaded to the WSUS server during synchronization. This is different from approving updates on the Updates page, where, by default, updates are approved for detection. You can configure automatic approval for updates by update classifications and groups. If the installation and detection rules you set conflict, your WSUS server will follow the installation rules. On the Automatic Approval Options page, you can also select an option to automatically approve revisions to existing updates as they become available. This option is selected by default. A revision is a version of an update that has had changes made to it (for example, it might have expired, or UI text, the EULA, or applicability rules for computers might have changed). If you do not choose to automatically approve the revised version of an update, WSUS will use the older version, and you must manually approve the update revision. Automatically Approving Updates for Detection When you select this option, you can create a rule that your WSUS server will automatically apply during synchronization. For the rule, you specify what updates you want to automatically approve for detection, by update classification and by computer group. This applies only to new updates, as opposed to revised updates. This setting is available on the Automatic Approval Options page. On this page, you can also set a rule for automatically approving updates for installation. In the event that rules conflict (for example, you have specified the same update classification and same computer group combination in both the rule to automatically approve for detection and automatically approve for installation), then your WSUS server applies the rule to automatically approve for installation. To automatically approve updates for detection 1. On the WSUS console toolbar, click Options, and then click Automatic Approval Options. 2. In Updates, under Approve for Detection, select the Automatically approve updates for detection by using the following rule check box (if it is not already selected). 3. If you want to specify update classifications to automatically approve during synchronization, do the following.

184 168 Microsoft Windows Server System Deployment Guide for Midsize Businesses a. Next to Classifications, click Add/Remove Classifications. b. In the Add/Remove Classifications dialog box, select the update classifications that you want to automatically approve, and then click OK. 4. If you want to specify the computer groups for which to automatically approve updates during synchronization, do the following: a. Next to Computer groups, click Add/Remove Computer Groups. b. In the Add/Remove Computer Groups dialog box, select the computer groups for which you want to automatically approve updates, and then click OK. 5. Under Tasks, click Save settings, and then click OK. Automatically Approve Updates for Installation When you select this option, you can create a rule that your WSUS server will automatically apply during synchronization. For the rule, you specify what updates you want to automatically approve for installation, by update classification and by computer group. This applies only to new updates, as opposed to revised updates. This setting is available on the Automatic Approval Options page. On this page, you can also set a rule for automatically approving updates for detection. In the event that rules conflict (for example, you have specified the same update classification and same computer group combination in both the rule to automatically approve for installation and automatically approve for detection), your WSUS server applies the rule to automatically approve for installation. To automatically approve updates for installation 1. On the WSUS console toolbar, click Options, and then click Automatic Approval Options. 2. In Updates, under Approve for Installation, select the Automatically approve updates for installation by using the following rule check box (if it is not already selected). 3. If you want to specify update classifications to automatically approve during synchronization, do the following: a. Next to Classifications, click Add/Remove Classifications. b. In the Add/Remove Classifications dialog box, select the update classifications that you want to automatically approve, and then click OK. 4. If you want to specify the computer groups for which to automatically approve updates during synchronization, do the following: a. Next to Computer groups, click Add/Remove Computer Groups.

185 Chapter 5: Installing and Configuring Windows Server Update Services 169 b. In the Add/Remove Computer Groups dialog box, select the computer groups for which you want to automatically approve updates, and then click OK. 5. Under Tasks, click Save settings, and then click OK. Automatically Approving Revisions to Updates The Automatic Approval Options page contains an option to automatically approve revisions to existing updates as they become available. This option is selected by default. A revision is a version of an update that has changes (for example, it might have expired, or have an updated EULA, UI text, or applicability rules for computers). If you configure your WSUS server to automatically approve new revisions of an update but an expired revision for the update is synchronized, your WSUS server will automatically decline the update. If you choose not to automatically approve the revised version of an update, your WSUS server will use the older revision, and you must manually approve the update revision. To automatically approve revisions to updates 1. On the WSUS console toolbar, click Options, and then click Automatic Approval Options. 2. Under Revisions to Updates, click Automatically approve revisions of existing updates during synchronization. 3. Under Tasks, click Save settings, and then click OK. Approving Superseding or Superseded Updates Typically, an update that supersedes other updates does one or more of the following: Enhances, improves, and/or adds to the fix provided by one or more previously released updates. Improves the efficiency of its update file package, which is installed on client computers if the update is approved for installation. For example, the superseded update might contain files that are no longer relevant to the fix, or to the operating systems now supported by the new update, so those files are not included in the superseding update's file package. Updates newer versions of operating systems. Be aware that the superseding update might not support earlier versions of operating systems. Conversely, an update that is superseded by another update does the following: Fixes a similar vulnerability to the update that supersedes it. However, the update that supersedes it might enhance the fix that the superseded update provides. Updates earlier versions of operating systems in some cases these versions of operating systems are no longer updated by the superseding update.

186 170 Microsoft Windows Server System Deployment Guide for Midsize Businesses In the list of updates on the Updates page, an icon next to the update indicates that it has a supersedure relationship to another update. The Details tab in the properties for the update tells you whether the update supersedes or is superseded by another update. In addition, you can determine which updates supersede or are superseded by the update by looking at the Supersedes and Superseded by entries. The Properties box for the update is available at various locations in the WSUS console (for example, on the Updates page, on the Computers page). WSUS does not automatically decline superseded updates, and it is recommended that you do not assume that superseded updates should be declined in favor of the new, superseding update. Before declining a superseded update, make sure that it is no longer needed by any of your client computers. Following are examples of scenarios where you might need to install a superseded update: If a superseding update supports only newer versions of an operating system, and some of your client computers run earlier versions of the operating system. If a superseding update has more restricted applicability than the update it supersedes, which would make it inappropriate for some client computers. If an update no longer supersedes a previously released update due to new changes. It is possible that through changes at each release, an update no longer supersedes an update it previously superseded in an earlier version. In this scenario, you will still see a message on the Details tab for the superseded update that it has been superseded, even though the update that supersedes it has been replaced by an update that does not. Recommended Process for Approving a Superseding Update Because a superseding update typically enhances a fix provided by a previously released, superseded update, it is recommended that you first see how many client computers will be compliant with the new update, and work backward from there. Use the following process. To approve a superseding update 1. Approve the superseding update for Install on all computers where the fix provided by the update is appropriate. 2. Check the resulting status of the approval action on your computers. Note which computers show status as Not needed for the update, and then compare the properties of those computers with the properties of the update. 3. Use the information available in the update properties to help you determine which previously released versions of the update are available. For example, look under Supersedes on the Details tab, and check the Description and KB article number entries if appropriate. 4. Get information about the superseded, previously released versions of the updates; for example, view their properties.

187 Chapter 5: Installing and Configuring Windows Server Update Services When you find a superseded update that seems appropriate for the remaining client computers, approve the update for installation. 6. Repeat this process until all of your client computers are updated with the intended fix. Approving Office Updates There are three broad ways to install Microsoft Office, each of which has its own method: Directly from CD or CD image: You run Setup.exe (or the MSI) from the CD image, pick your options, and install on a single computer. When you use this method, you must supply the Office PID each time you install. Updates to Office using this approach are manual (the user can navigate to the Office Update site and select updates to install), or can be handled by WSUS. An Administrative install: You run setup using the /A switch, which loads all of Office onto a server share. From this server share, users can run setup to install Office on their individual computers. When you use this approach, you supply the PID when running setup /a. Users can then install directly from the server share, without having to specify the PID. Patching in this environment is more difficult, as noted later. Using Local Installation Source: This is a new method, added with Office With this option, you copy the CD image (which is highly compressed) to a server share. Users can just run setup to install Office, which is in effect the same as the first option. However, you can modify the setup.ini files, to specify an Installer Transform, which can customize the specify options added. Updating this type of installation is the same as for direct installations, manually or through WSUS. Using LIS and MSI transforms is now the preferred way to deploy Office 2003 in corporate environments, and is easy to update, as previous noted. Although it is a bit more difficult, you can update administrative installations of Office by using WSUS. Updating Administrative Installations of Office via WSUS Each update to Office is an.msp file that you can obtain from WSUS. These updates are either: A full file (FF) *.msp (Microsoft Installer patch) in this option, whole files are contained in the MSP and are replaced on the user s file system. A delta patch this is an.msp file that represents a simple change from the original file. The delta patch is therefore much smaller. By moving to delta patching, Microsoft can significantly reduce the size of the update, thus making updating much quicker. However, in order to use delta patching, the update tool must have access to the original source file. This is why the LIS option is now preferred.

188 172 Microsoft Windows Server System Deployment Guide for Midsize Businesses With delta patching: The delta is downloaded and the installation is attempted. If the installation fails because the needed baseline isn t installed, Automatic Updates will attempt to use the source, if available. If the source isn t present, such as a CD not in the drive or a UNC path that is not available, or if the source is of the wrong baseline, Automatic Updates will fail with a special error code. When Automatic Updates fails with this special error code, the next time it attempts to provide this update, it will use the FF *.map file, which won t fail for this reason, because it doesn t need a baseline to successfully install. Testing Updates Until you install an update, you cannot be certain about the impact it will have on the existing code running on your systems. By installing an update in a test environment before deploying it to your production environment, you can analyze and assess its impact before it has the opportunity to harm your production systems. This can prevent unplanned downtime and lost productivity. WSUS enables you to create custom computer groups, which you can use to test updates. For example, Figure 5-5 depicts three computer groups: two custom groups created by the administrator (Test and Accounting), as well as the built-in All Computers group. In this example, the Test group contains a small number of computers representative of all the computers contained in the Accounting group. This creates a virtual test lab. The administrator can first approve updates for the Test group. If the testing goes well, the administrator can roll out the updates to the Accounting group. Microsoft Update Figure Metadata downloaded on synchronize 2 Administrator approval 3 triggers download of updates Using computer groups to test updates WSUS Approved updates stored locally You can expand this basic scenario to fit testing needs for your organization. For example, you can create multiple test computer groups that resemble actual computer groups containing computers with different configurations.

189 Chapter 5: Installing and Configuring Windows Server Update Services 173 Backing Up Windows Server Update Services Although WSUS does not provide a built-in backup tool, you can use the Backup Utility that is available on all servers running Windows 2000 or Windows Server 2003 to easily back up and restore both the WSUS database and update file storage folder. The Backup Utility is also known as Ntbackup.exe. Backing up WSUS involves backing up the following: The WSUS database, which contains: Update metadata, including information about updates (for example, properties). Metadata is also where EULAs are stored. WSUS server configuration information, which includes all settings for WSUS server (that is, options you specified through the WSUS console and settings configured by WSUS automatically during setup). Information about client computers, updates, and client interaction with updates. You can access this information through the WSUS console when you view status and run reports on update status and client computer status. The folder where the update files are stored. These update files are the actual files required to install an update on a computer. By default, update files are stored in the %systemdrive%\wsus\wsuscontent folder on your WSUS server. If you have chosen to store update files on Microsoft Update (either during setup or on the Options page), you do not have to back up the update file storage folder on your WSUS server. If you are using a full version of Microsoft SQL Server 2000 for your database, which is not installed by WSUS, you can use SQL Server Enterprise manager as an alternative to the Backup Utility. For more information about SQL Server Enterprise Manager, refer to your SQL Server documentation. For more information about database options and configurations for WSUS, see Deploying Microsoft Windows Server Update Services at go.microsoft.com /fwlink/?linkid= To back up the update file storage folder 1. On your WSUS server, click Start, and then click Run. 2. In the Open box, type %systemdrive%\%windir%\system32\ntbackup.exe, and then click OK. 3. In the Backup or Restore Wizard, click Next. 4. Verify that Back up files and settings is selected, and then click Next. 5. Click Let me choose what to back up, and then click Next. 6. Select the WSUSContent folder (under %systemdrive%\wsus\), and then click Next.

190 174 Microsoft Windows Server System Deployment Guide for Midsize Businesses 7. Use the Browse button to choose a place to save your backup, type a name for the backup, and then click Next. 8. If you want to set additional specifications for your backup, including whether it will be an incremental backup, whether you want to verify the backup, set a recurring backup schedule, or other options, click Advanced, and then follow the instructions in the wizard. 9. When the wizard is finished, click Finish. 10. When the message appears that informs you that the backup is complete, click Close. To back up the WSUS database 1. On your WSUS server, click Start, and then click Run. 2. In the Open box, type %systemdrive%\%windir%\system32\ntbackup.exe, and then click OK. 3. In the Backup or Restore Wizard, click Next. 4. Verify that Back up files and settings is selected, and then click Next. 5. Click Let me choose what to back up, and then click Next. 6. Under %systemdrive%\wsus\mssql$wsus\, select the Data and LOG folders, and then click Next. 7. Use the Browse button to choose a place to save your backup, type a name for the backup, and then click Next. 8. If you want to set additional specifications for your backup, including whether it will be an incremental backup, whether you want to verify the backup, set a recurring schedule for the backup, or other options, click Advanced, and then follow the prompts that appear in the wizard. 9. When the wizard is finished, click Finish. 10. When the message appears that informs you that the backup is complete, click Close. To restore the update file storage folder 1. On your WSUS server, click Start, and then click Run. 2. In the Open box, type %systemdrive%\%windir%\system32\ntbackup.exe, and then click OK. 3. In the Backup or Restore Wizard, click Next. 4. Click Restore files and settings, and then click Next. 5. In the What to restore dialog box, under Items to restore, expand the file that contains the WSUSContent folder (under %systemdrive%\wsus\), and then click Next.

191 Chapter 5: Installing and Configuring Windows Server Update Services 175 Alternatively, you can select a subset of the %systemdrive%\wsus\wsuscontent folder to restore. Within the %systemdrive%\wsus\wsuscontent folder, you can restore one, all, or a combination of its subfolders and files. 6. If you want to set additional specifications for your restore, including whether you want to restore the files or folders to a different location, replace existing files, restore security settings, or specify other options, click Advanced, and then follow the instructions in the wizard. 7. When the wizard is finished, click Finish. 8. When the message appears that informs you that restoring is complete, click Close. To restore the WSUS database 1. On your WSUS server, click Start, and then click Run. 2. In the Open box, type %systemdrive%\%windir%\system32\ntbackup.exe, and then click OK. 3. In the Backup or Restore Wizard, click Next. 4. Click Restore files and settings, and then click Next. 5. In the What to restore dialog box, under Items to restore, expand the file that contains the Data and LOG folders (under %systemdrive%\wsus\msql$wsus), and then click Next. Alternatively, you can select a subset of the %systemdrive%\wsus\msql$wsus \Data or %systemdrive%\wsus\msql$wsus\log folders to restore. Within the %systemdrive%\wsus\msql$wsus\data and %systemdrive%\wsus \MSQL$WSUS\LOG folders, you can restore one, all, or a combination of their subfolders and files. 6. If you want to set additional specifications for your restore, including whether you want to restore the files or folders to a different location, replace existing files, restore security settings, or specify other options, click Advanced, and then follow the instructions in the wizard. 7. When the wizard is finished, click Finish. 8. When the message appears that informs you that restoring is complete, click Close. Monitoring Windows Server Update Services In this section you will see the status terminology used in the WSUS console and how to run reports. Update Status Terminology You can access update status from various locations in the WSUS console. Table 5-4 defines each possible status that can be reported by WSUS for an update. Typically, WSUS presents

192 176 Microsoft Windows Server System Deployment Guide for Midsize Businesses update status for a particular computer (for example, the status of an update on one computer) or computer group (for example, status for the five computers in Computer Group X, on which the update has been installed). Table 5-4 Update Status Definitions Status Description Installed The update was installed on the computer. Needed This is the positive result of a Detect only approval. When referring to the status of one computer, Needed means the update is compliant with (and should be installed on) the computer. When referring to status for a computer group, the Needed column displays the number of computers in the group with which the update is compliant. Additionally, a positive Needed result means, technically, that as of the last time client computers made contact with the WSUS server, the update was determined to be compliant, but has not been installed. Therefore, it is possible that any of the following could be true when the status for an update is Needed: You have approved the update for installation but the client computers have not yet contacted the WSUS server since you made this change. You have not yet approved the update for installation, although the Detect only action has been performed. The update has already been downloaded and installed, but the client computer has not contacted the WSUS server since the update was installed. The update has already been downloaded and installed, but the update requires that the client computer be restarted before changes go into effect, and the client computer has not yet been restarted. The update has been downloaded to the computer but not installed. The update has been neither downloaded nor installed on the computer. Not needed This is the negative result of a Detect only approval. When referring to the status of one computer, Not needed means the update is not compliant with or required by that computer. When referring to the status for a computer group, the Not needed column displays the number of computers in the group for which the update is not compliant or required. Unknown Typically, this means that since the time that the update was synchronized to the WSUS server, the computer has not contacted the WSUS server. Failed An error occurred when either a detection or an installation was attempted on the computer for the update. Last contacted This is the date on which the computer last contacted the WSUS server. Running Reports Reports enable you to monitor the components of your Windows Server Update Services implementation.

193 Using the Reports Page Chapter 5: Installing and Configuring Windows Server Update Services 177 You can generate three main reports from the Reports page, as described in Table 5-5, and in the sections that follow. Table 5-5 Report Name Status of Updates Status of Computers Reports Available on Reports Page Synchronization Results Settings Summary Status of Updates Report Function View the status of all approved updates by computer group and computer. View the status of client computers and the status of updates on those computers (for example, a summary of updates that have been installed or are needed for a particular computer). View a list of new updates, update revisions, and errors that occurred during synchronization. View or print a summary of the settings configured through the Options page. The Status of Updates report enables you to view the status for all of your approved updates. You can view the report in three ways: you can view the status of an update at a high level, by computer group, and by computer. The report displays information resulting from the most recent contact between client computers and the WSUS server. The frequency with which client computers contact the WSUS server is configured through Group Policy. By default, this is every 22 hours. Unless you want to change the contact frequency for your client computers, generate this report the day after you approve updates, so that it reflects your latest approvals. For more information about configuring Group Policy, see Deploying Microsoft Windows Server Update Services at go.microsoft.com/fwlink/?linkid= Note You can use a command-line tool on client computers that are running the WSUS client software (Automatic Updates) in order to initiate contact between the client computer and WSUS server. This can be useful if you want to get immediate update status for a particular computer you can run this tool to force connection and then generate a Status of Updates report. To initiate immediate contact between a client computer and WSUS server 1. On the client computer, at the command prompt, type wuauclt.exe /detectnow, and then press ENTER. To run a Status of Updates report 1. On the WSUS console toolbar, click Reports. 2. On the Reports page, click Status of Updates.

194 178 Microsoft Windows Server System Deployment Guide for Midsize Businesses Update Summary View The Update Summary view is the default view that appears when you run a Status of Updates report. By default, the report displays an alphabetical list of approved updates. You can filter the display by both approval action and computer group by making appropriate selections under View and then clicking Apply. Your filter is reset to the default list of all updates when you close the Status of Updates report. The columns displayed in the Update Summary view are described in Table 5-6. Table 5-6 Description of Columns Displayed in Update Summary View Column Name Description Title The name of the update. To view the properties for an update, click an update in this column. The update properties box provides the following information: The Details tab contains general information about the update. The Status tab contains status information for the update by computer group. This is also what you see in Computer Group view. You can also expand this view into Computer view by expanding a computer group. The Revisions tab displays information about changes to the update. Installed The number of computers on which the update has been installed. Needed The number of computers for which the update is applicable but not installed. For these computers, a detect-only action has been performed for the update. If an update requires a restart, then a computer that has installed the update will continue to appear in the Needed column until it is restarted. Failed The number of computers that last reported a failed download, installation, or removal (uninstallation). Last Updated The date that the latest action for this update occurred. Computer Group View The Computer Group view displays the status of an update by computer group. To use this view, expand any update that is listed in Update Summary view. The columns displayed in the Computer Group view are described in Table 5-7. Table 5-7 Description of Columns Displayed in Computer Group View Column Name Description Computer Group The name of the computer group to which the update has been targeted. Approval The action that this update has been approved for, specific to the group. Deadline The deadline for the action, if you have set a deadline. Installed The number of computers on which the update has been installed. Needed The number of computers for which the update is applicable but not installed. For these computers, a detect-only action has been performed for the update. If an update requires a restart, a computer that has installed the update will continue to appear in the Needed column until it is restarted.

195 Chapter 5: Installing and Configuring Windows Server Update Services 179 Table 5-7 Description of Columns Displayed in Computer Group View Column Name Description Failed The number of computers that last reported a failed download, installation, or removal (uninstallation). Computer View The Computer view displays the status of each computer in a computer group. To use the Computer view, expand a computer group. The columns displayed in this view are described in Table 5-8. Table 5-8 Description of Columns Displayed in Computer View Column Name Description Computer Name Name of the computer To see the properties for the computer, click the computer name. The computer properties dialog box that appears displays details and status for the computer. The Status tab displays the result of the last communication between the WSUS server and the computer, and the status of updates for which an action has been approved on the computer. Status The status will be one of the following: Failed - The download, installation, or removal action for the update on this computer was not completed. Needed - The update is applicable but not installed. If an update requires a restart, a computer that has installed the update will continue to be counted as needed until it is restarted. Not needed - The update is not applicable. Installed - The update has been installed. Unknown - No action has been performed on the computer. To see details for an event, click the result in the Status column. Printing the Report You can print the report in Update Summary, Computer Group, or Computer view, depending on how you have expanded the Status of Updates report. To print the Status of Updates report 1. Expand your report into Update Summary, Computer Group, or Computer view, depending on the information you want to print. 2. Under Tasks, click Print report. Note You cannot use the Print report task to print a dialog box, and the Print report task is not enabled if a dialog box is open.

196 180 Microsoft Windows Server System Deployment Guide for Midsize Businesses Status of Computers Report The Status of Computers report provides both a cumulative and individual update status summary for computers in the computer group and for the update status results you specify. Table 5-9 provides more information about the status provided for each update. Table 5-9 Status Installed Needed Not Needed Unknown Failed Last Contacted Status Provided for Each Update Description The update was installed on the computer. A detection was performed on the computer for the update, which determined that the update should be installed on the computer. Either the update is already installed on the computer, or the update does not belong to a product or classification you specified when configuring synchronization options. Typically, this means that since the time that the update was synchronized to the WSUS server, the computer has not yet contacted the WSUS server. An error occurred when either a detection or an installation was attempted on the computer for the update. This is the date on which the computer last contacted the WSUS server. You can also print the report, including the list of individual updates with status for individual computers, if you have expanded the computers (clicked the + sign). However, you cannot print the dialog box that appears when you click individual updates in the list or when you click the status for an individual update. To run a Status of Computers report 1. On the WSUS console toolbar, click Reports, and then click Status of Computers. 2. Under View, select the criteria you want to use to filter the report, and then click Apply. The report displays a cumulative update status summary for all of the computers in the computer group and for the status you specified. 3. If you want more information about a specific computer, you can do the following: To view the status of individual updates for the computer, expand the computer (click the + sign next to the computer). In addition, you can see the properties of an individual update by clicking the title of the update. To view more information about the specific status result of an update (or the event details), click the status for the update. 4. To print the report, under Tasks, click Print report. Synchronization Results Report The Synchronization Results report enables you to see synchronization information for your server for a given time period, including errors that occurred during synchronization and a list of new updates. In addition, you can get general, status, and revision information for each new update.

197 Chapter 5: Installing and Configuring Windows Server Update Services 181 To run a Synchronization Results report 1. On the WSUS console toolbar, click Reports. 2. On the Reports page, click Synchronization Results. By default, the report displays synchronization results for the last 30 days. 3. To change the synchronization period for the report, under View, select another synchronization period in the list, and then click Apply. 4. To print the report, under Tasks, click Print report. Note The Print report task is not enabled if you have a dialog box open. You cannot use the Print report task to print a dialog box. The report has four components, which are described in Table Table 5-10 Components of Synchronization Results Report Component Name Purpose Last Synchronization Displays information about the last time the WSUS server synchronized with Microsoft Update or another WSUS server, and whether it was a successful synchronization. Synchronization Summary Displays summary information about new updates and errors that occurred during synchronization. Errors For each error, displays the date of the error, a description of the error, and the update ID associated with the error. New Updates Displays the updates that have been synchronized to the WSUS server for the given time period. You can view the properties for each new update by clicking the update in the New Updates list. The update properties dialog box that appears contains details, status, and revision for the update. It is identical to the update properties box that appears in the Status of Updates report when you click an update in the list. It is also identical to the properties tabs associated with each update on the Updates page. Settings Summary Report The Settings Summary report enables you to view and print a summary of all of the settings that can be specified on the Options page. To run a Settings Summary report 1. On the WSUS console toolbar, click Reports. 2. On the Reports page, click Settings Summary.

198 182 Microsoft Windows Server System Deployment Guide for Midsize Businesses Table 5-11 describes the components of the Settings Summary report. Table 5-11 Components of Settings Summary Report Component Name Synchronization Schedule Products and Classifications Update Source Proxy Server Update Files Languages Automatic Approval Revisions to Updates Downstream Servers Client Computer Options Database To print a Settings Summary report 1. Under Tasks, click Print report. Running Compliance Reports Purpose The time that your WSUS server automatically synchronizes with the update source. The update products and classifications that you want to synchronize with your server. The location from which the server synchronizes. The proxy server used during synchronization. The location where update files are stored (on the WSUS server or on Microsoft Update). Also, the download options you have selected. The languages for the updates that synchronize with the server. Only updates available in the languages specified are synchronized with the WSUS server. The automatic approval settings for specific update classifications, targeted by computer group. The approval action that your WSUS server will perform when revisions to existing updates are available; whether update revisions are automatically approved by your server, or whether they must be manually approved. The servers which receive updates from the WSUS server. The method you have selected for assigning computers to groups. The name of the database used by the WSUS server. You can view or print two types of compliance reports: one for individual computers and one for individual updates. To run a computer compliance report 1. On the WSUS console toolbar, click Computers, and then click the computer for which you want to produce the compliance report. 2. Click Print compliance report. 3. If you want more information about a specific update under Update Status, you can do the following: To view the properties of an individual update, click the title of the update. To view more information about the specific status result of an update (or the event details), click the status for the update.

199 Chapter 5: Installing and Configuring Windows Server Update Services To print the report, click the File menu, and then click Print. To run an update compliance report 1. On the WSUS console toolbar, click Updates, and then click the update for which you want to produce the compliance report. 2. Click Print compliance report. 3. To print the report, click the File menu, and then click Print. Troubleshooting WSUS There are a number of issues that can arise during the installation, deployment and management of WSUS. These can occur on the server, or on the client. For detailed guidance on troubleshooting, please see the extensive section on troubleshooting in the WSUS Operations Guide white paper at go.microsoft.com/fwlink/?linkid= Additional WSUS Resources For more information and support, see the following resources. Windows Server Update Services Communities References Microsoft communities are great places to exchange ideas with other users and discuss common issues. You can read and write messages by using an NNTP-based newsreader, such as Microsoft Outlook Express. You can also use the Web-based newsreader provided by Microsoft to access all of the newsgroups. To access the WSUS Communities, visit the Windows Server Update Services Public Newsgroup at For high-level information about what s new and features of WSUS, see Microsoft Windows Server Update Services Product Overview at serversystem/updateservices/evaluation/overview.mspx For step-by-step guidance for getting started, including installing WSUS, setting up a client computer, and deploying your first set of updates, see Step-by-Step Guide to Getting Started with Microsoft Windows Server Update Services at /downloads/details.aspx?familyid=3ba03939-a5a9-407b-a4b0-1290ba5182f8&displaylang=e

200

201 Chapter 6 Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition Microsoft Operations Manager (MOM) 2005 Workgroup Edition helps you manage your systems while keeping the cost of your operations under control. MOM 2005 a key component of the Microsoft Dynamic Systems Initiative (DSI) increases the manageability of your Microsoft Windows Server System infrastructure. By delivering operational knowledge and subject-matter expertise directly from the application developers, MOM 2005 Workgroup Edition simplifies the identification of issues, streamlines the process for determining the root cause of infrastructure and application problems, and facilitates the quick resolution of these problems. MOM 2005 Workgroup Edition is built for smaller, targeted Windows Server System based environments of 10 or fewer servers. It provides the type of event management, proactive monitoring and alerting, and systems and application knowledge that small to mid-sized businesses need to improve system availability and reduce operational costs. Planning MOM Deployment Take a few minutes to review the key concepts of MOM 2005 Workgroup Edition against your deployment design and planning documents before you begin installing the software on your host computer. Also, take a few minutes to look through the following software and hardware requirements and series of quick tips to help make the installation process more efficient. Software Requirements Take advantage of the Prerequisites Checklist provided by MOM 2005 Workgroup Edition to ensure that all software requirements are met before installing it. MOM 2005 Workgroup Edition requires a Windows Server 2003 operating system, Active Directory directory service, and Microsoft SQL Server 2000 Desktop Engine (MSDE) or SQL Server 2000 on the computer that will host the MOM server. For more information on MOM 2005 Workgroup Edition software requirements, go to 185

202 186 Microsoft Windows Server System Deployment Guide for Midsize Businesses Note Verify that all appropriate security updates, hotfixes, and service packs have been applied to the operating system and to applications that are required for deploying MOM 2005 Workgroup Edition components. You can do this by visiting the Microsoft Windows Update Web site at go.microsoft.com/fwlink/?linkid=1623. Hardware Requirements Take advantage of the Prerequisites Checklist provided by MOM 2005 Workgroup Edition to ensure that you meet all hardware requirements before installing it. Here are the minimum requirements for the MOM 2005 Workgroup Edition server: 550 MHz or higher Pentium-compatible processor 512 MB of RAM 5 GB of disk space The list of minimum hardware requirements does not take into consideration database size. Because either SQL Server or MSDE will be used, it is recommended that the MOM 2005 Workgroup Edition server have at least 1 GB of RAM. SQL Server can be memory intensive, particularly during high event generation. For more information on MOM 2005 Workgroup Edition hardware requirements, go to Preparing to Deploy MOM 2005 Workgroup Edition Before you begin deploying MOM 2005 Workgroup Edition, you need to make the following preparations: Verify service accounts. Determine security groups for the MOM Administrator console and Operator console. Install and configure MSDE or SQL Server Verifying Service Accounts MOM 2005 Workgroup Edition uses two primary service accounts: MOM uses the Management Server Action Account to run computer discovery, and can also use it to automatically install agents. The Management Server Action Account enables the MOM Management Server to communicate with, collect data from, and run actions on agentless-managed computers. The Management Server Action Account is

203 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 187 also used to collect data from the registry and event logs of the local computer on which the MOM Management Server is installed. This account must have three local policy rights to work properly: Log on as a service Log on locally Act as part of the operating system MOM uses the Agent Action Account to collect data from, and to run actions on, agentmanaged computers. Best Practices Microsoft recommends assigning different passwords to each service account for security reasons. Determining Security Groups for the MOM Administrator Console and Operator Console MOM 2005 Workgroup Edition uses Windows security groups to assign and control access privileges to various MOM functionalities. You can grant a user access to use the MOM consoles by adding a user s domain account to the appropriate MOM user group on the Management Server. Installing and Configuring MSDE or SQL Server 2000 Before installing MOM 2005 Workgroup Edition, you must first install and configure the database server that will be used to store application data. You can download MSDE from the Microsoft Download Center. MSDE is available at no charge, and installation instructions are included. If you choose to deploy SQL Server 2000, consider reviewing the Deploying SQL Server 2000 Project Guide, available at partner.microsoft.com/us/productssolutinos /projectguides/ , which provides detailed pre-installation and installation guidance on deploying new implementations of SQL Server Keep the following notes in mind to ensure that you install and configure the database server correctly: An existing remote SQL Server cannot be used as the database server for MOM 2005 Workgroup Edition. The database must be installed on the same machine as the MOM 2005 Workgroup Edition server components.

204 188 Microsoft Windows Server System Deployment Guide for Midsize Businesses Install MSDE or SQL Server 2000 by using the Local System account. You might optionally use a service account created explicitly for this purpose. Because of security concerns, do not use a user account as a service account. User accounts might be subject to policy-driven password expirations, which can cause MSDE or SQL Server to stop functioning. In addition, security privileges might inadvertently get altered if group membership or other rights are modified for a user account. SP3a must be applied. If you install MSDE or SQL Server 2000 by using media that does not have SP3a pre-installed, you can download SP3a from the following location on the Microsoft Download Center ( Configure database authentication for Windows Only. Verify that both the SQL Server (MSSQLSERVER) and the SQL Server Agent (SQLSERVERAGENT) services are started and configured to start automatically when the computer starts. Building and Deploying MOM The scenario used in this chapter includes the option of monitoring the server environment by using MOM 2005 Workgroup Edition, and installing it on the management server (as explained in Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server 2003 ), which is the server that is also running Windows Server Update Services, Windows SharePoint Services, and RIS. Because MOM 2005 Workgroup Edition allows the monitoring of up to 10 computers, and the scenario as presented in Chapter 2 assumes an edge server running ISA, two core infrastructure servers, and the management server, MOM 2005 Workgroup Edition is clearly the appropriate solution for monitoring in this environment. Even if you decide to put Microsoft Exchange Server 2003 on a separate server and also put File and Print services on a separate server, you will still be able to use the following configuration. Installing MOM 2005 Workgroup Edition There are three types of MOM 2005 Workgroup Edition installations: full server install, manual agent install, and console-only install. The first step to complete is the full server install, which installs MOM 2005 Workgroup Edition components, after which you can establish Computer Discovery rules and then install agents remotely. The manual agent install is used where pushed-agent installation is not possible, such as in instances that involve firewalls and non-domain machine agent installations. Finally, after the basic MOM 2005 Workgroup Edition installation is complete, additional Administrator and Operator consoles can be set up on other computers in the console-only install.

205 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 189 Installing MOM 2005 Workgroup Edition Components The following steps outline the process for installing MOM 2005 Workgroup Edition components. Before beginning installation: Ensure that the IIS and Microsoft World Wide Web Publishing Service are both running. Use an account with domain administrator credentials to log on to the computer where you want to install MOM. Close all open applications. To start installation 1. On the MOM 2005 Workgroup Edition software CD, double-click Setup.exe to open the Microsoft Operations Manager Setup Resources dialog box. On the Setup Tasks tab, you will see the three installation steps. 2. If you have not yet checked the computer for prerequisites, click Check Prerequisites, choose Complete, and then click Check. Address any prerequisites before continuing. 3. Click Install MOM 2005 Workgroup Edition to start the MOM 2005 Workgroup Edition Setup Wizard. 4. On the Welcome screen, click Next. 5. Read the terms of the license agreement. Select I accept the terms in the license agreement, and then click Next. 6. Enter the customer name, organization name, and 25-digit license key, and then click Next. 7. Change the installation folder, if desired, and then click Next. 8. The setup program verifies the prerequisites automatically. If your computer does not meet the prerequisites, you must address the identified issues before continuing. 9. On the SQL Server page, select the server instance from the SQL Server database instance list on which you want to install the MOM database. 10. On the Management Server Action Account page, enter the account that you want the Management Server to use. If you are using this account to install agents on remote computers, it must have administrative privileges on each target computer. As an alternative to using this highly privileged account, you can configure the Management Server Action Account to be a low privileged account and to install MOM agents by using the procedure described in Configuring MOM 2005 Workgroup Edition later in this chapter.

206 190 Microsoft Windows Server System Deployment Guide for Midsize Businesses 11. On the MOM Error Reporting page, you can select Enable error reporting. If you want MOM to automatically send service error reports to Microsoft, enable error reporting. It is recommended that you use the default Automatically send error reports to Microsoft option. If you select the Queue error reports and let me approve sending them to Microsoft option, MOM stores error reports on the computer where they occur. The next time your customer logs on to that computer, a dialog box appears from which the customer can send the accumulated reports. For more information about error reporting, see the Microsoft Data Collection Policy Web site at oca.microsoft.com/en /dcp20.asp. Note The computer must have Internet access in order to be able to send error reports. 12. On the Ready to Install page, click Install to complete the wizard. 13. Click Configure MOM 2005 Workgroup Edition to open the Administrator console and start configuring MOM 2005 Workgroup Edition. Note If you install the MOM 2005 Workgroup Edition Web console on a domain controller, the Web console might not function properly because of access rights on the computer. To remedy the problem, you need to add an ACL entry for the NETWORK_SERVICE and grant NETWORK_SERVICE full access right to the %Systemroot%\Microsoft.NET\Framework \v \temporary ASP.NET Files folder. Configuration Best Practices Regardless of the specific deployment of MOM 2005 Workgroup Edition, the amount of data that is generated during operations is limited due to the restrictions that MOM 2005 Workgroup Edition has on the number of managed servers and on the number of management groups. Use the following guidance to configure MOM 2005 Workgroup Edition for maximum responsiveness and the best performance. To configure the MOM Operator console refresh rate 1. On the Operator console File menu select Console Settings. 2. In the Console Settings dialog box, set Refresh data at the following interval to 30. To configure the Management Server 1. In the Administrator console, expand Administration, and then click Global Settings. 2. In the details pane, right-click Management Servers, and then click Properties. 3. In the Management Servers Properties dialog box, click the Heartbeat Checking tab.

207 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition Set Interval to scan for agent heartbeats to Set Number of scans before generating service unavailability to 2. To configure agents 1. In the Administrator console, expand Administration, and then click Global Settings. 2. In the details pane, right-click Agents, and then click Properties. 3. In the Agents Properties dialog box, click the Agent Heartbeat tab. 4. Set Heartbeat interval to 5. Limiting the Number of Consoles in MSDE Deployments Using MSDE with MOM 2005 Workgroup Edition cannot support as many concurrent console sessions as if it were deployed with SQL Server For best performance when MOM 2005 Workgroup Edition is deployed with MSDE, ensure that no more than three console sessions are active at the same time. The active console sessions can include any combination of Administrator, Operator, or Web consoles. Activating additional consoles can invoke the MSDE Workload Governor, which might cause a reduction in performance, and the system might generate warning messages notifying a user that it is too busy to perform requested operations. Setting Up Additional MOM Administrator Consoles and Operator Consoles A MOM Administrator console and a MOM Operator console are installed by default on the Management Server during setup. You can install additional Administrator and Operator consoles on other computers and use these consoles to remotely connect to the Management Server. On any computer where you want to install an Administrator console and an Operator console, it is recommended that you set the display resolution to with 24-bit color. To install the Administrator and Operator consoles 1. Log on by using an account that has administrative credentials on the local computer. 2. Close all open applications. 3. On the MOM 2005 Workgroup Edition software CD, double-click Setup.exe. 4. In the Microsoft Operations Manager 2005 Setup Resources dialog box, click the Custom Installs tab. 5. Click Install MOM 2005 Workgroup Edition UI Consoles to start the installation. 6. Wait for the progress indicator to indicate that the installation is complete.

208 192 Microsoft Windows Server System Deployment Guide for Midsize Businesses Note For retail customers, this install process might fail due to a missing product key. Therefore, retail customers need to type the following at a command line: Msiexec /i [location of MOMServer.msi] /qn ADDLOCAL="MOMXUI" PIDKEY=[CDKey provided with acquisition of MOM 2005 Workgroup Edition] After the installation is complete, you can open the Administrator console or the Operator console in one of two ways: Navigating back to the Setup Tasks tab in Setup and clicking Configure MOM 2005 Workgroup Edition. Opening the console from the Start menu. When starting a console for the first time, you are prompted for the Management Server name. MOM 2005 Workgroup Edition has only one Management Server; therefore you will not need to enter any additional server names. Configuring MOM 2005 Workgroup Edition Following server installation, install MOM agents on the computers that will be monitored and managed. The agent deployment process involves the following stages: Identifying and creating a record of the computers that your customer wants to manage Preparing the event logs on managed computers for running MOM agents Configuring the MOM Management Server settings for agent deployment Creating Computer Discovery rules Initiating Computer Discovery Installing agents Confirming that agents are installed and being properly managed Identifying Computers to Manage The first step in the MOM configuration process is to identify and make a record of the computers that your customer wants to manage with MOM 2005 Workgroup Edition. Each of these computers must meet the managed computer requirements listed in Software Requirements and Hardware Requirements earlier in this chapter. Increasing the Size of Log Files on Target Computers To reliably manage the state of a computer, MOM must be able to retrieve the latest events from the event logs of the computer. If an event log on a managed computer fills up, then

209 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 193 event logging can stop or events could be overwritten, depending on how that event log is configured for this condition. It is important to note that if event logging stops, MOM cannot pick up the latest events until the log has been manually cleared and new events are being logged. If MOM cannot pick up the latest events, important information about the state of health for the computer might not be reported. Also, note that if the Security log fills up, the managed computer can become locked. For more information, see the Microsoft Knowledge Base article located at go.microsoft.com/fwlink/?linkid= For computers on which you plan to install a MOM agent, it is recommended that you increase the size of the following logs: Windows event logs Service event logs, such as Directory Service, File Replication, and DNS Application logs, such as IIS log files This helps to ensure that the log files on the managed computers do not fill up too quickly and stop logging events. For the Application, System, and Security logs, it is recommended that you increase the maximum log size to at least 25 MB. It is also a best practice to configure Windows logs to Overwrite events as needed. With this option, when the log is full, it can continue to log new events, with each new event replacing the oldest event. Note that configuring the Security log to overwrite events as needed might result in the loss of some security events. Ensure that you determine your customer s policies regarding security event logging and follow these when configuring logs. You should also adjust the log sizes depending on the role of the computer and the available disk space. You might need to increase the log size further under the following circumstances: Your customer wants to preserve and review data over a longer time period. The computer is running an application that generates a high volume of data. The computer is a domain controller. The computer has a large amount of available disk space. To modify Windows event log settings for agent-managed computers: 1. On the Start menu, point to Programs, point to Administrative Tools, and then click Event Viewer. 2. Right-click the event log that you want to modify settings for: Application, Security, or System. 3. Click Properties, modify the settings, and then click OK.

210 194 Microsoft Windows Server System Deployment Guide for Midsize Businesses Configuring the Management Server Before you begin creating Computer Discovery rules, it is important that you review and configure certain Management Server settings as appropriate for your customer. To learn more about the settings recommended in this section, refer to the MOM 2005 Security Guide at Configuring Automatic Agent Installation By default, the global setting for the Management Server is not to install, uninstall, or upgrade agents automatically during computer discovery. Instead, MOM adds these computers to the Pending Actions folder. You can then approve the computers on which you want to install, uninstall, or upgrade an agent. You can override this setting in MOM 2005 Workgroup Edition by following these steps: 1. In the MOM Administrator console, expand Administration, expand Computers, and then click Management Servers. 2. In the details pane, right-click the Management Server for which you want to change the global setting, and then click Properties. 3. On the Automatic Management tab, clear the Use global settings check box, and then click Automatically install, uninstall, and upgrade agents. Note If you are going to use Automatic Management, the Management Server Action Account must be an administrator on each of the computers that will host a MOM agent. Configuring Mutual Authentication For greater security, MOM 2005 Workgroup Edition gives you the option of requiring mutual authentication, which means that the Management Server and agents must authenticate one another before communicating. Mutual authentication requires a two-way Active Directory trust relationship between the Management Server and all agents in the management group. By default, for a new installation of MOM in an Active Directory environment, mutual authentication is enabled. You can change the setting during initial setup if you do not want to require mutual authentication. You should confirm this setting before deploying MOM 2005 Workgroup Edition agents. This setting must be the same on both the Management Server and the agents or the agents will not be able to communicate with the Management Server. You can find this setting on the Failover tab on the properties dialog box for the Management Server in the MOM Administrator console under Administration/Computers/Management Servers/<Management Server name>.

211 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 195 Configuring for Manually Installed Agents By default, the global setting for the Management Server is to reject new manually installed agents. This prevents unauthorized agents from being installed automatically or from being inadvertently approved for installation and then sending harmful data to the Management Server. Mutual authentication must be enabled for this setting to block new manually installed agents. If you typically use mutual authentication but need to install agents manually, you can temporarily change this setting. After you have installed agents manually, it is recommended that you re-enable the setting to reject new manually installed agents. To configure MOM 2005 Workgroup Edition for manual agent installation 1. In the MOM Administrator console, expand Administration, and then click Global Settings. 2. In the details pane, select Management Servers. 3. On the Agent Install tab, clear the Reject new manual agent installations check box. 4. Select Global Settings again from the Administration pane, choosing the Global Settings option. 5. Select the Security tab, and clear the Mutual Authentication Required field. 6. Right-click the Management Pack folder, and then click Commit Configuration Change. 7. Restart the MOM Service on the Management Server. Creating Computer Discovery Rules After you have configured the Management Server settings as appropriate, the next step is to direct MOM to discover computers by creating Computer Discovery rules. You can create Computer Discovery rules by specifying one or more computer names or by specifying search criteria. Creating Computer Discovery rules that use search criteria provides the greatest flexibility for defining ranges of computers to include or exclude during computer discovery. For example, you might create a Computer Discovery rule to include all computers that have names containing specific letters, or one to exclude all domain controllers from being discovered by MOM. There are several Computer Discovery rule properties that you can specify when creating a Computer Discovery rule, as described in the following topics.

212 196 Microsoft Windows Server System Deployment Guide for Midsize Businesses Rule Type When you create a Computer Discovery rule by using the Install/Uninstall Agents Wizard, the rule type is set to Include by default and you cannot change it on the Computer Discovery Rule property dialog box. When you create a Computer Discovery rule by using the Computer Discovery Rule property dialog box on the Administrator console, the options for this property are Include or Exclude. In addition to creating Computer Discovery rules to include specific targeted computers, you can also create Computer Discovery rules to exclude specific computers. If changes to the properties for a Computer Discovery rule result in excluding agent-managed computers that were previously included, MOM continues to manage these computers until the agent is uninstalled. Computer Discovery rules that exclude computers always override Computer Discovery rules that include computers, and Computer Discovery rules that exclude computers always override computers in the ManualMC.txt file (typically used in larger networks). Domain Name You can leave this field blank; however, it is recommended that you specify a domain name to expedite computer discovery. You can specify a Fully Qualified Domain Name (FQDN), for example domain.corp.company.com, or you can specify a NetBIOS domain name. A NetBIOS name cannot exceed 15 characters. Computer Name You can specify a single computer name by using the default equals operator, or you can use the other available operators, such as contains substring or matches wild card, to define a range of computer names. You can use the matches regular expression operator or the matches Boolean regular expression operator and insert additional operators, such as Any Character or Character in Range, to build more complex expressions. Computer Type The options for this property are Servers, Clients, or Servers and Clients. If you specify either Servers or Clients, MOM must contact each targeted computer to determine its role. This can cause the discovery process to take longer. If you do not need to limit your search, select Servers and Clients to expedite the discovery process.

213 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 197 Initial Management Mode There are three management modes in MOM 2005 Workgroup Edition: Agent-managed: This is the primary management mode. With this mode, a MOM agent is installed on the managed computer. The agent collects data, runs responses on the local computer, and communicates with the Management Server. Agentless-managed: For computers that do not support a MOM agent (for example, Microsoft Windows NT 4.0 computers), MOM 2005 Workgroup Edition provides an agentless-managed mode for a limited number of computers. With this mode, the Management Server collects data and runs responses on the agentless-managed computers. Unmanaged: MOM does not perform any management or monitoring functions for computers with this management mode. MOM assigns this management mode to computers on which you have uninstalled the agent, or for computers on which you have stopped the agentless-managed management mode. When you create a Computer Discovery rule by using the Install/Uninstall Agents Wizard, the initial management mode is set to Agent-managed by default and cannot be changed. When you create a Computer Discovery rule by using the Computer Discovery Rule property dialog box, you can choose which management mode you want MOM to apply to the computer upon its initial discovery. Important The management mode that you specify in a Computer Discovery rule is applied to managed computers only when MOM initially discovers matching computers. If you change the management mode in a Computer Discovery rule, the new management mode is applied only to newly discovered computers. The management mode for computers previously discovered by that Computer Discovery rule is not changed. However, you can change the management mode for a computer after MOM has discovered it. If you include a computer in more than one Computer Discovery rule and the management modes for the Computer Discovery rules conflict, MOM applies the least privileged of the management modes. MOM determines the privilege levels of the management modes in the following order: 1. Unmanaged (least privileged) 2. Agentless-managed 3. Agent-managed (most privileged)

214 198 Microsoft Windows Server System Deployment Guide for Midsize Businesses Applying Computer Discovery Rules to Domain Controllers By default MOM does not discover or install agents on domain controllers. If you want a Computer Discovery rule to be applied to domain controllers, you must select this check box. This setting can also be used to create a Computer Discovery rule that excludes all domain controllers from being discovered. Contacting Computers During Computer Discovery to Verify Existence It is recommended that you do not contact each computer to verify that it exists during computer discovery. If you choose to contact each computer during computer discovery to verify its existence, this can substantially slow down the computer discovery process. When you create a Computer Discovery rule and you specify NetBIOS computer names without specifying a domain name, MOM must contact each computer during computer discovery to verify its existence. If you specify a domain name for the Computer Discovery rule, it is recommended that you clear this check box as Active Directory can provide verification. Initiating Computer Discovery When you run the Install/Uninstall Agents Wizard, the Management Server automatically initiates a limited computer discovery. In this case, MOM discovers and immediately installs agents on all computers that match the newly created Computer Discovery rules. MOM does not look for new computers that match existing Computer Discovery rules during this limited computer discovery. Full Computer Discovery MOM initiates a full computer discovery automatically on a periodic schedule. You can also initiate a full computer discovery on demand. During a full computer discovery, MOM performs the following actions: Gathers information from all existing Computer Discovery rules and searches the network for matching computers. Adds the name and domain of new matching computers to the MOM database. Checks the setting for automatic agent installation to determine if agents should be installed immediately on newly discovered computers or if the computers should be placed in the Pending Actions folder for approval. Checks for any computers that have approved agent installation, agent upgrade, agent update, or agent uninstallation-pending tasks. Initiates agent installation/uninstallation/update/upgrade for the appropriate computers.

215 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 199 After each full computer discovery, MOM performs a separate process to add the computers to the appropriate computer groups. When MOM discovers new computers that match existing Computer Discovery rules for which the specified management mode is agent-managed, one of the following actions occurs: If the Management Server is configured to not install new agents automatically (the default setting), MOM adds the computers to the Pending Actions folder in the MOM Administrator console. You must approve any newly discovered computers in the Pending Actions folder before MOM installs an agent remotely. If the Management Server is configured to install agents automatically, MOM installs an agent and adds the computer to the Agent-managed Computers view in the MOM Administrator console. MOM can discover computers beyond firewalls; however, MOM cannot remotely install agents on these computers. If you want to use an agent to monitor computers in workgroups, across non-trusted domains, or across firewalls, you must install agents manually on those computers. Manual installation of agents is covered in more detail in the Installing Agents Manually section later in this chapter. Note When traversing a firewall, port 1270 for both TCP and UDP must be open from the agent computer to the MOM 2005 Workgroup Edition server. You cannot run or schedule to run Computer Discovery rules individually. Initiating On-Demand Computer Discovery You can initiate a full computer discovery at any time by following these steps: 1. In the MOM Administrator console, expand Administration, expand Computers, and then click Management Servers. 2. In the details pane, right-click the Management Server for which you want to perform computer discovery, and then click Run Computer Discovery Now. Installing Agents Remotely There are a number of ways that you can remotely install MOM agents on computers within the management group. With some methods, you can immediately install agents and with other methods you can approve computers for automatic agent installation during the next full computer discovery. If you install agents immediately, you can specify which account you want MOM to use to install the agent and which account you want the agent to use to perform actions on the

216 200 Microsoft Windows Server System Deployment Guide for Midsize Businesses managed computer. If you approve a computer for automatic agent installation during the next full computer discovery, MOM uses the Management Server Action Account to install the agent and the Local System account for the Agent Action Account. Remote installation options include the following: Install/Uninstall Agents Wizard (preferred method): You can install agents immediately by running the Install/Uninstall Agents Wizard. MOM automatically discovers and installs agents on the computers matching the Computer Discovery rules that you create by running this wizard. Computer Discovery Rule property dialog box: You can discover computers for agent installation by creating Computer Discovery rules in the Computer Discovery Rule property dialog box. Depending on the automatic agent installation settings for the Management Server, MOM either automatically installs agents on the computers that match these rules or places the computers in the Pending Actions folder during the next full computer discovery. Processing computers in the Pending Actions folder: By using the Pending Actions folder, you can immediately install an agent or approve computers for automatic agent installation during the next full computer discovery. Changing the Management Mode: You can also install an agent immediately by changing the management mode of an agentless-managed or unmanaged computer to agentmanaged, which starts the Install Agent Wizard. Choosing Which Agent Installation Wizard to Use In order to install the MOM agent on computers, MOM requires an account with administrative rights on the local computer. The MOM 2005 Workgroup Edition Install/Uninstall Agents Wizard always uses the Management Server Action Account, which therefore means that to use this wizard the Management Server Action Account must have administrator rights on all target computers. Depending on how the Management Server Action Account is configured, select one of the two following installation options to install MOM agents on target computers: If the Management Server Action Account is configured with administrator rights, use the Install/Uninstall Agents Wizard. If the Management Server Action Account does not have administrator rights, use the Install Agent Wizard, which enables you to specify alternative accounts, as described in Using the Install Agent Wizard with Alternative Accounts later in this chapter.

217 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 201 Running the Install/Uninstall Agents Wizard When you run the Install/Uninstall Agents Wizard to create Computer Discovery rules, MOM discovers the computers and immediately installs agents as soon as you complete the wizard. This happens regardless of the automatic agent management settings for the Management Server. To install agents immediately by using the Install/Uninstall Agents Wizard 1. In the MOM Administrator console, expand Administration, and then click Computers. 2. In the details pane, click Install/Uninstall Agents Wizard. 3. If you have previously installed agents to the Management Server, the Install or Uninstall Agents page appears. Leave the Install Agents option selected and click Next. 4. On the Method for Discovering Computers and Installing Agents page, click Browse for or type in specific computer names or click Search Criteria, and then click Next. 5. If you selected the Browse for or type in specific computer names option in step 4, complete the following steps: a. On the Computer Names page, click Browse to locate computers on the network or type the names of computers where you want MOM to install the agents. Note You can use FQDN or NetBIOS names. With Active Directory directory service, you should use FQDN names. With NetBIOS names, MOM automatically contacts each of those computers to verify that they exist. This slows down computer discovery. You can also use the domain\computername format to indicate computers specifically. In addition, this format can be used to discover computers in workgroups, when the workgroup name is used instead of the domain. b. Click Next and proceed to step If you selected Search Criteria in step 4, complete the following steps: a. On the Computer Discovery Rules page, click Add. b. In the Computer Discovery Rule property dialog box, specify the rule properties. For more information about the rule properties, see the Creating Computer Discovery Rules section earlier in this chapter. c. Repeat steps a and b for each computer or group of computers on which you want to install agents. d. Click Next and proceed to step 7.

218 202 Microsoft Windows Server System Deployment Guide for Midsize Businesses 7. On the Agent Installation Permissions page, the Management Server Action Account is selected as a default setting. (This setting cannot be changed in MOM 2005 Workgroup Edition.) 8. On the Agent Action Account page, the Local System option is selected by default. (This setting cannot be changed in MOM 2005 Workgroup Edition.) 9. On the Agent Installation Directory page, the installation path defaults to '%PRO- GRAMFILES%\Microsoft Operations Manager (This path cannot be changed in MOM 2005 Workgroup Edition.) 10. On the Completing the Install/Uninstall Agents Wizard page, review your selections. If you want to monitor the agent installation progress, select the Show task progress check box, and then click Finish. When you use the Install/Uninstall Agents Wizard, the Management Server performs a limited computer discovery when you complete the wizard. MOM discovers only the specific computers that match the newly created Computer Discovery rules. If changes to the properties for a Computer Discovery rule result in excluding agent-managed computers that were previously included, MOM continues to manage those computers until the agent is uninstalled. Using the Computer Discovery Rule Property Dialog Box When you use the Install/Uninstall Agents Wizard to create Computer Discovery rules with search criteria, you create a Computer Discovery Rule property dialog box. You can also create Computer Discovery rules by using the Computer Discovery Rule property dialog box directly. When you create Computer Discovery rules by using the Computer Discovery Rule property dialog box directly, the matching computers are not discovered until the next full computer discovery. If the Management Server is configured to automatically install agents, agents are installed or uninstalled during the next full computer discovery. If the Management Server is configured to not automatically install agents, the computers are added to the Pending Actions folder during the next full computer discovery. For more information, see Processing Computers in the Pending Actions Folder later in this chapter. To create Computer Discovery rules by using the Computer Discovery Rule property dialog box 1. In the MOM Administrator console, expand Microsoft Operations Manager, expand Administration, and then expand Computers. 2. Right-click Computer Discovery Rules, and then click Create Computer Discovery Rule.

219 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition In the Computer Discovery Rule property dialog box, enter the properties for the rule. For more information about rule criteria, see Creating Computer Discovery Rules earlier in this chapter. Processing Computers in the Pending Actions Folder During a full computer discovery, MOM gathers information from all existing Computer Discovery rules and searches the network for matching computers. Depending on the automatic agent installation settings for the Management Server, MOM either installs agents immediately or places the matching computers in the Pending Actions folder. By default, the Management Server is configured to not automatically install or uninstall agents. Unless you change this setting, MOM places computers found during computer discovery in the Pending Actions folder. For the computers in the Pending Actions folder, you can immediately install an agent or approve them for automatic agent installation during the next full computer discovery. If you approve computers for automatic agent installation, MOM installs the agent by using the Management Server Action Account. If you want to use a different account to install the agents, you should choose to install the agents immediately. To install an agent immediately on a computer in the Pending Actions folder 1. In the MOM Administrator console, expand Administration, and then click Pending Actions. 2. Right-click the computer on which you want to install the MOM agent, and then click Install Agent Now. This starts the Install Agent Wizard, which gives you the option of using an account other than the MOM Management Server Action Account. To complete the wizard, follow the procedure, beginning with step 3, in Installing Agents by Using the Install Agent Wizard later in this chapter. To approve a computer in the Pending Actions folder for agent installation in the next full computer discovery 1. In the MOM Administrator console, expand Administration, and then click Pending Actions. 2. In the details pane, right-click the computer you want to approve for agent installation, and then click Approve for Processing by Computer Discovery. The computer remains in the Pending Actions folder. MOM will automatically install an agent during the next full computer discovery.

220 204 Microsoft Windows Server System Deployment Guide for Midsize Businesses Installing Agents by Using the Install Agent Wizard You can install an agent on a computer by changing the management mode of the computer in the Unmanaged folder. This starts the Install Agent Wizard, which installs an agent immediately, regardless of the automatic agent installation settings for the Management Server. To install an agent by changing the management mode 1. In the MOM Administrator console, expand Administration, and then click Unmanaged Computers. 2. Right-click the computer on which you want to install an agent, and then click Install Agent to start the Install Agent Wizard. 3. On the Agent Installation Permissions page, either leave the Management Server Action Account selected or click Other, and then type a User name and Password for the account. 4. On the Agent Action Account page, either leave the Local System option selected or click Other, and then type a User name and Password for the account. 5. On the Agent Installation Directory page, type the local directory where the MOM agent will be installed on the targeted computers. The default directory is %PROGRAM- FILES%\Microsoft Operations Manager On the Completing the Install Agent Wizard page, review your selections. If you want to monitor the agent installation progress, select the Show task progress check box, and then click Finish. Using the Install Agent Wizard with Alternative Accounts Follow these steps to use the Install Agent Wizard with alternative accounts. To use the Install Agent Wizard with alternative accounts 1. In the MOM Administrator console, expand Administration. 2. Right-click Computer Discovery Rule, and then select Create Computer Discovery Rule. 3. In the Computer Discovery Rule dialog box, enter the requested information, such as the Rule type and Domain name. Set the Initial Management Mode to Unmanaged. 4. To discover the computer, right-click Computer Discovery Rule, and then select Run Computer Discovery Now. 5. In the MOM Administrator console, select Unmanaged Computers. 6. In the details pane, right-click the computer on which you want to install the MOM agent, and then select Install Agent to start the Install Agent Wizard. 7. In the Install Agent Wizard, on the Agent Installation Permission page, you can either select the Management Server Action Account (which does not have sufficient privileges

221 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 205 in this scenario) or select Other and specify an account that has local administrator privileges on the target computer. This account is used to perform the installation on the target computers. 8. On the Agent Action Account page, you may enter an account with local user privileges on the target computer to reduce access to local resources on that computer by the MOM processes. This account is used to run providers, responses, and scripts used by MOM to collect and respond to events on the managed computer. 9. On the Agent Installation Directory page, type the local directory where the MOM agent will be installed on the targeted computer. The default directory is '%PROGRAM- FILES%\Microsoft Operations Manager Installing Agents Manually Under certain circumstances, installing an agent manually is preferable to using the Management Server to remotely install an agent. In some cases, installing the agent manually is the only method available for installing an agent. You must take additional steps when you manually install agents on any computer that is already in the Unmanaged Computers folder in the MOM Administrator console or if a previous push-installation failed. Do the following: 1. In the MOM Administrator console, under Administration/Computers/All Computers/Unmanaged Computers, right-click the computer that you want to install the agent on, and then click Delete. 2. Right-click the Management Pack folder, and then click Commit Configuration Changes. 3. Restart the MOM service on the Management Server. 4. Manually install the agent by following the steps and guidelines in this section. Some reasons for installing agents manually include the following: To install an agent on which the target computer is behind a firewall To control and limit network bandwidth usage (for example, to monitor computers that are across slow network links) To monitor a highly secure server Before you can install agents manually, you must configure the Management Server to accept new manually installed agents. For more information, see Configuring for Manually Installed Agents earlier in this chapter.

222 206 Microsoft Windows Server System Deployment Guide for Midsize Businesses Running the Agent Setup Wizard The Agent Setup Wizard installs a MOM agent on the local computer and guides you through agent configuration. To access the MOM 2005 Workgroup Edition Agent Setup Wizard 1. On the MOM 2005 Workgroup Edition software CD, double-click Setup.exe to open the Microsoft Operations Manager Setup Resources dialog box. 2. Click the Custom Installs tab. 3. Click Install Microsoft Operations Manager 2005 Agent. Note If the Management Server is behind a firewall or is otherwise inaccessible when you run the Agent Setup Wizard, a message appears stating that it cannot contact the Management Server. However, this does not necessarily indicate a problem, especially if you have verified the Management Server information that you entered. 4. Click Next to finish the wizard. Manual Agent Properties You can specify the following properties when you install an agent manually: Installation directory: The directory where the MOM agent software will be installed. The default directory is %SystemRoot%\Program Files\Microsoft Operations Manager Management group name: The name of the management group to which you want this agent to belong. Management Server: The name of the Management Server to which you want this agent to report. Management Server port: The TCP/IP port that MOM uses for communication between the agent and the Management Server. By default, this setting is If you have changed this setting, you must enter the correct port here. Agent control level: The level of Management Server interaction with the agent: None or Full. The Management Server adds the computer to the appropriate folders automatically for both settings. To change the level of agent control after you have installed an agent, you must uninstall the agent, remove the agent s entry in the MOM database, and then reinstall the agent. None: The Management Server does not remotely upgrade or uninstall agents. MOM never remotely updates manually installed agents with the agent control level set to None. When applying hotfixes or installing service packs to MOM, you must manually update these agents. You also must upgrade and uninstall the agent software manually.

223 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 207 Use this option for computers that are within the network but outside a firewall, or computers that the Management Server cannot contact, regardless of the reason. Note Agents with their Control Level set to None will not collect FQDN information and any Management Pack scripts or responses that use FQDN information will fail. To change this, set the Control Level to Full. Full: The Management Server performs all operations for the agent, including agent configuring, upgrading, uninstalling, and attribute collecting. Use this option for computers on the internal network to provide automatic agent configuration. MOM Agent Action Account: The account that the agent uses to access providers and to run responses on the local computer. By default, the Local System account is used. You can provide credentials for a domain or a local computer account. You can use a low-privileged account for the agent s Action Account under certain circumstances. With Windows 2000, the Action Account must be a member of the local administrators group. The Action Account must be either a member of the local administrators group or Local System for MOM to monitor the IIS logs or run the Simple Network Management Protocol (SNMP) responses. Active Directory configuration: For greater security, MOM 2005 Workgroup Edition gives the option of requiring the Management Server and agents to authenticate one another before communicating. Mutual authentication requires a two-way Active Directory trust relationship between the Management Server and all agents in the configuration group. This property is management-group-wide and cannot be set differently for individual agents. By default, this is set to Yes. Approving Manually Installed Agents The default setting is to reject new manually installed agents. Unless you change this setting, all new manually installed agents will be rejected and will not appear in the MOM Administrator console. For more information about changing this setting, see Configuring the Management Server earlier in this chapter. If you have changed the setting to manually install some MOM agents, you still must approve the new manually installed agents before they can download rules and begin monitoring. When the manual agent installation is complete, MOM places the computer with the manually installed agent in the Pending Actions folder. To approve a manually installed agent 1. In the MOM Administrator console, expand Administration, expand Computers, and then click Pending Actions. 2. In the details pane, right-click the computer for which you want to approve the agent, click Approve Manual Agent Installation Now, and then click Yes. You do not have to run computer discovery again.

224 208 Microsoft Windows Server System Deployment Guide for Midsize Businesses If the manually installed agent has an agent control level of Full, MOM automatically creates a Computer Discovery rule for that computer when it is approved. However, a Computer Discovery rule is not created for a manually installed agent with an agent control level of None. Verifying Results After installing agents either remotely or manually, you can review the status of the agent installation by using the MOM Administrator console and MOM Operator console. Using the Task Progress Dialog On the last page of the Install/Uninstall Agents wizard, you can select the Show task progress option to view the task progress as it happens. This progress dialog box shows the agents that are being installed, the progress of the agent s installation, the success or failure issues with agent installations, and a summary of the process. Verifying Agent Installation in the MOM Administrator Console You can verify in the MOM Administrator console that all agent-managed computers appear in the Agent-managed folder and that the agents are reporting to the correct Management Server. If you do not have automatic approval enabled (this is the default setting) these computers will appear in the Pending Actions folder. To verify that computers are discovered 1. In the MOM Administrator console, expand Administration, expand Computers, and then click All Computers. 2. Verify that the intended computers have been discovered and that they have the appropriate management mode. 3. Expand Pending Actions and verify that any computers not in the other folders are here. Verifying Agent Installation in the MOM Operator Console Follow these steps to verify agent installation. To review agent installation status in the MOM Operator console 1. Open the MOM Operator console. 2. In the Alerts pane, expand Microsoft Operations Manager, and then click Alerts. 3. In the Alerts details pane, verify that there are no alerts related to agent installation. 4. In the Alerts pane, expand Operations Manager 2005, and then expand Agent Deployment. 5. Click the items in the Agent Deployment folder to review the success and failure of agent installations.

225 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 209 Management Packs MOM management packs provide built-in, software-specific operations knowledge for a wide variety of server applications. Management packs contain rules for monitoring a comprehensive array of server health indicators and for creating alerts, often preemptively, when problems are detected or reasonable thresholds are exceeded that require administrator intervention. This powerful monitoring capability is augmented by in-depth knowledge-base content, prescriptive guidance, and actionable tasks that can be associated directly with the relevant alerts included in the management packs. Administrators can then act to prevent or correct situations, such as degraded performance or service interruption, maintaining service availability with greater ease and reliability. A management pack consists of a collection of rules, knowledge, and public views. The management pack makes it possible to collect a wide range of information from different sources. You can use management packs to determine how a MOM Management Server collects, handles, and responds to data. The following information is contained in a management pack: A list of rule groups that contain rules A list of rules for each rule group A list of providers that the rules reference A list of scripts that the rules need to call in response to an event A list of registry-based computer attributes that are needed for discovery A list of computer groups whose formula depends on the specified computer attributes A list of computer group and rule group associations that specify rule targets A list of notification groups that notification responses use in rules A list of view instances definitions that define how the operations data produced by managed computers should be viewed A list of tasks that users might need for managing the application The service discovery class schema that defines the entities that will be managed, their properties, and their relationship to other properties The diagram definitions that describe how service discovery data should be viewed as a diagram from an application perspective Knowledge associated with the rules that specifies how problems should be corrected and how the management pack should be used Rules contain information about a specified event, alert, or performance condition. This information describes the condition and its importance or significance and provides details to help

226 210 Microsoft Windows Server System Deployment Guide for Midsize Businesses resolve it. This information, called the knowledge base, is stored with the rule. When you view the properties of an alert, you can examine the knowledge base. The product knowledge base provided by Microsoft or other vendors is read-only to users. To create rules or management packs with built-in vendor knowledge, right-click the Rule Groups folder, and then select Enable Author Mode. In addition, your customer can add information to the company knowledge base when they create a rule and when they resolve an alert. The company knowledge base can be invaluable to an organization, because it reflects specific knowledge gained through experience and is available to benefit others in the organization. It can save hours of troubleshooting time. As you import or export a rule group, the knowledge base articles are also imported or exported. Microsoft Management Packs Management packs for Microsoft applications are developed directly by the individual software development teams in conjunction with Microsoft Consulting Services and Microsoft Product Support Services, combining the best of development, deployment, and troubleshooting knowledge. As specified in the Common Engineering Roadmap, located at /windowsserversystem/overview/engineeringroadmap.mspx, all server applications developed by Microsoft are required to include a management pack; most solutions already do include management packs and, moving forward, all new server applications will deliver management packs at or shortly after release to manufacturing. Third-Party and Custom Management Packs A wide range of non-microsoft application and hardware management packs enable MOM to manage far more than just Microsoft components within an IT infrastructure. To provide the best possible management for applications, Microsoft encourages application providers, who have the sophisticated knowledge associated with their own applications, to supply management packs for their applications, embedding the necessary operational intelligence to aid the administrator or operator. The Management Pack catalog located at /management/mma/catalog.aspx includes not only all of the management packs provided by Microsoft, but a number of non-microsoft management packs that enable MOM to manage a variety of other applications as well. In addition, custom management packs can be developed. Guidance on developing management packs is provided on the Creating Management Packs Web site, located at which offers a management pack development guide, among other resources.

227 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 211 Management Packs Included with MOM 2005 Workgroup Edition The following Microsoft management packs are included with MOM 2005 Workgroup Edition and are automatically installed during setup: Microsoft Baseline Security Analyzer (MBSA) Microsoft Exchange 2000 Server Microsoft Exchange Server 2003 Microsoft Operations Manager (MOM) 2005 Microsoft Systems Management Server (SMS) 2003 Microsoft SQL Server 2000 Microsoft Windows Active Directory Microsoft Windows Base Operating System Microsoft Windows DNS Microsoft Windows IIS Microsoft Windows Server Clusters In most deployments of MOM 2005 Workgroup Edition, these pre-installed management packs are expected to be sufficient. However, MOM 2005 Workgroup Edition fully supports importing, exporting, and upgrading of management packs in the same manner that MOM 2005 does. All management packs available for MOM 2005 can also be used with the MOM 2005 Workgroup Edition. Note By default, all management packs are enabled. Disabling any management packs that are not going to be used is recommended to reduce the overhead on the MOM server. Also, fine tune the management packs by turning off alerts that are not required. Importing Management Packs If you are importing a management pack that is already installed in the production environment, replace the existing management pack. This ensures that the management packs that are used in production match the management packs that have been tested and tuned in the test environment. When you import a management pack that does not exist in the MOM database, it is placed at the top level of the rules tree. When you import a management pack that already exists in the MOM database, it remains at the same level of the rules tree.

228 212 Microsoft Windows Server System Deployment Guide for Midsize Businesses Using the MOM Administrator Console to Import a Management Pack Follow these steps to import a management pack: 1. In the MOM Administrator console, click Management Packs. 2. In the details pane, click Import/Export Management Packs. 3. On the Import or Export Management Packs page, click Import Management Packs. 4. On the Select a Folder and Choose Import Type page, click Browse. 5. Navigate to the folder where the management pack is located, and then click OK. 6. On the Select Management Packs page, select the management packs that you want to import, select an import option, and then click Next. 7. To complete and close the wizard, click Finish. When you import a management pack, the rules can be viewed immediately in the MOM Administrator console, and the views can be viewed by pressing F5 or by using Refresh in the MOM Operator console. Updating an Existing Management Pack You can import a management pack as a method of updating an existing management pack. If you are updating an existing management pack, you can preserve some of the customizations. You have two options when importing a management pack: update or replace. To prevent critical data loss, with either option you should always choose to back up the existing management pack. Update Existing Management Pack Option This option renews an existing management pack. With the new version, user-modified rules, scripts, data providers, and computer groups on vendor-shipping rules are overwritten, but the following are retained: User-added company knowledge on vendor-shipping rules User modifications to the default state of rules (enabled or disabled) User-added custom rules This option is recommended if you want to completely synchronize the existing management pack with the latest version and retain company knowledge, enabled or disabled settings, and custom rules. You can create two rules with the same name in the same rule group without importing an external management pack. If a rule in the management pack conflicts with a pre-existing one,

229 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 213 then the rule from the management pack takes precedence. The existing knowledge base comments are retained. Do not use the Update Existing Management Pack option when you import a management pack into the production environment. If you want to renew a new or updated management pack with a previous management pack, then import the two management packs into a test environment. Replace Existing Management Pack Option This option replaces an existing management pack with the new version being imported, resulting in the following: User-added company knowledge on vendor-shipping rules is removed User-added custom rules are removed User-modified rules, scripts, data providers, and computer groups on vendor-shipping rules are overwritten This option is recommended if you want a fresh install of the latest management pack and do not want to retain any user-created company knowledge or custom rules. You can also use this option to import a management pack from the test environment into the production environment. Best Practices for Importing Management Packs When you import an updated management pack into the production environment, always replace the existing management pack with one from the test environment. When you import a new management pack, always select the Backup Existing Management Pack option. With this backup, you can return to the former management pack state by importing the backup. However, items such as providers, Views and Tasks, and scripts created after the new management pack is imported will remain after the restoration process. Management pack backups are located in the following folder: %SystemRoot%\Program Files\Microsoft Operations Manager 2005\MPBackupDir. Before importing an updated management pack, users who have modified any of the original rules from the vendor should do the following: 1. Open a rule group where there are modified rules. 2. Select a modified rule. 3. Copy and paste the rule into the same rule group, so that there are two identical rules in the same rule group. 4. After a rule is copied, remove the Copy of text that is part of the new rule s prefix.

230 214 Microsoft Windows Server System Deployment Guide for Midsize Businesses 5. Append the new rule with some text to distinguish the new custom rule from the original vendor rule. 6. Disable the original vendor rule. Important This process will not protect the old rules if the Replace option is used when importing the new management pack. Also, product knowledge will not be copied with the rules unless you are an author of the knowledge. After the modified rules are copied, the new management pack can be imported safely by using the Renew Existing Management Pack option. This ensures that all modifications to custom rules and company knowledge are retained. This separates user customizations from the original vendor rules. Vendors can continue shipping updated rules that function as the vendor intends, without putting custom rules and modifications at risk. A best practice is to use this process to create custom rules, instead of modifying the original vendor rule. Implementation Checklist Use the following checklist to plan, deploy, and configure MOM 2005 Workgroup Edition. Planning the deployment Ensure that all hardware/software requirements have been met. Assess capacity requirements for the deployment. Confirm that the customer does not require the additional functionality of MOM Preparing to deploy Verify the service accounts. Determine security groups for the MOM Administrator console and Operator console. Install and configure MSDE or SQL Server. Deploying and configuring Install MOM 2005 Workgroup Edition components. Set up additional Administrator and Operator consoles as required. Identify the computers to be managed by MOM 2005 Workgroup Edition.

231 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 215 Increase the log file size of all computers to be managed to recommended limits. Configure Management Server settings. Create Computer Discovery rules and initiate computer discovery. Prepare Agent installation: Assess the best option for installing agents: remote and/or manual. Install agents. Verify results of agent installation. Importing management packs Assess the management packs included with MOM 2005 Workgroup Edition and their usability within the organization. Fine-tune the management pack settings by turning off alerts that aren t required. Consider disabling any management packs that will not be used. Assess the need for additional management packs beyond those included in the original installation. If an update of an existing management pack is required, determine whether the Update Existing Management Pack or the Replace Existing Management Pack option is the most appropriate. Operating MOM To understand the processes and procedures for operating MOM 2005 Workgroup Edition, you should understand the MOM components. Table 6-1 provides an overview of the component definitions. The basic management unit is the MOM Management Group, which is a MOM installation that includes one MOM Database, one or more MOM Management Servers, and multiple MOM Agents that are installed on the physical computers. It can also include multiple computers that are managed by using an agentless monitoring technique. The MOM deployment scenario illustrated in this chapter has all of the components installed with managed computers in a single domain. The MOM Database is installed on the same server as the Management Server, and the only Management Pack that is installed is the MOM Management Pack. Table 6-1 Component MOM Database MOM Component Definitions Description A Microsoft SQL Server database that stores configuration information and operations data that is produced by the monitoring process.

232 216 Microsoft Windows Server System Deployment Guide for Midsize Businesses Table 6-1 Component MOM Management Server Data Access Server (DAS) MOM Server MOM Agent MOM Reporting Database User interfaces Processing Flow The primary elements in the data processing flow are the MOM Database, the MOM Management Server, and managed computers. This flow is bi-directional, and the flow direction is determined by the situation. Operational Data MOM Component Definitions Description A computer that is responsible for monitoring and managing other computers. The MOM Management Server consists of the Data Access Server, and the MOM Server and MOM Agent components. The MOM Management Server is an essential part of a management group. A COM+ application that manages access to the MOM Database. A component that manages the MOM Agents that monitor computers in a MOM environment. A component that monitors and collects data from a managed computer. A SQL Server database that collects and stores the operations data contained in the MOM Database. The Administrator console and Operator console installed by default when you install MOM. When an alert is raised on a managed computer, the data is sent to the Management Server. The MOM Server component passes the data to the Data Access Service (DAS) runtime component. The DAS adds the operational data to the MOM Database. After the alert is written to the database, the information is provided to the MOM Operator console. Note In scenarios with agentless-managed computers, the alert is raised by the local agent on the Management Server, which passes the data to the DAS. Rules and Configuration Data When there is a rule or configuration change, the MOM Server runtime component passes this information to the DAS, which writes the change to the MOM Database. After the change is stored in the operational database, the MOM Management Server sends these changes to the managed computers.

233 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 217 Note In scenarios with agentless-managed computers, the changes are retained by the local agent in the MOM runtime. Operational Data During computer and application monitoring, all the operational data that is generated is stored in the MOM Database. This data includes: event data, performance data, alert data, and discovery data. Event Data (Events) Managed computers log events in local event logs (Application, Security, and System), and MOM collects event information from these logs, which can be used to: View operational data in the Operator console. Generate reports by using the MOM Reporting Server and the Reporting Database. Provide a context for problems that are detected. Provide information about MOM monitoring and management activities. Provide information about computer state, which is derived by correlating data from consolidation events or missing events. Performance Data Numeric performance data is gathered from sources such as Windows performance counters and Windows Management Instrumentation (WMI), which can be used to: View performance data in the Operator console by using different formats such as forms, lists, and graphs. Generate reports by using the Reporting Server and the Reporting Database. Identify critical threshold crossings that might indicate performance issues. Alert Data (Alerts) Alerts inform you about the health of managed computers and provide the basis for the status monitoring. Alert data contains the following information about a problem detected on a managed computer: The entity associated with the problem, described as a service discovery type. The problem area for the entity. For example, if the entity is the SQL Server Agent, the problem area could be the SQL Server Instance. The severity of the problem, indicated by a level, such as Error, Critical, and Warning. The Alert Name, which is descriptive. The Alert Description, which provides a brief description of the problem.

234 218 Microsoft Windows Server System Deployment Guide for Midsize Businesses The Problem State, which shows the current state of the problem and indicates whether the problem is still occurring. The Alert Count, which indicates how many times the problem was reported. The Alert Resolution State, which indicates whether the problem has been acknowledged, assigned, or resolved. The Alert History, which is contained in the knowledge base, provides a record for the alert. The knowledge base contains a problem description and recommended resolution, as provided by the Management Pack creator, or it can contain customer knowledge that describes the problem and its resolution. Alert data that is stored in the MOM Database is continuously updated as MOM collects information about the computer that generated the alert. When a problem is first detected, an alert is generated and inserted in the database. If MOM detects that the problem has disappeared, MOM updates the problem state of the original alert and retains it in the MOM runtime. Eventually, the problem state of the existing alert in the database is updated and flagged as fixed; however, alerts must still be acknowledged and resolved. Discovery Data Discovery data contains a snapshot of the entities that are discovered in accordance with a given Management Pack. Unlike the other operational data, discovery data is not directly exposed to the user, but is shown as topology diagrams, computer attributes, service lists, or computer lists. This data is presented in different views, such as the State view. References For the latest information about MOM, see the MOM 2005 Workgroup Edition site at go.microsoft.com/fwlink/?linkid=6727. To access the MOM core product documentation on the Web, see the Technical Resources section of the MOM 2005 Workgroup Edition site at go.microsoft.com/fwlink/?linkid=8943. For additional information and best practices on planning and deploying MOM 2005 Workgroup Edition, visit the following Web-based resources: The MOM 2005 Workgroup Edition Web site at /default.mspx provides in-depth solution information, including licensing details and technical resources. MOM 2005 Planning and Deployment resources, including: Conceptual Guide, at /details.aspx?familyid=e06970bb-02f9-40da-b986-00d98d595696&displaylang=en Planning Guide, at DF08-431B-8D0D-2D184E81E161&displaylang=en

235 Chapter 6: Installing and Maintaining Microsoft Operations Manager 2005 Workgroup Edition 219 Deployment Guide, at dca-da65-44eb-875f-0ab4928cbfbd&displaylang=en Security Guide, at /secguide.mspx MOM 2005 Technical Resources on TechNet at /mom/mom2005/default.mspx help you plan, maintain, and support MOM 2005 and MOM 2005 Workgroup Edition implementations. MOM Management Packs at /default.mspx include general information and links to additional resources, including a guide on creating custom management packs and the comprehensive management pack catalog. For information on monitoring, maintaining and optimizing MOM, refer to the MOM Operations Guide at /default.mspx.

236

237 Chapter 7 Installing and Configuring File Sharing and Print Services This chapter provides guidance that can be used to plan, build, deploy, and operate file services. It provides guidance on designing and implementing a single unified namespace for network shares by using DFS. The chapter provides guidance on implementing file services and storage on the existing primary infrastructure server or on a Microsoft Windows Storage Server 2003 based network-storage device. File services are a critical component of the core information technology (IT) infrastructure of any medium business. Based on factors like storage requirements, scalability needs, and the available budget, the medium business can have one of the following two possible options deployed in its end state environment: The primary infrastructure server providing file services, in addition to other services such as network services, Active Directory, and Certification Authority (CA). A Windows Storage Server 2003 based network-attached storage device dedicated to provide file services. The scope of the guidance provided in this chapter includes: Designing a network share structure that is logical and facilitates the finding of information on the shares. Implementing technologies such as Distributed File System (DFS), which facilitates the deployment and management of a well-designed network share structure. Choosing and implementing the appropriate storage technology to meet current and future requirements. Enabling the following features: Shadow Copies of Shared Folders using the Volume Shadow Copy service Folder redirection and offline folder caching which will be discussed in Chapter 9, Managing Desktops by Using Group Policy Disk quota management 221

238 222 Microsoft Windows Server System Deployment Guide for Midsize Businesses This chapter provides guidance on implementing file services on the following: The primary infrastructure server, which runs additional services, including: Network services, which include Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and Windows Internet Name Service (WINS) The Active Directory directory service Certification Authority (CA) A Microsoft Windows Storage Server 2003 based network-attached storage device that is dedicated to provide file services This chapter complements the information provided in the Windows Storage Server 2003 product documentation and the Designing and Deploying File Servers chapter of the Planning Server Deployment guide in the Windows Server 2003 Deployment Kit available at Planning File Sharing and Print Services Choices When planning your organization's file sharing and print services, you should consider your business needs and select the solution that is best suited to meet them. The following choices were considered for the file share design in this chapter: Network share URL: Consists of the name of the server that hosts the network share and the name of the network share. For example, the URL for the Users network share that is hosted on the FileSvr server will be \\FileSvr\Users. DFS namespace: Provides a single unified namespace for all the network shares that reside on different servers. Clients use this unified namespace to access the network shares in the environment regardless of the location of the share. To the user, it appears that all the shares are on a single file server. This book recommends choosing one of the following two implementations: File services hosted on the primary infrastructure server. Windows Storage Server 2003 based network-attached storage device dedicated to provide file services.

239 Chapter 7: Installing and Configuring File Sharing and Print Services 223 Hosting file services on the primary infrastructure server is recommended for organizations that have the following requirements: Data storage needs are nominal. Your organization cannot afford a dedicated server for file services and wants to use an existing server. Performance of the file services and other services running on the primary infrastructure server is not an issue for you. (Running multiple services on the same server might affect the performance of some or all of these services.) A second server exists that provides redundancy to network services, so that business is not affected in case of short-duration service outage. A Windows Storage Server 2003 based network-attached storage device provided by the original equipment manufacturer (OEM) is recommended for organizations that need the following: Storage for a large amount of data Easy scalability to meet a fast rate of growth in data Centralized data storage that is easy to manage and cost effective Disk-based backup, because of the long delay in restoring data from offsite tape backups File services that are easy to deploy and manage Typically, a Windows Storage Server 2003 based network-attached storage device can be set up in 30 minutes. File Services Configuration Being an optimized version of Microsoft Windows Server 2003, Windows Storage Server 2003 provides all the file service features provided by Windows Server These technologies can be implemented on the Windows Storage Server or on the primary infrastructure server. There are file service features and technologies that provide various benefits to the internal users as well as the mobile users. Some of the recommended file service features and technologies that can be implemented in the medium IT environment are: Shadow Copies of Shared Folders Folder redirection (with offline folder caching)

240 224 Microsoft Windows Server System Deployment Guide for Midsize Businesses Deploying File Sharing and Print Services This section provides guidance on configuring file sharing protocol and various file service technologies on both Windows Storage Server 2003 and Windows Server In addition, this section provides prescriptive guidance on setting up and configuring Windows Storage Server 2003 based network-attached storage devices. This chapter does not provide steps for configuring the hardware and operating system of the primary infrastructure server. If you are deploying the file services on the primary infrastructure server, first build the server by using the guidance provided in Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server 2003, and then start configuring file services (refer to the Configuring File Service Technologies section later in this chapter). The following are the overall tasks that need to be performed to configure the file server: Gathering information for the initial configuration. Configuring the hardware and operating system. Performing the initial network configuration. Creating disk volume. Configuring the server message block. Configuring file service technologies. Configuring management features. Validating the server security configuration. Note If the steps in this section do not specify the exact values to be used while running a wizard, use the default values. Configuring File Service Technologies This section provides prescriptive guidance on configuring various file service technologies. Configuring DFS Perform the following steps on the DFS server (for example, MONAS), using the Distributed File System console in Administrative Tools to add a new domain DFS root on the server on which file services will be enabled. 1. Access the Windows desktop of MONAS by using the Web UI and clicking the Remote Desktop link under the Maintenance link, and then log on to the server. 2. Create an empty folder (for example, E:\DFSRoot). Right-click the folder, and click Sharing and Security. Enable Share this folder. Grant the Domain Users group Full Control on the share. If the Everyone group is listed, select it and click Remove. Click OK.

241 Chapter 7: Installing and Configuring File Sharing and Print Services Click the Security tab, click the Advanced button, and then clear the Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here option. 4. When prompted to remove inheritable permissions from the child folders, click Remove. 5. If the Security dialog box appears, click Yes. 6. Add the Domain Admins and SYSTEM with Full Control. Click OK. 7. Click Add, type Domain Users, click OK, and select the List folder/read Data option. In the Apply onto drop-down menu, click This folder only. Click OK. Remove all other groups and users, and then click OK. 8. Under Administrative Tools, open the Distributed File System management console. 9. Create a DFS root by performing the following steps: a. Right-click Distributed File System, and click New Root. b. Use the New Root Wizard to create a root DFS as follows: i. On the Root Type page, select Domain root. ii. iii. iv. Accept the default domain name (for example, BusinessName.com). Type the server name that hosts the DFS root (for example, MONAS.BusinessName.com). Type a root name (for example, AllShares). v. In Folder to share, enter the path of the empty folder created previously (for example, E:\DFSRoot). c. On the Distributed File System console, right-click the newly created DFS root, and click Properties. d. On the Properties page, click the Publish tab, and select the Publish this root in Active Directory check box. Real World Lucerne Publishing wanted to publish a share called SalesData, which contains sensitive sales information that only the staff in the sales department should be allowed to access. The share was created on the MONAS server. The steps involved in accomplishing this task included the following: 1. Create a user called salesuser in the Active Directory domain. 2. Create a group called salesgrp in the Active Directory domain. 3. Add the user salesuser under salesgrp group. 4. Create the SalesData share and assign the appropriate permissions to allow access only to the users in the salesgrp group. 5. Create a DFS link under the DFS root.

242 226 Microsoft Windows Server System Deployment Guide for Midsize Businesses To create a user called salesuser in the Active Directory domain 1. On the primary infrastructure server (MOCOR1), open the Active Directory Users and Computers snap-in under the Administrative Tools. 2. Expand the domain name. Right-click the Users container, click New, and then click User. 3. On the New Object User page, provide the first name as salesuser and Users logon name as [email protected]. Provide a strong password for this user according to the security policy of your organization. 4. If you do not want to create an Exchange box for this user, clear the Create an Exchange mailbox check box. 5. Complete the user creation process. To create a group called salesgrp in the Active Directory domain 1. On the primary infrastructure server (MOCOR1), open the Active Directory Users and Computers snap-in under Administrative Tools. 2. Expand the domain name. Right-click the Users container, click New, and then click Group. 3. On the New Object Group page, type salesgrp in the Group name text box, and complete the group creation process. To add the salesuser user under the salesgrp group 1. Double-click the salesgrp group that was created previously. 2. On the Properties page, click the Members tab. 3. Click Add, add salesuser, and complete the setup. To create and assign appropriate permissions to the SalesData share 1. Log on to the file server MONAS as domain administrator, create a folder named SalesData, and then open the folder properties. On the Security tab, click the Advanced button. 2. Clear the Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here check box. 3. Click the Remove button in the message box that appears, and click OK. 4. Add the salesgrp group, and ensure that the group has Read & Execute, List Folder Contents, Modify, Write and Read permissions. Add the Domain Admins group, and ensure that the Domain Admins group has Full Control permissions. 5. Share the folder. Add the salesgrp group, and grant Change and Read permissions. Add the Domain Admins group and grant Full Control permissions. Remove any other users or groups from the permissions list. 6. Click OK to save the changes, and complete the setup.

243 Chapter 7: Installing and Configuring File Sharing and Print Services 227 To create a DFS link under the DFS root that was created previously 1. On the MONAS server, open the Distributed File System console. Right-click the DFS root (for example, \\BusinessName.com\AllShares), and click the New Link button. 2. Enter the following link properties: a. Link Name; for example, Sales Data b. Path to Target; for example, \\MONAS\SalesData 3. Save the changes. Real World Lucerne Publishing wanted to add the firewall client software share that was already created on the firewall server (MOISA) to their DFS root structure. This would allow the internal domain users in the main office to access the firewall client share by using DFS link and install the software on their computer. The firewall client software share is created as part of ISA Server 2004 software installation on MOISA, as prescribed in Chapter 3, Installing and Configuring Firewalls. To add the existing firewall client software to the DFS root structure 1. In the DFS console, right-click the DFS root (for example, \\BusinessName.com\AllShares), and click the New Link button. 2. Enter the following link properties: a. Link Name; for example, Firewall Client. b. Path to Target; for example, \\MOISA\mspclnt. 3. Save the changes. From an internal client computer, type \\BusienssName.com\AllShare and browse to the firewall client folder. You should be able to access the firewall client setup file. Note that even though the share is stored on the MOISA server, the user just needs to remember the DFS root name, and does not need to know the server name (MOISA) and the folder name (mspclnt) where the firewall client software is actually located. Configuring Shadow Copies of Shared Folders Configuring Shadow Copies of Shared Folders involves server-side and client-side configurations. The following sections discuss these configurations in detail. Server-Side Configuration You can configure Shadow Copies of Shared Folders on either the network-attached storage device or the primary infrastructure server.

244 228 Microsoft Windows Server System Deployment Guide for Midsize Businesses To configure Shadow Copies of Shared Folders on the network-attached storage device 1. On the Web UI, click the Disks tab, and click the Shadow Copies link. 2. Select the volume on which Shadow Copies of Shared Folders needs to be enabled, and click the Enable button. 3. Select the volume on which Shadow Copies of Shared Folders is enabled, and click Properties to define the maximum size limit for storing snapshots for the selected volume. It is recommended to leave the default value and click Cancel. If you have modified the settings, click OK to save the changes. 4. Select the volume on which Shadow Copies of Shared Folders is enabled and click the Set Schedule to define the scheduling of snapshots. Modify the scheduling based on your business requirement and click OK to save the changes. If you want to leave with the default value, click Cancel. To configure Shadow Copies of Shared Folders on the primary infrastructure server 1. Open the Windows Explorer (by using Start>All Programs>Accessories) and select the volume on which Shadow Copies of Shared Folders needs to be enabled. In this solution, this should be the data volume. 2. Right-click the volume, and click Properties. 3. Click the Shadow Copies tab, and then click Settings. Here, perform the following tasks: a. Define the maximum size for the shadow copies. b. Schedule the shadow copies as per the business requirement. 4. Click Enable if Shadow Copies of Shared Folders is not already enabled. 5. On the Enable Shadow Copies page, click Yes to accept the pop-up message regarding shadow copies. Client-Side Configuration Each client computer must have the client software for Shadow Copies of Shared Folders installed on it to access the shadow copies stored on the server. Note The client software for Shadow Copies is installed by default if you are using Windows XP SP2 or later. Group Policy is used to install the client software on multiple systems. For more information on using Group Policy, refer to Chapter 9, Managing Desktops by Using Group Policy. After installing Shadow Copies of Shared Folders client, no further client configurations are needed.

245 Configuring Folder Redirection Chapter 7: Installing and Configuring File Sharing and Print Services 229 The My Documents, Application Data, and Desktop folders redirection will be configured when implementing the Group Policy recommended in the Chapter 9. For more information on configuring folder redirection, refer to /windowsserver2003/technologies/management/user01.mspx. Configuring Disk Quotas on the Primary Infrastructure Server Perform the following steps to configure disk quotas: 1. Right-click the data volume on the primary infrastructure server, and click Properties. 2. Click the Quota tab. 3. Perform the following steps: a. Enable Disk Quota Management. b. Select Quota Entries to define the disk quota for individual user. Define the warning level and the maximum limit for the user. c. Enable the Log event when a user exceeds their quota limit and Log event when user exceeds the warning level logging options. 4. Click OK to accept the Disk Quota warning message, and complete the configuration. Configuring Windows Storage Server Begin by gathering the information required for the initial configuration of Windows Storage Server. This enables the administrator to complete the deployment quickly and easily. Gather the following for the initial configuration of the storage server: Host name to be assigned to the storage server. IP address to be assigned to the storage server network adapter. Refer to Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server 2003, which defines the IP addressing scheme for the medium business. Active Directory domain name and Domain Administrator privileges to join the server to the Active Directory domain. Documents and media required for implementing antivirus and backup solutions. In addition, the following will help the administrator in managing file services efficiently: A list of names of folders and shares that need to be created, along with the users and groups and the permissions they need to access shares and data. A policy document on storage space restrictions to be placed on the users in the environment. A data backup and restore policy.

246 230 Microsoft Windows Server System Deployment Guide for Midsize Businesses Configuring the Hardware and Operating System The Windows Storage Server 2003 based network-attached storage device comes preinstalled with the operating system. Perform the following tasks to set up the server: 1. Place the device in a suitable location that meets the electrical, mechanical, environmental, and network connection requirements specified in the product documentation. 2. Connect the device to the same network as the infrastructure servers. Establish the required connections, and turn on the server. Performing the Initial Network Configuration The following section provides the steps that are necessary to perform network configuration of the Windows Storage Server 2003 appliance. In the test scenario, the HP NAS 2000s Windows Storage Server 2003 was used to implement file services. Windows Storage Server 2003 can be configured by using the Web UI (user interface). Depending on the OEM, the Web UI can be accessed in different ways. For example, the Web UI running on the HP NAS 2000s server can be accessed by using the following methods: RapidLaunch Remote browser Direct attach The remote browser method was used to access Windows Storage Server 2003 from the primary infrastructure server. Accessing the Web UI Perform the following steps to access the Web UI: 1. Open the Web browser of a system that is running on the same network as MONAS. 2. Type of the NAS server>-:3202 in the Address bar. Refer to the installation guide to locate the serial number on the server; for example, 3. Accept the security alert warning related to the SSL certificate. 4. Log on to the Web UI, using the default user name and password provided by the OEM. For information on the default user name and password, refer to the installation guide. Now MONAS can be configured by using various tabs and links in the Web UI. Note that OEMs have their own customized Web UI. However, most of the features are common to all OEMs.

247 Chapter 7: Installing and Configuring File Sharing and Print Services 231 Changing the Default Password After logging on to MONAS, perform the following steps to change the default Administrator password: 1. On the Web UI, click the Network link and then click the Administrator link. 2. Change the default password, and enter a new password that conforms to the password policy of the organization. Note that this is the local administrator password. 3. On the Administrator Account page, click OK. Changing the Date and Time Perform the following steps to change the date and time on MONAS: 1. On the Web UI, click the Maintenance link, and then click the Data/Time link. 2. On the Date and Time Settings page, enter the correct date and time and the time zone appropriate to your location. Click OK to save the changes. Changing the Host Name Performing the following steps to change the host name and join the server into the Active Directory domain: 1. On the Web UI, click the Network link and then click the Identification link. 2. Enter the name of the server in the Server name text box for the Windows Storage Server 2003 according to the naming convention decided by your organization. For recommendations on host naming conventions, refer to Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server In the DNS suffix text box, enter the DNS domain name suffix (for example, BusinessName.com). 4. Join the server into the Active Directory domain by performing the following steps: a. Under Member of, click the Domain option, and in the text box, type the Active Directory domain name. b. In the User text box, type domain name\user name for the user who has the privileges for joining the server into the Active Directory domain. c. In the Password text box, type the corresponding password. d. Click OK. e. The server prompts you to restart. Now restart MONAS.

248 232 Microsoft Windows Server System Deployment Guide for Midsize Businesses Note From this point onward, perform all the installation and configuration tasks on MONAS by logging on as the domain administrator and accessing the Web UI, using the host name MONAS. For example, use or Configuring the Network Interface As recommended by this book, the MONAS should be configured as a DHCP client and should be assigned reserved IP addresses by configuring both the DHCP servers. After the server restarts, perform the following steps to make DHCP reservations: 1. Ensure that the DHCP servers are running. 2. Perform the following steps to determine the MAC address of the LAN interface of MONAS that is connected to the LAN: a. Log on to MONAS by using Web UI. b. On the Web UI, click Maintenance and then click Remote Desktop. c. Log on to MONAS again. d. On the Windows desktop, click Start, click Run, and type cmd to get to the command prompt. e. Run the ipconfig /all command, and note the MAC address of the network adapter that is currently connected to the network. f. Exit the Remote Desktop Connection session. 3. Log on to the DHCP server and perform the following steps to reserve an IP address. (You need to perform these steps on both the DHCP servers.) a. Open the DHCP Microsoft Management Console (MMC) snap-in. b. Expand the appropriate DHCP scope. c. Right-click Reservations, and then click New Reservation. d. Reserve an IP address for MONAS with the MAC address that you noted earlier. Note that the IP address is in accordance with the IP addressing scheme of the organization. For information on designing IP addressing scheme, refer to Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server Restart MONAS by performing the following steps: a. On the Web UI, click Maintenance, and then click Shutdown. b. Click Restart, and then on the Restart Confirmation page, click OK.

249 Chapter 7: Installing and Configuring File Sharing and Print Services 233 Warning Running ipconfig /release on the Windows Storage Server during a Remote Desktop session disconnects you from the Windows Storage Server. Because the IP address is released, you cannot even access the Web UI. Therefore, you should avoid using ipconfig/ release on the command prompt. Creating the Disk Volume The hard disks that were meant for storing data should be used to create the data and backupto-disk volumes, and should be formatted with the NTFS file system. The data volume is used to store business data and the backup-to-disk volume is used for disk-based backup of data. The built-in disk configuration utility can be used to create the data volume. On MONAS, the Array Configuration Utility link was used to create the volume. For more information, refer to the installation guide that was provided by the OEM. Configuring the Server Message Block Typically, the SMB protocol is enabled when the File and Print Sharing for Microsoft Networks option is enabled on the computer on which the file services will be implemented. Perform the following steps, using the Web UI on the network-attached storage device to create and configure a share to provide file sharing by using the SMB protocol: 1. Browse to the MONAS Web UI. 2. Click the Shares tab, click the Shares link, and then under Tasks, click the New button. 3. Under General, create a folder, and provide the path and name of the share. 4. Select the Create folder option, and verify that the Windows (Microsoft SMB) option is selected. 5. Click Windows Sharing, and define appropriate permissions. 6. Click OK to save the changes. Configuring the Disk Quota in Windows Storage Server 2003 Perform the following steps to configure quotas on the Windows Storage Server by using the built-in disk quota feature of Windows Server 2003: 1. Click the Disks link on the Web UI, and then click the Volumes tab. 2. Click the Set Default Quota button, and configure quota entries for new users and users whose quota limits have not already been set. 3. Click the Set Quota Entries button, and then modify existing quota entries and add new entries.

250 234 Microsoft Windows Server System Deployment Guide for Midsize Businesses If non Microsoft software is used to implement the disk quota, refer to the product documentation for configuring it. Monitoring and Alerting Windows Storage Server provides various tools that can be used to monitor and manage the server. The primary tools include: Alert through event logging and Monitoring logs The Status page in the Web UI Event logging should be enabled on the primary infrastructure server on which the file services are running. In addition, it is recommended to enable auditing on both the servers. Validating the File Server Security Configuration After completing all file services-related configurations, it is important to ensure that the server is secured properly before moving it to the production network. Perform the following steps to ensure that the server is secured properly: 1. Install the latest Windows Server 2003 updates. 2. It is recommended to install suitable antivirus software on the server and ensure that it is updated with the latest virus definition files. 3. Run the MBSA (Microsoft Base Security Analyzer) tool against the network-attached storage server, from the primary infrastructure server on which MBSA is installed. If the file services are installed on the primary infrastructure server, the MBSA tool must be run on the local system. Based on the result, take appropriate action. Configuring Printers That Connect to the LAN Install and configure the network-attached printer by performing the following steps: 1. Connect the network printer to the network, and install it as recommended by the manufacturer. This includes tasks such as installing the toner and loading the paper tray, connecting the printer to the network, and powering on the printer. 2. Using the control panel on the printer, assign a host name to the printer according to the host naming convention. 3. Get the MAC address of the LAN interface of the printer. Refer to the product manual for guidance on how to find the MAC address of the printer. In general, the MAC address can be obtained by printing out the printer configuration page from the printer s control panel.

251 Chapter 7: Installing and Configuring File Sharing and Print Services Perform the following steps on both the primary and secondary infrastructure servers (MOCOR1 and MOCOR2) to create DHCP reservations for the MAC address of the printer. Note that the IP address that needs to be assigned to the printer is based on the IP addressing scheme of your organization; this information was gathered in the Gathering Information for Initial Configuration section of this chapter. a. Open the DHCP MMC snap-in. b. Expand the appropriate DHCP scope. c. Right-click Reservations, and click New Reservation. d. Enter the IP address that needs to be reserved for the printer and the MAC address of the printer. e. Switch off the printer, and then switch it back on. Verify that the printer gets the reserved IP address. Configuring the Print Server Set up the print server by performing the following steps on the Windows Storage Server 2003 based network-attached storage device (MONAS): 1. Under Administrative Tools on MONAS, open the Configure Your Server Wizard. 2. On the Server Role page, select Print Server from the list of server roles, and then click Next. 3. On the Printers and Printer Drivers page, select Windows 2000 and Windows XP clients only. If you want to add support for other operating systems, select All Windows clients. 4. In the Add Printer Wizard, under the Local or Network Printer page, click the Local printer attached to this computer option, clear the Automatically detect and install my Plug and Play printer check box, and click Next. Note Although the printer is connected to the network and not directly attached to the print server, it is treated as local printer of the print server. 5. On the Select a Printer Port page, click Create a new port, in the Type of port dropdown menu, click Standard TCP/IP Port, and then click Next. 6. In the Add Standard TCP/IP Printer Port Wizard, on the Add port page, type the host name or IP address of the printer. 7. In the Add Printer Wizard, on the Install Printer Software page, click the name of the manufacturer, and select the correct printer model from the list. If the printer model

252 236 Microsoft Windows Server System Deployment Guide for Midsize Businesses does not appear in the list, click the Have Disk button, select a compatible driver, and install the printer driver software. 8. On the Name Your Printer page, provide a printer name in the Printer name text box. 9. On the Printer Sharing page, click Share name and provide a printer share name in the text box. 10. On the Location and Comment page, provide the location of the printer and relevant comments in the Location and Comment text boxes, respectively. Providing the location name and comments will help the network user to locate the printer that is nearest to his/her location by using Active Directory. 11. Print a test page, and ensure that the printer is working properly. Adding Printers Connected to Client Computers The client computers in the environment should be configured to access the network printer. After configuring and testing the printer connected to the network as specified in the Configuring the Print Server section earlier in this chapter, add the printer on the client computer. Configuring Client Computers to Access Network Printers Directly by Using TCP/IP The printers connected to the LAN in the branch offices, where there is no print server, can be accessed by configuring the client computers to directly access the printer by using TCP/IP. The client will send the print data directly to the TCP/IP port of the printer and not to a print server. Each client computer in the branch office network will need to be configured to access the printer directly. Configuring Directly Attached Printers A printer can be directly attached to the computer by using a parallel, serial, or USB cable. The printer needs to be configured to enable the local user of the computer to print to the directly attached printer. Sharing the Directly Attached Printers A printer that is directly attached to a computer can be shared so that more than one user can use it. For guidance on configuring a directly attached printer and then sharing the printer for a group of users, refer to Windows Help. Restricting Access to Printers If your design calls for restricting access to certain printers, you can do so by using printer permissions.

253 Chapter 7: Installing and Configuring File Sharing and Print Services 237 Real World Lucerne Publishing configured the high-cost color laser printer with appropriate permissions to restrict access exclusively to the staff in the graphics department. The printer is directly connected to a parallel port on the computer of one of the employees of the graphics department. Restricting access to printer to employees of the graphics department involved the following tasks: 1. Create a user group called Graphgrp in the Active Directory domain. 2. Create a user called Graphuser in the Active Directory domain. 3. Add the Graphuser user to the Graphgrp group. 4. Modify printer permissions to restrict access to Graphgrp. To create a group called Graphgrp in the Active Directory domain 1. On MOCOR1, open the Active Directory Users and Computers snap-in under Administrative Tools. 2. Expand the domain name. Right-click the Users container, click New, and then click Group. 3. On the New Object Group page, type Graphgrp in the Group name text box, and complete the group creation process. To create a user called Graphuser in the Active Directory domain 1. On MOCOR1, open the Active Directory Users and Computers snap-in under Administrative Tools. 2. Expand the domain name. Right-click the Users container, click New, and then click User. 3. On the New Object User page, enter Graphuser in the first box, and Graphuser@ BusinessName.com in the Users logon name box. Provide a strong password for this user according to the security policy of the organization. 4. If you do not want to create an Exchange mailbox for this user, clear the Create an Exchange mailbox check box. 5. Complete the user creation process. To add the user Graphuser to the Graphgrp group 1. Double-click the Graphgrp group, and on the Properties page, click the Members tab. 2. Click Add, add Graphuser, and then complete the setup. To modify printer permissions to restrict access to the printer 1. Log in by using an administrator account on the client computer. 2. In Control Panel, open the Printers and Faxes folder.

254 238 Microsoft Windows Server System Deployment Guide for Midsize Businesses 3. Right-click the icon for the printer to which you want to restrict access, and click Properties. 4. To remove extraneous group members, on the Security tab, remove all entries in the Groups or user names list box except Administrator and Creator Owner. 5. To grant access to the printer, click Add, and include the Graphgrp group. Publishing Printers By default printers that are added by using the Add Printer Wizard are published in Active Directory. If you want to manually add the printer to Active Directory, perform the following steps on the print server or the client computer from which the printer is shared: 1. In Control Panel, open the Printers and Faxes folder. 2. Right-click the icon for the printer that you want to publish in Active Directory, and click Properties. 3. On the Sharing tab, select the List in the directory check box. Implementing Group Policy Related to Printers If you are planning to implement the Group Policy objects (GPOs), the GPOs related to publishing printers and restricting the installation of kernel-mode print drivers will be applied as part of that implementation. If you are not implementing the recommended GPOs, manually define a GPO to publish printers automatically and to prevent installation of kernel-mode (Version 3) print drivers by performing the following steps: 1. Open the Active Directory Users and Computers snap-in, right-click the domain, and click Properties. 2. Click the Group Policy tab, and create a new policy named Printing Policy. 3. Edit the policy according to the configurations listed in Table 7-1, and then exit and close the policy. Table 7-1 Group Policy Configuration for Printing Purpose Location Setting Automatically publish new printers in Active Directory. Block the installation of kernel-mode drivers. Computer Configuration \Administrative Templates\Printers Computer Configuration \Administrative Templates\Printers Automatically publish new printers in Active Directory. State: Enabled Disallow installation of printers by using kernel-mode drivers. State: Enabled

255 Validating Print Services Chapter 7: Installing and Configuring File Sharing and Print Services 239 It is very important to test various printers in the environment to ensure that they are working as expected before releasing the services to users. In addition, the printing capability should be tested from different versions of Windows operating systems running in the environment. If required, appropriate drivers should be installed on the print server. Testing the Network Configuration Test the network configuration by performing the following steps: 1. Ping the network printer from a client to ensure that it gets the correct IP address. In addition, print out a configuration page of the printer and verify that it printed correctly. 2. Use the nslookup command for DNS name resolution of the network printer. Testing the Network Printer Configuration Test the configuration of the network printer by performing the following steps: 1. Log on to a Windows client computer as a domain test user. 2. Connect to the shared printer. 3. Perform a test print. Backing Up the Print Server Configuration It is strongly recommended that you perform a full backup of the file and print server, including the state information, before releasing the system to the users in the production environment. In addition, whenever a new configuration is made or existing configuration is modified, a backup should be performed.

256

257 Chapter 8 Installing and Configuring Microsoft Windows SharePoint Services Microsoft Windows SharePoint Services allows teams to create Web sites for information sharing and document collaboration, benefits that help increase individual and team productivity. No matter how large or small your organization, the users inside your organization have data, documents, and thoughts to share with each other. You can install Windows SharePoint Services on a single server to support a small to medium organization, or you can create a server farm environment to support a large, multinational organization. In a small to medium organization, you can install and run Windows SharePoint Services without a lot of overhead. For example, you can: Use the single server installation to get a site up and running quickly. Turn on Self-Service Site Creation to allow users to build sites as needed. Enable full-text searching so your users can easily find the information and documents they need. Instead of just dumping files into directories, Windows SharePoint Services supplies Web sites with document storage and retrieval with check-in and check-out functionality, version history, custom metadata, and flexible, customizable views. Users can find and share data, with the added assurance that data will not be lost. SharePoint sites store event calendars, contacts, Web links, discussions, issues lists, announcements, and much more. By using Windows SharePoint Services, you can create smart places that help your users share information and get work done, not just places to save files. You can grant users the ability to create sites, allow them to control site membership, monitor site usage directly, and moderate content submissions. Users can even create site templates and share them with one another, reusing customized, proven site solutions. Despite the authority delegated to users, Windows SharePoint Services also enables you to track which sites are created, who owns them, how long a site has gone unused, and so on. You can enforce quotas for sites, users, and storage; block users from adding specific file types to sites; and automatically delete sites that are unused for long periods of time. You can manage and configure Windows SharePoint Services right out of the box by using a Web browser or command-line utilities. You can also manage server farms, servers, and sites 241

258 242 Microsoft Windows Server System Deployment Guide for Midsize Businesses by using the Microsoft.NET Framework based object model and Web services, making possible a great many custom and third-party administration solution offerings. You can also use SharePoint Services as an extranet server, but that is beyond the scope of this book. For more information, see the References section at the end of this chapter. Installing SharePoint The quickest way to get started with SharePoint Services is to install it on a single server. This allows you to set up a small-scale installation to host several Web sites, without performing a lot of steps. When you install Windows SharePoint Services on a single server, you can choose between the following options: When you install Windows SharePoint Services using the default settings, the Setup program automatically installs Microsoft Windows SQL Server 2000 Desktop Engine (WMSDE) and uses it to create the database for your Web sites. You don t have to perform any other configuration steps to create the database. This installation scenario offers you the ability to host several Web sites without a lot of overhead. By using the remotesql=yes property, you can install Windows SharePoint Services to work with an existing installation of Microsoft Windows SQL Server 2000 Service Pack 3 or later. This installation scenario allows you to support a larger set of Web sites. When you use this method, you must perform additional steps to configure SQL Server and Windows SharePoint Services to work together. Consider using SQL Server instead of WMSDE if you expect to support more than 10 large, active Web sites. Note The database size required for Windows SharePoint Services depends on the number and size of the Web sites your server supports. Preparing the Server Before you install and configure Windows SharePoint Services, you should check to make sure you meet the hardware and software requirements. The following sections help you review the requirements. Hardware and Software Requirements To be able to set up Windows SharePoint Services on a single server, you must use a computer running Microsoft Windows Server 2003 (Standard, Enterprise, Datacenter, or Web Edition). The hardware requirements for Windows SharePoint Services are the same as the Windows

259 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 243 Server 2003 installation requirements. The computer must be configured as a Web server running Internet Information Services (IIS) in IIS 6.0 worker process isolation mode and must be running ASP.NET. For more information about installing and configuring IIS and ASP.NET, see the Windows Server 2003 documentation. The computer must be using the NTFS file system. Microsoft Windows includes a conversion utility (Convert.exe) that you can use to convert an existing file allocation table (FAT) volume to NTFS without losing data. The client computers must be running Microsoft Internet Explorer 5.01 or later (best results with Microsoft Internet Explorer 5.5 or later) or Netscape Navigator 6.2 or later to use Windows SharePoint Services features. Configuring the Server as a Web Server IIS is not enabled by default in Windows Server To make your front-end server into a Web server, you must enable IIS. To enable IIS and configure it to use IIS 6.0 worker process isolation mode 1. Click Start, point to All Programs, point to Administrative Tools, and then click Manage Your Server. 2. On the Manage Your Server page, click Add or remove a role. 3. In the Preliminary Steps pane, click Next. 4. In the Server Role pane, click Application server (IIS, ASP.NET), and then click Next. 5. In the Web Application Server Options pane, accept the default of ASP.Net, and then click Next. 6. In the Summary of Selections pane, click Next. 7. Click Finish. 8. Click Start, point to All Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager. 9. In Internet Information Services manager, click the plus sign (+) next to the server name, and then right-click the Web Sites folder and select Properties. 10. In the Properties dialog box, click the Service tab. 11. In the Isolation mode section, clear the Run WWW service in IIS 5.0 isolation mode check box, and then click OK. Note The Run WWW in IIS 5.0 isolation mode check box is selected only if you have upgraded to IIS 6.0 on Windows Server 2003 from IIS 5.0 on Windows New installations of IIS 6.0 use IIS 6.0 worker process isolation mode by default.

260 244 Microsoft Windows Server System Deployment Guide for Midsize Businesses Installing Windows SharePoint Services with WMSDE Because you are installing to a single, stand-alone server, you can run the Setup program as is, accepting all the defaults. In the default installation, WMSDE is installed as part of the Setup program. Caution During Setup, in a default installation, the default virtual server (Default Web site in IIS) is extended with Windows SharePoint Services. If you have a Web site running on the default Web site in IIS, that Web site will be taken over by Windows SharePoint Services during installation. Also, before installing Windows SharePoint Services, verify that FrontPage 2002 Server Extensions from Microsoft are not running on the virtual server on port 80. If FrontPage 2002 Server Extensions are running on the default virtual server, the virtual server will not be extended when you install Windows SharePoint Services. (If you upgraded from Windows 2000 to Windows Server 2003, FrontPage 2002 Server Extensions were installed by default to port 80.) To install Windows SharePoint Services with default settings 1. Download STSV2.exe to your computer. You can download STSV2.exe from the Microsoft Windows Update Web site. 2. Run STSV2.exe to extract the installation files and start the installation. 3. On the End-User License Agreement page, review the terms, select the I accept the terms in the License Agreement check box, and then click Next. 4. On the Type of Installation page, click Typical Installation, and then click Next. 5. On the Summary page, click Install. 6. Setup runs and installs Windows SharePoint Services and WMSDE. To install Windows SharePoint Services specifying the location of the WMSDE database If you want to specify the location to install the WMSDE database, use the /datadir= option with the setupsts.exe command line tool. The syntax is as follows: setupsts.exe /datadir="path\\" For example, to install the WMSDE database to the D:\Program Files\wmsdedata\ folder, type the command: setupsts.exe /datadir="d:\program Files\wmsdedata\\"

261 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 245 To download and install Windows SharePoint Services, specifying the location of the WMSDE database 1. Download STSV2.exe to your computer. You can download STSV2.exe from the Microsoft Windows Update Web site. 2. Run STSV2.exe to extract the installation files. 3. When the Windows SharePoint Services installation starts, click Cancel. 4. Click Start, and then click Run. 5. In the Open box, type C:\Program Files\STS2Setup_<LCID>\setupsts.exe /datadir="<path>\\" (where "LCID" is the locale ID for the version you installed, and "path" is the path where you want to install WMSDE). For example, if you installed the US English version of STSV2.exe, the folder is C:\Program Files\STS2Setup_ Click OK. The Windows SharePoint Services Setup program opens. 7. On the End-User License Agreement panel, review the terms, select the I accept the terms in the License Agreement check box, and then click Next. 8. On the Type of Installation page, click Typical Installation, and then click Next. 9. On the Summary page, click Install. 10. Setup runs and installs Windows SharePoint Services and WMSDE to the specified path. After Installing Windows SharePoint Services with WMSDE After Setup finishes, your default Web site is extended with Windows SharePoint Services. Your browser window opens to the home page of your new Web site, and you can start adding content right away, or you can customize the site or set administrative options by using HTML Administration pages. Some actions you can take to get users working with your site are: Adding users to the site. For more information, see Managing Users and Cross-Site Groups later in this chapter. Customizing the home page and other pages in the site. For more information, see Customizing a Web Site Based on Windows SharePoint Services at /resources/documentation/wss/2/all/adminguide/en-us/stsh01.mspx. Setting up version control. For more information, see Managing Versions and Checking Documents In and Out at /adminguide/en-us/stsf07.mspx.

262 246 Microsoft Windows Server System Deployment Guide for Midsize Businesses If you have multiple virtual servers, you can extend additional virtual servers with Windows SharePoint Services. To extend a virtual server, you use HTML Administration pages. For more information, see Extending Virtual Servers at: /wss/2/all/adminguide/en-us/stsd03.mspx. Note If you have a previous version of SharePoint Team Services or FrontPage Server Extensions, you need to upgrade the virtual server, rather than extend it. For more information, see Upgrade Considerations at /adminguide/en-us/stsb04.mspx. After you have used Windows SharePoint Services with WMSDE for some time, you might run into performance or storage problems, and you might need to move to a more scaled out solution. If you find yourself in this situation, you can switch to using Microsoft SQL Server 2000 as your database instead of WMSDE. For more information, see Migrating from WMSDE to SQL Server at /stsf17.mspx. Installing Windows SharePoint Services to Use SQL Server Before you are ready to install Windows SharePoint Services, you must be sure that SQL Server 2000 is installed with Service Pack 3 or later and ready to host Windows SharePoint Services data. If you want to use Windows SharePoint Services with SQL Server 2000 on the same computer, you must take specific steps to configure your server computer before, during, and after installing Windows SharePoint Services. For example, to set up Windows SharePoint Services, you must run Setup from the command line, using the remotesql=yes property. This section describes the steps needed to configure a single server running both Windows SharePoint Services and SQL Server This section does not cover using a remote SQL Server computer. Preparing SQL Server You must configure your SQL Server installation to work with Windows SharePoint Services. For Windows SharePoint Services to be able to connect to your SQL Server database, it is recommended that you configure the SQL Server database to use Windows authentication. To enable Windows authentication for SQL Server 1. On your server computer, click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager. 2. In Enterprise Manager, click the plus sign (+) next to Microsoft SQL Servers. 3. Click the plus sign (+) next to SQL Server Group. 4. Right-click the SQL Server name, and then click Properties.

263 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services In the Properties dialog box, click the Security tab. 6. Under Authentication, select Windows only, and then click OK. Running Setup By default, when you install Windows SharePoint Services, the Setup program installs WMSDE. To use Windows SharePoint Services with SQL Server, you must install Windows SharePoint Services without installing WMSDE. To do so, you run the Setup program with the remotesql command-line option. For more information, see the Administrator s Guide for Windows SharePoint Services at /adminguide/en-us/stsc02.mspx. To install Windows SharePoint Services without installing WMSDE 1. Download STSV2.exe to your computer. You can download STSV2.exe from the Microsoft Windows Update Web site. 2. Run STSV2.exe to extract the installation files. 3. When the Windows SharePoint Services installation starts, click Cancel. 4. Click Start, and then click Run. 5. In the Open box, type C:\folder\setupsts.exe remotesql=yes (where c:\folder is the path to the Setupsts.exe file on your local computer). For example, if you installed the US English version of STSV2.exe, the folder is C:\Program Files\STS2Setup_ Click OK. The Windows SharePoint Services Setup program opens. 7. On the End-User License Agreement page, review the terms, select the I accept the terms in the License Agreement check box, and then click Next. 8. On the Type of Installation page, click Server Farm, and then click Next. 9. On the Summary page, verify that only Windows SharePoint Services will be installed, and then click Install. 10. Setup runs and installs Windows SharePoint Services. After Installing Windows SharePoint Services to Use SQL Server After the Setup process is complete, you can configure your administrative virtual server (including specifying an application pool to use for the virtual server processes), connect to SQL Server, and then configure your virtual servers with Windows SharePoint Services. You perform these steps by using HTML Administration pages.

264 248 Microsoft Windows Server System Deployment Guide for Midsize Businesses To configure the administrative virtual server 1. On the Configure Admin Virtual Server page, in the Application Pool section, select Create a new application pool. Note You can also use an existing application pool, but any Web application that is using the same application pool can modify the Windows SharePoint Services databases. This is a potential security risk. 2. Type the name to use for the new application pool, and then specify whether to use a predefined or configurable security account for the application pool. If you selected Predefined, select the security account to use. If you selected Configurable, type the user name and password to use. 3. The account you use must have rights to create databases in SQL Server. In other words, this account must be a member of the Security Administrators, Process Administrators, and Database Creators roles in SQL Server. 4. Click OK. If you have used an account that does not already have database creation rights in SQL Server, you can give the account this access in SQL Server Enterprise Manager. This is a one-time-only change. Once you have granted database creation permissions to the account used by the Windows SharePoint Services administration virtual server, this account can create databases for any subsequent virtual servers. To grant database creation rights in SQL Server 1. On your server computer, click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager. 2. In Enterprise Manager, click the plus sign (+) next to Microsoft SQL Servers, click the plus sign (+) next to SQL Server Group, and then click the plus sign (+) next to your SQL Server computer s name. 3. Click the plus sign (+) next to Security, and then right-click Logins, and click New Login. 4. In the Name box, type the account in the format DOMAIN\name. 5. Click the Server Roles tab. 6. In the Server Role list, select the Security Administrators, Process Administrators, and Database Creators check boxes, and then click OK. After you configure the administrative virtual server (and grant SQL Server rights to the new application pool account, if necessary), you must restart Internet Information Services (IIS)

265 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 249 by typing iisreset on the command line. After IIS is reset, you can click the link on the Application Pool Changed page to continue configuring Windows SharePoint Services to work with SQL Server. To connect to SQL Server 1. On the Set Configuration Database Server page, in the Configuration Database section, enter the server name and database name to use. 2. Under Database connection type, select Use Windows integrated authentication (more secure, recommended). 3. Click OK. Extending a Virtual Server with Windows SharePoint Services After you set up the connection to SQL Server, you are ready to extend your virtual servers with Windows SharePoint Services. When you extend a virtual server, Windows SharePoint Services is applied to a virtual server, and a top-level Web site is created. To extend a virtual server, you use HTML Administration pages. To extend a virtual server with Windows SharePoint Services and connect to SQL Server 1. On the SharePoint Central Administration page, click Extend or upgrade virtual server. 2. On the Virtual Server List page, click the name of the virtual server to extend. 3. On the Extend Virtual Server page, in the Provisioning Options section, select Extend and create a content database. 4. In the Application Pool section, select either Use an existing application pool or Create a new application pool. Note It is recommended that you create a new application pool for each virtual server so that they run in separate processes. This application pool should use a domain account, but it does not need to have database creation rights in SQL Server the administration virtual server account will create any databases required. If you selected Use an existing application pool, select the application pool to use. If you selected Create a new application pool, enter the new application pool name, user name, and password to use. 5. In the Site Owner section, in the Account name box, type the user name for the site owner (in the format DOMAIN\username if the user name is part of a Windows domain group). 6. In the address box, type the address that corresponds to the account.

266 250 Microsoft Windows Server System Deployment Guide for Midsize Businesses 7. In the Database Information section, select the Use default content database server check box, or type the database server name and database name to use for a new content database. 8. If you want to specify a path for the URL, in the Custom URL path box, type the path to use. 9. In the Site Language section, select the language to use. 10. Click OK. After a few moments, the virtual server is extended and a confirmation page is displayed. You can open the home page for your new Web site in your browser by using a link on the confirmation page. You can continue to extend other virtual servers or configure Self-Service Site Creation so that users can create their own sites. For more information about allowing users to create their own Web sites based on Windows SharePoint Services, see Configuring Self- Service Site Creation later in this chapter. Creating and Managing Sites and Subsites Web sites in Microsoft Windows SharePoint Services are organized into site collections. Each site collection has a top-level Web site. This top-level Web site can have multiple subsites, and each subsite can have multiple subsites. Because sites are nested in a hierarchy within the site collection, it can be challenging to manage them all. Note Local server administrators and members of the SharePoint administrators group can perform any task that a site collection administrator can perform for a site collection. You can use two methods to manage sites and subsites: HTML Administration pages: When you use HTML Administration pages to manage sites in a site collection, be aware that some features are available only from the top-level Web site. These features include managing site collection galleries, viewing storage space allocation, viewing the site hierarchy, and listing all users in the site collection. Command-line administration: If you use the command line to manage sites in a site collection, the levels are not as important, because you can always specify the full URL path for a site you want to manage, and you can adjust the URL to list sites and subsites at any level in the site collection. However, you must be a member of the administrators group for the local server computer to use the command-line tools.

267 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 251 Creating Top-Level Web Sites for Users You can give users the ability to create their own top-level Web sites by enabling Self-Service Site Creation. If you want to control top-level Web site creation yourself, however, you can disable Self-Service Site Creation and create top-level Web sites on your users behalf from SharePoint Central Administration. To create a top-level Web site outside of Self-Service Site Creation, you must be an administrator of the local machine on which the site will reside or a member of the SharePoint administrators group. Note When you are running a server farm with multiple host names or are in Active Directory account creation mode, you cannot create a top-level Web site from SharePoint Central Administration. To perform this action in Active Directory account creation mode, you must use the command line or object model. For more information, see Using the Object Model to Manage Windows SharePoint Services in the Administrator s Guide to Windows SharePoint Services at: /stsc02.mspx. To create a top-level Web site from SharePoint Central Administration 1. Click Start, point to All Programs, point to Administrative Tools, and then click Share- Point Central Administration. 2. Under Virtual Server Configuration, click Create a top-level Web site. 3. On the Virtual Server List page, click the virtual server under which you want to create the top-level Web site. 4. To create a site under a predefined URL path for the virtual server, on the Create Toplevel Web Site page, select Create site under this URL. Then in the Site name box, type the name for the top-level Web site, and in the URL path box, select the path to use. The name and URL path are combined with the server name to create the full URL to the site. For example, on if you create a top-level Web site at the /sites URL path, and use Site001 as the name, the full path to the new top-level Web site is 5. To create a site at a predefined URL path, select Create site at this URL, and then in the URL path box, select the URL to use for the top-level Web site. The site is created at the top level of the URL path you select. For example, on if you select /portal as the path, the site is created at 6. In the Site Collection Owner section, type the user name (in the form DOMAIN\username) and address (in the form [email protected]) for the user who will be the site owner and administrator.

268 252 Microsoft Windows Server System Deployment Guide for Midsize Businesses 7. If you want to identify a user as the secondary owner of the new top-level Web site (recommended), in the Secondary Owner section, type the user name and address for a secondary owner and administrator of the new site. 8. If you are using quotas, in the Quota Template section, select a quota template to use. 9. In the Site Language section, select the language to use for the top-level Web site. 10. Click OK. The site owner can select a template for the site when first browsing to the URL, or you can browse to the URL on the confirmation page and select one yourself. You must alert the site owner and secondary owner when you have created the site with the URL. They are not notified automatically when you create a site. Creating Subsites You can create a subsite of a current site by using the Manage Sites and Workspaces page. To create a subsite 1. On a site, click Site Settings. 2. Under Administration, click Manage sites and workspaces. 3. On the Manage Sites and Workspaces page, click Create. 4. On the New SharePoint Site page, in the Title and Description section, type the title and description for the new subsite. 5. In the URL name box, type the URL for your subsite. 6. In the User Permissions section, select either Use same permissions as parent site or Use unique permissions. Select Use same permissions as parent site if you want to share users with the parent site, or Use unique permissions if you want to maintain a separate list of users for your subsite. For more information, see Managing Site Groups and Permissions at 7. In the Language section, select the language to use. 8. Click Create. 9. On the Template Selection page, select a template to use, and then click OK. Managing Sites and Subsites by Using HTML Administration Pages You can use the HTML Administration pages to view a list of subsites within a site collection or for a particular subsite. You can also use HTML Administration pages to delete a site or subsite. Depending on your administrative access level, you can perform different actions:

269 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 253 Members of the local server s administrator group and members of the SharePoint administrators group can delete a site collection from SharePoint Central Administration. Site collection administrators can also delete a site collection by using the Top- Level Site Administration page. Deleting the site collection deletes the top-level Web site in that site collection, as well as any subsites. Members of the site collection administrators group can view a list of all subsites below the top-level Web site in that site collection from the View Site Hierarchy page. They can delete a specific subsite in the site collection or the entire site collection by navigating from the View Site Hierarchy page to the Site Administration page for the subsite or toplevel Web site (to delete a site collection). Members of the administrator site group for a subsite can see only the immediate subsites below their subsite. They can delete the subsites they see, provided that the subsites have no subsites beneath them. Viewing Subsites If you are a member of the administrator site group for a site, you can view a list of subsites from the Manage Sites and Workspaces page in Site Settings. This list displays only the immediate set of subsites for the current site (one level down). To view the list of immediate subsites for a site 1. On the site, click Site Settings. 2. On the Site Settings page, under Administration, click Manage sites and workspaces. If you are a site collection administrator, you can see the full list of subsites for the site collection (any subsites of the top-level Web site, plus any of their subsites) by using the View Site Hierarchy page in Site Administration. To view the entire list of subsites within a site collection 1. On the top-level Web site for the site collection, click Site Settings. 2. On the Site Settings page, under Administration, click Go to Site Administration. 3. Under Site Collection Administration, click View site hierarchy. Deleting a Site Collection If you are an administrator of the local server computer on which a site resides or a member of the SharePoint administrators group, you can use the Delete Site Collection page in the Central Administration or Virtual Server Administration pages to delete a site collection (a toplevel Web site and any subsites beneath it).

270 254 Microsoft Windows Server System Deployment Guide for Midsize Businesses Caution When you delete a top-level Web site, you also delete any subsites beneath it. Before you delete a site, be sure to verify that there are no subsites beneath it, or that you no longer need the subsites beneath it. You cannot recover a subsite unless you have a backup version of the subsite. For more information about backing up a site, see Backing Up and Restoring Databases by Using the SQL Server 2000 Tools in the Windows SharePoint Services Administrator s Guide at /en-us/stsf03.mspx. To delete a site collection from SharePoint Central Administration 1. Click Start, point to All Programs, point to Administrative Tools, and then click Share- Point Central Administration. 2. On the Central Administration page, under Virtual Server Configuration, click Delete site collection. 3. In the URL of the site to delete box, type the site s full URL. 4. Click OK. If you are the owner of or a site collection administrator for a top-level Web site, you can delete the top-level Web site by using the Delete This Site page in the Site Administration pages. To delete a site collection from Site Administration 1. On the subsite, click Site Settings. 2. On the Site Settings page, under Administration, click Go to Site Administration. 3. Under Management and Statistics, click Delete this site. 4. On the confirmation page, click Delete. Deleting a Subsite Depending on your administrative access level, you can use different methods to delete a subsite: If you are a member of the Administrator site group for the subsite you want to delete, you can use the Delete This Site page in Site Administration. If you are a member of the administrator site group for the site one level up from the subsite you want to delete, you can use the Manage Sites and Workspaces page in Site Settings for your subsite. Caution You cannot recover a subsite unless you have a backup version of it. For more information about backing up a site, see Backing Up and Restoring Databases by Using the SQL Server 2000 Tools in the Windows SharePoint Services Administrator s Guide at

271 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 255 To delete a subsite using the Delete This Site page 1. On the subsite, click Site Settings. 2. On the Site Settings page, under Administration, click Go to Site Administration. 3. Under Management and Statistics, click Delete this site. 4. On the confirmation page, click Delete. To delete a subsite from the Manage Sites and Workspaces page, you must use the Site Settings page for the site immediately above the subsite you want to delete. To delete a subsite by using the Manage Sites and Workspaces page 1. On the site above the subsite you want to delete, click Site Settings. 2. On the Site Settings page, under Administration, click Manage Sites and Workspaces. 3. On the Manage Sites and Workspaces page, next to the subsite you want to delete, click the Delete icon. 4. On the confirmation page, click Delete. Security and Self-Service Site Creation Self-Service Site Creation allows users to create and manage their own top-level Web sites automatically. This capability can obviously affect the security for your Web server running Windows SharePoint Services. Self-Service Site Creation is disabled by default you must turn on the feature to use it. You enable Self-Service Site Creation for a single virtual server at a time. If you want to use it on all virtual servers in your server farm, you must enable it for every virtual server individually. The Administration pages for Self-Service Site Creation are part of the virtual server administration pages, which can be accessed only by local computer administrators or members of the SharePoint administrators group. Access to the signup page follows the same security rules as other Web site pages. By default, the Use Self-Service Site Creation right is included in all site groups except the Guest site group, and gives users access to the signup page and the ability to use Self-Service Site Creation to create their own top-level Web sites. Because Self-Service Site Creation simply creates new top-level Web sites on an existing virtual server, any new sites automatically conform to the virtual server s quota settings, unused Web site notification settings, and other administrative policies. Managed Paths and Self-Service Site Creation By default, when you install Windows SharePoint Services, a URL path called /sites is added to your virtual server. When you enable Self-Service Site Creation, that path is the default path for sites that your users create. For example, a user can create MyTeamSite under /sites on

272 256 Microsoft Windows Server System Deployment Guide for Midsize Businesses Server 1. Using the defaults, the path for this site would be similar to the following: server/sites/myteamsite. You can use the default /sites path for users' Self-Service Site Creation sites, or you can create additional paths. You specify which URL paths are available for users to create sites under by adding managed paths. If you do add more URL paths for Self-Service Site Creation to use, when users go to the Scsignup.aspx page, they see a drop-down box listing the various paths available, and they can choose which path to create their site under. Enabling Self-Service Site Creation You can use either HTML Administration pages or the command-line tool to enable and configure Self-Service Site Creation. Either method allows you to turn Self-Service Site Creation on or off and allows you to specify required information for each site. Configuring Self-Service Site Creation from HTML Administration Pages To enable Self-Service Site Creation for a virtual server, use the Configure Self-Service Site Creation page for that virtual server. To enable Self-Service Site Creation 1. Click Start, point to All Programs, point to Administrative Tools, and then click Share- Point Central Administration. 2. On the SharePoint Central Administration page, under Virtual Server Configuration, click Configure virtual server settings. 3. On the Virtual Server List page, click the virtual server to enable. 4. On the Virtual Server Settings page, under Automated Web Site Collection Management, click Configure Self-Service Site Creation. 5. In the Enable Self-Service Site Creation section, next to Self-Service Site Creation is, select On. 6. If you want to require two contact names for each site, select the Require secondary contact check box. Requiring a secondary contact is highly recommended if you are using site use confirmation and have enabled automatic Web site deletion. 7. Click OK. To disable Self-Service Site Creation, go to the Configure Self-Service Site Creation page; next to Self-Service Site Creation is, select Off, and then click OK.

273 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 257 Managing Users and Cross-Site Groups Every Web site has users, and part of your job as administrator is to make sure the users of a Web site have the appropriate rights to use the site. To grant access to a site, users must be added to the site (either individually or as part of a cross-site group) and assigned to a site group. In Windows SharePoint Services, users and cross-site groups can be added by using one of two modes: Domain account mode: Used inside organizations to grant access to users and groups with existing domain accounts Active Directory account creation mode: Used by Internet service providers to create unique accounts for customers You determine which mode to use when you first install and configure Windows SharePoint Services, and you cannot switch between modes later. Whichever mode you use, you can add users and cross-site groups to your site by using either the command-line tool or HTML Administration pages for your Web site. Note Mixing account modes is not supported. You must choose either domain account mode or Active Directory account creation mode. Some organizations might need to be able manage accounts for both internal employees (in the organization s Active Directory directory service) and external customers (not in organization s Active Directory directory service). In these cases, one option is to choose domain account mode, use a separate forest for the external users, and then configure the external forest to trust the internal domain for adding internal users. About Domain Account Mode If you are using Windows SharePoint Services inside an organization that uses Microsoft Windows domain accounts, you can use domain account mode for user and cross-site group accounts. With domain account mode, you add users and cross-site groups to your site by using their existing domain account information, including their account names and addresses. And you can add Windows NT domain groups to your site, which is not possible in Active Directory account creation mode. Domain account mode is the standard mode for Windows SharePoint Services. You can use Active Directory directory service to manage domain accounts the difference between the modes is the type of account you use and when they are created, not the tool you use to manage them. About Active Directory Account Creation Mode If you host Web sites based on Windows SharePoint Services for customers on the World Wide Web, you can configure Windows SharePoint Services to automatically create Active Directory accounts for new users and cross-site groups. You must enable Active Directory account creation mode when you first configure Windows SharePoint Services.

274 258 Microsoft Windows Server System Deployment Guide for Midsize Businesses Using HTML Administration Pages to Manage Users and Cross-Site Groups The steps for adding users and cross-site groups are the same, no matter which account mode you are using. Using either method, you can manage users and cross-site groups from the Site Settings page for your Web site. To manage users and cross-site groups, you follow the Manage users link on the Site Settings page to the Manage Users page. By using this page, you can view a list of users and cross-site groups, check which site group a user or cross-site group is assigned to, add new users and cross-site groups, delete users and cross-site groups, or assign users and cross-site groups to site groups. When you add new users or cross-site groups, you also have the option to send an message to them, inviting them to use the site. You can even include a custom message in the invitation message. For example, you can describe your site and what it should be used for, or add a personal message to the default invitation. Note If you do not see the Manage users link on your Site Settings page, you are probably in a subsite that uses the permission settings of a higher-level Web site of the server or virtual server. To work with user accounts and permissions, either go to the parent-level Web site, or change to using unique permissions for the subsite. For more information about subsite permissions, see Managing Site Groups and Permissions in the Windows SharePoint Services Administrator s Guide at /en-us/stsf03.mspx. If you want to view which site groups a user is a member of, you can use the Manage Users page. To view site group membership for a user or cross-site group On the Web site you want to manage, click Site Settings. On the Site Settings page, under Administration, click Manage users. The users and cross-site groups added to the Web site and the site groups they are members of are displayed on the Manage Users page. From this page, you can change which site group a user or cross-site group is a member of. To change site group membership for a user or cross-site group 1. On the Manage Users page, select the check box next to the name of the user or crosssite group whose group membership you want to change. 2. Click Edit Site Group of Selected Users. 3. In the Site Group Membership area, select the site group of which you want the user or cross-site group to be a member, and click OK. You can also add new users and cross-site groups to your site from the Manage Users page.

275 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 259 To add a new user or cross-site group 1. On the Manage Users page, click Add Users. 2. In the Step 1: Choose Users section, specify the users you would like to add, separated by semicolons. You can enter: addresses (for example, [email protected]) User names (for example, DOMAIN\user_name) Microsoft Active Directory directory service security group names (for example, DOMAIN\security_group_name) Domain group names (for example, DOMAIN\group_name) Cross-site group names (for example, Accounting) Note Be aware of the following limitations: When running Windows SharePoint Services in a server farm, you cannot add local accounts. Local accounts must exist before you attempt to add them. Windows SharePoint Services does not create local accounts, as SharePoint Team Services v1.0 does. When using Active Directory account creation mode, you cannot add local accounts or security groups. 3. In the Step 2: Choose Permissions section, select the site group to which the user or group will belong, and then click Next. 4. In the Step 3: Confirm Users section, verify the addresses, user names, and display names. 5. In the Step 4: Send section, if you want to send an invitation, select Send the following to let these users know they ve been added, and type the subject and body text information to send in the message. 6. Click Finish. You can delete users or cross-site groups from all site groups by using the Manage Users page. This does not delete the user or cross-site group account, but does remove all rights to the Web site.

276 260 Microsoft Windows Server System Deployment Guide for Midsize Businesses To add all users from an distribution list Note To complete the steps in this section, you must have a Windows SharePoint Services compatible address book program, such as Microsoft Office Outlook 2003, installed on the computer you are running. 1. On the Web site you want to manage, click Site Settings. 2. On the Site Settings page, in the Administration section, click Manage Users. 3. On the Manage Users page, click Add Users. 4. In the Step 1: Choose Users section, click Address Book. 5. Select the distribution list you want to add from the address book. Note You can add only distribution lists that reside on the same server as your current account. For example, in Office Outlook 2003, the names of distribution lists that reside on the same server appear in bold text. The list of users from the distribution list appears in the Users field. 6. In the Step 2: Choose Permissions section, select the site group to which you want to add the members of the distribution list, and then click Next. 7. In the Step 3: Confirm Users section, verify the addresses, user names, and display names. 8. In the Step 4: Send section, if you want to send an invitation, select Send the following to let these users know they ve been added, and type the subject and body text information to send in the message. 9. Click Finish. Note Adding or removing users from the distribution list will not add or remove them from the site. You must manually add or remove users from the site after changing your distribution list membership. To delete a user or cross-site group from all site groups 1. On the Manage Users page, select the check box next to the user or cross-site group you want to delete. 2. Click Remove Selected Users. 3. On the confirmation message that appears, click OK to remove the users.

277 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 261 Managing Users in a Site Collection Every Web site with unique permissions has a Manage Users page that the site s administrator can use to add, modify, or delete users. In addition to this page, the top-level Web site in a Web site collection also includes a page that server administrators or the site collection administrator can use to view and delete users. This page lists all users for the site collection, including the users of the top-level Web site and users of any subsites in the site collection. When you remove a user from this list, the user is removed from all sites and subsites in the site collection. To remove a user from a top-level Web site 1. On the top-level Web site, click Site Settings. 2. Under Administration, click Go to Site Administration. 3. On the Top-Level Site Administration page, under Site Collection Administration, click View site collection user information. 4. Select the check box next to the user you want to remove, and then click Remove Selected Users. Managing Users from SharePoint Central Administration If you are an administrator on the server computer or a member of the SharePoint administrators group, you might have administrative rights to change settings on the Site Settings page for any individual site on your server. What happens when a top-level Web site owner leaves your organization, or a user must be added to or removed from a site that you do not have administrative rights for? The SharePoint Central Administration page includes a link for managing users for sites even if the administrator does not have rights to the site. You can add users or cross-site groups, remove users or cross-site groups, change site group membership, and change owners, without having to be an administrator on a specific site. You do, however, need to know the URL for the site, and the specific user name that you want to change. To change the owner of a site collection 1. Click Start, point to All Programs, point to Administrative Tools, and then click Share- Point Central Administration. 2. On the SharePoint Central Administration page, under Security Configuration, click Manage site collection owners. 3. On the Manage Site Collection Owners page, in the Site URL box, type the URL to the site, and then click View. The information for the current site owner and secondary owner is automatically filled in on the page when you click View. 4. In the Site Owner section, in the User name box, type the account name for the new owner.

278 262 Microsoft Windows Server System Deployment Guide for Midsize Businesses 5. If you have a new secondary contact name, type the account name in the Secondary Owner section. 6. Click OK. If you are an administrator on the server computer and need to change the owner of a site that you do not have administrative access to, you can make the change from the SharePoint Central Administration page. To add a new site user or group 1. Click Start, point to All Programs, point to Administrative Tools, and then click Share- Point Central Administration. 2. On the SharePoint Central Administration page, in the Security Configuration section, click Manage Web site users. 3. On the Manage Web Site Users page, in the Site URL box, type the URL to the site, and then click View. 4. In the Add a User section, specify the users that you would like to add, separated by semicolons. You can enter: addresses (for example, [email protected]) User names (for example, DOMAIN\user_name) Microsoft Active Directory directory service security group names (for example, DOMAIN\security_group_name) Domain group names (for example, DOMAIN\group_name) Cross-site group names (for example, Accounting) Note Be aware of the following limitations: When running Windows SharePoint Services in a server farm, you cannot add local accounts. Local accounts must exist before you attempt to add them. Windows SharePoint Services does not create local accounts like SharePoint Team Services v1.0 does. When using Active Directory account creation mode, you cannot add local accounts or security groups. 5. In the Display name box, type the full name. 6. In the address box, type the address. 7. In the Site group box, select a site group to which to add the user or group, and then click Add User. You can also delete a user or change a user s site group membership from this page.

279 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 263 To delete a site user or change site group membership 1. Click Start, point to All Programs, point to Administrative Tools, and then click Share- Point Central Administration. 2. On the SharePoint Central Administration page, under Security, click Manage Web site users. 3. On the Manage Web Site Users page, in the Site URL box, type the URL to the site, and then click View. 4. In the Change Existing User section, in the Account name box, type the user account you want to change or delete, and then click View user. 5. To change site group membership, select the check box for the site group you want the user to be a member of, and then click Update. 6. To remove the user from all site groups, click Delete User. Backup and Restore Options for Windows SharePoint Services There are several methods you can use to back up and restore data for Microsoft Windows SharePoint Services. Each of these methods allows you to back up and restore data, but each method acts at a different level of granularity and might require different permissions. You can back up and restore data for Windows SharePoint Services by using the following methods: Use the Microsoft SQL Server 2000 tools to back up the databases: You can use the backup tools included with SQL Server 2000 to get a full-fidelity, complete backup of the databases used by Windows SharePoint Services on your server or server farm. When you use this method, you back up and restore the entire configuration database and each content database on your server or in your server farm. You can then restore any or all of these databases. You must be running SQL Server 2000, not Microsoft SQL Server 2000 Desktop Engine (WMSDE), to be able to use this backup method, and you must be an administrator on the local server computer that is running SQL Server. This option is the most secure of the backup and restore options described in this topic. For more information about backing up databases in SQL Server, see Backing Up and Restoring Databases by Using the SQL Server 2000 Tools in the Windows SharePoint Services Administrator's Guide at: /all/adminguide/en-us/stsf03.mspx, and the SQL Server 2000 Help system. Use the Stsadm.exe command-line tool to back up individual site collections: You can get a full-fidelity, complete backup or restore of an entire site collection by using the Stsadm.exe command-line tool with the backup and restore operations. This method of backing up and restoring data does not require SQL Server However,

280 264 Microsoft Windows Server System Deployment Guide for Midsize Businesses you must still be an administrator on the local server computer that is running Windows SharePoint Services in order to perform this method of backing up and restoring. For more information about backing up site collections by using the Stsadm.exe command-line tool, see Backing Up and Restoring Web Sites at: /technet/prodtechnol/office/office2003/maintain/bureswss.mspx. Use the Microsoft SharePoint Migration Tool (smigrate.exe) to back up individual sites and subsites: You can back up and restore individual sites or subsites by using the SharePoint Migration Tool. This method is not full-fidelity; you might lose some customizations or settings in the process. For example, security settings for the site, such as user membership in site groups, cannot be restored when you use the SharePoint Migration Tool. However, with this backup method, you do not need to be an administrator on the local server computer. Any member of the administrator site group for a site or subsite can use this method. For more information about backing up sites and subsites by using the SharePoint Migration Tool, see Migrating and Upgrading Web Sites at /resources/documentation/wss/2/all/adminguide/en-us/stsf12.mspx. Table 8-1 describes the scope and limitations of each backup and restore method, and the permissions required to perform each one. Table 8-1 Backup and Restore Methods Method Scope Limitations Required Permissions SQL Server 2000 Backup and Restore Stsadm.exe Backup and Restore SharePoint Migration Tool Site Migration Database None Administrator on local server computer Site collection Site or subsite None Some customizations or settings might not migrate. Does not migrate security settings. Administrator on local server computer Member of administrator site group for the site or subsite Running Microsoft SQL Server tools at frequent intervals (such as once a week) can be costly to an organization. Also, these tools support backup and restoration at the database level only, making it impractical to restore single sites or site collections. The Stsadm.exe command-line tool supports complete backup and restoration at the site-collection level, including security settings. It is ideal for targeted backups and is less costly to run. A practical and effective backup strategy for your Windows SharePoint Services installation is to use both of these tools. At longer intervals, such as monthly, back up your entire set of databases using the Microsoft SQL Server tools. At shorter intervals, such as weekly, run Stsadm.exe to back up just those site collections that have changed. This will facilitate quick recovery of lost items with a minimum of space usage, while the Microsoft SQL Server tools backups are available for large-scale disaster recovery.

281 Chapter 8: Installing and Configuring Microsoft Windows SharePoint Services 265 References For more information, refer to: Administrator s Guide for Windows SharePoint Services at /documentation/wss/2/all/adminguide/en-us/stsa02.mspx. Microsoft Windows SharePoint Services Step by Step by Olga Londer, Todd Bleeker, Penelope Coventry, and James Edelen. Microsoft SharePoint 2003 For Dummies by David McAmis. The self-paced e-learning course: Course 2286: Implementing Microsoft Windows SharePoint Services - New Look & Feel! at ww.microsoftelearning.com/elearning /offerdetail.aspx?offerid=11817.

282

283 Chapter 9 Managing Desktops by Using Group Policy This chapter provides guidance on designing and implementing advanced Active Directory features and determining the prerequisites for building the services. If you followed the guidance presented earlier in this book, Active Directory is already deployed on the primary and secondary infrastructure servers. Organizational Unit Design In a single-domain single-site Active Directory implementation, such as the one recommended for the medium business environment, the most important element of the Active Directory design is the organizational unit (OU) structure. An OU contains directory objects such as users and computers, and provides a way of logically grouping and organizing objects in Active Directory. OUs can be used for performing the following functions: Organizing objects for implementing Group Policy: The primary purpose of the OU structure is the efficient application of Group Policy. Delegating authority for administration: If there are business units within the organization that require some self-administration authority, make sure to put those users into a separate OU. For example, if an organization has a finance department in a separate location and there is a local administrator for managing the IT infrastructure at that location, the domain administrators can delegate some administration authority for the finance OU to the local administrator. This allows the local administrator in the finance department to handle many issues without having to involve the domain administrators. For medium-business networks, multiple Group Policy objects (GPOs) that contain settings to automate the configuration of numerous key features in the environment are applied. GPOs are objects that contain Group Policy settings and can be applied either at the domain level or at the OU level. GPOs that contain Group Policy settings for users or computers across the organization, such as domain security GPOs, are applied at the domain level. All other GPOs are applied at the OU level to increase logon performance. 267

284 268 Microsoft Windows Server System Deployment Guide for Midsize Businesses There are two ways of selectively implementing GPOs to objects in Active Directory. These are as follows: OU: GPOs applied at the OU level are only evaluated by the objects in that OU and objects in all of the child OUs. It is very important to have an OU structure that supports efficient application of GPOs and provides flexibility for different scenarios and requirements in different areas of the organization. This is the recommended implementation. ACLs: GPOs are applied selectively by placing access control lists (ACLs) on individual GPOs. In this case, ACLs must be evaluated each time a user logs on or a computer restarts, regardless of whether the GPO is applied to them or not. As a result, logon and startup performance is degraded. The OU structure should be designed to organize directory objects so that you can consistently apply GPOs to a group of objects. Designing the Organizational Unit This chapter provides a baseline OU design that can be implemented in most medium business IT environments. You can enhance or extend this baseline configuration to suit your environment. However, it is important to at least implement the baseline OU design represented in Figure 9-1. BusinessName.com BusinessName Computers Users Clients Servers Internal Internal Desktop External Sales Mobile Operations BO Desktops Executive Restricted IT Kiosk Production Task Workstation Figure 9-1 Minimum recommended OU structure

285 Chapter 9: Managing Desktops by Using Group Policy 269 Note When creating the OU structure in your environment, ensure that you create the structure in a hierarchical fashion, as shown in Figure 9-1. Begin by creating the BusinessName OU underneath the domain. Next, create the Computers and Users OU under the Business- Name OU. Continue creating the rest of the OUs under other parent OUs exactly as represented in the figure. When the entire structure is created, the top OU (BusinessName) will have two child OUs under it. These OUs will also have two child OUs under each of them, and so on. For more information on designing an Active Directory logical structure, refer to /dssbc_logi_overview.asp. The Group Policy settings to be applied at the domain level and the OUs that are recommended in the baseline OU structure are described as follows. Domain Level There are some Group Policy settings that can be applied at the domain level only. Table 9-1 presents the Group Policy settings implemented at the domain level. Table 9-1 Servers OU Group Policy Settings for the Domain Level Setting Value Remembered passwords 24 Maximum password age 42 days Minimum password age 2 days Minimum password length 8 characters Passwords must meet complexity requirements Enabled Account lockout threshold 50 invalid logon attempts Account lockout duration 30 minutes Reset account lockout counter after 30 minutes There are two OUs, Internal and External, included within this OU. The Internal OU is designed for servers that do not have a direct connection to an external network, such as the Internet. The External OU is designed for servers that are directly connected to the Internet or any other external network. In the topology recommended in this book, the firewall server is placed in the External OU. All other servers, with the exception of the primary and secondary infrastructure servers, are placed in the Internal OU. The infrastructure servers, by default, are placed in the built-in Domain Controllers OU, and should not be moved from that OU.

286 270 Microsoft Windows Server System Deployment Guide for Midsize Businesses Table 9-2 presents the Group Policy settings implemented at the Servers OU. Table 9-2 Group Policy Settings for the Servers OU Setting Value Security auditing Enabled Allow local logon Administrators Guest account status Disabled Interactive logon: Do not display last user name Enabled Network access: Do not allow anonymous enumeration Enabled of SAM accounts and shares Shutdown: Allow system to be shut down without Disabled having to log on Automatic Updates Automatic download and notification for install Automatically publish new printers in Active Directory Enabled Password protect the screen saver Enabled Computers OU The Computers OU is where all generic, scenario-based client computer settings are applied. These settings are implemented on all client computers in the domain. Table 9-3 presents the Group Policy settings implemented at the Computers OU. Table 9-3 Group Policy Settings for the Computers OU Setting Value Interactive logon: Do not display last user name Enabled Interactive logon: Display logon message Enabled Network access: Do not allow anonymous enumeration Enabled of SAM accounts and shares FTP publishing service Disabled Messenger service Disabled World Wide Web publishing service Disabled Automatic Updates Automatically download and install Windows Firewall Disabled for Windows XP with Service Pack 1 (SP1) and earlier Enabled, with specific exceptions, for Windows XP with SP2 and later

287 Chapter 9: Managing Desktops by Using Group Policy 271 There are multiple divisions within the Computers OU. There are four different OUs that allow different kinds of security, software, and management Group Policy settings to be applied. These OUs are: Desktop: This OU will have all the settings for desktop computers at the main office. The GPOs applied on the Desktop OU have the following characteristics: Allow basic customization of the desktop environment. Users can save desktop configurations, but they cannot customize network, hardware, and system settings. Support free seating. Users can log on to any computer and get their data and settings. No cached state is maintained on the computer when users leave. Restrict write access of users on the local computer so that users can write data to their user profile and to redirected folders only. Have a set of applications that are always available (assigned), and applications that can be installed and removed as necessary (published). Are highly secure. Mobile: This OU will be used for client computers that are mobile; for example, Tablet PCs and laptops. The GPOs applied on the Mobile OU have the following characteristics: Have specific configurations required for mobile devices, such as configuration for securing wireless network connections. Are used by users who are away from office most of the time, who usually log on by using low-speed dial-up links, but who also occasionally log on by using highspeed network links. Are used by users who are away from the office only occasionally and log on by using remote access or remote network links. Provide users with continuous access to their data and configuration settings, whether the computer is connected to or disconnected from the network. Partially support free seating (can optionally support full free seating) to facilitate centralized data backup and enable users to access important data and settings from different computers. Allow users to disconnect from the network without logging off or shutting down. BO Desktops: This is the OU for desktops in the branch office. Many of the settings for the GPOs applied to this OU are the same as those applied to Desktop OU. However, additional settings for the BO Desktops OU include: Slow link detection for Group Policy.

288 272 Microsoft Windows Server System Deployment Guide for Midsize Businesses Removal of settings that require high bandwidth, such as publishing of applications with a large installation size. Removal of automatic installation of firewall client. Restricted: This is the OU for desktops on which a high degree of management and configuration with less flexibility is desired. The GPOs applied to this OU have the following features: Allow minimal customization by the user. Allow users to access a small number of applications appropriate to their job role. Do not allow users to add or remove applications. Support free seating. Provide a simplified desktop and Start menu. Restrict write access to the local computer; users can write data only to their user profile and to redirected folders. Are highly secure. Users OU The Users OU helps in applying settings to different groups of users. This is typically based on the organizational structure, and allows different software, shares, and other policy settings to be applied to users. This OU structure should be customized based on the needs of your organization. In the baseline OU structure, there are OUs created for user accounts in the Sales, Operations, IT, and Executive areas. This allows for specialized configurations that are department-specific. For example, company executives might need to have a specialized reporting application installed that allows them to view high-level reports from the accounting system to monitor the business. Likewise, the Operations department might have a specialized lineof-business (LOB) application to which they need access to perform their daily business operations. Although OUs are created for user accounts, no policy settings are applied to these OUs by this solution. The policies applied to these OUs should be based on the specific business requirements of the organization. Group Policy Design GPOs can be used in a domain environment to automatically configure many elements of client devices, servers, and the user environment. Group Policy is an extremely powerful tool, and can be used to provide extensive configuration in an environment. In this book we focus on a scenario-based baseline set of GPOs to provide a configuration that strikes a balance among complexity, functionality, and security to ensure smooth operation.

289 Basic Guidelines for Implementing Group Policy Chapter 9: Managing Desktops by Using Group Policy 273 When implementing Group Policy, remember the following simple rules: GPOs are applied in order. In case of a setting conflict, the setting that is applied last will be the effective setting. Avoid the use of ACLs on GPOs, if possible. Each ACL must be evaluated at logon time, and a large number of GPOs with different ACLs can reduce logon performance. Instead, apply Group Policy at the OU level rather than the domain level. This allows the administrator to control the settings applied to groups of users and objects without using ACLs. Applying Group Policy at the OU level is possible only if the OUs are well designed and allow a more granular application of Group Policy. Always model and test Group Policy before implementing it in a production environment. Microsoft Windows Server 2003 provides new tools, such as the Resultant Set of Policy Wizard and the Group Policy Modeling Wizard, to help you view the effects of various Group Policy implementations before they are applied in the production environment. Because of the way Windows detects whether there is a slow link or not, when implementing the Branch Office Active Directory Group Policies, the hardware firewall/vpn device (connecting the branch office to the main office) and/or Group Policy settings might need to be tuned to accommodate the branch office connection. For more information, refer to How a Slow Link Is Detected for Processing User Profiles and Group Policy, available at support.microsoft.com/?id= In some severe cases, the slow link detection feature might have to disabled by adjusting the branch office user and computer Group Policy settings and modifying registry entries on the branch office clients. However, this will have the consequence of increased client computer startup and logon times. Policies have two types of settings: user configuration settings and computer configuration settings. Under normal circumstances, any computer configuration settings in the OU path to the computer account of the computer to which the user logs on are applied to that user s session. In addition, any user configuration settings in the OU path to the user account are applied to that user s session. This means that user settings in the OU path to a computer account and computer settings in the OU path to a user account are ignored. Many of the settings provided in various scenarios (such as Desktop, Mobile, and Kiosk) in this book are user settings that need to be applied when a user logs on to a particular computer. To enable the scenario-based GPO settings, the GPOs provided with this guidance use Group Policy Loopback Processing. Group Policy Loopback Processing allows user configuration settings to be enforced on a session based on the OU the computer is located in, regardless of where the user account is located. Group Policy Loopback Processing enables the scenario-based GPO settings provided in this book.

290 274 Microsoft Windows Server System Deployment Guide for Midsize Businesses For more information on Group Policy Loopback Processing, refer to support.microsoft.com/?id= Note Take special care when using Group Policy Loopback Processing, because there is a potential for unexpected user settings to be applied to a logon session. This is because the settings that are applied are a combination of the user settings in the OU path to the user account and the user settings in the OU path to the computer account. General Recommendations A number of different GPOs are provided as part of this solution. These settings are imported into new GPOs created in the Active Directory, and linked to the OUs discussed in the previous section. The OUs and the GPOs that are linked to each OU are listed in Table 9-4. Table 9-4 OU Servers\Internal Servers\External Clients Clients\Desktop Clients\Mobile Clients\BO Desktops Clients\Restricted Clients\Kiosk OUs and Associated GPOs Clients\Task Workstation Linked GPOs Internal Server Computer Policy Internal Server User Policy External Server Computer Policy External Server User Policy Windows Firewall (Windows SP2) Settings ICF (Windows XP SP1 and earlier) Settings Desktop Computer Policy Desktop User Policy Mobile Computer Policy Mobile User Policy BO Computer Policy BO User Policy Restricted Computer Policy Restricted User Policy Kiosk Computer Policy Kiosk User Policy Task Workstation Computer Policy Task Workstation User Policy All computer GPOs referred to in this book use Group Policy Loopback Processing. The Kiosk and Task Workstation policies use the replace function of this setting, while the remaining policies use the merge feature. This means that the user configuration settings that are applied to the user account will be combined with the user configuration settings applied to the computer to which the user logs on for all OUs except Kiosk and Task Workstation. For users logging on to computers in those OUs, only the user settings from those OUs will be applied.

291 Chapter 9: Managing Desktops by Using Group Policy 275 Folder Redirection Folder redirection can be used to redirect key folders from a user profile to a specified location, rather than storing them in the default location on the system drive. This allows the network administrators to control the storage location of files, allowing data to be centralized for management and backup. In the medium business IT environment, Group Policy can be used to automatically configure and enforce folder redirection properties on client computers without any user intervention. GPOs can be used to automatically configure folder redirection for clients. The guidance provided in the Build section in Implementing Common Desktop Management Scenarios with the Group Policy Management Console at /windowsserver2003/technologies/management/csws2003.mspx includes settings for redirecting Start Menu, Application Data, and My Documents folders of computers in the Desktop, Restricted, and Task Workstation OUs. The redirection settings are an optional component. Note that the settings are not included with the GPOs referred to in this book. Therefore, files will be redirected only if the steps provided in the Configuring Folder Redirection section later in this chapter are implemented. Software Installation One of the most powerful features of Group Policy in Active Directory is the ability to publish and assign software packages to client computers. GPOs provide the ability to automate software installation in two ways. First, installation files can be published, providing the users with the option of selecting and installing the programs through Add or Remove Programs in Control Panel. The second method of automating software installation is to assign applications to client computers. Assigning applications will automatically install the applications on client computers in the environment without any intervention from the user. This solution provides guidance for assigning the Microsoft Firewall client as well as the Volume Shadow Copy service client to the computers in the Desktop, Mobile, Task Workstation, and Restricted OUs. In addition, the Volume Shadow Copy Service client is assigned to the computers in the BO Desktops OU, and the Firewall Client is assigned to computers in the Kiosk OU. The application installation settings are an optional component. The steps for implementing the software installation are included in the Configuring Software Installation section later in this chapter. Note that the settings are not included with the GPOs provided with this solution. Therefore, the assigned applications are implemented only if the steps in the Configuring Software Installation section later in this chapter are followed. Wireless Configuration GPOs can be used to automate wireless configuration on mobile computers.

292 276 Microsoft Windows Server System Deployment Guide for Midsize Businesses This book includes guidance for configuring wireless settings in the GPOs applied to the Mobile OU. The automated wireless configuration settings are optional Note that the settings are not included with the GPOs provided with this solution. Therefore, wireless settings are implemented only if the steps provided in the Configuring Wireless Settings section later in this chapter are implemented. Software Update Services Guidance on implementing Windows Server Update Services was covered in Chapter 5, Installing and Configuring Windows Server Update Services. However, there is client configuration for the implementation that is performed by using Group Policy. Roaming Profiles A user profile defines the desktop environment of the user, which includes individual display settings and network and printer connections. When roaming profiles are used, the profile data is redirected by the administrator to a share on the network. The profile is copied from the share to the computer when the user logs on. Changes made to the profile are updated on the server when the user logs off. You should configure roaming profiles for all users who move between computers within the environment, users who have multiple computers (such as a laptop and a desktop), shift workers who share a common computer (such as on a manufacturing floor), or users who need to preserve their settings between computers in the environment. Exclude the following folders from roaming profiles: My Documents Application Data Desktop Roaming profiles should be used within a DFS namespace, as described in the Network Share Structure section in Chapter 7, Installing and Configuring File Sharing and Print Services. This makes it easier to change the location of folders containing the roaming profiles, if so required in the future. The location may change if more share space is required and the files are moved to the new location. To change the location, copy the files in the shared folder to the new shared folder and update DFS with the new link target. No other configuration is required. To prevent synchronization problems, make sure that you disable offline folders for shared folders where roaming user profiles are stored. If you do not disable offline folders for a user profile, you might experience synchronization problems because both offline folders and roaming user profiles will try to synchronize the files in a user profile. This synchronization conflict does not affect offline folders with redirected files, such as the My Documents folder.

293 Chapter 9: Managing Desktops by Using Group Policy 277 Remember that disk quotas might need to be increased, because the roaming profile synchronization process creates a temporary duplicate copy of a user profile, using the logon context of the user. Because the roaming profile synchronization process runs under the user context, it debits the user quota during synchronization. Configuring and Implementing Group Policies to Manage Desktops Once you have designed your Active Directory structure, and decided on the policies that will be applied to manage desktops, you are ready to implement that configuration. Configuring the OU Structures Figure 9-2 represents the baseline OU design recommended in this solution. BusinessName.com BusinessName Computers Users Clients Servers Internal Internal Desktop External Sales Mobile Operations BO Desktops Executive Restricted IT Kiosk Production Task Workstation Figure 9-2 Baseline OU design recommended in this solution Create new OUs by performing the following steps: 1. From the Administrative Tools folder, open Active Directory Users and Computers. 2. Right-click the object where you want to create the new OU (such as the domain or another OU). Click New, and then click Organizational Unit.

294 278 Microsoft Windows Server System Deployment Guide for Midsize Businesses To create the structure shown in Figure 9-2, begin by right-clicking the domain name itself, <BusinessName.com>, to create the <BusinessName> OU. Then create the rest of the OUs in a hierarchical fashion as shown underneath the <BusinessName> OU. 3. Type a name for the OU, and click OK. Moving Objects into the OU As new objects (users or computers) are added to the domain, they will need to be moved into the proper OU. The OU where an object should be placed varies depending on the OU structure you created. If you are using the sample OU structure provided with this solution, you should begin by placing any servers that are directly connected to the Internet (such as MOISA) in the External OU under Servers OU. Any other servers should be placed in the Internal OU under Servers OU. Clients should be placed in one of the six Clients OUs based on the scenario (such as moving the branch office clients to the BO Desktops OU under Clients OU) and user accounts in one of the Internal OUs under the Users OU, based on their role in the organization. After creating the OUs, you need to move the existing objects into the proper OUs. You will also need to move any newly created objects into the proper OU as they are created. Move objects into the correct OU by performing the following steps: 1. From the Active Directory Users and Computers console, locate the computer or user object that needs to be moved into an OU. 2. Right-click the object, and click Move. 3. Navigate to the OU where the object should be placed, and click the OU. 4. Click OK. 5. Repeat this process for every object that needs to be moved. If you have multiple objects in the same place that need to be moved to the same OU, you can select more than one object in Step 1. Note By default, when a domain is created, an OU for domain controllers is created. Therefore, do not move any domain controllers into a different OU. If your OU design calls for it, you can move the entire Domain Controllers OU to a different location (such as another OU). However, do not move the domain controllers inside that OU to another location. The minimum required OU structure for the medium business IT environment does not require any modification or moving of the Domain Controllers OU. Making modifications to or moving this OU is an advanced option that should only be carried out by an engineer who has good knowledge of Active Directory and fully understands the implications of doing so, and has considered those implications as part of a larger Active Directory and OU structure design. In addition, do not move any of the default users and/or groups into an OU unless you fully understand the ramifications of doing so. This solution does not require moving any of the default users or groups into any OU.

295 Configuring Group Policy Objects Chapter 9: Managing Desktops by Using Group Policy 279 Configuring GPOs in the medium IT environment involves the following steps: Import GPOs. Link policies to OUs. Configure Automatic Updates setting on the Domain Controller OU. Configure Windows Firewall policies on Client OU. To import GPOs 1. Save and unzip the GPOs in the advancegpos.zip file on the primary infrastructure server (MOCOR1). The advancegpos.zip file is not distributed along with this book, but is available as part of the download of the Medium Business Solution for Management and Security using Active Directory Group Policy download at details.aspx?familyid=bb534b41-b f5cafe2dc&displaylang=en. 2. Under Administrative Tools, open the Group Policy Management Console by clicking its shortcut. 3. Expand <Forest>\Domains\<BusinessName.com>. 4. Right-click Group Policy Objects, and click New. 5. Name the Group Policy Internal Server Computer Policy. 6. Choose Group Policy Objects in the left pane, and then right-click the GPO object you just created, and click Import Settings to start the Import Settings Wizard. 7. Complete the Import Settings Wizard by performing the following: a. On the Backup GPO page, you do not need to perform a backup, because this is a new policy and does not yet have any settings. b. On the Backup Location page, specify the backup folder where you have saved the GPO distributed with this book. c. Choose the GPO that matches the Group Policy you just created. 8. Repeat steps 4-7 with the following Group Policy names and associated GPOs: a. Internal Server User Policy b. External Server Computer Policy c. External Server User Policy d. BO Computer Policy e. BO User Policy

296 280 Microsoft Windows Server System Deployment Guide for Midsize Businesses f. Desktop Computer Policy g. Desktop User Policy h. Mobile Computer Policy i. Mobile User Policy j. Restricted Computer Policy k. Restricted User Policy l. Task Workstation Computer Policy m. Task Workstation User Policy n. Windows Firewall (SP2) Settings o. ICF (Pre-SP2) Settings 9. Perform the following steps on the Internal Server, External Server, BO, Desktop, Mobile, Restricted, and Task Workstation User Policies to exempt administrators from the user settings: a. Under Administrative Tools, open the Group Policy Management Console by clicking its shortcut. b. Expand <Forest>\Domains\<BusinessName.com>, and click Group Policy Objects. c. Right-click the policy, and choose Edit. d. In the Group Policy Object Editor, right-click the policy name, and click Properties. e. Click the Security tab, and select Domain Admins. f. In the Deny column, click the box next to Apply Group Policy. g. Click OK. h. Click Yes to acknowledge the security warning. i. Close the Group Policy Object Editor. To link policies to OUs 1. In the Group Policy Management Console, follow the path <Forest>\Domains\<your domain>\<businessname OU>\Computers\Servers\Internal. 2. Right-click the Internal OU, and click Link an Existing GPO. 3. Click the Internal Server Computer Policy, and then hold down the Control key and click the Internal Server User Policy (so that both are highlighted). Click OK.

297 Chapter 9: Managing Desktops by Using Group Policy Repeat steps 1-3, linking all new user and computer policies that were created in the previous section to the appropriate OU. Each OU will have two policies linked, the corresponding user policy and the corresponding computer policy. To configure the Automatic Updates Setting on the Domain Controller OU 1. In the Group Policy Management Console, follow the path <Forest>\Domains\<your domain>\group Policy Objects. 2. Right-click the Default Domain Controllers Policy, and then click Edit. 3. Within the Group Policy Object Editor, go to Computer Configuration/Administrative Templates/Windows Components/Windows Update. 4. Configure the settings in this node as shown in the following steps by right-clicking each setting and choosing Properties: a. Configure Automatic Updates should be Enabled (do not change the defaults for the other settings). b. Reschedule Automatic Updates scheduled installations should be Enabled (do not change the defaults for the other settings). c. No auto-restart for scheduled Automatic Updates installations should be Enabled. Note Perform the next step only if you have implemented Windows Server Update Services (WSUS) in your environment. d. Specify intranet Microsoft update service location should be Enabled. Set both fields to the address of the WSUS server; for example, To configure Windows firewall policies on the Client OU Configure the Windows Firewall policies on the Client OU by performing the following steps: 1. In the Group Policy Management Console, follow the path <Forest>\Domains\<your domain>\<businessname OU>\Computers. 2. Right-click the Clients OU, and click Link an Existing GPO. 3. Choose the Windows Firewall (SP2) Policy, and then hold down the Control key and click the ICF (Pre-SP2) Policy (so that both are highlighted). Click OK.

298 282 Microsoft Windows Server System Deployment Guide for Midsize Businesses 4. Install the Group Policy update for Windows Firewall settings by performing the following steps: a. Download the update for Windows Server 2003 from support.microsoft.com/?id= Note The Knowledge Base article referenced here contains updates for a number of different operating system versions. Use caution and ensure that you download the version for Windows Server The update for Windows Server 2003 is listed at the end of the article, and is easily confused with the update for Windows 2000 SP3. b. Install the patch, accepting all default choices in the installation wizard, on MOCOR1. 5. In the Group Policy Management Console, follow the path <Forest>\Domains\<your domain>. 6. Right-click the WMI Filters folder, and click Import. 7. Browse to the location of the WMI filter backups (.mof files) included with this book, choose PreSP2.mof, and then click Open. 8. On the Import WMI Filter screen, click Import. 9. Repeat steps 6 through 8 to import PostSP2.mof. 10. In the Group Policy Management Console, follow the path <Forest>\Domains\<your domain>\group Policy Objects. 11. Right-click the Windows Firewall (SP2) Policy, and click Edit. 12. In the Group Policy Object Editor, right-click the policy name, and click Properties. 13. Click the WMI Filter tab, select This filter, and click Browse/Manage. 14. Ensure that the PostSP2 WMI Filter is highlighted, and click OK. On the WMI Filter tab of the GPO properties sheet, Post SP2 should be displayed in the This filter box. 15. Click OK, and close the Group Policy Object Editor. 16. Right-click the ICF (Pre-SP2) Policy, and click Edit. 17. In the Group Policy Object Editor, right-click the policy name, and click Properties. 18. Click the WMI Filter tab, and then select This filter. Then click Browse/Manage. 19. Highlight PreSP2, and click OK. 20. Click OK, and close the Group Policy Object Editor.

299 Configuring Folder Redirection (Optional) Chapter 9: Managing Desktops by Using Group Policy 283 Because a server name is specified when configuring redirected folders, the GPOs provided with this solution do not specify folder redirection properties. To complete the implementation of folder redirection in your environment, you need to perform the following tasks: 1. Create a redirected files shared folder. 2. Create the DFS link. 3. Modify the policies to add the path for redirected folders. To create a redirected files shared folder and disable offline folders 1. On the server where you want the files to be stored, create a folder named Redirected- Files. Then open the folder properties, and on the Security tab, click the Advanced button. 2. Clear the Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here check box. 3. Click the Remove button on the message that appears, and click OK. 4. Ensure that the Domain Users and Domain Admins groups have Full Control permissions. 5. Share the folder. Click the Permissions button, and grant the Domain Users and Domain Admins groups Full Control permissions. Remove any other users or groups from the permissions list. 6. Click OK. Note If you have not implemented the guidance provided in Chapter 7 and do not have an existing DFS root, you can skip the following section. To create the DFS link 1. Open the DFS management console, and then open the DFS root created in the Configuring DFS section in Chapter Right-click the DFS root, and click the New Link option. 3. Enter the following link properties, and then click OK: Link Name: Redirected Path to Target: \\<servername>\shared folder for redirected files

300 284 Microsoft Windows Server System Deployment Guide for Midsize Businesses Modify the Policies to Add the Path for Redirected Folders When creating a shared folder redirection directory, you should allow access only to those users who need the access. For information about the permissions required, refer to /user01.mspx#xsltsection Modify the policies to add the path for redirected folder by performing the following steps: 1. In the Group Policy Management Console, right-click each GPO and then click Edit. 2. Within the Group Policy Object Editor, go to User Configuration/Windows Settings/ Folder Redirection. 3. Right-click the My Documents node and click Properties. 4. In the Properties dialog box, change the Setting list to Basic Redirect everyone s folder to the same location. 5. Leave the Target Folder Location list set to Create a folder for each user under the root path. 6. Set the Root Path field to the DFS or UNC path of the folder where the files of the user are to be stored, for example, \\BusinessName. com\allshares\redirected, and then click OK. Folder redirection automatically appends %user name% to the path specified. 7. Repeat steps 3-6 for the Desktop and Application Data nodes. 8. Close the GPO. 9. The permissions for redirected folders should be set on the File Server (MOCOR1) so that only the user or the domain administrator can access the user s redirected folders. Configuring Software Installation (Optional) Because a server name is specified when configuring assigned applications for installation, the GPOs provided with this solution do not specify software installation packages. To complete the implementation of software installation in your environment, you must carry out the following tasks: 1. Create the software installation files shared folder. 2. Create the DFS link. 3. Copy the.msi file to the new directory. 4. Modify the policies to add the packages for software installation.

301 To create the software installation files shared folder Chapter 9: Managing Desktops by Using Group Policy On the server where you want the files to be stored, create a folder named SoftDist, and then open the folder properties. 2. On the Security tab, click the Advanced button. 3. Clear the Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here check box. 4. Click the Remove button on the message that appears, and click OK. 5. Ensure that the Authenticated Users group has Read permissions. Ensure that the Domain Admins group has Full Control permissions. 6. Share the folder. Click the Permissions button, and grant the Authenticated Users group Read permissions, and the Domain Admins group Full Control permissions. Remove any other users or groups from the permissions list. 7. Click OK. Note If you have not implemented the guidance provided in Chapter 7 and do not have an existing DFS root, you can skip the following section. To create the DFS Link 1. Open the DFS management console, and open the DFS root created in the Configuring DFS section in Chapter Right-click the DFS root, and click the New Link option. 3. Enter the following link properties, and then click OK: a. Link Name: SoftDist b. Path to Target: \\<servername>\shared folder for software installation files To copy the.msi file to the new directory 1. Download the msi file for the Volume Shadow Copy client from /downloads/details.aspx?familyid=e382358f-33c3-4de7-acd8-a33ac92d295e&displaylang=en. 2. Place the file in the DFS or UNC path created in the previous section; for example, \\BusinessNameit. com\allshares\softdist.

302 286 Microsoft Windows Server System Deployment Guide for Midsize Businesses To modify the policies to add the packages for software installation 1. For the Desktop, Mobile, Restricted, and Task Workstation computer policies, perform the following steps: a. In the Group Policy Management Console, right-click each GPO, and then click Edit. b. Within the Group Policy Object Editor, go to Computer Configuration/Software Settings/Software Installation. c. Right-click the Software Installation node, click New, and then click Package. d. Browse to the DFS or UNC path of the folder where the software distribution files are stored (for example, \\BusinessName. com\allshares\softdist), select Shadow- CopyClient.msi, and then click Open. e. Select Assigned, and click OK. f. Right-click the Software Installation node, click New, and then click Package. g. Browse to the location of the Windows Firewall client. In the medium IT environment, the file is located under the DFS Root at \\BusinessName.com\allshares\ISA Firewall Client or at \\MOISA\mspclnt. h. Select MS_FWC.msi, and then click Open. i. Select Assigned, and click OK. 2. For the BO Computer GPO, perform the following steps: a. In the Group Policy Management Console, right-click the GPO, and click Edit. b. Within the Group Policy Object Editor, go to Computer Configuration/Software Settings/Software Installation. c. Right-click the Software Installation node, click New, and then click Package. d. Browse to the DFS or UNC path of the folder where the software distribution files are stored (for example, \\BusinessName. com\allshares\softdist), select Shadow- CopyClient.msi, and then click Open. e. Select Assigned, and click OK. 3. For the Kiosk Computer GPO, perform the following steps: a. In the Group Policy Management Console, right-click the GPO, and click Edit. b. Within the Group Policy Object Editor, go to Computer Configuration/Software Settings/Software Installation. c. Right-click the Software Installation node, click New, and then click Package.

303 Chapter 9: Managing Desktops by Using Group Policy 287 d. Browse to the location of the Microsoft Firewall Client. In the medium IT environment, the file is located under the DFS Root at \\BusinessName.com\allshares\ISA Firewall Client, or at \\MOISA\mspclnt. e. Select MS_FWC.msi, and then click Open. f. Select Assigned, and click OK. Real World Lucerne Publishing used Active Directory to deploy the ISA client and Volume Shadow Copy service client software. In addition, they deployed Microsoft Office, graphics programs, and the WaveMaster software. They deployed WaveMaster by creating their own MSI file for the distribution. For more information on creating a custom MSI file, refer to Microsoft Knowledge Base Article , HOW TO: Create Third-Party Microsoft Installer Package (MSI), at support.microsoft.com/?id= Configuring Wireless Settings (Optional) This section provides the steps to automate the configuration of wireless settings on mobile client workstations. Configure wireless settings for the mobile computer by performing the following steps: 1. In the Group Policy Management Console, right-click the GPO, and then click Edit. 2. Within the Group Policy Object Editor, go to Computer Configuration/Windows Settings/Security Settings/Wireless Network (IEEE ) Policies. 3. Right-click the Wireless Network (IEEE ) Policies node, and click Create Wireless Network Policy. 4. Complete the wizard by accepting all default values, except on the Wireless Network Policy Name page, where you should type the name Client Computer Wireless Configuration. 5. When you click Finish, the Client Computer Wireless Configuration Properties dialog box opens. Click the Preferred Networks tab, and then click the Add button. 6. On the Network Properties tab of the New Preferred Setting Properties dialog box, type the SSID of your wireless network. 7. In the Wireless Network Key (WEP) section, select all three check boxes. 8. Click the IEEE 802.1x tab. 9. For EAP Type, select Protected EAP (PEAP) from the drop-down list. 10. Click OK twice.

304 288 Microsoft Windows Server System Deployment Guide for Midsize Businesses Configuring SUS (Optional) This section provides the steps to automate the configuration of SUS on client computers. For the Internal Servers, External Servers, Desktop, Mobile, BO, Restricted, and Task Workstation computer policies, perform the following steps to configure SUS settings: 1. In the Group Policy Management Console, right-click each GPO, and click Edit. 2. Within the Group Policy Object Editor, go to Computer Configuration/Administrative Templates/Windows Components/Windows Update. 3. Right-click the Specify intranet Microsoft update service location node, and click Properties. 4. In the Properties dialog box, change the setting to Enabled. 5. Set both fields to the address of the SUS server (for example, and then click OK. Configuring Roaming Profiles (Optional) This section provides the steps for configuring roaming profiles, which involves the following tasks: 1. Create a roaming-profiles shared folder, and disable offline folders. 2. Create the DFS link. 3. Configure user profiles to roam. To create a roaming profiles shared folder and disable offline folders 1. Create a folder on the data partition of the server to store the user profiles, or if available, on the Windows Storage Server. 2. Open the folder properties, and on the Security tab, click the Advanced button. 3. Clear the Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here check box. 4. On the message that appears, click the Remove button, and then click OK. On the warning message, click Yes. 5. Ensure that the Domain Users group has Read & Execute, List Folder Contents, Modify, and Read permissions. Ensure that the Domain Admins group has Full Control permissions. 6. Share the folder. Grant the Domain Users group Change and Read permissions, and the Domain Admins group Full Control permissions. Remove any other users or groups from the permissions list. 7. Click the Sharing tab, and click the Offline Settings button.

305 Chapter 9: Managing Desktops by Using Group Policy Select the Files or programs from the share will not be available offline option. 9. Click OK. Note If you have not implemented the guidance provided in Chapter 7 and do not have an existing DFS root, you can skip the following section. To create the DFS link 1. Open the Distributed File System management console, and then open the DFS root created in the Configuring DFS section in Chapter Right-click the DFS root, and click the New Link option. 3. Enter the following link properties, and then click OK: a. Link Name: RoamingProfiles b. Path to Target: \\<servername>\shared folder for roaming profiles To configure user profiles to roam Note The following steps can be completed only after you have created user accounts in the domain. In addition, the steps must be repeated for each new user added to the domain. Complete the following steps after you have configured the environment and added users, but before users log on for the first time. In addition, refer to this section and complete these steps each time a new user is added to the environment. 1. Open the Active Directory Users and Computers console, and select the OU where the users are located. 2. Open Properties for each user, and click the Profile tab. 3. Type the DFS path of the folder where the profile of the user is to be stored; for example, \\BusinessNameit. com\allshares\roamingprofiles\%username%. For more information on configuring roaming user profiles, refer to the Step-by-Step Guide to User Data and User Settings document available at /prodtechnol/windowsserver2003/proddocs/deployguide/dmebc_dsm_wntz.asp.

306 290 Microsoft Windows Server System Deployment Guide for Midsize Businesses Configuring Branch Office Policy Settings (Optional) This section provides the steps to disable slow link detection in the Branch Office Group Policies and update the registry on the branch office clients. These steps should be performed only after confirming that group policies are not being applied to branch office clients due to domain controller connectivity issues. To disable slow link detection for the Branch Office Computer Group Policy 1. In the Group Policy Management Console, right-click the GPO, and then click Edit. 2. In the Group Policy Object Editor, go to Computer Configuration/Administrative Templates/System/Group Policy. 3. Right-click the Group Policy slow link detection node, and click Properties. 4. In the Properties dialog box, on the Settings tab, click Enabled, change the value of Connection speed to 0, and then click OK. To disable slow link detection for the Branch Office User Group Policy 1. In the Group Policy Management Console, right-click the GPO, and then click Edit. 2. Within the Group Policy Object Editor, go to User Configuration/Administrative Templates/System/Group Policy. 3. Right-click the Group Policy slow link detection node, and click Properties. 4. In the Properties dialog box, on the Settings tab, click Enabled, change the value of Connection speed to 0, and then click OK. To add a registry entry on a branch office client Add the following registry entries on each branch office client by performing the following steps: 1. Log on as administrator, click Start and then Run, type regedit, and then click OK. 2. Navigate to the following keys and add values as indicated: a. Navigate to HKey_Local_Machine\Software\Policies\Microsoft\Windows\System. Create a DWORD entry named GroupPolicyMinTransferRate, set to a value of 0. Note exist. You will have to create the System key in these steps, if it does not already b. Navigate to HKey_Current_User\Software\Policies\Microsoft\Windows\System. Create a DWORD entry named GroupPolicyMinTransferRate, set to a value of 0.

307 Chapter 9: Managing Desktops by Using Group Policy 291 Note You will have to create the Windows and System key in these steps, if it does not already exist. Also, because this is a Current User key and value, it must be created for each user who logs on to this Branch Office computer. 3. Exit Regedit, and restart the computer. 4. Verify that Group Policy is applied successfully and that no errors appear in the Application event log related to Group Policy. Performing Final Security Configuration Validation After completing the Active Directory configuration, it is important to complete a full security audit on all servers to ensure that they are completely secured. To do this, run the MBSA tool against all servers in the environment. Deploying and Operating Once you have implemented your OU structure and applied your policies, you can use the Group Policy Management Console to create policies, import templates, and examine settings. References For more information on the Group Policy Management Console and Resultant Set of Policy, refer to

308

309 Chapter 10 Enabling Remote User Access This chapter provides guidance on how to establish a variety of remote connections that might be required by branch offices and remote computers. This chapter assumes that ISA Server is deployed as a firewall solution at the main office. ISA Server greatly simplifies the setup of VPN connectivity. It discusses the following scenarios: Building and configuring Virtual Private Network (VPN) services for remote client access and site-to-site connections. Configuring remote access using Terminal Services. Remote Connection Infrastructure Design Remote connections are typically required by branch offices and remote computers (portable, home, and public computers). Remote connections are required to establish either of the following two types of connections: Client-to-site remote connections: A computer establishes a remote connection to the main office, and only that computer uses the connection. Typically, such connections are established for short durations when required to access the network at the main office. This type of connection is required by: Mobile users with laptops. Mobile users working on public computers at kiosks. Home users working on home computers. Employees of partner organizations. Site-to-site remote connections: A single remote connection is used by multiple computers to access resources at the main office. These remote connections are established permanently and are broken only due to network problems. This type of connection is required by branch offices, where a single remote connection is established by the branch office router and is used by all computers at the branch office to access resources at the main office. The following sections provide guidance on designing the infrastructure for both types of connections. 293

310 294 Microsoft Windows Server System Deployment Guide for Midsize Businesses Choosing a Remote Connection Method The remote connection method is used to connect two entities. An entity might be a client, such as a portable or home computer, or a site, such as the main or branch office. There are typically three choices for remote connections. Network administrators can choose a dedicated point-to-point connection over leased lines, dial-in access by modem, or Virtual Private Network (VPN) connections established over the Internet. In most cases, VPN is the most cost-effective option, and is capable of providing the best performance, because Internet connections probably already exist in all locations. Choosing an Authentication Technique and VPN Protocol Among the primary decisions to be made while designing the VPN service are how to securely authenticate an entity s credentials, and what protocol to use to securely transfer data over the Internet. This chapter will discuss Point-to-Point Tunneling Protocol (PPTP) with Microsoft Challenge Handshake Authentication Protocol 2 (MS-CHAP v2) for client-to-site VPN, because it is simple and easy to set up and configure. If an organization wants higher security and has a certificate infrastructure that is capable of supporting features such as autoenrollment and autorenewal of certificates, it is recommended to use Layer Two Tunneling Protocol (L2TP)/ IP Security Protocol (IPsec) with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication. For site-to-site VPN access, the configuration described will use IPsec with pre-shared authentication even though it is less secure compared to other choices. This is because most non- Microsoft VPN devices or firewall broadband routers support only IPsec with pre-shared authentication. VPN Service Deployment Design The VPN service must be deployed at the main office to receive requests from the branch office and remote computers, and to establish VPN connections. This section provides guidance on choosing the right server or device for hosting the VPN service at the main office. The VPN service must be capable of: Establishing site-to-site VPN connections from branch offices and client-to-site VPN connections for remote client computers. This requires supporting the following: PPTP-based client-to-site VPN connections. Pre-shared IPsec-based site-to-site VPN connections from non-microsoft firewalls and VPN broadband routers at branch offices. Supporting multiple client-to-site and site-to-site VPN connections simultaneously. Providing support for Active Directory-based integrated authentication for remote VPN users.

311 Chapter 10: Enabling Remote User Access 295 This chapter will describe hosting the VPN service at the main office on a firewall server running Internet Security and Acceleration (ISA) Server In addition to securing the network with its firewall capabilities, ISA Server enables straightforward configuration options for VPN access. VPN Client Software Installation and Configuration Choices for installing and configuring VPN client software include: Manually installing and configuring. Using Microsoft Connection Manager Administration Kit (CMAK). There is no real advantage to using manual configuration. The only reason to do it is that if you are not familiar with CMAK and there are only a few VPN users, manual installation and configuration could be used to save the time required to become familiar with CMAK. For environments with multiple VPN users and frequent requests for VPN access, using CMAK to automate VPN client installation and configuration is highly recommended. IP Address Allotment to VPN Clients When a remote client computer connects to the main office LAN using a client-to-site VPN, it needs to be assigned an IP address so that it can communicate with the other devices and access the resources on the LAN. The pool of addresses from which the remote client computers are assigned IP addresses can be configured in the following ways: Static address pool: The VPN server is configured with a range of static IP addresses from which the remote computers are assigned IP addresses. Dynamic address pool: The VPN server is configured to request a small number of IP addresses from the DHCP server running in the internal network. Once the VPN server assigns all the requested IP addresses to remote computers and runs out of more IP addresses, it requests the DHCP server for more addresses. The pool of addresses used by the VPN service can be static or dynamic. Table 10-1 provides a comparison of these two choices. Table 10-1 Static Address Pool Versus Dynamic Address Pool Choices Advantages Disadvantages Static address pool Dynamic address pool Easy and Quick: Configuration can be done easily and quickly in the ISA Server management console of the firewall server, and does not require making configurations on another server. Centralized management: Allows centralized management of DHCP scope assigned for remote computers using DHCP MMC. No centralized management: It is not possible (using the DHCP MMC) to determine which IP address has been assigned to a remote computer. Complexity: Involves complexity, and more configuration steps than the static pool configuration.

312 296 Microsoft Windows Server System Deployment Guide for Midsize Businesses This chapter will describe using a static address pool, because it can be configured easily and quickly. Configuring VPN Services This section provides guidance on building the VPN service, publishing internal resources by using HTTPS for secure remote access using the Internet, and building, publishing, and enabling Terminal Server access. The general implementation overview of the remote connectivity solution is as follows: Configure remote access through VPN. Configure remote access through Terminal Services. Note If the steps in this section do not specify the exact values to be used while running a wizard, use the default values provided by the wizard. Configuring Remote Access Through VPN Configuring VPN services involves the following tasks: Configure a site-to-site VPN. Configure a client-to-site VPN. Configure home clients for VPN Access. Configuring a Site-to-Site VPN Establishing a site-to-site VPN between the main office and branch offices involves the following tasks: Configure a site-to-site VPN on the firewall server at the main office. Configure a site-to-site VPN on the multi-purpose firewall and VPN router at the branch office. Note Before starting the site-to-site VPN configuration, back up the present working configuration on the ISA Server using the steps provided in the Backing Up the ISA Server Configuration section in Chapter 3, Installing and Configuring Firewalls. Configuring a Site-to-Site VPN on ISA Server 2004 at the Main Office Configuring a site-to-site VPN on ISA Server 2004 at the main office involves the following steps:

313 Chapter 10: Enabling Remote User Access 297 Create the branch office (remote) network object definition (on ISA Server). Create the network rule. Create the access rule. Customize the configuration. To create the branch office network object definition (on ISA Server) 1. In the ISA Server Management console, click Virtual Private Networks (VPN). 2. In the center pane, click Remote Sites, and then under the Tasks tab in the right pane, click the Add Remote Site Network link. 3. On the Welcome page, provide a name for the remote site (for example, BO1). 4. On the VPN Protocol page, click IP Security protocol (IPSec) tunnel mode. 5. On the Connection Settings page, type the public IP address of the remote site VPN gateway at the branch office in the Remote VPN Gateway IP Address field. This is the IP address of the external interface of the branch office VPN router. Select the IP address of the ISA firewall s external interface from the Local VPN Gateway IP Address dropdown list. 6. On the IPSec Authentication page, select Use pre-shared key for authentication, and type a strong password. Note It is important that you remember this password, because it will be used later while you are configuring the remote site VPN gateway. Using a certificate created by a CA provides higher security than using a pre-shared key. A pre-shared key is used because the low-end VPN gateway that was used at the branch office did not support certificates and supported only pre-shared keys. If the remote VPN gateway is capable of supporting certificates, it is strongly recommended to use certificates instead of a pre-shared key. 7. On the Network Addresses page, add the internal network IP address range of the branch office (for example, ), and complete the setup. It is not necessary to apply the changes at this stage, because the site-to-site VPN configuration is not yet complete. To create the network rule 1. In the ISA Server Management console, expand Configuration, and then click Networks. 2. In the center pane, click Network Rules. In the right pane, click Tasks, and then click the Create a new Network Rule link. 3. Type a name for the rule (for example, MO-VPN1), and add the following values: Network Traffic Source: Internal

314 298 Microsoft Windows Server System Deployment Guide for Midsize Businesses Note Internal network objects can be found under Networks in the Add Network Entities page. Network Traffic Destination: Branch office network; for example, BO1. Note Branch office network object can be found under Networks in the Add Network Entities page. 4. On the Network Relationship page, click the Route option button, and finish the setup. Now you need to create the access rule that will allow VPN traffic from the main office to the branch office and from the branch office to the main office. To allow VPN traffic from the main office to the branch office 1. In the ISA Server Management console, click Firewall Policy. 2. In the right pane, click Tasks, and then click the Create New Access Rule link. 3. Type a name for the rule (for example, MO-VPN1 to BO1). 4. On the Rule Action page, select Allow. 5. On the Protocols page, click All outbound traffic in the This rule applies to dropdown list. 6. Add the following values: a. Access Rule Source: Internal. Click Next. b. Access Rule Destination: BO1. 7. Complete the setup. To allow VPN traffic from the branch office to the main office 1. Click the previously created firewall rule (MO-VPN1 to BO1) in the Firewall Policy tab, and then copy and paste the rule. This will create a copy of the policy with the name MO-VPN1 to BO1 (1) on the firewall policy console. 2. Right-click the copied rule (MO-VPN1 to BO1 (1)), and click Properties. 3. Click the General tab, and change the name to BO1 to MO-VPN1. 4. Click the From tab, remove the Internal network, and add the branch office (BO1) network. 5. Click the To tab, remove the branch office (BO1) network, and add the Internal network. Click OK.

315 Chapter 10: Enabling Remote User Access 299 To establish a site-to-site VPN between the firewall server at the main office and the multipurpose firewall and VPN router at the branch office, the IPsec configuration values on both sides must be the same. ISA Server needs to be configured properly for the IPsec configuration values to match the VPN configuration on the remote VPN router available at branch office. In the test lab, the ISA Server was configured as follows: 1. In the ISA Server Management console, click Virtual Private Network (VPN). 2. Click Remote Sites, and then double-click the access rule defined for the branch office (for example, BO1). 3. On the BO1 Properties page, click the Connection tab. Then click IPSec Settings, and set the configuration as follows: Phase I: Encryption Algorithm: 3DES Integrity Algorithm: SHA1 Diffie-Hellman group: Group 2 (1024 bit) Authenticate and generate a new key every: seconds Phase II: Encryption Algorithm: 3DES Integrity Algorithm: MD5 Generate a new key every: 3600 seconds Enable Use Perfect Forward Secrecy (PFS) Diffie-Hellman group: Group 2 (1024 bit) 4. Save the changes. 5. Click Apply to save the changes on ISA Server and ensure that the changes are applied successfully. Configuring a Site-to-Site VPN on the Remote VPN Gateway at the Branch Office The VPN gateway at the branch office should be configured to match the VPN configuration of the ISA firewall at the main office. In this example, the Linksys BEFSX41 broadband firewall and VPN router is used for configuring VPN. There are many VPN-capable firewall devices on the market today, and Linksys is used purely as an example. For more information, please consult the documentation for your VPN-capable router. Before you start configuring the VPN feature on the non-microsoft firewall and VPN router, the existing firewall service configuration should be changed to avoid the Domain Name Service (DNS) caching issue that arises because of the use of both the internal and the external

316 300 Microsoft Windows Server System Deployment Guide for Midsize Businesses (public) DNS servers. Make sure to remove the IP addresses of the public DNS servers provided by the ISP and include only the IP addresses of the internal DNS servers on the branch office router. In addition, make sure to include the IP addresses of the Windows Internet Name Service (WINS) servers to help legacy clients that need WINS servers for name resolution. Since the internal DNS servers at the main office can resolve Internet-based DNS queries, the branch office router use these internal DNS servers for name resolution after the VPN tunnel is established between the branch office and the main office. This allows the branch office client to resolve the names of both internal and external (Internet) systems. Configure the Linksys BEFSX41 broadband firewall and VPN router in the branch office as shown below. Make sure to update the router firmware to the latest version. For more information on router firmware update, contact the manufacturer of the router or refer to the manufacturer s Web site. To configure the broadband firewall and VPN router 1. On the Setup tab of the router configuration software, configure the router parameters as shown in Table Table 10-2 Router Configuration Parameter Value Host name MO1RTR Domain Name BusinessName.com Time Zone As required LAN IP Address (IP Address) Subnet Mask (Subnet Mask) 2. Release and renew the IP configuration on the DHCP client system by using the ipconfig command, and then continue as indicated in Table Table 10-3 Router Configuration Parameter Value WAN Connection Type Static IP Specify WAN IP Address Provided by the ISP Subnet Mask Provided by the ISP Default GW Provided by the ISP DNS (Required) (IP address of Internal Primary DNS server) (IP address of Internal Secondary DNS server)

317 Chapter 10: Enabling Remote User Access On the Firewall tab of the router configuration software, configure the router parameters as shown in Table Table 10-4 Router Configuration Parameter Advanced Firewall Protection Web Filter: Proxy Java ActiveX Cookie Block WAN Request Multicast Pass Through IPSec Pass Through PPTP Pass Through PPPOE Pass Through Remote Management Remote Upgrade MTU Value Enabled Allow Allow Allow Allow Enable Enable Enable Enable Enable Disable Make unavailable Auto 4. On the DHCP tab of the router configuration software, configure the router parameters as shown in Table Table 10-5 Router Configuration Parameter Value DHCP Server Enable Starting IP address Number of DHCP Users 50 Client Lease Time DNS (IP address of Internal Primary DNS server) DNS (IP address of Internal Secondary DNS server) WINS On the Log tab, set Log to Enable. After this configuration is complete, perform the following VPN service configuration on the branch office router: 1. On the Web user interface of the branch office router, click the VPN tab.

318 302 Microsoft Windows Server System Deployment Guide for Midsize Businesses 2. In the drop-down menu, click Tunnel 1 (-) and on the This Tunnel option, click Enable. 3. Under the Tunnel Name option, provide a name for the VPN tunnel (for example, BO1 to MO). 4. Set the values shown in Table 10-6 on the router. Table 10-6 Parameter Local Secure Group Remote Secure Group Remote Security Gateway Encryption Authentication Key Management Pre-shared Key Key Lifetime VPN Configuration Value 5. Click Apply to save the changes. On the drop-down menu, click Subnet. IP: ; (Internal Network Address of branch office-1) Mask: On the drop-down menu, click Subnet. IP: ; (Internal Network Address of Main Office) Mask: IP address of external interface of ISA Server. 3DES MD5 On the drop-down menu, click Auto (IKE). Select the PFS (Perfect Forward Secrecy) check box. Enter a strong password. The pre-shared key or password entered on this router and ISA Server should be the same secs 6. Click the Advanced Setting tab. Use the values in Table 10-7 for configuring advanced settings. Table 10-7 Phase 1 Advanced VPN Configuration Parameter Value Operation mode: Main Mode Encryption Authentication Group 3DES SHA 1024bit Key Lifetime 28800

319 Chapter 10: Enabling Remote User Access 303 Table 10-7 Phase 2 Advanced VPN Configuration Parameter Encryption Authentication PFS Group Key Lifetime Value 3DES MD5 ON 1024 bit 3600 seconds Other Options Enable NetBIOS Broadcast 7. Click Apply to make the changes. 8. On the VPN tab, click Connect. After some time, you should be able to get Connected status. You can view the conversation between the two VPN gateways by clicking View Logs on the VPN tab. In addition, you can view the current status of the VPN tunnel connection by clicking Summary (located next to where tunnel name was initially defined) on the VPN tab. The same procedure should be followed to establish VPN tunnels between other branch offices and the main office. Pay special attention when dealing with the network IP addresses of the internal networks of the main office and the branch offices while configuring the remaining branch office routers. Take special care when dealing with the IP addresses of end gateways. Configuring a Client-to-Site VPN Configuring client-to-site VPN involves the following tasks: 1. Create VPN users and a VPN users group in the Active Directory infrastructure. 2. Configure the RADIUS server for VPN client access. 3. Configure ISA Server for VPN client access. 4. Create the VPN client access rule. 5. Configure the client computer for VPN access. 6. Configure home clients for VPN access.

320 304 Microsoft Windows Server System Deployment Guide for Midsize Businesses Creating VPN Users and a VPN Users Group on the Active Directory Infrastructure To allow remote VPN users to connect to the network, a domain user account should be created on the Active Directory structure with dial-in permissions enabled. It is recommended to create a VPN users group and add the VPN users to this group. Before creating VPN users and a group for these VPN users, verify that the Active Directory domain is in the native mode or the Windows Server 2003 functional level by performing the following steps: 1. On the primary infrastructure server (MOCOR1), open the Active Directory Domains and Trusts snap-in under Administrative Tools. 2. Right-click the domain name (BusinessName.com), and click Properties. On the Properties page, ensure that Domain functional level is set to Native or Windows Server To create a group for VPN users on the Active Directory structure 1. On the primary infrastructure server (MOCOR1), open the Active Directory Users and Computers snap-in under Administrative Tools. 2. Expand the domain name. Right-click the Users container, click New, and then click Group. 3. On the New Object Group page, type a name for the group in the Group name field (for example, VPN Users Group), and finish the setup. To create a VPN client user account on the Active Directory structure. 1. On the primary infrastructure server (MOCOR1), open the Active Directory Users and Computers snap-in under Administrative Tools. 2. Expand the domain name. Right-click the Users container, click New, and then click User. 3. On the New Object User page, provide the user s first and last name and logon name (for example, [email protected]). Provide a strong password for this user according to your organization s security policy. If you want to create an Exchange box for this user, select the Create an Exchange mailbox check box. To move the user that you created previously to the VPN Users Group 1. Double-click the VPN users group that was created previously. 2. On the Properties page, click the Members tab. 3. Click Add, add the existing user (for example, testuser100), and complete the setup.

321 Chapter 10: Enabling Remote User Access 305 To verify that the user has been configured for VPN dial-in access 1. On the domain controller, open the Active Directory Users and Computers snap-in. 2. Select the user who needs to be given VPN dial-in access (for example, testuser100. Rightclick the user name, click Properties, and then click the Dial-in tab. 3. In the Remote Access Permission (Dial-in or VPN) list, ensure that Control access through Remote Access Policy is selected. In addition, verify that the user is member of the VPN Users Group by clicking the Member Of tab. Configuring the RADIUS Server for VPN Client Access The Internet Authentication Service (IAS) running on the primary infrastructure server (MOCOR1) enables the use of Remote Authentication Dial-in User Service (RADIUS) authentication for VPN clients. For information on configuring IAS on MOCOR1, refer to Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server To complete RADIUS-related configuration on MOCOR1 1. Log on to MOCOR1 as the domain administrator. Open the Internet Authentication Services MMC. 2. In the left pane, right-click RADIUS clients, and click New RADIUS Client. 3. On the New RADIUS client page, under Name and Address, add the ISA server as RAIDUS client. Provide a friendly name in the Friendly name text box, for example, ISA server. Enter the host name of the ISA server, which is MOISA, in the Client address (IP or DNS) text box. Click Next. 4. On the New RADIUS client page, under Additional Information, enter a strong shared secret word in the Shared Secret text box, and enter the same secret word in the Confirm shared secret text box. Remember this shared secret, because it will be required when you configure the ISA server later for RADIUS authentication. 5. Select the Request must contain the Message Authenticator attribute check box. 6. Complete the setup. 7. On the Internet Authentication Service MMC, right-click Remote Access Policy in the left pane, and click New Remote Access Policy. 8. On the Welcome page, click Next. 9. On the Policy Configuration Method page, type a meaningful name for the remote access policy in the Policy name text box (for example, Remote Access Policy for VPN Users). 10. On the Access Method page, ensure that the VPN option is selected. 11. On the User or Group Access page, ensure that Group is selected, and on the Select Groups page, click Add, enter VPN Users Group, and click OK.

322 306 Microsoft Windows Server System Deployment Guide for Midsize Businesses 12. On the Authentication Methods page, ensure that only Microsoft Encrypted Authentication version 2 [MS-CHAPv2] is selected. 13. Complete the setup. Configuring ISA Server for VPN client Access Normal The next step is to configure ISA Server. To configure ISA Server for VPN client access 1. In the ISA Server Management console, click Virtual Private Networks (VPN) policy. In the center pane, click VPN Clients, and then in the right pane under Tasks, click Enable VPN Client Access. If you get an error message related to a problem in adding the ISA server to the list of valid remote access servers in Active Directory, issue the following command line on the ISA server and then restart: netsh RAS add registeredservers 2. In the ISA Server Management console, click Virtual Private Networks (VPN) policy. In the center pane, click VPN Clients, and then in the right pane under Tasks, click Configure VPN Client Access. 3. On the General tab, ensure that the Enable VPN client access check box is selected, and then set the maximum number of VPN clients allowed (for example, 20). 4. On the Protocols tab, select the Enable PPTP check box. 5. Complete the configuration. 6. Click Apply to save the changes. 7. Restart the ISA server. Next, you need to define the IP address range and authentication method for the VPN clients. For simplicity, define the static address pool method for assigning IP addresses to VPN clients. We assume that Internet Authentication Service (IAS), which provides RADIUS authentication to the VPN clients, is set up and running on the primary infrastructure server. To define the IP address range and authentication method for VPN clients 1. On the ISA Server Management console, click Virtual Private Network (VPN). In the center pane, click VPN Clients, and then in the right pane under Tasks, click Define Address Assignments. 2. On the Virtual Private Networks (VPN) Properties page, click the Address Assignment tab. Select Static Address Pool as the Select the IP address assignment method option.

323 Chapter 10: Enabling Remote User Access Add the IP address Range (for example, ). Ensure that the address range is not conflicting with other address ranges used anywhere in the internal network, including branch office networks. 4. Click Advanced, and select Use the following DNS server addresses. 5. Type the IP addresses of the internal DNS servers (for example, and ). 6. Select Use the following WINS server addresses, and type the internal WINS servers IP addresses (for example, and ). 7. On the Virtual Private Networks (VPN) Properties page, click the Authentication tab. Ensure that MS-CHAPv2 (and no other method) is selected. 8. On the Virtual Private Networks (VPN) Properties page, click the RADIUS tab, and perform the following tasks: a. Select the Use RADIUS for authentication check box. b. Select the Use RADIUS for accounting (logging) check box. c. Click the RADIUS Server button. On the RADIUS Servers page, click Add. Then, on the Add RADIUS Server page, enter MOCOR1 (host name of the RADIUS server, which is also the primary infrastructure server) in the Server name text box. Click the Change button, and on the Shared Secret page, enter the shared secret word that was created earlier while adding ISA server as a RADIUS client on MOCOR1. Click OK. Select the Always use message authenticator check box. On the Add RADIUS Server page, click OK. On the RADIUS Servers page, click OK. 9. On the Virtual Private Networks (VPN) Properties page, click OK and complete the configuration. 10. In the ISA Server details pane, click Apply to apply the changes to the ISA Server. It might be necessary to restart the ISA Server after making VPN configuration changes. To check whether a restart is needed 1. Open the ISA Server Management console and click Monitoring. 2. Click the Alerts tab, and look for an alert that reads, ISA Server computer restart is required. If there is such an alert, restart the ISA Server. Creating the VPN Access Rule This rule allows the VPN clients to access internal resources securely. Note that the VPN client access to the Internet is through the internal network and not direct. The VPN client cannot directly access the Internet, because split tunneling is disabled by the VPN client software package, which is created later using CMAK. One of the main advantages of using the Edge template for defining a firewall policy is that it automatically creates the access rule on the firewall to allow VPN clients to access internal

324 308 Microsoft Windows Server System Deployment Guide for Midsize Businesses resources as well as the Internet. To see the firewall rules defined on the ISA Server, click Firewall Policy in the ISA Server Management console. The following two rules are already defined: VPN Clients to Internal Network: Allows remote users to establish the VPN session with ISA Server and securely access the internal resources. Web Access Rule: Allows the VPN client that has an established VPN session to access the Internet. Because these two rules are already defined, you have the advantage of not putting effort and time into configuring these access rules. Because of the security risks involved, it is strongly recommended not to allow the client computers, which are connected to the main office network through VPN, to access the Internet directly. Therefore, by default, when the client computer establishes a VPN connection with the internal network at the main office, split tunneling is disabled and the client computer cannot access the Internet directly. Configuring the Client Computer for VPN Access It is difficult for an end user to configure the built-in VPN client software on the Windows desktop operating system. Creating a customized VPN client and distributing it to remote users securely makes this easier. This also eliminates the administrative overhead involved in providing support for configurations and troubleshooting issues. The following steps are involved in creating VPN client software by using the CMAK tool: 1. Create a CMAK service profile of the VPN client software. 2. Install the service profile file on the VPN clients. Creating a CMAK service profile involves the following tasks: 1. Install the CMAK tool on a server in the environment. In this book, the primary infrastructure server was used. 2. Create a service profile for VPN clients using the CMAK tool. To install the CMAK tool on a primary infrastructure server 1. Open Add or Remove Programs, and click Add/Remove Windows Components. 2. Highlight Management and Monitoring Tools, and click Details. 3. Select the Connection Manager Administration Kit check box, and complete the installation. You might need the Windows Server 2003 operating system CD.

325 Chapter 10: Enabling Remote User Access 309 To create a service profile for VPN clients by using the CMAK tool Note Accept the default value unless otherwise stated. 4. From Administrative Tools, open Connection Manager Administration Kit. 5. On the Service Profile Selection page, select New Profile. 6. On the Service and File Names page, provide a name for the service (for example, VPN client for MIT) and for the file (for example, VPNcli). 7. On the VPN support page, select the Phone book from this profile check box. Select Always use the same VPN server, and provide the public domain name for the VPN server or the IP address (for example, vpn.businessname.com). Click Next. 8. On the VPN Entries page, select the VPN client for MIT Tunnel <Default> entry in the Virtual Private Networking entries list, and click Edit. Then perform the following steps: a. On the Edit Virtual Private Networking Entry page, leave the default settings on the General Tab unless you do not want to allow file and print share on the VPN client. b. On the TCP/IP Settings page, ensure that the following settings are selected: Server assigns addresses under Client DNS and WINS configuration. Make this connection the client s default gateway. Use IP header compression. c. On the Security tab, in the Security settings drop-down menu, click the Use advanced security settings option. This option is selected because this book recommends that organizations have the latest operating system on their server and client computers. This option does not support older versions of operating systems, such as Windows Millennium Edition and Windows 98. Under Advanced Security Settings, click Configure and ensure that only the following settings are selected: Require encryption under Data encryption. Microsoft CHAP Version 2 (MS-CHAP v2) under Authentication methods. Do not select other methods. Try Point-to-Point Tunneling First under VPN strategy. If you want to use L2TP, select Try Layer Two Tunneling Protocol First. d. On the Advanced Security Settings page, click OK. e. On the Edit Virtual Private Networking Entry page, click OK.

326 310 Microsoft Windows Server System Deployment Guide for Midsize Businesses 9. On the Phone Book page, clear the Automatically download phone book updates check box. 10. Create a text file, call it proxyconfiguration.txt, and enter the following information: [Automatic Proxy] AutoProxyEnable=1 AutoConfigScript=1 AutoConfigScript= Note Make sure to change the earlier URL to reflect your own ISA server. 11. On the Automatic Proxy Configuration page, select Automatically configure proxy settings, and provide the name of the text file that you just created. 12. Ensure that the Restore the user s previous proxy setting after disconnecting check box is selected. 13. On the Support Information page, provide the phone number the end user needs to call for support if there are any issues with the VPN client setup. 14. On the Connection Manager Software page, verify that the Install Connection Manager 1.3 with this service profile check box is selected. Note that if the client already has a previous version of connection manager, it will be upgraded to the 1.3 version. 15. On the Ready to Build Service Profile page, select the Advanced customization check box. 16. On the Advanced Customization page, choose the following settings: File Name: VPNcli.cms Section name: Connection Manager Key name: Dialup Value: Record the location where the self-extracting binary file is created, and complete the setup. 18. Create a share on the primary infrastructure server (for example, \\MOCOR1\VPNCli), and copy the VPNcli.exe file to this share.

327 Chapter 10: Enabling Remote User Access 311 Installing the Service Profile File on the VPN Clients Installing the service profile file on the VPN clients involves copying the service profile to the client computer and then installing it, after which the software can be used to establish PPTPbased VPN connection to the main office. Configuring Home Clients for VPN Access VPN client software that was created using CMAK can be distributed to home users to install on their home computers. This will enable them to access the IT resources available on the corporate LAN. Installing the CMAK VPN client software service profile file on the VPN clients involves copying the service profile to the home computer and then installing it, after which the software can be used to establish a PPTP-based VPN connection to the main office. Configuring Remote Access Through Terminal Services The general steps involved in building a Terminal Server include: 1. Configuring hardware and installing the operating system. 2. Installing Terminal Services. 3. Installing and activating Terminal Server licensing. 4. Installing the client access license. 5. Adding users to access the Terminal Services applications. 6. Configuring Terminal Services for Web access. 7. Publishing the Terminal Server for TSWeb access. 8. Configuring the internal server for remote access. 9. Installing applications. 10. Deploying Terminal Server client software. 11. Managing the Terminal Server. 12. Configuring client resource redirection. Note If the steps in this section do not specify the exact values to be used while running a wizard, use the default values.

328 312 Microsoft Windows Server System Deployment Guide for Midsize Businesses Terminal Server Deployment Design When deploying a Terminal Server for remote access to business applications, there are two hardware choices: Integrated server: The Terminal Server is installed on a server that also hosts other services. Dedicated server: A separate Terminal Server is built on dedicated server hardware. The main considerations when choosing the hardware for the Terminal Server are the applications that will be run on the server and the users who will access these applications. Some of the critical factors about the applications and users that need to be considered are: Number of applications that will be run on the Terminal Server. Number of users who will run these applications. Number of applications that will be run simultaneously by a single user. Here, consider the following: If a single user is going to run two or three applications, consider at least 10 MB of random access memory (RAM) per user. If a user is going to run more than three applications, consider at least 21 MB of RAM per user. Type of applications: 16-bit, 32-bit, or 64-bit. If you are using a server topology similar to that described earlier in this book, you might benefit from purchasing dedicated hardware to provide Terminal Server access, because there are already multiple services running on each server in the Terminal Server environment. Configuring the Hardware and Installing the Operating System Connect the server to a separate network where other build servers (if any) are installed. Ensure that this network is not connected to any other network. Configuring the server hardware and the operating system involves installing the Windows Server 2003 operating system and completing the network configuration of the Terminal Server, including adding it to the Active Directory domain. The following information will be required for making for the configuration: Server Name: MOTS IP Configuration: DHCP (Reserve MAC address-based IP address on both the DHCP servers) Disk configuration: Two disks configured in RAID 1 and formatted with single NTFS partition.

329 Chapter 10: Enabling Remote User Access 313 Note After adding the ISA server to the Active Directory domain, perform the installation and configuration tasks on the server by logging on as domain administrator. Installing Terminal Services Before installing Terminal Services, it is recommended that you disable Internet Explorerenhanced security settings for members of the Remote Desktop User group. These users have limited privileges on the server, and therefore allowing them to browse the Internet might not be a security risk. To disable the Internet Explorer enhanced security settings for these users 1. From Add or Remove Programs in Control Panel, click Add/Remove Windows Components. 2. Under Components, select Internet Explorer Enhanced Security Configuration, and click Details. 3. Clear the For all other user groups check box. To install Terminal Services 1. While in the Windows Components wizard, install Terminal Services by selecting Terminal Server, and complete the installation. 2. Select Full Security as the Terminal Server setup to enhance the security of the Terminal Server. Using the Relaxed Security setting enables careless or malicious users to alter system files or settings. Therefore, the Full Security setting should be used wherever possible. Use Relaxed Security mode only if your test results indicate that it is necessary. 3. Restart the computer after the installation. Installing and Activating Terminal Server Licensing For smaller deployments, where cost is a critical factor, the Terminal Server and Terminal Server Licensing Server should be installed on the same physical server. In the test scenario, the Terminal Server Licensing Server was installed on the server hardware on which the Terminal Server was also running. To install Terminal Server Licensing Server 1. Click Start, Control Panel, and Add and Remove Programs, and then click Add/ Remove Windows Components. 2. Under Components, select the Terminal Server Licensing check box, and complete the installation. Choose Your domain or workgroup as the Terminal Server Licensing Setup during the installation, because typically there is only one domain in a midsize business IT.

330 314 Microsoft Windows Server System Deployment Guide for Midsize Businesses 3. To enable the Terminal Server to detect the Terminal Server Licensing Server, complete the steps described in the Knowledge Base article at support.microsoft.com/?id= To activate Terminal Server Licensing 1. On the computer running Terminal Server License Server, click Start, All Programs, Administrative Tools, and Terminal Server Licensing. 2. Right-click the license server, and click Activate Server. 3. Activate the license server using the telephone as the activation method. If you have an Internet connection at this point, use the Internet as activation method, which is faster, and complete the activation by following the instructions on the computer screen. Installing the Client Access License When installing the client access license, consider the following: The organization must select the licensing mode that they want to use from the following choices: Per device Per user By default, the Terminal Server is configured for per device mode. Per user licensing is not monitored by the Terminal Server. For more information on licensing modes, refer to /documentation/windowsserv/2003/all/deployguide/en-us/sdcce_term_sswl.asp. If you have already purchased the client access licenses, complete their installation. If not, first buy the licenses and then install them by right-clicking the license server and then clicking Install Licenses. Ensure that the same licensing mode is selected on both the Terminal Server and the licensing server. For more information about Terminal Services, refer to /windowsserver2003/techinfo/overview/quickstart.mspx#xsltsection Adding Users to Access the Terminal Services Applications The Terminal Server user must be a part of the built-in Remote Desktop Users group to access the applications running on the Terminal Server. It is recommended that you create a Terminal Server users group on the domain controller and place all the Terminal Server domain users in that group. Then move the Terminal Server users group to the built-in Remote Desktop Users group on the Terminal Server. This way, the management of Terminal Server users and the related GPO policies, if any, can be conducted from a single place.

331 Chapter 10: Enabling Remote User Access 315 To create the Terminal Server users group on the primary infrastructure server 1. Log on to the server as domain administrator. 2. In Administrative Tools, open Active Directory Users and Computers. 3. Under the BusinessName.com domain, right-click Users, point to New, and then click Group. 4. On the New Object Group page, enter a Terminal Server users group name (for example, TS Users Group), and complete the configuration. 5. On the right pane, double-click the Terminal Server users group created previously (for example, TS Users Group). On the Properties page, click the Members tab, and add the domain user accounts of Terminal Server users. 6. Click Apply, and then click OK to complete the configuration. To add the Terminal Server users group to the built-in Remote Desktop Users group on the Terminal Server 1. Log on to the Terminal Server as administrator, and in Administrative Tools, open Computer Management. 2. Click Local Users and Groups, and then in the right pane, double-click Groups. 3. In the right pane, double-click the Remote Desktop Users group. On the Remote Desktop Users Properties page, click Add, and click the previously created Terminal Server users group (for example, TS Users Group). Click Apply, and then click OK to complete the configuration. Configuring Terminal Services for Web Access Terminal Services Web access should be configured so that the Terminal Server can be accessed remotely and securely from anywhere on the Internet by using a standard Web browser. To have this feature, the Terminal Server must be installed with Internet Information Services (IIS), the Terminal Server Web package to host the TSWeb Web site, and the relevant SSL certificate for secure HTTP access. ISA Server 2004, which provides the Internet security and publishing services for the medium business, must be configured to publish the internal Terminal Server and the TSWeb Web site to the Internet. The following sequence of events takes place when user accesses the TSWeb Web site remotely: 1. The remote user types in the Web browser. 2. The Web browser is automatically redirected to for secure access. 3. The user is presented with the Remote Desktop Web Connection Web page. The remote user is instructed to install Remote Desktop ActiveX control.

332 316 Microsoft Windows Server System Deployment Guide for Midsize Businesses 4. The user types remote.businessname.com as the server name to connect to the Terminal Server. 5. The user is presented with the Terminal Server s regular Windows logon screen. 6. The user provides the domain credentials. 7. After successful authentication, the user logs on to the Terminal Server. From here, the user can run an application or remotely connect to their desktop by using the Remote Desktop Connection (RDC) tool. The configuration process involves the following steps: 1. Install IIS and Remote Desktop Web Connection software on the Terminal Server. 2. Configure the TSWeb Web site for secure HTTP access. 3. Configure ISA Server 2004 to publish the TSWeb Web site and the Terminal Server. To install IIS and Remote Desktop Web Connection software on the Terminal Server 1. From Add or Remove Programs, open Add/Remove Windows Components. 2. Highlight Application Server (do not select the check box), and click Details. 3. Highlight Internet Information Services IIS (do not select the check box), and click Details. 4. Highlight World Wide Web Service (do not select the check box), and click Details. 5. Select the Active Server Pages check box. 6. Select the Remote Desktop Web Connection check box. 7. Complete the installation. Configuring the TSWeb Web site for secure HTTP access involves performing the following tasks: Configure a certificate on the Terminal Server for SSL communication. Configure the DNS record for remote.businessname.com. Configure a Web site to redirect for secure HTTPS access. To configure a certificate on the Terminal Server for SSL communication Note Ensure that the internal certificate authority (CA) is configured and is running as recommended in Chapter Open Internet Information Services (IIS) Manager. 2. Expand Web Sites, right-click Default Web Site, and click Properties. 3. Click the Directory Security tab.

333 4. Click the Server Certificate button. Chapter 10: Enabling Remote User Access Go through the IIS Certificate Wizard, and specify the following settings (accepting the default choices if the value for a setting is not following specified): a. On the Delayed or Immediate Request page, click Send the Request Immediately to an Online Certification Authority. b. On the Name and Security Settings page, type remote.businessname.com. c. On the Organization Information page, type the name of your company for both Organization and Organizational Unit. d. On the Your Site s Common Name page, type remote.businessname.com. e. On the Geographical Information page, enter the Country, State, and City details. 6. Complete the wizard setup. 7. In the Secure Communications section of the Directory Security tab, click the Edit button. 8. Select the Require secure channel (SSL) and Require 128-bit encryption check boxes. 9. Complete the configuration. To configure DNS records for remote.businessname.com 1. On the primary infrastructure server (MOCOR1), open the DNS management console. 2. In the BusinessName.com zone, create a new Alias (CNAME) record for remote.business- Name.com. The target host is MOts.BusinessName.com. Note When creating the record, you only need to type the host name (for example, Extranet and intranet), because DNS will automatically append the parent domain name. To configure a Web site to redirect for secure HTTP access Perform the following steps to redirect or remote.business- Name.com to 1. Open Internet Information Services (IIS) Manager. 2. Right-click Web Sites, and click New and then Web Site. 3. Run through the wizard, and specify the following settings (accepting the default choices if the value for a setting is not specified): Description: remote.businessname.com Host Header Name: remote.businessname.com Path: <systemdrive>:\inetpub\wwwroot

334 318 Microsoft Windows Server System Deployment Guide for Midsize Businesses 4. Right-click the site you just created, and click Properties. 5. Click the Home Directory tab, and select A redirection to a URL. 6. In Redirect to, type Publishing the Terminal Server for TSWeb Access Terminal Server publishing involves the following tasks: 1. Publish the TSWeb Web site to accept HTTP requests. 2. Publish the TSWeb Web site to accept HTTPS requests. 3. Define the Terminal Server protocol. 4. Publish the internal Terminal Server. To publish the TSWeb Web site to accept HTTP requests 1. In the ISA Server Management console, click Firewall Policy, and then under Tasks in the right pane, click Publish a Web Server. 2. On the Welcome page, type the Web publishing rule name (for example, Publishing Terminal Server - TSWeb Web Site for HTTP access). 3. On the Select Rule Action page, click Allow. 4. On the Define Web Site to Publish page, type the computer name of the internal Terminal Server that hosts the TSWeb Web site in the Computer name or IP Address box (for example, remote.businessname.com). Ensure that ISA Server is able to resolve the name internally. On the Define Website to Publish page, type the computer name of the internal Web server that will be published by the firewall server in the Computer name or IP Address box (for example, remote.businessname.com). 5. To avoid exposing the internal extranet server name (MOTS) to the Internet, create a CNAME (for example, remote) on the internal DNS servers. In the test scenario, this CNAME was defined on the internal DNS servers as part of the Terminal Server TSWeb Web site creation process. For more information and the steps involved in building the TSWeb Web site, refer to the Publishing the Terminal Server for TSWeb Access section later in this chapter. For the internal and external DNS naming convention that should be followed, refer to Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server Ensure that the ISA Server is able to resolve remote.businessname.com to the IP address of the internal terminal server. 6. Select the Forward the original host header instead of the actual one (specified above) check box. 7. On the Public Name Details page, click This domain name (type below), and then type the name that is going to be used by the Internet users in the Public name text box

335 Chapter 10: Enabling Remote User Access 319 (for example, remote.businessname.com). Ensure that the Internet system is able to resolve this name to the IP address of the ISA Server s external interface. 8. On the Select Web Listener page, click Web Listener for Publishing HTTP Sites in the Web Listener drop-down list. 9. Complete the configuration. 10. On the ISA Server Management console, click Apply to save the changes you have made. To publish the TSWeb Web site to accept HTTPS requests 1. In the ISA Server Management console, click Firewall Policy, and then under Tasks in the right pane, click Publish a Secure Web Server. 2. On the Welcome page, type the Web publishing rule name (for example, Publishing Terminal Server-TSWeb Web Site for HTTPS access). 3. On the Publishing Mode page, click SSL Bridging. 4. On the Select Rule Action page, click Allow. 5. On the Bridging Mode page, click Secure communication to clients and Web server. This provides end-to-end encryption between the Web client and Web server. 6. On the Define Website to Publish page, type the computer name of the internal Terminal Server that hosts the TSWeb Web site in the Computer name or IP Address box (for example, remote.businessname.com). Select the Forward the original host header instead of the actual one (specified above) check box. 7. On the Public Name Details page, click This domain name (type below), and then type the name that will be used by the Internet users in the Public name text box (for example, remote.businessname.com). Ensure that the Internet system is able to resolve this name to the IP address of the ISA Server s external interface. 8. On the Select Web Listener page, click Web Listener using wildcard certificate for Publishing HTTPS Sites in the Web Listener drop-down menu. 9. Finish the setup. 10. Double-click the TSWeb Web publishing rule (for example, Publishing Terminal Server TSWeb web site for HTTPS access) that was previously created. On the Properties page, click the Traffic tab, and select the Require 128-bit encryption for HTTPS traffic check box. 11. In the ISA Server Management console, click Apply to save the changes. To define the Terminal Server protocol 1. In the ISA Server Management console, click Firewall Policy, and then in the right pane, click Toolbox. 2. Click Protocols.

336 320 Microsoft Windows Server System Deployment Guide for Midsize Businesses 3. Click New, and then click Protocol. 4. Provide Terminal Server as the Protocol Definition name. 5. In the Primary Connection Information area, click New, and then type the following information: Protocol Type: TCP Direction: Inbound Port Range: From: 3389; To: Complete the setup. 7. In the ISA Server Management console, click Apply to save the changes. To publish the internal Terminal Server 1. In the ISA Server Management console, click Firewall Policy, and then under Tasks in the right pane, click Create New Server Publishing Rule. 2. On the Welcome page, type the Terminal Server publishing rule name (for example, Publishing the Terminal Server). 3. On the Select Server page, type the internal IP address of the Terminal Server. 4. On the Select Protocol page, click Terminal Server on the Selected Protocol dropdown menu. 5. On the IP Addresses page, select the External check box. 6. Complete the setup. 7. In the ISA Server Management console, click Apply to save the changes. Note When you test the access to TSWeb Web site, the Web browser might warn you that you need to download Remote Desktop ActiveX control on your client computer. Configuring the Internal Server for Remote Access The various computers in the IT infrastructure need to be configured to provide remote access to IT generalists or service providers so that they can perform various administrative and troubleshooting tasks from remote places like the IT generalist s home or the service provider s office. Remote access to the internal server can be achieved by one of the following methods: Using Terminal Services: This method uses the Terminal Server running in the medium IT environment. As recommended in this solution, the administrator or service provider in the remote location should first access the Terminal Server by using the TSWeb Web

337 Chapter 10: Enabling Remote User Access 321 access method and then access the internal computer by using the Remote Desktop Client installed on the Terminal Server. This method provides better remote access network performance than remote access using VPN. In addition, the Web client computer does not need to have the VPN client software installed on it. This book recommends this method instead of using remote access by VPN for administrative jobs. Before allowing access to the internal server, you should configure it to allow for remote access. Using a remote management card: Remote access to the internal systems can also be achieved by installing a remote management card that supports the out-of-band (OOB) management feature. The OOB management capability allows the remote administrator to access the server by using the modem-based dial-up access built into the remote management card, and provides access to the server hardware even if the server operating system is not running because of issues like operating system or hard disk failure. To install and configure the remote management card, refer to the server hardware guide that was supplied with the server hardware. The following build steps allow the remote administrator to access the ISA Server from a remote location. Two tasks should be performed to configure the ISA Server to allow remote access. The second task is specific to the ISA Server and is not required for allowing access to other computers in the environment. 1. Enable the Remote Access feature on the ISA Server. 2. Define a firewall rule on the ISA Server to allow RDC from the Terminal Server. To enable the Remote Access feature on the ISA Server Note Follow these same steps on other computers that you need to remotely manage. 1. Right-click My Computer, and click Properties. 2. On the System Properties page, click the Remote tab. 3. Under Remote Desktop, select the Allow users to connect remotely to this computer check box. 4. Click OK. To define a firewall rule on the ISA Server to allow RDC from the Terminal Server 1. In the ISA Server Management console, right-click Firewall Policy, and click Edit System Policy. 2. On the System Policy Editor page, under Configuration Groups, click Terminal Server under Remote Management.

338 322 Microsoft Windows Server System Deployment Guide for Midsize Businesses 3. Click From, and then click Add. 4. On the Add Network Entities page, click New, and then select Computer. Provide the Terminal Server s host name and IP address. This allows the remote user to first connect to the internal Terminal Server using TSWeb Web access and then use RDC on the Terminal Server to connect to the ISA Server. You first need to publish the Terminal Server as recommended in this chapter. 5. On the Add Network Entities page, expand Computers, and click the Terminal Server host name that was previously added. Click Add, and then click Close. 6. On the System Policy Editor page, click OK. 7. Click the Apply button to save the changes to the ISA Server. Now you should be able to connect by using RDC from the Terminal Server. Installing Applications Consider the following recommendations when installing the applications on the Terminal Server: Before installing an application, ensure that the application is compatible with the Terminal Server by installing and testing it in a development environment.. Use Add or Remove Programs to install the applications that you want Terminal Services users to access. Use the Terminal Server console as the preferred method for installing the applications rather than using a remote console session. To reduce network traffic and increase performance, install programs on the local drive instead of using the network share. First install the Terminal Server; then install the applications and ensure that they are working correctly. For performance and security reasons, always use 32-bit programs, and avoid using 16-bit programs. Restrict users to only the program groups that they need to access. Disable any unnecessary program features. Ensure that no users are logged on to the Terminal Server during application installation. Send notification and temporarily disable access to the server for users until the installation is complete.

339 Deploying Terminal Server Client Software Chapter 10: Enabling Remote User Access 323 By default, RDC, which is the latest version of the Terminal Server client, is installed on Windows XP and Windows Server 2003 systems. Systems running other Windows operating systems must install the latest version for improved security and performance. To download the client software, refer to If there are many systems that need the Terminal Services client software installed, use Group Policy to deploy the software on these systems. It is recommended that you create a share on the file server under the DFS link and place the Terminal Server client software on it for public access so that the users can install it whenever there is a problem. Managing Terminal Server Terminal Server and Terminal Server Licensing Server can be managed as follows: The Terminal Server client access licenses can be managed using Terminal Server Licensing. It can be accessed from the Terminal Server by clicking Start, All Programs, Administrative Tools, and Terminal Server Licensing. User sessions can be managed by using the Terminal Service Manager on the Terminal Server, accessed by clicking Start, All Programs, Administrative Tools, Terminal Service Manager. Configurations related to Terminal Services, such as setting the license mode and number of sessions per use, can be defined by using Terminal Service Configuration on the Terminal Server, accessed by clicking Start, All Programs, Administrative Tools, and Terminal Services Configuration. Configuring Client Resource Redirection RDC supports a wide variety of data redirection types, including file systems, serial ports, and printers. Using this feature, a local hard disk drive or network share on the client computer can be redirected and accessed during the Terminal Services session. For example, redirecting the file system allows files to be opened, edited, or saved on the client computer during the Terminal Server session. The business should understand the security risks involved in sharing disk drives during the Terminal Server session. Unless it is required by the business and there is no security risk involved in sharing the disk drives by redirecting them, it is recommended that you not redirect these local resources on the client computer. The various client resources can be redirected by performing the following steps: 1. Log on to the client computer as administrator. Click Start, All Programs, Accessories, and Communications, and then click Remote Desktop Connection. 2. In the Remote Desktop Connection dialog box, click Options.

340 324 Microsoft Windows Server System Deployment Guide for Midsize Businesses References 3. Click Local Resources, and under Local devices, select the devices that you want to redirect to the remote computer. 4. Click the General tab, and provide the computer name of the Terminal Server and the relevant domain authentication information. 5. Click Connect, and accept the warning message by clicking OK to log on to the Terminal Server. 6. Access the redirected resources from the Terminal Server. Tasks such as copying a file between the client computer and the Terminal Server can be done. The following supplementary information and background material is relevant to the contents of this chapter: Terminal Services Scaling Scripts and Utilities, available at /windows2000/techinfo/administration/terminal/loadscripts.asp. Guidelines for Deploying Terminal Server, available at /windowsserver2003/techinfo/overview/quickstart.mspx. Windows Server 2003 Terminal Server Capacity and Scaling, available at e4b7170b33d9&displaylang=en. Locking Down Windows Server 2003 Terminal Server Sessions, available at e6ae6a0d&DisplayLang=en. Frequently Asked Questions about Terminal Server, available at /windowsserver2003/community/centers/terminal/terminal_faq.mspx. Product information about Terminal Server on Windows Server 2003, available at /featuresorterresults.aspx?technology=terminal+services.

341 Chapter 11 Managing the Network The extent to which you configure your monitoring environment depends on several factors, such as business requirements, the complexity and size of your organization s Microsoft Operations Manager (MOM) deployment, and the level of MOM expertise in your IT support group. Planning the Monitoring Environment Consider the following questions before configuring your monitoring environment: What user accounts do you need to implement for monitoring your computers? What individuals or groups of individuals in IT support need to receive notifications? What computer groups and associated rules do you need for monitoring specific computers or groups of computers? What information does your support staff need in order to do their jobs successfully? Are there any requirements or opportunities for using built-in or custom tasks to support problem resolution? Do existing rules need to be customized to provide the best fit for the hardware and software that you want to monitor? Implement the configuration described in this chapter, as appropriate for your MOM deployment. Configuring the Monitoring Environment Configuring the monitoring environment involves the following tasks: 1. Add users to MOM local groups. 2. Add operators. 3. Create notification groups. 4. Create new computer groups. 5. Associate rule groups with computer groups. 6. Create new tasks. 7. Add or modify rule groups and rules. 325

342 326 Microsoft Windows Server System Deployment Guide for Midsize Businesses The first task is performed by members of the MOM Administrators group, and the remianing tasks are performed by membes of the MOM Authors group. Adding Users to MOM Local Groups IT support staff have to be added to one of the MOM local groups. For more information about MOM security, see the Microsoft Operations Manager 2005 Security Guide, available at Note All members of the Local Administrators group are automatically added to the MOM Administrators group. To add a user to the MOM Users group 1. Log on to the MOM Management Server with an account that has sufficient privileges to add users to a local group. 2. On the Start menu, point to Programs, point to Administrative Tools, and then click Computer Management. 3. Expand Local Users and Groups, and then click Groups. 4. Right-click MOM Users, and then click Add to Group to open the MOM Users Properties page. Note In Windows Server 2000, the dialog box is named Select Users or Groups, and the format for adding a user is domain\user. 5. Click Add to open the Select Users, Computers, or Groups dialog box. 6. At the Enter the object names to select prompt, type the name of the user you want to add, and then click OK to close the dialog box. 7. Click OK to close the MOM Users Properties page. You can use the preceding procedure to add users to the other MOM groups, based on the tasks that the users need to perform. For example, any user who needs to edit rules or create a new rule has to be added to the MOM Authors group. Adding Operators You need to identify the operators that you want to notify and how and when they should be contacted. You can do this from the Create Operator dialog box in the Administrator console.

343 To create an operator 1. In the Navigation pane, expand Management Packs. Chapter 11: Managing the Network In the Navigation pane, right-click Operators, and then click Create Operator to open the dialog box for creating an operator. 3. Follow the instructions in the dialog box. Note Changes that you make to a Management Pack are not immediately deployed to managed computers. By default, the MOM Management Server scans for rule changes every five minutes. For more information about global settings, refer to the Administrator Console Reference section of the Microsoft Operations Manager 2005 Operations Guide at /maintain/opsguide/refs2005.mspx. If you want, you can commit Management Pack configuration changes immediately after they are made by using the Administrator console. To commit configuration changes. 1. In the Navigation pane, right-click Management Packs. 2. Select Commit Configuration Change. Creating Notification Groups Notification groups support sending notifications to a group of operators, rather than individual ones. Note MAPI notifications are not supported in MOM Use SMTP or Exchange solutions for sending notifications. After you have finished creating operators for your MOM environment, you can add them to one of the existing notification groups provided by the MOM Management Pack, or you can create a new notification group. Note Predefined notification groups are determined by the Management Packs that you install. The MOM Management Pack creates the Operations Manager Administrators group and the Operations Manager Notification Testing group. A newly created notification group needs to be referenced by a rule response before notifications can be sent to the group. You use the Administrator console to create a notification group.

344 328 Microsoft Windows Server System Deployment Guide for Midsize Businesses To create a notification group 1. In the Navigation pane, expand Management Packs, and then expand Notification. 2. Expand Notification Groups to view the groups that are available. 3. Right-click Notification Groups and then click Create Notification Group to open the Notification Group dialog box. 4. Follow the instructions in the dialog box to create the group and identify the operators that you want to be members of the group. Creating New Computer Groups By using custom computer groups, it is possible to further organize the monitoring and management of computers in your organization. For example, you can create a computer group that consists only of Web servers, and use a computer group as a container for the servers that you specify. Use the Administrator console to create a new computer group. After you create the computer group, it is necessary to associate the computer group with a rule group. To create a new computer group 1. In the Navigation pane, expand Management Packs. 2. Right-click Computer Groups, and click Create Computer Group to start the Create Computer Group Wizard. 3. Follow the wizard steps to create a new computer group. Associating Rule Groups with Computer Groups Use the Administrator console to associate a computer group with a rule group. To associate a rule group with a computer group 1. In the Navigation pane, expand Management Packs. 2. Expand Rule Groups, and locate the rule group that you want to associate with a computer group. 3. Right-click the rule group that you want to configure, and then click Associate with Computer Group to open the Properties page for the rule group. 4. On the Computer Groups tab, click Add to view a list of available computer groups. 5. In the Select Item page, click the computer group that you want, and then click OK. 6. Click OK to save your changes and close the Properties page.

345 Chapter 11: Managing the Network 329 Creating New Tasks You use the Administrator console to create a new task. To create a task 1. In the Navigation pane, expand Management Packs. Right-click Tasks, and then click Create Task to start the Create Task Wizard. Note The task that you create will be saved at the location where you started the wizard. For example, starting the wizard from the Microsoft Operations Manager folder (below the Tasks folder) will cause the new task to be stored at that location in the folder hierarchy. Tip When you right-click Tasks, you also have the option to create a folder that you can use for organizing any new tasks that you create. 2. Follow the wizard steps to create a task. After you create the task, it will appear in the Operator console Tasks pane, but will be active only for the View type (Alerts, Events, Computers) that you configured. Note If the Operator console was open when the task was created, you will have to refresh the console to see the new task. Adding or Modifying Rule Groups and Rules In addition to modifying any of the existing rules in MOM, you can create new rules and rule groups. Consult the Microsoft Operations Manager 2005 Management Pack Guide at CBFAE&displaylang=en before modifying existing rules. Note Before you can modify existing rules, you have to enable Authoring mode. Authoring mode activates user interface features in MOM that enable you to create and edit vendorspecific knowledge. Enabling Authoring mode also enables advanced properties on rules, groups, and other items that are read-only or disabled by default. The Microsoft Operations Manager 2005 Management Pack Guide provides detailed information about Authoring mode. To create a rule group 1. In the Navigation pane, expand Management Packs, and click Rule Groups.

346 330 Microsoft Windows Server System Deployment Guide for Midsize Businesses 2. Expand Rule Groups, and navigate to the location where you want to create a rule group. 3. Right-click the folder where you want to create a rule group, and click Create Rule Group to open the Rule Group properties page. 4. Provide a name and description, and company knowledge, if you want. 5. Click Finish to save the Rule Group. You will be asked whether you want to deploy the rules in the rule group to a group of computers. It is recommended that you do not do this until you have finished adding rules to the rule group. To create a rule 1. In the Navigation pane, expand Management Packs, and click Rule Groups. 2. Expand Rule Groups, and navigate to the rule group where you want to create a rule. 3. Expand the rule group that you have selected, and right-click the type of rule that you want to create (Event Rules, Alert Rules, or Performance Rules). 4. Click Create Event Alert Performance Rule to open a rule dialog box. 5. Follow the steps in the dialog box to create and configure the rule that you want. Note If the Operator console was open when the rule was created, you will have to refresh the console to see the new rule. Working with Alerts The Operator console is the primary interface for working with managed computers. With this console, users can obtain different types of information about the computers they manage, resolve alerts, perform diagnostics, and run tasks against selected computers within the boundaries of the console scope that they are using. Using the Web Console The Web console provides the following subset of Operator console views: Alerts, Computers, and Events. It does not provide the ability to run predefined tasks against a managed computer. Another important difference between the consoles is view filtering. A Web console user can filter any of the views, but this information is not retained after the user navigates away from the view. You can configure the Web console as read-only by using the following procedure.

347 To configure the Web console as read-only Chapter 11: Managing the Network On the server where the console is installed, open the %INSTALLDRIVE%\Program Files\Microsoft Operations Manager 2005\WebConsole\Web.config file in a text editor. 2. Locate the <appsettings> tag. 3. Remove the comment markers to enable addkey="readonly" value="true". 4. Save and close the file. 5. Stop and restart the Microsoft Operations Manager 2005 Web console application in the Internet Information Services snap-in. Operational Data Processing Cycle Managed computers are continuously sending data to the Management Server. Event, performance, alert, and discovery information originates on the managed computer. Although the internal processing of each type of data is different, the data flow is the same. Figure 11-1 illustrates how an alert is handled and processed by an operator. In this example, a WMI event indicating high queue length on an Exchange server provides the starting point in the process. 1 2 Managed computer 3 (1) The agent receives a WMI event indicating high queue length. (2) A rule on the agent creates an alert. (3) The agent sends the alert to the management server. 5 4 Management server 6 (4) The consolidator component in the MOM runtime checks database and suppresses the alert if it is a duplicate. (5) The runtime uses the Data Access Server (DAS) to insert the alert in the database. Operational database Operator console 7 (6) After the alert is inserted in the database, alert information is passed from the runtime to the Operator console to refresh the alerts view. (7) The user acknowledges the alert and generates a trouble ticket or assigns it to an expert. Figure 11-1 Alert processing cycle

348 332 Microsoft Windows Server System Deployment Guide for Midsize Businesses The process described in Figure 11-1 occurs regardless of how MOM is deployed. For example, communication between the DAS and the database is the same when the MOM Database and MOM Management Server are installed on the same computer, or on different computers. Given the steps in the process, the display of new information in the Operator console is almost in real time, rather than in actual real time. The refresh rate, especially for events, is directly related to the size of the operational database and the refresh rate that is configured for the Operator console. There are two points where latency can occur and data transfer can be interrupted: between the agent and the Management Server, and between the Management Server and the operational database. For more information, see Monitor MOM Components in Chapter 3 of the Microsoft Operations Manager Operations Guide at /prodtechnol/mom/mom2005/maintain/opsguide/default.mspx. Important Latency and potential disruption in the data flow are important considerations for configuring high-service availability and performance tuning. Using the Alerts View This section covers the following aspects of working with an alert: Obtaining information about an alert. Setting the alert resolution state. Adding comments to the Alert Details. Using Maintenance mode. Running diagnostic tasks. Service Level Exceptions Service level exceptions are a subset of the Alerts view that is used to flag alerts that have exceeded a predefined service level for the computer being monitored. You can change these settings by opening the Properties page for an alert view and editing the settings. In order to change the default settings, you have to create a custom service level exception. To create a custom service level exception 1. In the Alerts view, click Service Level Exceptions. 2. In the Results pane, right-click the alert displayed as a service level exception to open the alert s Properties page. 3. Click the Criteria tab to display the view description.

349 Chapter 11: Managing the Network The phrase that begins with and that violated will contain the phrase default company as an active link. Click the link to open the Service Level Exception properties page. 5. Click the Custom service level agreement option button to display a list of service level options. 6. Each of the service level options in the list contains minute, hour, or day settings displayed as active links. To change a setting, click the appropriate link to open the Service Level Agreement properties page. 7. Change the setting and click OK to return to the Service Level Exception properties page. 8. When you finish configuring the custom service level exception, click OK. Alerts View Summary If the Alerts view is not active in the Results pane, click the Alerts navigation button. The columns in Table 11-1 are displayed by default for each alert. Table 11-1 Column Name Severity Maintenance Mode Domain Computer Time Last Modified Resolution State Time in State Problem State Repeat Count Name Source Ticket Id Owner Columns Displayed for an Alert Description Indicates the severity of the alert, such as Service Unavailable or Success. Indicates whether the alert is in Maintenance mode. Specifies the domain to which the computer belongs. Specifies the computer on which an agent generated the alert. Specifies the date and time that the alert was last changed. Indicates the status of the resolution process of the alert, such as New or Resolved. The resolution state indicates whether the resolution process has begun. Specifies the amount of time that the alert has been in the current resolution state. Indicates what problem state the alert is in. Specifies the number of identical duplicate alerts that this instance represents. Specifies the name of the rule that generated the alert. Indicates where the alert was generated: for example, from MOM, or a specific server. Specifies the ticket ID assigned to the alert. Specifies the person responsible for tracking and resolving the alert Note The enabled columns chosen from the list in Table 11-1 display only the data that is available. For example, if an Owner is not assigned to the alert, no information is displayed.

350 334 Microsoft Windows Server System Deployment Guide for Midsize Businesses Viewing Alert Details To view the details for an alert, you click the alert in the Results pane. After a specific alert is selected, the tabbed view is dynamically generated for the alert. The following tabs are provided. For more information, see Alert View Sample later in this chapter. Properties: The Properties tab describes the alert and provides additional details, such as the Alert Id and the rule that generated the alert. From this tab you can do the following: Copy all or some of the information and paste it into a text file. Print the information. Disable the rule that generated the alert. To undertake any of the preceding tasks, right-click anywhere in the display area, and choose the action that you want to perform. Custom Properties: The Custom Properties tab enables the user to provide additional information about the alert, including: The alert owner The ticket ID Note This information can be generated programmatically by integrating a ticketing system with MOM Custom fields for adding information that can be used by other users in the IT support group. Events: The Events tab provides the following summary information about the event that generated the alert: Type (Information, Error or Warning), Time, Source Computer, Provider Type, Provider Name, and Source. To view more information about the event, right-click anywhere in the display area, and click View Events. Product Knowledge: The Product Knowledge tab displays the appropriate Management Pack information for the alert. To view the information in the browser window, click the View button.

351 Chapter 11: Managing the Network 335 Company Knowledge: Depending on the console scope, the Company Knowledge tab enables the user to view, copy, print, or add to the company knowledge base. Users who are members of the MOM Authors or MOM Administrators groups can click Edit to open a text editor and create knowledge for the alert. Note When changes are made to the Company Knowledge tab, these changes are not tracked in the alert history. History: The History tab displays summary information about the history of the alert, such as the management group in which it was created and the notification group to which it was sent. A user can add comments to the alert history by clicking the Append button to open the Alert History dialog box. Alerts View Sample The following sample is typical, and represents the type of information that you can obtain in the Details pane of an alert. Properties Tab Error Alert Description: The host process host process for script responses (3036) will be restarted because it is using more bytes than its limit of To adjust this limit, edit the Software\Mission Critical Software\OnePoint\MaxScriptHostPrivateBytes registry key. Management Group: MG2749 Name: The MOM Host process was consuming too much memory and will be terminated Severity: Error Resolution State: New Domain: SMX Computer: WOW406D Time of First Event: 11/23/2004 5:52:00 PM Time of Last Event: 11/23/2004 5:52:00 PM Alert latency: 0 sec Problem State: Investigate Repeat Count: 0 Age: Source: Microsoft Operations Manager Alert Id: 618b8e08-7e f6-d4ed5eeea89e Rule (enabled): Microsoft Operations Manager\Operations Manager 2005\Agents on all MOM roles\the MOM Host process was consuming too much memory and will be terminated

352 336 Microsoft Windows Server System Deployment Guide for Midsize Businesses Product Knowledge Tab Related Knowledge MOM OnlineManagement Pack Summary The Action Account (MOMHost.exe) process was consuming too much RAM (physical) memory and was restarted by MOM. The MOMHost.exe process is run under the agent Action Account and is used to gather information about, and perform actions on, the managed computer. This restart might signify a problem with the managed computer, especially if the host process is restarted often, this might indicate a problem with the managed computer. Causes This could be caused by any of the following: The amount of memory allotted to the process is too small and needs to be increased. The host process is running too many tasks or is gathering data form too many providers at one time. The host process is running scripts that are not freeing resources. Resolutions To troubleshoot and fix this problem: 1. Make sure that the managed computer is not low on resources. 2. If the managed computer rarely uses more than 70% of its RAM memory, you can increase the amount of memory allotted to the MOMHost.exe process. To increase or decrease the amount of memory allotted to the MOMHost.exe process: In Regedit.exe (or some similar Registry editor), change the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Mission Critical Software\OnePoint MaxDefaultHostPrivateBytes REG_DWORD <bytes> NOTE - the default setting for this key value is 0x (100MB). 3. Continue to monitor the process by looking for this alert. If you see this alert for the host process on a specific computer and you have already increased the memory allocation, consider enabling tracing for the computer. To enable or disable tracing for a specific agent: In Regedit.exe (or some similar Registry editor), change the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Mission Critical Software TraceLevel REG_DWORD = = disabled (default) 0-2 = error level tracing only 3-5 = error and warning level tracing only 6 = error, warning and information level tracing NOTE - Setting the registry key value to 4 or higher will affect the performance of the MOM Service on the managed computer. Setting Alert Resolution State When an alert is first received, its resolution state is automatically set to New. Support staff can change this state, as appropriate. To set the alert resolution state 1. In the Results pane, click the alert for which you want to set a resolution state. Tip If there are multiple alerts that originate from a single computer, you can bulkselect the alerts and set a resolution state for all of them.

353 2. Right-click the alert, and then click Set Alert Resolution State. Chapter 11: Managing the Network Choose the state that you want from the list provided to set the state for the alert. Note Some alerts will automatically be resolved when the alert state changes, or might be removed from the operational database during database grooming. Using Maintenance Mode Maintenance mode provides a means of stopping the insertion of alerts in the operational database. This mode does not take the computer that is generating alerts offline; Maintenance mode only instructs the Management Server to set all new, incoming alerts from the computer to Resolved. As a result, the new alerts are not included in health calculations, and responses are not run on the Management Server. To put a computer in Maintenance mode 1. In the Results pane, click the alert for the computer that you want to put in Maintenance mode. 2. Right-click the alert, and click Put Computer in Maintenance Mode to open the Maintenance Mode properties page. 3. You can provide a reason for putting the computer in Maintenance mode, adjust the length of time the computer is in Maintenance mode (the default is 20 minutes), or specify an ending date and time for Maintenance mode. Note It is recommended that you do not use a time interval of less than 5 minutes for Maintenance mode. Due to timing cycles, the Management Server can keep a computer in Maintenance mode for a minimum of 5 minutes. 4. Click OK to close the Properties page and put the computer in Maintenance mode. Tip The Microsoft Operations Manager 2005 Software Development Kit at contains a sample that shows how to programmatically put a computer in Maintenance mode.

354 338 Microsoft Windows Server System Deployment Guide for Midsize Businesses Running Tasks The tasks provided in the Operator console enable an operator, depending on console scope being used, to run preliminary diagnostics to determine the cause of a problem. Table 11-2 summarizes all of the tasks that are provided with MOM Table 11-2 Name Computer Management Available Tasks in Operator Console Event Viewer IP Configuration Ping Remote Desktop Start MOM 2005 Service Stop MOM 2005 Service Test end-to-end monitoring Description Opens the Computer Management snap-in on a specified computer. Opens the Event Viewer for a specified computer. Runs the ipconfig command against a specified computer. Runs the ping command against a specified computer. Opens a Remote Desktop session to a specified computer. Starts the local MOM service Stops the local MOM service Creates an event on a managed computer to test the end-to-end monitoring of the MOM system. The availability of a task to an Operator console user is determined by: The console scope being used. The computer group filter being used. To run a task 1. In the Tasks pane, click the task name, or right-click the task name and then click Run. Note If a task is not available to the current scope, either the Run option will be disabled, or nothing will happen when you click the task name. Tasks that require a higher level of privilege will display an Access is denied error message when you run them. In some cases, you might have to look at the Task Status view to obtain this information. Notes on Other Views The Alerts view is often the primary view used by IT support staff, but the other views provide a means for isolating a problem, as well as meeting the information requirements of different

355 Chapter 11: Managing the Network 339 users. Table 11-3 adds to the information already provided in Chapter 2, Deploying Core Infrastructure Services with Microsoft Windows Server Table 11-3 View Summary of Operator Console Views Personalize Link to other views Enable/disable Maintenance mode Comments State Y Y Y Aggregates information about alerts and associated entities to display the state (health) of a computer group. See State Icons, State Alert, State Rollup Events Y Y Y See Time Filtering. Performance Y N N See Performance Data View Computers and Y Y Y Groups Diagram N Y - Computer groups N See Diagram View State Icons When an agent heartbeat has a Service Unavailable error for a computer, every state icon for the other roles (for example, Exchange Server and Active Directory) is suspect, and visually depicted as gray line icons that are identical representations of the full color ones. For example, the gray circle-x icon is interpreted as follows: the last known state for this role is critical error, but since the agent is either not heart-beating, or flagged as service unavailable, the data for the other role is suspect. Until the MOM agent is up again and heart-beating normally, the gray versions of the state icons will remain. When the agent is OK again, the icons will return to the colored versions. The logic is that, since the agent performs the communication, if it is down, information that it communicates is also suspect. State Alert MOM 2005 provides the State alert. This alert has two problem state values: Active and Inactive. Each of these states handle rule response processing differently. For example, when the Processor time value crosses a specified threshold, an alert is created with a problem state of Active, and any specified responses are run. If the counter drops below the threshold, another alert with a problem state of Inactive is created; however, none of the responses specified for the rule are run. State Rollup The state of a computer group is based on a roll-up policy, which can be configured by MOM authors by using the State Roll-up Policy tab of the Computer Group property sheet.

356 340 Microsoft Windows Server System Deployment Guide for Midsize Businesses Authors have three possible roll-up polices that they can define for their computer groups. These include: Most Severe of any Server: This policy indicates that the state of the computer group will be equal to the most severe state of any one of the members of the computer group. Most Severe of the Healthiest X % of Servers: This policy indicates that the state of the computer group will be equal to the most severe state of some % of the healthiest servers. For example, suppose that a computer group with 10 members has a policy set to 50%. If five have Warning states, and five have Service Unavailable states, the state of the computer group would be Warning. Least Severe of any Server: This policy indicates that the state of the computer group will be equal to the least severe state of any one of the members of the computer group. Important At times, the State view in the Operator console gets out of synchronization with the database. Some of the reasons for this are: A queue is full because multiple blocks of data were submitted to the server queue at the same time, and are likely be processed at same time. The MOM server has gone down, causing the agents to fail over. One server might have the red alerts for an agent; another might get the green alerts. Because the server was restarted, alerts are inserted out of order. The operational database is unavailable. The best workaround is to resolve the alert. Time Filtering Time filtering is a mechanism for determining how many days worth of information you want to see in the Results pane for the Alerts and Events views. The default setting is seven days, but you might want to consider changing this for the following reasons: In the case of alerts, the number of active alerts might appear to be higher than it actually is. In the case of events, which generate more data than alerts, viewing response time is affected by the number of days of data that has to be retrieved from the database and displayed in the console. To change the time filter 1. On the toolbar, click the Edit view time filter button to open the View Date and Time Filter properties page. 2. By default, Alert and Event data is displayed for the last seven days. You can change the number of days by typing a lower value. You can also use the list box to select hours, minutes or seconds.

357 Chapter 11: Managing the Network 341 Another option is to specify a time range. To do so, click the Within the time range option button, and set the After or Before date and time. 3. When you finish configuring the time filter, click OK. Performance Data View Rather than selecting a computer, clicking counters, and then drawing a graph, you can use the Performance Data view to identify specific counters for a computer. Use the following procedure to create this view. When you are finished, save it in All My Views or Public Views. To create a Performance Data view 1. Click the My Views navigation button. 2. In the Navigation pane, right-click My Views, click New, and then select Performance Data View. 3. In the Create View - Performance Data View dialog box, identify the type of performance data view that you want to create. 4. When you select an item, the corresponding View description area displays the description with hyperlinks that you will use later. Click Next to continue. 5. Click the box beside each type of performance data that you want to include: for example, for specified counter, measured on specified computer. When you select an item, a hyperlink is displayed in the corresponding View description (click the underlined value to edit) input area. 6. Click each hyperlink to open a dialog box, and provide the required information. Click Next to continue. 7. Type a View name and Description for the view, and then click Finish. Tip Expand the Performance Views navigation tree to include Agent Performance. You can use the Performance Data views that are already constructed as a model for creating your own views. Diagram View The Diagram view provides an ideal visual representation, complete with state indicators, of a MOM computer group. You can diagram for specific computer groups provided for the console scope you are using by selecting them from the Group list on the toolbar. If more than one object is shown on the screen, you can arrange the layout by clicking an object and dragging it to a new location. If you want to reset the diagram layout to the default layout, click the Relayout diagram button on the toolbar.

358 342 Microsoft Windows Server System Deployment Guide for Midsize Businesses You can export the Diagram view and save it as a Visio drawing (.vdx) file. To export the current diagram 1. With Diagram as the active view, click the Export to Microsoft Visio button on the toolbar. This opens the Save diagram as a Visio.VDX file properties page. 2. Navigate to the location where you want to save the file, provide a file name, and then click Save. Background images are not provided for the Diagram view. In order to add a background image, you must be a member of MOM Administrators, and must provide the image. The recommended image size is 640 x 480 pixels. Image quality and distortion will vary depending on how much you zoom in or out. Note A management group can have only one image displayed. To add a background image 1. Open the Operator console as a member of the MOM Administrators group. 2. Click the Diagram navigation button. 3. Right-click anywhere on the diagram, and click Diagram View Properties to open the Properties page for the view. 4. In Diagram View Properties, click the Diagram Settings tab. 5. Click the Background Images button to open the Diagram Background Images properties page. 6. Click Add to locate and specify the image that you want to add. 7. After you finish adding images, you can use any of the selected images as a background image for the Diagram view. Additional Resources For the latest information about MOM, see the MOM Web site at go.microsoft.com/fwlink /?linkid=6727. To access the MOM core product documentation on the Web, see the Technical Resources section of the MOM Web site at go.microsoft.com/fwlink/?linkid=8943.

359 Index A access control lists (ACLs), 268, 273 access rules, 119, 298, 307 ACLs. See access control lists (ACLs) Action Account for MOM agents, 207 Active Directory Account Cleanup Wizard, 95 account creation mode, 257 configuring, 40, 207 domain, 231, 237 Group Policy objects (GPOs). See Group Policy objects (GPOs) groups, 226 implementing in workgroups, Windows 2000/NT, 7 in-place upgrades for migration to, 8 installing, 40 Migration Tool, 93 new environments, objects, moving into OUs, 278 organizational units (OUs). See organizational units (OUs) parallel installation for implementing, 8 populating, schema, making Exchange-specific. See ForestPrep testing, 43 user accounts, cloning, 93, 97 user objects, and directory synchronization, 93 users, creating, 226 VPN domain user account, 304 Windows NT/2000 Server, in-place upgrade procedures for, 9 10 Active Directory Connector (ADC), Active Directory Integrated, DNS and, 16 ADC Tools, 96 Administrative Template, 148 administrative virtual servers, 248 Administrator console. See MOM 2005 Workgroup Edition Agent Action Account, 187 agents, configuring, 191 alerting. See monitoring and alerting alerts, 65, 217, All Computers group, 132 antivirus software, 58 application filtering, 46 application pools, 249 application share, 57 approving computers in Pending Action folder, 203 MOM agents, manually installed, 207 updates, automatically for installation, 168 updates, for detection, 164 updates, for removal, 166 WSUS update revisions, automatically, 169 WSUS updates, 164 WSUS updates, automatically, 167, 168 WSUS updates, automatically for detection, 167 WSUS updates, for installation, 165 WSUS updates, superseded, 169, 170 authentication, 246, 307 forms-based. See forms-based authentication Authoring mode (MOM), 329 Automatic Updates, 132, 142, B background images for MOM Diagram view, 342 Background Intelligent Transfer Service (BITS), 138 backing up, 81 IIS configuration, 115 infrastructure servers, 44 ISA Server 2004 configuration, 62 logs, 54 management packs, 213 print server configuration, 239 SharePoint sites, 264 site collections, 263 verifying, 129 Windows SharePoint Services, 263 WSUS, backup and restore service, hosting, 32 bandwidth, managing, with WSUS, bandwidth conservation, 136 BO Desktop OU, 271 branch office, 290, building infrastructure servers, 38 Terminal Server, 311 built-in firewall policy templates, 51 C caching. See Web caching certificates, configuring, 115 Certification Authority (CA), 42 client computers, Client OU, configuring Windows firewall policies on, 281 client-side targeting of computer groups, 150, 159 client-to-site, 293, 303 cloning Active Directory user accounts, 93 CMAK, command-line administration of Windows SharePoint Services, 250 company knowledge base, 210 compliance reports, 182 computer discovery, , 208 Computer Discovery rules, , Computer Group view, 178 computer groups, 132 adding computers to, 158 associating rule groups with, 328 creating, 150, 151 creating, in MOM, 328 default, 132 roll-up policies, 339 server-side targeting vs. client-side targeting, 150 specifying assignment method, 151 Test, manually adding computers to, 151 testing updates with, 132 Computer view, 179 computers removing from WSUS servers, 158 status report, running, 180 Computers OU, configuration connection agreements, 97 configuring Active Directory, 40, 207 administrative virtual servers,

360 344 connection agreements configuring (continued) agents, 191 Alerts, 65 Automatic Updates, 148 Automatic Updates setting, on Domain Controller OU, 281 Branch Office policy settings, 290 broadband firewall, for VPN, 300 cache settings, 66 certificates, 115 Certification Authority (CA), 42 client-to-site VPN, 303 database authentication, 188 database server, 187 DHCP, 41 disk quotas, in Windows Storage Server 2003, 229, 233 Distributed File System (DFS), 224 DNS, 40 DNS records, 116, 118 alert notification, 78 event logs, to overwrite, 193 Exchange Server 2003, 112 file servers, 224 Firewall Client, 58, 72, 75 firewalls, folder redirection, 283 forms-based authentication, 115 FQDNs (fully-qualified domain names), 117 Group Policy objects (GPOs), 279 Group Policy, for printers, 238 hardware, for Windows Storage Server 2003, 230 home clients, for VPN access, 311 IIS 6.0 worker isolation mode, 243 internal network, 61 internal Terminal Server for remote access, 320 Internet Explorer, 73 intrusion detection filters, 64 IP addresses, for VPN clients, 295 ISA Server 2004, 62 64, 299, 306 logging, 53, 76 Management server, 190 MOM 2005 Workgroup Edition, network interface, for Windows Storage Server 2003, 232 network services, 59 network, for Windows Storage Server 2003, 230 operating system, for Windows Storage Server 2003, 230 Operator console, in MOM 2005 Workgroup Edition, 190 OWA (Outlook Web Access), 127 ports, on hardware firewalls, 49 printers and print servers RADIUS server, for VPN clients, 305 remote access, through VPN. See VPN reporting, 79 roaming profiles, 276, 288 RPC over HTTP, 122 RPC virtual directory, 124 Shadow Copies of Shared Folders site-to-site VPN, 296, 299 SMB, for Windows Storage Server 2003, 233 SMTP filtering, 64 software installation, on Group Policy objects (GPOs), 284 SQL Server, for Windows SharePoint Services, 246 SUS (Software Update Services), 288 Terminal Server hardware, 312 Terminal Services, for Web access, 315 URLScan, 117 VPN, , 308 Web caching, 65 Web Enrollment Web site access, 70 Web Listener, Web sites, to redirect requests, 116 Windows SharePoint Services, as Web server, 243 Windows Storage Server 2003, 224, 229 Windows Time Service, 41 WINS, 42 wireless settings, 275, 287 WSUS server, 144 connection agreements, 97 Connection Manager Administration Kit. See CMAK connections, remote. See remote connections Connectivity Verifier, 78 console, WSUS, opening, 144 core network services, 4 7, 24. See also DHCP; WINS; DNS cross-site groups, 259 D data storage, 223 databases, WSUS, 133 declining WSUS updates, 166 decommissioning servers, 22 deferring WSUS updates, 135 defining Terminal Server protocol, 319 deleting cross-site groups, 260 SharePoint subsites, 254 site collections, 253, 254 subsites, 255 top-level SharePoint Web sites, 254 users, 260, 263 delta delivery, 137 delta patching, 171 deploying DNS namespace, public, 35 Exchange Server 2003, firewall servers, 80 MOM 2005 Workgroup Edition, , 214 MSDE, with limited consoles, 191 redundant servers, 30 RPC over HTTP, 123 Terminal Server, 312 Terminal Server client software, 323 WSUS, , Deployment Tools. See Exchange Server Deployment Tools Desktop OU, 271 devices, naming, 33 DFS. See Distributed File System DHCP configuring, 41 DNS servers and, 37 implementing, 4 6 implementing. See also core network services installing, 41 IP addresses to assign with, 36 migrating to new IP addressing scheme, considerations, on infrastructure servers, 31 planning, 35 servers, reserving IP addresses on, 232 testing, 44 Diagram view (MOM), directory synchronization, disabling management packs, 211 NetBIOS over TCP/IP, 61 offline folders, 288 Self-Service Site Creation, 256 slow link detection, in BO Computer GPO, 290 disk quotas, 229 Distributed File System (DFS), 13, 23, , 283, 285

361 Group Policy 345 distribution lists. See distribution lists DNS configuring, 40 configuring with ISP, 118 DHCP and, 37 hosting service, buying, 35 implementing. See also core network services IP configuration, 37 namespaces, designing, 34 on infrastructure servers, 31 public namespace, deploying, 35 records, configuring, 116 removing from server forwarder list, 17 servers, authoritative, 35 switching Active Directory Integrated mode from, testing, 44, 113 domain account mode, 257 Domain Controller OU, 281 domain controllers applying Computer Discovery rules to, 198 installing Exchange Server 2003 on, 88 installing MOM 2005 Workgroup Edition Web console on, 190 on Windows NT, retiring old, 19, 20 organizational units (OUs) for, 278 retiring old, 17 domain modes, 18 domain name system. See DNS DomainPrep, domains, 19 20, 226 DoS attacks, preventing. See intrusion detection Dynamic Host Configuration Protocol. See DHCP dynamic updates, enabling, 41 E Edge template, 62 editing Group Policy objects (GPOs), 282 Urlscan.ini file, 140 alert notification, configuring, 78 distribution lists, 260 servers, publishing, 33 entities, 294 error reporting, enabling, on MOM 2005 Workgroup Edition, 190 event logs, , 217 Exchange 2000 Server, integration procedure, 12 Exchange 2003 Setup, 103 Exchange Server decommissioning procedure, 23 hosting, 32 Exchange Server See also messaging services Active Directory Account Cleanup Wizard, 95 certificates. See certificates coexisting with Exchange Server 5.5. See mixed mode components and services required for, 101 configuring, 112 decommissioning, 22 deploying, deployment considerations, Deployment Tools. See Exchange Server Deployment Tools DomainPrep. See DomainPrep ForestPrep. See ForestPrep hardware recommendations, 90 installing, 88, 112, 114 mode, determining, 107 Native mode, 22 roles, delegating to security group, 99 RPC over HTTP. See RPC over HTTP securing. See security system-wide requirements, 98 Task Wizard, 105 upgrading Exchange Server 5.5 to, 89 Exchange Server 5.5 coexisting with Exchange Server See mixed mode connecting directory to Active Directory. See Active Directory Connector (ADC) integration procedure, 12 mailboxes, migrating, 105 synchronizing with Active Directory. See Active Directory Connector (ADC) upgrading, 89 Exchange Server Deployment Tools, 91 Exchange System Management Tools, 114 Exchange System Objects container, 100 excluding computers with Computer Discovery rules, 196 exporting Diagram view, in MOM, 342 express installation files, External OU, 269 extranet sites, publishing, 72 F FAT volumes, 243 file servers, configuring, 224 file services, 14, 32 implementing, 24. See also DFS; Shadow Copy Services file shares, filtering, 136, 163, 340 firewall traffic. See application filtering Firewall Client, application, 57 58, firewall clients, 55 firewall policies, firewall servers, as default gateway, 55 disk configuration, 61 ISA Server, rollout options for, 2 4 operating system, installing, 60 placement of, Web caching, configuring, 52 firewalls. See also hardware firewalls; software firewalls client configuration, client software, adding to Distributed File System (DFS), 227 configuring, defining rules for 2004, 321 filtering traffic. See application filtering general rules for, 50 hardware vs. software, 30 logging, policies. See firewall policies positioning ISA Server behind existing, 21 replacing exisiting with ISA Server, 22 rules, defining, 62 VPN, configuring, 301 Web proxies. See Web proxies folder redirection, 275, ForestPrep, forms-based authentication, 115, 127 FQDNs (fully-qualified domain names), 117 full computer discovery, 198 fully-qualified domain names. See FQDNs (fully-qualified domain names) G Group Policy applying, to WSUS servers, 149 designing, domain-level settings, 269

362 346 Group Policy Loopback Processing Group Policy (continued) folder redirection. See folder redirection implementing, basic rules for, 273 implementing, for printers, 238 installing Firewall Client application with, 57 installing software with, 275 slow link detection feature, 273 Group Policy Loopback Processing, Group Policy Management Console, 279 Group Policy objects (GPOs) ACLs and, 273 administrators, exempting from user settings, 280 applying at the ACL level, 268 applying at the OU level, 268 associated with OUs, 274 BO Computer, disabling slow link detection for, 290 configuring, 279 domain-level, 269 editing, 282 for BO Desktop OU, 271 for Windows firewall, configuring on Client OU, 281 importing, 279 linking to OUs, 280 modifying to include software installation, 286 on Desktop OU, 271 on Mobile OU, 271 on Restricted OU, 272 redirected folders, adding path to, 284 software installation, configuring, 284 wireless configuration, automating with, 275 wireless settings, configuring, 287 groups creating in Active Directory domains, 226 creating, in Active Directory domain, 237 MOM Users, adding users to, 326 H hardware, 20, 39 hardware firewalls 30, See also firewalls home clients, configuring for VPN access, 311 hosting, 32 HTML Administration pages, 250, 252, 258 HTTP, 46, 72, 120, 318 HTTPS, 121, 319 I IIS backing up configuration, 115 configuring to use IIS 6.0 worker process isolation mode, 243 enabling, 243 installing, 140 installing, on Terminal Server, 316 resetting, 248 restarting, 248 security, ensuring, 141 IIS 6.0 worker process isolation mode, 243 IIS Lockdown Tool, implementing Group Policy, 273 infrastructure servers backing up, 44 building, 38 deploying redundant, 30 hardware for, 39 hosting Exchange Server on, 32 RAID configuration, 39 RAM, selecting amount, 39 server-side conflict detection, enabling, 41 services hosted on, 30 storage configuration, 39 validating security configuration, 43 infrastructure services, assigning IP addresses, 36 in-place upgrade procedures, 8 9 Install/Uninstall Agents Wizard, installing Active Directory, 40 Active Directory Connector (ADC), 95 Administrator console, for MOM 2005 Workgroup Edition, 191 Certification Authority (CA), 42 client access license, in Terminal Server, 314 CMAK, 308 DHCP, 41 Exchange Server 2003, 114 Exchange Server 2003, 88, 112 Exchange System Management Tools, 114 Firewall Client application, 57 58, 74 firewall server operating system, 60 IIS, 140, 316 ISA Server 2004, 61 Microsoft Office, 171 MOM 2005 Workgroup Edition, 188, , 200, MOM 2005 Workgroup Edition components, 189 Operator console, for MOM 2005 Workgroup Edition, 191 Remote Desktop Web Connection software, on Terminal Server, 316 software, 275, 285 superseded WSUS updates, 170 Terminal Server applications, 322 Terminal Server Licensing Server, 313 Terminal Services, 313 VPN, 295, 311 wildcard certificates, 70 Windows 2000 services, 102 Windows Server 2003 services, 102 Windows SharePoint Services, WINS, 42 WMSDE, 242 WSUS, 142 internal network, configuring, 61 Internal OU, 269 internal resources, publishing to Internet, 67 internal services, publishing to Internet, 33 internal SMTP server, publishing to Internet, 119 internal Web sites, publishing to Internet, 67 Internet and Security Acceleration Server. See ISA Server Internet Explorer, intrusion detection, 45, 64 IP addresses, 36 37, 232, 295, 306 IP addressing scheme, ISA Server, 2 4, ISA Server 2004 automatic detection, enabling, 58 backing up configuration, 62 benefits of, 45 cache settings, configuring, 66 clients supported by, 55 configuring, configuring site-to-site VPN on, 296 configuring, for VPN, 299 configuring, for VPN client access, 306 Firewall Client application. See Firewall Client application firewall rules, defining, 321

363 monitoring and alerting 347 firewall servers. See firewall servers gateway configuration, 36 Help file, 84 inbound traffic, configuring, 50 installing, 61 intrusion detection. See intrusion detection logging. See logging newsgroups, 84 outbound traffic, configuring, 49 publishing on, 33 Remote Access, enabling, 321 reporting. See reporting restarting, checking necessity of, 307 services recommended for, 32 standard edition vs. enterprise edition, 45 Web site, 84 wildcard certificates, installing, 70 K knowledge base, 210 L linking Group Policy objects (GPOs) to organizational units (OUs), 280 to Distributed File System (DFS) root, 227 log files, increasing size of, 192 logging, backing up, 54 compressing files, why not to, 54 configuring, 53, 76 end-user information, 53 removing old log files, 54 size limits, 53 storage location for, 54 to databases, 53 to files, 53 viewing history of, 53 M mailboxes, 10 12, 105 Maintenance mode, 337 managed paths, Self-Service Site Creation and, 255 management packs, Management Server, 190, 206 Management Server Action Account, 186 messaging services, 10 13, 87, 90, 129. See also Exchange Server 2003 metadata, in WSUS updates, 160 Microsoft Challenge Handshake Authentication Protocol, 2. See MS- CHAP v2 Microsoft Exchange Information Store service, 112 Microsoft Exchange Server See Exchange Server 2003 Microsoft Exchange Server Public Folder Migration Tool. See PFMigrate Microsoft Internet Security Acceleration (ISA) Server See ISA Server 2004 Microsoft Internet Security and Acceleration (ISA) Server See ISA Server 2004 Microsoft management packs, 210 Microsoft Office, 171 Microsoft Operations Manager 2005 Workgroup Edition. See MOM 2005 Workgroup Edition Microsoft Operations Manager. See MOM Microsoft SQL Server 2000 Desktop Engine (Windows). See WMSDE Microsoft SQL Server 2000 Desktop Engine. See MSDE Microsoft SQL Server See SQL Server Microsoft Windows SharePoint Services. See Windows SharePoint Services Microsoft Windows SQL Server 2000 Desktop Engine. See WMSDE migrating Migration Tool, Active Directory, 93 mixed mode, 107, 111 Mobile OU, 271 MOM alert processing cycle, 331 alerts, Alerts view, 333 Authoring mode, 329 computer groups, 328 configuration changes, committing, 327 Diagram view, local groups, adding users to, 326 Maintenance mode, 337 notification groups, creating, 327 operational data processing cycle, 331 Operator console, views in, 338 operators, creating, 326 Performance Data view, 341 rule groups, 329 rules, creating, service-level exceptions, 332 State alert, 339 state icons, 339 tasks, 329, 328 time filtering, 340 Web console, MOM 2005 Workgroup Edition Active Directory configuration for, 207 Administrator console, 191, 208, 212 agent deployment process, 192 Agent Action Account, 187 Agent Setup Wizard, 206 agents, , , 216 alerts, 217 Computer Discovery rules. See Computer Discovery rules computer discovery. See computer discovery configuring, configuring Management Server, 190 consoles, granting access to, 187 Data Access Server (DAS), 216 database, 215 database authentication, configuring, 188 database server, configuring, 187 deployment checklist, 214 discovery data, 218 error reporting, enabling, 190 event logs, 217 full computer discovery, 198 hardware requirements, 186 implementation checklist, 214 Install Agent Wizard, using with alternative accounts, 204 installing, 188 installing components, 189 log files, increasing size for, 192 Management Group, 215 management packs. See management packs Management Server, 216 Management Server Action Account, 186 mutual authentication, enabling, 194 operational data, 217 Operator console, , 208 Pending Actions folder, 203 performance data, 217 processing flow, 216 Reporting Database, 216 server, 216 service accounts, verifying, 186 software requirements, 185 user interfaces, 216 monitoring, 78, 234 monitoring and alerting, 54

364 348 MSDE MSDE as WSUS database software, 134 consoles, limiting number of, 191 deploying, with limited consoles, 191 downloading, 187 Workload Governor, 191 mutual authentication, 194 N namespaces, DNS, 35 naming, 33 native mode, 107 8, 111 NetBIOS over TCP/IP, 61 network configuration, 43, 239 network connectivity, 113 network printers, 234, 239 network rules, 297 network services, 14, 24, 59 network share URL, 222 Network Time Protocol (NTP), firewall policy synchronization, 52 network topologies, 30 with ISA Server. See ISA Server notification for Automatic Updates, 149 notification groups, creating, in MOM, 327 NTFS, converting FAT volumes to, 243 O objects, moving into organizational units (OUs), 278 Office. See Microsoft Office offline folders, disabling, 288 on-demand computer discovery, 199 operating systems, installing on firewall servers, 60 Operator console. See MOM 2005 Workgroup Edition operators, creating, in MOM, 326 Organizational Unit field, 34 organizational units (OUs), 267 applying Group Policy objects at level of, 268 BO Desktop, 271 Client, configuring Windows firewall policies on, 281 Computers, 270 Computers, divisions of, 271 Computers, Group Policy settings, 270 creating, 277 designing, Desktop, 271 Domain Controller, configuring Automatic Updates setting on, 281 External, 269 for domain controllers, 278 GPOs associated with, 274 Internal, 269 linking Group Policy objects (GPOs) to, 280 Mobile, 271 moving objects into, 278 Restricted, 272 Servers, 269 Servers, Group Policy settings for, 270 Users, 272 outbound SMTP traffic, 119 Outlook 2003, RPC over HTTP, 122, 126 Outlook Web Access (OWA). See OWA (Outlook Web Access) overwriting event logs, 193 OWA (Outlook Web Access), 33, OWA site, 69, 72, P parallel installation for implementing Active Directory, 8 partitioning, 39 password, changing, 231 Pending Actions folder, 203 Performance Data view (MOM), 341 permissions, 226, 252 PFMigrate, 106 ping of death, protecting against. See intrusion detection policies, firewall. See firewall policies populating Active Directory, port scanning, preventing. See intrusion detection ports, configuring, on hardware firewalls, 49 primary infrastructure server, configuring disk quotas on, 229 print servers, 235, 239 print services, validating, 239 printers connected to client computers, adding, 236 directly attached, 236 Group Policy, implementing, 238 network, configuring, 234 publishing, 238 restricting access to, 236, 237 sharing, 238 printing reports, 179, 182 product families, 161 product knowledge base, 210 products, 155, 161 proxy servers, 144, See also Web proxies public DNS namespace, deploying, 35 public folder connection agreements, 97 public folders, migrating, 106 publishing DFS root, 225 servers, 33 extranet sites, 72 file shares, 225 internal resources, to Internet, 67 internal services, to Internet, 33 internal SMTP server, to Internet, 119 internal Web sites, to the Internet, 67 on ISA Server, 33 OWA, 33 OWA sites, 69, 72, printers, 238 SMTP service, 119 Terminal Server, 318, 320 terminal servers, 33 TSWeb Web sites, 72, Web sites, multiple, 69 R RADIUS server, configuring, for VPN clients, 305 RAID, configuring, on infrastructure servers, 39 RAM, 39, 90 RDC, allowing from Terminal Server, 321 recipient connection agreements, 97 redirected files shared folder, 283 redirecting folders. See folder redirection Terminal Server resources, 323 Web sites, 317 Web site requests, 116 redundancy testing, 44 registry, adding entries for branch office clients, 290 remote access, 320 remote connections See also Terminal Server; VPN Remote Desktop Web Connections software, 316 remote installation of MOM 2005 Workgroup Edition agents, 199 remote management of firewall servers, 82 remote management cards, 321

365 Terminal Server 349 remote storage of WSUS updates, 135 replacing management packs, 213 replication, verifying, 114 reporting, 54, 79, 81 reports, , 179 reserving IP addresses, on DCHP servers, 232 Resource Mailbox Wizard, 97 restarting IIS, 248 ISA Server 2004, 307 Windows Storage Server 2003, 232 restoring, Restricted OU, 272 restricting printer access, retiring old servers, 22 revising WSUS updates, 169 roaming profiles, 276 configuring, 276, 288 creating, 289 folders to exclude from, 276 shared folder for, creating, 288 synchronization problems, preventing, 276 rollbacks, Windows NT/2000 Server, 25 roll-up policies for computer groups, 339 router, VPN, configuring, 300, 302 RPC over HTTP, RPC virtual directory, 124 rule groups, rules, 62, running, ADC Tools, 96 DomainPrep, 101 Exchange 2003 Setup, 103 Exchange 2003 Task Wizard, 105 ForestPrep, 99 PFMigrate, 106 S scheduling Automatic Updates installation, 149 mailbox moves, 105 WSUS synchronization, 156 secondary infrastructure server, deploying Exchange Server 2003 on, 87 SecureNAT clients, security, 43, 117, 129 security groups, delegating Exchange roles to, 99 Self-Service Site Creation, Server Message Block. See SMB server publishing, 67 servers deploying redundant, 30 firewall. See firewall servers naming, 33 retiring old, consolidating, 22 Servers OU, server-side conflict detection, 41 server-side targeting of computer groups, 150, 159 service accounts (MOM 2005 Workgroup Edition), 186 service-level exceptions, 332 services, 30 internal. See internal services Settings Summary report, Shadow Copies of Shared Folders, Shadow Copy Services, 13 shared folders for redirected files, creating, 283 for roaming profiles, creating, 288 for software installation files, creating, 285 SharePoint Migration Tool, 264 SharePoint Services. See Windows SharePoint Services sharing printers, 236, 238 site collections backing up, 263 changing owner of, 261 deleting, 253, 254 managing, 250 managing users in, 261 site groups, 258, 263 Site Replication Service (SRS), site-to-site VPN, 296, 299 SMB protocol, 233 SMTP, 46, 64, 119 software, installing, 275, 285 software firewalls, 30. See also firewalls; ISA Server Software Update Services (SUS), 288 SQL Server as WSUS database software, 134 backing up Windows SharePoint Services with, 263 configuring, for Windows SharePoint Services, 246 connecting to, 249 database creation rights, granting, 248 installing Windows SharePoint Services for, 246 Windows authentication, enabling, 246 SSL certificates, configuring, 115 configuring Terminal Server certificates for, 316 deploying WSUS with, 153 SSL certificates, 68 State alert (MOM), 339 state icons (MOM), 339 Status of Computers report, 180 Status of Updates report, 177, 179 storage services, 32 storing WSUS updates, Stsadm.exe command-line tool, 263 subsites, deleting, 254 superseded WSUS updates, SUS (Software Update Services), 288 Synchronization Results report, 180 synchronizing Active Directory with Exchange Server 5.5. See Active Directory Connector (ADC) stopping, for specific products, 155 WSUS, 131, 145, 147, WSUS updates, by product/ classification, 154 system folders, migrating, 106 T tasks, 329, 338 templates for firewall policies, 51 Terminal Server applications, installing, 322 building, 311 certificates, configuring for SSL, 316 client access license, installing, 314 client software, deploying, 323 deploying, 312 hardware considerations, 312 hardware, configuring, 312 IIS, installing, 316 internal, configuring for remote access, 320 Licensing Server, installing, 313 licensing, activating, 314 managing, 323 protocol, defining, 319 publishing internally, 320 publishing, for TSWeb access, 318 RDC, allowing from, 321 remote access, with remote management card, 321 Remote Desktop Web Connection software, installing, 316 resources, redirecting, 323 user group, creating, 314

366 350 terminal servers, publishing Terminal Server (continued) users group, adding to Remote Desktop Users group, 315 terminal servers, publishing, 33 Terminal Services, 313, 315 Test group, 151 testing Active Directory, 43 DHCP, 44 DNS, 44, 113 firewall servers, 81 messaging services, 129 network configuration, 43, 239 network connectivity, 113 network printer configuration, 239 redundancy, 44 reporting, 81 updates, 132, 172 time filtering (MOM), 340 topologies. See network topologies TSWeb access, 318 TSWeb Web sites, 72, U Unassigned Computers group, 132 Unique Identifier field, 34 update compliance reports, 183 update management, 82 Update Summary view (WSUS), 178 updating management packs, 212 Microsoft Office, 171 testing, 172 upgrading Exchange Server 5.5, 89 URLScan, 117 Urlscan.ini file, 140 user objects, Active Directory. See Active Directory, user objects user profiles, roaming. See roaming profiles users creating, in Active Directory domain, 237 profiles, roaming. See roaming profiles SharePoint Services Web sites, creating for, 251 site group membership, changing, 258 viewing site groups member of, 258 Users OU, 272 V validating print services, 239 security configuration, 129 server security configuration, 43 Windows Storage Server 2003 security configuration, 234 verifying backup, 129 computer discovery, 208 connectivity, 78 MOM 2005 Workgroup Edition service accounts, 186 MOM agent installation, 208 replication, 114 virtual servers 246, VPN access rule, creating, 307 access rules, creating, 298 Active Directory domain user account, creating, 304 authentication method, selecting, 307 branch office network object definition, creating, 297 branch office traffic, allowing, 298 broadband firewall, configuring, 300 client computer, configuring, 308 client-to-site, configuring, 303 CMAK service profile, creating, 308 deployment design, 294 domain user account, creating, 304 firewall, configuring, 301 home clients, configuring, 311 installing, 295 IP address allotment, 295 IP address range, defining, 306 ISA Server 2004, configuring, 306 ISA Server, configuring, 299 RADIUS server, configuring, 305 router, configuring, 300, 302 service profile files, installing, 311 service profiles, creating with CMAK, 309 site-to-site, configuring, 296 site-to-site, configuring on ISA Server 2004, 296 site-to-site, configuring on remote gateway at branch office, 299 static address pool vs. dynamic address pool, 295 W Web access rules, 76 Web caching, 47, 52, Web console (MOM), Web Enrollment Web site, 70 Web Listener, Web proxies, 46 Web Proxy Auto-Detection (WPAD) DHCP option, 58 Web proxy clients, Web publishing, 33, 67, 68 Web sites internal. See internal Web sites managing users, 257 publishing multiple, 69 redirect requests, 116 redirecting, 317 top-level, 251, 255, 261 wildcard certificates, Windows 2000, 7, 102 Windows 2000 Server, 9, 20, 25, 141 Windows 2003, 142 Windows authentication for SQL Server, 246 Windows firewall policies, 281 Windows Internet name service. See WINS Windows NT, 7, 9, 19 20, 25 Windows NT 4.0 user accounts, 93, 97 Windows Server 2003, 7, 18, 102, 141 Windows Server Update Services. See WSUS Windows SharePoint Services, , Windows Storage Server 2003, Windows Time Service, 41 Windows Update, 77 WinNuke. See intrusion detection WINS, 16, 31, 37, 42. See also core network services wireless settings, 275, 287 WMSDE, 133, workgroups and Active Directory, 7 WSUS, Administrative Template, 148 Automatic Updates. See Automatic Updates Background Intelligent Transfer Service (BITS), 138 backing up, 173 client self-update, 141 communication with client computers, 157 compliance reports, running, 182 Computer Group view, 178 computer groups. See computer groups Computer view, 179 Computers page, 157 configuring server, 144 console, opening, 144 database components, 173 database, deploying, with SSL, 153 detection, manually initiating, 150

367 disk requirements, 141 Group Policy, applying, 149 hardware recommendations, 138 IIS Lockdown Tool and, 141 installing, 142 managing client computers with, pointing client computer to, 149 proxy servers, 144, 156 removing computers from, 158 reports, security, Settings Summary report, 181 Status of Computers report, 180 Status of Updates report, 177, 179 superseded updates, 170 synchronization classifications, 145 Synchronization Results report, 180 synchronizing, 131, troubleshooting, 183 update classifications, 162 update compliance reports, 183 update file storage folder, restoring, 174 update files, backing up, 173 update products, specifying, 145 update status terminology, 175 Update Summary view, 178 Updates page, opening, 163 updates, , 141,

368