Updated: DB Cleanup Tool 2.0

By Max Ranzau


From the Tools-R-Us Dept. You may recall a while back in February, I reported on a cool utility to address the issue with clearing individual log files in RES Workspace Manager. There’s now a new version 2.0 out from one of our community heroes (=someone who contributes and shares stuff), Patrick van Grinsven in the Netherlands (For the record, Morgan Freeman did not develop it ;). The SQL Database Logging Cleanup Tool has seen a few GUI changes and some other improvements:

  • It is now possible to directly Analyze / Query / Clear the configured logging database if the supplied connection details and logs are valid.
  • It is now possible to Analyze / Query / Clear the logging between dates, or to completely clear the selected log (1)
  • Logging analysis is being sorted descending.
  • Displayed record count added (2)

If you are a RES engineer or admin, this utility should most definitely be in your Bat-utility belt.

For further information and downloads, see the updated article here: doc-icon2


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 IE cookie trouble with RES WM

By Max Ranzau


delcookiesFrom the Worlds Greatest Browser (Right…) Dept: In Internet Explorer 10 and up, the WebCacheV01.dat file was introduced. This file lives in %LocalAppdata%\Microsoft\Windows\WebCache. The webcache folder is hidden. The issue at hand is that the webcache file is always in use, which makes for a rainy day if you try to roam/copy IE cookies, or otherwise store them with RES User-Settings. The issue was described back in April by Rob Beekmans on his blog here.

As of now, the problem is rumored to have been addressed by Microsoft on Server 2012, but is still very much alive and kicking on Server 2008, which at the time of writing still represents a large contingent of server deployments out there.

While Mr. Beekmans illustrated the issue, my partner-in-crime the good Mr. Aarts tackled the issue head on, providing a neat and shareable solution with the RES community in the shape of a Workspace Manager buildingblock. By running a couple of strategic Powershell scripts in the users session and including a couple of extra (freeware) utilities as custom resources, the buildingblock solves the problem described above. The Workspace Manager BB includes the following:

  • A PowerShell command to set the PS execution policy to unrestricted to make sure we don’t get any unnecessary prompts when running the following items unattended:
  • A PS script running at logoff, which backs up the current webcache to a location of your choice *1). The script will create two backup .zip files for the two folders WebCache and INetCookies as well. The script will also leave 5 rotated backup file sets.
  • A PS script running at logon to restore the latest backup of these two folders to their original location
  • Both logon/logoff scripts closes all open file handles before making the backup/restore operations.
  • 7zip and SysInternals Handle64.exe are included as RESWM custom resources.

As you may infer, the above essentially extends the WM User Settings with a basic Hybrid Profile – style copyout-copyin script system. This is necessary, as UserSetting would face the same issue as any other UEM; that the target files are locked. I’d say there’s a loud and clear feature request waiting to be implemented here that could solve a lot of potential headaches for customers.

script1Important: As you can see on the screenshot, there is a couple of places you may need to modify the logon/logoff scripts. The destination where the backup files are to be stored defaults to H:\ – you may need to change that. If you already are using a UNC path like \\server\share\%username% for your User Settings, you perhaps want to consider using that as well. Just remember to add a subfolder for this, like \\server\share\%username%\IEbackup or similar. We could of course have added an environment variable so you only had to change the storage destination once, however it’s two edits. Chances are you may survive it :)

Click the brick to download the buildingblock: legobrick-cropped

Automated VDI Optimization

legobrick-croppedFrom the BuildingBlock Dept. Here’s a set of buildingblocks for Automation Manager I’d like to share with you. They have kindly been provided by my co-blogger Rob Aarts. Rob asked me to go through the buildingblock and we agreed to document the result in an article. This collection of modules is very useful when implementing best practices for a Windows 8.1 golden image.

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



Aspen Systems and RESguru Consulting partnership

aspen-logoToday it’s my pleasure to announce a new partnership with Mike Meyer over at Aspen Systems. Mike has been in the virtualization business for as many years as I’ve been in the workspace and automation business. Recognizing our respective strengths we quickly realized there is good business to be made by combining these strengths.

This partnership will effectively allow our respective companies to offer virtualization and workspace expertise combined in north and southern California. Santa Barbara based Aspen Systems has an impressive track record delivering high quality desktop solutions based on Citrix, VMware and other virtualization technologies. RESguru Consulting, based in the San Francisco bay area, brings 15 years of implementation and training experience with RES Software technologies to the table, allowing implementation of fast and predictable managed desktop and automation solutions in the datacenter, as well as in the end-user computing environments. Together we are excited at the prospect of serving current and future clients with well proven technology to increase savings on IT and reduce complexity.

To kickstart this partnership, I’ve created the first of a series of technical articles for the Aspen Systems newsletter that will focus on different aspects of RES technology. The first article is how to use RES Automation Manager in environments where Windows Authentication is required.

doc-icon2<<< Click here to read the article on Aspen Systems’ blog.


Secret Weapons of a Master Trainer

By Max Ranzau


From the Teacher’s Tips Dept. Having trained a lot of great folks in RES tech over the years, one particular question I often get on the side is this: “Max, what is that digital whiteboard solution that you are using?” I thought I might as well share that with you here, as well as a couple of useful tips. You’ll need these as circumstances have changed around the product’s availability.

cpsFirst of, what I use is called Canson Papershow. It is a quite ingenious solution to white boarding. The Canson Papershow solution differs itself by using a real ballpoint pen tip on real paper. It’s not a recorder pen that plays back later, or one of these Wacom tablet jobs where you can’t see what you’re doing. I’ve even seen folks trying to finger paint on a VGA connected iPad – ye gods! With this kit, everything you write will be drawn precisely in real-time in the whiteboard app on screen as well as on the paper. The kit consists of a USB key, a pen and a special micro-dotted paper pad. The USB key has 3 functions:

  • It’s a Bluetooth receiver for the pen device.
  • It stores the software for the host computer (it supports both Windows PC and Mac)
  • It provides storage for your saved whiteboard drawings (I think the key in total has about half a Gig). The drawings are stored in a vector based format, not as bitmap, so you can edit them later or continue next day of training in the same file.

The pen runs off a single AAA battery. It’ll run for about Read more »

RESguru Consulting goes live!

Hi everyone, it’s been a while. Plenty has been happening on Planet RES for the last few months, which why I’m here today to bring you a very exciting announcement. For me this year, the American independence day will have double meaning:

As of today July 1st 2014, I am launching RESguru Consulting as a  company. Specifically I am offering consulting, design, implementation and training/workshop options to anyone who is looking at RES Software automation, workspace or self-service solutions.

Having worked actively with RES products for the last 1½ decade, trained hundreds of consultants, admins and several instructors in the ways of the Force, I am now putting my services and experience at your direct disposal.

I am based in the San Francisco bay area, yet available internationally. For further information, call (+1) 610 462 2200, email m.ranzau@resguru.com or reach out via LinkedIn. See my profile page here, for a backgrounder and more information.

To everyone who’s been following and enjoying the site over the years, rest assured – all the content and goodies will stay up on RESguru.com and more are being added in the future.

I look forward to working with you.

Max Ranzau