If you would like to read the other articles in the series please go here:
- Scripting for Server Based Computing: Part 2 – Terminal Services Server and Connection Setting
- Scripting for Server Based Computing: Part 3 – Citrix Presentation Server Scripting
Introduction
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.
Tab
Attribute Name
Attribute Script Name
Possible Values
Remote Control
Enable Remote Control
EnableRemoteControl
0-4, See Figure 2 for more details
Require User’s Permission
EnableRemoteControl
0-4, See Figure 2 for more details
Level of Control (View or Interact)
EnableRemoteControl
0-4, See Figure 2 for more details
Terminal Services Profile
Profile Path
TerminalServicesProfilePath
String, Path to some Directory
Home Folder Local Path
TerminalServicesHomeDirectory
String, Path to some Directory
Home Folder Connect: To:
TerminalServicesHomeDrive
String, Drive Letter
Allow Logon to Terminal Server
AllowLogon
0-1, 0=Disabled, 1=Enabled
Sessions
End a Disconnected Session
MaxDisconnectionTime
Number, in minutes
Active Session Limit
MaxConnectionTime
Number, in minutes
Idle Session Limit
MaxIdleTime
Number, in minutes
When a session limit… Disconnect or End
BrokenConnectionAction
0-1, 0=Disconnect, 1=End
All Reconnection… From Any Client or From Originating Client Only
ReconnectionAction
0-1, 0=Any, 1=Originating
Environment
Start the following program at logon Program File Name:
TerminalServicesInitialProgram
String, Path to Executable
Start the following program at logon Start In:
TerminalServicesWorkDirectory
String, Path to Working Directory
Connect Client Drives at Logon
ConnectClientDrivesAtLogon
0-1, 0=Disabled, 1=Enabled
Connect Client Printers at Logon
ConnectClientPrintersAtLogon
0-1, 0=Disabled, 1=Enabled
Default to Main Client Printer
DefaultToMainPrinter
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 “Andy-land.com” 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
UserOBJ.SetInfo
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”)
‘REMOTE CONTROL ATTRIBUTES SECTION
UserOBJ.EnableRemoteControl = 0 ‘VALUES RANGE FROM 0-4, SEE TABLE 2 FOR EXPLAINATION‘TERMINAL SERVICES PROFILE ATTRIBUTES SECTION
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‘SESSIONS ATTRIBUTES SECTION
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‘ENVIRONMENT ATTRIBUTES SECTION
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‘DO NOT FORGET TO SET THE CHANGES
UserOBJ.SetInfo
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
Disable
0
Enabled, Require User’s Permission, Interact
EnabledInputNotify
1
Enabled, NO Require User’s Permission, Interact
EnabledInputNoNotify
2
Enabled, Require User’s Permission, View ONLY
EnabledNoInputNotify
3
Enabled, NO Require User’s Permission, View ONLY
EnabledNoInputNoNotify
4
Table 2: EnableRemoteControl Attribute Value
Conclusion
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:
