RES Workspace Manager kent met de Advanced Administration een perfecte integratie met Citrix XenApp. Applicaties die op silo’s staan, kunnen via RES Workspace Manager worden gepubliceerd en worden opgenomen in het startmenu van de gebruiker. Mocht een gebruiker een applicatie starten die niet op de server staat waar hij op dat moment op zit (en dus op een silo server draait), dan wordt automatisch de Citrix Receiver gestart en verbinding gemaakt met de applicatie. Dit werkt zoal met silo’s binnen dezelfde farm waar je gepubliceerde desktop onder valt, als silo’s in een andere farm (bv. een XenApp 5.0 farm onder Windows 2003 voor applicaties die niet werken op Windows 2k8 R2).

Maar wat als je om één of andere reden alleen de Composition & Personalization module hebt gekocht en je gebruikers toch één startmenu wil aanbieden waar de applicaties van de gepubliceerde desktop als die van de silo’s in staan? In dat geval moet je een truc uitvoeren met behulp van de Citrix Receiver. Het idee is dat RES Workspace Manager eerst het startmenu opbouwt met applicaties die op de hoofddesktop staat en dat daarna de Citrix Receiver het startmenu aanvult met applicaties die op de silo’s staan geïnstalleerd. Daarbij willen we uiteraard op de silo wel RES Workspace Manager inzetten voor het beheer. Tevens gaan we uit van de Citrix Reciever met ingebouwde Program Neighbourhood Agent.

Stap 1: Aanmaken silo applicaties in RES Workspace Manager

We willen de kracht van RES Workspace Manager gebruiken op de silo servers. De applicaties die we op de silo’s gaan starten, plaatsen we dan ook binnen RES WM, zodat we van alle mogelijkheden van RES WM gebruik kunnen blijven maken. In onderstaande stappenplan ga ik er dan ook vanuit dat RES Workspace Manager al op de silo servers is geïnstalleerd.

• Maak eerst een aparte Workspace aan voor de silo servers (node User Context – Workspace Containers) en plaats hier alle silo servers in.
• Maak daarna een aparte subfolder in het startmenu (Composition – Applications – New Menu). Hierin komen alle applicaties die op de silo servers staan (al dan niet in hun eigen subfolders). Hierdoor kunnen we makkelijker de “normale” applicaties van de silo applicaties scheiden.
• Voeg nu de applicaties van de silo’s servers toe. Het beste kun je dit doen vanaf een WM Management Console op de silo server waar de applicatie staat, omdat je dan makkelijker kunt browsen naar de applicaties bij het toevoegen ervan i.p.v. het hele pad met de hand in te voeren (wat de kans op fouten vergroot). Zorg ervoor dat je de applicatie in de net aangemaakt subfolder binnen het startmenu plaatst.
• Verander de volgende instellingen binnen de applicatie eigenschappen van de toegevoegde silo applicatie:
  • Onder Properties – Settings: Zet het vinkje bij ‘Hide application’. We verbergen de applicatie binnen het startmenu van de gebruiker. Dit voorkomt problemen als je per ongeluk de workspace niet goed in zou stellen.
  • Onder Access Control – Workspace Containers: Plaats de applicatie in de workspace van de silo servers. Dit zorgt ervoor dat RES WM de applicatie niet toevoegt aan het startmenu van de gebruikers. De applicatie staat immers niet op de servers waar de gebruikers hun desktop hebben.
• Maak een notitie van de applicatie id van de silo applicatie. Deze vind je binnen de applicatie eigenschappen op het tabblad Properties – General. Onthoud deze ID, want die hebben we nog nodig. Onthoud tevens de gebruikersgroep die je hebt gebruikt bij het aanmaken van de applicatie (tabblad Access Control – Identity)

Stap 2: Publiceren van de Silo applicatie

De volgende stap is het publiceren van de applicatie binnen Citrix. Doe dit op de manier zoals je dit normaal ook zou doen voor applicaties die je binnen de webinterface wil aanbieden of via de receiver. Het enige verschil is, dat je de applicatie niet rechtstreeks aanroept, maar dit via RES Workspace Manager laat lopen. Dit doe je door de volgende command line te gebruiken (uitgaande van een 32bit server): “c:\program files\res software\Workspace Manager\pwrgate” xx “%*”   Hierbij is xx het applicatie ID die de applicatie heeft gekregen binnen RES Workspace Manager. Bij een 64bit silo server gebruik je uiteraard “c:\program files (x86)”. Ook kun je %respfdir% gebruiken in het path (i.p.v. c:\program files\res software\workspace manager), dan gaat Citrix bij het starten automatisch naar de juiste folder

Alle overige instellingen maak je zoals je de applicatie ook normaal aan zou bieden. Dus vol een naam in voor het startmenu, selecteer de silo server onder ‘servers’, selecteer de juiste gebruikersgroep (die je ook gebruikt hebt binnen RES WM) en geef de applicatie het juiste icoon.

Stap 3: Starten van de Citrix Receiver

Nu moeten we nog zorgen dat de Citrix Receiver start en de applicaties van de silo server toevoegt aan het startmenu dat de gebruiker initieel krijgt van RES Workspace Manager. De Citrix Receiver moet op de server zijn geïnstalleerd inclusief de single sign-on module, zodat de gebruiker niet nog een keer moet inloggen als de Citrix Receiver start.

• Zorg ervoor dat de Reciever niet opstart als de gebruiker inlogt, voordat RES Workspace Manager klaar is. Verwijder daarom de Citrix Receiver uit de opstart folder van het startmenu van Windows Explorer en verwijder hem uit het register onder de RUN-keys.
• Voeg de instellingen van de Receiver toe aan het register. Ten tijde van schrijven werd de URL die de reciever gebruikt opgeslagen in HKCU\Software\Citrix\Program Neighborhood Agent onder de key Config URL. Deze kun je als registerinstelling opnemen in RES WM (Node Composition – Actions by Type – User Registry).
• Voeg nu als laatste de Citrix Receiver toe aan het startmenu van de gebruikers en plaats deze in de workspace van de servers die de gebruikers de desktop aanbieden. Zorg ervoor dat je onder de eigenschappen van de Citrix Receiver, aangeeft dat deze automatisch moet starten voor alle gebruikers. Je kunt er tevens voor kiezen dat de Citrix Reciever niet zichtbaar wordt gemaakt binnen het startmenu van de gebruikers.

Dat is alles. Als een gebruiker nu inlogt wordt het startmenu voor deze gebruiker eerst door RES Workspace Manager gevuld met applicaties. Volgens start RES WM de Citrix Receiver voor de gebruiker. Door Single Sign-On logt deze automatisch in op de Citrix Services Site en haalt daar de gepubliceerde applicaties op silo servers op voor de gebruiker. Deze worden dan toegevoegd aan het startmenu van de gebruiker. Als de gebruiker een silo applicatie start, handelt de Citrix Receiver deze af. Deze maakt verbinding met de silo server en start PowerGate op. Deze zal de eerste keer RES WM de instellingen laten maken voor de gebruiker (printers, netwerkshares, etc.) en vervolgens de silo applicatie starten.

Deze methode heeft een aantal minpunten. Hij is omslachtig en vergroot de beheerdruk voor de silo applicaties. De kans op (type)fouten bij het aanmaken en onderhouden van de applicatie is groot. Tevens moeten gebruikers bij het vernieuwen van de workspace, ook handmatig de Citrix Receiver opdracht geven om de applicaties te verversen. Bij het vernieuwen van de workspace zal RES WM namelijk alle niet bekende applicaties uit het startmenu verwijderen. De Citrix Receiver moet dan opdracht gegeven worden om de silo applicaties er weer aan toe te voegen.

Als je de mogelijkheid hebt om de Advanced Administration Module van RES Workspace Manager erbij te kopen, dan is mijn advies dat ook te doen. Deze module vereenvoudigd het beheer van silo applicaties aanzienlijk, omdat je op dat moment de silo applicatie op precies dezelfde manier beheerd als alle overige applicaties. De RES WM zorgt voor het publiceren binnen Citrix Xenapp en zorgt er tevens voor dat de receiver wordt gestart als een gebruiker een gepubliceerde applicatie aanklikt in zijn startmenu. Tevens is er de mogelijkheid om XenApp servers te groeperen. Mocht er een server bijkomen of afvallen, dan kun je dit regelen in een XenApp groep in Workspace Manager. Op het moment dat de groep veranderd, worden gelijk alle gepubliceerde applicaties aangepast. Dit scheelt een hoop tijd omdat je in een XenApp 4.5 / 5.0 omgeving niet alle applicaties met de hand hoeft na te lopen. Tevens zorgt het maken van groepen XenApp servers in WM voor een beter overzicht van de servers. Namen zeggen immers meer dan een servernaam met een volgnummer.