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:

http://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 (7)

  1. Yves says:

    Guten Tag

    Was ist mit dem "optionalen Mount beim System Start" gemeint? Was müsste ich hier machen?

  2. S Gern says:

    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

  3. Yves says:

    Hallo

    Ich nochmals. Ich habe nun das HF 5 auf unserem Image installiert. Den SCS aktiviert und den Packagefolder auf %ProgramData%App-V wieder zurück verschoben. Die App-V 5 Applikationen sind immer einer Benutzergruppe zugeteilt.

    Problem nun ja ist, dass der erste User gar keine AppV Applikationen bekommt. Führe ich bei diesem Sync-AppVPublishingServer aus kommen diese automatisch.

    Es wird ja von einem Script geschrieben. Ist dieses pro User oder pro Maschine?

    Danke für die Unterstützung

  4. S Gern says:

    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  

  5. Yves says:

    Hallo Sebastian

    Danke für deine schnelle Antwort. Ich habe überall Global- und Userrefresh auf True gestellt. Die beiden Userlogon Aufgaben im Aufgabenplaner werden mit dem Fehler 0xfffffffe ausgegeben.

  6. Lars says:

    Warum ist das oben beschriebene Verhalten eigentlich so gewollt? Unter 4.6 funktionierte das doch sehr gut. 🙂

  7. S Gern says:

    Der Client muss davon ausgehen das Informationen die er hat korrekt sind und in App-V haben wir in Registry und Dateisystem Informationen die zusammen passen müssen – IM PVS Scenario mit Persistent Cache ist das nicht der Fall da nach dem Boot keine Registry Informationen da sind aber der Cache eben Voll ist, darum wird hier der Cache geleert und neu erstellt mit den Registry Informationen.

    Als Praktikabel hat sich erwiesen nach dem Boot des PVS Images einen Pre Cache anzustoßen – im Fall von der Persistent Platte müsste man den Cache natürlich erst selbst leeren.

    /Sebastian

Skip to main content