Building a kiosk computer walkthrough

Before you read on, you can press play on the video below to watch Senior Technical Writer Steve Dodson from Binary Research International walk you through the basics of building a Kiosk Computer. The video demonstrates the essentials presented on this page.

Step 1 of 3: Creating a menu

The first thing we need to do is to create a menu. At first we can just start it from the script editor for later installation through the OU Group Policies. If we just want the computer to start one specific application, we can just write a script line to do that one thing at startup, for example starting a published Citrix XenApp Desktop using the ShowIcaApp command followed by a ShutDown command. In this case we will show a menu of choices.

Let us use the example from the Citrix page as a template, which mixes an offering of locally installed applications and Remote Desktop and Citrix XenApp remote sessions. You can insert this example in the script editor by selecting "Kiosk Menu" in the "New Script" window.
This will show the menu below. While you are testing on your own computer, you should replace the ShutDown command with an Exit command to avoid shutting down your computer, when exiting the menu. The initial ResumeOnError should be present, because in case of a problem launching a menu item, the script must continue to avoid terminating the script itself and rendering the kiosk computer with no shell.


We need to compile our script into an exe file. Hit F10 or select "Create Exe File" -> "Compile Script To Exe File" in the script editor menu. Save the exe file as "FSHShell.exe" on the netlogon share.


If you need more than one type of kiosk computer, you can handle it two ways. You can duplicate the whole setup using more OUs and shell exe files, but if the kiosk computers are relatively similar, you can use one OU and shell exe file and control the menu by computer security groups in the menu script. An example of this can be seen on the RemoteApp launchers page, but ComputerIsMemberOf must be used instead of UserIsMemberOf, as this script must be based on computer groups instead of user groups.

Step 2 of 3: Creating an installation script

Now we have a shell exe file ready and the next thing we need is a script to install the shell and make a few machine modifications. The way this script will be deployed is by compiling it into an msi file and then set up as a software installation for the OU that we will be creating later. The script we will use, looks like the below. You can insert this example in the script editor by selecting "Kiosk Installer" in the "New Script" window.
If we look at the MSI page, it says that when you compile a FastTrack script into an MSI installation file, the command-line parameter "Action" is passed, which contains either "Install" or "Uninstall", depending on the context. When you drag a computer into the OU, the MSI file is installed and the "Action" command-line parameter value will contain "Install". When you drag a computer out of the OU, the script is uninstalled and the value then contains "Uninstall". In other words, the first half of the script is executed when a computer is removed from the OU and the second half is executed, when a computer is added to the OU.

The command EnableAutoLogon command needs credentials to log on automatically to the computers. In the next section, the creation of the user is explained. Correct the domain "acme" to your domain and decide on a password to use for KioskUser before saving the script.

Let us first compile the script into an MSI file to understand the context of use, before analyzing the script further. Save the script and go to the menu named "Create Msi File" and select "Compile Script Into Msi File":



You could also have included the FSHShell.exe file inside and msi file by using "Compile Project To Msi File", but leaving the FSHShell.exe on a network location instead allows you to change it at any time without requiring a new deployment each time.

It is important to pay attention to the version number, because in case you need to update existing computers, you can just generate a new MSI file, increase the version number and replace the OU software package. Because the installation name is the same, FastTrack will automatically later identify the package as the same software in an updated version, which again will invoke what is called "major update" in Windows Installer. The "Major Update" feature ensures that existing installations are updated instead of installing another copy. This is explained on the MSI page.

If we go back to the script above, the script basically does this on install (and the opposite on uninstall):

• Disables the services for USB, CD-ROMs, DVDs and legacy floppy disks. While it may not be necessary, it is still possible to open a document from a usb stick, if word or excel were offered as a menu choice.
• Sets auto logon for a specific user. This must be a user in the same OU as the kiosk computers - see next section.
• Points the shell process to FSHShell.exe on any copy of the netlogon share instead of Explorer.exe.

Step 3 of 3: Setting up the OU and GPO

The last step is creating the OU and Group Policies for this OU. Create a new OU for example called "Kiosk Computers". Inside this OU, create a user for example called "KioskUser". This user must NOT have password expiration, as no one knows the password. The username and password you selected in the installation script must be used. This user will be used as the user that logs on to all computers in the OU. The new OU with the kiosk user looks like this:


Note that you could also decide to remove the auto logon command and let each user log on to the computer first and have the menu served. This could make a lot of sense in many scenarios, but there is a tradeoff that you must be aware of. Your users are then not in the above OU and therefore you would have to apply lock-down Group Policy settings (explained further down) outside the new OU to these users. This means they apply to all computers these users log onto, because it the same set of Group Policies that each user has on all computers. So if you decide to let users log on to the workstation, you are not able to lock the task manager and other ctrl+alt+del offerings, unless you move the users to the new OU also, but then you must make sure they never use non-kiosk computers.

Next step is to create Group Policies that only applies to this OU. Start "Group Policy Management" under "Administrative Tools" on a domain controller, identify the new OU and create and edit a new policy called for example "Kiosk Policy":




The first thing we need to do with the group policy is to install our MSI file on all computers that are dragged into the OU. Select a new Software installation and make sure that you set the installation under Computer Configuration and not User Configuration:


You must now place the "Kiosk Shell.msi" in a location which can be reached from clients, for example your netlogon share and point the package to this file. After creating the package, it is extremely important that you open properties on the package, select the "Deployment" tab and check "Uninstall this application when it falls out of the scope of management" (see below). If you don't set this checkmark, your shell will not be restored, if you drag a computer out of the OU.


Now everything is set up and you can drag computers into the OU and next time they restart, the computers are kiosk computers like the one in the movie at the top.

There is one detail left though. If we lookup Kiosk Software at wikipedia here, there is a consensus that kiosk software means locking down the computer. The example on this page should be sufficient for locking down, but you can expand Group Polices and scripts to your needs. The best way around this is to make your own list of what you would want to lock down and if it is not covered on this page, Google each topic for group policy settings, registry keys, etc. Everything can be locked down, preferably with Group Policies, and secondarily with computer modification that can be included in the step 2 installation script. The USB, CD-ROM, DVD and floppy disk blocking is an example of the latter, where the only way to do it is to stop the corresponding services.

One thing that always makes sense on kiosk computers is to disable all ctrl+alt+del options and make sure that the computer never prompts for password, as the user will not know the password for the "KioskUser". Some settings are not possible to set per machine. For example disabling the task manager was possible to set per machine until Windows 7, but was never truly supported by Microsoft, so best practice is to pay attention to what is supported by Microsoft and what is not, to make sure everything works on future versions of Windows.

The password prompt settings and ctrl+alt+del options are only officially supported per user, and this was why our KioskUser was created in the same OU. If it wasn't, it would not be covered by the group policy we created and if we let the user themselves log on, they would also not be covered by the policies. So first we need to make sure that password prompt is disabled for screensavers and resume:



The next thing to do is to remove all options, when ctrl+alt+del is pressed. Normally options are available to lock the computer, switch user, log off, change password and start the task manager. We need to disable all these settings, so when a user hits ctrl+alt+del, no options but shutdown are offered, as shown below.




If the "KioskUser" must share a common logon script to map drives and printers, you can use "If UserIsInOU KIOSK Computer Then" condition to differentiate the logon script for this user.

Now everything is ready. When a computer must be converted into a kiosk computer, the computer can just be dragged into the OU, as shown below, and when dragged out of the OU, the computer is restored to a normal desktop.