Instant File Type Associations in RES PowerFuse explained - Part 1

What are File Types and Associations
In a Windows environment, different types of documents and files are identified by three-character file types. Common examples include .doc, .xls, .pdf, .bat and .vbs.

A file type association links a specific file type to a specific piece of software that is installed on the Windows device. If Microsoft Word is installed on the Windows device, then .doc is associated with Microsoft Word. When you double click on a .doc document, Microsoft Word starts up automatically and opens your document. If you have installed Open Office instead of Microsoft Word, then .doc is associated with Open Office.

Default file type associations are created during the installation of an application. These file type associations are stored in HKLM\Software\Classes. Users can change their file type associations. User-specific associations are stored in HKCU\Software\Classes. During the Windows logon process, HKLM\Software\Classes and HKCU\Software\Classes are combined into one Classes Root (HKCR). Windows refers to the Classes Root to see which application should be started when a user double-clicks a document.

HKCR is a ‘merged’ view of HKCU\Software\Classes and HKLM\Software\Classes, where the HKCU takes precedence over HKLM.

The Problem with default file type associations
On Windows devices, users can control and change associations manually via the File menu option, provided they have administrator rights on the device. In most company-controlled Windows environments, most users aren’t administrators, and so users cannot control their file type associations. Therefore, IT staff needs to control users’ file type associations.

The problem with file type associations that are managed by IT staff, is that those file type associations are static, not dynamic. If two applications are installed to handle the same file type, the administrator can only link one application to the file type, and this link will apply in all situations. In most companies, file type associations need to change depending on the action or on the environment to which the user is logged on at a given moment. Furthermore, different file type associations may be needed for different user or groups of users.

Reasons to use RES PowerFuse to control file associations
With RES PowerFuse, you can control file types centrally and dynamically. File type associations can vary for different users and groups of users, but also for different locations, available applications, etc.

In RES PowerFuse, administrators can define file type associations directly on each managed application. You can associate the same file type with multiple applications, and set different priorities so that the file type is associated to the correct application for the user during logon.

On this basis, IT administrators can meet users’ expectation that the correct application will start when they open a document.

If your Windows environment is already managed by RES PowerFuse, but no Instant File Associations are configured in the RES PowerFuse Management Console, your users will be using the default Windows file type associations. In this case, the applications that are started when users double-click documents are not managed by RES PowerFuse, without the benefit of RES PowerFuse features such as PowerLaunch, Instant Mail, Instant Datasources, publishing, license metering and security are bypassed.

How to configure Instant File Type Associations
From RES PowerFuse 2008 Service Release 5, sets of default file type associations (that were created when an application was installed) can be imported directly into an application in the RES PowerFuse Management Console. After the import, some finetuning may be needed as to when which file type association should be used.

For detailed information about configuring file type associations, you can press F1 to open the Help in the RES PowerFuse Management Console.

Configuring RES PowerFuse App-V integration for SCCM

The latest versions of both App-V and System Center Configuration Manager (SCCM) can work together to deliver virtual applications to the user. Some minor changes needed to be made to RES PowerFuse to support the executable (VApplauncher.exe) used by this new method.

This blog describes the way to configure RES PowerFuse to handle App-V applications distributed by SCCM.

Create a Software Distribution Package
In the SCCM console, create a new software distribution package by going to Site Database > Computer Management > Software Distribution > Packages.
Right-click on Packages and choose New > Virtual Application Package

Browse for the App-V XML file belonging to the application you’re adding.

Click [Next >]. Add information as needed and click [Next >].

Fill in the DataSource (distribution share), for example \\RESQA-SCCM\DataSource\Excel2003.

N.B. Be careful to type a new subfolder to the share otherwise all other applications in that folder will be gone!!

Click [Next >] and change the security as needed. Click [Next >] again. If all information shown is correct, hit [Next >] again. The actual import starts now. This will take some time, depending on the size of the package.

If all goes well you’ll see:

On the Data Source share, you’ll see the newly created folder (for example \\RESQA-SCCM\DataSource\Excel) containing the imported package.
After closing the wizard, you’ll see your newly created package under the packages node.

Publishing the package
Right-click this package and choose Distribute -> Software. This activates the “Distribute Package Wizard”. Click [Next >]. Tag the required server(s) and click [Next >]. Keep the setting “Advertise” on “Yes” and hit [Next >] and [Next >] again. In the next screen you can select the clients (think “Wisdom Agents”) to which this package will be distributed. This is done by choosing a collection (think “Wisdom Team”). Browse to the one you need (for example “All Desktops and Servers” ) and select it.


Click [OK] and [Next >]. Type in the name you want the distribution to have. Click [Next >] three times.

In this screen you can choose to “Assign” the application.

Assign means “mandatory” or “push”. Not assigning will make it “pull”. Since RES PowerFuse cannot force SCCM to distribute, PowerFuse needs that application to be available. So, it has to be “Yes, assign the virtual application”. Click [Next >] and finish the wizard.

This ends the SCCM part.

Creating the application in RES PowerFuse
Open the RES PowerFuse Management Console and check the settings for the “SoftGrid Integration” under the “RES PowerFuse Setup” node. Make sure the settings are exactly as shown here.

Go to “Application Management”. Select the menu node the application needs to be added to and hit the “Add Application” button. Click the [Next >] button and browse to the data source share (e.g. \\resqa-sccm.resqa.res.nl\DataSource\Excel). Select the OSD file and click [OK].
Walk through the wizard and select the settings you need and hit [Finish].

In the “Edit application” window select the “Settings” tab under “Properties”. Check the “Hide application if executable was not found” setting.

The combination of the executable on the “Command line” and the “Hide application…” setting tells the workspace manager to hide the application from the start menu until SCCM has distributed the application.

As soon as the application is available and the menu is refreshed the application will become available.

Shell Folder handling in a RES PowerFuse session

Shell Folder handling in a RES PowerFuse session

Introduction
The way in which users’s Desktop, Start menu and Quick Launch folders are handled has been redesigned in RES PowerFuse 2008 SR5.

Users’ Desktop, Start menu and Quick Launch folders require careful handling by RES PowerFuse in sessions using the Windows shell. RES PowerFuse must take into account that these folders can contain items that were created prior to the RES PowerFuse session, and which should not be made visible in the RES PowerFuse session.

Before SR5, RES PowerFuse copied such items to special folders when the session started, and when the session logged off this action was reversed. However, this method had some drawbacks.

This article explains the old design, the reasons why it had to change, and the new design introduced in RES PowerFuse 2008 SR5. It also explains what happens when you upgrade from a previous release to SR5.

The old design: how Shell folders were handled before RES PowerFuse 2008 SR5, and why this had to change

At the start of a RES PowerFuse session
When a RES PowerFuse session was started with the Windows shell, the RES PowerFuse Workspace Manager automatically set up the the \startmenu, \desktop and \quicklaunch folders by:

• creating 3 new folders with the extension .org (for example \startmenu.org).
• copying all existing items in the main folder to the matching .org folder.
• deleting the contents of the main folders.
• copying the contents of any existing .res folder to the main folder and then deleting the .res folders (only for desktop and quick launch items).
• creating 3 new folders with the extension .tmp.

The .tmp folders were used to prepare the contents of the folders based on all the user’s settings in RES PowerFuse. When this was ready, the contents of the .tmp folder was copied to the original folder, thus providing the user with a start menu, desktop and quick launch that contained all the items managed by RES PowerFuse.

Note: by “main folder” I mean the original \startmenu, \desktop or \quicklaunch folder.

At the end of a RES PowerFuse session
At logoff (or shutdown), the actions were reversed. RES PowerFuse also had to handle any items that the user placed on his \desktop in his \quicklaunch folder during the session, such as documents or shortcuts.
At the end of the session, the RES PowerFuse Workspace Manager:

• deleted the .tmp folders.
• created a folder with the extension .res for \desktop and \quicklaunch.
• copied all non-RES PowerFuse items (such as documents posted on the desktop by the User) to the .res folder.
• deleted the contents of the main folders.
• copied all items in the .org folders back to the main folder
• deleted the .org folders.

This method resulted in a correct environment for the user after the session was logged off correctly. New or managed desktop or quicklaunch items were not visible when the user logged on to the desktop without RES PowerFuse (because they were saved in the .res folder).

Issues with the old design
There were a number of flaws in the old approach to Shell folders:

• Copying took a long time if there were large files.
• Users could run out of diskquota during the copy operation.
• If a user preference was defined which placed files on the desktop, these files ended up in the .org folder and were therefore not visible in the session.
• If a session was not logged off properly, for example due to a system crash or a session reset, non-RES PowerFuse items were lost and the user’s folders left in an undefined state.
• The fact that items could be lost was a particular concern, but the performance impact of large files also needed to be solved.
  

The new design introduced in RES PowerFuse 2008 SR5, and why this is better

RES PowerFuse 2008 SR5 solves the issues by:

• moving files instead of copying them.
• improving the integration of the contents of the user’s main folders which exists outside
• the RES PowerFuse session with the RES PowerFuse session.
• improving the way in which information is recovered if a session was not logged off
  properly, so that no action is required from the user.
  

At the start of a RES PowerFuse session

When a RES PowerFuse session is started with the Windows shell, the RES PowerFuse Workspace Manager first checks for the existence of .mslinks folders for each of the 3 main folders.

A normal, correct log off does not leave any.mslinks folders behind, so if no .mslinks folders are found the Workspace Manager follows the regular procedure. This consists of:

• create the .mslinks folders (for example \desktop.mslinks)
• move the contents of the start menu folder to the startmenu.mslinks folder
• move shortcuts (.lnk files) that point to executables (.exe or .com) from the desktop and
  quick launch folders to the .mslinks folders. NB: Shortcuts that point to pwrgate.exe are
  not moved.
  

An incorrect logoff will leave .mslinks folders behind, so if it finds any .mslinks folders when the session starts the Workspace Manager executes a different procedure:

• instead of creating new .mslinks folders, only move the contents of the start menu folder to the startmenu.mslinks folder.
• move shortcuts (.lnk files) that point to executables (.exe or .com) from the desktop and quick launch folders to the .mslinks folders. NB: Shortcuts that point to pwrgate.exe are not moved.
• remove any existing shortcuts to pwrgate.exe, because these were left by a session that
  did not end properly.
• create .tmp folders from which to prepare the user’s Desktop, Start menu and Quick Launch in the same way as was done pre-SR5
• delete the above-mentioned .tmp folders.
  

At the end of a RES PowerFuse session

At the end of the session, the RES PowerFuse Workspace Manager:

• removes all shortcuts (.lnk files) that point to pwrgate.exe from the main folders
• moves the contents of the .mslinks folders back to the main folders
• deletes the .mslinks folders.
  

Why this is better

The new design is a major improvement, first of all because it moves files instead of copying them. This prevents the performance impact and the disk quota issues. Also, this method has a much better integration between non-RES PowerFuse items and RES PowerFuse items. For instance, if a user copies a document to the desktop, it will remains visible within and outside of the RES PowerFuse session.

Also, the way the .mslinks folder are handled ensures that the user can recover from a session which was not logged off properly. Any remaining RES PowerFuse shortcuts are removed automatically when a new RES PowerFuse session starts, and any content left in the .mslinks folder will be restored once the user logs on and off again. No files are ever lost.
What happens during an upgrade: the lost+found folders

Under normal conditions, no special actions are needed after installing RES PowerFuse 2008 SR5. New sessions will automatically use the new method for the shell folders.

However, in situations where .res folders from the ‘old’ method still exist and contain items, these are preserved in a manner that allows their recovery. If the RES PowerFuse Workspace Manager finds such folders when a session is started, then RES PowerFuse:

• creates a new folder called .lost+found
• moves the content of the .res folder to that folder
• deletes the .res folder.
  

If the old .res folder contained files that users wish to recover after the upgrade, then the files can be found in the lost+found folder and should be restored to the main folder.

This only applies only to the desktop and quick launch folders. The Start menu folder never has a .res folder.

Summary
The new method of handling the user’s shell folders is a major improvement, and solves quite a few long standing problems of data integrity and performance. The behavior of non-RES PowerFuse items is a little bit different, so please be aware that users may have a desktop or quicklaunch which differs slightly from previous RES PowerFuse versions.

thanks to Ton and Alex for the technical input and the review of the blog

Who's who in the registry

Someone showed me this neat little trick a while ago (can't remember who though. Sorry.) and I needed it today. I wanted to walk through the registry of a specific terminal server user. So I logged onto that terminal server too (using my own credentials) and opened up regedit... And then it hit me (again). I need to know the SID of the user to open his part of the registry.


To prevent having to get a SID ever again I implemented the earlier mentioned trick. I launched the RES PowerFuse console, went to Powerlaunch; User Registry and added a new String Value directly under HKEY_CURRENT_USER. I named the String "Username" and entered "%username%" as the value.



Now after a new logon the name of the user will be put in the registry and you can easily browse for the right user. So thanks for the tip.. Whoever you are ;-)

Focus

Focus, when you look this up on Wikipedia you will get as result

"Focus (computing), a component of the graphical user interface which is currently selected"

So focus is important for users, when they select an application that application should get focus and not some other application or object in their Workspace.

RES PowerFuse in Combination with RES Subscriber (or RES Workspace Extender) creates a cohesive environment between local installed applications and a central desktop. This gives the user the experience of a single desktop with all his applications. When the user selects one of those applications that application, local or remote, will get the focus.

Unfortunately because of the different ways applications handle focusing of their own windows (e.g. Word handles multiple documents totally different than Excel), in some situation the focus on (subscribed) applications did not work properly. Potentially frustrating users.

But we have great news, Friday 24th of April RES Software Release Service Release 5 of RES PowerFuse 2008 and Service Release 5 of RES PowerFuse Subscriber and Workspace Extender. Those new versions will solve a lot of those focus issues.

When you encounter focus issues at the moment with previous version of RES PowerFuse and RES PowerFuse subscriber, we advise you to test the new releases. You also can engage RES Support (if you have a valid SA) to help you solving the focus Issues.

Please let us know if your Application focus issues are solved!