From the Skunkworks Dept. This is an article I’ve been looking forward to writing for a while. I had the opportunity to look at AppVolumes when it was still pre-VMware Cloudvolumes, but as you know – timing is everything, so I decided to hang back until VMware released AppVolumes today! In this article I will share some thoughts on how the AppVolumes product can be augmented by RES technology to offer some very interesting options for integrators.
Category: RES Products
From the Nuts&Bolts Dept. November 2014 saw the release of Workspace Manager 2014 Service Release 2. You may have read the initial post over at RES, but as always here at RESguru.com we like to kick the tires and take it for a spin around the block. There’s several items in this release that are important to know about and I’m going to highlight some and give you my view on them.
From the About-Damn-Time Dept. One of the most popular articles on RG is the Registry reference for RES Workspace Manager. Unfortunately it’s been sitting on the backburner for a while, but no more! As of this weeks release of Workspace Manager 2014 FR2, the guide has been updated with all published registry settings available from the base 2014 release notes and up to. If you come across missing or any other spooky settings, feel free to contribute in the comments section on the article.
From the Technotes-R-Us Dep: Today I have the pleasure of sharing a new article based on some preliminary work I did for a couple of clients who are looking to integrate SOAP based web-services into RES Workspace Manager. I put together a simple demo that show how to use SOAP calls to pull a live weather report from major airport cities around the world. If you can make that work, you can do pretty much anything from configuring a firewall, set up infrastructure or even process creditcard payments.
This is the first of a two-part article, where we next time will look at wrapping a service around the module and learning a few nifty tricks on how to deal with value dependent dropdowns.
From the BuildingBlock Dept. You may recall a couple of years ago that I published a RES Automation Manager buildingblock for Citrix Xen Desktop 5.5, XA and PVS. Today it’s my pleasure to publish a new buildingblock that will do the same for Xen Desktop 7.5. It’s pretty slick, as it hardly needs any configuration or special prerequisites and allows you to choose all the install options for Xen Desktop.
My friend and co-blogger Mr. Jeroen Speetjens from the Netherlands has been kind to share this with the RES community. You folks over at Citrix might also want to take note of this work. In order to use this buildingblock, all you need is the Xen Desktop ISO and a fresh Server 2008 or 2012. Deploy a RES Automation Manager agent to the target server, then import and schedule the module. The module contained in this RES Automation Manager buildingblock will configure everything else you need.
When you import the buildingblock, you will be prompted for the path to the contens of the XD .iso file, as shown on the screenshot below It is recommended to either mount it somewhere and share it, or copy all the files out of the ISO to a share. Either way, it’s about 2GB and you don’t want to add that as a AM resource, not that Automation Manager can’t handle it, it’s just a hassle next time you’re updating the binaries when you have a new .iso.
When you schedule the module to the target server, the module will prompt you for what kind of installation you want. After that it’s off to the races: The average deployment time is about 10 minutes on a target system with SSD’s.
Note: If you decide to download this AM buildingblock and take it for a spin, I kindly ask you to take a moment to comment your feedback below and send thanks to Jeroen for his efforts.
Remember: RESguru.com is still the number one place to get noticed if you are doing cool stuff with RES: If you’ve got something to share – the guru community cares!
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:
From 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!
From 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.
Important: 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 :)
From 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.
Update April 28th 2015: SR3 now has experimental support for Windows 10 and probably works alot better now than described below. While they haven’t tested it fully, according to a partner seminar held today, RES will accept support tickets now on Windows 10 based systems running Service Release 3.
From the Somebody-had-to-try-it Dept. So, the other day I decided to check out Windows 10 and see how it works with RES WM SR2. You may recall I did a similar piece on Windows 8 back in the day, where we looked at alternative ways to bring back the start menu. Bringing back the start menu via the RES classic shell may not be that important anymore, as the Windows start menu is (almost) back in business. See further down. The obvious question I wanted an answer to is, how well does the RES products work at this point with the Win10 tech preview. I deployed the usual complement of endpoint items onto the Windows 10 client:
- RES Workspace Manager 2014 SR2
- RES Automation Manager 2014 SR2
- RES IT Store Client
Logging in: I gave the stack a quick whirl to see what works and not. No, I did not test every nut & bolt. Allegedly there’s people at the mothership that get paid to do that.. ;) After installation I set the WM Composer to Automatic and logged in as a regular user. First thing I noticed; I got what looked like the dreaded black screen of death. Okay, unfazed this gave me an opportunity to test the Automation Manager agent. I scheduled an AM module to reboot the computer and it came up again nicely. I decided to switch the workspace composer back to manual and launch the Composer binary pwrstart.exe by hand, to see if/when anything went pear-shaped. It seemed to launch okay. Deciding it might have been a fluke (tech preview and all), I set the composer back to automatic and logged in again. WM’s Composer seemed to come up fine again and again after that. So far so good.
Start Menu management: As most of us know by now, Microsoft finally opted to send the poo-flinging primates who occupied their Windows 8 focus group room back to the zoo. As mentioned above the start menu is back. Well… sort of – I guess they had to compromise somewhere, so instead of the horrible fullscreen Metro/Modern tablet experience that blotted out your Windows 8 desktop, now the Start menu has been expanded with a “mini-metro” to the right. I for one can live with that. Thanks for listening Microsoft!
By the way, if you’re wondering why they skipped the Windows 9 version, one possible explanation is to avoid potential issues with software checking for or against oldschool Windows 95 or Windows 98. Think about it; chances are if you’re a developer and wrote a line of code to make sure your software does not attempt to run on old Win9x, you might just use a wildcard like Windows 9* – Q.E.D.
As for RES Workspace Manager 2014 on the Win 10 Tech preview, it’s hardly surprising the WM start menu management doesn’t work 100% yet. Ischn’t tish weird? I’m shure tere’sh shomewone working on tish (that’s how you write with a Dutch accent, kids. Don’t try this at home :) Seriously though, it’s clearly evident the Startmenu has undergone a large overhaul, thus it’s likely working differently than the current release of Workspace Manager thinks. For example Replace Mode does not blow away the start menu, instead it looks like Merge Mode for now. Also there is obviously no way as of yet to handle the tiles. If the next FR/Major release of WM does not support native tile management then if someone figures out the proper HKCU/%userprofile% hacks to wrangle them, let me know. Placing desktop icons on the desktop seems to work as well too. Besides that, Process Intercept seems to work just fine too.
ITS Client: One thing I noted, when you install the RES IT Store Client, it doesn’t launch when you have switched shortcut management to replace mode. This is not entirely unexpected as Win7 does the same thing. WM removes the Startup folder when in replacemode, i.e. the ITS client doesn’t launch as a result. It’s just a little bit weird when WM seems to leave the startmenu alone on Win10. Anyway this is not a hard snafu to overcome, if you’re currently testing the tech preview, just add an Execute Command item to launch “%programfiles%\RES Software\IT Store\Client for Windows\resocw.exe” at session start. Alternatively you could create an AM job that launches said binary in HKLM\…\Windows\Run.
Other small potatoes: Putting up a wallpaper logo from WM, I noticed that Windows 10 apparently doesn’t care for if you select placement in one of the upper corners. The wallpaper will be placed centered on the screen. Other than that, for obvious reasons, neither WM or AM is currently able to natively determine it’s Windows 10 as there aren’t zone/team/condition rules for it yet. Again, if you’re hacking around the tech preview, you could consider create a zone that checks for a registry key identifying the OS, like I’ve previously described here for Win8 back in the pre-release days. You would instead be looking for the value ‘Windows Technical Preview’ and perhaps the number in the CurrentBuildNumber REG_SZ value.
In summary: the WM/Win10 combo looks very promising. Already now with a few limitations it’s actually quite usable, if not just for starting to become familiar with Windows 10 in a workspace manager context. According to the twitterati Windows 10 will be available “late 2015”, possibly in July.
Until then, keep doing things you’re not supposed to do! ;)