[Terminal server 2003] Inloggen gaat traag

[Vinze]

Op mijn stage ben ik bezig met het opzetten van een terminal server.
Tot nu toe ben ik al een aardig eindje opweg en loopt alles mooi soepel op 1 ding na:
Wanneer ik inlog op de terminal server en op enter druk krijg ik een blank grijs scherm welke +/- 10 seconden blijft staan voor het venster met "Applying your personal settings" tevoorschijn komt.

In die 10 seconden denken gebruikers vaak dat hij vast loopt en gaan dan op allemaal knoppen drukken.
Nu zou ik heel graag dat grijze scherm weg willen hebben, maar hier loop ik dus op vast.

Wat heb ik al gedaan:
- Alle policy's uitgeschakelt.
- Geen logon scripts gebruiken
- Inloggen als administrator
- Lokale profielen verwijderd

Het ligt in iedergeval niet aan de verbinding tussen de thin client en de server, hier ligt glasvezel tussen en heeft een response tijd van <1ms. Ook moet de server snel genoeg zijn aangezien ik met maar 2 gebruikers inlog namelijk; de administrator en een testgebruiker.
Specs: Intel Xeon 3,40ghz 1GB Ram (VMware machine)

Kan iemand mij advies geven over waar ik nog kan zoeken, of hoe ik erachter kan komen wat hij doet op het moment dat het grijze scherm verschijnt?

B.v.d

[Question Mark]

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

[Vinze]

Question Mark schreef op maandag 09 maart 2009 @ 12:33:
How to enable user environment debug logging in retail builds of Windows

Bedankt, maar helaas werkt het niet.. Kan de key UserEnvDebugLevel niet vinden in het register.

En nog even een aanvulling op de startpost:
In de event viewer staan ook geen rare dingen of foutmeldingen die verklaren waarom het lang duurt, daar heb ik dus ook niks aan.

[Question Mark]

Vinze schreef op maandag 09 maart 2009 @ 13:14:
[...]

Bedankt, maar helaas werkt het niet.. Kan de key UserEnvDebugLevel niet vinden in het register.

Dan maak je hem aan, dat staat ook in het artikel:

Gebruik de Register-editor om de volgende registervermelding toe te voegen of te wijzigen:

Subsleutel: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Sleutel: UserEnvDebugLevel
Type: REG_DWORD

[Vinze]

Question Mark schreef op maandag 09 maart 2009 @ 13:19:
[...]
Dan maak je hem aan, dat staat ook in het artikel:


[...]

Oh, overheen gelezen
Heb hem nu aangemaakt maar nogsteeds schrijft ie geen log file weg, geen flauw idee waarom hij dat niet doet.
Maar ga liever ook niet teveel in het register om prutsen, als ik de boel om zeep help heb ik een probleem

Verder nog mensen die weten wat de oorzaak zou kunnen zijn van dat grijze scherm direct na het inloggen en voor het toepassen van de persoonlijke instellingen? Lijkt me sterk dat ik de enige ben, we hebben hier 2 terminal servers staan, beide met hetzelfde probleem.

[alt-92]

Vinze schreef op maandag 09 maart 2009 @ 16:43:
[...]

Oh, overheen gelezen
Heb hem nu aangemaakt maar nogsteeds schrijft ie geen log file weg, geen flauw idee waarom hij dat niet doet.

Server heeft wel een reboot nodig denk ik (HKLM key).

[Vinze]

alt-92 schreef op maandag 09 maart 2009 @ 18:05:
[...]

Server heeft wel een reboot nodig denk ik (HKLM key).

Heb ik al gedaan, heeft niet geholpen.

Zijn er hier niet meer mensen die werken met terminal servers?
Zo ja; Hoe zit het bij jullie? Is het normaal dat het grijze scherm zo'n ~10 seconden leeg blijft staan na het inloggen?

[Question Mark]

Probeer nu gewoon om die logging werkend te krijgen. Ik heb nog nooit meegemaakt dat deze niet werkt, waarschijnlijk heb je ergens een kleine typefout gemaakt.

Die logging is hét hulpmiddel om traag aanloggen te kunnen troubleshooten. Het heeft niet zo heel veel zin om andere mensen naar ervaringen te vragen mbt aanloggen. Het is sterk afhankelijk van de inrichting van de omgeving en er is groot risico dat je appels met peren gaat vergelijken.

[FCVD]

Ff voor mijn beeldvorming:

-draait je Terminal server als een vmware op die server met 1gb geheugen?
-log je steeds in via Remote Desktop?
-wat gebeurt er als je rechtstreeks aanlogt?
-heb je tools draaien als NetOp(*) of iets in die richting? Deze willen nog wel eens langzaam starten met aanloggen.
-anti-virus of firewall applicaties die te 'strak' staan afgesteld


Dit zijn zomaar een paar dingetjes die bij mij voorbij schieten........


*applicatie voor het overnemen van het scherm van de gebruiker

[Vinze]

FCVD schreef op dinsdag 10 maart 2009 @ 10:31:
Ff voor mijn beeldvorming:

-draait je Terminal server als een vmware op die server met 1gb geheugen?
-log je steeds in via Remote Desktop?
-wat gebeurt er als je rechtstreeks aanlogt?
-heb je tools draaien als NetOp(*) of iets in die richting? Deze willen nog wel eens langzaam starten met aanloggen.
-anti-virus of firewall applicaties die te 'strak' staan afgesteld


Dit zijn zomaar een paar dingetjes die bij mij voorbij schieten........


*applicatie voor het overnemen van het scherm van de gebruiker

1. De terminal server is een virtuele machine met 1gb werkgeheugen toegewezen
2. Ik log in via Remote Desktop (Verbinding met extern bureaublad) en met een thin-client (Neoware) - Beide hebben het probleem
3. Goede vraag! Kan zelf niet op VMware inloggen dus kom hier nog op terug.
4. Nee er draaien geen tools, het is een bijna kale server met alleen een virusscanner
5. Trend Micro Office scan gebruiken we, weet niet of die strak staat afgestelt maar zal even aan mijn stage begeleider (administrator) vragen of ie tijdelijk uitgeschakeld kan worden om dit te testen.

Question Mark schreef op dinsdag 10 maart 2009 @ 10:30:
Probeer nu gewoon om die logging werkend te krijgen. Ik heb nog nooit meegemaakt dat deze niet werkt, waarschijnlijk heb je ergens een kleine typefout gemaakt.

Die logging is hét hulpmiddel om traag aanloggen te kunnen troubleshooten. Het heeft niet zo heel veel zin om andere mensen naar ervaringen te vragen mbt aanloggen. Het is sterk afhankelijk van de inrichting van de omgeving en er is groot risico dat je appels met peren gaat vergelijken.

Volgens mij heb ik het al door, hoe krijg ik nou precies de waarde 0x00030002?
Als ik bij value data 10002 (Hexadecimal) invul kom er te staan: 0x00010002 (65538).

Edit: oke ik heb het al, moest gewoon 30002 invullen

In iedergeval bedankt alvast!

[FCVD]

Nog meer vragen (sorry):

gebruik je roaming profiles? zo ja, hoe groot is/zijn deze?

1gb voor een TS vmware is wat aan de krappe kant.

Hoe zit het met je netwerkverbinding?

[Vinze]

Geen probleem, ik wil er best wat moeite voor doen

Maar ik gebruik geen roaming profiles, alle profielen zijn local (en rond de 1 tot 2 mb groot)
1gb lijkt mij toch ruim voldoende voor het inloggen van 2 gebruikers, dit is namelijk een test server waarop niemand inlogd bahalve ik zelf, als admin en testgebruiker.
De netwerk verbinding is prima, ping tijd van <1ms en er ligt een glasvezel verbinding.

Wat ik uit de logfile kan opmaken blijft hij hangen na winlogon.exe.
Zodra de gebruiker inlog duurt het 10 seconden voordat de logfile verder loopt.
Zie het volgende:
USERENV(fcc.c4) 13:41:28:050 InitializePolicyProcessing: Initialised Machine Mutex/Events
USERENV(fcc.c4) 13:41:28:050 InitializePolicyProcessing: Initialised User Mutex/Events
USERENV(fcc.c4) 13:41:28:050 LibMain: Process Name: \??\C:\WINDOWS\system32\winlogon.exe
USERENV(fcc.c4) 13:41:42:519 LoadUserProfile: Yes, we can impersonate the user. Running as self
USERENV(fcc.c4) 13:41:42:519
[...]
Er gaat nog 2-4 seconden vanaf bij winlogon.exe omdat ik ook het wachtwoord moest intypen

Edit: Heb net direct op de server ingelogd in de VMware console.
Dan loopt hij wel snel en goed door, helaas kan ik er nu nog niet achter komen waarom hij via RDP wel traag is.. Deze persoon heeft trouwens exact hetzelfde als wat ik ook heb, helaas geen oplossing.

[ Voor 18% gewijzigd door Vinze op 10-03-2009 13:48 ]

[Zwelgje]

clientprinters geredirect clientdrives geredirect

[Vinze]

Nee & nee..

Vreemde vind ik dat hij ook zonder een policy of een toegewezen homedir/printer zo traag is.
Snap ook niet dat we hier 2 servers hebben (1 in productie, en 1 om de testen) welke exact hetzelfde probleem hebben. En wat ik al helemaal niet snap is dat ik niemand kan vinden met hetzelfde probleem

[BFS]

Wellicht dat dit je verder helpt? Dit probleem heb ik al vaker gezien, er wordt gesproken over Citrix maar gaat eigenlijk over over TS.

[ Voor 12% gewijzigd door BFS op 11-03-2009 11:11 ]

[Vinze]

BFS schreef op woensdag 11 maart 2009 @ 11:10:
Wellicht dat dit je verder helpt? Dit probleem heb ik al vaker gezien, er wordt gesproken over Citrix maar gaat eigenlijk over over TS.

Bedankt voor de tip, heb even gekeken of dit is waar ik last van heb.

Volgens dit stukje:

To verify this delay, you can view the contents of the Branding log file (Brndlog.txt) for Internet Explorer Maintenance.

Note The Brndlog.txt file is in the following folder:
%UserProfile%\Local Settings\Application Data\Microsoft\Internet Explorer

Moet er in Brndlog.txt ergens 20 seconden tussen zetten. Dit is bij mij echter niet het geval.
Neem aan dat ik dit probleem dus kan uitsluiten.

[Zwelgje]

BFS schreef op woensdag 11 maart 2009 @ 11:10:
Wellicht dat dit je verder helpt? Dit probleem heb ik al vaker gezien, er wordt gesproken over Citrix maar gaat eigenlijk over over TS.

dat is echt een specifiek citrix probleem wat je daar aanhaalt

[Vinze]

offtopic:
Even een kickje..

Nou ik heb de bron gevonden, de (correcte) oplossing nog niet.
Zal even uitleggen wat er nou dwars zit en wellicht kunnen jullie mij verder helpen.

Als de gebruiker het inlogscherm ervoor heeft staan kan ik in de mcc Terminal Services Manager zien dat er 2 processen bij hem actief zijn, namelijk csrss.exe en winlogon.exe. Zodra de gebruiker zijn inlognaam en wachtwoord invult en op enter drukt komt hier 1 proces bij, dit is het proces mpnotify.exe.
Vervolgens blijft hij hier exact 12 seconden op staan en zie je het lege grijze scherm voor hij verder gaat met het inloggen.

Nu heb ik mezelf al even ingelezen en voor zover ik gezien heb is het de bedoeling dat winlogon.exe het proces mpnotify.exe beëindigd. (wat dus 12 sec. duurt)
Ik weet dat mpnotify wordt gestart door SYSTEM, en tijdelijk heb ik even de toegang hiertoe geblokkeerd (properties > security > SYSTEM > Full Control = Deny)
En voilá, hij start razendsnel op!

Nu weet ik echter niet of het kwaad kan dat ik dit proces blokkeer voor het systeem en zit dus met 2 vragen:
1. Kan ik zonder problemen mpnotify.exe blokkeren?
2. Is het mogelijk dat winlogon.exe het proces mpnotify.exe sneller beëindigd? (register key o.i.d)

Bvd

mpnotify.exe
The Mpnotify.exe process hosts network provider .dll files. Specifically, the Mpnotify.exe process calls the NPLogonNotify function of the network provider .dll file. Therefore, the network provider may not function as expected.

[ Voor 9% gewijzigd door Vinze op 25-03-2009 16:05 ]

[alt-92]

Toevallig software op deze TS geinstalleerd die iets met Single SignOn doet?

http://blogs.technet.com/...2-minute-logon-delay.aspx

[ Voor 41% gewijzigd door alt-92 op 25-03-2009 17:17 ]