The example script

Stripped of comments, the example script presented further down is only 30 script lines and will basically do the following:

• Gives you control over client naming. The example script will use sequential names and formatting to your preference
• Automatically re-use computer names by looking at the mac address when re-installing clients
• Join the domain without having plain text passwords in answers files or opening up unsecure domain joins
• Optionally put clients in a different organizational unit to avoid the manual step of prestaging computers
• Create an extra local admin account for offline servicing, to protect the built in administrator password
• Put an Active Directory group into the local administrators group, in the example a group called HelpDeskUsers
• Install additional files and settings from a single repository, to avoid having a copy for every install image
• Create a local folder for local sharing and give all users full control over the folder

In this example script, we will take over the process of joining the domain and your Windows answer files must be stripped of domain join information. The password used in the example script to join the domain is encrypted, which removes the need for an easy-to-retrieve plain text admin password in Windows answer files, opening up unsecure domain joins or using manual prestaging.

Hooking into the deployment process

In this section, we will deploy Windows 7 through WDS, Windows Deployment Services (formerly RIS, Remote Installation Services). The technique is the same for all other versions of Windows; we will be using the $OEM$ structure of a Windows install image to get our custom files to the installing client, which is documented here on TechNet.

As a note, this article is also valid for other means of distribution, such as SCCM or sysprep'ed cloning technology. The principles are the same; as described in the link above. We basically just need to get the 4 files (see further down) into the %WinDir%\Setup\Scripts folder during the installation process, which is done by simply placing the 4 files in the source image under Sources\$OEM$\$$\Setup\Scripts. For example, if you are using SCCM 2007, we would place the 4 files under \\AcmeServer\Images$\Win7x64Pro\sources\$OEM$\$$\Setup\Scripts, if the operating system image is located in \\AcmeServer\Images$\Win7x64Pro:



In this example we will use Windows Deployment Services (WDS) to push the image out. If you are unfamiliar with WDS or unattended Windows 7 deployments, please refer to the documentation from Microsoft on WDS or the Windows 7 Step-by-Step Deployment guide.

We need to get a FastTrack Script executed as part of the installation process. To do this, we will use the Windows feature that looks for a file called SetupComplete.cmd before the final reboot, as explained here. For this we need 4 files. To get them to the client before the installation is complete, we will use WDS' OEM structure to avoid having to modify any image files. If you have already setup unattended Windows 7 installations through WDS, you can simply follow this procedure to get a script executed without modifying your existing images.

Locate your "Images" folder under your WDS remote install folder. We will create a file structure for one of the images and then copy the same files to the other image directories. Create a structure for any one of your image files named: ImageFileNameWithoutExtension\$OEM$\$$\Setup\Scripts:


Under the "Scripts" folder, place these 4 files:

• A copy of FSH.Exe
• A copy of FSH.Lic
• A batch file named SetupComplete.cmd (see content below)
• A script file named Preinstall.fsh (see example content in next section)

Any content under $OEM$\$$ will be copied by WDS to your clients' Windows directory during the installation process. As Windows setup looks for a file called SetupComplete.cmd, we will need to use that to get our script named Preinstall.fsh to execute. Thus the content of the file will be this:
Your final structure will look like this:



Copy the directory structure to each of your installation images, each time replacing "ImageFileNameWithoutExtension" in the structure ImageFileNameWithoutExtension\$OEM$\$$\Setup\Scripts by the name of the image file without extension. At the end of the installation, the Preinstall.fsh script will execute before the final reboot. In our example script, we show a splash screen inside the script and the final step of the Windows 7 installation will look like this:

Example script (Preinstall.fsh)

In the previous section we talked about how to get a script to execute before the final reboot and in this section, we will present an example script. The script requires FastTrack Scripting Host 6.1 (or newer) and if you have at least version 6.1 installed, it is directly available in the script editor: Go to the "Documentation" tab, select "Windows 7 Deployment Script" under the "Insert Example Script" submenu. The script is explained in detail in the next section.

To construct and test a script of this type, it is not necessary to run a full Windows installation for every test iteration. Just execute it on a computer that is not in the domain. To test again, unjoin the domain and repeat this procedure until the script is finalized.

The script is an example, any undesired functionality can be removed and your own additional custom scripting can be inserted. The first 7 script lines in the example must be modified with your custom information:

• Credentials for the executing domain admin user
• UNC path to a share that contains client files (the script will create two files in the root first time executed)
• Credentials of the additional local administrator account created
• The name of an Active Directory group that will be put into the local administrators group

Both passwords must be encrypted in the script editor by selecting "Encrypt Password" in the "Tools" menu. For further details, look at the next section for the details in the example script.

Do NOT run the script on your own computer. Unless the script fails to connect the share, it will rename the executing computer.

The script explained

The script will connect a network share called W: with the supplied credentials. This share can be any share on the network and must contain a folder named "ClientFiles", which contains files that will be copied to all clients. Furthermore, the first time the script is executed, two xml files will be created in the root, to keep track of client naming and for re-using computer names, when re-installing clients. There are no special requirements for this share. Just create a folder on a server, share it and place a "ClientFiles" directory in it. We will refer to this share as the distribution share from here on.

Computer naming

In the root of the distribution share, an xml file will be created the first time the script is executed and it contains a sequence counter that can be changed at any time. The name Acme, number of decimals, and other computer name formatting can be edited in the script itself.

If the computer must be placed in a specific organizational unit, simply use the JoinDomainAndOU instead of JoinDomain in the script. If there are multiple naming formats or multiple OU's to place computers in, you can create multiple copies of your install images with different Preinstall.fsh files. Alternatively, a menu could be shown, asking for a list of choices to feed to SetComputerName and JoinDomainAndOU. This would however break the idea of a completely unattended installation.

If you already have computers and want to start with a higher sequence count, simply create a ClientSequence.XML file in the root of the distribution share with a default content, as shown below, assuming first computer should be 400 in the sequence.

Re-using computer names

Each time a new computer name is created, the mac address and the computer name is stored in a file called Clients.XML in the root of the distribution share. The purpose of this file is for the script to detect when a computer is re-installed, to avoid having obsolete accounts in the domain. After installing the first client, the file would look like this (with a different MAC address):
When the script is executed, the script looks in the file for a node called MAC_xxxxxxxxxxxx where the x's is the mac address of the fastest network adapter in the computer. If a value is returned (Acme0001 in the case the mac address is 00155D010136), this name is used and a new name is not created.

Putting an additional group into the local administrators group

The intention with this operation is to give a certain group, which is not a member of domain admins, local administrator permissions. This could typically be Help Desk users that need to service the computer.

The executing user is not a domain user, thus credentials to the domain must be established to get access to domain objects, in this case an Active Directory group. To establish credentials, the domain admin user is impersonated with the ImpersonateUser command. The next command, AddGroupToLocalGroup, will put a group into the local administrators group using the impersonated credentials.

Additional administrator account

An additional administrator account is created. The purpose of this is to avoid having to give the local administrator password to service operators, in case the computer needs to be serviced offline.

Local writable folder

A folder called C:\AcmeShared is created and any user will get full control over the folder. The purpose is to let users share files locally that are not needed to be backed up and take up network storage.

SelfInstall

The SelfInstall command will copy the executing engine (from %WinDir%\Setup\Scripts) and the license file to "FastTrack Software\FastTrack Scripting Host" under the Program Files directory and associate the .fsh extension to the exe file. This will allow execution of .fsh files on the computer without specifying where the exe file is located.

If you are using FastTrack Logon for logon scripts: It is important to understand that when using FastTrack Logon, it will copy its own copy of the engine to the user's profile, execute the login script with this copy and make a user association to .fsh files to this copy. If the user then executes an .fsh file, it will be this copy that is executing the script. If the system, a local user or a user that does not use FastTrack login executes a script, it will be the copy installed under Program Files. This is because a user file association superseds a system file association. And the reason why this is important to know, is that if at some point in the future a newer version is used for login scripts, this will not be a problem because FastTrack Logon's copy will supersed a system installed copy of the engine.

Copying of additional files

On the administrative share, any files under a folder named "ClientFiles" will be copied to the same locations on the client. If there for instance is a folder named Program Files\Acme, this will be placed in the same structure on the client.

This can also be accomplished by putting these files inside install images, but usually this means there are multiple copies of the same client files, increasing maintenance time and the chance of inconsistency.

Typically there would be further scripted manipulation related to your additional files, like creating shortcuts in the default user's profile, setting registry values related to the files, etc. These things can easily be inserted after the copying. Also, if you have scripted your installations, these could also be included with simple include commands. See unattended installation for more details on scripted installations.

FastTrack Inventory

One last note is relation to unattended installations of Windows. If you don't have a management system, you don't know what is installed on which computers, who has what computer or what hardware is in which computer.

FastTrack Scripting Host comes with a cloud-based inventory system that has no setup steps and is free for licensed customers. You can just include this one simple command in your unattended script to upload inventory information: UploadInventory With this one command, you will have full hardware and software inventory of your computers. It is a good idea to include this same command in your regular logon script also, as the upload will then include information about who logged on to the computer the last time. FastTrack Inventory has no additional cost; it just requires your clients to be licensed and within maintenance period. Refer to this page for more information on FastTrack Inventory.