Blog – Page 8 – Virtual Engine Ltd

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

7th May 2010

RES Workspace Manager 2011 Training

The new RES Workspace Manager 2011 training courses are now available.

RES Software have announced the availability of the new RES Workspace Manager 2011 courses (RWMBC-4×0) and the 2 day RES Workspace Manager 2011 upgrade (RWMUC-400) course. Virtual Engine consultants are trained and qualified to deliver this training today either at the partner locations or on customer site.

For more information, please see the training page or contact us.

23rd October 2009

User PWRMENU.INI Preferences

The PWRUSER.INI file stores the user specific settings for their PowerFuse environment. For example, if a user chooses to place certain application shortcuts on the desktop or in the Quick Launch then the application list is stored within this file. That’s all well and good, but what options can I set in PWRUSER.INI file and how do I go about implementing them?

When a user first logs on the default PowerFuse action is to copy the model \PWRMENU directory (under the ‘Configuration Management > PowerLaunch > Directory Maintenance > Home Directory > Settings‘ node in the PowerFuse management console) if it doesn’t already exist to the user’s home directory. This directory is hidden so you might have to change your Windows Explorer settings to see it.

If you wish to set defaults for new users then you can make the required changes in the PWRUSER.INI file directly from the management console. To change the settings for existing users then you will have to implement a Home Directory maintenance task to modify the specific Section, Key and Value settings within the PWRUSER.INI file (you do remember those Windows 3.1 .INI files don’t you!?).

The options for the PWRUSER.INI are not listed in the application help although there is a RES Knowledge Base article, ‘Q200958 INFO: PWRUSER.INI explained‘, that details all the available settings. In case you don’t have a portal login or can’t be bothered to look, here are some of the common settings:

[Preferences]
SmallIcons={Yes/No}
LeftRight={Yes/No}
TimeoutScrnSaver={0/99}
SwapMouse={Yes/No}
Printer={\\server\printershare}
PreviousPrinter={\\server\printershare}
DesktopColor={ColorNumber}
DesktopForeColor={ColorNumber}
HideDescription={Yes/No}
ShowAllOnDesktop={Yes/No}
MessageDefaultPrinter={Yes/No}
NoAppGuard={Yes/No}
OnTop={Yes/No}
LCID={Windows Language Number}
MLS={RES PowerFuse Language Code}

If you’re looking for a particular setting then make the change within PowerPanel and then check the PWRUSER.INI file. I do this all the time for the background colours as they don’t appear to follow any standard RGB scheme that I can decode!

22nd September 2009

HOW TO: Mandatory Profiles

I highly recommend using Mandatory Profiles with PowerFuse in Terminal Services and VDI deployments. There is some information around the Internet detailing how to do this, but none of it appears to be step-by-step and you’ll get various snippets of information from varying sources. Having set this up on numerous occasions and having to piece together the details each time from my notes I thought I’d share them. I’ll cover some PowerFuse specific recommendations and best practices in a future post. Enjoy!

Creating the Mandatory Profile:

Create the mandatory profile on your file server. For example, create the ‘D:\MandatoryProfile’ folder.
Copy the Default User profile directory to the ‘D:\MandatoryProfile’ folder.
Rename the ‘Default User’ folder to ‘Mandatory’ (or whatever you wish).
Rename the D:\MandatoryProfile\Mandatory\NTUSER.DAT file to NTUSER.MAN.
Remove NTFS permission inheritance and copy the existing permissions.
Remove all named ACEs for all non-“Well Known Groups” and users.
Add ‘Authenticated Users’ with Read and Execute permissions.
Change the Owner of the directory (and sub-directories/files) to the local ‘Administrators’ group.
Share the ‘D:\MandatoryProfile’ folder as ‘Mandatory’.
Add ‘Authenticated Users’ with Read permissions to the share permissions

Modifying the Profile:

Delete the NTUSER.LOG file and any other files/shortcuts that you don’t want available to the users from the ‘D:\MandatoryProfile\Manadatory’ folder.
Change the registry permissions in the HKCU registry hive:
1. Open REGEDIT.
2. Highlight the HKEY_USERS hive.
3. Select ‘File > Load Hive‘.
4. Browse to the ‘D:\MandatoryProfile\Mandatory\NTUSER.MAN‘ file.
5. Enter a name for the hive. This is only a place holder whilst the HKCU hive is loaded and can be named anything you like, i.e. ‘MAND’.
6. Edit the permissions (Right click > Permissions) on the loaded hive and;
  1. Remove any non-“Well Known Groups” or individual users.
  2. Add the local ‘Users’ group with Full Control.
7. Make any specific registry changes required here, for example, disabling the default Windows Startup sound.
8. Unload the registry hive by highlighting the ‘MAND’ key and selecting ‘File > Unload Hive‘ from the menu. If you don’t unload the registry hive users will not be able to load the mandatory profile and receive errors at log on.
Add additional files and shortcuts that you want available to the users, e.g. desktop shortcuts.

Assign the Mandatory Profile to users:

To assign the Mandatory Profile to Terminal Services users, specify the users ‘Profile Path‘ setting as ‘\\SERVER\Mandatory\Mandatory‘ on the ‘Terminal Services Profile‘ tab of their AD account(s).
To assign the Mandatory Profile to desktop and laptop users, specify the users ‘Profile Path‘ setting as ‘\\SERVER\Mandatory\Mandatory‘ on the ‘Profile‘ tab of their AD account(s).
To assign the Mandatory Profile to VDI users, assign the profile as per the ‘desktop and laptops’ option above.