Environment Variables in App-V Dynamic Suite Composition

Bij veel klanten wordt al Dynamic Suite Composition toegepast om bijvoorbeeld meerdere applicaties aan een Oracle-client te koppelen. Daar is niks mis mee, alleen was ik afgelopen week wat tegengekomen wat mij toch opviel. Een applicatie (laten we het maar Applicatie A noemen) had Oracle-client versie 9i nodig, deze had ik standaard gesequenced en via het Microsoft DSC tool gekoppeld aan Applicatie A. Applicatie A had ik dus opgestart en hij gaf opeens een melding dat hij het bestand oraoledbpus.dll niet gevonden kon worden. Ik had daarna gelijk via de sequencer de Oracle-client maar even geopend voor upgrade en gekeken of dat bestand nou bestond. Het bestand kon ik gewoon vinden in de installatiefolder van Oracle-client, dus zat het ergens anders in. Via procmon had ik het nog even gemonitord, het viel me op dat hij zoekt in de root van de installatiemap en daarna in C:\Windows. Ik had voor de zekerheid nog even het Oracle-client osd geopend, daar zag ik wat "path" variables en die verwezen naar de goede map waar die dll in zat. Na wat gepuzzel had ik maar alle Environment Variables in de osd van
Applicatie A gekopieerd om te testen of dat werkte, en warempel dat werkte ook! Op een blog van Microsoft blijkt dit dus ook te zijn aangegeven als workaround..

Zie bericht onderaan het blog;
http://blogs.technet.com/b/virtualworld/archive/2007/11/27/dynamic-suite-composition-dsc.aspx

App-V sequences distribueren met SCCM 2007 R2.

Vandaag had ik samen met collega Matthieu Bongers even onderzocht hoe app-v sequences nou gedistribueerd konden worden met SCCM 2007 R2. Ik had alvast vm1 met server 2003 R2 SP2 en SCCM 2007 R2 (met SQL 2008) ingericht en een vm2 met Windows XP SP3. Hierbij had ik de SCCM client op vm2 geinstalleerd en via SCCM had ik de App-V client (versie 4.5 sp1) naar vm2 gedistribueerd. We hadden een aantal blogs erbij gepakt waarop werd uitgelegd hoe je dit kon aanpakken. Jammer genoeg konden we nergens teruglezen hoe de sequence ingesteld moest worden, bijv. het protocol waarmee de sequence wordt gestreamd of de lokatie van de sequence. Uiteindelijk hadden we in ieder geval de 2 vinkjes gezet (Site Database->Site->Site Settings->Client Agents->Advertised Programs Client Agent(dubbelklikken)->Allow virtual application package advertisement(aanvinken); Site Database->Site->Site Settings->Site Systems->ConfigMgr distribution point(dubbelklikken)->Virtual Applications->Enable virtual application streaming(aanvinken)). We hadden nog even zitten zoeken naar geschikte sequences, en uiteindelijk 2 packages succesvol aangemaakt als virtual package. Hierbij hebben we wel 2 verschillende opties geselecteerd voor de advertisement, namelijk bij de ene in het tabblad Distribution Point "Download content from distribution point and run locally" en bij de ander "Stream virtual application from distribution point".
Beide App-V sequences starten gewoon op (eerst wel via SCCM client installeren), zodra er geen connectie is met het netwerk kon je GEEN gebruik maken van de sequence die gestreamd is (indien de cache leeg is). Ook konden we zien dat beide OSD's werden aangepast (in de app-v client management console te zien) tijdens de installatie via SCCM, bij de gestreamde sequence werd het omgezet in http://[sccm server]:80/... en bij de lokale sequence file://[sccm cache]/..
De App-V sequences hoeven dus niet speciaal te worden aangepast, dus je kan gewoon bestaande sequences distribueren met SCCM 2007 R2.
In dit scenario is ook geen App-V Management of Streaming server gebruikt. Wel vonden we het vreemd dat bij het aanmaken van de virtual packages, er eerst een moet worden opgegeven waar de .xml bestand staat (van de App-V sequence) en daarna ook nog om het pad van de data source folder wordt gevraagd (hierbij wordt na het aanmaken alles gewist in deze folder dus pas op!). We hebben ook opgemerkt dat het .sft en .osd bestand worden aangepast na het aanmaken van de virtual package. Het .sft wordt hernoemd naar [packageid].sft en in het .osd wordt ook naar [packageid].sft verwezen.

VDI en App-V 4.6 RTM

Om met de deur in huis te vallen: App-V versie 4.6 brengt een nieuwe feature met zich mee welke van groot belang kan zijn op een (middel-)grote VDI omgeving. Of deze daadwerkelijk zo mooi uit de verf gaat komen als op dit moment door Microsoft wordt geadverteerd is nog even afwachten, maar dat gaan we bij een van mijn huidige projecten in de nabije toekomst uittesten.

De feature in kwestie is centralised client cache. Dit houdt in dat de App-V 4.6 client de mogelijkheid biedt om de client cache op een SAN storage te plaatsen, waarbij meerdere (virtual) desktops dezelfde cache kunnen aanspreken. Voor een VDI omgeving van 1000+ werkplekken heeft dit een behoorlijk significante impact. Gebruikers loggen bij de betreffende klant immers in op full clone virtual desktops, welke blijven bestaan een doorgegeven worden aan de volgende gebruiker nadat een gebruiker zich afmeldt. Op langere termijn wordt dus elke applicatie wel een keer gestart op elke client. Met als direct gevolg dat er op 1000 gecentraliseerde werkplekken in elke afzonderlijke werkplek alle 400 applicaties in cache gaan staan, wat per client op in totaal zo'n beetje 10-15GB aan schijfruimte neerkomt.

Mocht de nieuwe centralised cache feature van de App-V 4.6 client zo goed blijken te werken als Microsoft zelf adverteert, dan zou dit betekenen dat er voor de client cache zo'n beetje 1000 maal 10-15GB aan storage space terug te brengen is naar eenmaal 10-15GB centrale storage, wat een behoorlijk verschil in kosten met zich mee brengt.

Meer info over de App-V 4.6 client features:

http://blogs.technet.com/mdop/archive/2010/02/19/app-v-4-6-and-med-v-1-0-sp1-rc-are-here.aspx