Daniele Tosatto

The RD Virtualization Host Capacity Planning in Windows Server 2008 R2 is now live on the Download Center.  This white paper is intended as a guide for capacity planning of RD Virtualization Host in Windows Server 2008 R2. It describes the most relevant factors that influence the capacity of a given deployment, methodologies to evaluate capacity for specific deployments, and a set of experimental results for different combinations of usage scenarios and hardware configurations.

From an App-V point of view, App-V with HTTP deployment method is not too complicated, but there are some aspects that have the potential to cause confusion in the community and with this Microsoft hope to avoid the confusion and hopefully, one can test, play and deploy this method with confidence.

In this article, we will discuss the following:

The configuration of IIS

- The installation of IIS

- The creation of the virtual directory

- The MIME types

The creation and configuration of the Publishing Document

- How HTTP streaming works with App-V and how we use and create the Publishing Document

- Testing the Publishing Document

The configuration of the App-V Client

- The configuration of the HTTP server

- The configuration of the App-V client settings

- More information

For the creation of this document, a Windows Server 2008 R2 machine has been used with Internet Information Services 7.5 and a Windows 7 client with App-V for Windows Desktops 4.6 x64.

The configuration of IIS

The configuration of the IIS server is not that complicated for use with App-V; however, there are some things we should keep in mind.

The installation of IIS

When installing IIS for App-V, we should make sure the following role components are installed:

· Common HTTP Features – ALL except HTTP redirection

· Application Development – ALL

· Health and Diagnostics – HTTP logging and Request Monitor only

· Application Development – ALL

· IIS 6 Management Compatibility – ALL

· Security – ALL authentication options

· Management Tools – ALL

The creation of the virtual directory

A virtual directory in IIS must be created in order to represent the App-V content share that contains all application packages. The virtual directory has to be pointed to the location where the content share is. The content share should be configured as a default file share. For the virtual directory, the default settings can be maintained, but make sure that the virtual directory is located under the default website and that Directory Browsing and Read are checked.

The MIME types

In IIS, we have to configure a couple of MIME types to make sure we can handle the App-V files properly. Below is a summary of these MIME types:

The creation and configuration of the Publishing Document

Whether HTTP Publishing and Streaming works or fails depends mostly on the Publishing Document. The Publishing Document is an .aspx page to which the App-V client connects to send its request for applications (icons, FTA’s etc.). If the Publishing Document is not functioning properly for any reason, the clients will not be able to connect and the App-V applications will not work. There are several methods to create a proper Publishing Document, some of them are easy and some complicated and some of them are suited for quick tests and some not.

We can create a Publishing Document manually, which is a good one for testing purposes. However, when we are looking for a larger deployment, we would not be happy to process each application package manually. This would also be prone to errors and it would require manual modification when a new package is deployed to the environment. Because this is not desired, we can also use more complicated ways to achieve our goal, making our lives much easier in the end by creating your Publishing Document automatically.

How HTTP streaming works with App-V and how we use and create the Publishing Document

When we deploy App-V with Management or Streaming servers, the App-V clients are configured to point to the App-V server, which handles their request. When we only use IIS for the publishing and streaming of App-V applications, we need to have a slightly different approach.

From a client perspective, we do not have to do much, except configuring it to point to a HTTP server and configure some settings. However, from the IIS point of view, we should understand some things before we can implement this properly.

When the App-V client performs a Desktop Configuration Refresh (DC Refresh), it sends a request to the IIS server. With this request, the client is asking what applications are available, and where icons should be placed and whether this application has File Type Associations (FTA’s). The client needs to receive this information in XML format.

Therefore, in order for the client to get all information properly, we have to make sure that this information is accurately available on the IIS server. In order to achieve this, we have to make a Publishing Document. This Publishing Document is an .aspx file that is located in the root of the content directory. The client needs to be pointed to this page in order to work, but this will be discussed later on. This Publishing Document needs to contain information about the Desktop Configuration, which includes (but is not limited to) the Refresh Settings, the Refresh Interval, Reporting Settings and of course, the Applist.

A basic Publishing Document looks like this:

The POLICY part of the document will specify how (and if) the Desktop should be configured, whether we want a refresh on login to occur or not and on what interval and whether we want to enable reporting.

The part between the APPLIST tags is interesting. This is the part where the XML should be placed that specifies the applications, their icons and FTA’s etc. Back in the old days, there was no ‘easy’ way to create this piece of information. We had to perform a DC refresh on a client with Verbose Logging enabled, because that way the complete APPLIST was parsed to the client in the App-V Client Log. We could then reuse this piece to create the Applist in the Publishing Document.

Nowadays, this is much easier. When we create an App-V package, the Sequencer creates an XML manifest file for each application, and this manifest file contains all publishing information. An example of a manifest file looks like this:

As we can see here, we have a ready-to-go APPLIST section. This part can be used to automatically create the APPLIST, making our lives very easy.

We can configure the Publishing Document to call another piece of code that parses all manifest files of all applications on the Content Share so that a proper Publishing Document is created. For this to work, we need to modify the original Publishing Document a bit:

As you can see, we have added a section at the top of the page. This piece is referring to a class file called publishing.aspx.cs and this code is responsible for parsing the XML manifest files that exist on the content share. This code also makes sure that the parsed info will be placed in the Publishing Document between the APPLIST tags. So simply said, the Publishing Document calls a CodeFile class file, and this class file is responsible for the creation and placement of the APPLIST. Below is an example of the Class file. Please note that there are various options for this file, and that it is not limited to the example below. In this example, we use a C# method that uses an algorithm to check for XML manifests files and to process the info to the APPLIST.

Testing the Publishing Document

When we have created the Publishing Document, we can test it to see if it works. Of course, when your App-V Client refreshes, publishes and launches applications correctly, it seems to be working just fine but if this does not work, we need to troubleshoot this. When we move to the IIS server and browse to the publishing.aspx page from Internet Explorer, we should see an error, and it should also be telling us where this error is located. An example is a failing DC Refresh, resulting in the error below (0A-400001F4). This error basically means that the IIS Server returns an Internal Error 500.

When we now browse to the publishing page from the Internet Explorer, we get a more detailed error:

This would be the best way to troubleshoot these kinds of issues. Even a verbose App-V client log will not show detailed info on the problem in the Publishing Document.

When the DC refresh is happening properly, but applications that are not published or launched, we have an issue in another part of the configuration (probably the client configuration).

The configuration of the App-V Client

As mentioned earlier, the configuration of the server on the client is not that difficult. However, there are some settings we should keep in mind in order to have a succesfull deployment.

The configuration of the HTTP server

In the server section of the App-V Client Management Console, we need to specify a name for the server, which can be anything you like. The hostname should represent the machine name that runs the IIS server. When selecting a Standard HTTP Server as the server type, the port will be automatically changed to port 80. The path to the Publishing Document should be in the format /content/Publishing.aspx if the aspx page is in the content directory.

The configuration of the App-V client settings

In the App-V Client registry, we should configure the SourceRoot for the Applications, Icons and OSD’s.

This can be configured here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration:

This would make the deployment of applications much easier. Setting these SourceRoots makes sure that the Client always looks in the right directions for the necessary files. When configured the SourceRoot overwrites the part before the subfolder in the HREF section of the OSD file. For example, when the OSD is set to RTSP://server:554/appsubfolder/app.sft and the ASR is set to \\branchserver\content, the RTSP://server:554 part will be overwritten by \\branchserver\content.

In order to make this work, we have to make sure that the subfolders are properly configured in the applications XML manifest (which can be done on the Sequencer). When we look at the below snippet of a manifest file, we see that it points to %SFT_MIME_SOURCE%/DeepZoomComposer.osd for the OSD.

Usually, the application files are located in a subfolder on the content share. If this would be the case, and if the package would be located in \\appvcontent\deep zoom composer, and we would set the ASR to http://IISSERVERNAME:80/contentname, this would fail because the client will look in http://IISSERVERNAME:80/contentname/DeepZoomComposer.osd. So on the sequencer, we should make sure the Package Folders are set right so that we do not have to modify the XML manifests afterwards.

When we have issues with the locations, we can see this in a verbose client log very well. We would see entries like the ones below that tell us the wrong location where the client looks for the files.

Could not load OSD file http://servername:80/content/application.osd

The app manager could not create an application from ‘http://servername:80/content/application.osd’ (rc 24603C4A-40000194)

More information

HTTP Publishing in App-V (Part 1): http://blogs.msdn.com/b/johnsheehan/archive/2009/03/24/http-publishing-in-app-v-part-1.aspx#comments

Support for Client Reporting over HTTP: http://technet.microsoft.com/en-us/library/ee956912.aspx

How to Configure the IIS Server: http://technet.microsoft.com/en-us/library/cc843650.aspx

.NET Framework General Reference – @ Page:

http://msdn.microsoft.com/en-us/library/ydy4x04a(vs.71).aspx

http://msdn.microsoft.com/en-us/library/ydy4x04a(VS.85).aspx

Feature Overview

The goal of RemoteFX USB redirection is simple: the user should be able to use any device they want, and have it just work. RDP has numerous high-level redirections that allow specific types of devices to be used effectively in a remote session, such as:

• Easy Print, which allows users to print to local printers in remote sessions
• Drive Redirection, which allows users to access the file system on any local drive in a remote session, including USB drives
• Smart Card Redirection, which allows users to authenticate to and in a remote session by using smart cards/e-tokens
• Plug-and-Play Device Redirection, which allows users to access PTP digital cameras, MTP music players, and POS for .NET devices in a remote session, among others
• Input Redirection, which allows the use of keyboards/mice in remote sessions
• Audio Redirection, which allows recording and playback of audio in remote sessions
• Port Redirection, which allows the use of serial and parallel ports in remote sessions

However, there are many devices which are not covered by these redirections, such as scanners, multifunction printers, webcams, and more. RemoteFX USB redirection acts as a catch-all mechanism that redirects these USB devices! Unlike high-level redirections such as drive redirection, RemoteFX USB redirection happens at the port protocol (USB request block or URB) level, and is similar to how one can redirect serial or parallel ports via RDP. This provides some unique advantages, as you’ll see below. However, RemoteFX USB redirection is meant to supplement high-level redirections, not to supplant them. By combining RemoteFX USB redirection with RDP high-level device redirections, you can have the best of both worlds. Here is a table that compares and contrasts the two forms of redirection.

Setting up a Basic Deployment

Now that you’ve seen what RemoteFX USB redirection can do, let’s take a look at how to set up the feature.

Prerequisites

You will need the following:

• A RemoteFX-capable client (Remote Desktop Connection 7.1 or later)
• A virtual machine hosted on a RemoteFX host (Windows 7 SP1 or later)

Enabling RemoteFX USB redirection on the clients

1. In order to redirect USB devices from a given machine, the RemoteFX USB redirection feature must be enabled. In Group Policy, navigate to Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client\RemoteFX USB Device Redirection, and edit “Allow RDP redirection of other supported RemoteFX USB devices from this computer.” Enable the policy, and specify whether you wish to allow all users or only admins to redirect devices.
   
2. On the client machines, run “gpupdate /force” (without quotes) from an Administrator command prompt to enable/disable the feature, and then restart the computer for the changes to take effect. The feature will not work until you restart.

Using the feature

1. On the client, open Remote Desktop Connection. If the tabs are not listed, click Options to expand the dialog box.
2. On the Local Resources tab, click More to display the Local devices and resources dialog box. If at least one supported RemoteFX USB device is connected, it should be listed in the device tree under Other supported RemoteFX USB devices.

   Note: The heading “Other supported RemoteFX USB devices” will only appear if the RemoteFX USB redirection feature is enabled on the client (apply the Group Policy setting, run gpupdate, and then restart) and at least one supported RemoteFX USB device is connected and available for redirection.
   

3. After you are connected, the devices that you have selected should appear in the remote virtual desktop.
   

XenApp 6 has now been available for about two months.

There are some concerns about the transition to XenApp 6 being that mixed farms and upgrades aren’t supported and that migration is the only option. Another major area of concern is app compatibility. Let’s address these items:

•Mixed Farms. For each of the XenApp/Presentation Server/MetaFrame product releases, warning statements about mixed farms have existed, and best practice has always been to run a native farm. These warnings statements range from potential unexpected results to multiple if/then requirements and lots of maybe’s in between.
•Upgrades: Citrix doesn’t support upgrading the operating system and then upgrading the Citrix product version, and XenApp 6 is no different. XenApp 6 is purpose-built for Windows Server 2008 R2 (and only Windows Server 2008 R2!). Not being able to upgrade the OS and XenApp version continues with XenApp 6.
•Migration: Unlike previous versions of XenApp, XenApp 6 includes a Migration Tool that will enable you to export your existing farm and app settings to your new farm. Previously, you could only export/import published app settings. This PowerShell tool is currently in beta through MyCitrix.com and will be released in a few weeks.
•App Compatibility: While 16-bit apps can’t run on a 64-bit operating system, 32-bit apps are generally fine. Research whether your concerns are real or not so real. Test your apps or use a tool such as App-DNA to determine potential app issues. If your concerns are real, consider VM Hosted Apps.

From Citrix blog, Let’s step back and discuss why migration is now the only option.

•Worker Group data: The Data Store for a XenApp 5 farm vs. a XenApp 6 farm differs due worker group data. XenApp 5 has no provision for this, and a business decision had to be made regarding adding functionality such as worker groups vs. mixed farm support.
•Integration with Active Directory: While XenApp has always been integrated with Active Directory, XenApp 6 takes that integration to a new level. The Group Policy Management Console can be used to administer XenApp 6. Further, when new servers are placed into OUs and automatically spun up via Provisioning services, a XenApp server can take on settings automatically.
•Operating System: Because operating system upgrades are not supported by Citrix for any component, installing a clean, new Windows Server operating system and then the new XenApp version is required anyway.
•Tech Support issues: Quite a few Tech Support issues were raised due to mixed farms, and some of these could never be resolved. Engineering could never test all of the “what if’s” that could present themselves in a mixed farm environment. So, we had customers that could never be totally content with the mixed farm approach.

While XenApp 5 is good, XenApp 6 takes on a whole new level of functionality — and hopefully now you can see why mixed farm compatibility would have been counterproductive.

Some resources you may find helpful:
•CTX124481: Advanced Farm Administration with XenApp Worker Groups
•CTX124241: Technical Guide to Upgrading/Migrating to XenApp 6

There are tremendous benefits to moving to XenApp 6 — a single management console, worker group functionality, improved AD integration, and much more. Give yourself a solid hour or two to work with it in your lab, and you’ll be giving thought to how fast you can migrate to XenApp 6!

The Remote Desktop Services Deployment Guide for Windows Server 2008 R2 is now live on the Download Center and on TechNet.  This guide is intended for use by system administrators and system engineers who are responsible for deploying the role services and features for Remote Desktop Services for the Virtual Desktop Infrastructure (VDI) environment. It provides detailed guidance for deploying a Remote Desktop Services design that is preselected by you, an infrastructure specialist, or a system architect in your organization.

The Terminal Services Deployment Guide for Windows Server 2008 is now live on the Download Center and on TechNet.  This guide is intended for use by system administrators and system engineers who are responsible for deploying the role services and features for Terminal Services. It provides detailed guidance for deploying a Terminal Services design that is preselected by you, an infrastructure specialist, or a system architect in your organization.

Microsoft is increasing its marketing effort in promoting its VDI platform since a few months now.

Microsoft published a guide to help Deploying Remote Desktop Connection Broker with High Availability.

This guide is intended for IT professionals, and tells how to configure Remote Desktop Connection Broker in a failover cluster. The configuration provides users with access to personal virtual desktops or virtual machines in a virtual desktop pool through RemoteApp and Desktop Connection.

You can find it here.

Whereas best practice violations, even very important best practice violations, are not necessarily problematic, they indicate server configurations that can result in poor performance, poor reliability, unexpected conflicts, increased security risks, or other potential problems.

Best Practices Analyzer (BPA) is a server management tool that is available in Windows Server 2008 R2. BPA reports best practice violations to the administrator after BPA scans the roles that are installed on Windows Server 2008 R2.

After this update is installed on a server that is running Windows Server 2008 R2, you can run a series of Best Practices Analyzer scans on Hyper-V that will help you to bring the role into compliance with best practices.

You can use Hyper-V Best Practices Analyzer to scan a server that is running the Hyper-V role, and help identify configurations that do not comply with best practices for this role. BPA scans the configuration of the physical computer, the virtual machines, and other resources such as virtual networking or virtual storage.

You can dowload Hyper-V Best Practices Analyzer here .

Hi,

In this post, you can find a tutorial about Citrix Server XenApp 6 installation and configuration.
I hope you find this useful for your job.

In this tutorial, Citrix XenApp 6, a Citrix Web Interface and Citrix License Server will be installed on one server.

Don’t hesitate to comment this for suggestions, problems etc…

Before starting, I suggest you to read System Requirements for XenApp 6 for Windows Server 2008 R2 available at the following link:

http://support.citrix.com/proddocs/index.jsp?topic=/xenapp6-w2k8/ps-system-requirements-w2k8-xa6.html

How to install and configure a Citrix Server XenApp 6: download PDF ! howto_install_configure_xenapp6_server_with_webinterface_license_server

On Windows 7 and Windows Server 2008 R2, there is a great troubleshooting tool called the Problem Steps Recorder (PSR). The PSR allows screenshots and details of actions to be automatically recorded and saved in a .MHT file that is automatically zipped. A user can send this file to Microsoft Support to provide an accurate account of steps to reproduce and issue. There is a short video on TechNet that gives a demonstration of the Problem steps recorder.

We can appropriate this tool and turn it into a Sequencing Steps Recorder to document “recipes” for sequencing applications. Other App-V blog articles have demonstrated how to use video to document sequencing. The Problem Steps Recorder just provides another alternative, especially for those users that like to read from a printout.

The PSR can be easily be found on Windows 7 or Server 2008 just by clicking on the Windows Logo and typing “steps” ,“record”, or “PSR.exe” in the search bar.

In order to use the PSR correctly on your Sequencer, it is important to follow these steps:

1. Connect to your Sequencing Virtual Machine.

2. Click on the Windows Logo (Start button) and type “steps”.

3. Click on “Record steps to reproduce a problem.”

4. Click on the down arrow by the Help icon and choose “Run as Administrator” if it is not grayed out. Some windows may not capture if this is not selected.

5. From the same menu, click on SETTINGS.

6. Change the NUMBER OF RECENT SCREEN CAPTURES TO STORE to the maximum value of 100.

a. If you have more than 100 actions, which is possible, screenshot #1 would be removed in order to capture screenshot #101. The text detail for Step #1 would still remain.

7. Click on START RECORD

a. Recording doesn’t have to start until before “Begin Monitoring” is selected. You may wish to document the procedure start to finish , especially if there are other pre-requisites that need to be installed prior to sequencing.

b. If you Begin Monitoring before launching the PSR, you will pick up the PSR in your sequence and possibly prevent your application from working as expected.

8. Install pre-requisites or launch the Sequencer

9. Complete the sequencing process.

10. Click on STOP RECORD and save the zip file.

When the .ZIP file is extracted, the .MHT file can be double-clicked and viewed inside Internet Explorer. Scroll through the steps, or choose to watch them as a slide show. Each step provides text details of the action taken and clearly defines in the screenshot where the action should be taking place.

The “Additional Details” section at the end of the .MHT file provides a text only version of all the steps taken as well as specific version information. This information can be especially helpful in a Technical Support situation. Here are the details from the same step as above:

Problem Step 17: User left click on “Begin Monitoring (push button)” in “Sequencing Wizard: Step 3 of 7″

Program: Microsoft Application Virtualization Sequencer, 4.5.2.17140, Microsoft Corporation, SFTSEQUENCER.EXE, SFTSEQUENCER.EXE

UI Elements: Begin Monitoring, Begin &Monitoring, Button, Sequencing Wizard: Step 3 of 7, #32770, Sequencing Wizard: Step 3 of 7, #32770

The Problem Steps Recorder does have a few limitations, but the ability to capture easy to follow, easy to distribute, and explicit documentation makes it a very valuable tool. The limitations include: 100 screenshot maximum, inability to capture detail inside a VM when PSR is run outside the VM, it captures your mistakes as well.

Starting with Windows Server 2003 SP1, it is possible to provide server authentication by issuing a Secure Sockets Layer (SSL) certificate to the Remote Desktop server. This is easy to configure using the “Remote Desktop Session Host Configuration” tool on Server operating systems. Though no such tool is available on Client operating systems such as Windows Vista and Windows 7, it is still possible to provide them with certificates for Remote Desktop connections. There are two possible ways to accomplish this. The first method is using Group Policy and Certificate Templates, and the second one is using a WMI script.

Part I: Using Group Policy and Certificate Templates.

This method allows you to install Remote Desktop certificates on multiple computers in your domain but it requires your domain to have a working public key infrastructure (PKI).

First, you need to create a Remote Desktop certificate template.

Creating Remote Desktop certificate template:

1. On the computer that has your enterprise Certification Authority installed start MMC and open the “Certificate Templates” MMC snap-in.
2. Find the “Computer” template, right-click on it, and then choose “Duplicate Template” from the menu.
3. In the “Duplicate Template” dialog box, choose “Windows Server 2003 Enterprise” template version.
   
4. The “Properties of New Template” dialog box will appear.
5. On the “General” page of this dialog box, set both “Template display name” and “Template name” to “RemoteDesktopComputer”. Note: it is important to use the same string for both properties.
6. On the “Extensions” page, select “Application Policies”, and then click the “Edit…” button.
7. The “Edit Application Policies Extension” dialog box appears.
   
8. Now you can either remove the “Client Authentication” policy leaving the “Server Authentication” policy, or you can use the special “Remote Desktop Authentication” policy. Doing the latter will prevent certificates based on this template from being used for any purpose other than Remote Desktop authentication.
9. To create the “Remote Desktop Authentication” policy, first remove both the “Client Authentication” and “Server Authentication” policies, and then click “Add…”
10. The “Add Application Policy” dialog box appears. In this dialog box click the “New…”
    
11. The “New Application Policy” dialog box appears. In this dialog box, set “Name” to “Remote Desktop Authentication” and “Object Identifier” to “1.3.6.1.4.1.311.54.1.2”, and then click “OK.”
    
12. Select “Remote Desktop Authentication” in the “Add Application Policy” dialog box, and then click “OK.”
13. Now the “Edit Application Policies Extension” dialog box should look like this:
    
14. Click “OK” in this dialog box, and then click “OK” in the “Properties of New Template” dialog box.

The new template is now ready to use.

The next step is to publish the template.

Publishing the “RemoteDesktopComputer” certificate template:

1. On the computer that has your enterprise Certification Authority installed, start the Certification Authority MMC snap-in.
2. Right-click on “Certificate Templates”, then select “New\Certificate Template to Issue” from the menu that appears.
3. The “Enable Certificate Templates” dialog box appears. Select “RemoteDesktopComputer”, and then click “OK.”

Now the “RemoteDesktopComputer” template is published and can be used in certificate requests.

The last step is to configure Group Policy to use certificates based on the “RemoteDesktopComputer” template for Remote Desktop authentication.

Configuring Group Policy:

Note: The following steps create the new policy to apply to all computers in the domain, but it can also be scoped to an Organizational Unit if needed.

1. On the domain controller, start the “Group Policy Management” administrative tool.
2. Right-click the “Default Domain Policy” and click on “Edit…” in the menu that appears. The “Group Policy Management Editor” appears.
3. Navigate to “Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security.”
4. Double-click the “Server Authentication Certificate Template” policy.
5. Enable the policy, type “RemoteDesktopComputer” in the “Certificate Template Name” box, and then click “OK.”
   
6. As soon as this policy is propagated to domain computers, every computer that has Remote Desktop connections enabled will automatically request a certificate based on the “RemoteDesktopComputer” template from the Certification Authority server and use it to authenticate to Remote Desktop clients. You can speed up the propagation to a specific computer by running the “gpupdate.exe” command line tool on that computer.

Part II: Using a WMI script.

This method allows you to use a server certificate of your choice with Remote Desktop connections but the certificate needs to be manually installed on the computer first. For example, this method can be used if you bought your certificate from a public certificate authority.

First check that your certificate meets the requirements for Remote Desktop certificates. Certificates that don’t meet these requirements won’t work and will be ignored.

Basic requirements for Remote Desktop certificates:

1. The certificate is installed into computer’s “Personal” certificate store.
2. The certificate has a corresponding private key.
3. The” Enhanced Key Usage” extension has a value of either “Server Authentication” or “Remote Desktop Authentication” (1.3.6.1.4.1.311.54.1.2). All-purpose certificates can be used as well.

In order for a certificate to be used for Remote Desktop connections you first need to obtain the certificate’s thumbprint.

Getting the certificate’s thumbprint:

1. Double-click on the certificate.
2. Click the “Details” tab.
3. Select the “Thumbprint” entry from the list.
   
4. Copy the thumbprint value into Notepad.
5. Delete all the spaces between the numbers.

Now you have the thumbprint string ready to use. It should look like this: 0e2a9eb75f1afc321790407fa4b130e0e4e223e2

Once you have the thumbprint you can use the following script to cause the certificate to be used for Remote Desktop connections.

WMI script for configuring Remote Desktop certificate:

var strComputer = ".";

var strNamespace = "\\root\\CIMV2\\TerminalServices";

var wbemChangeFlagUpdateOnly = 1;

var wbemAuthenticationLevelPktPrivacy = 6;

var Locator = new ActiveXObject("WbemScripting.SWbemLocator");

Locator.Security_.AuthenticationLevel = wbemAuthenticationLevelPktPrivacy;

var Service = Locator.ConnectServer (strComputer, strNamespace);

var TSSettings = Service.Get("Win32_TSGeneralSetting.TerminalName=\"RDP-Tcp\"");

if (WScript.Arguments.length >= 1 )

{

    TSSettings.SSLCertificateSHA1Hash = WScript.Arguments(0);

}

else

{

     TSSettings.SSLCertificateSHA1Hash = "0000000000000000000000000000000000000000";

}

TSSettings.Put_(wbemChangeFlagUpdateOnly);