Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the better-wp-security domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /customers/6/3/c/comegetit.nl/httpd.www/wp-includes/functions.php on line 6114 Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the jetpack domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /customers/6/3/c/comegetit.nl/httpd.www/wp-includes/functions.php on line 6114 Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the powerpress domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /customers/6/3/c/comegetit.nl/httpd.www/wp-includes/functions.php on line 6114 Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wordpress-seo domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /customers/6/3/c/comegetit.nl/httpd.www/wp-includes/functions.php on line 6114 Wat is een gebruiker profiel, en tegen welke uitdagingen kun je aanlopen? - Come Get IT ( CGIT )
Gemiddelde leestijd: 5 Minuten

Iedere gebruiker heeft er een, een profiel. Of je nou op een fysieke machine werkt, laptop of desktop, een virtuele machine, multi-user of single-user het maakt niet uit. In het profiel van een gebruiker wordt persoonlijke informatie opgeslagen. Helaas kun je afhankelijk van de gekozen desktop of applicatie oplossing nog wel eens tegen bepaalde uitdagingen aan lopen. Vandaag bespreken we er een aantal.

De inhoud

Het profiel van een gebruiker kun je beschouwen als een centrale opslagplek waarin diverse gebruikersinstellingen worden bewaard. Zo bevat het profiel informatie over de gebruikte applicaties en overige programma’s, inclusief instellingen die door de gebruiker worden aangepast. Ook gebruiker gerelateerde informatie m.b.t. het besturingssysteem wordt in het profiel bewaard. Denk hierbij onder andere aan monitor configuraties, netwerk connecties, desktop achtergrond, favorieten, bezochte bestanden/mappen/directories (historie) en meer.

Als een gebruiker zijn of haar profiel om wat voor reden dan ook kwijt raakt, of het profiel raakt corrupt (onbruikbaar), dan is dat erg vervelend. Er zal een nieuw, standaard leeg profiel worden aangemaakt. Je kunt weer van voor af aan beginnen.

Om maar een simpel voorbeeld te geven, de eerst volgende keer dat je Microsoft Word opstart zul je eventueel aangebrachte wijizgingen aan de instellingen kwijt zijn.

Nadeel

Een nadeel van een gebruiker profiel is dat deze aanzienlijk in omvang kan toenemen. Profielen van tientallen of honderden MB’s zijn geen uitzondering. Tegenwoordig groeien ze zelf tot meerdere GB’s.

Als je op een gewone PC of laptop werkt is dat geen probleem. Je profiel staat dan op de lokale harde schijf of SSD opgeslagen. Je start de computer, logt in en je persoonlijke data (vanuit je profiel) is vrijwel direct beschikbaar.

Log je in op een VDI of RDSH omgeving, van Microsoft, Citrix, VMware of een andere leverancier, dan staat je profiel over het algemeen centraal opgeslagen, op een apart systeem (een File Server). Zodra je inlogt zal het profiel van dit systeem naar de VDI/RDSH omgeving gekopieerd worden. Je voelt ‘m al aankomen, hoe groter het profiel, hoe langer dit duurt – zie onderstaande afbeelding.

Dit geldt overigens ook voor Cloud omgevingen, inclusief Windows Virtual Desktop.

Wanneer de gebruiker uitlogt wordt het profiel van de gebruiker terug gekopieerd naar het centrale systeem, inclusief eventueel aangebrachte wijzigingen. Dit kan opnieuw de nodige tijd in beslag nemen, hoewel je hier als gebruiker over het algemeen weinig van mee krijgt.

Dit concept, in zijn geheel, wordt ook wel “Roaming Profiles” genoemd.

Het is gebruikelijk dat een profiel bij het uitloggen van een gebruiker wordt “ontkoppeld” en verwijderd. Daarom moet het profiel iedere keer als een gebruiker inlogt opnieuw worden gekopieerd/geladen.

De architectuur van dit type oplossingen (VDI / RDSH) kan er voor zorgen dat een profiel niet juist wordt “ontkoppeld” of “opgeruimd” bij het uitloggen van de gebruiker. Of, dat een profiel meerdere malen tegelijkertijd wordt geladen. Als gevolg hiervan kan een profiel “corrupt” en dus onbruikbaar raken, als eerder aangegeven.

Er is meer

Vandaag de dag is het gebruik van Office 365,waarbij je e-mail vanuit de Azure Cloud wordt aangeleverd eerder regel dan uitzonering.

Een veel voorkomende aanpak binnen VDI en/of RDSH omgevingen is het gebruik van niet persistente virtuele machines. Wanneer de gebruiker uitlogt of zich afmeld (hangt van de configuratie af) binnen een VDI omgeving betekend dit dat de machine opnieuw wordt opgestart en volledig wordt geleegd (reset).

Alle aanpassingen en eventueel opgeslagen data worden/wordt verwijderd en de machine wordt klaar gezet voor de volgende gebruiker. In het geval van een RDSH omgeving werkt het iets anders. Het gebruiker profiel wordt zoals eerder uitgelicht “ontkoppeld” en verwijderd. Daarmee wordt ook alle data en aangebrachte wijzigingen binnen het profiel teniet gedaan. Een resultaat vergelijkbaar met dat van VDI.

In het geval van Office 365 komt er nog een uitdaging bij.

Bij het gebruik van Office 365 en mail vanuit Azure kun je kiezen tussen het gebruik van twee modi, online en offline (dit regelt je IT afdeling). Het gebruik van de online modus betekend dat je direct en live in de Azure Cloud aan het werk bent.

In de praktijk blijkt dit onvoldoende te werken (traag).

Offline betekend dat een configureerbare hoeveelheid (bijvoorbeeld de laatste drie of zes maanden) van je mail in Azure lokaal wordt gekopieerd en opgeslagen. Belangrijk om te weten: deze mail data komt terecht in je gebruiker profiel (wordt opgeslagen in een zogenaamd .OST bestand).

Hierdoor zal je profiel aanzienlijk in omvang toenemen.

De eerstvolgende keer dat je inlogt op een VDI of RDSH omgeving zal opnieuw je profiel geladen moeten worden. Aangezien deze in grote (meerdere GB’s waarschijnlijk) is toegenomen kan hier enige tijd over heen gaan.

Office 365 nadeel Nr. 1.

Een tweede uitdaging bij het gebruik van Office 365 op VDI/RDSH omgevingen is het gebruik van je Windows zoek index. Wanneer een gebruiker inlogt begint de Windows zoek index op de achtergrond met het indexeren van data, inclusief alle e-mail welke zich in het gebruiker profiel bevindt.

Omdat je profiel, en alle bijbehorende data wordt verwijderd na het uitloggen van de gebruiker of het herstarten van de machine (iedere keer weer), als eerder uitgelegd begint ook het indexering proces steeds opnieuw.

Als gevolg zal je direct na het inloggen niet beschikken over een geïndexeerde inbox. Met andere woorden, je kunt niks vinden, “Outlook search” zal vrij nutteloos zijn totdat de data is geïndexeerd. Hoe snel dat gebeurt is mede afhankelijk van de hoeveelheid data. Ook het auto aanvullen van eerdere gebruikte namen en e-mail adressen wordt binnen het gebruiker profiel opgeslagen. Informatie waar je snel over wilt kunnen beschikken.

Office 365 nadeel Nr. 2.

Oplossing

Gelukkig zijn er verschillende oplossingen beschikbaar die ons hier bij kunnen helpen. Een van de meest gebruikte en efficiëntste oplossingen is die gebaseerd op lagen (Layering).

Je hebt misschien wel eens iets gehoord over “application layering”. Er zijn verschillende gebruiker profiel oplossingen die zijn gebaseerd op deze technologie.

Dat werkt grofweg zo: Er wordt een aparte virtuele laag (virtuele harde schijf / VHD, VHDX) gecreëerd waarop het profiel van de gebruiker wordt geplaatst. Zodra de gebruiker inlogt wordt deze virtuele laag (VHD) aan het Windows besturingssysteem toegevoegd/gekoppeld. Deze aanpak zorgt ervoor dat het gebruiker profiel, inclusief alle data vrijwel direct beschikbaar is.

In plaats van het gebruiker profiel te kopieeren en over het netwerk te sturen wordt het nu is zijn geheel aan de betreffende machine gekoppeld. Het betreft een zogenaamde “disk mount” van de virtuele VHD. Alle data is hierdoor direct te bereiken en te gebruiken. Sneller, en een stuk efficiënter.

Omdat de VHD wordt gekoppeld iedere keer als een gebruiker inlogt op een VDI of RDSH systeem, en alle wijzigingen binnen het profiel worden opgeslagen lijkt het alsof de data persistent is, terwijl het in werkelijkheid met de gebruiker mee “zwerft”.

Ik probeer het zo eenvoudig mogelijk uit te leggen, de onderliggende technologie is echter zeer complex. Een van de meest gebruikte oplossingen in dit genre is FSLogix. Nog niet zo heel lang geleden gekocht door Microsoft en nu een standaard onderdeel van de Windows Virtual Desktop propositie.

Naast profiel data bieden dit type oplossingen ook een uitkomst voor andere applicaties die data of configuratie instellingen opslaan binnen het profiel, zoals OneDrive bijvoorbeeld.

Onderstaand nog een afbeelding om het proces (hopelijk) iets te verduidelijken.

Het blijft een lastig concept om uit te leggen, hopelijk heeft dit verhaal het een en ander voor je opgehelderd. Zo niet, kom maar op met je vragen, of schiet een van je meer technische collega’s aan.

Dank voor het lezen en tot een volgende blog.