Vandaag was de eerste dag van TechEd Europ 2012. Heb me de hele dag vermaakt bij de SCCM 2012 sessie.
Halverwege kwam de vraag waarom je App-V niet zou integreren in SCCM op het moment dat je de SCCM infrastructuur toch al hebt liggen. Er zijn namelijk genoeg redenen om een integratie met SCCM te doen in plaats van een volledige App-V omgeving ernaast te bouwen.
Integratie met SCCM biedt de volgende voordelen:
Geen dubbel beheer via twee consoles. Alles integreert naar 1 console. Je hoeft het beheer gedeelte van App-V niet meer te installeren.
Je kunt de bestaande infrastructuur van SCCM gebruiken voor het leveren van de applicaties. Deze is in grote omgevingen schaalbaarder.Applicaties worden via de Distributies Points van SCCM verspreidt.
De applicaties kunnen altijd offline gebruikt worden. Je bent niet afhankelijk van de backend nadat de applicatie is uitgerold naar de werkplek/gebruiker.
Dus welke voordelen kan het hebben van een losse SCCM omgeving nog hebben? Tijdens de discussie op Twitter was maar één reden te bedenken, namelijk het actief monitoren van de licenties. Dit is niet mogelijk met SCCM.
Echter, dit punt is met een goed desktop management systeem op te lossen. RES Workspace Manager kan bijvoorbeeld de licenties actief monitoren en gebruikers blokkeren als het aantal concurrent licenties op zijn gebruikt (overigens is bij gebruik van RES WM en zonder SCCM aan te raden een App-V Light omgeving te bouwen).
Bij een klant kreeg ik na een aantal App-V pakketten ineens steeds vaker de melding ‘Het systeem kan het opgevraagde pad niet vinden’ (App-V cliet errorcode 4615186-07D0082C-00000003) bij het starten van een applicatie op de client. In de sequencer starte de applicatie altijd wel goed op, dus het probleem leek niet direct in het op te starten pad en applicatie executable te liggen.
In de logfile van App-V kwam deze melding ook terug (1). Iets daarboven stond een andere melding, namelijk ‘Beschadigd CP-bestand gedetecteerd’ (2). Het osguard.cp bestand bevat de informatie over het virtuele file-system. Als deze beschadigd raakt weet App-V niet meer welke bestanden zich waar in de virtuele laag bevinden. Dit zou dus wel het probleem kunnen zijn. Mogelijk dat bij het opslaan op het netwerk een probleem ontstond waardoor de inhoud van dit bestand niet goed wordt weggeschreven. De Guid (3) komen we later op terug. Een andere Sequencer VM biedt inderdaad de oplossing, maar ik wilde meer weten van wat er aan de hand was, omdat ik niet kon geloven dat alleen dat ene bestand beschadigd raakt door dit probleem. Tevens gebeurde het elke keer opnieuw als ik de applicatie opnieuw had gesequenced.
Na het wissen van alle user-cache bestanden van de App-V client opnieuw de applicatie gestart. Daar kwam iets vreemds uit. De applicatie SBI maakt de user-cache directory SPSS.V16-D1A1D5C9xxxxx aan. Dat is vreemd, aangezien dat een totaal andere (eerdere gesequencede en geteste) applicatie is. Dus wat is er aan de hand?
Na het openen van de App-V console van de App-V client werd al snel duidelijk wat er aan de hand is. Er zijn 2 applicaties met dezelfde package GUID. SPSS is als eerste in de cache geladen met het desbetreffende GUID. Alle gegevens (pakketgrootte, grootte in de cache, grootte voor starten) van de applicaties zijn gelijk, terwijl de SBI applicatie een stuk kleiner is kwa applicatie.
Dit verklaard ook gelijk de melding over het beschadigde CP-Bestand. In de OSD-file van de applicatie staat namelijk aangegeven hoe groot de virtuele omgeving hoort te zijn. Doordat de App-V applicatie de GUID al in de cache heeft staan, opent hij deze gecachede virtuele omgeving. Echter, de grootte van deze virtuele omgeving komt niet overeen met de grootte die in de OSD-file staat en daar geeft de client een waarschuwing op.
Een deepdive op het internet, via Google gezocht naar de oorzaak van mogelijke oorzaken van dubbele package-GUIDs, brengt naar boven dat dat kan worden veroorzaakt door het openen van de Sequencer direct na het installeren en voor het nemen van een snapshot. Dat had ik inderdaad gedaan, maar dat is de fout in dit geval niet. Het probleem ontstaat bij mij omdat ik de snapshot bij een werkende machine heb gemaakt! Stomme fout, maar was alweer een tijdje geleden dat ik sequences had gemaakt. Na het maken van een nieuwe snapshot met de machine uit, veranderd de package-GUID netjes bij elke reboot.
Na het herpackagen van SBI is inderdaad de package-GUID aangepast en zijn de gegevens bij het pakket ook aangepast. De App-V client ziet de applicatie nu daadwerkelijk als een nieuwe applicatie.
Dus een tip voor in de toekomst: Altijd een snapshot maken met de VM uit. Dat voorkomt veel problemen.
Halverwege kwam de vraag waarom je App-V niet zou integreren in SCCM op het moment dat je de SCCM infrastructuur toch al hebt liggen. Er zijn namelijk genoeg redenen om een integratie met SCCM te doen in plaats van een volledige App-V omgeving ernaast te bouwen. 
