Windows Server : Branch Office Deployment - Branch Office Services (part 1)

7/21/2011 11:34:21 AM

Branch Office Services

Designing the Active Directory Structure for Branch Office Administration

The first issue to consider in the branch office is the establishment of the proper level of access and authority for the branch office administrator. The branch office administrator is generally less skilled and less trusted than the administrators in the corporate HQ. Branch office administrators are responsible for lower-level administrative functions related to application installation, performing operating system and application updates, and restarting servers and domain controllers (DCs). However, the branch office administrator is generally not authorized to perform Active Directory–related administrative functions. Because branch office administrators are not as skilled or as trusted as the HQ administrators and because they typically are responsible only for their local branch office systems, it is generally not desirable to add the branch office administrators to the Domain Admins group or to other domain-related built-in groups. This is usually too much privilege.

As in Windows Server 2003, you can use the Delegation of Control Wizard in Windows Server 2008 to delegate preconfigured levels of privilege at the Active Directory site, the domain, and the organizational unit (OU). Several additional preconfigured levels of privilege have been added at the domain level to the wizard in Windows Server 2008.

Because the branch office almost always represents an Active Directory site, it might seem that the Delegation of Control Wizard should be used at the site level to delegate privilege to the branch office administrator. However, the preconfigured privileges available at the site level number exactly one—Manage Group Policy Links, just as it was in Windows Server 2003. The Delegation of Control Wizard enables you to create custom tasks to delegate, but when privilege is delegated at the site level, the branch office administrator’s level of authority would approximate that of an Enterprise Admin. Enterprise Admin is far too much authority for the branch office administrator and is usually not a good choice for delegation in this case.

If the branch office is configured in Active Directory as its own domain, the branch office administrator can be granted Domain Admin status in his or her home domain. This might or might not be too much authority because members of the Domain Admins group can write GPOs, delegate authority, and define a great deal of policy and control over the domain. Delegation at the domain level would require a skilled and trusted branch office administrator. If the branch office administrator is up to this level of challenge, responsibility, and authority in the enterprise, in which the branch office is its own domain, making the branch office administrator a domain administrator in his or her home domain could be a viable option.

It is generally better to delegate administrative authority at the lowest possible container within the Active Directory structure—the OU. For more granular administrative control, create an OU for each branch office and delegate authority to the branch office administrator at the OU level. Then place all local branch office users and computers into the proper branch office OU. At the OU level, the Delegation of Control Wizard has about a dozen preconfigured levels of privilege. Members of the Enterprise Admins group can still create and link GPOs at the Site level, with the optional “Enforced” setting enabled, for high-level, enterprise administrative control. Members of the Domain Admins group can also create and link GPOs at the domain level, again with the optional “Enforced” setting enabled, for high-level administrative control.

Note: Domain restructuring

Windows Server 2008 provides for domain restructuring in an entirely new way. Branch offices are often isolated from the main office not just geographically but financially (like a different cost center) or administratively (politically), with different network administration, and they might even have different requirements regarding security and compliance concerns.

No matter how the branch office is configured within Active Directory, the branch office might be restructured to better fit the business needs of the enterprise with the control and administration models supported by the different Active Directory containers.

Although you can use delegation of authority at the site, domain, or OU to provide administrative control over member computers and users, what about the domain controller that is physically located in the branch office? Domain controllers should never be moved from the Domain Controllers OU. How can the local branch office administrator manage that operating system and applications? You don’t want the local administrator working with Active Directory, but you need his or her help in maintaining the server operating system underlying Active Directory. Windows Server 2008 introduces Administrator Role Separation specifically to address this issue.

Administrator Role Separation

A new feature of Windows Server 2008 is the ability to delegate local administrative privilege on a domain controller (DC). This grants the delegated user or group local administrator privilege on the server, with the ability to log on to the server, update drivers, and restart the server, but disallows them from being able to manage Active Directory or the Directory Services. This is called Administrator Role Separation.

You must perform Administrator Role Separation delegation on a server-by-server basis. The delegated user or group will not have any administrative privileges on other DCs in the domain. To implement Administrator Role Separation on a single DC, at a command prompt, type:


and press Enter. At the DSMGMT prompt, type:

local roles

and press Enter. You can type a question mark (?) to get help at any level in the DSMGMT application. Next, type:

list roles

to view the possible delegations on the server. Now, for the delegation, type:

add <domain>\<username or group name> administrators

You should receive the following response:

Successfully Updated Local Role

Next, to confirm the delegation, type:

show role administrators

You should see the user or group that has been delegated the Administrator Role Separation role. Keep in mind that this grants the delegated user or group administrative privilege only on this one DC. To grant administrative privilege to the branch office administrator over users and computers in the branch office, you will also need to delegate privilege at the site, domain, or OU level for the branch office, as appropriate.

Components and Services in the Branch Office

The branch office typically has relatively few users, relatively few computers, a smaller budget for information services, reduced network infrastructure devices (like servers and firewalls), and, most unfortunately, lesser security and less-skilled administration. The users in the branch office will still need access to enterprise resources, along with a reasonable level of performance, coupled with an appropriate level of security for the information systems. Furthermore, there might be the need to provide additional infrastructure in the branch office to remain in compliance with industry regulations and laws. There needs to be a balance between the needs of the users in the branch office and the cost of providing infrastructure, support, performance, and reliability for the network. It is not prudent business practice to “just throw money” at the issue, hoping that the complaints and other problems go away.

Consequently, a branch office will need an infrastructure to provide information services. This section will explore some of the options and discuss the benefits, along with the price you’ll pay to implement the service in the remote and potentially unsupported and nonsecure branch office. As a branch office grows, the need for local services and support also grows. Following is a list of information system components and services that might be desirable in the branch office:

  • Client computers

  • Servers

    • Member or standalone, to support services like File Services, Print Services, and other infrastructure services

    • Full server or Server Core installation

  • Domain controller (DC)

    • Full server: DC or Read-Only DC (RODC)

    • Server Core: DC or RODC

  • Global catalog (GC)

  • Operations master roles

  • Domain Name System (DNS)

  • DHCP

  • Multisite cluster nodes

  • Distributed File System (DFS) or Distributed File System with Replication

  • Routing and Remote Access Services

    • For dial-in and VPN, DHCP relay agent, and Network Address Translation (NAT) support

  • Windows Server Update Services, to provide Microsoft operating system (OS) and application updates

  • Windows Server Virtualization (WSv) services

In addition, the branch office will typically need at least one firewall/router and a wide area network (WAN) link to provide connectivity to the HQ networks, as well as to the Internet. A more detailed discussion of the elements on this list follows.

The branch office network typically connects to the HQ over dedicated WAN links, like a T1 or a T3, or they connect through VPNs over the Internet’s public network. In either case, for performance and reliability reasons, it is often desired to place network infrastructure systems in the branch office.

Windows Deployment Services

What is the value of a branch office without computers? How do you get those standardized operating system and application installations to the branch office? Microsoft has redesigned the earlier Remote Installation Services (RIS) in Windows Server 2008 to enhance the remote deployment and reimaging of computers using preconfigured images complete with applications and settings. Windows Deployment Services (WDS) is a server role that can be added to any Windows Server 2008 server.

WDS is optimized to deploy Windows Vista and Server 2008, but it can deploy earlier versions of Windows operating systems. It relies on preboot execution environment (PXE) technology and requires Transmission Control Protocol/Internet Protocol (TCP/IP) connectivity between the WDS server and the target client. WDS can deploy remote clients using multicast transmission to deploy an image to a large number of client computers simultaneously.

Windows Server 2008 Server—Member or Standalone

In the enterprise, the most common deployment of client and server class computers is to make them members of the domain by joining them to the domain. This must be done on the local computer, by script, or by answer file during an unattended installation. Joining these systems to the domain implements the administrative control desired (required) by the administration and by the enterprise security policy. The majority of administrative control is accomplished through the GPO within Active Directory. The benefit to the user of the system is single sign-on to access resources enterprise-wide. The impact of joining the domain for a computer is giving up administrative control of the computer. The administrators in the enterprise now own the control of the system.

For the administrator in the enterprise, almost the only circumstances in which it might be desirable to have a company computer remain a standalone system and not join the domain is when there is little or no need to access enterprise resources and when there is significant risk of the computer being compromised. The compromise could be physical theft or access, or it could be an attack through the network.

Windows Server 2008 Server Core

Server Core is the securest installation of Windows Server 2008. Server Core installs a minimal operating system, providing minimal services and applications, with no Windows shell and a limited graphical user interface (GUI). This reduces the maintenance, the management, and the hardware requirements of the server. (Server Core requires only about 1 GB of hard disk drive space for installation and about 2 GB for ongoing server operations.)

Perhaps more significant, Server Core reduces the attack surface of the server, making it the securest installation of Windows Server 2008. It is designed as a bastion host or hardened server, already minimizing the attack vectors of the operating system. Almost always, the way that a hacker is able to compromise a computer is through vulnerabilities in services and applications (program code) running (in memory) on the computer. These vulnerabilities are inherent in all program code. By reducing the number of services and applications that run on a computer, you are reducing the number of attack vectors available to the hacker. This is exactly what Server Core does. It operates with a bare minimum of services and programs running in memory.

Furthermore, if the hacker can break into a running process, the hacker’s level of privilege is that of the user account that initially launched the compromised process. After a hacker accesses a computer through one of the vulnerabilities in running program code, the hacker’s next objective is to elevate his or her level of privilege in order to acquire greater control over the computer. This is commonly accomplished by triggering the execution of a service (or other process) that runs at a higher level of privilege. Because vulnerabilities are inherent in all program code, the hacker now breaks into the process that runs at the higher level of privilege, acquiring a higher level of privilege on the computer. Again, because Server Core has a reduced set of services and applications installed and available on the computer, the hacker has fewer targets with elevated privilege to execute and exploit. This reduces the likelihood that a hacker can elevate his or her level of privilege on the Server Core server, keeping the hacker at a lower level of privilege. These are the principal mechanisms that make Server Core the securest implementation of Windows Server 2008.

Note: The many facets of security

The reduction of programs in memory and on the hard disk drive does not alone ensure security of the computer. These features, combined with a comprehensive, multilayered, and monitored security structure, are the best defense against hacker compromise of the computer system.

It only takes one vulnerability in a system to enable the hacker to exploit the system. You must attempt to secure them all.

Because Server Core has no Explorer shell and a limited GUI, local administration and administration through a Remote Desktop (Terminal Services) connection must be performed using commands at a command prompt. Figure 1 shows the Server Core console.

Figure 1. The Server 2008 Server Core console

Many Control Panel items are available in Server Core. Type the name of the .cpl item at the command prompt, like intl.cpl and timedate.cpl. These Control Panel items provide about the only limited GUI for local server administration. Other useful administrative tools are RegEdit.exe, RegEdt32.exe, and bcdedit.exe. You can also use scripts, based on Extensible Markup Language (XML), to configure the Server Core server.

You can also manage the Server Core server remotely, using the Microsoft Management Console (MMC) or through remote command-line tools. The MMC used through a remote connection to the Server Core server is the only way to administer the Server Core server through a GUI interface.

Server Core supports the following server roles:

  • Active Directory Domain Services (AD DS)

  • Active Directory Lightweight Directory Services (AD LDS)

  • DHCP Server

  • DNS Server

  • File Server

  • Print Server

  • Streaming Media Services

  • Web Server (IIS)

You must select Server Core during the installation of the operating system. Figure 2 shows the selection menu from which you need to select the Server Core installation during the installation of Windows Server 2008.

Windows Server 2008 Server Core in the branch office, whether configured as a standalone, member, domain controller, or read-only domain controller server, provides the securest Windows Server 2008 operating system platform because of its server hardening by design. You should use this implementation when the server has a significant risk of being either physically or electronically exposed to compromise or when the server will be supporting the most sensitive data or processes, even in a well-protected LAN or branch office environment. The potential minor cost savings in hardware should typically not be a consideration in making this decision.

Figure 2. Selecting Windows Server 2008 Full Installation or Server Core Installation

  •  Windows Server : Planning Application Virtualization
  •  Windows 7 : Understanding TCP/IP (part 2)
  •  Windows 7 : Understanding TCP/IP (part 1) - Basics of IP Addressing and Configuration
  •  Windows Server 2008 : Planning Operating System Virtualization (part 2) - Planning for Server Consolidation
  •  Windows Server 2008 : Planning Operating System Virtualization (part 1)
  •  Windows Server 2003 : Troubleshooting Group Policy
  •  Windows Server 2003 : Working with Resultant Set of Policy (part 2)
  •  Windows Server 2003 : Working with Resultant Set of Policy (part 1) - Generating RSoP Queries with the Resultant Set Of Policy Wizard
  •  Configuring Windows 7 NIC Devices (part 2) - Configuring Wireless NIC Devices
  •  Configuring Windows 7 NIC Devices (part 1) - Configuring a Network Adapter & Troubleshooting a Network Adapter
  •  Windows 7 : Configuring Network Connectivity - Understanding Networking
  •  Preparing to Install Windows 7 (part 2) - New Install or Upgrade
  •  Preparing to Install Windows 7 (part 1) - Different Versions of Windows 7 & Hardware Requirements
  •  Maintaining Windows 7 with Backup and Restore (part 2) - Using Advanced Backup Options & Using System Protection
  •  Maintaining Windows 7 with Backup and Restore (part 1) - Creating a Backup & Restoring Files from a Backup
  •  Windows 7 : Configuring Backups and Recovery - Using Advanced Boot Options
  •  Windows Server 2003 : Implementing a GPO (part 2) - Modifying a GPO
  •  Windows Server 2003 : Implementing a GPO (part 1)
  •  Windows 7 : Using Windows Live Calendar (part 3) - Scheduling Appointments and Meetings & Viewing Agendas and Creating To-Do Lists
  •  Windows 7 : Using Windows Live Calendar (part 2) - Sharing Your Calendars with Others & Synchronizing Google Calendar with Windows Live Calendar
    Top 10
    Maintaining Windows 7 with Backup and Restore (part 2) - Using Advanced Backup Options & Using System Protection
    Exchange Server 2007 : Configure the Client Access Server - Manage Exchange ActiveSync
    Expert computing advice (Part 1)
    Windows 7 : Configuring Disks and Drives (part 2) - Converting a Basic Disk to a Dynamic Disk
    SQL Server 2008 : Advanced Stored Procedure Programming and Optimization - Using Cursors in Stored Procedures
    Leveraging and Optimizing Search in SharePoint 2010 : Federating Search
    iPhone 3D Programming : Blending and Augmented Reality - Blending Caveats
    Understanding and Using Windows Server 2008 R2 UNIX Integration Components (part 1)
    Building Out Of Browser Silverlight Applications - Using COM Interoperability and File System Access
    Microsoft XNA Game Studio 3.0 : Working with Colors
    Most View
    Creating Windows with Mixed Content
    Exchange Server 2010 server roles (part 1) - Mailbox Server role
    Send an Email via SMTP
    iPad SDK : Popovers - The Font Size Popover
    Building a WPF Application without XAML (part 2)
    Windows Phone 7 Development : WebBrowser Control - Saving Web Pages Locally
    Mixing Windows and Forms
    Windows Server 2008 : Synchronizing Directory Information with Forefront Identity Manager (FIM)
    Information Theory
    Sony Tablet S
    iPhone 3D Programming : Textures and Image Capture - Creating Textures with the Camera
    Maintaining and Optimizing Windows Vista Systems : ReadyBoost and ReadyDrive
    Building LOB Applications : Implementing CRUD Operations in RIA Services
    Business Intelligence in SharePoint 2010 with PerformancePoint Services : PerformancePoint Services Overview
    SharePoint 2010 :Implementing a Partner Extranet Solution (part 2) - Configuring Authentication Providers
    Monitoring a SharePoint 2010 Environment : Understanding Timer Jobs for SharePoint 2010
    Collaborating Within an Exchange Server Environment Using Microsoft Office SharePoint Server 2007 : Exploring Basic MOSS Features
    Windows Phone 7 Development : Handling Device Exceptions
    Positioning Elements in XAML
    Communicate Between Processes on the Same Machine (WCF)