Tag: XenApp

Flickering Desktop Icons and re-directed folders

This blog post will only cover a scenario with Microsoft Windows Server 2016 Remote Desktop Services (RDS) and re-directed folders where flickering icons appear. Other solutions may apply to different scenarios.
Since the release of Windows 10 / Server 2016 and their different releases 1607, 1703, 1709 and 1803 there has been several issues regarding flickering icons on the Start-menu, in File Explorer and taskbar.

SCENARIO

During the deployment of Citrix Virtual Apps and Desktops 7.15 on Windows Server 2016 with published Desktops and re-directed Desktop folder, users could experience that the desktop icons kept flickering continuously. The more shortcuts, folders or files on the Desktop the more prevalent the issue was. Constantly blinking icons on the desktop looked like refreshing the desktop with F5 or Ctrl+R and would also flash when browsing network shares.

My first thought was to activate ”Always show icons, never thumbnails” in Folder Options since there seemed to be a constant query to network shares where the re-directed Desktop folder resided.

File Explorer - Options

File Explorer – Options

File Explorer - Always show icons

File Explorer – Always show icons

INVESTIGATION

The moment I clicked on View in Folder Options the desktop icons ceased flashing in my session. Dwelling deeper with Procmon investigating what actually happens when opening View tab in Folder Options I found out that explorer.exe queries a registry key in the users HKEY_CURRENT_USER registry. If the registry entry does not exist it will be created.

  • HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}
Explorer query and creation of registry key

ProcMon – Explorer.exe query and creation of registry key

SOLUTION

With the knowledge that the registry key was missing and creating they key would stop the icons from flashing for users on Windows Server 2016 RDS, the appropriate solution was to use Group Policy Preferences (GPP) that created the registry key for users during logon (run in logged-on users’s security context) and apply it to Windows 2016 RDS servers.
Gorup Policy Preferences - User Configuration - Registry

Gorup Policy Preferences – User Configuration – Registry

Apply to Current User

Apply to HKEY_CURRENT_USER and set Key Path

Run in logged-on users security context

Run in logged-on users security context

Step 1: Create a USER GPP that will be applied to affected targets

Step 2: Create a Registry Item

Step 3: Add registry key

  • Hive: HKEY_CURRENT_USER
  • Key Path: SOFTWARE\Classes\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}
  • Tab Common: [v] Run in logged-on user’s security context (user policy option)

If you have any questions regarding above solution, or ideas on how to handle above in a better way, please contact me at viktor.glinski@xenit.se or post a comment below.



Scout 3.0 släppt med XenApp 7.14

I samband med att XenApp/XenDesktop 7.14 media blev tillgängligt 2017-06-09 ingår även Scout v3.0 med i mediet.

Scout GUI

Scout GUI

Scout är ett verktyg för Citrix-administratörer att enkelt kunna samla in diagnostik och loggfiler från en Delivery Controller eller VDA. Loggfiler kan sedan laddas upp till Citrix Insight Services (CIS) för analys, hälsokontroll och få rekommendationer på åtgärder eller förbättringar.

Verktyget används även vid kontakt med Citrix support för att underlätta vid felsökning och korta ner tiden det tar att lösa eventuella incidenter eller problem. För närvarande finns inte Scout v3.0 tillgängligt via en separat nedladdningslänk likt Scout v2.23.

Scout v.3.0 ingår endast i det media som används vid installation och uppgradering av XenApp/XenDesktop miljöer.

Värt att notera är att tidigare version av Scout (2.x) stödjer:

  • XenApp 6.x
  • XenDesktop 5.x
  • XenApp/XenDesktop 7.1 upp till 7.14

Version 3.0 stödjer endast XenApp/XenDesktop 7.14 och senare.

Om man av någon anledning valt bort installation Citrix Telemetry Service när man installerat VDA eller tagit bort tjänsten, kan man utföra installationen manuellt genom att köra installationfilen i mediet som finns under ”Citrix XenApp and XenDesktop 7.14.1\x64\Virtual Desktop Components\TelemetryServiceInstaller_x64.msi”

Den nya versionen förbättrar säkerheten, prestandan och användarupplevelsen.

Andra förbättringar är:

  • Capture Always-on-Traces (AOT)
    • AOT eliminerar behovet av att reproducera problem eftersom inloggningsspåren kan skickas säkert till Citrix med verktyget.
  • Insamling av obegränsad diagnostik data (beroende på resurser tillgängliga)
    • Tidigare versioner hade 10 enheter som standard vid ett insamlingstillfälle.
  • Support för Citrix Cloud
  • Schemaläggning av Call Home
  • Powershell Call Home cmdlets på alla maskiner med därTelemetry Service installerats
    • Tidigare fick man använda sig av CMD på den lokala maskinen.

För att läsa mer hur man använder sig av den nya Scout v3.0 besök följande länk.

Källor: http://docs.citrix.com/en-us/xenapp-and-xendesktop/7-14/manage-deployment/cis/scout.html



Uppdatering av Citrix XenApp 7.6 LTSR

I dagarna släpptes den senaste uppdateringen för XenApp 7.6 LTSR, Cumulative Update 3. Uppdateringen är släppt för samtliga licensnivåer av XenApp. Versioner för CU3 av de olika komponenterna är följande:

  • VDA för Klient OS* 7.6.3000
  • VDA för Server OS 7.6.3000
  • Delivery Controller 7.6.3000
  • Citrix Studio 7.6.3000
  • Citrix Director 7.6.3000
  • Group Policy Management Experience 2.5.3000
  • StoreFront 7.6.4
  • Provisioning Services* 7.6.4
  • Universal Print Server** 7.6.3000
  • Session Recording*** 7.6.3000

 

I och med att det är Citrix Long Term Service Release så är det inga större nyheter i de nya versionerna, utan främsta fokus har varit på att förbättra stabilitet och säkerhet ytterligare.

Om det är så att ni själva driftar en Citrix XenApp LTSR-plattform så skulle jag vilja rekommendera nedan verktyg från Citrix, deras LTSR Assistant. Verktyget kontrollerar att rätt versioner är installerade och att allt ser rätt ut utifrån ett versionsperspektiv.

Citrix LTSR Assistant: https://support.citrix.com/article/CTX209577

Just nu fungerar verktyget endast upp till CU2, men jag är övertygad om att en uppdaterad version kommer inom närmsta dagar eller veckorna.

Används assistenten tillsammans med Citrix Scout kommer du få en riktigt bra överblick över din plattform!

Källa: http://docs.citrix.com/en-us/xenapp-and-xendesktop/7-6-long-term-service-release.html

*: Speciella villkor för Windows 10

**: Endast Windows Server 2008R2 SP1, Windows Server 2012, Windows Server 2012R2 som är supporterade OS

***: Endast med Citrix XenApp/XenDesktop Platinum-licens



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/



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.

 



Publicera RDP Proxy-länk via StoreFront

Sedan ett tag tillbaka har NetScaler Gateway inte bara möjlighet att agera ICA Proxy för XenApp och XenDesktop, utan kan även agera RDP Proxy åt Remote Desktop Session Hosts.

För att dra nytta av detta har man antingen behövt publicera länken via Clientless-portalen som finns i NetScaler Gateway alternativt länka till den på något annat sätt. Jag hittade ett enkelt sätt att få in denna länk tillgänglig via StoreFront, så användarna kan starta sitt Remote Desktop via RDP Proxy på samma ställe de har sina publicerade skrivbord och applikationer från XenApp/XenDesktop. Värt att notera är att jag bara fått det att fungera via webläsaren och inte via Citrix Receiver, samt att detta inte är något som är supporterat från Citrix så finns möjlighet att det ställer till problem (men enkelt att inaktivera). Jag har testat det med StoreFront 3.0 och 3.5, men mycket möjligt att det kan behöva göras om för äldre/nyare versioner.

Utan att gå in något djupare på hur allt fungerar så skickar StoreFront en lista till webläsaren med alla tillgängliga applikationer. Det vi gör är att vi skriver om denna lista med hjälp av NetScalerns rewrite-funktion och infogar en ytterligare applikation på ungefär samma sätt som ”content” kunde bli publicerat i XenApp 6.5.

Först behöver vi inaktivera encoding så vi kan skriva om innehållet, jag gjorde det på följande sätt och applicerade det till den virtuella servern jag har för lastdelning av StoreFront:

Beskrivning av ovan:

  1. Skapa en rewrite action för att ta bort headern ”Accept-Encoding” från requesten som kommer från webläsaren till StoreFront-servern
  2. Skapa en rewrite policy som applicerar vår action när headern X-Citrix-Via är ”nsgw.xenit.se” (alltså endast när trafiken kommer via NetScaler Gateway, byt ut nsgw.xenit.se till ditt FQDN), när path är ”Citrix/StoreWeb/Resources/List” (byt ut StoreWeb till din StoreFront stores namn) samt när trafiken inte kommer från Citrix Receiver
  3. Bind policyn mot den virtuella servern för StoreFront

Nästa steg, utför själva omskrivningen av svaret från StoreFront till webläsaren:

Beskrivning av ovan:

  1. Skapa en rewrite action som infogar det nya innehållet (i JSON-format) efter ”resources”:[. Se till att byta ut FQDN för NetScaler Gateway samt RDPProxy-länken (i mitt fall 10.20.30.40) samt peka om URL till ikonen, samt välj ett namn och ID som passar.
  2. På samma sätt som innan, skapa en rewrite policy
  3. På samma sätt som innan, bind policyn mot den virtuella servern för StoreFront

Detta går att använda för fler typer av länkar, säg siter som är skyddade av AAA eller länk till någon hjälpsida. När jag testade mig fram till detta med hjälp av XenApp 6.5 och publicering av content fanns det en del andra parametrar som publicerades förutom dem jag infogar, men vad jag sett har det fungerat utan – men kan vara så att de behövs vid något speciellt scenario.

Hoppas detta kan vara till hjälp för någon som bygger en Unified Gateway med vill använda StoreFront som den enda portal att komma åt alla resurser. Förhoppningsvis kommer något liknande detta vara inbyggt i framtiden, så vi inte behöver göra det manuellt.



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