NW Doc

How can I install the Remote Desktop Connection 5.2 client by use of GPO (Group Policy Objects)?

RDP (Remote Desktop Protocol) client is the client-side component of the Terminal Server connection. In order to allow a client to connect to a TS, the client needs to install the RDP client on their machine.

The RDP client can be installed by use of one of 3 methods:

• Local manual installation

• Login script initiated script

• Group Policy initiated installation

In this article we will focus on the 3rd option. Naturally, the steps described here will also work for any other software installation, as long as it is packaged as an .MSI file.

System requirements

In order to install (anything) via GPO you will need the following:

• Active Directory in place (Windows 2000/2003 AD)

• Client machines that are part of the domain

• Client machines running W2K and beyond.

• Proper administrative rights

Note: In case you cannot install the RDP client on the computer you're working at (in situations where you don't have the necessary rights for example) you can still connect to the TS by using the Remote Desktop Web Connection component. Read Download Remote Desktop Web Connection for Windows Server 2003 and Install Remote Desktop Web Connection on Windows Server 2003 for more info.

Obtaining the RDP client installation file

One of the best TS clients is the Microsoft RDP client (others exist, but we won't discuss them here). The RDP client was first introduced in Windows XP (version 5.1), and was later upgraded (version 5.2 in SP2 and Windows Server 2003). Last year RDP client was upgraded to the latest version -

(Note the new Security tab and the version number)

You can get the new RDP version from any Windows Server 2003 SP1 installation - Look for it in the %systemroot%system32clientstsclient folder.

If you don't have a Windows Server 2003 computer accessible, you can also download the file from the Microsoft's site (Download RDP 5.2 (Old Version)), but after downloading it you will need to extract its content.

Extract the msrdpcli.msi file from the archive

As said above, after obtaining the file called msrdpcli.exe from Microsoft's website you will now need to extract the files from it. In order to do so you should install some 3rd-party extracting tool such as WinZip or WinRAR.

Lamer note: You do NOT need to perform the following action if the file you've obtained is already named msrdpcli.msi.

Navigate to the folder where you've placed the msrdpcli.exe file, and right-click it:

Choose either the WinZip or the WinRAR context menu and select the command that'll extract the files from the archive.

You will find a few files that were extracted from the archive. We do not need them for this guide, however you do need to copy the one file called msrdpcli.msi. The file's size and attributes may vary as there are at least 3 versions of the RDP client. The latest version that can be freely downloaded from Microsoft's site is v5.2.3790.0. This version's size is 922kb.

In case you've copied the msrdpcli.msi file directly from the %systemroot%system32clientstsclient folder on a Post SP1 Windows Server 2003 computer, the file's version will be v5.2.3790.1830 and its size will be 959kb. This is currently the latest version available, and it can also be obtained from the Download RDP 5.2 page.

Whatever version you're using, just copy it. We will need it in a second.

Creating the installation point

You will need to create a network share and place the msrdpcli.msi file in it. You could do so on one of your servers (you could use one of your Domain Controllers, depending on the number of clients on your network).

Let's assume you're using one server called zeus and that the network share you'll create will be located on that server. Let's assume that server is also a Domain Controller.

1. Open Windows Explorer, navigate to one of your partitions, create a folder (I'll call it RDP Client, just for the purpose of this article).
2. Right-click that folder and choose Sharing and Security.

3. Give the share a name. It's best to use a short name of less than 8 characters, but you can use any name you want. You can also add a $ sign after the name in order to hide the share from curious eyes (note that this however won't protect the share's content, it will only hide it from unknowing users). I've named the share RDP_Client$.

4. Grant the Everyone group Read access for the share. On Windows Server 2003 this is the default. You do not need more than that in order for the users to be able to install the software.
5. Click Ok all the way out.
6. Check to see if the share is accessible from the network by typing 'servernamesharename (in our case - 'zeusRDP_Client$). If the share opens in a new window, we're set.
7. Needless to say, you need to paste the msrdpcli.msi file in that share, duh...

Note that in some cases, with a large network containing many users, one installation point won't be enough. You will then need to use some load balancing method such as DFS (Distributed File System) and replicas of the content inside, but that's for a different article.

Choosing computer account or user account-based installation

The next decision you need to make is whether to install the software on the computers based on the computer's account location, or based upon the user's account location. For example, if in your AD infrastructure you have an OU called Workstations OU, and, OU called Sales OU and a third one called IT OU:

Lets say you decided to configure the software to be installed on all the users in the Sales OU. Then the GPO will need to be linked to the Sales OU, and the software will need to be configured on the User Configuration part of that GPO:

You will now link this GPO to the Sales OU (or to the IT OU, or to both, depending on your choice). If you choose this option, the software can be installed in one of two methods:

• Published - Which means that it won't be actually installed, the user will need to manually install it from the Add/Remove Programs applet in the Control Panel.
• Assigned - Which means the software will "seam" to be installed, it will show in the Programs folder on the Start menu, but it won't actually do anything. The first time a user clicks the shortcut, it will automatically be installed.

However, if you choose to install the software for all the computers in the company, and these computers have their computer accounts in the Workstations OU, then you will need to configure the software installation on the Computer Configuration part of that GPO:

As a "bonus" of this option you will also get the added value of installing the software as a mandatory installation to the computer, and it will be installed during the computer's booting, right before the CTRL-ALT-DEL screen appears. That means that software installed to the Computer Configuration part of the GPO can only be Assigned, and not Published, as with the Users Configuration option. However, unlike the Assigned option in the User Configuration, the software will fully install itself and not "wait" for the first use of it by the user.

You will then have to link this GPO to the Workstations OU.

Creating or editing the Group Policy Object (GPO)

You will now need to decide what scope will your GPO cover. For example, will you need to install the software for ALL your users/computers, or just for some of them, according to some internal company logic. Based upon your design you will need to either edit an existing GPO, or create and edit a new one. This GPO will need to be linked to the right OU, or to the entire domain or site, depending on your design. I will not go into this area in this article, perhaps in a future one.

Lets say you need to create a new GPO and want to link the new GPO to the Sales OU:

1. Open Group Policy Management Console (GPMC). You don't have GPMC yet? Bad boy! Read Download GPMC for more info.
2. Expand the domain tree, right-click Group Policy Objects, and choose New.

3. Enter a descriptive name for the new GPO, press Ok.

4. Right-click the new GPO and select Edit.

5. In the new GPO editor window select either the Computer Configuration part of the GPO or the User Configuration part of the GPO, depending on the choice you made in the previous step. Expand it, go to Software Settings > Software Installation. Right-Click Software Installation and choose New > Package.

(I chose the User Configuration option)

6. In the Open window, make sure you manually type in the full network path (UNC path) to the installation point (to remind you, in our case it's 'zeusRDP_Client$). Do NOT make the mistake of browsing to the local location of the file, you MUST provide the network path to the share.

This is where the msrdpcli.msi file is supposed to be waiting for you. Click to select the file, then click Open.

7. In the Deploy Software window click on the right choice based on the decision you made in the previous step. I chose Assigned.

8. The new installation package will appear on the right pane.

That's it, you're done.

Now, in order for the new installation to work, you'll need to wait for AD replication to finish (depending on the size of your AD infrastructure, this can take anywhere from a few seconds to a day or two, but assuming you're using 2 or 3 DCs, this'll take a minute or less).

Next, ask your user(s) to reboot their computer. In some cases a refresh of the GPO (gpupdate /force) and/or a logoff will be enough, but we need to make sure.

Ask the user to look for a window saying "Software installation" right before the CTRL-ALT-DEL window appears (in case of a Computer-based installation), or right after it (in case of a User-based installation). Ask them to look for the program in the Start menu.

If something doesn't work right, you can begin to troubleshoot by looking at replication issues, permissions, GPO inheritance and filtering, and at event ids. But that's for a different article.