RES Automation Manager Emergency Patch Management

I previously covered the reasons why you probably wouldn’t use RES Automation Manager for patch management (see here). Max Ranzau (AKA @RESguru) made a great point that you can certainly use Automation Manager to push a patch out individual patches easily. With the release of the Microsoft RDP critical patch MS12-020 and an exploit apparently in the wild, this proves that RES Automation Manager certainly still has its place in your patch management strategy.

Assuming that you haven’t exposed port 3389 directly to the internet you may feel that you’re somewhat “safe.” I actually think that the greater risk comes from worms that will be run from within the corporate network firewalls. All it takes is for one machine to be compromised… How many desktops and servers do you have inside the corporate network that have RDP access enabled?

Microsoft provides some workarounds that will give you time to test the patch prior to deployment. Fortunately, RES Automation Manager gives you the following options in dealing with this exploit using the built-in Automation Manager tasks/tasklets:

    1. Deploy the patch within minutes and/or
    2. Disable RDP connections completely and/or
    3. Enable/modify the Windows firewall rules to block RDP connections and/or
    4. Enable Network Level Authentication for RDP connections.

One thing is for certain, you need to be acting and mitigating this risk now. I think it’s only a matter of time before things get interesting. Who remembers Slammer?! I know people who are still mentally scarred by its long lasting effects!

GPOs could help you with some of this, but nothing is going to be able to deploy any of (or a mixture of) the above workarounds within minutes. How will you be sure that your workarounds are in place on all machines? RES Automation Manager will give you near instant feedback on what tasks failed and provide you with the data to target those computers. Remember, if you use RDP/Remote Assistance for support then you’re probably limited to option #1 (or maybe #4).

If you don’t have RES Automation Manager today, you probably wish you did! You’ve been warned Smile with tongue out..

Iain

PVS Image Management

There has been a bit of banter on the Twittersphere about how people manage and document their PVS images. It was suggested (by more than just me Smile) that RES Automation Manager could be utilised for this task. This post is not a best practice guide as to how to create, update or document your images, rather a use case on how and why we use/recommend RES Automation Manager. Heaven forbid, you might even decide to do away with Provisioning Services as a result. Either way RES Automation Manager will play very nicely with or without PVS but I couldn’t fit it into 140 characters!

Provisioning Services Private Image Management

Maintaining the gold or private mode PVS image can be a complex task for a number of reasons. Simplifying any of these potential hurdles can only be a good thing, right?

  1. A certain level of skill is required to both create and maintain images. There are numerous tasks that need to be completed and in some cases, performed in a particular order. As a result, this task is typically left or assigned to the senior administrators.
  2. Application upgrades can taint or stain the master image. Some applications require an uninstallation of the old version and installation of the new product MSI. I don’t need to tell you that uninstallers are not always reliable or clean everything out when run!
  3. How are changes to the gold image documented to ensure that they’re incorporated into all other PVS images? It is typical that there will be more than one image for deployment. For example, hardware differences will typically require separate images.
  4. Ad-hoc and emergency changes can wreak havoc with your PVS images. How quick and easy is it to push an update out to 100 XenApp servers streamed from a central image? If we make changes whilst the servers are running then they’ll be lost when the write cache is erased meaning we either have to reapply this change after every reboot or update our gold image pronto! This will get a lot more interesting if the servers are rebooted on a nightly basis and the write cache cleaned!

RES Automation Manager

If know me by now, you probably know that I’m going to say that RES Automation Manager is the answer to all your prayers! Now whilst it can certainly address the above “issues” (and I would recommend it in conjunction with Provisioning Services any day of the week) there are other processes and solutions that may address one or more of the above and deploying RES Automation Manager won’t automagically fix them. A good example of this is documentation. If your internal processes mandate that all changes are documented and you bypass this process, there is nothing to stop you bypassing this process even if Automation Manager is installed!

What RES Automation Manager Won’t Do

Thought I’d better get this bit out of the way before you get all the way to the end and are disappointed! RES Automation Manager is a Run Book Automation tool and not an imaging/deployment tool. This means that we cannot (directly) deploy an Operating System from RES Automation Manager. Fortunately for us there are many technologies out there that can, e.g. Windows Deployment Services/Microsoft Deployment Toolkit which BTW can by combined with RES Automation Manager – take a look at this White Paper. Why reinvent the wheel?!

What RES Automation Manager Will Do

So once we have our Operating System deployed and the RES Automation Manager agent installed (we can do this with WDS/MDT as mentioned earlier) what benefits will this give us? Well, at a simplistic level, RES Automation Manager can automate the entire server configuration and application deployment process. This process can also include installing XenApp and XenApp Prep as well as any other applications. This obviously takes some additional time but gives us a clean, repeatable process for deploying a XenApp server from scratch. It’s a strategic decision and not a tactical one!

Why is this important? Typically it comes down to issues #2 and #3 so let’s take them one at a time..

Issue #1

RES Automation Manager can reduce this complexity by removing Provisioning Services altogether. I’m not suggesting that you remove this from your infrastructure. Not even for one minute. However, if you don’t need to have a clean image after every reboot getting shot of PVS maybe an option? We have automated the complete server deployment and can typically provision a new server in a few hours from start to finish; Operating System, XenApp and applications. OK it’s a few hours of time, but there is no user interaction required. I’m guessing that it’s probably not that often that you need to add a new server within 30 minutes?

This benefits the typical IT department as these are now regular servers. They’re supported in the same way as other servers and they have a proper OS install etc. There are downsides too. Now we need to patch and maintain multiple OS instances and not just one master image. Isn’t this part of the reason you deployed Provisioning Services in the first place?

Issue #2

By having a repeatable process for building our XenApp server(s) from scratch we can avoid tainting our image. If we need to cut a new image then we can deploy a completely clean server and deploy the required applications as required. We don’t need to uninstall and reinstall or upgrade applications. I’m not advocating this as a best practice, but I know lots of admins that are a lot happier with this process. It doesn’t need to be performed for all updates, but you now have an option as to whether you update the master image or cut a new one. If you have not automated the entire deployment and configuration process, recreating a new image from scratch probably doesn’t make you feel warm and fluffy inside!

When you finally get run over by a bus (it’s going to happen one day as everyone keeps saying it) pretty much anyone with ounce of intelligence can deploy a new server or reverse engineer the Modules and Tasks in the Run Book to discover how things are tied together.

Issue #3

By virtue of automating the entire configuration and deployment process with RES Automation Manager, you have actually documented every step in the process. RES Automation Manager includes the ability to create an Instant Report of any or all Run Books, Projects and/or Modules. These reports are very detailed (small example here) and typically run to 1,000+ pages. For us consultants, this feature alone is worth its weight in gold. Did I mention that it’s available in RES Workspace Manager too? Winking smile

Issue #4

Finding out when and by whom the changes were made. Whether they be changes made to the gold image or Ad-Hoc emergency it doesn’t matter the audit trail of the changes is vitally important especially with change management processes. Well would be surprised to hear that RES Automation Manager has an in-built Audit Trail which allows you to view all actions performed in RES Automation Manager – how handy is that when a witch hunt is on (Oh that never happens now does it!?).

Issue #5

As usual I’ve saved the best until last and you didn’t see number 5 coming! The “pièce de résistance” if you like. This might get a bit confusing so strap yourselves in ready…

Emergency changes to running PVS instances are pain. Depending on your configuration after a reboot changes may be lost and depending on your requirements, you may reboot nightly or even weekly. If there is a configuration change that needs to be made then ultimately we need to update the master image. We can implement the change on the running instances, but it will be lost at some point when the write cache is cleared. Until the master image is updated we will need to implement the change, potentially after every reboot.

Because RES Automation Manager is a Run Book Automation tool we can implement this change across all running instances within minutes. “WAIT!”, I hear you cry, “These changes will be lost after a reboot!” Correct. But now we have achieved two things; documented the change and can automate the update to the master image at some point in the future.

Why did I say at “some point in the future?” Fortunately for us there is a hidden gem within RES Automation Manager called Snapshot Intelligence. With a name like that it better be good right!?

As the RES Automation Manager database has a record of all jobs that have executed on a given agent it can detect a snapshot. Whether this is a virtual snapshot or a backup restoration, it makes no odds. In our PVS world, if RES Automation Manager jobs have been run on a machine and the PVS instance is reset back to our master image state (write cache cleared), RES Automation Manager will detect this as a snapshot. You with me so far..?!

Once a snapshot is detected, RES Automation Manager can automatically reapply the job history (I’ll pause whilst you take this in and wait for the penny to drop!).

So if we automate all the emergency or ad-hoc updates with Automation Manager we can automatically reapply these after every reboot? Yes. No need to update the master image for every change? Yes.

In fact it gets better than that. When we update our master image we can run the exact same job history (automatically if you wish) to update the gold image. If you want to cut a new image from scratch we’ve got that covered too. Above all, if everything is automated with RES Automation Manager it’s automatically documented too. Needless to say, you get all the usual audit logging and change history.

Summary

So, in summary, using RES Automation Manager in combination with Citrix Provisioning Services has huge benefits, but there’s obviously a cost associated. Would I recommend it? Absolutely! For all of the above reasons. Is it worth it? Unfortunately, I can’t tell you that as only you know your environment.

Can RES Automation Manager replace Provisioning Services? Not entirely as you’ll still need WDS/MDT (or equivalent) to deploy the OS. It also depends on your reasons for deploying PVS in the first place. If it’s for near instant deployment, remove local disks, reduce the storage footprint or a clean image on every reboot, you’ll probably be using it for a long while yet. If your reasons are purely for “single image” management then you could potentially replace PVS in favour of a “traditional” deployment. Would I recommend this? It depends!

I know we’ve been focused on Provisioning Services in this article but RES Automation Manager will help you with the rest of your infrastructure automation. Desktops, laptops, servers; Exchange and Active Directory etc. You may have XenDesktop, Quest vWorkspace or VMware View for your virtual desktops. The same principal applies and you may even be using PVS in combination with these. Anyway, I don’t need to preach to the converted!

I will say that it should be a strategic decision to deploy RES Automation Manager. Don’t underestimate the amount of time it takes to automate and test. But I guess you already spend a lot of time testing your images?

You can find some video overviews/introductions on RES Automation Manager on Citrix TV and RES Tutorials. If you don’t want to take the time to download, install and configure RES Automation Manager but want to take a quick look, you can always request access to the RES Showcase. Some background and example videos on the Showcase platform can be also found here.

I’ll get off my soapbox now and crawl back to whence I came! Please feel free to comment and I’d love to hear your thoughts. Iain

Virtual Engine Releases the Free RES Showcase

Virtual Engine announces the launch of the free RES Showcase, a cloud-hosted demonstration environment that gives RES resellers the ability to show customers and prospects the latest innovations in dynamic desktops, desktop management and IT automation. The new service will assist partners in the development of sales opportunities, as well as making it simple for Virtual Engine to deliver training on RES products.

Steve Jackson, Vice President Channels and Strategic Alliances, RES Software commented, “Virtual Engine has an extremely strong track record in helping our partners and customers to get the most from their RES Software implementations, both around management of the desktop and automation of IT processes. This new portal will provide our partners with an easy way to help customers evaluate how they can make use of dynamic desktop solutions within their own environments to reduce costs and improve the management of users across multiple desktop delivery platforms.”

The free RES Showcase from Virtual Engine is designed to allow you to evaluate and perform Proof of Concepts (PoC) in a pre-installed and pre-configured demonstration environment. Included in the RES Showcase are RES Workspace Manager, RES Automation Manager, RES Service Orchestration, RES VDX with Subscriber, Citrix XenApp, Microsoft App-V and Exchange 2010.

RES Workspace Manager VDX Options Explained

When delivering RES Workspace Manager training there can be some confusion over some of the settings available when integrating it with RES Virtual Desktop Extender (VDX). The purpose of this post is to attempt to clarify what option does what!

image

  1. This is the global option that will enable or disable the RES Workspace Manager and VDX integration, i.e. the ability to run applications as a “Workspace Extension”. Note: If this option is disabled and the RES VDX Engine is installed, there is potentially nothing from stopping this running, just you won’t get the RES WM integration, i.e. licensing etc.
  2. If this option is enabled then the VDX Engine process will be started. By disabling this option you will effectively be turning on the legacy RES Subscriber/Workspace Extender functionality only.
  3. If you have the VDX Engine installed, then this option will enforce the VDX settings to take preference over the RES Subscriber/Workspace Extender, e.g. options 7 – 13 and the Z-ordering improvements. Don’t disable this option if deploying RES VDX!
  4. Depending on the setting chosen the following taskbar behaviour will occur:
    1. Autodetect: The behaviour as defined in the Display Settings section will be honoured, i.e. the configuration of the remote session display.
    2. Yes: The taskbar of the local session will always be hidden regardless of the remote session display configuration.
    3. No: The taskbar of the local session will never be hidden. Note: with the RES Subscriber/VDX Shell, the taskbar is hidden by default.
  5. Depending on the setting chosen, the following client application pass-through behaviour will occur:
    1. Autodetect: If running client application window will be obscured by the remote session, it will automatically be displayed in the remote session.
    2. Yes: All running client applications will be automatically displayed in the remote session.
    3. No: No existing client applications/processes will be displayed in the remote session when it’s first started. Note: this does not prevent reverse seamless applications from being launched from the remote session!
  6. If selected, when a user logs off a remote session, all locally running client applications will be closed (or attempted to be closed!) before the remote session is ended.
  7. Enable this option if you which users to be able to access the system tray icon and enumerate the applications present in the user’s local client Start Menu.
  8. Enable this option if you which users to be able to access the system tray icon and enumerate the applications present in the user’s local client Desktop.
  9. Enable this option if you which users to be able to access the system tray icon and enumerate the applications present in the local client System Tray.
  10. Client applications can be excluded from the VDX seamless window integration by entering the process name, i.e. pnagent.exe.
    1. Multiple processes should be separated with semicolons.
    2. Processes can still be launched, but will not be displayed in the taskbar the remote session and Z-ordering will not be implemented.
  11. If you wish client applications to be unavailable via the System Tray integration, enter the process(es) here.
    1. Multiple processes should be separated with semicolons.
    2. If a client process is excluded, it will not be displayed in System Tray Start Menu or Desktop folders.
  12. Allows you to override the default VDX pop-up balloon title (a).
  13. Allows you to override the default VDX pop-up balloon text (b).
    1. This text is also displayed at the top of the VDX system tray Client Start Menu/Desktop window (c).

image

SNAGHTML6c0f49e

Display Settings

The following information has been taken from the RES VDX User Guide and is used when configuring the Local Client Taskbar integration in option #4 above:

VDX supports several display scenarios. Each scenario may require specific settings. For an overview of these settings, see Setting up the Behavior of the RES VDX Engine (on page 10). Some examples of supported scenarios are:

A single display

In this scenario, both the local desktop and the remote desktop are run on the same display. The remote desktop is the visible desktop, showing both remote applications and local applications. The local taskbar is obscured if the remote session is maximized. With the remote session at a smaller size, the client taskbar is shown twice, once in its original position on the client and once integrated in the remote session.

A dual display setup with the remote desktop spanning both displays

In this scenario, both the local desktop and the remote desktop span both displays. The remote desktop is the visible desktop, showing both remote applications and local applications. The local taskbar is obscured if the remote session is maximized on the first monitor or if both sessions are maximized. 

A dual display setup with the local desktop running on the primary display and the remote desktop running on the secondary display

Both taskbars are displayed. 

A dual display setup with one remote desktop running on the primary display and another remote desktop running on the secondary display

Both remote desktop taskbars are displayed. Client windows can be moved from desktop to desktop.

I hope this helps clarify things for someone! Iain