Category: XenApp

Print drivers and Microsoft Update KB3170455

Typically users get their printers mapped by Group Policies or Group Policy Preferences. Especially in Citrix environments, users should not have the right to add their own printers or drivers that are not approved for multi-user environments. On July 12th 2016, Microsoft released a security update (KB3170455) to safeguard Man-in-the-Middle (MITM) attacks for clients and print servers. Then an updated version was released again September 12th 2017.

Users could encounter the dialog boxes below if the driver did not meet the requirements of Microsoft where the driver would be packaged and signed with a certificate:

Scenario 1

For non-package-aware v3 printer drivers, the following warning message may be displayed when users try to connect to point-and-print printers:

Do-you-trust-this-printer

Do you trust this printer?

Scenario 2

Package-aware drivers must be signed with a trusted certificate. The verification process checks whether all the files that are included in the driver are hashed in the catalog. If that verification fails, the driver is deemed untrustworthy. In this situation, driver installation is blocked, and the following warning message is displayed:

Connect-to-printer

Connect to Printer

Even if you enabled Point and Print restrictions in GPO and specified which server’s clients could get drivers from, users could encounter an installation prompt and request administrator privileges to install.

For most printers this is not an issue if there is an up-to-date driver which is compliant. Some manufacturers do not always provide printers drivers that is both packaged and signed. The first thing you should do is update the driver to one that both is signed and packaged. Usually the drivers from the manufacturer are signed according to Microsoft Windows Hardware Quality Labs (WHQL) but may not be packaged correctly and the users get prompted for administrator credentials when the printer is being added to the client computer or in the remote desktop session.

Since KB3170455 we need to enable point and print restrictions and specify our print servers in the GPO. For most printers there is no issues, however a couple of printers will not be pushed out by Group Policy Preferences since the update. Even though the print server was listed in the point and print GPO. Browsing the print share and trying to connect the printer manually would result in the ”Do you trust this printer” pop up which will then prompt for administrator credentials to install the driver. Looking at Print Management on the server in question shows that the problem printer drivers have a ”Packaged” status of false.

Workaround:

If you are pushing out printers via Group Policy or Group Policy Preferences and they are of Non-Packaged type you will always get a prompt to install, ignoring the point and print GPO, which will cause the install to fail. A workaround to this is a registry edit on the print server – test and verify this first before putting it into production:

  • HKLM\System\CurrentControlSet\Control\Print\Enviroments\Windowsx64\Drivers\<…>\<Driver name>\PrinterDriverAttributes

Change the value from 0 to 1 and reboot the printspool service or/and server. The value for other print drivers may not be 1, but to make this work the value needs to be set to an odd number. For example, if the value is 4 change it to 5. Only do these changes if you have no other means of getting a valid driver or printer swapped. In RDS/Citrix environments you could pre-install the printer driver on the host if viable and you only have a few session-hosts.

Back in Print Management you will see the Packaged status is now changed to true, and the printer should deploy. If you can find packaged print drivers then use those, but some manufacturers have not bothered supplying them.

PrintManagement-packaged-true

PrintManagement – Packaged True

Source: https://support.microsoft.com/en-us/help/3170005/ms16-087-security-update-for-windows-print-spooler-components-july-12



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



Configure Google Chrome in a multi-user environment

Installing and configuring Google Chrome in a multi-user environment can be everything but easy. More and more users change from Internet Explorer to a much more convenient browser and they expect to use it in business too. In this post, I will provide a short tutorial how I usually install and configure Google Chrome for a non-popup seamless experience for your end user.

Installing Google Chrome is a basic next, next, next installation by using the MSI-file provided here. The problem with configuring Chrome is that there are several ways to set different kinds of settings. Sometimes you can configure the same type of settings on several places and sometimes you only have one place to configure some settings. There are mainly three ways of configuring settings – Policy based (ADMX-template), master preferences and tags on the shortcut when launching Chrome. I will be talking about the first two in this post. I always try to set as much settings as possible in a group policy (GPO) using the ADMX-templates. Why? Because it is much easier to update a GPO than to update a file on each session host.

Google Chrome is an application that configure and do many things in the background. Do you really want all users to be prompted to check the default browser, get a first run introduction and create shortcuts on the desktop? Although this is a standard procedure that most users are familiar with, it is much more convenient (and enterprise) to not get any popups at all. Below is what I usually add in the “master_preferences”-file. I have not found a convenient way to see a full list of settings to configure, but this is the closest I have yet to come.

 

notepad “C:\Program Files (x86)\Google\Chrome\Application\master_preferences”

 

After installing Google Chrome and adding the “master_preferences”-file I usually proceed by downloading the ADMX-templates from here. Download and install the ADMX-template in your central store. Browsing through the settings you should notice three things.

  1. All settings are applied to the computer, meaning that the settings configured do not affect user login time.
  2. There is two folders with policys. In “Google Chrome – Default Settings” the user may override all the configured defaults. In the other folder the user may not override the configured defaults.
  3. The settings we configured using the “master_preferences” is not overridable.

 

Google Chrome GPO

Please browse through each setting in the group policy and configure the settings to your liking.

Google Chrome saves a lot of settings and files in the user profile. If you are using roaming profiles, the profiles will soon begin to fill up and users will get a longer login time. There are two different approaches we can take. If your roaming profile system allows you to include and exclude files and directories you may use the first one below.

 

Include files:

 

The second approach is to configure the policy “Set user data directory” to your home catalog. I prefer using the second one due to that it is much easier to manage.

Google Chrome GPO User data directory



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!



Windows Login prompt with Single Sign-On XenApp

Lately some customers reported they didn’t get Single Sign-On all the way into the desktop when logging in via the browser to StoreFront. Single Sign-On worked partly with automatic login to the StoreFront desktop/application view, but whenever they tried to start a new session the users faced a Windows login prompt. Citrix have released a relatively new article with a variety of things to test when facing problems with Single Sign-On for XenApp/XenDesktop.

Windows Login Prompt

I usually apply settings for Citrix Receiver using GPO and applying them to user level. The problem was immediately solved by applying Citrix Receiver settings to the computer level instead.

Citrix Receiver Authentication Settings



StoreFront for Web med Firefox 52

NPAPI är ett API som används för att identifiera plugin för webbläsare och tillåta dem att köras när man går in på sidor som kräver dem. API:et är väldigt gammalt och det finns många mer moderna och smidiga lösningar än att använda just NPAPI. För att få webutvecklare att gå över till nya teknologier och modernare lösningar har bland annat Google Chrome sedan en tid tillbaka slagit av stödet för API:et. The Mozilla Foundation har även dem meddelat sedan en tid tillbaka att det skulle slås av för Firefox – från version 53.

I Citrix fall har NPAPI använts för att identifiera, aktivera och använda Citrix Receiver när man startar sessioner från Citrix StoreFront for Web, det vill säga när man loggar in i en webbläsare för att starta skrivbord eller publicerade applikationer.

Det verkar som att Mozilla har ändrat sig och helt enkelt slagit av stödet en version tidigare än kommunicerat, vilket förmodligen kan ställa till det för en hel del mjukvaruutvecklare och systemleverantörer – där ibland Citrix. Som tur är så är Citrix väl förberedda och har redan släppt en lösning!

Som nämnt var Citrix sett till att vara förberedda på NPAPI förändringen, från version 3.8 av Citrix StoreFront var allt förberett och planerat för att använda den nya tekniken så fort version 53 skulle komma. I och med att förändringen kom en version tidigare behöver administratörer gå in och manuellt ändra konfigurationen – det är väldigt enkelt!

Det man behvöer göra är att modifiera sin *web.config* för de StoreFront Stores som används för StoreFront for Web (C:\inetpub\wwwroot\Citrix\StoreWeb, där StoreWeb är namnetpåstore+Web).

Leta där i upp följande rad:

Och ändra till:

Som den uppmärksamme läsaren möjligen noterar så uppdaterar man den regexp som definierar vilka versioner av Firefox den så kallade protocolHandlern skall användas istället för native NPAPI från version 5[3-9] till 5[2-9] – helt enkelt från 53-59 till 52-59.

Efter en replikering av inställningarna, vid högt tillgänglig StoreFront, och en iisreset så skall Firefox åter fungera perfekt med Citrix StoreFront for Web.

Lycka till!

Källa: https://www.citrix.com/blogs/2017/03/15/firefox-52-and-citrix-receiver-for-web/



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



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/