Automation Machine <> WSUS integration

Scenario

Automation Machine provides options for managing with Windows Updates. On a collection you can set a list of options to manage Windows Updates on the client machines. In this blogpost I’ll discuss a common setup. A single WSUS server which all clients point to using client side targeting. The clients in this case being a set of servers (the role of the server is not relevant). over which we want full control regarding Windows Updates. I’m assuming you already have an Automation Machine environment and have working knowledge of WSUS (you can find numerous posts about setting up WSUS anyway).

 

Automation Machine Setup

Without Automation Machine you would configure Windows Updates using a GPO. Some of the settings in the screenshot below are similar or simply identical. Automation Machine also provides some options not available in the GPO. For example “Manage Windows updates service”. This option enables the control of the wuauserv Windows service. So when enabling this option Automation Machine takes over full control of Windows Updates on the machine. The first option “AutoInstall windows updates” simply enables controlling windows updates from Automation Machine. The other updates control which updates are installed. Since we’re going to use a WSUS server which controls updates to be installed these are irrelevant.

Automation Machine Collection Settings
Windows Update Collection Settings

For WSUS to work we’re still missing a few options though. Clients would need to know which WSUS server to target and which group they belong to. Though you can use a GPO to configure these settings. I’d rather configure them using Automation Machine. You already have a tool with which to configure your servers. So you want as much configuration as possible in a single tool as a general best practice.

For that purpose I’ve created an AM package which configures the remaining options needed. You can download here. This package provides you with 3 options (seen below). The target group, Windows Update Server and the Windows Update Statistics Server. It also sets some additional registry settings to enable Windows Updates. Which you can find on the deployment tab if you want to dig in the package. The Target Group has been made Global. I’ll explain this in the next paragraph.

Automation Machine Package Private Variables
WSUS Package Private Variables

 

The variable has been made Global because the Target Group usually differs per collection. Since you don’t want to create a WSUS package for each set of servers Automation Machine features the option to override these settings on a per collection basis (as seen below). Using this you can link the package to each collection you want and then override the setting on a collection to match the desired target group. I haven’t done the same for the Windows Update Server variables since you usually have only 1 WSUS server. If you want though, you can simply tick the box below “Global” and it’ll also show up in the Collection Package Settings tab.

Automation Machine Package Settings
Collection Package Settings

How does it work?

Ok, so now you’ve configured everything and are ready to update servers using WSUS and Automation Machine. Yes, you should also setup a WSUS server, configure the updates you want to deploy and create target groups but I’m not discussing that in this post.

Automation Machine incorporates the Windows Updates process in a so-called “Deployment reboot”. A deployment reboot is an ordinary Windows reboot. With the addition that at startup Automation Machine will start processing the packages that were configured by the administrator to process. At the end of processing all packages Automation Machine will start the Windows Update and install all available updates (reboot in the process if necessary).

If you want to learn more please visit Automation Machine website.

Automation Machine 2014 Reporting

In my last blog post I discussed a reporting script that was made for Automation Machine but also functions in XenApp environments without Automation Machine to manage the environment. This version however is only compatible with Automation Machine 2012 and a couple of earlier versions. The latest version (Automation Machine 2014) has a completely different framework so the script i wrote is incompatible.

So for Automation Machine 2014 I’ve rewritten the script and created an Automation Machine 2014 package for it. Allowing you to change options much easier using simple checkboxes and drop down menus. So instead of opening the script and writing down some settings and changing some text from true to false you can simply configure all the settings, schedule the script and wait for it to run.

AM2014 Reporting
The package as shown in the Automation Machine 2014 GUI

You can download the package here.

Reporting script for SBC farms

A lot of RDS and XenApp farm (SBC in general) are on a reboot schedule. Meaning they reboot regularly, mostly daily or weekly. This is done to ensure stability of the servers and to have a maintenance window in which we can install or upgrade software. Specifically we use Automation Machine Maintenance for this. AM Maintenance is used to provide high availability of the SBC farm. Maintenance accomplishes this by rebooting the server in 2 separate groups.

Rebooting and deploying software automatically without having to perform any actions outside of office hours is a nice feature. It does impose some risks. For multiple reasons the servers might not be up and running properly after the reboot and/or after deploying new or updated software. You could do a manual check each time the farm is rebooted but that sounds like a lot work and is very repetitive. To me, that sounded like something that can be automated. Ideally you would like a report each morning with a list of server and metrics.

With this in mind i wrote a Powershell script which does just that. It creates a list of server, retrieves a bunch of metrics and bundles them in a nice report using HTML. That’s all nice but you’d like to have it available for reading somewhere. So i also made it save to a location (locally or on a share) and it e-mails the report to one or more recipients.

The script currently has the following features (you can enable and disable them to suit your needs):

FeatureRequirementsNotes
Server NameXenApp PoSh SDK or Automation Machine 2012You can choose to use XenApp or Automation Machine to retrieve the servernames
Collection NameXenApp PoSh SDK or Automation Machine 2012You can choose to use XenApp or Automation Machine the retrieve the collection
Server StatusICMP trafficUses test-connection (ping)
Logon StatusWMI
Server IPICMP traffic
Server ListenerXenApp PoSh SDK
Last Boot TimeWMI
Install TimeWMI
CitrixXenApp PoSh SDKEnables or disables importing the Citrix XenApp PoSh SDK
Data CollectorsXenApp PoSh SDK
Load EvaluatorsXenApp PoSh SDK
Session CountXenApp PoSh SDK
Startup ErrorAutomation Machine 2012
Cycle ErrorAutomation Machine 2012
S4MaticAutomation Machine 2012
AmTasksAutomation Machine 2012

To give you an idea of what this will look like:

Reporting script output

You can download the script here. Or if you don’t like downloading the reporting script directly. You can check out the code below and copy it yourself.