Windows 2008 R2 has introduced a number of compelling features that would entice any Windows administrator to upgrade to, and the most welcomed feature in my own opinion would have to be the Active Directory Recycle Bin.  Previous to the R2 upgrade, system admins and the like would have had to rely on paid 3rd party software that would take care of accidental deletions of users or even worst organizational units.  Those who did not make the investment in 3rd party software would have had to rely on system state backups which is always a disruptive process in the event that you needed to perform an authoritative Active Directory restore.

Well, that’s not the case anymore and as noted above, Windows 2008 R2 introduces the Active Directory Recycle Bin Feature in addition to a number of other enhancements and features which I have listed in an earlier post, Introducing your first Windows 2008 R2 Domain Controller.

Before we begin, we need to ensure that we have met the minimum requirements allowing you to enable the Active Recycle Bin.  In summary, your Domain Forest Functional Level needs to be at least Windows 2008 R2.  More information can be found in the following TechNet article; http://technet.microsoft.com/tr-tr/library/dd379484(WS.10).aspx

Now that we have met those requirements, we need to run the following command on the AD Domain controller where the Schema Master Resides.  If you are not sure where the Schema Master role resides, follow the below TechNet article on How to view and transfer FSMO roles in Windows Server 2003.

On the Schema Master Domain Controller, run Start / Administrative Tools /  Active Directory Module for Windows PowerShell.

Type in the following command;

N.B replace yourdomain.com with your own Active Directory domain name

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=yourdomain,DC=com’ –Scope ForestOrConfigurationSet –Target ‘yourdomain.com’

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=yourdomain,DC=com’ –Scope ForestOrConfigurationSet –Target ‘yourdomain.com’

You will get a warning which you will need to confirm stating that enabling the Recycle Bin Feature is irreversible.

That’s it!  The recycle bin will now begin capturing deletions of objects which will allow you to later restore them to their original or alternate location.  Now you might be asking, how do we actually perform a restore?  Well, I’m glad you asked, that’s the 2nd reason why you are reading this article right?!

Microsoft for some reason did not provide admins with a GUI in doing so, however there are FREE 3rd party tools that plug directly into the Recycle Bin feature that will provide you with an easy GUI for performing Active Directory object(s) restoration.  Now before delving into MY current tool of choice, the following article by Microsoft explains how it is done via the command line; Restore a Deleted Active Directory Object http://technet.microsoft.com/tr-tr/library/dd379509(WS.10).aspx

My tool of choice (there are several out there) providing me with a graphical interface is PowerGUI in combination with their Active Directory Recycle Bin for PowerPack.  You can download these from the links below;

Download the latest PowerGUI from http://powergui.org/downloads.jspa

Download the latest Active Directory Recycle Bin PowerPack from http://powergui.org/kbcategory.jspa?categoryID=46

Now that we have the relevant components, install PowerGUI and then import the AD Recycle Bin PowerPack via File / PowerPack Management / Import

Now as a test I have created a Test User account in Active Directory and then deleted the account a few minutes later.  Lo and behold when I refreshed the Active Directory Recycle Bin node within the PowerGUI Navigation tree, my Test User was listed in the results pane.

From the Actions menu, you can easily restore the user to either its original location or alternate location.  From the Actions menu you can also configure the recycle bin further via a GUI, and empty the recycle bin completely.

As you can see from the above, the Active Recycle Bin is a long awaited feature introduced with Windows 2008 R2 and with a front end like PowerGUI you can now easily and very quickly restore accidentally deleted Active Directory objects.  Now I wonder if Microsoft will incorporate their own graphical interface in the near future.

Resources

Scenario Overview for Restoring Deleted Active Directory Objects http://technet.microsoft.com/tr-tr/library/dd379542%28WS.10%29.aspx

Enable Active Directory Recycle Bin http://technet.microsoft.com/en-us/library/dd379481(WS.10).aspx

Restore a Deleted Active Directory Object http://technet.microsoft.com/tr-tr/library/dd379509(WS.10).aspx

Additional Active Directory Recycle Bin Tasks http://technet.microsoft.com/tr-tr/library/dd392260(WS.10).aspx

Welcome back to the 3^rd and final article in this series in installing and configuring your Remote Desktop Services in Windows 2008 R2, with the focus of today’s article around Remote Desktop (RD) Web Services (formerly referred to as TS Web Services) and utilising RemoteApp to publish applications to our RD Web Access web page and to the client desktop. For those that missed the previous 2 articles, you can access these from the links below;

1. Remote Desktop Services in Windows 2008 R2 -Part 1 – Installation
2. Remote Desktop Services in Windows 2008 R2 – Part 2 – RD Gateway

RD Web Access is a component within Remote Desktop Services in Windows Server 2008 R2 which provides your remote users with the ability to access network published applications via Internet Explorer over SSL or commonly referred to as HTTPS.  This type of access breaks all barriers and restrictions where traditional VPN’s were IPSEC based or L2TP and usually required special software to be installed on the client machine which in itself required special configuration.  Not only was it cumbersome and problematic to setup for the non IT savvy, it usually caused potential problems for remote workers that were connected behind restricted Internet connections that only opened up a limited number of ports, namely HTTP and HTTPS.  This is where SSL based VPN’s such as RD Gateway (introduced in part 2 of this series) and RD Web Access come into play.

To recap, we went through the process of installing the necessary components for Remote Desktop Services including the RD Session Host and RD Web Access role services in part 1 of this series, with today’s focus on completing and fine tuning the configuration of RD Web Access and then shifting our focus on publishing remote applications in the latter half of this post.

So let’s begin by confirming the operation of the RD Web Access role by navigating to Start / Administrative Tools / Remote Desktop Services / Remote Web Access Configuration.

Because we are running a self-signed certificate on the IIS web site you will receive the usual Internet Explorer Certificate warning. It’s safe for us to click on continue to this website.

The below RD Web Access login screen will appear. Enter your administrative network credentials and then click on sign in.

The configuration screen will be displayed in which you have the option to select a Remote Desktop (RD) Connection Broker server or specify individual RemoteApp sources.

Let me provide you with a primer on the RD Connection Broker Server. Recall this was installed back in part 1 of this series as one of the role services installed for Remote Desktop Services. Formerly known as TS Session Broker, RD Connection Broker provides enhancements and benefits to the users experiences when connecting to an RD Host Server and are accessing RemoteApp and or Remote Desktop connections. These are listed below;

• Support for load balancing amongst Remote Desktop Servers located within a single farm
• Support for seamless user reconnection with farm based setups
• A new feature in Windows 2008 R2 is the ability to combine RemoteApp sources from different Remote Desktop Session Host servers that may potentially be housing different RemoteApp programs for compatibility and segregation reasons.
• Also a new feature in Windows 2008 R2 is the Direct integration with the newly introduced Virtual Desktop Infrastructure (VDI) – (to be covered in a future post.)

Considering that this is a basic single server Remote Desktop Host setup, we do not require to setup the RD Connection Broker, but I will outline the steps for convenience if you decide to go down this path;

1. The RD Connection Broker role service is required to be installed on a server. This could be on any server located on your network and does not necessarily need to be installed on a server running the Remote Desktop Host server or any of the other Remote Desktop Services Roles.

2. Add the RD Session Host servers that you would like to aggregate in your farm setup to the Session Broker Computers local group which is located on the RD Connection Broker server. (screen capture below)

3. Navigate to Start / Administrative Tools / Remote Desktop Services / Remote Desktop Session Host Configuration and configure each RD Session Host Server that will participate in the farm to become a farm member in the RD Connection Broker. (highlighted below)

4. Lastly, you can utilise DNS round robin with the RD Connection Broker to provide load balancing. This is as simple as creating an addition A record in DNS to point each Remote Desktop Host Server that is participating in the farm to the farm name. The farm name is specified in the Remote Desktop Session Host Configuration and is common on all Remote Desktop Host Servers. Recall that this is located under Remote Desktop Session Host configuration / RD Connection Broker / Member of farm in RD Connection Broker’s properties.

The above steps have outlined the configuration of an RD Connection Broker server and the necessary steps required to configure your farm .  So going back to the RD Web Access Configuration screen we can either select “An RD Connection Broker server” as our source or individual RemoteApp sources (i.e. individual RD Host Servers).

As this is a single Remote Desktop Host setup, I will select one or more RemoteApp sources (which is selected by default), leave localhost as the source name as this is also our single  RD Host Server and click OK.

The web page will then redirect to the RemoteApp Programs screen which currently is not populated with any published applications …. but not for long.

This brings us to the second part of this article, Publishing RemoteApp Programs. Windows 2008 was the first version of Windows that provided us with the ability to publish individual applications to the Desktop and to TS Web Access or should we now say RD Web Access.

Quite simply, we can only publish applications that are installed on the Remote Desktop Host. Installing client applications on a Terminal Server is not the same as installing on a client computer and to ensure Remote Desktop compatibility it is best practice to still utilise the “Install Application on Remote Desktop” mini wizard provided. This is to ensure that our applications are installed utilising RD Install mode which configures the correct registry entries for a multi user Remote Desktop environment. You can also utilise Windows command prompt to achieve the same;

Change user / install – prior to running setup.exe of the application

Change user /execute  – after the application installation has completed.

For simplicity, you can access the wizard via Control Panel / Programs / Install Application on Remote Desktop.

This will initiate the wizard.

Click Next, complete the installation, and then click on Finish. Let’s install Office 2007 as our first client application on the Remote Desktop Host.

After installing Office 2007 utilising RD install mode, we now have our first application to publish to RD Web Access and to a Remote Computer desktop such as Windows 7. Lets start with the former first. Navigate to Start / Administrative Tools / Remote Desktop Services / Remote App Manager.

Under the Actions pane, click on Add RemoteApp Programs.

This will invoke the RemoteApp Wizard.

Click Next.

Choose the application that you would like to publish. I will select Microsoft Office Word 2007 in this example. Before clicking on next, let’s venture into the properties area as there is an enhancement made to Windows 2008 R2 over Windows 2008.

The first tab (properties) as you will see is identical to that provided in Windows 2008 with the ability to change the icon, provide additional command line arguments and a checkbox allowing us to make this published application available through RD Web Access.

The second tab (User Assignment) is new and a welcome enhancement to Windows 2008 R2 allowing us to specify users and or groups whom you want the published application to be visible to.

I will keep All authenticated domain users ticked and click OK.

Click Next to proceed with the wizard.

You will then be presented with the below summary of settings.

Click Finish.

We have now published our first RemoteApp to RD Web Access.

If I now navigate to the RD Web Access URL from any internal client computer, usually in the form of  https://servername/RDweb and login, our Microsoft Office 2007 icon will now be listed providing us with the ability to now launch published application singularly via a secure web interface.

In addition to publishing RemoteApp Programs to RD Web Access, we  are also provided with the ability to publish applications via a Windows Installer Package or via the creation of an .rdp file which both can be assigned to Remote Computers running Windows 7 etc.

Quite simply, right click on the Microsoft Office Word 2007 under RemoteApp Programs within RemoteApp Manager and select either Create .rdp File or Create Windows Installer Package. You can also initiate both wizards under Actions on the right navigation pane. Both have advantages and disadvantages with the .rdp file providing you with flexibility in the distribution method in deploying applications to remote users by providing them with a single .rdp file, whereas the Windows Installer Package is more geared towards Group Policy Software installation with added benefits in specifying shortcuts locations such as specifying that the shortcut icon will appear on client computers Desktop or Start Menu Folder.

This ends the series on Remote Desktop Services. This is by no means an exhaustive complex setup but it gives you a taste of what is possible with the technology and how far it has come since the early days of Windows NT. Every setup will be different and even though I have installed all of the roles on a single server, depending on the size of your organization and deployment these can be easily split across multiple servers with farm configurations and so forth to accommodate for larger number of users.

This article has not gone into great depth or detail with regards to securing your RD Gateway and RD Web Access with trusted 3rd Party Certification Authority Certificates such as those provided by GoDaddy and Verisign, nor have we discussed potentially publishing both RD Web Access and RD Gateway using a reverse proxy firewall such as Microsoft’s Internet and Acceleration Server (ISA) 2006 and the recently announced Forefront Threat Management Gateway (TMG).  Expect to see future articles on this topic.

Well, I hope you enjoyed this series and please feel free to comment about your experiences or questions you may have.  As always, you can follow me on Twitter and or subscribe to my feed.

Resources

Remote Desktop Connection Broker- What’s New; http://technet.microsoft.com/en-us/library/dd560675(WS.10).aspx
Remote Desktop Connection Broker; http://technet.microsoft.com/en-us/library/cc771419.aspx
Remote Desktop Web Access; http://technet.microsoft.com/en-us/library/cc731923.aspx
RemoteApp and Desktop Connection – What’s New; http://technet.microsoft.com/en-us/library/dd560650(WS.10).aspx
RemoteApp Manager; http://technet.microsoft.com/en-us/library/cc755261.aspx

____________________________________

Articles in this series;

1. Remote Desktop Services in Windows 2008 R2 -Part 1 – Installation
2. Remote Desktop Services in Windows 2008 R2 – Part 2 – RD Gateway
3. Remote Desktop Services in Windows 2008 R2 – Part 3 – RD Web Access & RemoteApp

Welcome to the second article in this series on Remote Desktop Services in Windows 2008 R2.  We were first introduced to the Remote Desktop (RD) Gateway in the first release of Windows 2008 and as previously mentioned in part 1 of this series, the RD Gateway was formerly known as Terminal Server (TS) Gateway.  TS Gateway opened up Remote Access barriers providing access to our Terminal Servers via SSL or port 443, as opposed to the conventional “legacy” VPN access through either IPSEC or L2TP. In Windows Server 2008 R2, not much has changed and in today’s article I will provide you with a step by step guide on configuring your RD Gateway which will provide your remote users access to the Remote Desktop Host or RD Web Access via any Internet connection utilising Remote Desktop Connection client over HTTPS.  If you missed part 1 of this series which discussed the installation of your Remote Desktop Role and services, you can access it here.

There are a number of prerequisites that are required in order for the RD Gateway to function and these were all setup in part 1 of this series. For reference I have listed these below;

• Remote procedure call (RPC) over HTTP Proxy
• Internet Information Services

Let’s begin by navigating to All Programs / Administrative Tools / Remote Desktop Services / Remote Desktop Gateway Manager. You will be presented with the below screen.

In the left navigation pane of your RD Gateway Manager MMC console, click on your server and select properties under Actions. We will now go through each tab under the server properties and make any necessary configuration changes.  Let’s refer to this process as post wizard configuration.

Under the General Tab, we are provided with the ability to configure the maximum number of connections that are allowed to connect to this RD Gateway. If you are concerned with server performance, we can set a hard limit of allowed simultaneous connections. We can also disable new connections if we are performing scheduled maintenance on our server.

The next tab allows us to secure the RD Gateway by using an SSL certificate.  We can create a self-signed certificate (recall that this was completed during the initial install wizard in part 1 of this series), select an existing certificate that is located on the server under Certificates / Personal store or Import a certificate that we have requested via a 3^rd Party Certification Authority (CA) or utilising an internal CA. It is deemed best practice to utilise a 3^rd party CA that participates in the Microsoft Root Certification Members Programme alleviating the headache that is usually involved in exporting the root certificate, distributing them to your end users and then providing them with instructions on how to import them into their local machines. Utilising a self-signed certificate is usually reserved for testing purposes only, and not in a production environment, however it will suffice in this step by step guide.

The third tab introduces the RD CAP Store and provides us with the ability to utilise our local server running Network Policy Server (NPS) or the ability to specify a central server that is already configured and running NPS.  This was also initially configured during the installation wizard of our Remote Desktop Services role in part 1.

The next tab, Server Farm, allows us to specify farm members for the RD Gateway. As a minimum we need to Add this RD Gateway server below as follows.  You do so by entering the fully qualified domain name of the server and clicking on Add.  It will then add it below under Remote Desktop Gateway server farm status as per the below screen capture.

You will notice the above warning regarding the registry not being updated. This warning will disappear and the status will change to OK after clicking on Apply.

The next tab allows you to select or deselect events that you would wish to log. These corresponding events are stored in Event Viewer under Application and Services Logs\Microsoft\Windows\Terminal Services-Gateway\.  By default, all items under the Auditing tab are selected to be captured and logged.  The below screen capture is an example of the TerminalServices – Gateway Event Viewer on our Windows 2008 R2 server.

SSL bridging is next and is required to be configured if you are utilizing Microsoft ISA Server to further secure the RD Gateway.  Microsoft ISA Server is a great application level firewall which offers reverse proxy and can be configured to work hand in hand in providing secure access over SSL.

The last tab in the RD Gateway properties is Messaging which was not present in Windows 2008 TS Gateway. This is a welcome addition for administrators to utilise when pre-planning for system maintenance and wanting to advise users with a global system notification, and the also providing the ability to set a logon message such as the company’s logon policy.

The first area within the Messaging tab is the ability to set a timed system message with the ability to set a start date/time and end date/time.

When a user logs in via the RD Gateway, they will be presented with the following message that we configured above;

The second area under messaging allows you to specify a message such as your company’s logon policy that will appear each time a user logs into the RD Gateway remote computer. This is simply a text file with the contents within.

The below similar notice is what will appear when logging on to your Remote Desktop Host via the RD Gateway

You will notice that the system will not continue to login (the OK button is dimmed) unless you accept the terms of this policy.

The last option allows you to specify that connections to the Remote Desktop Host via the RD Gateway will be restricted to clients that support RD Gateway messaging which is anything greater than Remote Desktop Client version 7.

Now prior to connecting to the RD Gateway and testing our setup, we will need to export the self-signed SSL certificate located on the RD Gateway and install it on our client computer that we will be connecting from. The easiest way to accomplish this is to open the Certificates MMC snap-in, locate the certificate from the Personal / Certificates store, and right click, All Tasks / Export.

This will invoke the below Certificate Export Wizard.

Click Next

Select Yes, export the private key.

Click Next.

Select, Include all certificates in the certificate path if possible

Click Next. Type and confirm a password and then click Next again.

Specify a name and location to export the pfx certificate file.

Click Next and then Finish.

We can now copy or email the exported certificate to our end users who will then install the certificate to their local personal store. This can be easily achieved by double clicking on the exported certificate and invoking the Certificate Import Wizard. Please ensure that when you come to the Certificate Store section of the Import Wizard that you select “Place all certificates in the following store” and select “Trusted Root Certification Authorities”.

Now that we have successfully imported the root self signed certificate authority, we can now test our setup and login to our remote computer via the RD Gateway. Before we begin, you need to ensure that you are running the latest Remote Desktop Connection client which is version 7. This version is already included with Windows 7 and is made available for download to Windows Vista SP1 and SP2 clients and to Windows XP SP3 clients. This can be downloaded from the Microsoft Support site; http://support.microsoft.com/kb/969084

The above article also provides you with a comprehensive list of new features and their explanations that are only possible with RDC 7 and Windows 2008 R2.  I have listed these below for convenience;

• Web Single Sign-On (SSO) and Web forms-based authentication
• Access to personal virtual desktops by using RD Connection Broker
• Access to virtual desktop pools by using RD Connection Broker
• Status & disconnect system tray icon
• RD Gateway-based device redirection enforcement
• RD Gateway system and logon messages
• RD Gateway background authorization & authentication
• NAP remediation with RD Gateway
• Windows Media Player redirection
• Bidirectional audio
• Multiple monitor support
• Enhanced video playback

From a client machine running RDC 7, navigate to Start / All Programs / Accessories / Remote Desktop Connection or just search for mstsc.

Click Options and then navigate to the advanced tab.

Click Settings and then select Use these RD Gateway server settings:

Enter your server name and logon method details as follows;

Then click OK. Ensure that Bypass RD Gateway server for local addresses is deselected. Navigate back to the General Tab and enter the Computer and User name details and then click Connect when ready.

The following Windows Security popup will appear asking you to authenticate prior to launching a full remote desktop session.

After entering your credentials and clicking OK, You will be prompted to accept the login policy that we specified earlier under the Messaging tab of the RD Gateway properties.

So that’s it, we are now logged in to the Remote Desktop Host via the RD Gateway. We can confirm this by clicking on the spanner located on the top toolbar which will output the Remote Computer and Gateway Server that we are connected to. It also states that the connection to the remote computer was made using a Remote Desktop Gateway server.

That’s it for now. In our next and final article I will discuss Remote Desktop (RD) Web Access and the publishing of Remote Desktop Applications, so stay tuned.

_________________________________________

Articles in this series;

1. Remote Desktop Services in Windows 2008 R2 -Part 1 , Installation and Configuration
2. Remote Desktop Services in Windows 2008 R2 – Part 2 – RD Gateway
3. Remote Desktop Services in Windows 2008 R2 – Part 3 – RD Web Access & RemoteApp

Windows Terminal Services has come a long way since its infancy and has improved with every version of Windows, and Windows 2008 R2 is no exception.  There are even noticeable differences between Windows 2008 and Windows 2008 R2 and should be highly considered as a worthy upgrade for those currently running older versions of the Windows component.  I first began working with Terminal Server technologies back in the day of WinFrame which was a “special” version of Windows NT 3.5.1 that was developed by Citrix.  Since then I have worked with all versions of Terminal Server from NT4 to the most recent Windows 2008 R2 which I am excited about.

This 3 part series will consist of the following articles and will provide you with step by step instructions in getting most of your Remote Desktop infrastructure in place;

• Part 1 – Installation of Remote Desktop Services
• Part 2 – Configuration of Remote Desktop Gateway and Remote Desktop Client
• Part 3 – Configuration of Remote Desktop Web Access

In Windows 2008 R2, Terminal Server and its underlying components is now referred to as Remote Desktop Services (RDS).  The below table is a snippet directly from TechNet outlining the renaming of Terminal Server and it’s services;

Before delving into the step by step guide I will quickly highlight some of the enhancements and improvements that have been incorporated in this release;  This is by no means a comprehensive list, however I have provided a number of links at the end of this post to TechNet articles outlining What’s New in RDS.

• Windows Server 2008 R2 is 64 bit only, meaning that RDS is also 64 bit.
• Forms based authentication for Remote Desktop Web Access
• Per user RemoteApp program filtering
• Enhancements to Remote Desktop Client experience such as multiple monitor support, Audio recording redirection and Audio and Video playback
• Windows Installer compatibility
• Introduction of Remote Desktop Virtualisation Host providing personal virtual desktops utilising Hyper-V (note: This technology will not be discussed in this series, however I will have a future post dedicated to this new inclusion)

So let’s begin the installation by Navigating to Start / Administrative Tools / Server Manager (This post is assuming that you already have a dedicated Windows 2008 R2 server setup)

Click on Roles located on the left navigation pane and then select Add Roles located on the right pane to invoke the Add Roles Wizard.

Click Next

Select Remote Desktop Services as the role to install on this server.

Click Next.

The below introduction to Remote Desktop Services is displayed. Microsoft have done a great job in providing administrators with thorough documentation pertaining to the role being installed.

Click Next

This is a single server setup so I will select all of the role services for Remote Desktop Services excluding Remote Desktop Virtualisation Host (this will be covered in a future post). I have provided Microsoft’s description of each service in the table below;

Adding the Remote Desktop Gateway and or Remote Desktop Web Access will prompt you to install other services that are prerequisites such as IIS.

Click Add Required Role Services

After you have the Selected Roles checked, click Next.

The below warning will appear advising that it is recommended to install the Remote Desktop Session Host prior to installing any “client” applications.

Because this is a new install of Windows 2008 R2, I can ignore this warning and click Next.

You will now be required to specify an Authentication Method for the Remote Desktop Session Host. The two options provided below are as follows;

Require Network Level Authentication: This is more secure as user authentication occurs before a full remote desktop session is established, however it is only supported by Remote Desktop Client 6 and greater running on Windows Vista or Windows XP SP3 (Windows 7 is equipped with Remote Desktop Client 7) as they are the only current operating systems that support Credential Security Support Provider (CredSSP) protocol. Please be aware that the CredSSP is turned off by default on Windows XP SP3 and must be turned on via the registry. Please refer to the following Microsoft KB article for more details http://support.microsoft.com/kb/951608

Do not require Network Level Authentication: This is less secure because authentication occurs later in the connection process, however is supported by all Remote Desktop clients and all versions of Windows.

More information can be found in the following TechNet article, Configure Network Level Authentication for Remote Desktop Services Connections; http://technet.microsoft.com/en-us/library/cc732713.aspx

We will select Require Network Level Authentication.

Click Next.

Specify your Licensing Mode

Click Next

You will then be prompted to select user groups that you would like to provide access to the Remote Session Host Server. By Default, the “Administrators” group is added and I will also be adding a security group that I have created specifically for my Remote Desktop Users. Users or User groups added in this section will be automatically added to the local Remote Desktop Users group.

Click Next

The next screen will allow you to configure the client experience providing your end users with similar functionality and visual experience found from a Windows 7 desktop.

I will be selecting all 3 options provided, with one of the enhancements to Remote Desktop Services in R2 being the ability to provide users with a much better Video playback experience than in previous releases. It does so by offloading the actual video playback to the local graphics processing unit. More information on Multimedia Redirection Improvements in Windows 7 and WS2008 R2 can be found here; http://blogs.msdn.com/rds/archive/2009/07/24/multimedia-redirection-improvements-in-windows-7-and-ws2008-r2-part-1.aspx

Click Next

The next screen provides you with the ability to configure discovery scope for RD licensing. Following Microsoft’s recommendation, I will not configure a discovery scope for the license server and will utilise the inbuilt RDS Host configuration tool instead.

Click Next

The next screen is requesting a server authentication certificate for SSL encryption. To simplify matters during the installation I will select create a self-signed certificate for SSL encryption and will discuss this in more detail in part 2 of this series.  Note that using a self-signed certificate will create additional administrative overhead for administrators as the certificate will need to be exported and imported to your remote desktop client computers.  Using a 3rd party certificate from a Trusted certificate authority will remove that administrative burden and provide end users with a seamless experience.

Click Next

The next screen introduces Authorisation policies for the RD Gateway. Recall, the RD Gateway is designed to provide users with the ability to log onto a Remote Desktop Host via the Internet and SSL. Windows 2008 first introduced the TS Gateway which incorporated 2 types of policies TS CAP and TS RAP. These have been superseded in Windows 2008 R2 with; you guessed it, RD CAP and RD RAP.

Here is a brief primer on the two;

RD CAP (Remote Desktop Connection Authorisation Policy): Here you will specify users and groups who will have the ability to connect to a Remote Desktop Gateway Server. With an RD CAP you can also specify conditions for specific users and groups such as, you can only connect to this RD Gateway if you are using a smart card.

RD RAP (Remote Desktop Resource Authorisation Policy): After providing users and groups the ability to authenticate with an RD Gateway, RD RAP provides you with the ability to specify which computers located in the internal network are accessible to your user groups.  This could be restricted to a number of Remote Desktop Servers depending on the user or group authenticating.

Add your users and groups that you would like to connect through the RD Gateway as per the below screen capture.

The next part of the wizard is all about creating your RD CAP and RD RAP. Don’t worry too much if you don’t get everything right in the wizard as all of these options are configurable post wizard installation.

Notice, I have created a specific Active Directory Group called “Remote Desktop Computers” in which I have added computers with Remote Desktop enabled.

Click Next

The next part of this wizard provides you with a primer on Network Policy and Access Services.

Click Next

Leave Network Policy Server selected….

Click Next

The following screen provides you with an introduction to the Web Server Role that is required to be installed for Remote Desktop Web Access.

Click Next and Next again to accept the default role services options.

We are finally presented with a summary of the confirmed installation selections that we have made throughout this wizard. It is worthwhile printing and or saving this information via the available hyperlink to form part of your documentation.  Kudos to Microsoft who in my own opinion have done a great job with their wizard based installations which eases the usual configuration pains associated with such an install.

Click Install. The installation process will now begin and you will be presented with the installation results screen below notifying you of completion. Click Close and then restart your server to complete the process.

Upon shutdown, restart and logon, Windows will proceed with the installation and configuration of our roles and services.

That’s it for now.  In this first article of this series on RDS, we went through the process of adding and configuring the necessary roles and services associated with Remote Desktop Services via  Windows 2008 R2 Server manager.  In the next article, I will be discussing the Remote Desktop Gateway (RD Gateway) in some detail and will go through some of it’s configuration settings both at the server and remote desktop client level.

____________________________________________________

What’s New – TechNet Resources

Remote Desktop Session Host; http://technet.microsoft.com/en-us/library/dd560667(WS.10).aspx
Remote Desktop Virtualisation Host; http://technet.microsoft.com/en-us/library/dd560648(WS.10).aspx
Remote Desktop Connection Broker; http://technet.microsoft.com/en-us/library/dd560675(WS.10).aspx
Remote Desktop Web Access; http://technet.microsoft.com/en-us/library/dd560668(WS.10).aspx
Remote Desktop Gateway; http://technet.microsoft.com/en-us/library/dd560672(WS.10).aspx
RemoteApp  And Desktop Connection; http://technet.microsoft.com/en-us/library/dd560650(WS.10).aspx
Remote Desktop Licensing; http://technet.microsoft.com/en-us/library/dd560655(WS.10).aspx
Remote Desktop Client Experience; http://technet.microsoft.com/en-us/library/dd560636(WS.10).aspx

Remote Desktop Services Management; http://technet.microsoft.com/en-us/library/dd939782(WS.10).aspx
__________________________________________

Articles in this series;

1. Remote Desktop Services in Windows 2008 R2 -Part 1 , Installation and Configuration
2. Remote Desktop Services in Windows 2008 R2 – Part 2 – RD Gateway
3. Remote Desktop Services in Windows 2008 R2 – Part 3 – RD Web Access & RemoteApp

Windows 7 was just recently released to the General Public and has been in the hands of TechNet and MSDN subscribers for a while before that, and one of the features that I have been utilising lately is “XP Mode” which is a glorified version of Virtual PC as we have known it in previous releases.  Windows Virtual PC for Windows 7 (not to be confused with Windows Virtual PC 2007) is actually one of two pre-requisites for XP mode with the other being “Hardware-assisted virtualization (HAV)”.  HAV are processors with the Intel VT, AMD-V or VIA VT feature which will need to be enabled in the conputer BIOS.

A couple of enhancements of XP mode and Windows Virtual PC for Windows 7 over legacy Virtual PC 2007 include the ability to run XP compatible applications in what other desktop virtualisation vendors refer to as “unity” mode,  i.e. the ability to launch applications directly from the Windows 7 start menu that are actually installed on the XP virtual machine itself. The second enhancement to Windows Virtual PC for Windows 7 is the ability to utilise HAV to increase performance of your virtual machine which I have been impressed with to date.

As much as we would like to run an application on Windows 7 natively we know that this may not be feasible as there will always be legacy applications that may not work natively with newer operating systems.  Windows “XP mode” is dubbed as the last resort in assisting organisations in migrating to the latest and greatest operating system to date.

So let’s begin the setup by first downloading an Intel utility which will check if the computer processor supports HAV and if this setting is enabled.  You can download this utility from the Intel site here; http://www.intel.com/support/processors/tools/piu/

The utility when launch will look like the below;

Click on the CPU Technologies tab.  Note that in this case the Intel Virtualisation Technology is already enabled.

If you have an AMD processor then you will need to download the AMD Virtualization Technology and Microsoft Hyper-V System Compatibility Check Utility here; http://www.amd.com/us-en/assets/content_type/utilities/AMD-V_Hyper-V_Compatibility_Check_Utility.zip

Microsoft have also released their own detection tool since XP Mode was released to manufacturing and can be downloaded from here; http://www.microsoft.com/downloads/details.aspx?FamilyID=0ee2a17f-8538-4619-8d1c-05d27e11adb2&displaylang=en

This tool is a lot simpler and will look similar to the below when launched;

Please be aware that in some cases you may need to enable HAV from within the computer BIOS.  Now that we have HAV in check we can proceed with the setup of XP Mode on our Windows 7 machine.

The next step is to install Windows Virtual PC  which you will need to download first from the Microsoft site here; http://www.microsoft.com/windows/virtual-pc/download.aspx

Begin by launching the executable.

Click Yes.

Accept the license terms.

Click Restart Now to finalise the installation of Windows Virtual PC for Windows 7.

The second installation that is required is Windows XP Mode.  This can also be downloaded from the Microsoft site here; http://www.microsoft.com/windows/virtual-pc/download.aspx (Follow steps 1-3)

Click Next.

Select your location and click Next.

Click Finish to finalise the setup.

We are now ready to launch Windows XP mode for the first time in which it will begin a “one time” configuration process setting up our virtual machine.

We can do so by navigating to the Windows XP Mode shortcut. From the Start menu, click Windows Virtual PC, and then click Windows XP Mode.

Accept the license terms and click next.

Please note that if your machine is not HAV compatible or has not been enabled for HAV you will receive the following error message;

“Unable to start Windows Virtual PC because hardware-assisted virtualization is disabled”

Continuing on with our installation of XP mode you will be prompted for the installation folder and the “XPMUser” password.  This “system created” user is used to log into the Virtual Machine automatically when booted up and run the installation applications within in.

Click Next

Select “Help protect my computer by turning on Automatic Updates now”

Click Next

Click Start Setup.

Setup will begin installing Windows XP with SP3 with the end product looking similar to the below screen capture;

The new virtual machine is now ready for you to customize it by installing the applications you want to use. After you install the applications, you can open them directly from the Start menu of your Windows 7 host operating system as per the below screen capture.  As this is considered as another machine that is connected to the network via NAT (default), I would ensure that the latest Windows Updates are installed and that an antivirus package is also installed to keep the machine secure and clean.

Hope you have found this article useful.  In summary, the setting up of Windows XP Mode consists of  three parts.  The first part installs Windows Virtual PC for Windows 7 with the second part installing Windows XP Mode on the computer. The third and final part to the jigsaw is always required. It sets up a virtual instance of Windows XP Professional with Service Pack 3 (SP3) as a virtual machine, allowing you to install your legacy applications that can then be accessed via your Windows 7 start menu.

Don’t forget to subscribe to future articles via your RSS reader and follow me on twitter @georgekhalil.

Welcome to the final article in this series on Windows Deployment Services, WAIK and Windows 7.  Our first articled introduced WDS and its configuration with parts 2 and 3 focusing on our beloved WAIK tool and Windows System Image Manager and the creation of our XML answer files.  We conclude the series by introducing one of the enhanced features in WDS and Windows 2008 and that’s the ability to inject driver packages and have them deployed to our client computers along with the install image.  Note that this functionality is only available when you are installing images of the following operating systems: Windows Vista with SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

I have on purposely left this discussion to the end in order to determine what driver packages need to be added to the WDS server and this could only be determined after deploying our first Windows 7 Image via WDS to our various hardware.  After the initial deployment I would log onto the machine and launch the Device Manager MMC and see what devices were not detected by the Windows 7 install.  From experience, these will primarily be audio and/or video drivers that you will need to download from the manufacturers support site.  Since Windows 7 has just been released into the market, many vendors such as Dell and HP may not have released Windows 7 certified drivers for their older fleet, however I have found that Windows Vista drivers are compatible in most instances.  So let’s begin the process!

My Windows 7 install image was deployed to a Dell Latitude D630 in which Window 7 did not detect the video adapter so I went forth and downloaded the latest “Vista” drivers from the Dell support site. The Dell drivers are wrapped in a nice executable for installation, however because we are injecting these drivers via WDS we need to extract the contents of the executable which will contain the .inf file that describes the package.  The .inf file includes a list of the files that make up the package (and their locations), and is included with the driver installation program. Generally, the .inf file is located on the driver installation media in the same folder as the Setup program, or in a subfolder.

We can easily extract these via WinRAR by right clicking on the executable and selecting Extract to <foldername>.

Once we have these files extracted we can proceed and add the driver package via WDS, so let’s navigate to the WDS Management console and right click on drivers and select “add driver package”

Browse for the .inf file that we extracted earlier via WinRAR and click Next.

Double click on the package details and click on the second tab “Drivers” to confirm that the correct drivers are being distributed.

Continuing will then proceed and add the driver package as per the below screenshot.

We will not place the “driver packages in a driver group” at this time and we will not  “Modify the filters for this group now.”

We can now click on Finish to complete the Task.

We will now follow the instructions as per the above screen capture and invoke the “Add Driver Group Wizard” by right clicking on the Drivers node.  Type a name for this driver group similar to the below screen capture.  In most instances you will create driver groups for different makes and models.

Click Next.  Now click add to select a filter type.  I will be creating a filter based on manufacturer as listed in the BIOS.

You can find this information on the client computer using the System Information tool (Msinfo32.exe). To open this tool, click Start, click Run, type msinfo32.exe, and then click OK. This value is listed as the System Manufacturer.

Click on Add

Now that you have located the Manufacturer you can add the parameter as per the below screen shot.

You also have the ability to be specific with regards to applying these drivers based on the selected install image.  Because I only have the single Windows 7 install image I will leave this filter blank and continue.

Leave the default option of “Install only the driver packages that match a client’s hardware”.

Click Next.

That’s all that is to it.  The next time you deploy an Install Image that meets the BIOS manufacturer’s parameter it will inject the necessary drivers for Windows to freely use.  It sure beats the legacy method of creating $oem$ folders etc and hoping that the drivers are correct.  As you can see, WDS in Windows 2008 R2 simplifies matters dramatically and the driver validation process is comforting to an IT Pro, ensuring that you have the correct drivers selected.

This comes to the conclusion to our 4 part series in which I hope you have enjoyed.  Don’t forget to subscribe to future articles via your RSS reader and follow me on twitter @georgekhalil.

________________________________________________

Articles in this series

1. Windows Deployment Services, WAIK & Windows 7 – Part 1/4 (Installation and Configuration of the WDS Role)
2. Windows Deployment Services, WAIK & Windows 7 – Part 2/4 (Creation & Configuration of WDSUnattend.xml)
3. Windows Deployment Services, WAIK & Windows 7 – Part 3/4 (Creation & Configuration of ImageUnattend.xml)
4. Windows Deployment Services, WAIK & Windows 7 – Part 4/4 (Injecting Drivers)

We are back again and in today’s article we will continue our efforts in automating our Windows 7 deployment via Windows Deployment Services utilising the WAIK tool and the creation of our XML Answer files.  In Part 2 of this series we focused on the creation of the WDSUnattend.xml file that is required to automate the Windows Pre Execution Boot for our WDS clients and took care of the partitioning of our disks.  If you missed part 2 of this series, you can access it here. Today we continue our efforts in utilising the Windows System Image Manager (WSIM) to create our ImageUnattend.xml which will be specifically designed to automate the Out of Box Experience (OOBE) of our Windows 7 Enterprise install.

In our last article I introduced WSIM and the steps required to create an answer file.  I also went into some detail regarding the 7 distinct sections that make up an answer file that reflect the 7 possible stages in the deployment of your operating system, in our case Windows 7.  As you recall these stages are referred to as Passes and you may not necessarily need to utilise every single pass in an XML Answer File.  Our WDSUnattend.xml file that we created in Part 2 primarily focused on the windowsPE pass however our ImageUnattend.xml that we are creating in this article will utilise the specialize and oobeSystem passes.  So let’s begin!

Launch WSIM and select File / New Answer File.  The first area that we will focus on is the specialize pass which we will provide details for the automation of the joining of the machine to the domain.

The minimum components and passes required for our ImageUnattend.xml are listed as follows;

As a refresher, I will go through the process of adding our first component (Microsoft-Windows-Shell-Setup) to our Answer File Pane and it’s required settings.  Recall that I went through this process in some detail in part 2 of this series.

Right click on the required component and select Add Setting to Pass4 specialize.

This will then appear in the Answer File pane as follows;

We will make the following changes to the properties of the Microsoft-Windows-Shell-Setup component as per the below screen capture.  You will notice that in the ComputerName section I have specified “*” as I am letting WDS do the naming under the AD DS tab of the properties of the WDS server.

In the below screen capture, I have specified a Client Naming Policy under the properties of our WDS server.  The following format GK%03# will name my machines in the following format; GK001, GK002, GK003 etc.

I have listed the rest of the settings in text form for the components listed in the table above.  These are as follows;

In summary, the oobeSystem settings above (Windows Out of Box Experience) automates the initial configuration tasks that end users normally encounter when installing Windows 7 or Windows Vista.

The above settings are the required minimum settings to fully automate the Windows 7 Enterprise “install” image, however you can add other components such as setting a default theme (Microsoft-Windows-Shell-Setup\Themes).

The complete Unattended Windows Setup Reference can be found in the WAIK help area and on the Microsoft TechNet Site here.

Once you have completed adding any further settings to your ImageUnattend.xml file you will need to validate your settings and then save the file as “ImageUnattend.xml”.

We will now navigate to your WDS server and launch the Windows Deployment Services Management Console.  Expand Servers and then your Server Name and  click on Install Images.  Our Windows 7 Install Image should be listed as per the below screen capture.  Recall that this was added in Part 1 of this series when we first configured our WDS Server.

Right Click on our Image and select properties.  Under the General Tab, click on select file and browse for the ImageUnattend.xml file that we saved earlier.

We have now applied our WDSUnattend.xml which automates the WDS Pre-Execution Boot (part 2 of this series) and our ImageUnattend.xml which automates the OOBE of our Windows 7 “install” image.

Now is a good time to review your WDS Server settings within the Windows Deployment Services Management console by right clicking on the server and selecting properties.  Under the AD DS tab you can specify your Client Naming Policy and specify your Computer Account Location.  Also ensure that your WDSUnattend.xml file that we created in part 2 is applied to the Client tab – Unattend file settings area.

We are now ready to rock and roll and attempt to deploy our first Windows 7 Image via PXE boot.  When your machine is starting up press the relevant Function key combination to access the network PXE boot which should then detect your WDS Server and then press F12 again to launch the Windows PE Boot Image.

Once the boot.wim has completed loading, you will receive the below screen capture, allowing you to select your Windows 7 Install Image. If you have multiple Install Images they will also be listed here.

Click Next.

That’s it!  Your installation will now continue without any user input as this is taken care of by our ImageUnattend.xml file.

This concludes this part of the series.  In our next and final article I will show you how to inject any necessary drivers that may have been missed by Windows.  I have left this to the end as it is only until you deploy your first Image to your new or existing hardware that you will be aware of these missing drivers.

As always, if you would like to be notified of future articles, you can do so by subscribing via RSS, or have articles directly sent to your email by subscribing on the right navigation bar.

________________________________________________

Articles in this series

1. Windows Deployment Services, WAIK & Windows 7 – Part 1/4 (Installation and Configuration of the WDS Role)
2. Windows Deployment Services, WAIK & Windows 7 – Part 2/4 (Creation & Configuration of WDSUnattend.xml)
3. Windows Deployment Services, WAIK & Windows 7 – Part 3/4 (Creation & Configuration of ImageUnattend.xml)
4. Windows Deployment Services, WAIK & Windows 7 – Part 4/4 (Injecting Drivers)

Welcome back to the second part of this series and in the next 2 article’s I will be focusing our efforts on creating the necessary xml answer files to automate the deployment of our Windows 7 image via Windows Deployment Services (WDS).   In part 1, I provided you with step by step instructions on installing and configuring your WDS role on your Windows 2008 R2 machine. If you missed it, you can access part 1 here. Our focus in today’s article revolves around the creation of the WDSUnattend.xml file that is required to automate the Windows Pre Execution Boot for WDS clients.

Our tool of trade for today is the Windows Automated Installation Kit (commonly referred to as the WAIK or Windows AIK), and this was first introduced by Microsoft when Windows Vista was released for IT professionals assisting them with the deployment of Windows Vista.  It’s primary focus is to create the necessary answer files to deploy and customise the Windows install image and to also automate the WDS side of things or what is commonly referred to as windowsPE, more on this later.  Windows System Image Manager (also referred to as Windows SIM) is the actual tool required to create the XML answer files and is part of the WAIK.

The first thing you need to do is download the WAIK for Windows 7 which is quite a hefty download (1706.6MB) and can be accessed from the Microsoft Download site here.  Included in the WAIK as mentioned already is the Windows System Image Manager (WSIM) amongst other tools such as documentation, the Deployment Imaging Servicing and Management Tool (DISM), the User State Migration Tool (USMT) and the Volume Activation Management Tool (VAMT).

Once you have downloaded the WAIK ISO you can easily burn the disc image using Windows 7 Disc Image burner and then install the entire package on your “technician computer”.  Typically the technician computer is another PC that must be running Windows 2003, Windows Vista or Windows 7.  The below welcome splash screen is what you will see when you begin the installer.

Click on Windows AIK setup to begin the installation.

Click Next

Agree to the terms and then click Next.  The installation is pretty straight forward after this point.  Once the installation has completed you can then launch the Windows System Image Manager application which is located under the Microsoft Windows AIK All Programs folder.

We will now need to create our working folder and copy the install.wim from our Windows 7 source media, typically I will create a folder on the technician PC and call it Windows AIK Distribution Share.

Once we have created our folder and copied across our install.wim we can now proceed to open our image via Windows System Image Manager, File / Select Windows Image.  Browse to the Windows AIK Distribution Share that we created and select the install.wim file.  At this instance you will receive the below warning in which we will click Yes.

It will now proceed and create the catalog file that is required.  This process can take a while and will only need to be completed once.  Please note, If the WIM file contains multiple images then you must select the image to open from the WIM file (e.g., Windows 7 BUSINESS or Windows 7 ENTERPRISE).

Upon completion, your catalog will be created and the components and packages will be listed under the Windows Image pane located on the left hand corner of WSIM.

We can now proceed to create our first answer file by clicking on File / New Answer File.

You can see that the Answer File can potentially be made up of 7 distinct sections as per the above screen capture.  These are 7 possible stages in the deployment of your operating system whether it be Windows Vista, Windows 7 or Windows 2008.  These stages are also referred to as passes and you may not necessarily need to utilise every single pass.  Because we are utilising WDS for our deployment of Windows 7, we will be required to create 2 XML Answer files using WSIM and these will be named as follows;

• WDSUnattend.xml (This will automate the windowsPE which encompasses the login to our WDS server, the creation of our partitions, selecting the partition to install Windows 7, and the language to run setup in.  The WDSUnattend.xml is eventually attached to the Client Tab of the properties of your WDS server.)
• ImageUnattend.xml (This will primarily automate the Out of Box Experience (OOBE) of your Windows 7 Install Image.  These are the screens that you would normally fill out after the first boot of your system, such as the creation of a local user account.  The ImageUnattend.xml is eventually attached to the General Tab of the Image Properties in WDS).

So let’s begins with WDSUnattend.xml.  Part 3 will discuss the ImageUnattend.xml in a lot more detail so stay tune for that article.

Now that we have created our Answer File albeit a blank canvas we need to inject the various components for our WDSUnattend.xml.  You do so by expanding the components under the Windows Image pane and then right clicking on the required component and inserting the relevant Pass to our Answer File.  At first sight this may seem to be very daunting as there are so many components that need to be matched off to the correct Pass.

The Components and Passes required for our WDSUnattend.xml are as follows;

Please note that when expanding the components list, ensure that you expand the component to the lowest level before adding the setting to the relevant Pass.  This ensures that the selected setting and all its parent settings are also added to the answer file in the single step.

Our first component required is the “Microsoft Windows International Core-WinPE”.

As per Microsoft’s documentation, Windows Preinstallation Environment (commonly known as Windows PE) is referred to as a minimal operating system designed to prepare a computer for Windows installation. It can be used to:

• Start a computer with no operating system (a bare-metal system)
• Partition and format hard drives
• Copy disk images or initiate Windows Setup from a network share

We will be automating the WindowsPE via the WDSUnattend.xml Answer File that we are just about to create.

I will begin by locating  our first component Microsoft-Windows-International-Core-WinPE\SetupUILanguage as per the below screen capture and right click and select the appropriate Pass.  As you can see the only Pass available to me is “windowsPE” and by selecting this pass it will add the component to my answer file under the Answer File navigation pane.

We can now fill in the details of the component that we have just added on the right navigation pane.  In the example below I have specified the InputLocale, SystemLocale and UserLocale to be "en-AU" for Australia.  Please note that you can click F1 on any parameter field to reveal your options from the help file.

We also need to specify the subcomponent SetupUILanguage as per the below screen capture.

So to recap on what we have just achieved, we have entered 4 settings in our answer file.  As you can see from the Microsoft Windows International Core-WinPE component we had 3 settings to fill in and a sub component “SetupUILanguage” that also needed a setting entered as per the below;

The next steps involved are 2,3 and 4 from our component list which is all about configuring our disk and preparing it for install.  As part of any Windows setup process when you boot into Windows PE (pre-execution boot) you are provided with the opportunity to create and format disk partitions preparing it for installation.  In order to automate this process, we need to specify these details in our WDSUnattend.xml answer file.  We will now focus on the below highlighted components.

As per our previous exercise, we will need to inject the necessary components into our Answer File and this case we will start by adding Microsoft-Windows-Setup\DiskConfiguration\Disk setting to the WindowsPE Pass as follows.

Right click on Disk Configuration and add setting to Pass1 windowsPE as per the below screen capture.

This setting will now appear in the Answer File pane within Windows System Image Manager.

We will now right click on DiskConfiguration and select Insert new Disk. The details area for Disk will now need to be set so the WillWipeDisk is set to true.

We will now right click on Create Partitions and select Insert new create partition.

We will now proceed and create our Windows Partition and then we will need to Modify the Partition specifying details such as Label, Drive Letter and File System Format.  Your results should look similar to the below screen captures.

Answer File Structure

Create Partition Details

Modify Partition Details

The last component that we need to inject is Microsoft-Windows-Setup\WindowsDeploymentServices\ImageSelection\InstallTo providing details on which partition our Windows 7 Image should install to.  Again, we will right click on the Microsoft-Windows-Setup\WindowsDeploymentServices\ImageSelection\InstallTo  component and select Add setting to Pass1 windowsPE.

The settings required for the above component is captured in the below screen shot.  We have simply specified that our eventual Windows 7 image will install directly on the first partition of our selected disk.

In summary, the below are the above settings in text form;

We have now completed the settings and passes required for our WDSUnattend.xml Answer File which we can now save.  Upon saving your xml file, Windows System Image Manager will check for any warnings or errors.

We will now apply the WDSUnattend.xml file to our WDS server as follows.  Navigate to the Windows Deployment Services Management Console and right click on your Server object and select properties.  Click on the Client tab and select Enable unattend installation and you will notice that you will need to specify a separate WDSunattend.xml file for the differing architectures.  Select Browse and navigate to your saved xml file and then click on Apply and OK.

We have come to the conclusion of the second part of this series and have successfully created and applied our WDSUnattend.xml file to your WDS Server, automating the PXE boot.  In the next article we will focus our efforts in creating an ImageUnattend.xml file which will be applied against our Windows 7 image or commonly referred to as our  “Install” image automating the Out of Box Experience.

Stay tuned!  If you would like to be notified of future articles, you can do so by subscribing via RSS, or have articles directly sent to your email by subscribing on the right navigation bar.

________________________________________________

Articles in this series

1. Windows Deployment Services, WAIK & Windows 7 – Part 1/4 (Installation and Configuration of the WDS Role)
2. Windows Deployment Services, WAIK & Windows 7 – Part 2/4 (Creation & Configuration of WDSUnattend.xml)
3. Windows Deployment Services, WAIK & Windows 7 – Part 3/4 (Creation & Configuration of ImageUnattend.xml)
4. Windows Deployment Services, WAIK & Windows 7 – Part 4/4 (Injecting Drivers)

I have been known to be at the cutting edge of technology, early adoption of Microsoft technologies is a must and this time round nothing is going to change.  I first played with Windows Deployment Services (WDS) back in the day when it was referred to as Remote Installation Services (RIS) and had first exposure to the Windows Automated Installation Kit (WAIK) back when it was in beta and so was Vista at the time.  I took the plunge and deployed Windows Vista using Light Touch deployment via WDS and the WAIK a month after Vista was released to the enterprise and today I will be providing you with step by step instructions on how you can do the same with Windows 7 and Windows 2008 R2.

In this 4 part series I will begin my focus in providing you with instructions in setting up your WDS role on a Windows 2008 R2 server, with part’s 2 and 3 focusing on utilising the WAIK to create your necessary xml files that are needed for light touch deployment and finish off our setup in part 4 by introducing the capability to inject any necessary drivers to your original “install images”.  This article is assuming you have a Windows 2008 R2 server ready to rock and roll with, so let’s begin!

With the introduction of Roles and Features there is no need to have the Windows 2008 R2 media at hand as all roles and features are included in the initial installation albeit inactive. In order to setup WDS navigate to Administrative Tools / Server Manager and click on Roles on the left navigation pane and then click on Add Role on the right navigation pane. This will invoke the Add Roles Wizard that we have become familiar with in Windows 2008.

Click Next.  Select Windows Deployment Services as your Server Role.

Click Next.  One of the many things that Microsoft have improved upon lately is their thorough explanations when deploying roles and features within Windows 2008.  Below is an introduction to Windows Deployment Services and things to note regarding the configuration and installation.

Click Next.  The below role services are automatically checked.

Click Next.  The below confirmation screen is displayed.

Click Next. The installation will now proceed with the results displayed as per the below screen capture.

Once the installation has completed, navigate to Administrative Tools / Windows Deployment Services. When you click on the server node you will receive the below warning message;

Windows Deployment Services is not configured.
This server is not configured. To configure this server, first verify that you are a local administrator.

Right click on the server and select configure server.  The below wizard is invoked.  You will need to ensure that the below pre-requisites are met before WDS can become functional.

Click Next.  Select your Remote Installation Folder Location.  As per the below description, ensure that you choose a partition that is large enough to hold your images.

Click Next.  Select your PXE settings.  You have the option to prestage your client which is when you create a computer account object in Active Directory Users and Computers and map this computer object to a physical computer.  This then becomes a known client.  In my example below I have selected Respond to all computers for simplicity.

Click Next.  The server will then go through the configuration process until you receive the below confirmation.  You now have the ability to add your images to the server.  I will leave the Add images to the server now checked which will invoke the Add image wizard.

Here I will add the Windows 7 boot and install images.  These images are originally located under the sources folder on your Windows 7 DVD.  The two files that you need to locate are, install.wim and boot.wim.  In my example below I have copied these 2 files to the WDS server under C:\Windows7 Images.

You now have the option to select an existing image group or create a new one.  I have gone ahead and created a group called Windows 7.

Click Next.  The wizard will detect my 2 images, 1 boot being the boot.wim file and 1 install install image being the install.wim file that I had copied from the Windows 7 media to my image path below.

Click Next.  The images are now added to the server and will be listed as per the below 2 screen shots.

Below is the Windows 7 install image added from our media.

Below is the Boot image added from our media.

This concludes the first part of this article.  In part 2 of this series we will shift our attention to the Windows Automated Installation Kit otherwise known as the “WAIK” where we will concentrate our efforts in automating the PXE boot by creating a WDSunattend.xml file and then continue in part 3 by automating the Out of Box experience on our Windows 7 install image by creating an Imageunattend.xml.

________________________________________________

Articles in this series

1. Windows Deployment Services, WAIK & Windows 7 – Part 1/4 (Installation and Configuration of the WDS Role)
2. Windows Deployment Services, WAIK & Windows 7 – Part 2/4 (Creation & Configuration of WDSUnattend.xml)
3. Windows Deployment Services, WAIK & Windows 7 – Part 3/4 (Creation & Configuration of ImageUnattend.xml)
4. Windows Deployment Services, WAIK & Windows 7 – Part 4/4 (Injecting Drivers)

Windows 2008 R2 has only been out for over a week however I have decided to introduce my first Windows 2008 R2 domain controller (DC) almost immediately into an existing Windows 2008 Active Directory (AD) Domain to eventually have a complete R2 forest functional level to benefit from some of the new R2 features.  For a seasoned IT Pro, introducing new domain controllers is fairly straightforward, however I have decided to provide you with a step by step guide on doing so and the pre-work that is required, so let’s begin!

Now before we delve into the step by step guide I thought I would begin by listing the notable enhancements that come with R2 when it comes to Active Directory.  These are;

AD Recycle Bin – For me this is a long awaited feature providing you with the ability to recover deleted objects.  (Note there are already 3rd party products that have been providing this capability for many years).   In order to activate the AD Recycle Bin, you will require the AD functional level raised to R2, i.e all your domain controllers will need to be R2 providing you with the ability to raise the functional level.
AD Administrative Center – Ease of management for domain(s) providing you with task oriented user interface.  Screen capture located at the end of this post.
Powershell Cmdlets – There are approximately 85 Active Directory related PowerShell cmdlets that replace current Active Directory command line tools.  Whether we like it or not, Microsoft is really pushing Powershell and is a skill that is now required by all system administrators.
Service Account Management – Forget about managing service account passwords as these are now automatically updated for all services when an administrator changes the password.  This is also a welcome enhancement for most administrators.
Active Directory Best Practices Analyser – Know the health of AD based on best practices.  This is similar to “other notable” best practices Analysers that we have come accustomed to from other Microsoft products notably Exchange.  Screen capture located at the end of this post.

So let’s begin by analysing the pre-work that is required before we introduce a Windows 2008 R2 DC.  Because this is the first Windows 2008 R2 DC that is being introduced into an existing domain you will need to run adprep /forestprep command on the server that is holding the schema master operations master.  Note that you will need to do this regardless of whether you are running a Windows 2003 or Windows 2008 domain as the schema database version has changed in R2.  The following KB article from Microsoft http://support.microsoft.com/kb/324801 outlines how to view the Flexible Single Master Operations (FSMO) roles to determine which of your AD servers is holding the schema master operations master.

You will need to run adprep command line utility from the Windows 2008 R2 media which is located under the support\adprep folder.  The below message is what you will receive when trying to run adprep from a DC that is not a schema master operations master.

Once you have located the schema master operations master domain controller, open a command prompt, navigate to the Windows 2008 R2 media support\adprep folder and run the following command;

adprep /forestprep (Word of note, you will notice adprep32.exe is also available to you under the adprep folder if your current schema master operations master DC is a 32 Bit server)

Type C and then press ENTER to continue.

You will notice below that the schema version number for Windows 2008 R2 is 47.

After running forestprep you will need to run the adprep /domainprep /gpprep command on the server that holds the infrastructure operations master.

Once these two commands have been issued you will be ready to deploy your first Windows 2008 R2 domain controller.

We can now invoke the Active Directory Domain Services Installation Wizard by running dcpromo from either command line or Start / Run.

Click Next. The below Operating system compatibility warning is displayed.

Click Next.  We are introducing an additional domain controller into an existing domain as per the below screen capture.

Click Next. It will detect the current forest and current logged on credentials.

A list of domains in the forest will be listed as per the below screen shot.  Select the domain that you will introduce the new DC into and then click next.

You will receive the below warning “You will not be able to install a read-only domain controller in this domain…”.

You must first run “adprep /rodcprep” from a command window on any computer in this forest. The Adprep utility is available on the Windows Server 2008 R2 installation media in the \support\adprep folder.

Click Yes to acknowledge the warning as we are not installing a read-only domain controller at this time.

Select your site for the new domain controller.

Click Next.  The wizard will begin to examine your current DNS configuration.

You will be presented with additional Domain Controller Options that you can select or deselect.  Again we are notified that a domain controller running Windows Server 2008 or Windows Server 2008 R2 could not be located in this domain. To install a read-only domain controller, the domain must have a domain controller running Windows Server 2008 or Windows Server 2008 R2.  I admire Microsoft’s thoroughness and rigorous checks and warnings but they can sometimes be annoying.

Select a location for your database, log files and SYSVOL. It is best practice here to specify a separate disk for your logs and database.

Now specify your Directory Services Restore Mode Administrator Password.

Click Next.  The installation and configuration process now begins.

The below screen appears upon completion.  That’s it!  Reboot your machine and your new Windows 2008 R2 server will have transformed into a domain controller.

At the beginning of this post, I outlined some of the features and enhancements provided by R2 and as promised, below are screen captures of the Best Practices Analyser in action for Windows Active Directory and the new Active Directory Administrative Center.

I will leave you with a link to the TechNet Webcast: Active Directory Domain Services in Windows Server 2008 R2 Technical Overview (Level 300) which is worth watching.

My goal now will be to update the remaining two Active Domain controllers and raise the forest functional level opening the door to the new R2 Active Directory features that I will blog about in future posts.

So what is your favourite or sought after R2 feature when it comes to Active Directory?  I would be more than happy to hear your thoughts.