Phần chưa được công bố: Cấu hình CA cho SSL trên máy chủ RemoteFX

1. giới thiệu mô hình và quy trình cài đặt, cấu hình Certificate Authenticate (CA) với máy chủ RemoteFX:



2. Các bước thực hiện:

Bước 1. IIS 8


Bước 2.  Cấu hình Common name


Bước 3.  Cấu hình mã hóa RSA


Bước 4. Lưu fie txt hoặc req


Bước 5. Mở Server Manager trên máy chủ AD Server 2008 R2


Bước 6. Kiểm tra cấu hình CA server


Bước 7.  Dùng cmd chạy lệnh xác thực và tạo file chữ ký (đay là do lỗi phân quyền tự động duyệt chữ ký số)


certreq.exe -submit -attrib “CertificateTemplate:WebServer” newcert.txt newcert.cer

Bước 8. Mở lại Windows 2012, mở cmd và gõ lệnh mmc > chọn Certificate Authenticate:


Bước 9. Chọn mục Personal > chọn chữ ký số đã ký > bấm phải chuột chọn menu : Export…


Bước 10. Cài mật khẩu


Bước 11. Cấu hình chữ ký số cho các dịch vụ


Bước 12. Sau khi cài các chũ ký số

chúng ta có thể tiến hành publish các Application qua RD Broker Publish service bình thường


Bước cuối:

Chạy trình duyệt test, phần lớn trường hợp ở đây bị lỗi, cách tốt nhất là khởi động lại máy chủ Windows 2012 và kiểm tra màn Dashboard xem có dịch vụ nào không chạy (báo đỏ)

hãy vào các mục service lỗi đó và bấm chuột phải chọn Start để các dịch vụ đó chạy lên hết, rồi hẵng vào IE/Chrome/FF và test lại trang RemoteFX



Chúc các bạn thành công  !

Step by Step Customizing RD Web Access 2012 R2 – Part 6

How to restrict users from accessing local drives of an RD Session Host server while using RemoteApp programs

I would like to discuss a method that an administrator can use to keep users from storing files in public folders and scattering files randomly throughout a virtual machine pool or Remote Desktop Session Host (RD Session Host) server farm, while using Remote Desktop Services and RemoteApp programs. (Note: an “RD Session Host server” was formerly called a “terminal server” in Windows Server 2008.)

Currently, when a user creates an RDP session or a RemoteApp program, they can see, and in some cases transverse, drives C and D of the RD Session Host server. They can also save anything on the desktop, which might look like their personal desktop, but it’s actually the desktop of the RD Session Host server.

Restrictions will disable Libraries and Favorites and will hide or restrict users or a group of users from accessing and viewing any drives on the RD Session Host server. Users will be provided with an error message even if they use the UNC path to access the drives.

The primary reason to remove Favorites and Libraries and access to drives is because they contain mostly accessed locations on a system, so in the case of the RD Session Host server, this includes the desktop, downloads, recent places, etc. It is recommended that a user not save any documents to these locations.

Removing Favorites and Libraries

You must perform these modifications on the RD Session Host server. You can use the Registry to make these changes.

Using the Registry (applies to all users including the administrators)

Note: Back up the key first and take ownership of the ShellFolder before changing the value of Attributes.

1. For Favorites, the key is:

Changing a0900100 to a9400100 will hide Favorites from the navigation pane.

2. For Libraries, the key is:

Changing b080010d to b090010d will hide Libraries from the navigation pane.

Hiding/Preventing Access to Drives

You can use Group Policy settings to hide and restrict access to drives on the RD Session Host server. By enabling these settings you can ensure that users do not inadvertently access data stored on other drives, or delete or damage programs or other critical system files on drive C.

The following settings are located in the Group Policy Management Console under User Configuration\Policies\Administrative Templates\Windows Components\Windows Explorer:

  • Hide these specified drives in My Computer. You can remove the icons for specified drives from a user’s My Computer folder by enabling this setting and using the drop-down list to select the drives you would like to hide. However, this setting does not restrict access to these drives.
  • Prevent access to drives from My Computer. Enable this setting to prevent users from accessing the chosen combination of drives. Use this setting to lock down the RD Session Host server for users accessing it for their primary desktop.

Applies to:

  • Windows Server 2008 R2
  • Windows Server 2008
  • Windows Server 2003

Other Group Policy Settings for Additional Security

You can also enable the following Group Policy settings at User Configuration\Administrative Templates\Windows Components\Windows Explorer:

  • Hides the Manage item on the Windows Explorer context menu — Enabled
  • Remove Hardware tab — Enabled
  • Remove “Map Network Drive” and “Disconnect Network Drive” — Enabled
  • Remove Search button from Windows Explorer — Enabled
  • Disable Windows Explorer’s default context menu — Enabled
  • Remove Run menu from Start Menu — Enabled

Applies to:

  • Windows Server 2008 R2
  • Windows Server 2008
  • Windows 7
  • Windows Vista
  • Windows XP


Remove Network icon from explorer and Common File Dialog.

Note: This solutions is based upon personal experience with Windows Server 2008R2 SP1. This test case is comprised of one Terminal Server and this same Windows Server 2008R2 SP1 server editing the Group Policy on a Windows Server 2003R1 SP2 Domain Controller. (Because the Group Policy Preference is only available via Windows Server 2008)

Windows Server 2008R2 is 64-bit only it contains 32-bit compatibility for backwards compatibility reasons. This, sometimes, leads to duality within the system. For example there are two Program File directories. One ‘normal’ one and one x86 version. This is the same within the registry, but most of the time you won’t notice this because most program’s don’t really care where this data is stored. Unless you are named: Common File Dialog…

The trick, part 1:

To get rid of the Network icon from Windows Explorer edit this in the server’s registry:

Path: HKEY_CLASSES_ROOT\CLSID\{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\ShellFolder

Key: Attributes

Change this hex value: “b0040064” (without quotes!)

To this value: “b0940064” (also with quotes)

This first part is, in the 32-bit world, the solution for the Windows Explorer ánd the Common File Dialog. But in the 64-bit world you need another registry key edited. This is basically the same key, but in the Wow6432Node ‘folder’ within the registry. This is the backwards compatibility mode within the registry I was talking about before. Click here to learn more about this Wow6432Node and it’s uses.

The trick, part 2:

To get rid of the Network icon from the Common File Dialog edit this in the server’s registry:

Path: HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\ShellFolder

Key: Attributes

Change this hex value: “b0040064” (without quotes!)

To this value: “b0940064” (also with quotes)


(Note, this screenshot is made from Windows 7 Ultimate, but the keys are the same because the codebase for Windows 7 and Windows Server 2008R2 are the same.)

Step by Step Customizing RD Web Access 2012 R2 – Part 5

Adding the current user’s Active Directory displayname to RD Web Access 2012R2


This is another addition to the “Customize RD Web Access 2012 R2” series.

This post is inspired by comments in the series, in which readers asked if it was possible to show the logged in user’s displayname as it appears in Active Direcory.
I did a little digging in the code and found a way to accomplish this.

I’m not going to detail the setup I have here. If you’re interested I suggest you read up on the series.

Logging into the RD Web Access shows this:
RDS Customize Web Access - show user displayname 01
This is actually the top of the Default.aspx page.
Just basic stuff here, nothing customized, it shows a basic navigation bar. I’m going to show you how you can add the displayname right after the “Sign out” button on the navigation bar.

The files that make up RD Web Access are in C:\Windows\Web\RDWeb\Pages so make a copy of that folder structure just to make sure we have a backup should we break something.

We are going to use native Windows code from an assembly that is already present on the server that holds the RD Web Access role, but is not known to the RD Web Access application yet. So the first step is to tell the application that we are going to add code.

Open web.config from C:\Windows\Web\RDWeb\Pages in an editor.
Find line 52:
RDS Customize Web Access - show user displayname 02
And add the following code right after that:

<compilation defaultLanguage="c#" debug="true">
    <add assembly="System.DirectoryServices, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

The result must look like this:
RDS Customize Web Access - show user displayname 03

This tells the RD Web Access application that we need extra code. The extra code is in the .NET Assembly, and specifically in System.DirectoryServices.dll.
Save and close web.config, we don’t need it anymore.

Now open Default.aspx in an editor, which is in C:\Windows\Web\RDWeb\Pages\en-us.
Find line 225:
RDS Customize Web Access - show user displayname 04

Insert the following code before line 225:

private static string GetDisplayName(string strUserName)
 string strLDAPPath = "LDAP://dc=itw,dc=test";
 string strFilter = string.Empty;

 if(strUserName.Contains("\\")){strUserName = strUserName.Substring(1 + strUserName.IndexOf("\\"));}
 strFilter = "(SAMAccountName=" + strUserName + ")";
 if(strUserName.Contains("@")){strFilter = "(UserPrincipalName=" + strUserName + ")";}
 System.DirectoryServices.DirectoryEntry de = new System.DirectoryServices.DirectoryEntry(strLDAPPath);
 System.DirectoryServices.DirectorySearcher ds = new System.DirectoryServices.DirectorySearcher(de);
 ds.Filter = strFilter;
 System.DirectoryServices.SearchResultCollection results = ds.FindAll();

 return (results != null && results.Count > 0) ? results[0].Properties["DisplayName"][0].ToString() : string.Empty;

Remember to replace “LDAP://dc=itw,dc=test” with your own domain name. So for example, if your domain name is “contoso.local”, this code would be “LDAP://dc=contoso,dc=local”.
The result must look like this (I have wordwrap on in my editor):
RDS Customize Web Access - show user displayname 07

This shows line 225-242 in my file.

Now find line 249:
RDS Customize Web Access - show user displayname 06

And add the following line of code right after that:


The result must look like this:
RDS Customize Web Access - show user displayname 11

This last modification tells the xsl template that it can expect a new variable, and it’s called “userdisplayname”. The value of that variable is the result of the GetDisplayName code you inserted earlier.
Save and close Default.aspx.

Note that if you want to show the displayname on other pages than Default.aspx you need to make these two changes in those files as well! The modifications above in Default.aspx will only work on Default.aspx.

Now open Site.xsl in an editor, which is in C:\Windows\Web\RDWeb\Pages.

Find line 15 (empty line) and insert the following code:

<xsl:variable name="userdisplayname" select="/RDWAPage/@userdisplayname"/>

The result will look like this:
RDS Customize Web Access - show user displayname 08
Here we grab the new variable which we defined in Default.aspx (and now you see why we need to do this on every page that we want to show the displayname on, because the variable is supplied by the actual page).

Find line 323:
RDS Customize Web Access - show user displayname 09

Add the following code on the end of that line:

<xsl:if test="$userdisplayname"> (<xsl:value-of select="$userdisplayname"/>)</xsl:if>

The result must look like this:
RDS Customize Web Access - show user displayname 10

Save and close Site.xsl.

Open your RD Web Access page, login using valid credentials:
RDS Customize Web Access - show user displayname 12

Nice! We now have the displayname displayed on the navigation bar, right next to the Sign out button.
I have tested this in my very simple lab setup. I have only one domain, with a single UPN context, so I couldn’t test this with aliases and such.
I have tested this customization using DOMAIN\username, UPN and just username, and that all works.

Step by Step Customizing RD Web Access 2012 R2 – Part 0

Set up Remote Desktop Services in Windows 2012


Setup a collection of remote desktop servers for end clients to connect to using Session Hosts. This is not a VDI setup.


Service Requirements

– Active Directory. This guide assumes you have a working AD environment up and running already.

– DNS Server. This guide assumes you have a working DNS environment up and running already.

– External DNS domain optional for Labs, but of course you would probably want one in production.


Servers used in this deployment

– 1 x Domain Controller (Microsoft recommend at least two DC’s in live environments for redundancy purposes)

Roles Applied: Domain Controller, DNS

Hostname: DC1.tsdomain.local

– 1 x Domain Member Server

Roles Applied: Domain Member, Web Access Server, Gateway Server, Licensing Server, Connection Broker Server

Hostname: DC2.tsdomain.local

– 1 x Domain Member Server

Roles Applied: Domain Member, File and Storage Services

Hostname: fs1.tsdomain.local

– 3 x Domain Member Servers

Roles Applied: Domain Member, Remote Desktop Session Host.

Hostname: ts1.tsdomain.local, ts2 and ts3


General Client Settings/Tips


RDP Client – Some connection/security problems can occur when using older versions of the RDP client. The majority of this article I was able to connect using Windows 7 SP1 with RDP client 6.1.7601. If possible I would recommend that you upgrade your RDP clients to 6.2.9200.


The update can be downloaded from –


I also believe that you will require the latest version of RDP to get the best out of Remote Desktop Services VDI – More information here.


Web Access – When users are using the web access portal, I would recommend using Internet Explorer. Especially when using a Self Signed Certificate, as you are then able to install it correctly via the browser. Chrome never allowed me to do this and I never bothered with Firefox.


User Groups

– Human Resources

– Jenny Smith (jsmith\Password123!)

– Finance

– Paul Jones (pjones\Password123!)

– Sarah Young (syoung\Password123!)


Role definitions


RD Session Host – These are the servers that users will be connecting to for the Remote Desktop Sessions.

Official Definition – Remote Desktop Session Host (RD Session Host) enables a server to host RemoteApp programs or session-based desktops. Users can connect to RD Session Host servers in a session collection to run programs, save files, and use resources on those servers.


Session Collection – A group of RD Session Hosts, with permissions assigned according to User/Group requirements. An RD Session Host can only be part of one Session Collection.


RD Connection Broker – This is the role that connects users to their Remote Sessions, whether it’s a new session or an existing session.

Official Definition – Allows users to reconnect to their existing virtual desktops, RemoteApp programs, and session-based desktops. Enables you to evenly distribute the load among RD Session Host servers in a session collection or pooled virtual desktops in a pooled virtual desktop collection. Provides access to virtual desktops in a virtual desktop collection.


RD Web Access – The starting point/online portal for users to login and start their Remote Desktop Sessions.

Official Definition – Remote Desktop Web Access (RD Web Access) enables users to access RemoteApp and Desktop Connection through the Start menu on a computer that is running Windows 8, Windows 7, or through a web browser. RemoteApp and Desktop Connection provides a customized view of RemoteApp programs and session-based desktops in a session collection, and RemoteApp programs and virtual desktops in a virtual desktop collection.


RD Licensing – Remote Desktop Licensing (RD Licensing) manages the licenses required to connect to a Remote Desktop Session Host server or a virtual desktop. You can use RD Licensing to install, issue, and track the availability of licenses.


RD Gateway – Remote Desktop Gateway (RD Gateway) enables authorized users to connect to virtual desktops, RemoteApp programs, and session-based desktops on an internal corporate network from any Internet-connected device.


Firewall Rules

My servers all had Windows Firewall enabled, but I configured rules on each to allow all traffic between all the servers. These are not configured by default. Here are scripts to help you configure these rules:

Where x, y and z are replaced with your trusted IP’s and “Policy Name” is the name of the policy in question.


To add a new Policy:


New-NetFirewallRule -DisplayName “Policy Name” -LocalAddress “any” -RemoteAddress,yyy.yyy.yyy.yyy,zzz.zzz.zzz.zzz -Direction Inbound -Action Allow -Protocol TCP -LocalPort any


To edit an existing Policy:


Set-NetFirewallRule -DisplayName “Policy Name” -LocalAddress “any” -RemoteAddress,yyy.yyy.yyy.yyy,zzz.zzz.zzz.zz -Direction Inbound -Action Allow -Protocol TCP -LocalPort any

Installing Roles and Services


All Six servers are part of the domain that I have setup in this scenario, tsdomain.local.

You will also benefit from adding them all the Server Manager “All Services” Pool > Highlight “All Servers” in Server Manager > Right click ” Add Servers:

I did this from DC2 where the majority of the setup will take place.

Let’s Begin:

From the Server Manager Dashboard, select “Add roles and Features” and we want “Remote Desktop Services Installation” :

The main difference between Standard and Quick is Quick will install all the roles on one server, good for testing/learning, we of course want “Standard Deployment“:

We are doing a “Session Based Desktop Deployment“:

The Role Services to be installed are confirmed:

DC2.tsdomain is going to be my RD Connection Broker:

As well as the RD Web Access Server:

Now you are adding in the Session Host Servers (TS1, TS2 and TS3), these are the servers that will host the RD Sessions:

Review the selection of each role and when ready, hit Deploy:

Server Manager will then attempt to deploy each role for you, progress can be followed:

Once complete, we can go ahead and configure each of the Roles as required:


Configuring Roles and Services

Now that the Roles and Services have been successfully installed, we now need to configure each of the services accordingly.


Configure Gateway Server:

From Server Manager > Remote Desktop Services > Overview, Click the green “+” icon on the RD Gateway icon within the Deployment Overview, Add your RD Gateway Server, click next:



Set your RD Gateway URL,

Confirm and click “add“:

From Server Manager > Remote Desktop Services > Overview, Click the “Tasks” Menu and select “Edit Deployment“:

From here we can configure the following Services:


– RD Gateway

– RD Licensing

– RD Web Access

– Certificates

Gateway Configuration:

Specify the “Server name” using the Domain as the External FQDN that users will be using to connect to the service:

In this example, I have setup an A record in my External DNS for pointing to the External IP of my Gateway Server:


Note: The RD Gateway and RD Web Access roles will reside on the same Server

Licensing Configuration:

As this is a lab environment, we do not have any licenses. But this is where you would add the server with the installed licenses, it is pretty straight forward once the CALs are installed on the license server:

RD Web Access Configuration:

This is where the Web Access portal is activated, there should be no need to change anything here. The Internal URL is shown here and if you browse to the External FQDN ( set earlier in the Gateway Configuration you will/should see the RD Web Access portal:

RD Web Access Portal:

Certificates Setup:


At this point if you browsed to the above Web Access Portal, you would of seen the Certificate warning, of course. In this section you can configure your certificates for each of the Roles. It is recommended that you use a valid Certificate for the domain but as this is a lab, we can go ahead and use a self signed Certificate:

Note: If you want to use a Self Signed Certificate then your client will need to access the Portal using Internet Explorer as this will allow you to install the certificate from the browser, in my scenario, Chrome did not let me do this.

You can either use an existing Certificate if you have one already, or Create a new one. The preferred would be an existing one of course. You will need to know the location of the Certificate itself, as for some reason, this wizard doesn’t use the Certificate Store:

Note: Ensure you check the “Allow the Certificate to be added to the Trusted Root Certificate Store” as this gives the client to install the Certificate from the browser, required for Self Signed Certificates.

Once you have selected your Certificate, click apply:

Rinse and repeat for each of the Roles and Services listed, until they all have the Certificate installed:

Configure Session Collections:

Now that we have configured the Roles and Services, we now need to create Session Collections and assign Users/Groups to the Session Collections, this is in turn is giving Users/Groups that they require access to.

From Server Manager > Remote Desktop Services > Collections:



In the “Collections” section as above, go to “Tasks” on the right and “Create Session Collection“:


Give it a name and a Description, I will be creating two Session Collections according to the groups I have created in AD and assigning Session Hosts to each:


Note: Session Hosts can only be part of one Session Collection


User Groups

– Human Resources

– Jenny Smith (tsdomain\jsmith\Password123!)

– Finance

– Paul Jones (tsdomain\pjones\Password123!)

– Sarah Young (tsdomain\syoung\Password123!)

Session Collections:


– Human Resources

– ts1.tsdomain.local

– Finance

– ts2.tsdomain.local

– ts3.tsdomain.local

Setting up the Human Resources Collection:

I will setup User Profile Disks later, so un-tick that option and then continue:

Once complete, you will be able to see your collections in Server Manager:

If you highlight the collection itself on the left, you can edit the properties of the Session Collection itself in a bit more detail:

At this point you should now be able to logon as a user through the RD Web Access Gateway and selecting the Session Collection you have assigned to that user:

For Example: Jenny Smith in Human Resources:

As you can see above, I have successfully logged in as Jenny Smith.


Note: If you are using a Self Signed Certificate, you will need to get it installed before you will connect, look out for hidden certificate prompts behind other windows you may have open.


Setting up User Profile Disks

There are two main steps when setting up User Profile Disks (UPD for short):

  1. Creating the NTFS Share where the vhdx files will live
  2. Enabling and configuring UPD’s on the Session Collections


Creating User Profile Share

Logon to your Share Server, in this case I am using:

– 1 x Domain Member Server

Roles Applied: Domain Member, File and Storage Services

Hostname: fs1.tsdomain.local

Please Note: You will need to create a separate UPD Share for each Session Collection that you are enabling UPD’s on, you cannot use a single share for UPD across Session Collections

Create the folder where you are going to store your UPD’s:

From “Server Manager” go to “File and Storage Services” > “Shares” > “Tasks” > “New Share“.


We will use the “SMB Share – Quick” option:

Specify the “Share Location“, set to the folder you created earlier:

Specify the “Share name“:

Review additional settings, I left them default:

Review permissions, again I left them default:

Review the details, and “Create” to confirm and apply changes:

You will now see the Share in Server Manager > File and Storage Services > Shares:

Now that the share is setup you can configure/add UPD’s to the existing Session Collections.

Log onto your RD Connection Broker, DC2.tsdomain.local and navigate to your Collections, select the Session Collection you want to add UPD’s to and from the Properties box > “Tasks” > “Edit Properties“:

In the Session Collection properties, select “User Profile Disks“:

Configure User Profile Disks:

– Check the “Enable User Profile Disks” tick box

– Set the “Location” to the share created previously

– Set the Max size of the disks

– Set the Data settings:

You can choose to store ALL user settings or only certain profile folders. I chose the “All User Settings” option by default.

If you scroll down further, you have the option of included custom folders outside the default options:

I left this blank as I have no requirement for this. Click Ok/Apply to confirm the change. Once complete you should see the VHD Template in the share directory:

When you then login as a user you will see their UPD created after they login from the template:

That’s it, User Profile Disks are now enabled, meaning which ever Session Host they connect to, their profile will follow.