Tag: powerfuse

Posted on

RES Workspace Manager Run Once Per Computer, Per User

We all know that RES Workspace Manager stores the flag that determines if a Run Once task has completed for a given user in the \PWRMENU folder (at least by default). These files are named with the .ONCE file extension and given a (seemingly random) GUID, i.e. <SeeminglyRandomGUID>_task.once.

Unfortunately, there is no simple way of determining which .ONCE file relates to which task but that’s a post for another day! To force a task to rerun for a given user all we need to do is delete the relevant .ONCE file and the task will magically rerun. This avoids the necessity to check the “Clear History” checkbox and force it to run again for all users.

What about the Run Once Per User, Per Computer and Run Once Per Computer options? Logically they don’t live in the user’s \PWRMENU folder as they’re not a per user setting. So where do they live? After a discussion with RES Support it was discovered they live in the %RESPFDIR%\Data directory. Once you’ve determined which file relates to which task you can just delete it!

Here is an example of a Run Once Per Computer and Run Once Per Computer, Per User external tasks:

image

The 132DBDF_34930_105A_task.once file is a Per Computer external task. The 132DBDF_34981_1381_<domain>_<username>_task.once files are the Per Computer, Per User tasks for the LAB\Administrator and LAB\LOCAL01 user accounts.

Easy when you know how! Iain

Posted on

Migrating GPOs to RES Workspace Manager (Part 4)

Here is the story thus far. In Part 1 we discussed the issues with the RES Workspace Manager implementation of ADM/X templates and whether this is a good or a bad thing. The answer is, “it depends!” Part 2 detailed the locations of the existing Group Policy Objects (GPOs) and the REGISTRY.POL files. The last post (Part 3) we explored the REGISTRY.POL file format and the available options for extracting the resulting registry settings stored within.

Hail the release of the updated/new Virtual Engine Toolkit BETA 2 (registration required)! This update now incorporates the ability to create a .REG file from the GPO REGISTRY.POL file that we can import directly into RES Workspace Manager. We lose the ability to browse the ADM/ADMX structure hierarchy and view the explanations, but we do now have the ability to import existing GPOs without having to manually transition the settings!

Note: This is still a Beta product so please be careful and test, test and test again! If you have any issues please use the contact form on the website.

To migrate a GPO you will need to know where it is located and which REGISTRY.POL file to use and to add to the confusion all GPOs have a REGISTRY.POL file. To locate the correct REGISTRY.POL to import we  first need to find the GUID of the existing GPO:

  1. Open the Group Policy Management Console.
  2. Locate and edit the GPO we wish to migrate.
  3. Right click the <GPO NAME> in the left hand pane and select Properties from the resulting context menu.
  4. The GPO’s GUID will be displayed next the Unique Name entry (highlighted below).

image

Now we have the GPO’s GUID we can locate the correct REGISTRY.POL by performing the following:

  1. Launch the Virtual Engine Toolkit and select the “Convert POLs” tab.
  2. Click the ‘…’ button to browse for the REGISTRY.POL file (next to the .POL File Location text box).
  3. Open the ‘\\<DOMAIN FQDN>\SYSVOL\<DOMAIN FQDN>\Policies’ folder.
  4. Select the folder that matches the GPO GUID found earlier.
  5. Open the ‘User’ folder (this contains the User Configuration settings of the GPO).
  6. Select the ‘REGISTRY.POL’ file.
  7. Select an output location to save the .REG file in the ‘REG File Output Location’ text box.
  8. Give the file a name in the ‘REG Output Filename’ text box (the .REG extension will be added automagically).

It might look a little like this:

image

Note: It is possible to import the Machine (Computer Configuration container) REGISTRY.POL file and there are no checks enforced to stop you doing this. Within the REGISTRY.POL file is nothing to define whether the registry settings are User or Machine based, i.e. no HKLM or HKCU differentiators. The Virtual Engine Toolkit assumes that they’re User based and adds the HKCU text to the resulting .REG file manually.

Click the green “Toolkit” icon to create the .REG file. If all is well you should see something like this:

image

Now we can create a new Registry configuration object and import our .REG file into the RES Workspace Manager Management Console. If you browse the registry settings you should see that the resulting GPO settings have been migrated, in place exactly as they where configured in the GPO!

image

Posted on

Virtual Engine Toolkit BETA 2 Released

The Virtual Engine Toolkit BETA 2 (VET) has been released and can be downloaded from the web site here. This tool is free and will always be free although registration is required. At present there is currently no help available within the BETA 2 download so there will be a lot of blog posts to explain how all the features work to allow you to get you up to speed promptly.

So what does the Virtual Engine Toolkit do and what is its purpose?

The Virtual Engine Toolkit was originally developed (as the Building Block Spinner) to help automate the process of moving RES Workspace Manager Building Blocks between two domain environments. For example, you may have a development or test infrastructure that the RES Workspace Manager configurations are built/tested in and a live/production environment that is servicing your users. If our test and live databases are configured against the same Active Directory domain then they can typically be imported directly into the second environment. This scenario is covered in more detail in the Building Block Spinner (BETA 1) post.

This tool has since been extended to help with migrating and implementing Group Policy Objects within the RES Workspace Manager Management Console. The development won’t stop here so keep an eye out for future releases and future blog posts!

How can the Virtual Engine Toolkit help me?

The Virtual Engine Toolkit allows an administrator to specify different domain names for each of the two environments and select multiple Building Block files. When run it will create two sets of Building Blocks; one for the test environment and one for the live environment. Once the process is complete the Building Blocks can be loaded straight into the RES Workspace Manager Management Console. This saves you from having to perform a find and replace on each individual Building Block file which is both time consuming and error prone.

Existing Group Policy Objects (GPOs) can be converted in to .REG files for importation into RES Workspace Manager. This functionality mitigates the requirement of having to manually recreate existing GPOs within the RES Workspace Manager console.

Group Policy definition (both ADM and ADMX) files can be merged into a single file for more simple, logical management within RES Workspace Manager.

What next?

There are some additional use case scenarios for all you RES Workspace Manager consultants out there but we’ll save them for a future post. If you have any feedback, have found a bug or would like to see additional functionality put into the product then please Contact Us via the web site.

Posted on

Remote Assistance Troubleshooting

With any VDI technology that leverages Microsoft’s RDP (Quest’s vWorkspace and VMware’s View) deploying Microsoft’s Remote Assistance (RA) is a requirement for support as the typical remote console solutions do not work as originally intended. RES integrated the Remote Assistance technologies with the release of RES PowerFuse 2010 (Service Release 1?) and as a result we’re seeing more people attempting to integrate Remote Assistance with their VDI deployments. There are few things that can, and do go wrong.

RES Workspace Manager will configure the Remote Assistance registry settings on the local computer via the RES Workspace Manager agent without requiring Group Policy Objects or manual configuration of the registry. This includes ensuring that RA is enabled, the firewall ports are open and the RA Helper Active Directory accounts are populated with the specified groups. Once a Remote Assistance session is offered by the administrator via the RES Workspace Management console, this is handed off to the underlying infrastructure and RES Workspace Manager has nothing more to do with the remote session. If you’re having problems with Remote Assistance you might want to double check the following.

Local Helper Account

Ensure that the local HelpAssistant account is not disabled (on Windows XP). This account needs to be enabled on both the machine offering the Remote Assistance session and the target machine. If this is not enabled on the source computer, you may receive the “There is a problem with the invitation and it cannot be opened. To use Remote Assistance, the sender of this invitation will have to send you a new invitation.”

Remote Assistance HelpAssistant Error

Windows XP Help and Support Service

Double check that the “Help and Support” Service is enabled on Windows XP machines. There may be an old Group Policy Object somewhere that has disabled this and without this running, Remote Assistance is not going to be going anywhere! This service has been deprecated with Windows Vista and Windows 7.

DNS

The standard name resolution process is used to contact the destination computer when a Remote Assistance session is initialised. We have seen issues in VDI environments where the DNS records for desktops become stale. Here is a particular example:

  • VMware View is deployed with linked clone technology.
  • As VDI is booted it registers in DNS for the first time.
  • When the VM is recomposed it ends up with a new computer SID/MAC address but the same hostname.
  • The VDI attempts to update the DNS record but can’t because the SID associated with the DNS entry is incorrect.
  • If the RES PowerFuse console is located on a different subnet to the destination computer, Remote Assistance fails.

To ensure this isn’t a problem, make sure the computers are shutdown cleanly (and double-check their DNS entries are removed) before recomposing!

Posted on

Migrating GPOs to RES PowerFuse (Part 3)

So far in our ambition to migrate existing Group Policy Objects into RES PowerFuse we have detailed the shortcomings of doing so (Part 1) and discovered that all the registry settings for the User Container settings (“Administrative Templates” only) in a GPO are stored in the SYSVOL share as a REGISTRY.POL file (Part 2). Now we need to transpose the settings contained within the .POL file into a .REG file that is useable by RES PowerFuse.

Unfortunately, the .POL file format is a binary format that is not the same as the text-based .REG file format. There appears to be no easy way to view the contents of these files. The binary format is documented on the MSDN web site if you feel inclined to have a look. When we open a .POL file with notepad this is what we get:

Registry.pol

Therefore, before we can import this into RES PowerFuse we need to convert it to a text-based .REG file. After many hours scouring the internet, only a handful of solutions seem to be available.

There do appear to be some commercial registry utilities, i.e. Registry Workshop, that permit the loading/viewing of .POL files. The evaluation version of Registry Workshop does not allow exporting so it is unclear as to whether a .POL file can be exported as a .REG file that we can use with RES PowerFuse. In addition, we’re after a solution that doesn’t cost any money.

An alternative is the REGVIEW.EXE utility in the Windows 2003 Server Resource Kit. This does allow us to view the contents of the REGISTRY.POL file. Running the utility displays the contents of a .POL in text format like this:

regview_registry.pol

Unfortunately, this utility does not allow us to convert the REGISTRY.POL to a useful format, e.g. CSV. To utilise this tool we will have to redirect the output to a .TXT file, e.g. REGVIEW REGISTRY.POL > OUTPUT.TXT. Once in a plain text format we would then have to run another tool or script to convert the output to .REG. This is going to require some development time to implement.

To be continued…

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.

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