Tag: RDS

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.



Nyheter på väg till RDS 2016

Microsoft presenterade tidigare i höstas nyheter som är på väg till Remote Desktop Services (RDS) 2016. Det är några stora förändringar på gång som är viktiga att känna till, och detta inlägg sammanfattar några av de nyheter som ska komma inom kort.

Infrastruktur

I en traditionell RDS infrastruktur måste alla servrar i uppsättningen vara med i domänen. Det innebär att RD Gateway och Webaccess servrarna både är med i domänen och har direkt kontakt mot internet, vilket gör dem sårbara för attack.

Med den nya infrastruktur design som Microsoft presenterar så är Gateway, Webaccess och de övriga rollerna ej längre med i domänen. Kontakten från domänen till infrastrukturen görs endast genom utgående trafik på port 443. Förutom att detta ökar säkerheten, så möjliggör det för organisationer att drifta flera olika miljöer med samma RDS infrastruktur. Inte längre behövs den en RDS miljö för varje domän, utan nu kan infrastrukturen sättas upp en gång för att drifta flera olika miljöer och låta användare ansluta till deras respektive domän och Sessionhosts.

Microsoft presenterar även en ny roll inom Remote Desktop Services; Diagnostics, vilket har som uppgift att samla in information om uppsättningen och kan användas för att felsöka anslutningsproblem.

Azure

Integration med Azure Active Directory (AAD) är snart här. Med hjälp av AAD så kan Multi-Factor Authentication, Intelligent Security Graph och övriga Azure tjänster nyttjas i RDS miljön. Azure AD är något som många organisationer redan nyttjar, om de använder sig av Office 365 tjänster.

 

Om RDS miljön sätts upp i Azure så kan organisationer installera RDS rollerna som Platform as a Service (Paas) tjänster. Det innebär att det inte längre krävs ett VM för varje roll i infrastrukturen, Administratörer slipper alltså managera varje VM individuellt, samt de får tillgång till den smidiga skalbarheten som Azure erbjuder. Denna uppsättning stödjer även hybrid-lösningar, Sessionhosts kan alltså ligga on-premise och resten av infrastrukturen i Azure.

Det finns fortfarande ingen ETA på när dessa nyheter görs tillgängliga. För mer information och demo på några av dessa funktioner, se inlägget från Microsoft.



Just enough Administration & RDS

The Problem?

Microsoft RDS has limitations when delegating access, in fact there is no built-in access delegation whatsoever!

The solution? Powershell!

A Just enough Administration (JEA) endpoint, also known as a Constrained Powershell Endpoint.

I’ve created a powershell app to list and logoff users I also created a simple tool in powershell to connect to connection brokers and search users. All without delegating users access to any RDS servers.

  1. Connection broker/Endpoint connection
  2. Collection field, used to search and filter. Multiple collections can be selected at once
  3. Wildcard search field, can be blank (list all users)
  4. User information & selection are
  5. Press to logoff all selected users

How does this work? Constrained Powershell Endpoint.

The endpoint is restricted to only access List collection, list users and subsequently force logoff users. The endpoint configuration to only accept users from a certain AD group.

To configure endpoint, run the following code on all connection brokers. The script is somewhat generalized for easy adaptability. The main parts are in the parameters where we configure who can run, using which account and also what cmdlet are available in the constrained session.

The frontend application code is not posted in the blog.



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!



Update for Windows is already installed on this computer?

En del uppdateringar från Windows Update misslyckas vid installation med en prompt om att uppdateringen redan är installerad. Ett återkommande exempel är KB3146978 som listas som en rekommenderad hotfix för RDS 2012 R2 Session Hosts. I ett flertal miljöer har jag sett att KB3146978 inte listas under Installed Updates, Systeminfo, Powershells Get-Hotfix, wmic get hotfixid eller andra sätt som är baserade på Win32_QuickEngineering men installation fastnar ändå på ”Update for Windows is already installed on this Computer”.

För att få en mer inkluderande översyn på vilka uppdateringar som faktiskt är installerade kan följande köras:

$Session = New-Object -ComObject ”Microsoft.Update.Session”
$Searcher = $Session.CreateUpdateSearcher()
$historyCount = $Searcher.GetTotalHistoryCount()
$Searcher.QueryHistory(0, $historyCount) | Select-Object Title, Description, Date,
@{name=”Operation”; expression={switch($_.operation){
1 {”Installation”}; 2 {”Uninstallation”}; 3 {”Other”}
}}} | Export-Csv -NoType ”$Env:userprofile\Desktop\Windows Updates.csv”

Windows Updates.csv lägger sig då på skrivbordet och innehåller i detta exempel information om att KB3146978 faktiskt är installerad.