• 3886
• Login Automation Machine , PowerShell ,
• 06 Dec

My customer wanted to achieve a fully automated deployment of his terminal server environment. The Windows operating system is deployed with Microsoft Deployment Toolkit (MDT) and the applications are installed by Login Automated Machine (AM). After the installation of Microsoft Office (MS Office), the latest MS Office updates need to be installed. This is not only needed after a completely new installation of MS Office; the MS Office updates should be installed on a regular basis during maintenance windows to ensure the most secure and reliable MS Office experience for the users.

Windows Server Update Services (WSUS) is not used by the customer. Instead, WSUS Offline is used by the system administrators to deploy the updates needed. With WSUS Offline it is possible to update any computer running Microsoft Windows and Office safely, quickly and without an Internet connection. The product is developed by Torsten Wittrock and can be found by clicking on: WSUS Offline

The Windows updates are installed in an earlier stage during the operating system deployment. MS Office will be installed by Login AM; after the installation the updates should be installed. In this blog, I will show how I automated the MS Office update process and I hope it will help you to do the same if needed.

WSUS Offline is started by kicking off the command file “Update.cmd”. The logical next step is that Login AM starts the WSUS Offline command so that the updates will be installed. I created a list with requirements:

• There should be a created which will contain every action and outcome processed by the script.
• You want to be in control about when updates are installed and when not.
• The command (cmd) is started from a share. However, command files can’t be started from Universal Naming Convention (UNC) shares.

The script will be written in PowerShell. Login AM works together with PowerShell very well – and PowerShell is the logical choice if you want to manipulate Microsoft Windows.

Making a log file

Making a good log file is not only practical when bug fixing the PowerShell script. It is also needed if you want to know if all the actions are completed successfully and if unexpected behaviour has been recorded. I created a variable that is used for recording the current time. This is used in the log file. Text is added after the time entry that correspondents with what action has been completed or failed.

The variable will reoccur throughout the PowerShell script, each time with the current time and the corresponding action.

This way, it is possible to log what happens at every point throughout the PowerShell script. This results in a log file with all the actions at certain points in time. WSUS Offline has its own system of logging all the processes and actions.

When will the script run and install the updates?

WSUS Offline should be built with the selected updates that you as an administrator have selected for your environment. The building process leaves a text file behind with a build date.

On the target machine, there is no text file with a date   available. The idea is to start the updating process only if there is no text file with a date present. After the update process is completed, a text file with a date will be created on the target machine after the updates are installed. The dates in the two text files are now the same.

Another trigger to start the update process is that the target machine. In short, the WSUS Offline build is more recent and the new updates have to be installed on the target machine. Therefore, it is needed to compare the dates. I will explain below what key functions are needed to make this work.

Step 1: Check is there is a date file present on the target machine, if not update

If the date file does not exist on the target system, perform the update. Subsequently write the time, action and the result in the log file.

After the update process is done, a date file is created. Note the part where the update process is called. There is a “–Wait” command. This means that the script will continue after the process is completed.

What happens when there already id a date file present on the target system? It is needed to compare the dates of the date files. One is the WSUS Offline date, the other one is the date from the targeted system.

Step 2: Read the date from the files and converting it to date objects.

For comparison, the dates are converted to date objects and compared to each other. Every action is registered in the log file.

Step 3: Compare the date objects

After the strings are converted to date objects, they can be compared. The result could be that WSUS Offline process is started. In the other case, the script will finish with a log entry that there is no update needed.

This is basically the main part of the script. It checks, if the targeted system should be updated with MS Office updates and, if needed, starts the WSUS Offline process to do so. There are different alternatives to decide when the script should run by the manner the package is created within Login AM. In the chapter: “Create a Login AM package” you will find some more information about what can be done with Login AM.

Run the command file from UNC path

It is not possible to run the WSUS Offline “update.cmd” from a UNC share. To run the “update.cmd” from the network, it is needed to mount the UNC share under a temporary drive letter. I have chosen drive letter “B”. Just make sure the drive letter is not reserved or already in use.

As shown above, there is a check if the drive letter is available. If the drive letter is free, it is used for mounting the WSUS Offline share. If the drive is already in use, the script will stop and an entry is added to the log that the drive is already in use. See the screenshot below.

This PowerShell script will make a log file: It has a mechanism that determines when the update process is being started. I would say mission accomplished.

The last part is to put the script in Login AM.

Create a Login AM package

To deploy the package to the target machines, it is needed to create a package in Login AM. There are many variables in my PowerShell script, for example the location of the log file. A nice feature within Login AM is that you can add custom fields which can be connected to the variables inside the PowerShell script. By using this, there is no need to touch the PowerShell script again. Great, right?

In the package we determine the following:

And it correspondents in the PowerShell script with:

There may be situations when you want to control when the package is started or when it shouldn’t start at all. There may be situations that the date comparison isn’t good enough. Just imagine this:

The department responsible for deploying MS Office updates build a new version of the WSUS Offline program. On the servers there should be new software installed, but because there is a new WSUS Offline build, the Office updates will be installed, too. This could be a problem.

Login AM always processes every step that is defined. Thus, in this case, you need something extra to control when the Login AM package can be started and when not. Login AM offers the opportunity to do so.

How is that done? That’s something for another blog. But feel free to the check the following sites:

Login AM for the product and the possibilities it can offer for deploying software within your company and Login Consultants to help you with the implementation and knowledge to use the full potentional of Login AM.

In the download section it is possible to download the PowerShell script.