Nutzt man Methoden wie Citrix PVS oder MCS zur massenhaften Bereitstellung von virtuellen Maschinen sind einige Dinge zu beachten, wenn man Produkte wie AppSense oder Virenschutzprodukte einsetzten möchte. Solche Anwendungen sind häufig nicht für derartige Technologien ausgelegt. Da alle virtuellen Maschinen aus einem Masterimage entsprungen sind, hätten u.U. alle Maschinen die gleiche ID, was zu eigenartigen Effekten führen kann.

Dieses Skript für AppSense muss ausgeführt werden, bevor das aktualisierte Masterimage heruntergefahren und verteilt wird. Es löscht die "group id" und "machine id". Diese werden beim Starten des verteilten Images automatisch mit zufälligen Werten neu generiert und verhindert somit, dass sich alle virtuellen Maschinen mit der gleichen ID am AppSense Managementserver melden.

Die Updatefunktion des Provisioning Servers, welche mit Version 6 eingeführt wurde, macht es sehr einfach vDisks zu aktualisieren. Wie schnell das geht, möchte ich kurz im folgenden Artikel erläutern.

Wie in einem anderen Artikel bereits beschrieben, kann es bei der Bereitstellung von App-V Paketen auf provisionierten Servern zu Problemen (Appcrash) kommen, sofern man nicht die Funktion "Cache in Device RAM with Hard Disk Overflow" des Provisioning Servers nutzt oder den App-V Cache auf das persistentes Laufwerk auslagert.
Macht man letzteres muss sichergestellt sein, dass der App-v Cache nach jedem Reboot des Servers gelöscht wird, da es sonst zu Problemen beim Import der Pakete durch den App-V Client kommt.
http://blogs.msdn.com/b/sgern/archive/2014/05/26/10528435.aspx

Leider ist es nicht möglich, den App-V Cache (in unserem Fall "D:\App-V") so ohne weiteres bei jedem Neustart zu löschen, da dem SYSTEM Konto teilweise die entsprechenden Berechtigungen fehlen (Access denied).

Mit den Citrix Provisioning Services, XenDesktop 7.x und App-V 5.0 gibt es noch so einige Probleme. Hier wollen wir diese kurz zusammenfassen und eine Konfigurationshilfe bieten. Merkmal einer solchen Konfiguration ist der AppCrash der App-V Anwendung. Wenn das passiert, geht teiweise nichts mehr. Andere App-V 5 Anwendungen laufen noch. die gecrashte Anwendung machmal gar nicht mehr. Merkmal ist der Stopfehler 0xc0000005

Dies ist ein Problem, dass ab XenDesktop 7.1 gelöst sein soll. Jedoch setzen viele Kundenumgebungen noch auf XenApp 6.5 mit PVS und wollen nicht auf die neueren Produkte gehen.

Der Fix soll wohl die neue Option "Cache in Device RAM with Hard Disk Overflow" sein. CTX139627. Der Fehler tritt aber anscheinend auch mit den 7.1er Komponenten und der genannten Option auf. Nicht immer mit dem Fehlercode 0xc0000005. Der Workaround dazu findet sich untem im Text.