1. Active Directory Recycle Bin in Server 2008 R2

In the past, one of the things that seem to happen the most with Active Directory (AD) Domain Services and Lightweight Directory Services was the accidental deletion of AD objects. Now, some level of recovery has been available in both Windows Server 2003 and 2008, they were not options which allowed all of the attributes to be completely restored OR they were options which required bringing the AD server down (to enter Directory Service Restore Mode (DSRM)).

The AD Recycle Bin feature provides a mechanism which allows the complete restoration of the object’s link-values and non-link-valued attributes without having to restore from backup and bringing the AD server offline.

Learn more about the Active Directory Recycle Bin in Server 2008 R2.

2. Active Directory Administrative Center

The AD Administrative Center provides an additional option to manage AD directory service objects (by extending the abilities of AD Users and Computers). With the Administrative Center, the user is able to perform a number of administrative tasks including:

• Create new user accounts or manage existing user accounts
• Create new groups or manage existing groups
• Create new computer accounts or manage existing computer accounts
• Create new organizational units (OU) and containers or manage existing OU’s
• Connect to multiple domains or domain controllers using the same Administrative Center instance
• Filter AD data by using query-building search

Learn more about AD Administrative Center’s Global Search in Server 2008 R2.

3. AppLocker in Server 2008 R2

The Applocker feature was introduced to replace the functionality of the Software Restriction Policies feature. AppLocker extends the abilities that are available through the Software Restriction Policies feature.

With AppLocker, the user has the ability to define rules based on a number of different file attributes including digital signature, publisher, product name, file name and file version. Keep in mind however, that Applocker rules have an implicit deny at the end which means that all files which are not specified to be allowed to run are not permitted.

Learn more about AppLocker in Windows 7.

4. PowerShell Cmdlets for Group Policy

Windows PowerShell is a command line shell and scripting language which provides the ability for users to automate many of the same functions which are possible through a number of different management consoles. Some additional Cmdlets were included in the R2 distribution that provides the functionality to do a number of these additional tasks for group policy. These tasks include:

• GPO creation, removal, backup and import
• GPO link creation, update and removal
• Configuration of the inheritance flags and permissions of AD OU’s and domains
• The ability to update, retrieve and remove Group Policy registry settings
• Starter GPO creation and update

Learn more about AD PowerShell Scripts in Server 2008 R2.

5. Windows PowerShell in Server 2008 R2

Along with a number of new CmdLets which were included with Windows Server 2008 R2, there are also a number of PowerShell different enhancements. These enhancements include:

• Inclusion of PowerShell 2.0
• The ability to remote manage one or more computers by using a single command and the ability to establish an interactive session with one of more computers
• Introduction of the Windows PowerShell Integrated Scripting Environment (ISE) is a new feature which is provided
• Support for background jobs
• Introduction of the Windows PowerShell debugger
• Support for Windows PowerShell modules that let the user organize the PowerShell scripts and functions into independent, self contained units
• Transaction support
• New event infrastructure that lets the user create events, subscribe to system and application events and then listen, forward and act on these events
• Support for script internationalization
• Addition of online help that enables help options at the command line

Learn more about PowerShell 2.0 in Server 2008 R2.

6. DirectAccess in Server 2008 R2

Server 2008 R2 and Windows 7 Enterprise and Ultimate offer the ability to utilize DirectAccess functionality. DirectAccess offers the ability to connect into an organizational network whenever the client connects to an Internet based computer. DirectAccess also offers the ability to maintain software and policies which can be a big deal when dealing with remote users.

All enterprise destined traffic is authenticated and encrypted and provides the same access control as if the client was physically attached to the local organizational network. Unlike with many VPN options available, DirectAccess was designed to work over a number of different connections including behind existing Network Address Translation (NAT) devices.

Learn more about DirectAccess in Server 2008 R2 and get the steps on how to configure DirectAccess.

7. BranchCache in Server 2008 R2

The BranchCache feature in Server 2008 R2 offers the ability to improve the response time for data residing at a central office and access from a remote branch. It also provides the ability to limit the amount of WAN traffic required as data which is accessed often is cached at the local branch site.

BranchCache works in one of two modes: Distributed and Hosted cache modes: Distributed Cache mode and Hosted Cache mode.

When in Distributed mode, the BranchCache feature simply requires that the site have Windows 7 clients. In this scenario, the cache is held on the first local (at the branch) computer to access it and the other clients access the data from that client’s cache. When in Hosted cache mode, the branch requires a local server that runs Windows 2008 Server R2; this server is used for the local cache and all clients connect to this cache.

Learn more about BranchCache in Server 2008 R2 and get the steps on how to configure BrachCache.

8. RemoteApp and Desktop Connection in Server 2008 R2

The ability to use the RemoteApp feature was introduced in Windows Server 2008 through Terminal Services. With Windows Server 2008 R2, RemoteApp and Desktop Connection were introduced that offer the ability to configure a personalized view of RemoteApp programs, session-based desktops and virtual desktops to users.

RemoteApp programs which are configured on the client computer (Windows 7) show up under the Start menu with their normal programs. If connected, the client will have a notification area icon which can be used to identify this connection to disconnect if not being used.

Learn more about Remote Desktop Services in Server 2008 R2.

9. Web Server Role in Server 2008 R2

Internet Information Services (IIS) version 7.5 – IIS 7.5 is the foundation of the web server role running on Windows Server 2008 R2. This new version of IIS offers a number of new features including:

• WebDAV, FTP, Request Filtering and Administration Pack Module integrated extensions
• Best Practices Analyzer
• Windows PowerShell Provider and cmdlets
• Configuration logging and tracing

Learn more about the new features and configuration in IIS 7.5.

10. Windows Deployment in Server 2008 R2

There are a number of changes to Windows deployment which are available for Windows Server 2008 R2 and Windows 7, these include new versions of the Windows Automated Installation Kit (AIK) and Microsoft Deployment Toolkit (MDT).

The Windows Deployment Services role, which was introduced in Windows Server 2008, has also been enhanced to include support for multicast and driver-provisioning functionality; it also provides the ability to deploy Virtual Hard Disk (VHD) images by using unattended installation.

Coming Soon: Keep an eye out for additional how-to articles and tutorials on Windows Deployment in Server 2008 R2 and Windows 7.

More on Server 2008 R2

As with any new product, there are some features which will be very useful in day-to-day operations and other ones which will help only on occasion. The new functionalities that are provided by Windows Server 2008 R2 should give the user an even better platform to increase product supportability and decrease the required support time.

Here are a few additional articles on Server 2008 R2 that you might find useful:

• 7 Server Management Improvements in Server 2008 R2
• Windows Server 2008 R2 Green Features
• Server 2008 R2 Update Review

Related posts:

• Top 5 Security Changes in Server 2008 R2
• Windows Server 2008 R2 BranchCache Overview
• Windows 7 Features That Require Server 2008 R2

There are a number of different additions to this product which have enhanced the Windows Server experience both with security and with usability. The following features have added to the R2 product improving its security.

Listed in no particular order, here are my top 5 security changes in Server 2008 R2.

1. Active Directory (AD) Authentication Mechanism Assurance

While not enabled by default, this feature uses a certificate based authentication infrastructure and a Windows Server 2008 R2 domain functional level to offer an additional level of security when users login using a certificate-base method.

Administrators have the ability to control access to files, folders and printers by differentiating a user who has logged in with a certificate based method vs. a simple username/password combination. When a user logs in with a certificate based method, an additional administrator designated universal group membership is included with the user access token.

2. DirectAccess

Server 2008 R2 and Windows 7 Enterprise and Ultimate offer the ability to utilize the DirectAccess functionality. DirectAccess offers the ability to connect into an organizational network whenever the client connects to an Internet based computer.

DirectAccess also offers the ability to maintain software and policies which can be a big deal when dealing with remote users. All enterprise destined traffic is authenticated and encrypted and provides the same access control as if the client was physically attached to the local organizational network. Unlike with many VPN options available, DirectAccess was designed to work over a number of different connections including behind existing Network Address Translation (NAT) devices.

3. DNS Security Extensions (DNSSEC)

Server 2008 R2 includes support for DNS security extensions which enable the ability to have a secure DNS infrastructure. DNSSEC adds the ability to have origin authority, data integrity and authenticated denial of existence to the DNS servers.

With DNSSEC, the DNS server administrator has the ability to perform a number of tasks which were not available previously, these include:

• Ability to sign a zone and host signed zones
• Support new DNSSEC resource records: DNSKET, RRSIG, NSEC and DS

Clients that support the DNSSEC security extensions (Windows 7) can verify the authenticity of the DNS zone data by verifying the signature of the zones requested.

4. User Account Control (UAC) Changes

The functionality of the UAC has changed with the release of Server 2008 R2 so that the administrators can have a more streamlined experience and be able to control this experience more closely.

With these changes, users with administrative privileges can configure the UAC experience using the control panel. The local administrators have also been provided with additional security policies that enable the ability to change the behavior of local administrators in Admin Approval mode and standard users.

The Windows Server 2008 R2 built-in administrator account also does not run in admin approval mode, but all subsequently created administrators do.

5. Windows Security Auditing

While the ability to log a variety of security events has existed in a number of older Windows Server products, Windows Server 2008 R2 includes a number of enhancements which expand and simplify the deployment and management of auditing policies. These changes include:

• Global Object Access Auditing – This enhancement offers the ability to create a computer side system access control list (SACL) for either the file system or registry. The SACL is then applied to all objects of that type.
• “Reason for Access” Reporting – This enhancement offers the ability to view a list which provides the privileges which were used to permit or deny access to a specific element.
• Advanced Audit Policy Settings – There are now an additional 53 new settings which can be used in place of the nine based auditing settings. These can be used to more specifically target the types of behavior which are being investigated.

There are a number of other features which could have been included on this list including the AppLocker feature. However, the reviewed features above ranked above it in this author’s opinion. Hopefully, the addition of these features to Windows Server 2008 R2 will make the security of organizational networks easier to manage and maintain.

Related posts:

• Top 10 Changes in Server 2008 R2
• Using File Classification Infrastructure to Improve Security, Save Money, and Manage Data
• Windows 7 Features That Require Server 2008 R2

With the introduction of the Windows Server 2008 R2 the product formally known as Terminal Services has been renamed Remote Desktop Services and includes a number of key changes. The first of these key changes is an obvious change in the service and feature names as well as management tool names.

Below is a table with all of these name changes:

&nbap;

All of the existing functionality is still being supported with this name change.  There are also a number of different enhancements which have been included with Windows Server 2008 R2 including increased Remote Desktop session performance, processor fair scheduling, multi-core optimizations as well as equal processor quotas.

RDS Components

The main components of the Remote Desktop Services Architecture include:

• RD Session Host (RDSH) and/or RD Virtualization Host (RDVH) server(s)
• RD Licensing
• RD Gateway
• RD Connection Broker
• RD Web Access

The RDSH server is the same thing as the Terminal Server and provides all of the familiar features including session based desktop and application sharing. This type of server can also take advantage of the RD Connection Broker when multiple servers are deployed.

The RDVH server is a new feature which provides support for a Virtual Desktop Infrastructure. The RDVH server is configured to take advantage of Hyper-V based servers located within the data center, enabling the use of a VM-based remote desktop which can be configured with full administrative control without the security implications of session based setups. The RDVH servers can provide an administrator the option of configuring virtual desktops which can be fully personalized in order to deliver a consistent desktop environment. They can also be configured to utilize shared VM desktop pools which are not personalized.

The RD Licensing role provides management of RDS client access licenses (RDS-CAL’s) which are required for each device or user connecting into either a RSDH or RSVH server. There is however some changes which have been implemented, these include:

• Removal of automatic license server discovery
• Licensing tab changes
• New RDS-CAL’s wizard
• Service Connection Point (SCP) registration

The RD Gateway role provides a way of connecting to internal services from an outside location through the use of RDP over HTTPS. A couple of changes have also been implemented which include:

• The ability to enforce a secure device redirection policy
• Configurable Idle and Session timeouts
• Addition of background session authentication and authorization
• The ability to send service and content messages to connected users

The RD Connection Broker is used to provide users with access to remote desktop and RemoteApp application resources. RD Connection Broker extends the previous TS Session Broker by supporting not only session based capabilities but also support for VM based desktops (both personalized and polled).

RD Web Access provides the ability to use both session-based remote desktop and application abilities as well as VM-based remote desktop abilities through a web browser. An appropriate connection on either the RDSH or RDVH will be established when a session is initiated to provide the interface. Traffic from the browser utilizes HTTPS to secure the connection.

RDS Additional Capabilities

Along with everything mentioned above, RDS provides a number of different user experience capabilities which did not exist before which are focused on those running Windows 7 Enterprise and Ultimate. These capabilities include:

• High-quality multimedia redirection including audio and video redirection in its original format
• True multiple monitor support; this includes support for up to 16 monitors
• Audio input and recording capabilities; this includes support for speech recognition and user microphone support
• Windows Aero Glass support; this provides support or the Aero interface on RDSH servers ensuring a familiar look and feel.
• Enhanced bitmap acceleration; allows rich media like flash and Silverlight as well as applications using DirectX versions above 9 to be rendered on the host (server) and then sent to the client.
• Improved Audio/Video synchronization
• Support for language bar redirection when using RemoteApp programs

The RDS feature is a very powerful option which can be implemented to provide an alternative way of providing desktop or application solutions when a centralized infrastructure is available. If any of the features listed above seem to fit your specific requirements take time the time to invest in researching these services.

Related posts:

• Server 2008: How to Setup a Remote Desktop on Windows Vista
• Direct Access: How It Works And How To Configure It
• Active Directory Rights Management Services: Data Access Controls

These enhancements include:

• Integration of the FTP service
• Integration of WebDAV, including support for HTTP over SSL
• A new management console with administrative enhancements
• A configuration editor which is embedded into the management console for easier creation of automated scripts
• The addition of an Application Warm-Up extension which is used to decrease initial application response times
• Integration with Windows Server 2008 R2’s Best Practice Analyzer which advises based on IIS best practice rules
• Built in support for .NET 4.0 applications
• Several development enhancements which help developers code in the most secure way possible
• Ability to use configuration tracing to audit changes to the IIS system

IIS 7.5 Installation

As with many of the different services provided in Server 2008 R2, the installation of IIS is done through Server Manager and is rather easy to setup. The following steps are used to setup IIS 7.5 on your system.

Step 1: Launch Server Manager and select the roles option in the left pane as shown in Figure 1 (click on the image to see full screen):

Figure 1 – Server Manager Roles Option

Step 2: As IIS is considered an additional role for the server, select the Add Role option in the right pane, this will bring up the window as shown in Figure 2:

Figure 2 – Add Roles Windows

Step 3: Select Next from the initial Add Roles windows and you will receive the window as shown in Figure 3. From here select Web Server (IIS) and select Next.

Figure 3 – Select Server Roles Window

Step 4: Once you select Next on the Select Server Roles window, the Introduction to Web Server window will be displayed as shown in Figure 4 below, which gives an overview of the Web Server capabilities with additional links for additional information. Once done with reading this window select Next.

Figure 4 – Introduction to Web Server Window

Step 5: The window shown in Figure 5 and 6 below allows you to configure IIS with the capabilities which are required for your installation. Any of these options can be added or removed later should you be uncertain at this point.

Figure 5 – Select Role Services

Step 6: From the windows shown in Figure 6 you can also see where the FTP Server has been integrated into the Web Server (IIS) Services. Once you have selected all of the options needed for your installation select Next.

Figure 6 – Select Role Services (FTP Server Integration)

Step 7: Once you are finished with selecting the options available for the Web Server Installation, the wizard will prompt you with the Confirm Installation Selections window as shown in Figure 7, which enables you to review your configuration selections. Once you are finished reviewing your configuration options select Install.

Figure 7 – Confirm Installation Selections Window

Step 8: Watch the Installation Progress window as your selections are installed.

Figure 8 – Installation Progress

If everything was installed as expected, then the window shown in Figure 9 will be displayed which lists all of the options which you had selected.

Figure 9 – Installation Results Window

IIS 7.5 Management

There are a number of different Windows which can be used to display and configure the options available for the Web Server (IIS). The first of these is displayed in Figure 10 below.  

This window shows the various options which were installed with the Web Server (IIS) and provides the option to manage the Web Server through the use of the Go to Web Server (IIS) link. This window also offers you the ability to add or remove Role Services to your Web Server (IIS) installation, this is done via the Add Role Services and Remove Role Services links.

Figure 10 – Server Manager (Web Server (IIS))

Once the Go to Web Server (IIS) link is selected then the window shown in Figure 11 is displayed. From this window a variety of different options are available to connect and configure your Web Server (IIS). The servers which are currently configured for the Web Server can be seen displayed on the left pane of the management window, this is of course very familiar to many of the other Role management windows.

Figure 11 – Web Server – Main Configuration Window

Once the server which is intended to be managed is selected from the left management pane the window in Figure 12 is displayed. From this window the variety of options available are accessible.

Figure 12 – Web Server (IIS) Server Manager Window

As I mentioned in the previous section, IIS 7.5 includes the integration of the familiar Server 2008 R2 Best Practices Analyzer, this window is shown in Figure 13:

Figure 13 – Best Practices Analyzer

There are a number of different enhancements which come with IIS 7.5 which will enable both developers and users the ability to enjoy sites and their enhancements in an easier and more friendly manner. Hopefully this article allows you the ability to review these new features and helps in planning for Web Server (IIS) installation.

Related posts:

• Server 2008 R2 BranchCache Configuration
• Windows Server 2008 R2 DirectAccess Configuration
• 10 Steps to Installing the Web Server Role in Windows Server 2008

BranchCache can also be used in one of two different modes which determine where the specific content is cached. The first of these is via a more standard server configuration; this server will physically sit at the remote site and be a storage location of the BranchCache cache which is referred to as hosted cache mode.

The second of these modes does not require a server at the remote site and utilizes the available configured Windows 7 ultimate and enterprise clients as storage locations.  In this case the availability of the cache depends on the reachability of individual clients and not a central server location; this mode is referred to as distributed cache mode.

BranchCache Client Configuration

The first thing that we will do is explain the required client firewall configuration.  The Windows firewall (or whatever firewall you are using) needs to be configured to support the BranchCache traffic. The first rule which must be created is called the Content Retrieval predefined rule which opens up TCP port 80 both inbound and outbound.  The second rule depends on the mode of BranchCache operation:

• Distributed cache mode – Requires the configuration of the Peer-Discovery (Uses WSD) predefined rule which opens up UDP port 3702 both inbound and outbound.
• Hosted cache mode – Requires the configuration of the Hosted Cache Client predefined rule which opens up TCP port 443 outbound.

These options are shown in Figure 1 (click on the image to see full size):

Figure 1 – Predefined BranchCache rules

The second thing that needs to be configured on the clients is a group policy which enables BranchCache and the specific mode of operation to be used. There are three different policies which are used to configure the initial operation of BranchCache; these three are located at ‘Computer Configuration\Administrative Templates\Network\BranchCache’ node and include:

• Turn On BranchCache – Used to enable the use of BranchCache
• Set BranchCache Distributed Cache Mode – Used to enable Distributed Cache Mode operation.
• Set BranchCache Hosted Cache Mode – Used to enable Hosted Cache mode and provide the Fully Qualified Domain Name of the hosted cache server.

Now this policy can be configured on the individual machines or via a domain level with group policy. Figure 2 below shows the policy screen used when configuring the policy on each individual machines and Figure 3 below shows the policy screen used when configuring via group policy.

Figure 2 – Local Computer Policy

Figure 3 – Domain Group Policy

Another alternative that is available to configure BranchCache on clients is the use of the ‘netsh’ command line tool. The use of a single ‘netsh’ command line entry can enable BranchCache, set the cache mode and configure the appropriate firewall rules. The list below shows the commonly used ‘netsh’ BranchCache options:

• netsh branchcache reset – Resets BranchCache configuration, stops the service, resets the registry to defaults and sets the service start type to manual.
• netsh branchcache show status – Shows the current service mode and status of BranchCache.
• netsh branchcache set service mode=distributed – Configures the client to use the distributed cache mode, changes the service start type to manual, and configures the appropriate firewall rules.
• netsh branchcache set service mode=hostedclient location=hostedserver – Configures the client to use the hosted cache mode, configures the location of the hostedserver, changes the service start type to manual, and configures the appropriate firewall rules.

Server Configuration

If you are using the distributed cache mode, the content server must be configured with BranchCache. If you are utilizing the hosted cache mode, the server acting as the cache server must be configured at the remote location and the content server must be configured with BranchCache.

The configuration of the HTTP content servers and the initial configuration of the hosted cache server is the same with the installation of the BranchCache feature; this is shown in Figure 4:

Figure 4 – BranchCache Feature Configuration

The second step when configuring the hosted BranchCache server is telling the server to act as  a hosted cache server by using the ‘netsh branchcache set service mode=hostedserver clientauthentication=none’.

The third step depends on the specific configuration of the network being configured. This step requires that a trusted certificate relationship exist between the hosted cache server and the clients. This can either be done using a self-signed certificate on the hosted server which is also configured on clients as a Trusted Root Certification Authority or via a PKI infrastructure.

Now for the SMB content servers to support BranchCache a separate BranchCache role is configured on the content server; this role is part of the File Services role which is shown in Figure 5:

Figure 5 – File Service Role

When configuring the File Services role you must select the ‘BranchCache for Network Files’ option; this is shown in Figure 6:

Figure 6 – BranchCache for Network Files option

When configuring the SMB content server, a second step is required that enables Hash publication for BranchCache and is shown in Figure 7.

Figure 7 – BranchCache Hash Publication

Over the years there have been a number of different products and technologies created and implemented to improve the performance of remote data. BranchCache offers a modern alternative which requires little configuration effort and has the ability to give that extra performance required in these types of deployments.

Related posts:

• Windows Server 2008 R2 BranchCache Overview
• Windows Server 2008 R2 DirectAccess Configuration
• Top 10 Changes in Server 2008 R2

BranchCache offers the ability to cache specific remote content so that those individuals accessing it remotely can access them easier and with better performance. It does this by offering the ability to cache specific traffic types at the remote location and allowing these caches to be used locally in order to obtain performance increases. It is also important to note that the BranchCache feature/role is only a read cache and thus does not affect the updating of cached files.

BranchCache Modes

BranchCache has a couple of different working modes which are used for different types of traffic and different types of running clients and servers.

For those looking to cache file share data which will be accessed via the Server Message Block (SMB) protocol the BranchCache for network files role service is used. When this feature is used, file shares can be configured to utilize BranchCache to increase share performance.

For those looking to cache Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS) and Background Intelligent Transfer Service (BITS) traffic then the BranchCache feature is installed. Regardless of the traffic type this part of the BranchCache configuration is referred to as the Content servicer or server.

On the remote side (or Branch side) there are also a couple of options which are available enabling flexibility when deploying depending on the type and number of computers which are utilized at the site. The first of these deployment options is the Distributed Cache Mode and the second is the Hosted Cache Mode.

When utilizing the Distributed Cache no server is available or running at the remote site which can be used by BranchCache. In this case the Windows 7 clients which are available cache the information on their local hard drives and utilize these caches between each other. When a server is available at the remote site then it can be utilized as a cache point, when this is occurs the Hosted Cache Mode is utilized. When utilizing this mode all the cached information remains on the server and all clients utilize it to improve performance.

Like all technologies, each of these features requires a specific Operating System (OS) version in order to be deployed. These requirements are laid out below.

BranchCache client OS requirements:

• Windows 7 Enterprise
• Windows 7 Ultimate

BranchCache content server OS requirements:

All versions of Windows Server 2008 R2 except:

• Windows Server 2008 R2 Enterprise Core Install with Hyper-V
• Windows Server 2008 R2 Datacenter Core Install with Hyper-V

BranchCache hosted cache server OS requirements:

• Windows Server 2008 R2 Enterprise
• Windows Server 2008 R2 Enterprise with Hyper-V
• Windows Server 2008 R2 Enterprise Core Install
• Windows Server 2008 R2 Enterprise Core Install with Hyper-V
• Windows Server 2008 R2 for Itanium-Based Systems
• Windows Server 2008 R2 Datacenter
• Windows Server 2008 R2 Datacenter with Hyper-V
• Windows Server 2008 R2 Datacenter Core Install with Hyper-V

There are also some other requirements which must be met depending on the BranchCache operating mode. When using Distributed cache mode, a server is not required and the deployment of certificates is not required. When using Hosted cache mode you must enroll a server certificate to the Hosted cache server(s).

The use of either one of BranchCache’s available modes will increase the performance of the above types of traffic. While it is possible to deploy BranchCache using the Distributed cache mode even when a local server is available, it should be noted that Hosted cache mode has additional advantages over the Distributed cache mode, these include:

Increased cache availability:

As a server remains online all the time the cache will also remain online all the time thus increasing the availability of the cached information. When utilizing the Distributed cache mode the client which initially requests the data from the content server holds the cached data. If this client goes offline at any time the cache must be reestablished on another client.

Centralized caching when multiple remote subnets are used:

• When using Distributed cache mode each of the caching clients only work within their own subnet and clients on different subnets must separately cache data regardless of whether it has been already cached on the other subnet. When utilizing Hosted cache mode with a server this data can be centrally held on this server and used by clients over multiple subnets.

The BranchCache feature can be a useful tool when WAN’s separate main and branch offices and should be considered a useful addition to the available features available. Take the time to test the feature in a test bed and measure the potential performance increases.

Related posts:

• Server 2008 R2 BranchCache Configuration
• Top 10 Changes in Server 2008 R2
• Windows 7 Features That Require Server 2008 R2

DirectAccess Connection Process

As covered in the overview, the connection process for using DirectAccess depends on the connection between the client and the server and has been designed to work in a variety of different situations. The steps required to establish a connection are as follows:

1. A Windows 7 Ultimate or Enterprise DirectAccess client detects connection to a network
2. The client determines whether it is connected to an intranet, if not then DirectAccess is used
3. The client connects to the DirectAccess server viaIPv6 and IPSec; if a native IPv6 network is not available the client will use 6to4 or Teredo to send IPv4 encapsulated IPv6 traffic.
4. If a firewall prevents the client from establishing a connection to the DirectAccess server then a connection is attempted using HTTPS, when using HTTPS a Secure Sockets Layer (SSL) connection is used to encapsulate IPv6 traffic.
5. The client will authenticate the client (computer) and the server via computer certificates
6. If NAP is used health validation will occur
7. When the user on the client logs in, the DirectAccess client will establish the second tunnel to the resources and authenticate the computer and user credentials.
8. If authenticated the resources will be accessible

DirectAccess Network Requirements

There are a number of prerequisites which must be satisfied before deploying DirectAccess on your network. These are listed below and are what is recommended by Microsoft before a full implementation; some of these steps may be optional if simply testing in a lab environment:

• Deploy Active Directory
• Deploy a Public Key Infrastructure with AD certificate services
• Configure a certificate revocation list (CRL) which is reachable from the Internet (Clients)
• Install Windows 7 Ultimate or Enterprise on your clients and join to AD
• Configure firewalls to allow DirectAccess traffic
  • Teredo – UDP port 3544
  • 6to4 – IPv4 protocol 41
  • IP-HTTPS – TCP port 443
  • Remote IPv6 clients – ICMPv6 and IPv4 protocol 50
  • Ensure DNS servers are running at least Windows 2008 and remove ISATAP from global query block list

DirectAccess Client Connection Specifics

As step 3 in the above list tells use if a connection is to be established via DirectAccess a connection supporting IPv6 is required. As there are a number of different ways which exist to connect to IPv6 networks there are also a number of different ways to configure DirectAccess. The most preferred of these options would be to have an existing IPv6 client which connects to the server through an IPv6 network. In this case the connection between the server and the client is rather simple and just uses a simple IPv6 connection. However, if the client does not have a native IPv6 connection between the client and the server then DirectAccess’s other options can be used. These options include using 6to4 or Teredo transition technologies or as a last option using a HTTPS connection.

Now the best option with client configuration is to utilize group policy.  In this situation the required configuration can be created at a central point and published to all potential DirectAccess clients. Now if for whatever reason you want to manually configure the DirectAccess client then these four policies would need to be configured, all of which are located under the ‘Computer Configuration\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies’ node:

• 6to4 Relay Name – Configured with the public IPv4 address (one of the addresses) on the DirectAccess server
• IP-HTTPS State – Configured with the URL for the IP-HTTPS server (DirectAccess server) and configures the state which can be used to control the use of IP-HTTPS. By default, an IP-HTTPS connection is used as a last resort connection.
• Teredo Default Qualified – Enables the use of the Teredo transition technology.
• Teredo Server Name – Configured with the address of the Teredo server (DirectAccess server).

DirectAccess Server Connection Specifics

Now, with DirectAccess, the bulk of the configuration must be done on the server; however once this is complete the deployment of each DirectAccess client is as simple as putting them in the appropriate DirectAccess policy group.

There are some minimum requirements which must be met in order for a server to be configured with DirectAccess. These include:

• Must be running Windows Server 2008 R2 and be a Domain member (Not a DC)
• Must have two network adapters (Intranet and Internet), the Internet network adapter must have two consecutive global IPv4 addresses assigned to it (not private).
• Must have a digital certificate which is configured with the fully qualified domain name which matches the name associated with the two Internet IPv4 addresses.
• At least one global security group which will be used to assign DirectAccess policy to the clients
• Must configure a connection-specific DNS suffix

Once these requirements have been met you can start to setup DirectAccess on the server. The following screen shots show the basic steps which would be taken to set the server up for DirectAccess:

Figure 1 – DirectAccess Feature Setup

The first step is to install the DirectAccess Management Console; this will then be used to configure DirectAccess.

Figure 2 – DirectAccess Setup Wizard

Once the DirectAccess Management console is installed, then you can run it from the Administrator tools directory. Figure 2 above shows what the management console looks like and is organized into four different configuration steps.

Figure 3 – DirectAccess Client Setup

The first step is used to select the global security group used for DirectAccess clients.

Figure 4 – DirectAccess Server Setup – Internet interface Domain classification

The second step is used to configure the network interface for use with DirectAccess. The wizard at this point will perform a number of checks to ensure that all prerequisites have been satisfied. From this screen you would select which interfaces will be used to connect to the Internet and which one would be used to connect to the internal network servers. The interface which is going to be used for connecting to the Internet must not be classified by Windows as a domain interface as the wizard will not allow it; this is shown in figure 4.

Figure 5 – DirectAccess Server Setup – Existing IPv6 Configuration

If the wizard detects that IPv6 has already been configured on the Internet interface it will configure DirectAccess appropriately along with still providing IPv6 transition technology support; this is shown in figure 5.

Figure 6 – DirectAccess Server Setup – No Existing IPv6 Configuration

However, if IPv6 is not configured on the Internet interface then DirectAccess will detect this as well and enable the use of IPv6 transition technologies; this is shown in figure 6.

Figure 7 – DirectAccess Server Setup – IPv6 Prefix Configuration

Once the internal and Internet interfaces have been configured then the internal IPv6 prefix will be configured along with the prefix which will be given out to DirectAccess clients. This configuration is shown in figure 7.

Figure 8 – DirectAccess Server Setup – Certificate Configuration

The last part of this step configuration requires the assignment of certificates to be used for remote client certificates and for IP-HTTPS client connectivity. This configuration is shown in figure 8.

Figure 9 – Infrastructure Server Setup – Network Location Configuration

The next step is used to setup the infrastructure server setup including the network location server. The network location server is used by clients to determine whether they are already connected to the intranet and thus do not require DirectAccess. This can be configured to either work through a highly available HTTPS server or via the DirectAccess server itself; this configuration is shown in figure 9.

Figure 10 – Application Server Configuration

The last step involved with setting up DirectAccess involves the configuration for the internal application servers. As reviewed in the overview article there are a number of different ways to setup connections between the clients and the application servers; the configuration options available for this are shown in figure 10.

Related posts:

• Windows Server 2008 R2 DirectAccess
• Server 2008 R2 BranchCache Configuration
• Direct Access: How It Works And How To Configure It

Traditionally, these types of workers were able to utilize corporate intranet resources via either a Virtual Private Network (VPN) or via web gateways. The problem with these different options is that they are either cumbersome or complex to work with or they are limited in their access to internal resources.

It is for these types of users that DirectAccess was developed. With DirectAccess in Server 2008 R2 the cumbersome setup, authentication and authorization that exists with VPN solutions is done automatically in the background and the limitations which are imposed by web gateways are no longer limited.

How DirectAccess Works

DirectAccess works by establishing a bi-directional connection between the client and the internal company resources. This is done either with IPSec or with Hypertext Transfer Protocol Secure (HTTPS) tunnels if IPSec is not permitted. DirectAccess also relies on IPv6 which is transported within these established tunnels.

How DirectAccess Works (Image courtesy of TechNet)

When establishing the secure tunnels there are two tunnels which are established separately, these include an initial tunnel to the domain controller(s) and DNS server(s) which is used to download group policy objects and to authenticate the computer on the user’s behalf and a second tunnel which is used to authenticate the user and provide access to the permitted intranet resources.

Implementing DirectAccess: End-to-End & End-to-Edge Protection

Now there are also two different methods which can be used to implement DirectAccess depending on the currently implemented technologies on your intranet network and servers. These two methods include End-to-End and End-to-Edge protection.

When using the End-to-End method of protection, the second tunnel terminates at the server where the accessed resources exist. When using this method, the endpoint servers must run Windows Server 2008 or Windows Server 2008 R2 and support both IPv6 and IPSec.

When using End-to-Edge protection, the second tunnel terminates at the IPSec gateway server (which is also typically the DirectAccess server). The traffic destined for the endpoint server is then sent unprotected across the internal network. Either implementation requires that the client runs either Windows 7 Ultimate or Enterprise.

DirectAccess has another feature which provides another advantage over VPN connections; this includes its ability to have only intranet based traffic tunneled over the WAN back to a central location. When using a VPN all traffic is typically routed to the central location even if the destination is on the public Internet which can be accessed faster directly. By default, DirectAccess only tunnels traffic destined for the Intranet, although the option to route all traffic back to a central location is available.

DirectAccess Connection Process

1. A Windows 7 Ultimate or Enterprise DirectAccess client detects connection to a network
2. The client determines whether it is connected to an intranet, if not then DirectAccess is used
3. The client connects to the DirectAccess server viaIPv6 and IPSec; if a native IPv6 network is not available the client will use 6to4 or Teredo to send IPv4 encapsulated IPv6 traffic.
4. If a firewall prevents the client from establishing a connection to the DirectAccess server then a connection is attempted using HTTPS, when using HTTPS a Secure Sockets Layer (SSL) connection is used to encapsulate IPv6 traffic.
5. The client will authenticate the client (computer) and the server via computer certificates
6. If NAP is used health validation will occur
7. When the user on the client logs in, the DirectAccess client will establish the second tunnel to the resources and authenticate the computer and user credentials.
8. If authenticated the resources will be accessible

DirectAccess offers an additional technology which makes the job of accessing internal resources easier and more secure. This is a vital part of the modern working environment and allows businesses the option to allow more employees to work from home or other remote locations.

Related posts:

• Windows Server 2008 R2 DirectAccess Configuration
• Direct Access: How It Works And How To Configure It
• Windows Server 2008 R2 BranchCache Overview

Simply finding the right objects and then updating their properties or implementing changes can be a cumbersome process. Many Microsoft systems engineers have developed their own shortcuts and conventions over the years for dealing with the administration of complex Active Directory structures. One tool that has been lacking, however, is the ability to write powerful scripts to manage Active Directory.

The good news is that the arrival of Windows Server 2008 R2 with PowerShell 2.0 and the Active Directory Module changes all of that for the better.

Powershell 2.0 and Active Directory Module

Of the many new features in Windows Server 2008 R2, PowerShell 2.0 is one that may finally be coming into its own. One of the key new features in PowerShell 2.0 is the addition of modules. Modules differ from PowerShell 1.0 snap-ins in that they are self-contained and do not require registration or installation. Rather, modules are imported into the shell via the Import-Module command. Modules can also be offloaded when they are no longer needed.

To use the Active Directory Module, there needs to be at least on Windows Server 2008 R2 Domain Controller running Active Directory Web Services (ADWS) in the domain. As an alternative, the Active Directory Management Gateway Service can be installed on Windows Server 2003 SP2 servers and Windows Server 2008 (non-R2) servers with or without SP2 installed.

For the most powerful configuration of PowerShell 2.0 with the Active Directory Module, you will want to be able to do your scripting remotely from your own computer, or other workstation. This does require Windows 7 in order to install the Remote Server Administration Tools (RSAT).

The Active Directory Module provides a powerful way to manage AD structures even across domains. Part of the AD Module is the PSDrive Provider which allows you to map to an Active Directory domain using whatever credentials are required via the New-PSDrive cmdlet. Users are connected to their current domain by default. The mapped rights persist for the entire shell session, even if it requires using different login credentials for several different AD domains.

Active Directory Scripts In PowerShell 2.0

There are many different commands included in the Active Directory Module. One count places the total number of new commands at 82. The most commonly used commands, however, are those that match up with the most common Windows Server Administrator tasks. The naming convention for Active Directory cmdlets dictates that each cmdlet start with “AD” in order to help separate the Active Directory versions from similar PowerShell cmdlets available in the base PowerShell.

Thanks to this naming convention, obtaining a list of all the Active Directory Module cmdlets can be done by running the Help *-AD* command.

The most difficult part of getting up to speed with Active Directory management via PowerShell 2.0 is mastering all of the parameters available for each cmdlet. In an effort to allow virtually any function that can be performed manually to be scripted, Microsoft had to provide a working parameter for pretty much every setting, checkbox, and field that there is in the GUI. That means that some commands have a mind boggling array of available options. Fortunately, only a small subset of any cmdlet’s parameters are mandatory in order to run the desired command.

As with any new programming language, the key is to focus in the beginning on the basics and most frequently used options and build mastery as you go along. While it may seem daunting at first, one will quickly find that using built-in cmdlets specifically designed for their purpose ends up being much easier to both code and manage than mastering all of the work-arounds and band-aids currently required to perform the same tasks.

Common Active Directory Cmdlets for PowerShell

The most common administrative tasks within Active Directory are those that relate to creating, finding, and changing objects and users. Not surprisingly, these cmdlets make a great place to start learning and using PowerShell 2.0 to manage Active Directory.

Commonly used PowerShell AD cmdlets include:

• New-ADUser
• New-ADGroup
• New-ADComputer
• New-ADOrganization
• New-ADServiceAccount
• Unlock-ADAccount
• Enable-ADAccount
• Disable-ADAccount
• Get-ADUser
• Add-ADGroupMember
• Get-ADGroupMember
• Get-ADForest
• Get-ADDomain
• Get-ADDomainController

Of course, the real power from scripting comes not from typing in a bunch of esoteric computer commands instead of clicking mouse buttons, but from the ability to save useful scripts and use them over and over again. To this end, Active Directory cmdlets support piping information into the cmdlets. For example, to create a couple dozen new users, the administrator could take the Excel Spreadsheet supplied from Human Resources, export it as a CSV file and then pipe the resulting data to the New-ADUser command: Import-CSV c:\neweuserdata\april-new-employees.csv | New-ADUser and let the script take care of all the basic data entry.

Using parts of the same file, the admin can go back through and using the appropriate cmdlets add users to their respective groups and domains and even apply additional group policies to the new users.

Of course, easy, but highly repetitive tasks can be automated as well. Imagine picking up the phone with a call from a panicked user who has locked himself out of his account (again). A tiny shortcut launched directly with minimal typing and clicking requiring nothing more than the user’s login name quickly firing off and unlocking or even re-enabling the account, all without ever having to leave the screen you were already working on when the phone rang.

PowerShell Resources

Even though the Active Directory Module is new with PowerShell 2.0 there are already some great references available for Microsoft server administrators. Check out Jonathan Medd’s Active Directory PowerShell Quick Reference Guide for help getting up to speed and remembering lesser used commands. Microsoft has a general PowerShell Quick Reference guide as well. For those of you lamenting the hours spent mastering VBScripting, check out the VBScript to Windows PowerShell Conversion Guide.

Learning new technology and skills is never easy, but the truth — if we are willing to admit it — is that as high-tech computer administrators, we quickly grow bored with doing the same things over and over again. Not only does PowerShell 2.0 and the Active Directory Module provide some new material for the skills menu, it also provides a way to eliminate far more tedious, repetitive tasks than ever before.

Related posts:

• PowerShell 2.0: Server 2008 R2 Top New Management Feature
• Take Command of Server 2008 with Windows PowerShell – Part 1
• Don’t be Afraid of PowerShell

Installing FCI on Server 2008

Although FCI comes with all versions of Server 2008 R2, it is not installed by default in line with Microsoft’s strategy of installing only the necessary services and roles on each server based upon its functionality within the network. FCI is installed as a component of the File Services role, and implemented via the File Server Resource Manager console. Once installed, FCI is at once deceptively easy to use, and at the same time, infinitely complex in its possibilities.

The first step in using File Classification Infrastructure is to define what the tags are. There are no default tags or tagging systems, because FCI is designed to be custom tailored to a particular business environment. One need only think about the difference between what confidential or secret mean to a chain of dry cleaners, versus what they mean to a defense contractor to see why defaults would not be particularly useful in this case.

Tagging files is done by “classifying” them. FCI classification is a two-step process. The first step is to define the classifications. The second step is to apply the classifications to files.

Defining classifications is done within FSRM under Classification Management. Under Classification Management, is Classification Properties, where one creates the classification structure. Here the rules are defined that determine whether or not a file is classified as a particular kind of data. For example, a file might be classified as “confidential” if is stored in the “Confidential” directory of the Legal Department’s file server area. Obviously, more complex criteria are possible. A file might be classified as internal financial data if it is created by a member of the Accounting group, during the first week of the month, and the file name contains the words “monthly report.”

FCI supports classifications based upon date and time, numbers, multiple choice lists, ordered lists, strings, multiple strings, or Boolean criteria. There is no need to stick with generalized classifications like Confidential, Secret, or Internal Use Only, although these can be set as high-level classifications. The real power of FCI comes from more granular classifications, such as classifying all Excel spreadsheets, stored in the project folder “New Products”, created between January and March of 2009, that contain the words “projected internal costs”, as Internal Prototyping Projections.

Using FCI To Improve Security and Better Manage Data

Defining the classifications doesn’t actually do anything. No files are tagged just by defining the components of a classification. In order to do anything with these classifications, the real files must be tagged. Doing so requires creating Classification Rules.

To create a classification rule, one first defines a name and a scope for the rule in the Rule Settings tab. The name is what the tag attached to the file will be called. The scope defines which files to evaluate to determine if they are assigned that classification. The actual rules for classifying files are done in the Classification Tab. Classifying can be done by simply evaluating whether or not a file is within a certain folder (Remember the tag follows the file as it is moved and copied.). It can also be done by checking for certain words or phrases within the documents themselves. Powerful classification can be done using the PowerShell classifier. This limits your ability to evaluate files only by your ability to write a PowerShell script to do what you want.

An analogy can help make the process a little clearer.

Classifications Properties are the things that matter for determining speed limits. For example, how close is the road to a school, is the road an Interstate, is the road two-lanes, three-lanes, four-lanes, etc. Notice that these are just the properties that CAN be evaluated; there is no structure here for how a road is assigned a particular speed limit, only what properties will need to be examined in order to assign a speed.

Classification Rules are like the actual criteria that determines which speed limit a road gets. For example, roads within 100 feet of a school should be classified as 20 MPH roads. At this point, all you have is rules in the city planner’s office. In order to actually implement the speed limits, the possible criteria need to be evaluated against the rules.

At this point, you can actually apply the rules to the roads. Doing so requires choosing which roads to evaluate against which criteria (scope). Based on that evaluation, you can actually “tag” the roads by putting up speed limit signs that say 20 MPH (name).

Finally, the files are classified. However, nothing has actually been done based on those classifications.

To actually DO SOMETHING with all these tagged files, the administrator has several choices. First, both file management and reporting based on the classification tabs are available in FSRM. These tools can be used to move, copy, rename, or delete files, as well as setting more traditional file properties. Just as important, reports can be generated to alert administrators or managers that files tagged as Sensitive or Confidential are residing in insecure locations. Using just these two tools can resolve a lot of headaches, as well as create better processes. No doubt the first time that guy in accounting gets asked why he is saving proprietary budget documents to a public share, he won’t even know he was doing that. (“We’ve always saved them to the G Drive.”)

However, even more powerful management can be achieved using PowerShell. Once classified, the FCI system can be used inside PowerShell scripts in order to perform complex tasks or create additional reporting or alert levels.

Creating an entire file classification system from scratch is a daunting prospect. However, building some basic rules to generate reports is a good starting place. From there, needs and concerns will arise that can be easily solved by using the FCI system. Eventually, a file classification as robust and as well-defined as your Active Directory structure will emerge. After all, you didn’t start out the first day of the Active Directory implementation by creating all the objects you have today.

Related posts:

• File Classification Infrastructure in Server 2008 R2 SP2
• Top 5 Security Changes in Server 2008 R2
• Active Directory Rights Management Services: Data Access Controls