Here is the next version of our patch manager for Citrix XenApp 6 and XenApp 6.5. This version is free and requires only one registration and the request to announce annotations and error in the support-forum. Now I write first of all no new instructions. Also this Blog will grow with the versions.

Do you search for a version for XenApp or XenDesktop 7.x ? You find them >here<

I would like to thank all for the nice feedbacks to our patch manager for XenDesktop 7.6. Especially still once with my employee Martin von Hessert who had the idea for these tools

For visitors from Germany (special - Niedersachsen, Hannover und  Hamburg) : Wir, die Nick Informationstechnik GmbH, würden Sie gerne bei Ihren Migrationsprojekten, Performance Problemen, Reviews und Automatisierung zu XenApp 7.6 und App-V 5 unterstützen. Wir freuen uns auf Ihre Anfrage! Kontaktformular Info[at]nick-it.de

Image 1 : Screenshot with Japanese Citrix hotfixes

Diesmal geht es nicht um Software-Virtualisierung, sondern um Storage-Virtualisierung mit dem Hersteller Atlantis und der USX Appliance. Diese gibt es sowohl als Hardware, als auch als Software Lösung. Es geht hier nicht um einen Test bis ins letzte Detail der Appliance.

Die in den USA sehr erfolgreich Atlantis Computing, Inc. ist als Storage Hersteller neu am deutschen Markt. Vor kurzem wurde eine Niederlassung in München gegründet. Die Produkte versprechen die Storage Landschaft radikal zu verändern. Das mit Software-definierten Speicherplattform (Software-defined Storage). Unter Einbeziehung von Arbeitsspeicher und SSD Kapazitäten. Der Hersteller verspricht, mit der Atlantis USX eine bessere Leistung als mit den schnellsten „All-Flash-Array“ Systemen anderer Hersteller. Und das zu einem günstigeren Preis für den Endkunden.

App-V ist mit dem MDOP (dem Microsoft Desktop Optimization Pack) vor kurzem als Download im Microsoft Action Pack aufgetaucht. Eine Tatsache, die mich sehr gefreut hat. Wir sind selber bei sehr vielen Kunden mit App-V 5 Projekten aktiv und haben extrem viel Erfahrung. Nur hatten wir bis zu diesem Zeitpunkt seit ca. einem Jahr keine Möglichkeit mehr, selber noch an die Produkte zu kommen.
Ein Grund, etwas weiter auszuholen und etwas dazu zu schreiben.

Im Laufe der Zeit haben sich einige Skripte, meist zu Testzwecken angesammelt, die aber durchaus nützlich sein können. An dieser Stelle eine veröffentlichung meiner Snipets. Dieser Beitrag kann später noch ergänzt werden.

Vor einiger Zeit hatte ich das Problem, dass ich gerne Einzelbackups aller Spiele von Uplay und Origin haben wollte. Also einige löschen und später, bei Bedarf wieder recovern. Dafür habe ich dann ein kurzes Powershell Skript geschrieben, dass in Verbindung mit Winrar genau das erledigt. Ein Recovery habe ich nie getestet. Jedoch das Backup.

Hier das Skript dazu. WinRar muss installiert sein. Besonders die Nutzung von Winrar zur Archivierung mit Powershell dürfte auch für viele andere Zwecke Interessant sein.

Ich plane dafür ein Tool zu Bauen. Also ein Backup und Recovery Tool für Origin, UPlay und Steam. Hätte daran jemand interesse?

Für die Systemüberwachung reicht es machmal nicht, die Serververfügbarkeit zu prüfen. Wir hatten vor kurzem das Problem, dass ein PVS Server aus Netzwertechnischen Gründen verfügbar und voll finktionsfähig war, aber leider dennoch keine Images gestreamt hat. Zur Überwachung mit SCOM ist ein kleiner Powershell Skript entstanden, dass die Verbindungen von einem Citrix PVS Server überpruft. 

Wenn wir 0 Verbindungen haben, ist etwas nicht OK und das Skript liefert "False" zurück. Im Folgenden das genannzte Skript.

Hier kommt das alte Problem mit der Zertifikatprüfung wieder hoch. Das Signierte Programm Prüft beim Start die Gültigkeit der Zertifikate. Hat der Server keine Internetverbindung, dann kommt des zu einem Stark verzögerten Start und zu der Fehlermeldung

Das Problem, den Zertifikatcheck im Browser abzuschalten ist, dass das eine riesige Sicherheitslücke in das System reißt. Alternativ können auch die Citrix Stammzertifikate exportiert und wieder importirt werden.

Ein Windows Installer-Patch (MSP-Datei) ist eine Paketdatei, ein die Updates für eine bestimmte Anwendung enthält und beschreibt, welche Versionen der Anwendung gepatcht werden kann. Der Vorteil eines MSPs ist, dass nur die Dateien enthalten sind, die sich zu einem MSI ändern. MSP werden für Minor Releases eingesetzt (i.d.R. kleine Updates). Ich selber habe ein Tool in der Hinterhand, dass  binäre Differenzen für extrem kleine Patches verteilen kann (wird denn demnächst veröffentlicht).

In dem Patch enthalten ist u.a. ein Productcode und ein Patchcode für die zu ändernde Anwendung. Passt der Productcode zu einer installierten Anwendung, kann gepatched werden. Es ist also praktisch, diesen Code schon vor einer Installation zu ermitteln, um eine Softwareverteilung zu optimieren. Im Folgenden werden zwei Lösungen mit Powershell gezeigt.

Wie bekommt man den Productcode heraus? Eine Variante ist die Installation auf Codeplex: MSI Powershell Module. Der Nachteil dieses Modules ist, dass dafür auch wieder ein MSI installiert werden muss. Dies beinhaltet wiederum Komponenten des Windows Installer XML. Also nichts, was einfach in ein Paket eingebunden werden kann.Das MSI Powershell Module ist im übrigen sehr gut und ich kann das sehr empfehlen für komplexere Dinge. Nach der Installation bekommt man beispielsweise so die Daten einer MSI Datei:

get-msicomponentinfo `
    | where { $_.Path -like 'C:\Program Files\*\Common7\IDE\devenv.exe'} `
    | get-msiproductinfo

Vor kurzen habe ich nach einer Möglichkeit, gesucht, den Productcode eines eines MSP auszulesen, ohne diesen Overhead. Das COM Object "WindowsInstaller.Installer" bietet diese Möglichkeit. Der Vorteil ist, dass diese Funktionen leicht bei Installationen eingesetzt werden können. Also zum Abgleich, ob ein Patch für ein System geeigent ist. Demnächst baue ich das genau so in unseren Citrix XenApp Patcher ein.

Auslesen des "Display Name" des Patches mit Powershell. Achtung, dieser ist nicht immer im MSP enthalten:

function Get-MSPDisplayName {
<# 
.SYNOPSIS 
    Get the Display Name from an Microsoft Installer Patch MSP
.DESCRIPTION 
    Get Display Name from an Microsoft Installer Patch MSP (Andreas Nick 2015)
.NOTES 
    $NULL for an error
.LINK
.RETURNVALUE
  [String] Display Name
.PARAMETER
  [IO.FileInfo] Path to the msp file
#>
function Get-MSPDisplayName {
	param (
		[IO.FileInfo] $patchnamepath
	)
	try {
		$wi = New-Object -com WindowsInstaller.Installer
		$mspdb = $wi.GetType().InvokeMember("OpenDatabase", "InvokeMethod", $Null, $wi, $($patchnamepath.FullName, 32))
		$su = $mspdb.GetType().InvokeMember("SummaryInformation", "GetProperty", $Null, $mspdb, $Null)
		[String] $displayName = $su.GetType().InvokeMember("Property", "GetProperty", $Null, $su, 6)
		return $displayName
	}
	catch {
		Write-Output $_.Exception.Message
		return $NULL
	}
}

Auslesen des Productcodes eines Microsoft Patches (MSP) mit Powershell:

<# 
.SYNOPSIS 
    Get the Product Code from an Microsoft Installer Patch MSP
.DESCRIPTION 
    Get a Product Code from an Microsoft Installer Patch MSP (Andreas Nick 2015)
.NOTES 
    $NULL for an error
.LINK
.RETURNVALUE
  [String] Product Code
.PARAMETER
  [IO.FileInfo] Path to the msp file
#>
function Get-MSPProductcode {
	param (
		[IO.FileInfo] $patchnamepath
	)
	try {
		$wi = New-Object -com WindowsInstaller.Installer
		$mspdb = $wi.GetType().InvokeMember("OpenDatabase", "InvokeMethod", $Null, $wi, $($patchnamepath.FullName, 32))
		$su = $mspdb.GetType().InvokeMember("SummaryInformation", "GetProperty", $Null, $mspdb, $Null)
		#$pc = $su.GetType().InvokeMember("PropertyCount", "GetProperty", $Null, $su, $Null)
		
		[String] $productcode = $su.GetType().InvokeMember("Property", "GetProperty", $Null, $su, 7)
		return $productcode
	}
	catch {
		Write-Output $_.Exception.Message
		return $NULL
	}
}

Auslesen des Patchcodes eines MSP Patches mit Powershell:

<# 
.SYNOPSIS 
    Get the Patch Code from an Microsoft Installer Patch MSP
.DESCRIPTION 
    Get a Patch Code from an Microsoft Installer Patch MSP (Andreas Nick 2015)
.NOTES 
    $NULL for an error
.LINK
.RETURNVALUE
  [String] Product Code
.PARAMETER
  [IO.FileInfo] Path to the msp file
#>
function Get-MSPPatchcode {
	param (
		[IO.FileInfo] $patchnamepath
		
	)
	try {
		$wi = New-Object -com WindowsInstaller.Installer
		$mspdb = $wi.GetType().InvokeMember("OpenDatabase", "InvokeMethod", $Null, $wi, $($patchnamepath.FullName, 32))
		$su = $mspdb.GetType().InvokeMember("SummaryInformation", "GetProperty", $Null, $mspdb, $Null)
		$pc = $su.GetType().InvokeMember("PropertyCount", "GetProperty", $Null, $su, $Null)
		#Write-Host $pc
		[String] $patchcode = $su.GetType().InvokeMember("Property", "GetProperty", $Null, $su, 9)
		return $patchcode
	}
	catch {
		Write-Output $_.Exception.Message
		return $NULL
	}
}

NITCtxPatcher a patchmanager for Citrix XenApp and XenDesktop 7.x

May 2017 The NITCtxPatchManager is back, after some changes from Citrix on the website. Finally we've made it this far. Version 1.1.2 is available. Now with support for XenApp/XenDesktop 7.7 and 7.6 SP3. You can now detect the superseded hotfixes with the report function.

Broken:( are you searching for a version for XenApp 6.x ? Go to this blog post >here<)

Searching for patches on the Citrix website is a lot of work. 10 sites with 10 patches on each site for XenDesktop 7.6 alone. Therefore I have decided to build a patching tool and patchmanager for Citrix XenApp and XenDesktop 7.x. We created this application to download all hotfixes and LIMITED hotfixes.
This is the first release with all features. This tool can save a lot of work. Maybe even a few days in the year for an administrator, making it a real timesaver. Eric from Xenappblog.com has written a nice contribution about this: Automate Citrix Hotfix Installation Together With Feature PacksAutomate Citrix Hotfix Installation Together With Feature Packs

Direct downlaod latest Version 1.3.0

Please also note our other tool for Citrix :AppBot, a Citrix Application Streaming (CAS or XenApp Streaming) to App-V 5 and MSI Converter:Appbot

wfica32.exe stürzt in einer XenApp Sitzung in Verbindung mit dem Citrix Receiver ab

Ich hatte vor einiger Zeit bei einem Kunden das Problem, dass bei einem Anwender nach dem Start einer Published Application die Sitzung mit dem Absturz von wfica32.exe beendet wurde.

Nach einiger Recherche stellte sich heraus, dass die installierten Drucker auf dem Client dafür verantwortlich waren, die nicht verbunden bzw. nicht gefunden werden konnten. Nach dem Löschen dieser Drucker auf dem Client trat der Fehler nicht mehr auf.