Installing Applications

And assuming you have a purpose for your TS, there is a big chance you are setting all this up to provide users access to one or more applications either at the office or from home. If this is indeed the case we must go ahead and install applications. The main point here is very simple to understand: in a way TS is no different than any other regular PC and therefore installing applications is not really rocket science. But given the way TS works, there are some small differences that you must pay attention to. By following these simple rules (and understanding them) will save you time and headaches with TS in the future.

Basic Concepts

TS works as a multiuser ‘workstation’; multiple users, at the same time, logon to the TS and run applications. This may introduce a problem with these applications as in many cases they were not developed with TS in mind (meaning multiple instances of the application, running under different user accounts, at the SAME time on the SAME machine). To alleviate such problem, TS has something called ‘Install Mode’.

This mode is triggered when you install applications using Control Panel | Add/Remove Programs or if you open a command prompt and type CHANGE USER /INSTALL before installing the application. When this mode is triggered, the TS will track all registry entries and files created by the application to determine what users need to run it, on a per-user basis (i.e. if an application uses a .INI file under \Windows, the TS will copy such file under the user profile so each user has its own, unique .INI file).

ι When installing an application, if the application asks you for a reboot, do NOT reboot the server until you put the server back in EXECUTE mode. If using the command prompt you can trigger this mode by typing CHANGE USER /EXECUTE; when using Control Panel | Add/Remove Programs, simply choose not to reboot the server and click ‘Next’ on the wizard that will show up when installing applications. Just as a side note, all the information recorded when installing an application in install mode is stored under HKLM\Software\Microsoft\Windows NT\Current Version\Terminal Server\Install.

This is the main reason why it is very important to install applications using Control Panel | Add/Remove Programs is to allow the TS to track whatever is needed to make the application multiuser aware. If you follow this simple rule you will avoid a lot of issues with your TS setup.

Application Control

Now that you have applications installed on your terminal server, how do you control access to them? How to make sure users do not run applications they do not have rights to? That is exactly what Application Control means. Giving access to the right applications to the right users.

ι One of the steps usually required to do this is to use Group Policies to redirect certain folders (i.e. Start Menu) on the system to a network location. As this we will be covering this later on this guide, all group policies related steps will have to wait for now.

I am assuming at this stage that your users will be connecting to the TS and they will be presented with a Windows Server 2003 desktop. Once that is in place users will then go to the Start Menu to launch the applications they have access to.

The first step I usually recommend is to create application groups on AD (i.e. MS Office Pro, MS Office Std, SAP7, MS Project, etc) and also language groups (if you will be using MUI to deliver different languages for the TS desktop, all coming from the same TS; in this case create groups like TS English Users, TS French Users, etc).

Some people prefer to create department groups instead (i.e. TS Finance, TS Sales, TS Engineering, etc). Choose whatever you think works best for you. Here, there is no right or wrong way of doing things: both will achieve the same results but one may be easier or make more sense for your particular needs.

The idea here is very simple. Once you have these groups, the first step is to assign NTFS permissions to the application executables only to the groups that need access to that particular application (i.e. assign read/execute rights to the WINWORD.EXE file only to the MS Office Pro and MS Office Std groups; this way if someone is not on this group they will not be able to launch such executables). There are several ways to do this. There is always the manual way, that works well if you have one or two TSs. As these are really permissions being assigned to groups, you can easily script something that will use CACLS.EXE or XCACLS.VBS to set these. For more information please check this article:

How to use Xcacls.vbs to modify NTFS permissions
http://support.microsoft.com/kb/825751

The second step of course is to change the start menu based on the group membership so users will only see the applications they have access to.

If you follow these two simple steps you will end up with a well setup TS that will save you a lot of troubles down the road.

Application Troubleshooting

If you have made it this far, by now you should have at least one working TS, with applications locked down to run only by users that have access to them.

The next step is to understand what can go wrong with applications in a TS environment and where to look at when issues arise. This section will not make you an application expert but will give you a very good understanding on how to find issues on a TS environment and how to fix these.

You may think there is a lot to be covered here. Nope, that is not the case. TS is in a way, extremely simple and once you get the hang of troubleshooting applications you will notice how simple (not to mention repetitive) these steps are!

Tools

Application issues in TS are usually related to permissions. The typical example is an application that works when you logon as administrator but does NOT work when you logon as a regular user. Before we take a look at the tools you need to find where the problem is, let me refresh your memory with one simple thing. Do you remember when installing the TS, the step where it asked you if the TS was supposed to be in ‘Full Security’ or ‘Relaxed Security’? If you do remember, this is the first, simple step you can take in this case.

If the TS is set to ‘Full Security’, launch TSCC.MSC on it and change it to ‘Relaxed Security’ and then ask the user to logon and try running the application again. If it works you know for sure it is permissions related. And that is when the right tools come to the picture.

This is the basic toolbox you should have to troubleshoot applications under TS and I will briefly explain each and how to use them.

REGMON: a simple and powerful tool that monitors everything that is going on in the registry (reads, writes, etc) and the results of such actions. For example if an application is trying to read a registry key and the user has no access to it you will see an ‘ACCESS_DENIED’ message on the regmon log. You can download it here:
http://www.microsoft.com/technet/sysinternals/processesandthreads/regmon.mspx

FILEMON: the file system equivalent of Regmon. Every time something accesses the file system Filemon will show that and the result. If an application is trying to read a file the user has no access to, an ‘ACCESS_DENIED’ message will be shown in the logs. You can download it here:
http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx

ι Regmon and Filemon were combined into a single tool, now called Process Monitor. It replaces both tools but the idea remains exactly the same. You can get it here:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Now that we have the tool (let’s use Process Monitor) let’s come up with an example to show how to use them. On this test I will change the NTFS permissions for NOTEPAD.EXE and will deny access to my test user. By using Process Monitor we will be able to see the issue and how to fix it. The steps we will follow should be applied when troubleshooting any application under TS.

Error launching Notepad as a regular user

Looking for an ‘Access Denied’ error

‘ACCESS DENIED’ error on Process Monitor

The idea in this section was not to make you an application expert overnight and I am sure that is not the case right now after reading this far; but with the steps and tools described above you will be able to troubleshoot and fix almost all application issues that happen in a terminal services environment.

ι One thing that is definitely worth mentioning is the use of ‘Application Flags’ when trying to fix certain issues. One typical example is an application that works when the TS is in install mode (remember, CHANGE USER /INSTALL) but not when in execution mode (after you issue the CHANGE USER /EXECUTE command, once the application install is complete). This usually has to do with the application looking for certain files under C:\Windows (the real Windows directory) and not the redirected one that TS uses for users (under their profile/home directory usually). Once you set a flag for this (0x00000080) everything starts to work properly!
For more information on all the available flags and how to use them please check this article:
http://technet2.microsoft.com/windowsserver/en/library/df78c476-00d5-41f0-a21d-e1e12e3d1f8b1033.mspx?mfr=true