Updating Mandatory Profiles Part 2
Posted 2 weeks, 4 days ago @ Iain Brighton // No Comments
Having seen that our original Updating Mandatory Profiles post is quite popular, I thought I’d follow it up with an update. The process described in the first post is quite labourious and error prone. I’d like to make people aware of how quick and easy the Profile Update Utility (PuU) makes updating a mandatory profile with ActiveSetup keys.
Here’s the new process:
- Obviously you’ll need to have downloaded (it’s free) and installed VET.
- Once installed, simply launch the Profile Update Utility.
- Select your mandatory profile by clicking the “Browse” button (step 1).
- Check the “Merge HKEY_CURRENT_USER ActiveSetup keys” checkbox (step 2).
- Click the “Go” button (step 3).
It doesn’t get much simpler than that! Note: This will merge the ActiveSetup keys from the currently logged on user. Therefore, you need to perform this action on a machine that you’ll be using the mandatory profile on.
The “Output Options” at the bottom of the PuU windows could probably do with some explaination as there is sometimes some confustion.
- Update Original Profile: Overwrites the source (Step 1) profile.
- Backup Profile: Copies the source profile (in Step 1) to a .bak file and then updates the original.
- Create New Profile: Copies the source profile (in Step 1), renames the original (in Step 1) to a .bak file and then updates the new copy.
Which option you use is up to you depending on how you manage the lifecycle of your mandatory profiles.
Enjoy – Iain
Category : Blog
RES AM Passing Values Between Scripts
November 29th, 2011 @ Iain Brighton // No Comments
You don’t need to be told how great RES Automation Manager, but there are some things that we can only achieve via scripts; be it VBscript or PowerShell. In my example, it is scripting XenDesktop and XenServer for the demo showcase platform (more on this at a later date). There is currently no way to automate these products without using scripts. Unfortunately (for me) it’s always been problematic to pass values in and out of scripts to other modules. We can certainly pass a value into a script, but then we can’t return it to be used elsewhere.
My problem required creating an AD user (not via the built in task) in one script and then passing the username/password into another script. To overcome this particular issue, I started down the route of temporarily writing the information to the registry so that it could be read by the other script later in the Project. This is where I stumbled across a little gem hidden in RES Automation Manager. I don’t know whether it’s intentional and/or undocumented, but it certainly works!
I attempted to use a Parameter using the built-in @[REGISTRY] Function. In essence this instructs the RES Automation Manager agent to populate the Parameter with the contents of the registry key. This bit is simple to understand and you probably already knew this. However, what I didn’t realise is that this Parameter is updated/re-evaluated at every task within a Module. I assumed that it would only be evaluated when the Module is invoked by the RES AM agent. I’m certainly glad that this is not the case as we can now write values to the registry and AM will automatically pass the updated value to the next Task(s).
Here is an example building block that contains a single module with a single registry-based, emtpy Parameter value. The first script writes the current date to temporary location in the registry (just so happens to be where RES Automation Manager is reading the Parameter value from). The second script receives its Parameter value from RES AM (not directly from the registry within the script), adds a day (in US format!) and writes it back to the registry. The final task displays a pop-up message with tomorrows date from the RES AM Parameter.
What this does prove is that the Parameter is re-evaluated before each task is executed and therefore passed through all tasks. Never in this example module do we enter the date. Here is the status of the parameter before and after each task.
Task 1 – BEFORE: <Empty>, AFTER: <Empty> (We write today’s date to the registry, but it’s not re-evaluated until the next task)
Task 2 – BEFORE: <Current Date>, AFTER: <Current Date> (We write tomorrow’s date to the registry, but it’s not re-evaluated until the next task)
Task 3 – BEFORE: <Tomorrow’s Date>, AFTER: <Tomorrow’s Date>
I’m sure you can think of more ingenious ways of using this functionality. Enjoy! Iain
Category : Blog
RES Workspace Manager and 32/64 File Paths
November 2nd, 2011 @ Iain Brighton // No Comments
With deployments of x64 Windows Operating Systems (Windows 2008 R2 RDS and Windows 7) on the significant increase, you will discover over time that you need to support the same applications in the RES Workspace Manager management console but with two differing file paths. For example, Adobe Reader 9 on a 32-bit OS will typically be located in the ‘C:\Program Files\Adobe\Reader 9.0′ directory (or ‘%ProgramFiles%\Adobe\Reader 9.0′). The same application installed on a 64-bit OS will generally reside in the ‘C:\Program Files (x86)\Adobe\Reader 9.0′ directory (or ‘%ProgamFiles(x86)\Adobe\Reader 9.0′). On x64 system the ‘C:\Program Files\’ (or %ProgramFiles%) is used for native 64-bit applications. Now, if only Mickeysoft had chosen an alternative path the native 64-bit apps life would have been a whole lot easier…
Historically when deploying RES Workspace Manager on x64 Operating Systems you would have to update all your applications within the management console to reference the ‘%ProgramFiles(x86)%’ location as the installation paths are different. RES Workspace Manager attempts to fix problem this with on-the-fly redirection. That’s to say that it’ll automatically detect it’s running on a x64 OS and attempt to launch the executable in the %ProgramFiles(x86)% location instead of the defined %ProgramFiles% path. In turn this creates a problem for the 32-bit OSes as the ‘%ProgramFiles(x86)%’ system environment variable does not exist – DOH!
When I originally set out about writing this post, my understanding was slightly different from what I’ve ended up with. However, the findings are still valid so please continue to read. From the testing performed in preparation for this post with RES Workspace Manager 2011 SR2, it all appears to work correctly (shock/horror!). What I mean is, that not only does Workspace Manager appear to automatically redirect on 64-bit OSes, but also appears to attempt it on 32-bit OSes too.
The purpose of the “Disable folder redirection on 64-bit platforms” option (on a per application basis) stops RES Workspace Manager from redirecting entries defined with %ProgramFiles% to ‘C:\Program Files (x86)\’. Using Wordpad as an example, if you have the application entry defined as ‘%ProgramFiles%\Windows NT\Accessories\wordpad.exe’ Workspace Manager will automatically attempt to launch “C:\Program Files (x86)\Windows NT\Accessories\wordpad.exe” by default (the 32-bit version) on a 64-bit OS.
Checking the ‘Disable folder redirection..’ check box forces Workspace Manager to launch the actual process defined in the executable path, i.e. the 64-bit version. Obviously, this example only works if both 32-bit and 64-bit versions of the application are available. If you use Microsoft PowerPoint 2007 as an example, checking the ‘Disable folder redirection..’ option will break the 32-bit application on 64-bit OSes.
Caveat #1
The on-the-fly folder redirection only works when using system environment variables, i.e. %ProgramFiles% and/or %ProgramFiles(x86)%. If you have hard coded paths such as ‘C:\Program Files\’ or ‘C:\Program Files (x86)\’ it doesn’t work. So get updating all your applications to use these variables!
As previously mentioned, RES Workspace Manager appears to redirect on 32-bit OSes too. For example, Workspace Manager will launch an application defined with the executable path as ‘%ProgramFiles(x86)%’ successfully on a 32-bit OS even though the environment variable does not exist. I was not aware of this and can only assume that it’s a recent addition. Unfortunately this is different from what we’ve seen happening in the field and hence why we earmarked the subject for a blog post! What we have seen are applications failing to appear and/or launch correctly when updated to point to ‘%ProgramFiles(x86)%’ on 32-bit Operating Systems.
Caveat #2
Once you’ve updated all your applications with environment variables it should just work. To circumnavigate this issue we put the following simple workaround in place. Note: from the above diagnosis you should no longer have to do this.
Workaround
- Define the %ProgramFiles(x86)% environment variable only on 32-bit machines via a Location/Device zone. Configure this environment variable to point to %ProgramFiles%. On 32-bit systems both variables will point to same location but your applications are guaranteed to work on 32-bit OSes.
- Ensure that you replace all file paths for managed applications with their associated environment string (I have mentioned this already haven’t I?!). If you don’t do this then you’ll need to ensure you manage the availability another way, e.g. via Workspaces or Zones.
- Add/configure applications in the RES Workspace Manager console on 64-bit OSes wherever possible. This will ensure that 32-bit applications always use the %ProgramFiles(x86)% variable (and not cross-platform %ProgramFiles%). If not, you need to hope that RES Workspace Manager performs it’s on-the-fly redirection magic!
Thanks, Iain
Category : RES
Virtual Engine Toolkit v1.0 Released
October 31st, 2011 @ Iain Brighton // 2 Comments
We are pleased to announce that the free Virtual Engine Toolkit (VET) 1.0 has been released! The new release includes an updated wizard to convert multiple Group Policy Objects to .REG files in a single pass and also includes the new Profile Update Utility (PuU). For more information or to download now, visit the VET page on the Virtual Engine web site.
Category : Latest News
Disabling RES VDX
August 3rd, 2011 @ Iain Brighton // No Comments
If you’re like me you spend a lot of time on customer sites and a vast amounts of time using the RDP client to connect to various client machines and servers. It may just be me, but I find the whole RES VDX popup notification when starting an RDP session rather distracting. It’s fine if the client has the VDX Engine installed in the hosted desktop, but more often than not they don’t. Worse still, when integrating RES Workspace Manager with VDX it becomes even more frustrating when connecting with Admin accounts as, typically, the RES Workspace Composer is disabled. This results in VDX connecting in “time trial” mode, bringing the local applications through into the remote session and then dropping them with a pop up notification. Grrrr!
It’s for this very reason that I set off looking for how to disable the integration and allow me to re-enable it if necessary for testing. I checked the available Administration Pack but it doesn’t allow us to suppress the notification so off I went to Google. It didn’t take too long to find out where the RDP and ICA add-in settings are stored in the registry. The ICA key is only created if the Online and the locations are different for RDP and ICA..
RDP
Key 32-bit/64-bit: HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns\RESVDX
Value: Name
Type: REG_SZ
Data 64-bit: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x64.dll
Data 32-bit: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x86.dll
ICA
Key 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\RESVDX
Key 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\RESVDX
Value: DriverNameWin32
Type: REG_SZ
Data: VDXICAPlugin.dll
The simplest solution I’ve found is to rename the plugin DLL references in the registry so they’re not loaded. Renaming the individual registry keys doesn’t appear to work as the Add-In keys are still enumerated even though the key names have changed. I, for example, rename the above .dll filenames to .dl_ in the registry to disable the integration and set them back when needed. I have 2 .REG files; one to disable the integration and one to enable to make my life easier because I’m like that!
Quest vWorkspace and RES VDX Integration
July 29th, 2011 @ Iain Brighton // No Comments
We’ve come across some issues with the integration of RES VDX and Quest’s vWorkspace on a couple of customer sites just recently. Some old timers might remember an issue that occured when using the then, RES Subscrber/Workspace Extender, with Provision Networks Virtual Access Suite (VAS). The issue fixed by Q201760 RES Subscriber and RES PowerFuse Workspace Extender do not work with Provision Networks VAS is the same issue experienced with vWorkspace.
Both the legacy VAS client and the newer vWorkspace client are virtually the same and the registry key is still called ‘HKLM\Software\Provision Networks\Terminal Server Client\’. However, to integrate the newer VDX components we need to reference the newer VDX DLL(s) rather than the Workspace Extender DLL.
To get the VDX integration to work with vWorkspace we need to create one of the following keys on the local machine. Note: these registry keys are HKEY_LOCAL_MACHINE.
For 32-bit clients:
KEY: HKLM\Software\Provision Networks\Terminal Services Client\Addins\RESVDX
VALUE: Name
TYPE: REG_SZ
DATA: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x86.dll
For 64-bit clients:
KEY: HKLM\Software\Wow6432Node\Provision Networks\Terminal Services Client\Addins\RESVDX
VALUE: Name
TYPE: REG_SZ
DATA: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x86.dll
Simples once you know how! Iain
Patch Management with RES Automation Manager
July 14th, 2011 @ Iain Brighton // One Comment
It’s a question that I get asked; lots. As you may well know my stock answer to nearly all questions is “YES! However…” In this particular case I’m going to stick with my stock answer and I’ll explain why here.
Using RES Automation Manager to manage application deployment and patching is absolutely the right thing to be doing, but not for Microsoft products, i.e. Windows and Office updates etc. RES Automation Manager provides us with the advanced scheduling capabilities that are required when deploying updates. We can send feedback to users, control reboots and also create our own dependencies and prerequisites using the built-in Conditions. Creating installation and/or update modules for Adobe Reader, Flash and Java etc. is a fairly straightforward process.
So why can’t we use RES Automation Manager for MS updates? Let’s get one thing clear – there is nothing stopping you from doing this. However, do you really (and I mean REALLY!) want to be creating modules for every hotfix, patch and Service Pack that Microsoft releases? What about controlling installation orders and prerequisites? What about testing and ensuring the update is really needed before attempting to install it? When I last checked WSUS for Windows and Office updates I think there was more than 20,000+ updates. Hopefully you get the point!
What can we do then? By leveraging the metadata that Microsoft has already created we don’t need to and I’m guessing the product teams inside Microsoft are the best people to create this information! We use WSUS internally to manage our patching for Microsoft products on clients, servers, hosted servers and training labs. We recommend that our customers either use WSUS or an existing patch management tool if one is already in place. We then manage all other application installations and updates as Modules within RES Automation Manager and use its advanced scheduling capabilities to push them out.
Surely if we’re going to implement WSUS for Microsoft patching, it would make sense to patch all our products with an extension to WSUS? Not necessarily. Remember you’re getting a whole load more with RES Automation Manager than just pushing out patches; think Run Books and Evaluators. We can deploy software and machine configurations, provision resources such as Active Directory accounts and Exchange mailboxes and a whole lot more.
For those that want to extend WSUS there are products available in the market to integrate 3rd party patches such as Adobe and Java. Check out the EminentWare web site for one such example. You can roll your own application updates as well with the free Local Update Publisher on SourceForge.
At the end of the day, if you have to package a single internally developed application or products not supported with 3rd party tools you might as well extend that list to common middleware such as Flash and/or Java as save the money on the 3rd party integration. Leverage WSUS for what it’s good at and use RES Automation Manager for what it’s very good at; the rest!
Category : RES
Migrating RES Databases to a New SQL Server
July 11th, 2011 @ Iain Brighton // No Comments
We have recently had the requirement to move the SQL databases to a new Microsoft SQL Server 2008 R2 server. This process is not complicated, but there does seem to be a lack of documentation available. At a high level we need to perform the following actions:
- Backup the RES Workspace Manager and Automation Manager databases on the source server;
- Restore the RES Workspace Manager and Automation Manager databases on the destination server;
- Fix the SQL permissions, i.e. recreate the users and redelegate access;
- Update the RES Automation Manager Dispatchers to point to the new database server;
- Update the RES Workspace Manager Agents to point to the new database server.
I’m not going to cover Steps 1 and 2 as these are well documented on Microsoft’s web site and many other various blogs. In this particular instance we’re moving from SQL 2008 to SQL 2008 R2 and I’ve restored copies of the Workspace Manager and Automation Manager databases on the new server. The SQL user account for the Workspace Manager database (RES-WM) is ‘RES-WM’ and the user account for the RES Automation Manager database is ‘RES-AM’ (note that naming the database and user accounts the same is not best practice but it helps in our lab environment!).
Migrating RES Automation Manager
We’ll start with the RES AM database as we’ll then use this to update the RES WM information! Firstly we need to check that the correct user permissions have be granted on the new database server. When creating the SQL user accounts you’ll need to ensure that the password policies are set correctly:
In short make sure that the user password policies are disabled (unless you want to be forever updating your Dispatchers!). If you forgot to uncheck this and you can’t seem to change it, you can run the following SQL script via the SQL Management Studio (remember to change the RES-AM reference to your SQL user account!):
USE Master
GO
ALTER LOGIN “RES-AM” WITH PASSWORD = ‘samepassword’
GO
ALTER LOGIN “RES-AM” WITH CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF;
After this is complete you will need to ensure that the RES-AM user account has DB Owner (DBO) rights to the database via the “User Mapping” page of the user account:
Once we’re happy with this we can focus our attention on the RES Automation Manager console. As it’s only the RES AM Consoles and Dispatchers that talk directly to the SQL database, we do not need to worry about the RES AM Agents. From the RES AM management console select the Infrastructure > Setup > Database node and enter the new SQL database server name (if the username/password has changed you can update them here).
After you click the Connect button the management console will reload and ask if you want to use the connection information permanently.
The management console will reload. The final piece to this puzzle is to update all the Dispatchers and Consoles. From the Infrastructure > Engines node we need to repair each Dispatcher and update the SQL connection information.
After the Dispatchers have been updated don’t forget to update the consoles in the same manner. You could also run a registry job via AM to update the connection information (remember to do this from the old database as the Dispatchers will communicating with the old database until updated!) or push out a new MSI from the Components node.
Migrating RES Workspace Manager
Note: RES Workspace Manager 2011 has the built-in ability to migrate the exisiting database to a new SQL server and/or database; this can be found in Setup > Datastore > Connections > Click on the ‘…’ next to the Primary datastore to display the migrate wizard. At the end of the migration process after various other prompts you will also be prompted if you wish to create a handy building block that can be used in RES Automation Manager Module. You can use this Module to migrate RES Workspace Manager Agents running an older version of RES Workspace Manager, not yet containing the Datastore Migration Wizard. The only downside using the migrate method I’ve found is the fact you have to activate the licenses again; if this going to cause some issues follow the procedure set out below. [Nathan Sperry]
RES Workspace Manager is slightly different as all RES WM agents talk directly to the SQL server rather than via a Dispatcher. After migrating the RES Workspace Manager database (as above) and fixing the user permission we need to update the RES WM agents’ registry settings via RES Automation Manager! For this task I created a module that updates the required registry value and restarts the RES Workspace Manager agent service.
You will notice that there are two Reigstry Settings tasks with conditions; 1 is for 64-bit machines and the other for 32-bit. Note: if the authentication details have changed you’ll need to the relevant registry settings to both Registry tasks.
Note: if you have a mixture of freshly deployed RES Workspace Manager agents and agents upgraded from RES PowerFuse 2010 or earlier then the registry settings are in different locations and you may have more tasks/conditions!
Iain
Category : RES
RES Workspace Manager Zones and USB Devices
June 27th, 2011 @ Iain Brighton // 2 Comments
Have you ever had a requirement to base a Device Zone within RES Workspace Manager on a particular hardware device? If so, you may have already discovered that if is a storage based device then you’re good to go. However, if it’s not of a “removable storage” type then we’re seemingly out of luck. Not quite..
Whilst on a customer site, a requirement arose that necessitated that we detect whether a particular USB device was connected or not so that we could configure an application for the hardware device. After a lot of digging and searching, I discovered that device information is located in the [HKEY_LOCAL_MACHINE\System\CurrentContolSet\ENUM] registry subkey(s). The problem with these registry entries is that if the device has ever been connected then it will exist and it doesn’t indicate that the device is currently connected so it’s back to the drawing board..
On further investigation, the [HKEY_LOCAL_MACHINE\System\CurrentContolSet\Services] key lists all the currently connected devices (all internal devices are listed in here so don’t be too surprised how many there are!). The difficult bit comes in determining how your USB device is enumerated. As a general rule all USB devices attached will probably be listed under keys beginning with USB. For example, the USB microphone I’m using is listed under the ..\Services\USBAudio subkey and a USB printer under the ..\Services\USBPrint subkey (more detail on hunting this information down might be a future blog post). In this instance I’m going to pick on the Samson C03U microphone and show you how can create a Device Zone in RES Workspace Manager that will allow you to set configurations options only when it’s connected. Looking in the registry in the [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Serices\USBAudio\Enum] key exposes the following settings:
I know that my microphone is identified as USB\VID_17A0&PID_0100&MI_00\6&1895ccd4&0&0000. We can see that the Samson microphone is listed in here. When the device is unplugged the instance disappears like so:
So to create our Device Zone in RES Workspace Manager for detecting the presence of a Samson microphone all we need to is create a zone based on the presence of this particular registry setting? Nearly! By creating a zone on the information from the first screenshot, it will only be true for the microphone on my desk, not any Samson C03U mike that might be on someone else’s desk. Experience has shown that everything listed after the ‘&MI_00\6&’ is device specific, i.e. a serial number or unique identifer and can safely be ignored (unless you want to tie the zone to a unique device). Therefore, if we create a Zone based on the presence of the ‘USB\VID_17A0&PID_0100&MI_00&6*’ (note the wildcard) value it should work for all Samson C03U microphones.
Done? Almost (and you knew I was going to say that!). The value of ’0′ (zero) in the first screenshot depicts the order in which a device is attached. Therefore, if I just so happened to have another USB audio device, the Samson mike might be listed as the second device under ’1′ or the third device under ’2′ etc. In order to ensure that we account for this we need to add multiple entries in like so:
If I had 4 USB audio devices, then depending on the order they were attached my Zone may fail to detect that the Samson microphone was attached. I could have added 10 or so entries but hopefully you get the idea! If you have varying models of devices, then it’s likely that the PID_ (product ID) portion of the values will change. In this case, you’ll need to make sure the rules also incorporate any variations.
It would be nice to have pattern matching on the registry keys\values like we have within RES Automation Manager. Perhaps it’s an enhancement request, but in all honesty, why can’t we natively select any hardware devices attached rather than being restricted to USB storage devices already? Perhaps I’ll take this up with product management.
Good luck! Iain
Category : RES
RES Workspace Manager Registry Import Bug
June 2nd, 2011 @ Iain Brighton // No Comments
[UPDATE 01/08/2011 - RES have released a fixpack for RES Workspace Manager 2011 SR1 that resolves the issues highlighted in this post. I don't have any word on whether this fix will be rolled into the next Service Release of RES PowerFuse 2010 (SR5?). I hope so as we can then remove this post. In the meantime, please contact RES Software support to obtain this fix (assuming you're running WM 2011 SR1!)]
An issue has been discovered in RES Workspace Manager 2011 and earlier versions (e.g. PowerFuse) when importing .REG files. Ironically, this was discovered when converting existing Group Policy Objects via the Virtual Engine Toolkit (VET). RES Workspace Manager does not implement the removal/deletion of registry keys or values correctly. It has been reported to RES Software and they have acknowledged there is an issue. It is not an issue with the Virtual Engine Toolkit but a problem with any .REG file, i.e. one’s migrated from log on scripts etc. [UPDATE - for clarification purposes, a support ticket had been raised prior to this post and RES are working on a fix.]
The following snippet from a REG file (some entries removed for clarity) should toggle the removal of NoInternetIcon and NoNetHood values and also toggle the removal of the \Software\Policies\Microsoft\Windows\NetCache\AssignedOfflineFolders key.
Windows Registry Editor Version 5.00;
Created by the Virtual Engine Toolkit v0.9.7.0;
Creation date: 05-30-2011 17:04:08
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
“DisablePersonalDirChange”=dword:00000001
“NoDesktopCleanupWizard”=dword:00000001
“NoInternetIcon”=-
“NoNetHood”=-
-[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\NetCache\AssignedOfflineFolders]
What actually happens is RES Workspace Manager sets the two DWORD vales to 1 and doesn’t even import the \Software\Policies\Microsoft\Windows\NetCache\AssignedOfflineFolders key as shown below. This results in complete unexpected behaviour and might impact any Proof of Concept or pilot deployments.
Hopefully this issue will get resolved promptly but in the meantime, please be vigil!
Iain
Category : RES
