Поделиться через


Pre-Caching auf einer “Persitent” Disk und dem Fehler 4C401F0C-800700B7

Hallo zusammen,

Gerade im PVS Umfeld kann man schnell auf die – eigendlich – gar nicht dumme Idee kommen den App-V Cache auf eine persitent Disk (D Drive) zu legen. Somit muss alles nur einmal “gechached” werden und nich bei jedem Boot geladen werden.

Allein das Ihr das hier lest zeigt mal dass die Idee sicher gut ist es aber nicht so funktioniert. Nehmen wir folgendes Scenario an:

App-V 5.0 SP2 / W2k8 R2 RDS / Citrix PVS 6.1 (als Beispiel, kann man auch durch App-V 5.0 SP2 HF4 / Windows Server 2012 R2 und Citrix PVS 7.1.1 ersetzen)

Der App-V Cache also PackageInstallroot ist auf E:\ Abgelegt (E:\Appvcache). Benutzer melden sich an bekommen Anwendungen usw. – alles gut.

Nun wird der Server neu gestartet.

Nach dem Neustart und der Anmeldung des ersten Benutzers wird vom App-V Client ein Konflikt festgestellt – da die Informationen vom Image (keine Anwendungen) und die vom Cache (viele Anwendungen) nicht zusammenpassen. Beim nächsten Sync bzw. Add wird ein fehler generiert und die Versions Ordner der Pakate auf dem “Persistent” Drive werden gelöscht.

(Das war es dann mit dem persisten Pre-Cache).

Folgender Fehler wird in der Powershell geloggt:

image

Im Eventlog sieht das dann so aus:

image

Also der erste Sync schlägt mit den Fehlern oben fehl. Ein zweiter Sync geht durch und es passt auch alles wieder da im Cache nun “Grüne Wiese” ist. Können wir die Ordner und Dateien nun neu erstellen.

Dieses Verhalten ist so gewollt. Unser Ansatz mit “non-persistent” Maschinen umzugehen kann im Performance Guide nachgelesen werden.

Dieser ist hier zu finden:

https://technet.microsoft.com/en-us/library/dn659478.aspx

Alternativ, kann man dafür sorgen dass das D Drive / E drive beim Maschinen start keine Daten außer den AppVCache Ordner enthält.

Oder man legt den Cache gleich wieder in Image und nutzt SCS und einen optionalen Mount beim System Start.

Schönen Gruß

 

Sebastian Gernert – Escalation Engineer App-V

Comments

  • Anonymous
    June 09, 2014
    Guten Tag Was ist mit dem "optionalen Mount beim System Start" gemeint? Was müsste ich hier machen?

  • Anonymous
    June 09, 2014
    Hallo Yves, in den Scenario wird SCS (Shared Content Store) verwendet, damit ist per se nicht viel auf der Platte bzw. wird auf die Platte gestreamed. In diesem Fall könnte man Anwendungen die besonders wichtig sind aber dennoch auf die Platte des RDSH laden. Man muss lediglich für das Paket das man voll laden möchte einen Mount-appvclienpackage PAKETName absetzen evtl. in einem Startup script oder durch einen Task. Wenn man keinen SCS verwendet kann man auch ein Get-appvclientpackage machen und dann den Mount für alle Pakete. Schönen Gruß Sebastian Gernert

  • Anonymous
    July 08, 2014
    The comment has been removed

  • Anonymous
    July 08, 2014
    Hallo Yves, das hängt davon ab ob man GlobalRefreshonLogon und / oder UserrefreshonLogon aktiviert hat. Get-appvclientpublishing Server zeigt was gesetzt ist. Ist beides auf True gibt es zwei Tasks die bei der Anmeldung laufen einmal für die Maschine und einmal für den Benutzer. Ich würde mir mal die Tasks in Scheduled Tasks ansehen ob diese einen Fehler haben bei der Ausführung. Ggf muss die execution policy aud remotsigned gesetzt werden. Schönen Gruß Sebastian  

  • Anonymous
    July 08, 2014
    The comment has been removed

  • Anonymous
    October 11, 2014
    Warum ist das oben beschriebene Verhalten eigentlich so gewollt? Unter 4.6 funktionierte das doch sehr gut. :-)

  • Anonymous
    October 12, 2014
    The comment has been removed