Archive for the ‘RES’ Category

Enabling & Disabling RES WM / Powerfuse tracing with Powershell

October 14, 2011 1 comment

Happy scripting Friday!

I wrote this script in batch donkeys ago and have been looking for a good excuse to rewrite it in PowerShell. Today was that day!

Here is two very simple powershell functions to enable and disable tracing for either WorkSpace Manager or Powerfuse on x86 or x64 platforms. Theres also tons of checks for funny business.


Thanks to Dennis Van Dam from RES Software for the tip that the users must be able to write to the tracefile, I’ve updated the scripts to include setting the ACL and I’ve also packaged the scripts as an importable module. You can download this new file below.

The script enables logging by default to c:\restrace.log and doesn’t delete the file after you disable tracing to ensure you send it to the experts.

The script will:

  • check for x64 or x86 architecture
  • Check if we’re running Workspace Manager or Powerfuse
  • create / delete the keys
  • Set the needed acl
  • Restart the service

At present this script can be run on remote systems using powershell remoting, if you want a native remote script without remoting dependencies just request it and I’ll start working on it. I had attempted something in visual studio a year or so ago and got sidetracked (bored).

Importing the module:

To import the module, simply run the below command (where $path is the path to the downloaded module).

import-module $path\RES.WorkspaceManager.Tracing.psm1

Command usage:


Enables tracing and saves the trace file to c:\restrace.log

Enable-RESTracing -logfile c:\temp\trace.log

Enables tracing but overwrites the default log location of c:\restrace.log to c:\temp\trace.log


Exactly what it says on the tin.


You can download this new module from here:

Powershell Script to add all applications to a RES Workspace Container.

September 20, 2011 Leave a comment

As Part of a recent Proof of concept, I needed to move all of my applications from one workspace to another. With 50 + applications in just the proof of concept environment, the idea of opening each and modifying them individually did not excite me.

Upon starting my investigation, I found an interesting article by the PepperCrew’s @IngmarVerheij where he exported all building blocks, then used a find and replace command to add the workspace to the application, then added all building blocks back in again.

This approach worked great for his implementation, but I wanted to further automate my process while giving me the ability to amend a workspace without removing any currently configured workspaces.

My search continued to the following article on the RESGURU Blog, Where the RESGURU has kindly documented the usage of Powertech to automate (Certain) commands in the powerfuse / Workspace manager world. Sadly as they document, exporting from the database is not currently supported, but there was a glimmer of hope, they do support importing building blocks… result!

So the first task is to create your workspace and add one application to it, in my case I used notepad:

Next step is to export all applications to building blocks, this can be done easily by simply right clicking start icon and choosing building blocks > create…

Choose the directory you wish to work from (I Chose c:\temp) and click ok, I’ll later refer to this directory as your “scratch directory”.

Step three is to find the GUID of the workspace you wish to add all your applications to. Of the building blocks you’ve exported, find the application you added to the workspace. The workspaceGUID can be found as below, take a copy of this value for later:

Now that you have all the building blocks and the guid, the fun can begin!

Below you will find the automated script to add a workspace to each xml file, then load them back into workspace manager using the powertech.exe command line interface. Below is a quick screen shot of how it looks:

Although I’ve written this for Applications, this could just as easily work for printers, user registry, anything so long as you ammend the XML path correctly. If you do have a requirement for other components or building blocks, drop me a commend and I’ll see what I can do.

Two Values will need to amended for this script to work in your environment, I’ve highlighted them bold in the script

  • The workspace GUID
  • the scratch directory

foreach ($process in (gwmi win32_process | where {$ -eq "pwrtech.exe"})){
    $owner = ($process.getowner()).user
    if ($owner -eq "$env:username") {
        Write-warning "pwrtech.exe is currently running in your session and can cause issues, close it now, I'll wait 20 seconds."
        start-sleep 20
    }#end if
}#end for

$blocks = get-childitem $scratchdirectory
foreach ($block in $blocks) {
 Write-Progress -activity "Adding Workspace to Applications and importing the building blocks:" -status "Currently working on: $($  ($i of $($blocks.length))" -PercentComplete (($i / $blocks.length) * 100)

   [xml]$XMLBlock = get-content $block.fullname

    if (!($XMLBlock.respowerfuse.buildingblock.application.workspacecontrol)){
        #did not find a reference to Workspace Control,
        #write-host "Adding Workspacecontrol and Workspace element to $block"
        $workspacecontrolelement = $XMLBlock.CreateElement("workspacecontrol")

        #create individual workspace entry
        $WorkspaceElement = $XMLBlock.CreateElement("workspace")

        #append both elements
        $workspacecontrolelement.appendchild($WorkspaceElement) | out-null

        #append elements to xml
        $XMLBlock.respowerfuse.buildingblock.application.appendchild($workspacecontrolelement)  | out-null

        #saving XML file:

        #committing to database
        start-process "C:\Program Files (x86)\RES Software\Workspace Manager\pwrtech.exe" -wait -argumentlist "/add /overwrite ""$($block.fullname)"""
    }#end IF
        #Found a reference of workspace control, checking if our building block already contains the workspace we wish to add:
        if ($XMLBlock.respowerfuse.buildingblock.application.workspacecontrol.workspace -notcontains $WorkspaceGUID){
            #create a new workspace element to add to a current workspace control element
            #write-host "appending workspace in $block"
            $WorkspaceElement = $XMLBlock.CreateElement("workspace")
            $XMLBlock.respowerfuse.buildingblock.application.workspacecontrol.appendchild($WorkspaceElement) | out-null
            #saving XML file:

            #committing to database
            start-process "C:\Program Files (x86)\RES Software\Workspace Manager\pwrtech.exe" -wait -argumentlist "/add /overwrite ""$($block.fullname)"""        
         }#end If
        Else {
            Write-warning "$block contains this workspace container already, skipping."
        }#end else
    }#end Else

}#end for

App-V applications hang for 30 seconds on a CMD box before opening

January 24, 2009 Leave a comment

In our powerfuse environment we came across this problem recently.

When we would try to launch an App-V application the following window would open and remain open for 30 + seconds before finally opening the application:


The problem we discovered was to do with file type associations inside of the RES session, App-V by default will try to associate it’s file type associations for the application being sequenced and store them in the .osd file. The problem was that PowerFuse also controls file associations and this became an issue! PowerFuse has to be associated with the app and not vice versa.

I recommend you specify the file type associations inside of powerfuse and remove the associations inside of the App-V package. To remove the associations, open the .osd file and remove anything between the <FILEEXTENSIONLIST>  </FILEEXTENSION>:

After the link is an example.

Read more…

Categories: App-V, Microsoft, PowerFuse, RES Tags: ,

Get every new post delivered to your Inbox.

Join 2,057 other followers