Tag Archives: RES

Adding a list of Authorised files to RES Workspace Manager Building Block

Windows_PowerShell_iconThis is just a quick article on how to search for exe’s recursively in a specific path and add them to an RES Workspace Manager building block to be imported back in.

I needed to do this recently as the customer in question had an application that lived on a network share and after 14+ years of development in this style, everyone was afraid to move it!

Steps to use this script:

  • Export an existing building block for the application you wish to authorize
  • Ensure the exported building block has at least one authorized file
  • Modify the $import and $exportbuildingblockpath
  • Modify the $exedirpath to be the path you wish to search recursively for exe’s.
$importBuildingBlockPath = 'H:\path\bb.xml'
$exportBuildingBlockPath = 'h:\path\export.xml'
 
$alreadyauth=@()
$ExeForAuth=@()
$exedirpath = "\\servername\Share\APPS"
 
 
Get-ChildItem -Recurse $dirpath | ?{!($_.psiscontainer) -and $_.Extension -like ".exe"}  | %{
    $ExeForAuth+=$_.fullname.ToLower()
}
 
 
[xml]$bb = Get-Content $importBuildingBlockPath
 
 
$bb.respowerfuse.buildingblock.application.appguard.authorizedfiles.authfile | %{
    $alreadyauth+=$_.authorizedfile.tolower()
}
 
 
Compare-Object $alreadyauth $ExeForAuth | ? {$_.SideIndicator -eq "=>"} | % {
    $newnode=$bb.respowerfuse.buildingblock.application.appguard.authorizedfiles.authfile[0].Clone()
    $newnode.authorizedfile=$_.inputobject.tostring()                                                                                     
    $newnode.description="Auto Appended item via script"                                                                                        
    $newnode.process="*"                                                                                          
    $newnode.learningmode="no"                                                                                               
    $newnode.enabled="yes"   
    $bb.respowerfuse.buildingblock.application.appguard.authorizedfiles.AppendChild($newnode)
}
 
$bb.save($exportBuildingBlockPath)

Citrix XenApp Mobility pack & RES Workspace Manager, lets fix those issues!

Late last year Citrix announced the availability of the XenApp 6.5 mobility pack. This mobility pack allows more native gestures to tablet users within their desktop session. Having testing it first hand, its really, really cool, but has a few issues to be aware of.

Firstly, it tends to enumerate hidden drives like c: or whichever drives you hide with Group policy, Kees Baggerman blogged about this issue a number of weeks ago:





and to confirm, there is definitely a private hotfix available for this. My own call reference with Citrix was SR60726532 if you wish to log a call yourself and receive the hotfix, you can quote this number.

The hotfix itself is just a binary replacement for the touchoptimizedDesktop.exe file in c:program files (x86)citrixsystem32.

Secondly, the Mobility pack’s start menu will enumerate both the local start menu and the users controlled start menu via RES Workspace Manager.


*red applications shouldn’t be visible



This presents a show stopper as the user is able to launch local applications they are not assigned without the security rules assigned. I logged this with both Citrix and RES. Citrix politely told me to PFO and RES agreed to log a feature request to add support.

If like me, you’d prefer a workaround while RES work their magic, Follow the below steps:

modify the permissions to the default start menu (c:programdatamicrosoftwindowsstart menu):





Modify the ACL’s on the Programs folder as follows, ensuring to remove the users group and everyone group from the acl:




After doing so, the users start menu inside of the Mobility pack, should be correctly populated:




And that should be it, your fondleslab users should now be able to experience the XenApp mobility pack in all its glory!

Replacing Windows Devices and Printers with RES Workspace Manager PowerPrint

This post is with thanks to @patrickdamen for the great idea of using a building block and @antonvanpelt for taking time from his busy weekend to test the fix, thanks gents!

So one of the great features of RES Workspace manager is PowerPrint. Powerprint, among other things allows for you to map printers and track preferences depending on your location. Powerprint is so powerful most administrators will remove users ability to use the native windows functionality in favour of this tool.

A downside to the latest incarnation of Workspace manager is that PowerPrint is quite hard to find for the users, instead of being on the root of the Windows xp style start menu, its not moved down two tiers into the Workspace manager start menu folder on the windows 7 style desktop.

With the attached building block, you can replace the native windows shortcut to “Devices and Printers” with a link instead to powerprint!

This building block works by hacking and taking over the Class ID for Devices and Printers and populating the class id with entries for PowerPrint. In order to use this building block, follow my previous blog post on how to hide the Windows “Devices and Printers” from the users.

The great thing about this hack, is it reuses native windows functionality the user will be used to and makes powerprint much easier to access by the user. That being said, I’m not sure RES will be enthusiastic with this hack, so use it at your own risk.

The (32 bit) addition to the name is a bit of a mystery at the moment, I’ve a call open with RES and I suspect its wow6432 related.

Download the building block here:

Enabling & Disabling RES WM / Powerfuse tracing with Powershell

citrxready-ressoftware-300x199Happy 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.

Update:

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 $pathRES.WorkspaceManager.Tracing.psm1

Command usage:

Enable-RESTracing

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

Enable-RESTracing -logfile c:temptrace.log

Enables tracing but overwrites the default log location of c:restrace.log to c:temptrace.log

Disable-RESTracing

Exactly what it says on the tin.

Download:

You can download this new module from here: