Month: September 2010

Posted on

The Power Of 3

With the release of RES Wisdom 2011 hopefully dropping in our laps by the end of this calendar year, I thought it would be wise to revisit the Orchestration Pack for Wisdom. Having delivered many, many training courses this year, it is something that is discussed during both the RES Wisdom 2009 and RES PowerFuse 2010 courses. However, that is it – generally it is just a passing mention! I think this will be changing with RES Wisdom 2011 so we’d better get to grips with it.

RES Orchestra was always going to be the 3rd product in the RES Software suite, but RES instead rebranded it and announced it as an add-on for RES Wisdom (announced back in August 2009). The theory behind the Orchestration Pack is to be able to add business logic and workflows to both RES PowerFuse and RES Wisdom. When all three products are combined together we end up with a very powerful solution, driven by the business and not the IT department.

At a high level we define a “Catalog” of “Services” that are available to “Subscribers”. These Services could be anything that the business offers that requires some automated process and/or workflow to be performed (you’re only limited by your imagination). To get you off to a flying start we normally start with the basics; like granting access to applications or provisioning of a new user. These are IT related tasks, but they help you “get what Orchestration is all about.”

Let’s take our typical RES Wisdom Run Book example; provisioning a new user. You might have a Run Book defined within RES Wisdom that creates the user account in Active Directory (and configures it), creates their Exchange mailbox, creates the user’s home directory and then secures it. In addition you may have multiple Run Books that adds the user account into different sets of AD groups or creates MS SQL accounts depending on the user’s role.

Here is a “typical” new user (with RES Wisdom) workflow:

  • A manager in the business requests a new employee.
  • HR authorises the request and passes the request to IT.
  • IT provisions the user (via the RES Wisdom Run Book!).
  • IT adds the user to the relevant AD groups for the proposed role (via another RES Wisdom Run Book(s)).
  • IT send the details of the new user account to HR.
  • HR forwards the details back on to the requesting business manager.

In the above example, the RES Orchestration Pack will enable us to encapsulate the business logic and the workflow processes via the Orchestration Client (32-bit client executable) or via email and the Orchestration Web Client (hosted on IIS). We can offer the “New Employee” “Service” via the “Catalog” to the business managers. The RES Orchestration Pack will allow the business manager to complete the new starter request via an internal web site (with all the required new starter information) and automatically notify the HR department. Once HR approves the request, the RES Wisdom Run Book is automatically started to create the AD user account and mailbox etc. Once complete the details of the user account can then automatically be sent back the business manager.

We can take this process further and define what happens when the “New Starter” request is reversed. Now we have the power to start an alternative Run Book to decommission the user account when initiated by HR.

So what about “The Power Of 3?”, I hear you ask. We can connect the RES Orchestration Pack to RES Wisdom, but what about RES PowerFuse? Well, it’s good news here too. Within RES PowerFuse 2010 we have the ability to assign access control principal to a RES Orchestration Pack “Service”. When a “Service” is provisioned/authorised then we can grant access to RES PowerFuse 2010 applications. Here is a scenario that takes our HR example another step further on:

  • A user can request a “Service”, i.e. Adobe Acrobat.
  • The request is sent to the user’s line manager for approval.
  • If the business manager approves it then a notification is delivered to the account department for recharging.
  • Once a user has been granted access to the “Service” we can now make applications available to the user automatically via RES PowerFuse.
  • We can configure RES PowerFuse to launch a RES Wisdom module to check for the existence of the application prior to launch.
  • If it’s not installed, pop up a message and install it on demand.
  • Once installed, it will launch.
  • If the user is revoked access in due course, RES PowerFuse will not display the application to the user.

Now we can automate the business workflow, authorisation, delivery, presentation and installation of services and/or applications without being involved. The business has the power to decide where and when things happen, not IT. That my good friends, is the power of 3; RES Wisdom, RES Orchestration Pack and RES PowerFuse!

Posted on

Decoding the PWRMENU.INI Colours

Setting the desktop foreground and background colours is something that trips most of us up when we’re first picking up RES PowerFuse. The default PWRMENU.INI file contains default colours that are created at install that apply to all users. If these colours are changed via the Composition > Desktop > Background node in the RES PowerFuse Management Console, then the template PWRMENU.INI file is updated. Any time a change is made to the desktop colours, it won’t affect users that have already launched a RES PowerFuse session as the user’s PWRMENU.INI file won’t get updated (with the default settings). For an explanation and work around this, see RES Knowledgebase Article Q200186.

This however, is not what this post is about. Typically when uploading a custom background image we normally wish the background colour to match the background colour in our .BMP file (remember only the RES PowerFuse Shell supports .JPEGs). This is certainly true if we’re not stretching the image to fill the screen. If it’s not changed you’ll see the default blue background applied before the background image is applied and/or borders around the background image.

Unfortunately for us, when selecting the colours using the RES PowerFuse Management Console it is not necessarily intuitive or easy to pick the right colour that matches your uploaded .BMP file. We have to specify a custom colour, enter the RGB values, save the changes to make sure the default PWRMENU.INI is updated, open the default PWRMENU.INI file, note the colour “number” specified next to the DesktopColor property and then create a Home Directory Maintenance Task to update this value for existing users (as per the aforementioned KB article). Not particularly quick nor intuitive. Note: If you’re after a tool to pick up colours then you can use ColorPic and it freeware.

We’ll take Virtual Engine as an example. Internally there is a colour that is known as VE-Blue (or Virtual Engine Blue). This is the standard shade of blue used in email communication, on business cards and the on web site etc. The RGB (Red, Green and Blue) representations of this are; 4 (Red), 73 (Green) and 157 (Blue) or 04499D in hex. Is there an alternative process available to set the background colour used by RES PowerFuse without jumping through all the hoops listed above?

In the user’s PWRMENU.INI configuration file the colours are not specified in the standard hex/web format, they’re represented as a decimal number. Using the “Programmer” view available in the standard Windows 7 Calculator we can convert 04499D (hex) into decimal (280989). We now have the decimal representation that can be put straight in to the Home Directory maintenance task. Knowing this information we update the default PWRMENU.INI file and create a Home Directory Maintenance Task that updates this for all existing users… Ah – when testing this we end up with a nice brown, muddy background. Not what was expected!

After a little bit of reverse engineering, it turns out that the number is reversed and actually stored as a BGR (Blue, Green and Red) value. In our example we need to convert 9D4904 (hex) to its decimal value, i.e. 10307844. Putting this value in our Home Directory Maintenance Task and the default PWRMENU.INI file works first time and is an exact match. If you happen to have lots of different coloured backgrounds for various departments in your environment, this little bit of knowledge might save you 30 minutes and a lot of frustration one day..

Posted on

Staging RES PowerFuse 2010 Agent Deployment

Disclaimer: This is definitely something that  is not supported or endorsed by RES Software in any way shape or form. If you can avoid doing this then do not use it. Use at your own risk!

In large RES PowerFuse deployments where RES PowerFuse agents are located over a WAN link, deploying RES PowerFuse can place an unwanted strain on those WAN links during initial deployment. When the RES PowerFuse agent is first installed, it connects to the database and downloads the cache. Until this is complete (and if the Workspace Composer is enabled) a user is unable to log in.

In instances like this it is ideal to have database instances located on the local sites but this is not always possible due to licensing issues etc. If this is the case, then having 100+ agents download 50MB+ leads to a lot of unwanted bandwidth being consumed! This guide will help you stage the deployment so that the agents only download the deltas from our “database snapshot” that is deployed as and when we install RES PowerFuse.

To accomplish this, we need to think about the database structure and how the agent caches its information. The RES PowerFuse 2010 database contains GUIDs for each of the configuration database tables and a master GUID. Whenever anything is updated within the Management Console, the master GUID is updated and this update is cascaded to all corresponding configuration tables that have changed, updating their GUIDs in turn. When an agent connects it checks the master GUID and if different from its own master GUID, compares the GUIDs on each table and downloads the differences. The agent stores its cache and state information in a few places:

  • The local state of the database cache is maintained in the registry (HKLM\Software\RES\PowerFuse\UpdateGUIDs). These values are the GUIDs that the agent uses when connecting to the database. If any database configuration table GUID is different from what is stored here, an update is performed and the GUID changed to match the GUID in the central database.
  • The cached database tables are stored in XML format in the ‘%RESPFDIR%\Data\DBCache\Objects’ directory.
  • All other supporting resources are located within the ‘%RESPFDIR%\Data\DBCache\Resources’ directory and ‘%RESPFDIR%\Data\DBCache\IconCache’ directories.

Now, in theory all we need to do to pre-stage the agent cache is make sure that the UpdateGUIDs in the registry match what is in the \Objects, \Resources and \IconCache folders when the agent service is started. To capture our pre-staged “snapshot” we need to perform the following actions:

  1. Stop the RES PowerFuse agent service.
  2. Copy the \Objects, \Resources and \IconCache folders somewhere safe.
  3. Copy all the UpdateGUIDs from HKLM\Software\RES\PowerFuse\UpdateGUIDs (probably an export to a .REG file)

Herein lies the key to this operation. When we deploy the agent, the RES PowerFuse agent service is going to automatically start and proceed to populate the local cache and update the UpdateGUIDs in the registry. We do not want this to happen until we’re ready. Therefore, this is the process that we need to achieve:

  1. Install the RES PowerFuse agent unattended in the supported fashion, i.e. with Wisdom, ensuring that the agent service does not start.
  2. Copy our “snapshot” files to the \Objects, \Resources and \IconCache folders. How we do this depends on your deployment methodology. Typically the “snapshot” files would be captured as a RES Wisdom Resource Package, but it doesn’t really matter.
  3. Set the HKLM\Software\RES\PowerFuse\UpdateGUIDs registry values to our point-in-time ““snapshot” to match what is representative of the “snapshot cache” folders. Again, this can be achieved quite simply with a RES Wisdom “Apply Registry Settings” task, but could also be achieved via a batch file calling REG.EXE.
  4. Start the agent service (a reboot is still required for the kernel mode drivers to start). If we just reboot the service state is left as “Automatic” and will start after just a reboot.
  5. The agent will check the database and only download the deltas from the point-in-time “snapshot” hopefully saving a whole load of bandwidth!

The only real “gotcha” in this entire process is ensuring that the agent service does not start when the agent is installed, e.g. in Step #1 above. As the agent does not support the public properties to accomplish this we need to do it via a .MST file. To save you a whole load of time and pain we’ve kindly left one here for you called “RPF-NoServiceStartAfterInstall”.

Our example deployment command for Step #1 might look a little like this: MSIEXEC.EXE /i RES-PowerFuse-2010-SR2.msi TRANSFORMS=RPF-NoServiceStartAfterInstall.mst DBTYPE=MSSQL DBSERVER=<DatabaseServer> DBNAME=<DatabaseName> DBUSER=<DatabaseUser> DBPASSWORD=<DatabasePassword> /norestart /qn

Please remember; test and test again!

Posted on

Migrating GPOs to RES PowerFuse (Part 2)

In Part 1 we covered the basics of Group Policy Objects (GPOs), how they are implemented and the shortcomings of implementing Policy objects as User Registry Policies within RES PowerFuse. In our quest to work out how to migrate existing GPOs in to RES PowerFuse we’ll take a deeper dive in to how GPOs are stored and how we can get the existing settings out and allow us to import them into RES PowerFuse.

GPOs are stored within the SYSVOL share on Domain Controllers within the Active Directory infrastructure. The following information is from Group Policy Storage page from Microsoft.com.

Group Policy objects also store Group Policy information in a folder structure called the Group Policy template that is located in the System Volume folder of domain controllers (Sysvol) in the \Policies sub-folder. The Group Policy template is the container where Security Settings, Administrative Template-based policy settings, applications available for Software Installation, and script files are stored.

When you modify a GPO, the directory name given to the Group Policy template is the GUID of the GPO that you modified. For example, assume that you modified a GPO associated with a domain called Seattle. The resulting Group Policy template folder would be named as follows (the GUID is an example):

%systemroot%\sysvol\<SYSVOL>\Seattle.yourcompanyname.com\Policies\{47636445-af79-11d0-91fe-080036644603}

Registry.pol Files

All settings defined within the “Administrative Templates” section of a GPO are saved into the SYSVOL location indicated above as a REGISTRY.POL file either under the \User or \Machine subfolder depending on whether they are User-based or Machine-based policies. Here is the quote from the MS page:

The Administrative Templates snap-in extension of Group Policy saves information in the Group Policy template in Unicode files referred to as Registry.pol files; they are stored in the Group Policy template. These files contain the customized registry settings that you specify (by using the Group Policy Object Editor) to be applied to the Computer (HKEY_LOCAL_MACHINE) or User (HKEY_CURRENT_USER) portion of the registry.

Two Registry.pol files are created and stored in the Group Policy template, one for Computer Configuration, which is stored in the \Machine subdirectory, and one for User Configuration, which is stored in the \User subdirectory.

When you use the Administrative Templates extension of the Group Policy Object Editor to define customized registry settings, two Registry.pol files are created and stored in the Group Policy template. One Registry.pol file is for Computer Configuration-related registry settings and is stored in the \Machine sub-directory, and the other is for User Configuration settings and is stored in the \User sub-directory.

This means that all the User-based “Administrative Temples” settings within a GPO are stored within a single REGISTRY.POL file under the \User folder in the SYSVOL share. Therefore, if we can import the REGISTRY.POL file into RES PowerFuse we have a simple way of migrating an existing GPO, in its entirety. The custom extension information won’t be imported, e.g. software installation policies etc, but you’re probably using RES Wisdom for this anyway! There will be no need to manually import the ADM/ADMX templates and manually recreate all the individual settings for everything defined under the “Administrative Templates” section. Simples!

To be continued…

Posted on

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!

Posted on

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.

Posted on

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…

Posted on

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…

  1. 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..
  2. 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.
  3. 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!
  4. 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.
  5. 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.
  6. 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!
  7. 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.
  8. 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.
  9. 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.
  10. 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.

Virtual Engine Limited
450 Brook Drive, Green Park, Reading RG2 6UU