[W2K3] Windows 2003 Profiles

[chratnox]

Hallo,

We hebben op 't werk wat performanceproblemen met het laden van profielen van gebruikers. Ik zal eerst de situatie toelichten.

Gebruikers loggen middels een Citrix Web Interface aan op Citrix, waarna ze de betreffende applicaties kunnen openen. Wanneer ze de applicatie openen duurt het een lange tijd voor de applicatie daadwerkelijk ingeladen is. We hebben inmiddels kunnen kortsluiten dat dit probleem in de profielen van de gebruikers zit en hebben hiervoor een nieuwe server ingericht. Nu willen we echter "testen" met deze nieuwe server of het echt sneller is.

Het probleem is echter, we moeten meetbare resultaten hebben dat dit daadwerkelijk aan profielen ligt, heeft iemand tips hoe ik dit kan gaan meten? Zijn er applicaties of tools die dit kunnen "simuleren"?

Het zijn zowel virtuele als fysieke machines waar dit op voor komt.

Alvast bedankt.

[MAX3400]

Het loaden/unloaden van profielen gebeurt, denk ik, op het back-end dus je verbindingen vanaf je CTX-machine naar buiten toe, kan je buiten schot laten.

Denk dat je je eerst moet gaan afvragen of het aan je profielen ligt (hoe groot, wat voor SAN/share, kabeltjes etc) en daarna misschien afvragen of bepaalde policies (GPO's etc) niet in de weg zitten.

/edit
Hier zijn trouwens voldoende artikelen over geschreven door Microsoft, hun eigen techies (op blogs) en veel andere "hoge figuren" in de TS/CTX-wereld. Vraag me dus even af wat je zelf al hebt gevonden en bedacht (welk plan van troubleshooting, wat er al uitgesloten is, wat er mogelijk een probleem is etc. etc. etc.)

[ Voor 31% gewijzigd door MAX3400 op 09-02-2009 14:23 ]

[chratnox]

MAX3400 schreef op maandag 09 februari 2009 @ 14:20:
Het loaden/unloaden van profielen gebeurt, denk ik, op het back-end dus je verbindingen vanaf je CTX-machine naar buiten toe, kan je buiten schot laten.

Denk dat je je eerst moet gaan afvragen of het aan je profielen ligt (hoe groot, wat voor SAN/share, kabeltjes etc) en daarna misschien afvragen of bepaalde policies (GPO's etc) niet in de weg zitten.

De server waar de profielen op staan is een virtuele server (2 CPU, 4GB ram) met een extra vmdk eraan gekoppeld (uiteraard op het SAN, IBM DS4800). Het profiel is echter niet veranderd ten opzichte van het profiel op de oude server, dit zou een goed meetresultaat op kunnen leveren denk ik.

Ik dacht zelf ook al aan de verbindingen van de cliënt naar Citrix zelf buiten schot te kunnen laten inderdaad. Het belangrijkste zit hem in de grootte van de profielen, deze profielen zijn gemiddeld +/- 5MB groot. Ik denk dat je het met me eens kan zijn dat 5 minuten laden voor een profiel van 5MB veel te veel is .

Edit: Ik zag later je edit pas. de omgeving is als volgt opgebouwd: Kantoorautomatiseringsomgeving - Firewall - Tussenlaag (Citrix Servers, Web servers e.d.) - Backoffice laag (Database servers, applicatie servers e.d.). Wij denken dat het verplaatsen van de profielen server naar het Tussenlaag netwerksegment winst op kan leveren, omdat het verkeer met Citrix dan binnen 1 netwerksegment blijft. Om eerlijk te zeggen zit ik een beetje met mn handen in het haar om te kijken waar ik allemaal op moet meten.

[ Voor 19% gewijzigd door chratnox op 09-02-2009 14:30 ]

[MAX3400]

Ik vermoed, maar kan jouw omgeving niet zien, dat je je roaming profiles gewoon ruk/verkeerd/slecht hebt geconfigureerd van meet af aan... Ik heb zelf, op verschillende (fysieke en virtuele omgevingen) een roaming profile (terminal server profile!!) van tientallen MB's en dat duurt maar enkele seconden om te loaden.

Heb je al geprobeerd om een nieuwe user aan te maken, in een andere OU, en daar eens mee spelen zodat bepaalde verdachte GPO's niet worden applied en dat je misschien een nieuwe/andere GPO maakt voor het roaming profile?

[Archie_T]

Roaming profiles zijn meestal geen probleem tenzij ze heeeeeeel groot zijn. Het is niets anders dan een kopieerslag. Kijk even naar je AD/ DNS configuratie in deze omgeving.

[chratnox]

MAX3400 schreef op maandag 09 februari 2009 @ 14:29:
Ik vermoed, maar kan jouw omgeving niet zien, dat je je roaming profiles gewoon ruk/verkeerd/slecht hebt geconfigureerd van meet af aan... Ik heb zelf, op verschillende (fysieke en virtuele omgevingen) een roaming profile (terminal server profile!!) van tientallen MB's en dat duurt maar enkele seconden om te loaden.

Heb je al geprobeerd om een nieuwe user aan te maken, in een andere OU, en daar eens mee spelen zodat bepaalde verdachte GPO's niet worden applied en dat je misschien een nieuwe/andere GPO maakt voor het roaming profile?

Ha Max3400,

De profielen zijn inderdaad ook toegepast op nieuwe users, in andere OU's, waar de problemen zich ook voordoen. Dit is in een OU waar geen GPO's op toegepast zijn, waardoor deze niet voor vertraging kunnen zorgen. Nu komt er wel bij dat ik het volledig met je eens ben dat de omgeving niet goed ingericht is, maar helaas ben ik er pas later bij gekomen, waardoor ik nu als een soort inspecteur clouseau de gehele omgeving aan 't doorspitten ben om te kijken waar 't fout gaat.

[MAX3400]

Archie_T schreef op maandag 09 februari 2009 @ 14:31:
Roaming profiles zijn meestal geen probleem tenzij ze heeeeeeel groot zijn. Het is niets anders dan een kopieerslag. Kijk even naar je AD/ DNS configuratie in deze omgeving.

Goed punt maar topicstarter zit eraan te denken om de profiles te verplaatsen naar dezelfde "laag" als de CTX-bakkies. Of dat technisch verantwoord is, lijkt me niet, maar desondanks zou je daarmee DNS en mogelijk routing kunnen uitsluiten.

Misschien nog makkelijker; wat gebeurt er als je als admin via rdp aanlogt op een CTX-bak en handmatig het profiel van iemand kopieert van de huidige centrale opslag naar je desktop; gaat het dan ook zo brak of gaat dat wel goed?

Als je trouwens je GPO's eens een trap geeft via gpresult; staan er dan geen dubbele/overbodige of zelfde verschillende waarden in het resultaat t.o.v. de properties van userX in AD?

[ Voor 10% gewijzigd door MAX3400 op 09-02-2009 14:37 ]

[chratnox]

MAX3400 schreef op maandag 09 februari 2009 @ 14:36:
[...]

Goed punt maar topicstarter zit eraan te denken om de profiles te verplaatsen naar dezelfde "laag" als de CTX-bakkies. Of dat technisch verantwoord is, lijkt me niet, maar desondanks zou je daarmee DNS en mogelijk routing kunnen uitsluiten.

Misschien nog makkelijker; wat gebeurt er als je als admin via rdp aanlogt op een CTX-bak en handmatig het profiel van iemand kopieert van de huidige centrale opslag naar je desktop; gaat het dan ook zo brak of gaat dat wel goed?

Als je trouwens je GPO's eens een trap geeft via gpresult; staan er dan geen dubbele/overbodige of zelfde verschillende waarden in het resultaat t.o.v. de properties van userX in AD?

Technische verantwoording is op dit moment helaas niet meer van toepassing. De gebruikers klagen dat 't traag is, het management roept dus dat 't sneller moet, op welke manier ook. Als ik het gewoon kopieer gaat 't wel een stuk beter, maar zet nog niet echt zoden aan de dijk. Is er een soort netbios diagnostic tool welke ik zou kunnen gebruiken om te testen of netbios/wins in orde zijn?

Overigens, 1 van de redenen om te kijken naar de profielen is, wanneer je een gebruiker in laat loggen zonder TS profiel, kan hij wel snel inloggen. Daarom is het zaak voor ons om eerst naar de profielen te kijken. Ofwel: wanneer een gebruiker erg lang doet over inloggen, halen we tijdelijk het profiel uit het TS ProfilePath en laten we 'm opnieuw testen, op dat moment gaat het wel snel. Het profiel blijkt dan daarna echter maar 5MB groot te zijn.

[MAX3400]

chratnox schreef op maandag 09 februari 2009 @ 14:49:
[...]
...Als ik het gewoon kopieer gaat 't wel een stuk beter, maar zet nog niet echt zoden aan de dijk...

Mag ik hieruit opmaken dat je netwerk in het algemeen bagger is? Of is het echt alleen met profielen (en bijvoorbeeld niet met een BMP van 4MB die iemand vanaf het SAN wil openen in een applicatie)?

De vraag wordt in dit geval of de duplex-mode van de servers en de switches wel vast staat (en niet auto-sensing), of rotzooi als spanning-tree uitstaat, staat er ergens teaming aan (zo ja, wat gebeurt er zonder teaming), etc. etc.

Heb je ook gekeken naar andere mogelijke metingen; dus van layerA (hetzij kantoor/frontend/backend/whatever) kopieren/verplaatsen van bestanden op de bovenliggende/onderliggende/zelfde laag?

/edit
Ik krijg het gevoel dat er meer aan de hand is dan je hebt getypt (of los wil laten) en daardoor onze focus voor jouw troubleshooting beperkt. Vandaar mijn uitgebreide gebrabbel.

[ Voor 10% gewijzigd door MAX3400 op 09-02-2009 15:03 ]

[chratnox]

MAX3400 schreef op maandag 09 februari 2009 @ 15:00:
[...]

Mag ik hieruit opmaken dat je netwerk in het algemeen bagger is? Of is het echt alleen met profielen (en bijvoorbeeld niet met een BMP van 4MB die iemand vanaf het SAN wil openen in een applicatie)?

De vraag wordt in dit geval of de duplex-mode van de servers en de switches wel vast staat (en niet auto-sensing), of rotzooi als spanning-tree uitstaat, staat er ergens teaming aan (zo ja, wat gebeurt er zonder teaming), etc. etc.

Heb je ook gekeken naar andere mogelijke metingen; dus van layerA (hetzij kantoor/frontend/backend/whatever) kopieren/verplaatsen van bestanden op de bovenliggende/onderliggende/zelfde laag?

/edit
Ik krijg het gevoel dat er meer aan de hand is dan je hebt getypt (of los wil laten) en daardoor onze focus voor jouw troubleshooting beperkt. Vandaar mijn uitgebreide gebrabbel.

Ik begrijp het. Er is zoveel meer aan de hand, maar als ik dat allemaal ga opnoemen komt dat ook niet bepaald professioneel meer over. Anyway, rotzooi als spanning-tree, teaming e.d. staat uit. De netwerkkaart staat "hard" ingesteld op 1000Mbps FD, op de switches staan deze poorten ook op vast. Kopiëren van bestanden binnen dezelfde laag en van bestaden naar andere laag duurt ongeveer even lang (bestand van 100MB duurt +/- 25 seconden), zowel binnen zelfde netwerksegment als ander netwerksegment. Nadeel is denk ik ook een beetje, inmiddels ben je het "gewend" om ermee te werken, omdat alles ook afgekeurd wordt wanneer je iets wilt "verbeteren". Nu heb ik de kans om voor verbetering te zorgen, maar moet ik allerlei wazige metingen aanleveren. Dat is gelijk ook de reden van de vraag, hoe kan ik een goede meting uitvoeren via een citrix omgeving, is er een tool oid voor om dit te kunnen doen?

Ik geloof dat ik nu alles genoemd heb

[Archie_T]

Als je metingen mbt aanloggen enz wilt doen zou ik XPerf van MS adviseren. Ik heb dit zelf ook gebruikt voor wat problemen met trage PC's bij het aanloggen en opstarten op XP clients. Hier krijg je precies een overzicht van alle processen, wat ze doen, hoe lang ze erover doen. Je kan dit op verschillende manieren opsplitsen: Hier staat een wat betere beschrijving:
http://blogs.microsoft.co...-performance-toolkit.aspx

[MAX3400]

Vind 4MB/s op een Gbit-netwerk wel erg "traag", genuanceerd gezegd... Kan me inderdaad voorstellen dat er een x aantal problemen hieruit voorkomen waardoor (onder andere) het opvragen van een profiel erg lang kan duren.

Mogelijk dat het advies van Archie iets verbetering kan brengen in je profielen maar ik zou je scope (qua performance) zo groot mogelijk houden.

[Archie_T]

MAX3400 schreef op maandag 09 februari 2009 @ 15:28:
Vind 4MB/s op een Gbit-netwerk wel erg "traag", genuanceerd gezegd... Kan me inderdaad voorstellen dat er een x aantal problemen hieruit voorkomen waardoor (onder andere) het opvragen van een profiel erg lang kan duren.

Mogelijk dat het advies van Archie iets verbetering kan brengen in je profielen maar ik zou je scope (qua performance) zo groot mogelijk houden.

Dat zondermeer! Maar vanuit deze tool kan je wel zien wat er traag gaat, ik heb zelf met deze tool gevonden dat Windows updates bij ons in de weg zaten, je kan dus zien welke processen lang duren. Dat is het voordeel. Aan de hand van deze resultaten kan je dus kijken of het inderdaad netwerk, DNS, policies, AD, de DS4800, virusscanner, of weet ik veel is. Ik geef deze tool meer aan als begin, zodat je ergens kan zoeken, niet als oplossing.
Wat ik trouwens ook niet snap uit je antwoorden is waarom je een file server als VMDK op je DS4800 hebt? Kan je niet beter een RAW Lun mapping maken zodat je de overhead van het VMDK filesystem kwijt ben?

[chratnox]

Archie_T schreef op maandag 09 februari 2009 @ 15:34:
[...]

Dat zondermeer! Maar vanuit deze tool kan je wel zien wat er traag gaat, ik heb zelf met deze tool gevonden dat Windows updates bij ons in de weg zaten, je kan dus zien welke processen lang duren. Dat is het voordeel. Aan de hand van deze resultaten kan je dus kijken of het inderdaad netwerk, DNS, policies, AD, de DS4800, virusscanner, of weet ik veel is. Ik geef deze tool meer aan als begin, zodat je ergens kan zoeken, niet als oplossing.
Wat ik trouwens ook niet snap uit je antwoorden is waarom je een file server als VMDK op je DS4800 hebt? Kan je niet beter een RAW Lun mapping maken zodat je de overhead van het VMDK filesystem kwijt ben?

Ja, dat zijn dingen die ik ook aangekaart heb inderdaad. Helaas hebben we een eigenwijze architect zitten die het daar niet mee eens is, waardoor het niet uitgevoerd mag worden. Hierom moeten we ervoor zorgen dat het allemaal zo snel als mogelijk draait op de manier waarop 't nu ingericht is. Ik ga eens naar die tool van je kijken, dank je wel!

[Question Mark]

Het eerste wat ik altijd doe bij vermoede problemen mbt tot aanloggen en profiel problemen is het debuggen van de user environment:

How to enable user environment debug logging in retail builds of Windows

The versions of Microsoft Windows that are listed in the "Applies to" section let you modify the registry to turn on debug logging of the user profile and the Windows system policy processes. You can also use this logging to track down problems that are related to the start of Desktop Standard PolicyMaker client-side extensions (CSEs).

[_H_G_]

chratnox schreef op maandag 09 februari 2009 @ 15:08:
[...]
De netwerkkaart staat "hard" ingesteld op 1000Mbps FD, op de switches staan deze poorten ook op vast.

Je bedoelt dat snelheid/duplex op de switches ook vast staan? Weet je het zeker? Ik zou het toch even testen met netio ofzo, en dan huidige situatie vergelijken met beide kanten auto-sensing.

Je kan zulke vage resultaten krijgen, dat de rest testen niet zoveel zin heeft voordat je zeker weet dat je managed switch goed ingesteld staat en goed werkt.

[chratnox]

_H_G_ schreef op dinsdag 10 februari 2009 @ 09:16:
[...]


Je bedoelt dat snelheid/duplex op de switches ook vast staan? Weet je het zeker? Ik zou het toch even testen met netio ofzo, en dan huidige situatie vergelijken met beide kanten auto-sensing.

Je kan zulke vage resultaten krijgen, dat de rest testen niet zoveel zin heeft voordat je zeker weet dat je managed switch goed ingesteld staat en goed werkt.

Ja, ik heb zojuist nogmaals op de switches gecontroleerd, deze staan inderdaad op hard 1000mbps FD. Ik heb ze hierna ook nog op auto-sensing gezet (beide kanten), dit gaf geen verschil. Ik ga aan de slag met de opmerking van Question Mark (het debuggen van userenv), bedankt voor jullie tips!