Monthly Archives: October 2011

Lotus Notes in SBC & VDI, surviving the pitfalls of an aging client.

Should all this be necessary? definitely not, but if you plan right you’ll be better prepared for failure.

Note: The Following post has been updated to include the latest fix information for running Lotus Notes 8.5.3 Feature Pack 2.

To start, I think I should open by saying I’m not an IBM software fan, in fact I’m the furthest thing from an IBM software fan. I feel they write unnecessarily complicated, Java heavy and buggy applications. They completely miss the point of the MSI standard and their application architecture is a mesh of static files, misleading registry keys all rolled into what I consider a really ugly eclipse platform.

Finding accurate information on how to install Lotus Notes in an SBC / VDI environment including all fixes and improvements can be from difficult to impossible, so below you will find a roll up of the considerations, caveat’s and some silly hang ups to deploying Lotus Notes in the above environments.

I’m not a Notes expert, I’m just the poor idiot that’s been forced to support it for the last five years. I don’t intend to update this post frequently, consider this my knowledge dump as I move away from a Lotus Notes environment.

So to begin, some fun Lotus Notes facts!

  • Windows Remote Desktop Services isn’t supported, at all.
  • XenApp 6.5 is only supported on Notes 8.5.3 Fix Pack 1.
  • XenApp 6 is only supported in 8.5.3.
  • XenDesktop isn’t supported, so by extension VMware View shouldn’t be either.*

*I think it’s hilarious they don’t support desktops if a hypervisor is involved.

Update: A new up to date list of supported configurations has been added by IBM here, it seems a bit of work has been done.

  • XenApp is supported.
  • Raw Terminal Services / Remote Desktop Services is still not supported. (Ridiculous)
  • is XenDesktop supported? Good Question… the jury is out it seems. (dead link)
  • No love for Micrsoft VDI, or VMware view sadly.

For more specifics on earlier clients, check here:

So now let’s get right to it. Below I’ve broken this post into categories to base your decisions on. Even if you veer off course and use a network drive, there is still useful information to be had in optimising and pruning.

Continue reading

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:

Importing XenApp 6 administrators from an older farm using Powershell.

Just a quick post, when moving from XenApp 5 to 6 the recreation of the farm can take some time, lots of new options, lots of new considerations. We have a large number of farm administrators internally and recreating that list / assigning permissions was something I avoided as long as I could due to the monotony of the task in question.

Fortunately, Powershell stepped in and made my life extremely easy, below is a quick list of tasks you need to do to quickly export and import farm administrators:

On the source server, ensure to install the powershell cmdlets for XenApp.

Run the following command and export to a shared directory:

get-xaadministrator | Export-Clixml servershareadmins.xml

Now on the target XenApp 6 server, run the following command:

import-clixml 'servershareadmins.xml' | new-xaadministrator
import-clixml 'servershareadmins.xml' | set-xaadministrator

And that’s it!

Well actually, its not, some permissions and values have changed from 5 to 6 so you still need to review the permissions (around applications and servers) , but the pre-creation of administrative accounts and any translated permissions will be immediately set.

Automating Microsoft App-V Lightweight Streaming Services with Powershell.

App-V Lightweight streaming services (LWS) is awesome. In particular, its a great utility for enterprises who wish to use App-V but don’t need the user management overhead that comes along with the full product.

For example, when using something brilliant like RES Workspace Manager, you can provision App-V applications, manage licensing requirements and restrict access to applications to pretty much any collection you wish. With utilities like this managing your workspaces the App-V database and management servers are just unnecessary add-ons.

With Lightweight streaming services, you get all the benefit of isolation, streaming and version control but without the additional infrastructure and management overhead. Simply host a network based application depot and point the lightweight streaming servers / clients to the share, Done.

But even with all these great benefits, the key difficulty with Lightweight streaming services is pre-caching the applications before a user needs them and keeping the application content up to date as new updates are added.

Having scripted mechanisms in Batch to perform this function and lost some hair in the process, I’m delighted to say PowerShell handles this job really well. Below find the powershell functions I’ve written to handle the four core tasks and the script I use to tie them all together. I run this script as a startup script after our XenApp servers scheduled restarts, this script will:

  • delete local packages that no longer exist on the content share.
  • Add new packages on the content share.
  • Perform a version check, deleting a local older copy if found.

Note: These scripts assume best practices of the applications being stored in servernamecontentshareappnameapp files.
Add an appv package to the local machine:
Useage:  add-appvpackage -path “servercontentshare” -packagename “packagename”

function add-appvpackage{
    param(
        [string]$path,
        [string]$packagename)
       if (test-path $path$packagename$packagename`_manifest.xml){
            pushd $path
            start-process -wait sftmime.exe -argumentlist "add package:$packagename /manifest .$packagename$packagename`_manifest.xml /global"
            start-process -wait sftmime.exe  -argumentlist "load package:$packagename"
            popd
          }#end path if
       Else{
       write-warning "problem with path $path$packagename$packagename`_manifest.xml"}
}#end function

Remove an appv package to the local machine:
Useage: remove-appvpackage -packagename “packagename”


function remove-appvpackage{
    param(
        [string]$packagename)
    start-process -wait sftmime.exe -argumentlist "delete package:$packagename /global"
}

Retrieve a list of appv packages on the local machine:
Useage: get-appvlocalpackages

function get-appvlocalPackages{
    $localpackageswmi = get-wmiobject -class Package -namespace rootmicrosoftappvirtclient
    foreach ($package in $localpackageswmi) {
        $packagedetails = New-Object PSObject -Property @{
                Name=$package.Name
                Version=$package.version
                VersionGuid="`{$($package.versionguid)`}"
            }#end object
        $packages+=@($packagedetails)
    }#end for
    return $packages
}#end function

Retrieve a list of appv packages on the content share:
Useage: get-appvremotepackages

function get-appvremotepackages{
    param(
        [string]$remotedir="computernamecontentshare")

    foreach ($package in get-childitem $remotedir){
        [xml]$manifest = get-content $remotedir$package${package}_manifest.xml
        $packagedetails = New-Object PSObject -Property @{
            Name=$manifest.package.Name
            Version=$manifest.package.version
            VersionGuid=$manifest.package.versionguid
        }#end object
        $packages+=@($packagedetails)
    }#end for
    Return $packages
}#End Function

Gluing it all together into a maintenance script:

#getting package arrays
$locallist=get-appvlocalpackages | sort name
$remotelist=get-appvremotepackages | sort name

#sort the differences to highlight deletes first.
foreach ($difference in COMPARE-OBJECT -referenceobject $locallist -differenceobject $remotelist -property name,version | sort sideindicator){
    if ($difference.sideindicator -eq "<="){
        if ($difference.name -ne $null){
            write-host "removing $($difference.name)"
            remove-appvpackage -packagename $difference.name}
    }#end if
    Else {
        if ($difference.name -ne $null){
            "adding $($difference.name)"
             add-appvpackage -path $remotedir -packagename $difference.name}   
        }#end else
}#end for

To grab a copy of the whole script, follow the jump below:

Continue reading