Scripting for Server Based Computing: Part 1 – Terminal Services Attributes for Active Directory User Objects

If you would like to read the other articles in the series please go here:


Scripting. Love it or hate it, scripting has become a very powerful tool in the Windows world for administration. We have long had the ability to script with untold numbers of shell and scripting-specific languages in the Linux/Unix world. Many administrators have long held the belief that scripting was the “old way”; unnecessary, out-dated and even quaint when compared with a Graphical User Interface such as the Windows Explorer Shell. Why would I need scripting when I can accomplish the same task faster through the GUI?

Times, they are a changing… Scripting has evolved over the last several years (and platform releases) to include some amazingly powerful capabilities. The top of those abilities are to centrally configure nearly EVERY aspect of a Windows Server 2003 server’s settings, permission, rights, etc. Scripting has matured, with the Windows platform, to become an administrator’s best friend. In this article series, we will explore the ways in which scripting can assist an administrator specifically around Terminal Services. At a minimum, there will be three parts to this article series (more depending on the popularity or improvements that Microsoft makes in the ability to script Terminal Services). The first three articles will focus on User Object Settings inside of an Active Directory domain, Terminal Services Configuration settings on a given server and scripting Citrix Presentation Server Settings.

Before we get too far down the road in this endeavor, I should first mention that there are dozens of scripting languages for the Windows platform from which we could choose. For the purpose of this article series, I am going to focus entirely on VBScript as the language and this language`s ability to access COM Objects, WMI queries and more. This information is presented with the assumption that the reader has some basic understanding of VBScript and Terminal Services as separate technologies. The goal of this article is to “bring them together” to aid our friends that know a little scripting and a little Terminal Services. It is also assumed that you will be executing the sample scripts with an account that has sufficient privilege to modify the objects in question. Also, the scripting examples below are only “guaranteed” to work on Windows Server 2003. Microsoft made great advancements in the scriptability of the server platform with Windows Server 2003 and thus most of the functionality leveraged in this article didn’t exist (as far as scripting was concerned) with Windows 2000 Server.

Let us begin with an investigation of how scripting can automate some of the settings for a given user’s object inside of an Active Directory structure. There are four tabs inside of a user object that we will concern ourselves with the settings thereof (as they pertain entirely to Terminal Services). While there are a myriad of options that could be scripted for a user object we will focus on the Remote Control, Terminal Services Profile, Sessions and Environment tabs. Take a look at figure 1 below for a visual of the tabs in the red circles.

Figure 1: Terminal Services-specific User Object Tabs

Without going into gory detail of the way VBScript can be used to modify elements of Active Directory, let’s start with the premise that each Object has a predefined list of Attributes. The Attributes that “define” that Object are controlled by the Schema in Active Directory (and can be increased by “extending the schema”). Think of an Object as a User Account, Group or Computer account (although there are more types of objects). Some Attributes (think of them as properties for the object) are required to be “configured”, some of the Attributes are editable and some are not. If we draw a comparison between a User Object in Active Directory and a “real” person it may make this more understandable. Every “real” person must have a name, so must every User Object in Active Directory, thus we have an example of a required Attribute. Not every “real” person has a home, nor does every User Object in AD have a “home” defined, thus our optional Attribute. While a name or the ownership of a home can change, certain things about “real” people and User Objects cannot be changed (or are not “easily” changed). Such is the case with a “real” person’s DNA and a User Objects Security Identifier (SID); these are not changeable without catastrophic results. The basics attributes as pertaining to Terminal Services for a given User Object are laid out below in Table 1. All of the Attributes listed in this table are “changeable”, though some require a bit more information to change than others.


Attribute Name

Attribute Script Name

Possible Values

Remote Control

Enable Remote Control


0-4, See Figure 2 for more details

Require User’s Permission


0-4, See Figure 2 for more details

Level of Control (View or Interact)


0-4, See Figure 2 for more details

Terminal Services Profile

Profile Path


String, Path to some Directory

Home Folder Local Path


String, Path to some Directory

Home Folder Connect: To:


String, Drive Letter

Allow Logon to Terminal Server


0-1, 0=Disabled, 1=Enabled


End a Disconnected Session


Number, in minutes

Active Session Limit


Number, in minutes

Idle Session Limit


Number, in minutes

When a session limit… Disconnect or End


0-1, 0=Disconnect, 1=End

All Reconnection… From Any Client or From Originating Client Only


0-1, 0=Any, 1=Originating


Start the following program at logon Program File Name:


String, Path to Executable


Start the following program at logon Start In:


String, Path to Working Directory

Connect Client Drives at Logon


0-1, 0=Disabled, 1=Enabled

Connect Client Printers at Logon


0-1, 0=Disabled, 1=Enabled

Default to Main Client Printer


0-1, 0=Disabled, 1=Enabled

Table 1: Terminal Services User Object Attributes

Now that we have the basics down, let us turn our attention to actually using some of these Attributes in a VBScript to modify a User Object in Active Directory.

The first step is to “bind” to the object in AD that we wish to modify. This can be accomplished by creating a variable to bind to the object with, such as UserOBJ (this will be our variable).

Set UserOBJ = GetObject(“LDAP://cn=ICA Turner,OU=Testers,dc=Andy-Land,dc=com”)

At this point we are “attached” and “bound” to the User Object “ICA Turner” in the Organizational Unit “Testers” in the “” Domain. Now we can have some fun and modify this account. The next step is simply to use our UserOBJ and the Attributes from Table 1 to make modifications. Let us assume that for this “test” run, we will do something as simple as DISABLING “Connect Client Drives at Logon”. It is fairly easy as seen below. Notice the addition of the “SetInfo”. This is used at the end so that the script that has “opened” the Object will write and commit the changes we are making.

UserOBJ.ConnectClientDrivesAtLogon = 0

Now let`s take a look at a COMPLETE script that will allow you to FULLY edit ALL of a User Objects Attributes as they pertain to Terminal Services. As the script progresses, I will place the standard ‘COMMENTS in the script for more detailed explanation where apropos.

Set UserOBJ = GetObject(“LDAP://cn=ICA Turner,OU=Testers,dc=Andy-Land,dc=com”)


UserOBJ.TerminalServicesProfilePath = “\\ProfileServerName\ProfileShare\” ‘UNC or Drive letter
UserOBJ.TerminalServicesHomeDirectory = “\\ProfileServerName\ProfileShare\” ‘UNC
UserOBJ.TerminalServicesHomeDrive = “Z:” ‘Letter to MAP the HOMEDIRECTORY UNC to
UserOBJ.AllowLogon = 0 ‘All this hard work and I put a 0 to disable the TS Logon?! A 1 would have enabled

UserOBJ.MaxDisconnectionTime = 60 ‘In Minutes, so 1 hour
UserOBJ.MaxConnectionTime= 600 ‘In Minutes, so 10 hours
UserOBJ.MaxIdleTime = 10 ‘Also in Minutes
UserOBJ.BrokenconnectionAction = 0 ‘0=Disconnect, 1=End
UserOBJ.ReconnectionAction = 0 ‘0=From Any Client, 1=From Originating Client Only

UserOBJ.TerminalServicesInitialProgram = “C:\Windows\Notepad.exe” ‘UNC or DRIVE Letter Path to the EXE
UserOBJ.TerminalServicesWorkDirectory = “H:\” ‘UNC or DRIVE Letter Path to scratch space for the EXE
UserOBJ.ConnectClientDrivesAtLogon = 0 ‘0=Disabled, 1=Enabled
UserOBJ.ConnectClientPrintersAtLogon = 0 ‘0=Disabled, 1=Enabled
UserOBJ.DefaultToMainPrinter = 0 ‘0=Disabled, 1=Enabled

Wscript.Echo “Done” ‘A little reminder that we are finished with the script

A section of the script above concerning REMOTE CONTROL requires further explanation. While in the GUI there are several options concerning the remote control settings, these correlate to a single Attribute with five values that can be configured to achieve the desired effect as described in Table 2 below.

Desired Result

Attribute Value

Value for Script

Disable Remote Control



Enabled, Require User’s Permission, Interact



Enabled, NO Require User’s Permission, Interact



Enabled, Require User’s Permission, View ONLY



Enabled, NO Require User’s Permission, View ONLY



Table 2: EnableRemoteControl Attribute Value


As you can see, scripting can be a terribly powerful and convenient mechanism to control Attributes of User Objects in Active Directory. With a little imagination, one could adapt this script to perform these setting changes on a complete OU structure thus making the script that much more useful. In the upcoming articles in this series, we will examine how to leverage scripting for controlling the Terminal Services service itself and interacting with the Citrix Presentation Server settings.

If you would like to read the other articles in the series please go here:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top