Tag: Citrix

Outlook Search index med FSLogix

Något som upptäckts snabbt efter uppsättningen av sin ”FSlogix Office 365 Containers”-lösning i en fleranvändarmiljö är att sök-indexeringen för Outlook i vissa miljöer görs om vid varje ny inloggning, det gäller miljöer där man har flera Session Hostar användarna kan logga in på.

Sök-funktionen i Outlook använder sig av ”Windows Search” vilket är en databas över indexeringarna på hela Operativsystemet, det är alltså inget som lagras för varje enskild användare. Det innebär t.ex.  att en Citrix miljö med flera servrar kommer en användares Outlook indexera om hela Outlook vid varje ny server man loggar in på. Detta medför en långsam sökning (tills indexeringen är klar) och en onödigt belastning på CPU som i sin tur kan påverka hela miljön negativt. Det kan bli ännu värre i de fall man använder Citrix Provisioning Services (PVS) då den uppdaterade indexeringen försvinner vid varje omstart av servern.

FSLogix to the rescue

För att komma runt detta problem finns en funktion i FSLogix som tar med din Outlook indexering i VHD-filen, på så vis har du alltid din uppdaterade indexeringsdata med dig på vilken server du än hamnar på. Du behöver ändra på två stycken registervärden för att aktivera detta, jag själv föredrar att skapa/editera en GPO för detta.

Följande två registervärden ska justeras:

HKLM\Software\FSLogix\Apps

Type:                      DWORD

Value Name:          RoamSearch

Value Data:            2

 

HKLM\Software\Policies\FSLogix\ODFC

Type:                      DWORD

Value Name:          RoamSearch

Value Data:            2

 

Hör gärna av er om ni skulle vara intresserade av eller vill veta mer om produkter från FSLogix, se gärna våra tidigare blogginlägg om FSLogix nedan:

FSLogix Profile Containers – Enkel och snabb Profilhantering

Office365 med FSLogix i en fleranvändarmiljö

OneDrive with simulated Single Sign-On

 

 



FSLogix Profile Containers – Enkel och snabb profilhantering

FSLogix har en intressant produkt som heter Profile Containers, den tar hand om huvudvärken som profiler ofta skapar i fleranvändarmiljöer. Det är idag komplext att sätta upp en fleranvändarmiljö som erbjuder en bra upplevelse för användarna. En utav de stora utmaningarna är inloggningstiden för användaren eftersom storleken på profilen ofta är en stor faktor. Det krävs mycket tid till att exkludera så mycket som möjligt för att hålla nere användarens profilstorlek, vilket måste underhållas om t.ex. när nya applikationer introduceras i miljön. Det är dessutom väldigt standardiserad lösningar som inte tar hänsyn till varje persons unika behov vilket också försämrar upplevelsen.

Faktum är att Office 365 Containers som jag har skrivit om tidigare är en ”light-version” av Profiles Containers som löser några av de största problemen relaterade till Office 365 i en fleranvändarmiljö. Profile Containers fungerar nästan precis likadant som deras lite lättare produkt Office 365 Profile Containers som skapades just för att kunna nyttja några av de största fördelarna i Office 365 i en fleranvändarmiljö.

Precis som Office 365 Containers skapas en personlig VHD-fil för varje användare som lämpligtvis finns på en lagringsyta med hög tillgänglighet. VHD-filen kommer att anslutas till användarens session och hela profilen finns nu tillgänglig för systemet, ingenting behöver kopieras över, vilket är en mycket stor fördel. Det spelar ingen roll om profilen är 100 MB eller 5 GB, det kommer alltid ta samma tid för VHD-filen att ansluta till din session vilket innebär att inloggningstiden kommer ligga konstant, och det är runt ca 15 sek. Vi behöver alltså inte skapa komplexa regler för vad som ska finnas i profilen längre, användaren kan ha kvar allt och bibehåller då alla sina inställningar och data. Nedan kan du se skillnaden mellan FSLogix och andra metoder för att peka om profilen.

För att läsa mer om FSLogix Profile Containers och deras övriga produkter kan ni läsa mer på deras officiella sida www.fslogix.com

Vill ni veta mer om denna produkten tveka inte att kontakta oss för en mer detaljerad beskrivning om hur denna produkt kan hjälpa er!



Office365 med FSLogix i en fleranvändarmiljö

Eftersom Microsoft hårdsatsar på molnet och Office 365 har det länge varit ett naturligt steg att flytta sin on-prem Exchange till molnet – Exchange-Online i Office 365 för att kunna nyttja de många fördelar den erbjuder. Men det har i vissa fall inneburit försämrad upplevelse för slutanvändarna. I och med att Exchange nu befinner sig i Office 365 (Azure) har svarstiden ökat generellt. I många fall har en svarstiden ökat med en faktor om 10. Detta medför att navigering mellan mejl (när man använder förhandsvisaren aktiverad) är seg, det kan ta någon sekund för att det nya mailet man navigerar till dyker upp. Upplevelsen av Outlook blir påtagligt sämre och effektiviteten i sitt dagliga arbete påverkas.

Outlook Cached Mode

En lösning på problemet har varit att helt enkelt slå på Cached mode och helt blir av med problematiken av hög svarstid, detta fungerar väldigt väl med alla som har en ”fet klient” och har diskutrymme lokalt. I en fleranvändarmiljö blir det lite mer komplicerat, för att kunna köra cached mode i en fleranvändarmiljö såsom Citrix eller Microsoft Remote Desktop Services (RDS) måste man först kunna hantera stora mängder data eftersom fler och fler användare har väldigt stora mejllådor, profilstorlekarna blir dessutom väldigt stora och påverkar bland annat inloggningen negativt. För att komma runt detta riktar man om Outlook cachen (*.OST-filen) till ett lagringsyta (vanligtvis en filserver) som har kapacitet för lagringen och det i sin tur kommer inte belasta fleranvändarmiljön.

Många som kom fram till denna lösning har i sina tester haft mycket bra resultat, i en testgrupp på säg 20 personer fungerar detta mycket väl och implementering i sin produktionsmiljö är ett faktum. Men dessvärre slutar det inte här, det som kan vara svårt att förutspå är hur mycket den konstanta indexeringen av ost-filen belastar CPU:n och hur mycket nätverkstrafik SMB protokollet använder vid en sådan frekvent uppdatering av ost-filen, för att inte tala om vad Windows Search gör i en sökning av din mejllåda. All denna kraft står nu filservern för, som oftast inte är dimensionerad för detta, så som en Exchange-server är. Så när man produktionssätter sin lyckade lösning med 100+ användare blir resultatet ännu sämre än innan.

Detta är ett stort problem som många upplever och något som man har velat se en lösning på i många år, men det har dessvärre aldrig funnits någon lösning från Microsoft för detta. Det är här FSLogix Office 365 Containers kommer in i bilden.

FSlogix Office365 Containers

FSlogix är kortfattat ett företag där de tog saken i egna händer. De har utvecklat en produkt som löser alla problem ovan riktigt snyggt. Själva installationsförfarandet är mycket enkelt, du installerar en agent på alla servrar dina användare loggar på, lägger till ADMX tillägget i din Group Policy manager för styrning via GPO och pekar ut den filyta du vill att cachefilerna ska lagras.

Agenten kommer nu automatiskt peka om alla cachade filer till denna filyta (oavsett vad du definierar i Outlook). Det som FSLogix gör är att den skapar en vDisk för varje användare som vid inloggning kopplas på din session, det underlättar nätverksbelastningen avsevärt i jämförelse med SMB till en filserver, de har dessutom utvecklat intelligens för själva OST-filen som i grund och botten är en databas som konstant uppdateras. Den har ett slags mellanlager som sköter uppdateringen av OST-filen effektivare och snabbare, vilket gör att CPU belastningen blir en bråkdel av alternativet. Någon som också var en nyhet i våras som var mycket efterlängtat är att den även nu stödjer Windows Search så att din Cachade OST-fil är sökbar i Outlook.

FSLogix är ett mycket bra komplement för Exchange-Online i fleranvändarmiljöer!

OneDrive

I samma licens får man även tillgång till deras cachning av OneDrive, den lägger sig i samma vDisk som för Outlook och eftersom OneDrive börjar bli en bra produkt som fler och fler företag börjar använda är detta en mycket trevlig bonus.

 

 

Vill ni läsa mer om FSLogix Office365 Containers kan ni trycka här!



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



XenMobile 10.6 – Mycket nytt i senaste versionen

 

Citrix släppte i dagarna en ny version av XenMobile, 10.6, vilken innehåller flera efterlängtade funktioner och fixar. Bland nyheterna finns bland annat stöd för personliga kalendrar, virtuella smartkort och hantering av systemuppdateringar för iOS. För första gången på länge har det även kommit en uppdatering till Enterpriseversionen av Secure Mail och Secure Web.

Nyheter i klienten:

  • Derived Credentials (iOS) – I samarbete med Intercede kan Citrix nu erbjuda enroll med hjälp av certifikat. Läs mer på: http://docs.citrix.com/en-us/xenmobile/server/authentication/derived-credentials.html
  • Personlig kalender – Din personliga kalender (från Google/Apple) finns nu tillgänglig i Secure Mail, vilket även låter dig se när det blir krockar mellan din personliga och din arbetskalender
  • Per-app VPN för Android – Möjlighet att även för Android definiera vilka appar som skall gå genom VPN och vilka som går direkt mot internet
  • Stöd för Exchange Active Sync 16
  • Stöd för appar utvecklade med Xamarin Android och OkHttp

 

Nyheter på serversidan:

  • Uppdateringspolicy för iOS – Nu finns det (äntligen) stöd för att forcera uppdateringar av iOS
  • Windows 10 Unified Endpoint Management – Stöd för att identifiera och spåra förlorade enheter som kör Windows 10
  • Stöd för Windows Information Protection
  • Bättre stöd för Azure Active Directory – Azure AD kan nu användas som IdP för XenMobile
  • Bättre rapportering – Rapporter över användning har blivit utökade samt fått stöd för att exportera rapporter till pdf
  • Stöd för 2-faktorsautentisering för macOS – Enrollkoder kan nu skapas även för macOS
  • Möjlighet att välja flera plattformar för enroll – Hanteringen av enrollkoder blir lättare då det nu kan skapas en kod som gäller för samtliga plattformar

 

Utöver detta tillkommer ett antal buggfixar och förbättringar, samt några lite mindre synliga funktioner. För en full lista av ändringar, se:

http://docs.citrix.com/en-us/xenmobile/server/whats-new.html

samt

http://docs.citrix.com/en-us/xenmobile/server/fixed-issues.html

 



Provisioning services – Activate SMB2 for better security and performance

When installing Provision Services 7.x and below on a Windows 2008 R2 or Windows 2012 R2 – The Provisioning installer will disable SMB2 and only allow SMB1 on the server.
NOTE: SMB2 will still be enabled with a new install of PVS 7.13 (Thanks Andrew Wood).

Verify which SMB protocols are enabled on Windows 2012 R2 by running the following powershell command:

View SMB Protocols

View SMB Protocols


SMB 1.0 (or SMB1) – Used in Windows 2000, Windows XP and Windows Server 2003 R2 is no longer supported and you should use SMB2 or SMB3 which has many improvements from its predecessor. Another big reason is to prevent the security-hole that the WannaCry/Wcry/WannaCrypt0r-ransomware utilizes to infect and spread if you have not installed the security patch MS from Microsoft released 14th of March 2017.

Here’s a very brief summary of what changed with each version of SMB:

  • From SMB 1.0 to SMB 2.0 – The first major redesign of SMB – Windows Vista (SP1 or later) and Windows Server 2008
    • Increased file sharing scalability
    • Improved performance
      • Request compounding
      • Asynchronous operations
      • Larger reads/writes
    • More secure and robust
      • Small command set
      • Signing now uses HMAC SHA-256 instead of MD5
      • SMB2 durability
  • From SMB 2.0 to SMB 2.1 – The version used in Windows 7 and Windows Server 2008 R2
    • File leasing improvements
    • Large MTU support
    • BranchCache
  • SMB 3.0 – The version used in Windows 8 and Windows Server 2012

SMB2 has a requirement to utilize Oplocks. Enabling Oplocks will not cause any failures so long as the write cache is not stored on the Provisioning Server.
SMB2.1 introduced leasing and is more flexible and results in significant performance improvement in a high latency network.

If the write cache is on the PVS server then this would happen:

  1. You have two PVS servers, PVS1 and PVS2.
  2. The write cache for targets is hosted on \\FileSRV01\store
  3. A target device is connected to PVS1 and PVS1 becomes unavailable.
  4. The target device fails over and connects to PVS2.
  5. PVS2 cannot connect to the write cache file because PVS1 still has the exclusive OPlock to the file. Eventually, the OPlock will timeout and PVS2 will be able to connect to the write cache file, but there will be a delay.
    Cache-on-Server

ENABLE SMB2 and DISABLE SMB1

To activate SMB2 and disable SMB1 on Windows 2008 run the following PowerShell command:

To activate SMB2 and disable SMB1 on Windows 2012 run the following PowerShell command:

A reboot is required to activate the new settings. As always, perform any changes in a test scenario first, before deploying into production. This is important since Windows XP and Windows 2003 utilizes SMB1 and will not be able to communicate with servers over SMB where SMB1 has been disabled.

If you have any questions or feedback about above, feel free to leave a comment below!



Citrix PVS: UEFI Boot of Targets

If you wish to perform UEFI boot of Targets that are provisioned using Citrix PVS, below are the settings (mainly DHCP) that you need to apply. Majority of the info below was taken from this Citrix PowerPoint presentation.

If using Boot Device Management file (BDM):
With BDM, DHCP options are not needed since everything is in the BDM file. You will need to re-create the BDM file however and check the checkbox ‘Target device is UEFI firmware’.

If using either PXE or TFP to point Target devices to PVS servers:
– You need to specify either DHCP Option 11 or 17. Option 17 is only needed if you are not using port 6910 (which is standard) as the beginning of the PVS Streaming service ports on your PVS servers. For Option 11 you should add the IP address of each PVS server that will provide vDisk streaming (if you are using multiple NICs on your PVS server, specify the IP of the Streaming NIC).

– Option 17 only allows a single value, so in order to get redundancy between multiple PVS servers when using this Option you will need to
1. Specify a FQDN (not IP) as Option 17
2. Enable DHCP Option 6 (DNS server(s) to use)
3. Enable DHCP Option 15 (DNS domain name)
4. Configure Round Robin on the FQDN in step 1 on your DNS servers. It might be possible to load balance this on Netscaler instead, but that is not something I have tried.

The correct syntax for Option 17 is ”pvs:[MyPVSServer.domain.com]:17:6911” (without quotes), where 6911 is the custom PVS Streaming start port being used.

If using PXE to point Target devices to PVS servers:
– You will need to specify Option 60, as usual.

– With Citrix PVS, there is a feature called BOOTPTAB which allows you to specify, for example, that Target Device with MAC address X should be sent the Bootstrap file Y. The GUI for configuring this can be found at ”C:\Program Files\Citrix\Provisioning Services\bpedit.exe”. This feature allows us to support both Legacy and UEFI Targets in a PXE boot Setup (requires PVS 7.7 or higher). If you are using TFTP, then BOOTPTAB cannot be used since the name of the BOOTSTRAP to download will instead be extracted from Option 67.

If using TFTP to point Target devices to PVS servers:
– You need to specify DHCP Option 66, as usual (IP of your TFTP load balancer. If you only have a single PVS server, specify the IP of the PVS server)

– You also need to specify Option 67 (file name of the Bootstrap file that should be downloaded to booting PVS Targets from the TFTP servers). In normal Legacy boot setups, the value is ARDBP32.bin, but for UEFI this should be either PVSNBPX64.efi (for Targets running x64 Operating Systems) or PVSNBPX32.efi (for Targets running X86 Operating Systems).

– If you wish to support both Legacy and UEFI boot Targets in your TFTP setup, you will need to create an isolated DHCP scope for Legacy targets and an isolated DHCP scope for UEFI targets (or for example use BDM instead for Legacy devices) and then have Option 67 be different for each DHCP scope.

– A thing to note is that if you have only UEFI target devices in your setup, any IP address(es) specified for the ARDBP32.BIN file in below screenshot become irrelevant since the ARDPB32.BIN file will not be used in the boot process (the IPs or FQDN specified in Option 11 or 17 will instead dictate which PVS server a Target will stream the vDisk from).

Some additional notes:
– The reason why Option 11 or 17 is needed, instead of regular Option 67, is because the UEFI BOOTSTRAP files PVSNBPX64.efi/PVSNBPX32.efi cannot be edited, unlike the ARDBP32.bin file. And one purpose of the ARDBP32.bin file is to deliver to the booting Target device the IP of the PVS Server it should stream the vDisk from. Since the UEFI files cannot be edited to include the PVS server IPs, the PVS Server IPs must be delivered in some other way, hence Option 11 and 17.

– The ‘Secure Boot’ functionality of UEFI is only supported if the PVS Targets are physical devices. For VMs, the ‘Secure Boot’ feature must be disabled (it is enabled by default for Gen2 VMs on Hyper-V, for example)

– XenServer does not support UEFI boot of VMs hosted on it (as of XS 7.1). Hyper-V supports it but it requires that you use Gen2 VMs and Synthetic NICs on the VMs, and only x64 operating systems on the VMs. VMWare ESX 5.0 and higher support UEFI target boot.

– Citrix PVS 7.7 added support for TFTP/PXE booting of UEFI devices, while PVS 7.9 added support for BDM boot of UEFI devices.

– The boot menu on devices that allows you to choose a specific vDisk, for example, is not available with UEFI boot. A maintenance version of the vDisk will be chosen over a test or production version by default.

If you have any questions or comments about above, feel free to either comment here or email me at Rasmus.Kindberg@xenit.se.



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/