siteadmin – Page 12 – Virtual Engine Ltd

15th September 2010

RES PowerFuse Workspaces White Paper

Hot off the Virtual Engine press is the “RES PowerFuse Workspaces” White Paper. The White Paper can be downloaded from the Virtual Engine website here. As always, positive and negative feedback is welcomed.

When delivering RES PowerFuse training, this subject is something that some delegates can find confusing. As RES PowerFuse Workspace Containers have many uses, getting in a real twist is incredibly easy to do. This White Paper walks you through all of the RES PowerFuse Workspace Container uses based on a fictitious company providing a practical example of what to do and what not to do.

A big thanks to Max Ranzau AKA RESGuru for his assistance in getting this document completed. Enjoy!

13th September 2010

Disable Active Setup

RESGuru has updated the RG01F – Getting rid of the first-time login stuff technote article with the new RES PowerFuse 2010 SR2 feature; “Disable Active Setup (Skips First Time Shell Init)”. My experience with this is that it works for v2 profiles, but not v1, e.g. Windows XP and Windows Server 2003.

During a RES PowerFuse 2010 SR2 PoC , we had deployed mandatory profiles for both Windows XP desktops and Windows Server 2003 with Citrix Presentation Server 4.0. Checking the aforementioned checkbox did not have the expected behaviour, i.e. we assumed that it would stop the Active Setup components from running. Needless to say – it didn’t and we were back to square one. After a call to support it appears that this only works on Windows 2008/R2 and Windows 7, i.e. v2 profiles.

Whether this is a bug or a “feature” I’m not sure.

13th September 2010

Migrating GPOs to RES PowerFuse (Part 1)

When delivering RES PowerFuse Pilots, the process that typically takes the most amount of time is the manual creation of existing user Group Policy Objects (GPOs). With a Pilot (and Proof of Concept) deployment a clean OU within AD is a mandatory requirement. This ensures that we have a safe haven to place the Pilot user accounts to ensure that they are not impacted by any existing GPOs and logon scripts. Adding RES PowerFuse on top GPOs and logon scripts is going to slow the logon process down and is contrary to what is trying to be achieved!

In an ideal situation, the Pilot customer will know which GPOs and which settings need to be applied to which user groups/OUs that are partaking in the Pilot. After the required ADM/ADMX files have been located, the required settings can slowly and painfully be transcribed into RES PowerFuse as User Registry Policies.

As a GPO is made up of one or more ADM or ADMX files, the Group Policy Management Console (GPMC) does a fantastic job of consolidating these in to a single view and a single resulting GPO. Unfortunately, RES PowerFuse doesn’t do a great job of this. We can upload individual .ADM and .ADMX files but the result is numerous User Registry Policies for what was a single GPO. Let’s take Microsoft Office 2007 as an example. There is a separate ADM template for each Office 2007 application. In the GPMC we see these in a single view and can manipulate the settings under one Group Policy Object. With RES PowerFuse we need to upload each ADM template and create a User Registry Policy per ADM template. Now we have five User Registry Policies – one each for Word, Excel, Outlook, PowerPoint and Access rather than one. If we need to provide different settings to five groups of users we’ll need 25 User Registry Policies rather than 5 GPOs!

As an option, we can export the User Registry Policies from the RES PowerFuse management console to individual .REG files. The original User Registry Policies can be disabled and a new User Registry created. All the .REG files can be merged to create a single User Registry settings equivalent to our single GPO. However, by doing this we do lose the ability to “browse” the ADM file to turn settings on an off like within the GPMC.

The original ADM files shipped with Windows Server 2000 and Windows Server 2003 were quite large but there weren’t too many of them. With the release of Windows Server 2008 the file format changed to XML and Microsoft took the opportunity to split the large large ADM files in to many smaller ADMX files. On my test machine, I have 147 ADMX files on a basic install of Windows 2008. Now that equates to lots of User Registry Policies in the RES PowerFuse management console!

If getting the Pilot (or PoC) up and running as quickly as possible is a must, this manual process is going to add a vast quantities of time configuring the User Registry Policies. Manually transcribing the GPOs does allow for a review and consultation to be performed which is no bad thing considering there may be years of GPO bloat. What if there was a quicker method to actually getting the existing GPOs into RES PowerFuse? Would replicating existing GPOs “as is” without the review and consolidation be a good starting point? Would it be of benefit?

To be continued…

8th September 2010

Building Block Spinner (BETA 1)

The Building Block Spinner was written to solve a particular issue in a global PowerFuse 2008 deployment. In this example there are 4 PowerFuse databases, 2 in Test (Dev and UAT) and 2 in Live (Pilot and Prod). The Active Directory NetBIOS domain names are different in each environment and to add insult to injury, changes can originate in both Test and Live (global file authorisations etc).

In this example we can’t simply export Building Blocks (BBs) from Test and import them in to Live. Every time a new release is created, we need to perform the following actions:

Export the required BBs from Test DEV database.
Rewrite the domain names in all the BB files with the Live domain name.
Import the BBs in to the UAT database into Test and ultimately the 2 Live databases.
Export the relevant BBs from the PILOT database and/or the PROD databases in Live.
Rewrite the domain names in all the BB files with the Test domain name.
Import the BBs in to the databases in Live and the 2 Test databases.

As you can probably guess this process is error prone (and so is the change control process but that’s probably another blog post!). What the Building Block Spinner (BBS) allows us to do is drag and drop all the Building Blocks for an individual “release” into the program window, click a button and spit out two sets of Building Blocks, one for Test and one for Live. These Building Blocks can then be imported into the relevant environment. It doesn’t do anything particularly clever as it’s performing a simple find and replace function and spitting out two differently named sets of files.

There are plans to expand this to be able to rewrite particular tags, i.e. XenApp servers/groups for each environment and merge the resulting BBs in to a single file for each environment (hence the “Merge Files” option that is greyed out!). If you have any feedback or recommendations, then please let me know.

The Building Block Spinner can be downloaded from here.

6th September 2010

RES PowerFuse – Top 10 Wish List Update

I don’t think this list was ever published (I think I had a Wisdom one too) but I thought I’d share it just to show how much the PowerFuse product has come on since the 2008 release. I might get around to updating the list with new features for the ones that have made it in to the product. As you can see five of these wishes have been implemented fully within the RES PowerFuse 2010 product and two have been implemented partially. Kudos RES!

Original Post

Oh this list could have been so much longer! Why the list? Just wanted to put on “paper” my wish list so that someone might read it but, more importantly so that the rest of the world can add their comments and wishes to it too…

Licensing – Change the licensing model to a modular/vertical approach. The Express, Standard and Enterprise Editions are a start but they don’t go far enough for the UK market. I’ll cover my thoughts on this in another post some time..
Branding – For a product that interacts with user is such an obvious way, the inability to brand the log on banner with company information amazes me! OK – your company name is displayed but the RES branding takes up 75% of the available space. It’s the #1 request I get from people as soon as they see the product. I don’t necessarily think that the RES branding should be able to be taken away completely but your company logo/colours should be definable and more prominent than RES’s. They’ll do it – but you’ll get handsomely charged for the privilege. Update: RES PowerFuse 2010 can be rebranded via a signed XML file generated by RES with enough justification.
Local Groups – You can enable local group enumeration but you can’t add a “global” local group. For example, you can specify “CLIENT1\Administrators” and “CLIENT2\Administrators” as exceptions to the PowerFuse shell. I’d like to be able to specify “.\Administrators” so that all local administrators (including the local Administrator) can be excluded. This doesn’t break the AD integration and makes supporting non-domain or not trusted domain members easier. Update: Local groups are now supported but the implementation is limited. Remember PowerFuse finds the first match in its Directory Services definitions and then stops. If we have an Active Directory and Local Computer definition, we can only enumerate one. For example, if we target the local “Administrators” group then we apply different settings but we can’t then see their domain credentials as well!
Default Application Settings When Importing – it would be great to be able to set the default options when importing applications, either a global default or as part of the wizard. It’s a pain to have to go and change the “Maximum Instances” field to 3 or “Check application availability on client” for instance on all the imported applications. FIXED.
User Preferences – By default they’re stored in a compressed format and cannot be opened. It’d be handy to be able to get inside and delete a file or registry setting if it’s causing problems. Currently you have to wipe all the information and start again (argh!). FIXED: We can now browse and export both file and registry User Preferences/Settings.
Multi-Language Applications – There is no default way to attached language specific application Titles and Descriptions to each application. The current work arounds are either to create a lot of environment variables or create an application for each language variation which is just crazy!
Custom Backgrounds – We can enable custom backgrounds by removing the check in Desktop Management > Lockdown > Workspace Manager > Hide Change “Desktop Picture” in PowerPanel option. Unfortunately, if we want custom backgrounds, i.e. BGINFO, we have to let the user have the option of changing it. The ability to specify a custom background in the PWRUSER.INI file but remove the users’ ability to change it would be handy. FIXED: With the RES PowerFuse 2010 Workspace Model we can manage the background independently.
RES Wisdom Tasks on Applications – If you could launch an external RES Wisdom task prior to launching an application would enable us to install it on first launch. Rather than making sure all applications are installed on all computers this would be a great addition. Obviously we’d have to let people know that an application is being installed whilst they have to wait. FIXED.
PowerFuse Shell Redesign – The existing PowerFuse shell is great but now looks more than just a little bit dated. From some of the discussions I’ve had with RES employees there might be a change coming. It might be similar to the Windows Server 2008 shell which would be a great improvement.
Database Creation – When installing PowerFuse for the first time it requires an SQL account with SA privileges. In the corporate environment the SQL DBA’s won’t give you this permission ‘just to install and create the database’. Whilst there are workarounds, having the option to use an account that has DBO rights on a ‘pre-configured, blank database’ would make my life a lot more simpler when on customer sites! FIXED.

6th September 2010

Capture Targeted Items Once, Then Track Further Changes

New in RES PowerFuse 2010 Service Release 2 (are they being called Service Packs now!?) is the “Capture Targeted Items Once, Then Track Further Changes” option that applies to User Settings. This has been introduced to solve a particular problem and I’d thought I’d elaborate on this a bit further.

There are two modes of operation with User Settings at an application level within PowerFuse; “Track specified settings on application/session start/end” and the new“Track any setting changed by the application immediately” settings.

Track Specified Settings on Application/Session Start/End

This is the legacy PowerFuse 2008 User Preferences mode. During an upgrade to PowerFuse 2010, User Preferences are preserved in this mode.

To capture user registry and profile information, the items we wish to capture have to be explicitly defined. That is to say, ‘if we don’t tell PowerFuse exactly what we want to capture, it won’t be captured and won’t necessarily persist across user sessions’.

It works well, but as administrators we need to know where in the profile/registry application settings are stored and more importantly, what actually to we need to capture for our users. Many an hour will have been spent running applications with SysInternal’s Process Monitor to find out what an application is doing and then transferring this in to PowerFuse. If you’ve been using Mandatory profiles then you’ll know how painful and laborious this can be. Fret not – I feel your pain!

Track Any Setting Changed by the Application Immediately

Welcome to 2010. The ‘zero profile’ mode in PowerFuse 2010 is our saviour! What the new mode means is that we no longer need to know exactly where an application is making changes as the AppGuard and RegGuard drivers can monitor the application process and capture any changes that are made the HKCU registry hive or the user’s Profile directory.

Now don’t get too excited (you knew that was coming didn’t you!?)… It doesn’t always work and we have to revert to the old PowerFuse 2008 way of doing things if external processes are involved. Fortunately, these are the exception and not the norm.

The Problem

Unfortunately for us, this has one major short coming. If you deploy RES PowerFuse 2010 in to an existing site (not running RES PowerFuse 2008 previously) to capture user settings (read Stealth Mode here), then changes to user settings will be captured and stored in the user’s UserPref folder. But (and it’s a BIG BUT!), only the changes are captured. Therefore, if a user does not make a change settings within an application that may have been changed prior to deployment, they are never captured. DOH! Now my Windows XP to Windows 7 migration is never going to work Angry smile .

The Solution

This my friends is where the ‘Capture Targeted Items Once, Then Track Further Changes’ comes in. It does exactly what it says. The first time PowerFuse is invoked for the user the defined settings will be captured once. From then on it’ll track only the changes made to the user’s registry and profile directory. It solves the issue of not capturing the settings that the user never changes. Again, we’re back to square one and have to know roughly where the application settings are stored to be able to capture them the very first time PowerFuse kicks in.

Fortunately for us, our kind friends at RES have provided us with some application Templates for the major applications and system settings. This is another blog post, but even they’re still not perfect and need the odd ‘tweak’..

2nd September 2010

PowerFuse Delegation

Delegating access within PowerFuse is something that seems simple in theory and is covered on the official RES PowerFuse 2010 Basic Course (RPFBC-300). In practice, designing and implementing a delegation model takes a lot of thought and knowledge. The delegation model is something that has to be taken in to account during the design stage of a PowerFuse deployment otherwise you’ll find yourself re-architecting your environment!

Whilst working on the “soon-to-be-released” RES PowerFuse 2010 Workspaces White Paper, I thought that this was worthy of sharing now. What follows is some elaboration on how the delegation model works and things you need to know to implement it effectively, right from the start.

Administrative Roles

Administrative Roles (or ARs) are used to restrict what nodes within management console a PowerFuse administrator can see, manage and configure.

Administrative Roles are cumulative

That’s to say that if an administrator is assigned two Administrative Roles they’ll get the combination of both.
If Administration Role #1 only grants read access to the ‘Managed Applications’ node and Administration Role #2 grants read access to the ‘Drive and Port Mappings’ node, the effective rights are read to both nodes (assuming the administrator falls within both Administrative Roles).

Deny does not override Read and Modify rights

Unlike the NT ACL model.
If Administrative Role #1 grants Deny access to the ‘Managed Applications’ node and Administrative Role #2 grants Read access to the same node, the effective right is Read (assuming the administrator falls within both Administrative Roles).

Locations and Devices are not accounted for with Scope Control

Therefore only static agent assignments in Workspaces can be used to limit the agents displayed in the management console.
If the effective rights of all assigned Administrative Roles results in Deny access to the Locations and Devices node, then administrators cannot use or assign them to objects. No access to read the Locations and Devices means no access to assign them to objects either (which makes sense!).

Scope Control

Scope Control is used to further restrict what a PowerFuse administrator can see and target within each node in the management console as a result of their effective Administrative Roles. For example, we might allow an administrator to create/update objects within the ‘Managed Applications’ node in the management console, assign them to a particular OU within Active Directory and/or only attach them to a specific Workspace Container.

Sounds so simple! Unfortunately, there are numerous factors that you need to be aware of when designing a delegation model.

The Workspaces and Identities defined within a Scope are exclusive

The objects to be managed must be exclusively assigned to Workspace and/or Identities that are within the administrator’s Scope.
If two Workspaces are assigned to an object and the administrator’s Scope only includes one of them, the administrator will not be able to manage the object. The resulting permission is Read Only.
If two Identities are assigned to an object and the administrator’s scope only includes one of them, the administrator will not be able to manage the object. The resulting permission is Read Only.
When two or more Scopes are in effect they cannot be combined. For example, if AR #1 restricts an administrator to OU #1 and Workspace #1 and AR #2 restricts access to OU #2 and Workspace #2, an administrator cannot assign access on an object to OU #1 and Workspace #2. They can restrict access to OU #2 and Workspace #2 as defined by the Scope Control.

Administrators can only create objects that target the Identities and Workspaces within their scope

Workspaces have to be assigned when creating objects if Workspaces are included within the administrator’s Scope. For example, if an administrator has only been given Workspace #1 in their Scope, they have to assign objects to the Workspace #1 during creation, the “All Workspace Containers” nor any other Workspace cannot be selected.
All objects created by the administrator can only be assigned to users and groups that are defined on the administrator’s Scope. For example, if an administrator has only been given OU #1 in their scope, they have to assign objects to either users or groups that reside in OU #1, the “All Users” access principal cannot be used.
When both Workspaces and Identities are in an administrator’s Scope, both have to be explicitly assigned to every object during creation. The management console will give the “Object can not be saved because it does not match the scope that is currently in effect” error message meaning it has to be assigned both an Identity and a Workspace included within their Scope.
PowerFuse will allow administrators to assign groups to objects if the groups reside within Organisational Unit Identities defined within their Scope. For example, if application groups need to be assigned to objects, then the group objects have to exist with an OU assigned under the Identity tab in the Scope Control definition. The individual groups do not need to be listed explicitly.

The “All Users” Identity can be assigned by any Administrative Role regardless of their assigned Access Control Scope

Any Administrative Role can create an object (assuming the Administrative Role permits) targeted at the “All Users” access principal.
This is however, restricted to “All Users” that fall within the targeted Workspaces in Scope, but only if Workspaces are assigned.
Objects assigned to both the “All Users” and the “All Workspace Containers” access principals are visible (Read Only) if the Administrative Role grants either “Read” or “Modify” rights, whilst technically being out of Scope.

The Scope Control is taken in to account when displaying RES PowerFuse agents (only if the “Include All Computers” is not selected on any Workspaces within the Administrator’s Scope)

Checking the “Include All Computers” option on any Workspace Container will grant access to all agents if the Workspace is in the administrator’s Scope.
The Administration Role has to be granted Read or Modify via the Administrative Role to the Agent node to be to view the “Agents” node within the management console.

24th August 2010

PowerFuse 2010 SR2 Released

RES PowerFuse 2010 Service Release 2 is now available for download from the RES Software portal. New enhancements in this release include:

Allow Folder Synchronization to utilise network drives.
Support for Microsoft Office 2010 and the Microsoft Sync Framework 1.0 SP1.
User Settings Templates for common applications. This new feature might even allow migration of effective GPO settings as a one time operation..

12th July 2010

RES PowerFuse 2010 training

22nd June 2010

Hosted RES Training Labs

RES Workspace Manager 2012 and RES Automation Manager 2012 training labs are now available for RES training partners. Virtual Engine Hosted Labs provide RES training partners with greater flexibility and efficiency when delivering Workspace Manager or Automation Manager training. Now you can focus on growing training revenue, reducing costs and improving student satisfaction by unifying your training delivery.

Delivery of up-to-date training labs is accessible via a web browser with internet connectivity. Now you’re free to just “turn up and teach” rather than having to update, maintain and schedule time to configure the training environment prior to each course. For further information, please contact us.