Category: Automation Manager

New RES product packaging, part 1 of 2

By Max Ranzau

 

packFrom the Packaging&Shipping dept. Today some major changes were announced on the product packaging side. While it doesn’t affect the technical operations of the products (sorry, the unified license server is not there yet), it does have conceptual impact, which we all would do well to wrap our collective gray goo around. This is the first part of a two-phase announcement, the second one is coming out on May 24th next week during Synergy. Let’s run through the most important bits of the first announcement to understand what’s going on here. The headlines are as follows:

  1. WM and AM are merging into one product. This means that the current stand-alone product Automation is going to be part of Workspace. Again the consoles aren’t merging, this is just a licensing and naming change:
  2. Free RES Core for Workspace. This is essentially just the consoles plus basic functionality, like we’ve seen in the earlier Express versions of Workspace Manager and PowerFuse. For example Core has UserSettings, however only at the global level. If you want the per-app user settings, you will need the new Composition module. See item 4 below.
  3. No more metal versions. The old Bronze, Silver and Gold names have gone the way of the Dodo. This is a good thing, because it means you can now mix and match the editions without having to start out with the mandatory Bronze (configuration and user settings).
  4. Workspace will now have 4 modules:
    • Composition – Same as always (application based user settings, console configuration, app/shortcut management). This is what used to be in the old Bronze more or less.
    • Security – This includes the well-known managed app security, dynamic privileges/process elevation , network security, etc. One thing I didn’t see on the list was Read-only blanketing, however we’ll have to see if it’s still in there.
    • Governance – New name for the module formerly known as Advanced Administration. Contains administrative roles, usage tracking, auditing performance components and license management of managed apps.
    • Automation – This is essentially Automation manager lobbed into the mix as a WM module, where desktop is licensing is inferred, however these are still licensed separately per desktop and I’ll have to presume that any needed servers in the mix are still being licensed differently than desktop. Acording to RES, Automation also comes with some (as of yet undefined) predefined building blocks.
  5. Pricing. The MSRP still holds at $€30 per named user for all modules, with the exception of the free Core. However, it still remains to be seen if RES will be offering a bundling discount if you purchase the whole Workspace product.

According to RES Marketing, these changes are scheduled to go into effect early July 2016. Finally as indicated above, this is the first of a two-part announcement, the second going official next week during Synergy in Las Vegas. However it goes without saying that Service Store was not mentioned above. I will also be investigating what the new Suite with everything will look like. Stay tuned!

 

Managing VMware AppVolumes with RES

appvolumesFrom 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.

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

New Technote: Webservices & Automation Manager

Animated, Gears, boxFrom 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.

doc-icon2<<< Click here to read part one

doc-icon2<<< Click here to read part two

Automated XenDesktop 7.5 Build with RES AM

By Max Ranzau

 

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.

mr-jMy 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.

res_am_fileshareWhen 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.

XD75_01When 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.

Click the brick as per usual to download the buildingblock:  legobrick-cropped

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!

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!

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

 

 

Workspace Life on Windows 10

By Max Ranzau

 

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.

win8focusgroupStart 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!

win10 with res wm

nowin9By 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.

schmockeandapancakeAs 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.

mr-potato-headOther 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.

conclusionIn 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! ;)

 

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