Posts tagged: Automation Manager

Understanding Automation Manager traffic

By Max Ranzau


BandwidthexampleFrom the Nuts, Bolts and Bandwidth Dept. As some of you noticed, a while back RES released the Reference Architecture document for Automation Manager, so now we have one for both the core products, great. If you have no idea what I’m talking about, go read the document here. The reference doc leads in with the basic deployment scenarios and similar things, but the nittygritty stuff is on page 22+23, where we get down to the actual traffic load numbers. Some of these numbers are obviously based on estimates: For example the resulting network traffic of any job, invariably would be linked to what’s in the job in terms of modules, tasks and resources. Note: The ref.architecture doc specifies packet numbers, but since we are interested in the overall bandwidth consumption I’m leaving those number out as they’d only muddle the picture.

One more thing before we get started. The numbers listed below are obviously without Automation Manager bandwidth management involved. I may do another piece on that particular topic in the future so you get a better idea of what it actually does…

AM Agent-to-Dispatcher idle-traffic.

To begin with, lets talk about idle traffic. It’s a fact of life that all components in a network chat. The question is how much, how often and what the impact would be on the fringes on your infrastructure. Given the numbers below, chances are that you can work out the impact by yourself. While RES is keeping the formula on how to calculate the precise idle traffic under NDA, it’s pretty easy to make a couple of observations off the provided numbers. According to the examples in the document:

When idle, one AM agent spews about 47.5kByte worth of traffic per 5 min/300 sec. That’s not a whole lot as it boils down to just below 160 bytes/sec per agent.

Let’s expand on that: Even if you had 3000 agents on the same site, your total background noise from the AM agents, across all switches would be around 475k/sec. This is next to nothing on a regular LAN. Remember this is the agent-to-dispatcher poll traffic, so it would never have to cross a WAN link when you place your dispatchers strategically on your external sub-nets.

AM Dispatcher-to-Datastore idle traffic.

As most of you know, an AM Agent is wired never to talk to a datastore directly, but always go by way of at least one dispatcher.  How many dispatchers you will need depends entirely on the shape of the infrastructure you want to deploy AM in. Since each Dispatcher+ can handle 1500 concurrent agent connections, you are obviously going to have a lot less dispatchers than agents, however the kicker is that the dispatchers will usually be crossing WAN links if you have them. If you go about your dispatcher layout smartly, you should not need more than one dispatcher per wan, link which makes the following math rather easy. When the dispatchers aren’t doing anything job related, the idle traffic depends on:

A) Are there agents connected?

  • If no, the base impact is about 616k over 300 sec †1), being around 2kB/sec per dispatcher, which is negligible on most WAN links.
  • If yes, it seems there is a slight overhead when an agent is connected (22kB over 5 min = 73 bytes/sec). Presuming that number scales linear, then even with a fully loaded dispatcher with 1500 attached agents, you would be looking at around 110kb/sec dispatcher-to-datastore traffic †2)

†1)Disclaimer: As RES is keeping the formula for calculating this under wraps with the NDA stuff, I’m going to have to make a couple of leaps of faith here. Unless somebody with WireShark and the necessary time on their hands is prepared to run the numbers and verify (or spill the beans in the comments section ;)  – we can only go by what is stated in the doc. The reference document said the Agent idle traffic was measured over a 5 minute interval, but it doesn’t say so for the corresponding dispatcher traffic, thus we are going to presume they used the same measurement interval for that test. †2)The other presumption I had to make, is that each additional agent connected to a dispatcher adds on average the 73 bytes/sec onto the idle dispatcher-to-datastore traffic.

B) The other item to briefly consider: Is the dispatcher a garbage collector? This role has a very low impact and not much is posted about it anywhere at present, other than it’s selected dynamically amongst the dispatchers – supposedly similar to Citrix Zone Data Collectors as they all know about each other through their datastore. What the purpose of the RES AM data collection precisely is, when it happens, what the election criteria is, are still unanswered questions, but hopefully someone will provide that information in the near future. Anyway, based on the released numbers, we may presume the garbage collection role adds approximately 215k/5min to an idle agent, equivalent to just under 780 bytes/sec for the garbage collecting dispatcher. So unless part of your infrastructure is running over a 2G cell data connection you can probably ignore this completely.

AM Dispatcher-to-Datastore traffic, running a job

Since you hopefully won’t have your new Automation Manager installation sitting idly too much, it’s also worthwhile knowing what kind of traffic patterns you are looking at when a job is actually processing. Again we have to do a bit of guestimating based on the provided numbers in the RES reference architecture guide. The numbers are based on a job that downloads a 5.5MB AM resource. The only thing they really tell us is, that regardless if you are master caching or connecting a dispatcher directly to the datastore, the amount of data going across the wire seems roughly equivalent to the size of the resource payload + 500kB. If a dispatcher is set up as a master caching dispatcher, the transfer overhead looks to be about 200kB less than for a regular dispatcher connected to the datastore.

In conclusion, while the overhead isn’t very large, it is not easy to create usable rules of thumb out of this, as the reference document only provides one datapoint (5,5MB and resulting traffic), so in order to make an accurate estimate on traffic size, one would have to know how/if the 500kb overhead grows with the size of the resource/modules. I would suggest this would be an excellent addition to a revision of this document.

Other than that, clarifying comments are welcome!

Fixing a Linux AM agent install problem

Animated, Gears, boxFrom the Mostly Nuts (and bolts)bat-tux Dept. Recently I was messing around with getting the RES Automation Manager SR3 Linux agent (res-am-6.5-3.125079.tgz) installed on a Redhat Enterprise 6.2. However, aparently some crypto libraries were missing. The following linked article shows you how to easily fix this problem, even if you’re not 100% Linux savvy.

doc-icon2<<< Click here to read the article.



New technote: Creating a Maintenance Shell

Animated, Gears, boxFrom the Technotes-R-Us Dept. How often have you been in the situation that you need to make some changes to some computers out there, but no matter when you try, them pesky users seem to be logging in everywhere at any time! There is of course traditional ways to prevent this, but this article by my fellow RESguru writer Rob Aarts delivers an novel yet effective means to do this. The secret sauce is using RES Automation Manager to deploy and configure a smart little app which is then configured as the shell of the target computer(s). It has other bells and whistles, so you may want to check it out.

Update Feb 11th: Sourcecode for the Maint.Shell executable is now included in the article

doc-icon2<<< Click here to read the full article

Getting rid of a Explorer folder problem

By Max Ranzau

From the Hexbags and Spells Dept. One really annoying explorer behavior which seems to recently have been making its rounds on Win7 x64, is an error which typically appears when you either drag and drop move things around in desktop folders or just create a folder somewhere using explorer. The errormessage which often comes out of the blue is “Could not find this item” <new line> “This is no longer located in <path>. Verify the item’s location and try again.” This addition to the Technote Library shows you how to defeat it with RES Automation Manager and as usual a BuildingBlock is included

doc-icon2<<< Click here to read the technote



Defeating a live virus/trojan infection with AM

By Max Ranzau


From the Crush, Kill & Destroy Dept. This is an aricle about using RES Automation Manager to defeat a live virus infection and cleaning up the colatteral damage afterwards, in case you’re dealing with many computers. With the help of others, I’ve put together a solution, as well as providing some valuable generic takeaways, like how to change special permissions in the registry and how to use the Windows PendingFileRenameOperations queue from within Automation Manager.

doc-icon2<<< Click here to read the article.


Automation Manager SR2 – All the details

By Max Ranzau

From the There-we-fixed-it Dept. I guess this is one of the few downsides of living on the California coastline – the bloody 9 hour time diff to Europe! So while I certainly can't be the first to tell you about breaking RES news, I can at least fill in the blanks. Just think of me as Wolf Blitzer in his pyjamas :-) Aaaanyway, today RES Software released the Service Release 2 of Automation Manager 2012. This update and full installers can be downloaded from the RES Support Portal as usual. So what's in the box then? Well, besides the usual staple of fixes there's a handful of interesting enhancements:

  • Conditions in AM now support for Windows 8 and Server 2012.
  • Just like Worksspace Manager which can fill in it's tables into a pre-existing, empty database, AM can now do the same. This is great for situations where you are fresh out of bullets and the onsite DBA won't let you create a datastore for your pilot.
  • Finally AM now also has uppercase and lowercase functions. These are now known as @UPPER[()] and @LOWER[()]
  • A new global setting has been created to disable/enable the existing RunbookWho functionality. This setitng and associated $[runbookwho] parameter was created earlier to allow you to specify at scheduling what agent(s) should execute the runbook. See the releasenotes for further details.
  • The exchange mailbox task has been updated to support creating alternative email addresses on Exchange 2010 which stores these on the Exchange server and not in Active Directory as previously.

For more information, have a look at the releasenotes here:


3 new HyperDrive articles

From the Technote Dept. Yesterday two new articles by Rob Aarts were published. These articles respectively covers installation and configuration of RES Hyperdrive. You can also learn here how to fix the clock-drift issue which has been know to appear on CentOS linux builds running on a hyperV server. To read the new articles, click on the documents below. Update. As per July 25th, a third article on how to replace the self-signed certificate has been posted.

RG047 – Installing HyperDrive and fixing clockdrift

RG048 – Configuring RES HyperDrive

RG049 – Replacing the RES HyperDrive certificate


New technote: Parsing files with AM

From the TechNote Dept: A new article by Patrick Kaak has been posted in the TechLibrary. This time around Patrick shows us the advantages of incorporating existing scripts into RES Automation Manager, illustrating by example how an otherwise semi-static script can be converted into a reusable runbook, which requires no editing what so ever. The example at hand utilizes Thomas Koetzing’s excellent Citrix Hotfix downloader script. By embedding it into an AM runbook you don’t have to ever edit it again. As usual for your convenience, an example buildingblock is included

<<< Click here to read the article

New Technote: Dispatcher+ and WebAPI

From the Technotes-R-Us Dept. With the Automation Manager 2012 currently available as RC2, a RESguru article describing the nuts, bolts and registry settings of the new Dispatcher+ has been overdue for a while. To the rescue comes Rob Aarts with a great article, which explains the ins and outs of the new dispatcher component. Also covered in the article is the Master Dispatcher/Cache feature. The most important registry settings to tweak the behavior of the Dispatcher are also covered. Finally the article also covers the new WebAPI for Automation Manager.

<<< Click here to read the article!

Happy 3rd to and welcome Rob Aarts

Today, Jan 3rd we celebrate the 3rd year of and a new staffmembers arrival. As you may recall there was a bit of controversy surrounding’s date of inception, but I’m glad this is behind us now and the usurper was silenced – at least for a while anyway :-) At this time, I wanted to take the opportunity to thank YOU, our regular readers and commentors for help in making the site what it is today. Your feedback and constructive critique has been essential to motivating myself and the other writers to continue what is essentially a labor of love.

I would also like to thank my current co-writers for providing quality content over the years. As all contributions to are on a completely voluntary basis, it’s with gratitude that I am able to publish the shared works of our regular staff, colleagues, friends and industry partners. To all of you: Thank you!

On that note, I would also like to welcome another RESguru onto the regular writer’s staff: Mr. Rob Aarts. Rob has a load of technical RES product experience which he’ll be sharing here on the ‘Guru site. His first article is about the new Global Variables in the RES Automation Manager. I’d suggest you give it a read! Rob’s bio can be found here.