Category: XenApp

HTML5 Video Redirection

I XenApp 7.12 släpptes en policy för HTML5 Video redirection. Policyn optimerar HTML5 multimedia till användare på XenApp och XenDesktop-servrarna. Som standard är den här inställningen avstängd, även fast det står att inställningen är påslagen i i beskrivningen av policyn. För att använda detta behöver även policyn ”Windows Media Redirection” vara aktiverat. Som standard är den inställningen påslagen.

HTML5 Video Redirection Policy

Efter man har satt inställningen i Citrix Farm Policys så kan man verifiera fuktionaliteten genom att gå in på Citrix testsida för HTML5 redirects. Det fungerar väldigt bra och i våra tester ser man i princip ingen skillnad mellan att kolla på en video lokalt versus i XenApp med policyn och JavaScriptet igång.

Tyvärr finns det en begränsning i att man behöver lägga in en JavaScript-fil på de hemsidor som skall köra HTML5-mediat för att det skall bli optimerat i Citrix. JavaScript-filen ligger under ”C:\Program Files\Citrix\HTML5 Video Redirection\” med namnet ”HdxVideo.min.js”. Om skriptet inte finns så kommer HTML5 mediat renderas på serversidan.

Vi på Xenit hoppas att inställningen snart börjar fungera utan implementationen av JavaScriptet.

 



Automatisera Citrix Scout

Om ni inte redan har uppgraderat till de senare versionerna av Citrix XenApp/XenDesktop och kan använda Citrix Call Home får man nöja sig med att använda Scout för er kontroll av Citrix-miljön. Ni kan dock använda detta lilla tips för att enkelt  få en regelbunden automatisk kontroll med några få enkla steg!

När Citrix Scout V2.20 släpptes lade de till stöd för CLI, det innebär att man kan köra Scout via kommandon i kommandotolken (cmd.exe). Poängen med det är att nu kan man skapa script som man sedan schemalägger och kör i ett önskat intervall. När man kör kommandona första gången får man en popup-ruta att fylla i sina MyCitrix uppgifter, när man gör det laddas en token ner så att du i fortsättningen inte behöver skriva in dina uppgifter varje gång den körs. Denna token är giltig i 6 månader, sedan måste man förnya den igen.
Jag gjorde enligt följande:

Instruktioner

1. Starta CMD.exe och navigera till din Scout-mapp (om du inte har scout kan du ladda ner den här och lägg den valfritt ställe på en Citrix XenApp/XenDesktop Controller)

2. Skriv sedan ”run.exe mode=cli” och tryck enter:


3. Om ni aldrig kört detta i CLI förut kommer denna rutan komma upp, det är den som laddar ner din token som är giltig i 6 månader:


Fyll i uppgifterna och tryck ”Get Key”. (om du inte redan har ett MyCitrix konto, tryck på länken) Efter det dyker det upp en liten text längst ner som säger ”Successful”:

 

Det var allt! Nu kan man enkelt göra en schemalagd uppgift (Task Scheduler) med denna *.bat-fil!

Efter detta kommer det att automatiskt skickas ett mejl till den mejladress som är kopplad till ditt MyCitrix-konto!

Notera!

Det finns dock ett par nackdelar som man bör känna till:
1. Man kan endast köra denna på en Citrix XenApp eller XenDesktop Controller och man måste göra en för varje Controller man har.
2. Den fungerar inte att köra ifrån VDAer

Vill du läsa mer om Scout tryck här!
Vill du läsa mer om Call Home tryck här!



XENAPP/XENDESKTOP 7.12 – Local Host Cache

Citrix har släppt Xenapp/XenDesktop 7.12 och åter introducerat en mycket efterfrågad funktion som tidigare funnits i XenApp 6.x versioner. Funktionen är local host cache (LHC) och tillåter användare att ansluta till publicerade applikationer, även om SQL-databasen är otillgänglig. Det sker genom att information från databasen cacheas ner lokalt på Delivery Controllers varannan minut.

Local Host Cache Architecture

Local Host Cache Architecture

Citrix-databasen håller reda på vilka applikationer som är publicerade på vilken server. I tidigare versioner av XenApp/XenDesktop 7.x har man fått använda sig av Connection Leasing som nu ersätts av LHC.

Med Connection Leasing kunde användare endast använda sig av resurser som de tidigare anslutit sig till om databasanslutningen var otillgänglig. Med LHC har de möjlighet att ansluta till samtliga resurser oavsett om de tidigare anslutning till dem.

Aktivera Local Host Cache

Funktionen LHC blir aktiverad vid en nyinstallation av XenApp 7.12. Utför man däremot en uppdatering till 7.12, från 7.11 eller tidigare förblir Connection Leasing aktiverat.

För att se nuvarande status på Local Host Cache och Connection Leasing, kör följande kommando på Delivery Controller.

För att aktivera LHC efter en uppgradering kör man nedan PowerShell kommando på Delivery Controller.

Ovan kommando laddar in Citrix-snapin och aktiverar LHC och inaktiverar Connection Leasing funktioner.

Källa: http://docs.citrix.com/



Citrix StoreFront 3.X – Varning för .NET 4.6.2!

n4emv4ar-dotnet-logo1-300x229-s-1
För inte så länge sedan kom en ny version av .NET som ersätter nuvarande versioner av .NET 4.6 och .NET 4.5 (närmare bestämt 4.6.1 och 4.5.2). Jag skulle vilja varna alla som driftar Citrix-miljöer från att installera denna nya version av .NET på era StoreFront-servrar som kör Windows Server 2008R2. De versioner av StoreFront som är drabbade är 3.0 eller högre, det vill säga 3.0, 3.5, 3.6 eller 3.7. Märk väl att denna varning ej gäller för Windows Server 2012(R2) eller Windows Server 2016.

Citrix har gått ut med en så kallad Fast Publish-notis som säger att om man installerar den senaste versionen av .NET (4.6.2) på sina StoreFront-servrar så slutar autentiseringen att fungera i både webbgränssnitt och legacy services-sidor (som t.ex. används av Legacy PNA) helt att fungera. Dessvärre finns det i dagsläget ingen lösning utan rekommendationen från Citrix sida är att man installerar de ”senaste” äldre versionerna av .NET – 4.6.1 och/eller 4.5.2.

Min rekommendation till er är att hålla ett extra öga på WSUS och Windows Update för att se till att några uppdateringar inte trycks ut den vägen. Jag har inte sett denna uppdatering tryckas ut den vägen ännu, utan det är manuell nedladdning som gäller, men det bör inte vara långt kvar då versionen som sådan ser ut att fungera bra generellt sett.

tl;dr Installera inte .NET 4.6.2 på en StoreFront-server som kör Windows Server 2008R2!

Det här inlägget blev inte så tekniskt utan snarare ett Public Service Announcement, AKA PSA! Hoppas att det hjälper er att undvika onödiga driftstopp!

Källor:
https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
http://support.citrix.com/article/CTX216204



XenApp och XenDesktop 7.11

Citrix har äntligen släppt den version av Citrix XenApp och XenDesktop som kommer supportera Windows Server 2016 från dag ett (även kallat zero-day support).

Som många redan känner till så blev det sedan i somras officiellt från Microsofts håll att Windows Server 2016 kommer bli släppt under årets upplaga av Microsoft Ignite som pågår just nu – så nu är hög tid att börja planera för labbmiljöer och produktionssättningar!

Tech Preview 5 har varit ute sedan april i år har jag hunnit testa en hel del i det nya operativsystemet och jag måste säga att det ser riktigt bra ut! Att vi Citrix-entusiaster nu kommer kunna leverera ett fleranvändarskrivbord med samma gränssnitt som Windows 10 är något som, i alla fall jag, sett fram emot att kunna göra sedan Windows 10 släpptes!

2016-09-27-16_55_20-windows-2016-tp5-persistent-desktop-viewer

Funktionsmässigt i XenApp och XenDesktop 7.11 så har det kommit flera intressanta nyheter, några av dem är:

  • Self-Service Password Reset (nu även för 7.X och inte endast 6.X)
  • Publicera annat än applikationer och skrivbord (t.ex. dokument, URLs och media)
  • Uppdateringar i Citrix Director (bland annat ny rapporteringsfunktion och bättre övervakning)
  • Förbättringar i de olika video codec’s som finns tillgängliga på VDAer
  • Publicering av Universal Windows Platform (UWP)-applikationer
  • Windows Server 2016 Hyper-V Discrete Device Assignment (DDA)

Som tidigare nämnt så är nu hela Citrix-sviten (XA/XD) supporterad och förberedd för Windows Server 2016. Det kommer bli riktigt spännande att se vad ni alla kommer att hitta på!



Oregelbunden loggning av inloggningar i Citrix Director

Här om dagen upptäckte vi att Citrix Director inte loggade/visade alla inloggningar i en kunds XenApp 7.6-miljö. Utav en miljö som består av ca 250 inloggningar per dag, kunde vi motsvarande se ungefär 40 stycken inloggningar mellan 07:00-09:00.

 

Vid närmare utredning så såg vi att registervärdet i ”HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” för nyckel ”Citrix UPM UserMsg” såg lite märkligt ut. Det första är att det ser ut som att värdet på ”Citrix UPM UserMsg” försöker gå mot en mapp, när den egentligen skall gå mot en .exe-fil. Värdet i ”HKLM\…\Run” för nyckel ”Citrix UPM UserMsg” skiljer sig mellan olika VDA-versioner.

Citrix UPM UserMsg

För att Director skall logga korrekta inloggningstider för samtliga användare så behöver man sätta inställningen Run These Programs At User Logon i en GPO med värdet:

”C:\Program Files\Citrix\User Profile Manager\UpmUserMsg.exe” wait

 

I VDA 7.7 och högre fungerade inte det utan behöver bytas ut till:

”C:\Program Files\Citrix\Virtual Desktop Agent\upmEvent.exe” wait

 

Detta kan vara unik för våra miljöer. Lösningen borde snarare vara att byta ut registervärdet.

 



Felmeddelande IcaTS_X64.msi vid avinstallation av VDA 7

En kund fick problem vid en avinstallation av Citrix Virtual Delivery Agent 7.9 (VDA 7.9) med felmeddelande

 

Vid närmare utredning så försökte vi att avinstallera IcaTS_X64.msi manuellt med MSIEXEC. Vi undersökte vilken GUID vi skulle behöva för att avinstallera detta manuellt och hittade ganska snart applikationen under ”HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\2638CDCB-F4B7-4889-B278-571427FD7664”.

Ica_tsx64 regiternyckel

Vi använde oss av MSIEXEC och körde kommandot nedan i en eleverad kommandotolk.

 

Vid manuell avinstallation av IcaTS_X64.msi fick vi ytterligare ett felmeddelande gällande rättigheter på registernyckeln ”HKLM\Software\wow6432node\Citrix\EUEM\LoggedEvents”. Vi gick till registernyckel ”HKLM\Software\wow6432node\Citrix\EUEM” och lade till min specifika användare och bockade för ”Replace all child object permissions with inheritable permissions from this object”

LoggedEvents rights

Efter att vi tagit över rättigheterna av registernyckeln ”HKLM\Software\wow6432node\Citrix\EUEM\LoggedEvents” avinstallerade vi IcaTS_X64.msi med samma MSIEXEC-kommando. Efter lyckad avinstallation via MSIEXEC gick vi in under program och avinstallerade VDA-agenten precis som vanligt.

 



Integrera Application Virtualization med Citrix Provisioning Services

För ett tag sedan var jag i ett projekt där vi ville använda Microsoft Application Virtulization (App-V) 5.1 och Citrix Provisioning Services (PVS) 7.8. Detta är fortfarande ett relativt outforskat område även om möjligheten har funnits under en längre tid. Under projektets gång stötte vi på två stycken problemområden; startmeny och laddningstider av AppV-paket för slutanvändare. Citrix har i samråd med Microsoft lagt ut en integrationsöversikt. Denna innehåller bra information om själva funktionerna i AppV, men inte hur man sätter ihop helheten. Tanken med projektet var att behålla en så ren PVS Master som möjligt, fri från applikationer för att enkelt kunna uppdatera och underhålla applikationer utan att skapa nya vDiskar.

Redirected startmeny och inladdningstider av applikationer

Det bästa sättet för att skapa en startmeny i Citrix XenApp 7 är fortfarande att använda sig av redirected startmeny. Ett utav de stora problemen med App-V Management Infrastrukturen är att den behöver ha skrivbehörigheter på startmenyn för att kunna populera genvägarna.  Ett annat problem är att användarna behöver vänta på att App-V paketen laddas in i sessionen innan man kan starta dem. I en miljö där man estimerar att köra ungefär 400 applikationer är det orimligt att vänta på att alla dessa applikationer skall laddas in, innan användarna kan börja jobba och starta applikationerna.

För att slippa väntetiden av inladdningen av applikationer via App-V så kollade vi på att ”cacha” applikationer direkt på våra PVS Targets. Vid uppstart lade vi in ett uppstartsskript. Problemet med detta är att varje applikation behöver laddas in vid uppstart av alla targets. Fem AppV-applikationer tog ungefär 15 minuter att ladda in vid uppstart, vilket innebär att 400 applikationer skulle ta… lång tid.

Lösningen blev att köra samma startupskript på våra Masters. Eftersom vi vet att vi skulle behöva göra minst en vDisk per månad för att underhålla miljön genom Windows Updates så gör detta att applikationer läggs till, förändras eller tas bort successivt vid omstart utan någon manuell handpåläggning. Vi kör nedan skript på både Master och Targets, vilket gör att de applikationer som inte redan är cachade direkt på vDisken laddas in vid omstart. När man gör en ny vDisk laddas de applikationer som inte redan finns på Mastern in.

Eftersom samtliga paket finns inlagda direkt Mastern och i sin tur vDisken som publiceras, gör detta att du kan peka dina genvägar från din redirected startmeny till C:\Programdata\AppV\<AppID>\<VersionID>\*.exe. När applikationerna redan är lagrade lokalt, kommer användarna få en mycket bättre användarupplevelse. I princip så nära på lokalt installerade applikationer som möjligt.

Kontakta gärna mig om du har problem eller vill diskutera  App-V integrationer i din Citrixmiljö.



Provisioning av Windows 2012 R2 – ShortFileName

I Windows 2012 R2 har det introducerats flera förbättringar. En förbättring är att Microsoft valt att stänga av vissa funktioner som tidigare varit aktiverade för bakåtkompabilitet. En sådan funktion är ShortFileName (SFN), även kallat 8dot3 Name Creation (8dot3), som Microsoft valt att inaktivera på nya diskvolymer som läggs till på en Windows 2012 R2, utöver operativsystemsdisken.

SFN användes i DOS, Windows NT 3.51 och Windows 95 där det fanns en begränsning i FAT filsystem för hur många tecken ett namn fick innehålla. Anledningen till att det är inaktiverat i senare OS versioner är för att SFN skapar en prestanda försämring vid skapande eller enumrering av filer [1].

För att enkelt verifiera om SFN existerar på en volym, skriv kommandot dir /x när du befinner dig i root-katalogen på en volym.

ShortFileName Exists

Resultat när SFN sökvägar existerar

Vi kan se att ”C:\Program files” har en förkortning till C:\PROGRA~1 och ”C:\Program Files (x86)” har en förkortning till C:\PROGRA~2.

Det är fördelaktigt att SFN är inaktiverat om det är en volymdisk på en filserver att spara prestanda. Som tidigare beskrivit vid skapande och enumrering av filer när SFN är aktiverat [1]Är det avstängt på en systemdisk, där applikationer fortfarande kan använda sig av SFN av någon anledning kan man få udda felmeddelanden.

Ett sådant scenario kan man stötta på när man provisionerar ut en ny diskrevision med Office 2013 installerat. Installation av Office-paketet i Golden-image fungerar och ger inga felmeddelanden. Först när man startar Word på sina provisionerade targets kan man få meddelandet:

Office Word Something Went Wrong

Utför vi kommandot dir /x på en provisionerad target kan vi se att ShortFileName sökvägar inte längre existerar på diskvolymen.

ShortFileName Does Not Exist

Resultat när SFN sökvägar saknas

Som beskrivit tidigare, när nya diskar läggs i Windows 2012 R2 blir SFN inaktiverat på nya diskar. Äldre program och plugins som använder sig av SFN kan delvis eller helt sluta fungera om sökvägarna inte existerar.

I följande scenario har vi en Golden image med en Systemdisk C:\ som vi skall kopiera till den tomma vDisken E:\. Vi kan verifiera att möjligheten att skapa SFN är aktiverat på volymen C: genom att använda oss av

  • fsutil.exe 8dot3name query c:
8dot3 name creation enabled

Skapandet av SFN-genvägar är aktiverat

Värdet “0 – 8dot3 name creation is enabled” för C:\ visar att det är möjligt att skapa SFN genvägar.  Utför vi samma kommando mot vår tomma vDisk E:\ kan vi se att det SFN är inaktiverat, vilket innebär att SFN sökvägar inte kommer skapas.

8dot3 name creation disabled

Skapandet av SFN-genvägar är inaktiverat

LÖSNING OCH ÅTGÄRD

För att undvika att varje ny vDisk har SFN inaktiverat ändrar man följande registervärde [2] i sin Golden Image.

Registry PATH:                             HKLM\System\CurrentControlSet\Control\FileSystem\
REG_DWORD:                             NtfsDisable8dot3NameCreation
Value:                                             2 > 0

0: Enables 8dot3 name creation for all volumes on the system.
1: Disables 8dot3 name creation for all volumes on the system.
2: Sets 8dot3 name creation on a per volume basis.
3: Disables 8dot3 name creation for all volumes except the system volume.

Källa: [1]
https://blogs.technet.microsoft.com/josebda/2012/11/13/windows-server-2012-file-server-tip-disable-8-3-naming-and-strip-those-short-names-too/

Källa: [2]
https://technet.microsoft.com/en-us/library/ff621566.aspx



Svart skrivbord med Citrix VDA 7.6

Fler har börjat installera XenApp-miljöer på Windows 2012 R2. Vid installation av XenApp 7.6 VDA-agent på en Windows 2012 R2, kan man eventuellt stöta på att publicerade applikationer och skrivbord inte fungerar optimalt. Som till exmpel ett svart skrivbord när användare loggar in.

Symptom:

Nedan följer två symptom som kan uppstå när man försöker ansluta till en Citrix XenApp 7.6 miljö.

  • Vid start av publicerad applikation står det att den startar, men dyker aldrig upp när den laddat färdigt.
    Citrix Receiver Appstart
  • Vid försök att nå publicerat skrivbord blir det endast en svart ruta när man ansluter.
    Citrix Receiver svart skrivbord

    Citrix Receiver svart skrivbord

Anledningen är att VDA-agenten inte hittar korrekt sökväg till mfaphook64.dll, som lägger sig mellan VDA-agenten och de processer som startar på XenApp-hostar. VDA-agenten hänvisar till C:\Citrix\System32\mfaphook64.dllDenna sökvägen finns ej och kan således inte laddas in.

För att verifiera om mfaphook64.dll är laddad korrekt kan man använda verktyget Process Explorer. Är det felaktigt konfigurerat är det endast spoolsv.exe som dyker upp. Laddas mfaphook64.dll korrekt kan man se att DLL-filen kopplar på sig på flera processer.

DLL-filen mfaphook64.dll laddas ej
mfaphook65.dll laddas ej
DLL-filen mfaphook64.dll laddas korrekt
mfaphook65.dll laddas korrekt
Lösningen är att redigera registervärdet som heter ”AppInit_DLLs” på de servrar där XenApp 7.6 VDA-agenten är installerad enligt nedan:

PATH: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\
REG_SZ: AppInit_DLLs
Value: mfaphook64.dll

Förslagsvis applicerar man registerförändringen med Group Policy Preferences under Computer Configuration på de XenDesktop/XenApp-hostar där problemet uppstår.
Group policy preferences register applicering