[W2K3 & XP] Inloggen in domein time-out door winlogon

[SierdW]

Sinds vandaag heb ik een vreemd probleem:

Ik heb hier een W2K3 server draaien die domain-controller is. Deze server wordt door mij via Extern Bureaublad bestuurd. Alles werkte tot op vandaag goed.

Ik had echter vandaag een nieuwe regel aan het loginscript toegevoegd, zodat in een log bestandje kon worden bijgehouden welke gebruikers op welke computer aanmelden en op welk tijdstip. Om dit nieuwe script even toe te passen op de computers die al aanstonden heb ik die computers even de opdracht gpupdate /force gegeven en de stations werden netjes uitgelogd.

Toen ik weer in wilde loggen leek alles goed te gaan, instellingen werden geladen, instellingen werden toegepast en toen gebeurde er niks meer. Na ongeveer 10 minuten wachten werd uiteindelijk toch nog het bureaublad geladen en werkte alles weer 'perfect' (maw je kon niet merken dat er iets mis was). In het logboek echter staat nu de melding op de server:

Type gebeurtenis: Waarschuwing
Bron van gebeurtenis: Winlogon
Categorie van gebeurtenis: Geen
Gebeurtenis-ID: 1217
Datum: 6-9-2006
Tijd: 14:50:04
Gebruiker: n.v.t.
Computer: SERVER
Beschrijving:
Execution of GPO scripts has timed out and have been terminated.

Zie Help en ondersteuning op http://go.microsoft.com/fwlink/events.asp voor meer informatie.

en op de clients:

Type gebeurtenis: Waarschuwing
Bron van gebeurtenis: Winlogon
Categorie van gebeurtenis: Geen
Gebeurtenis-ID: 1217
Datum: 6-9-2006
Tijd: 15:06:21
Gebruiker: n.v.t.
Computer: PC2
Beschrijving:
Er heeft een time-out in de uitvoering van scripts voor groepsbeleidsobjecten plaatsgevonden. De scripts zijn gestopt.

Zie Help en ondersteuning op http://go.microsoft.com/fwlink/events.asp voor meer informatie.

Wie kan mij vertellen wat hier misgaat, want ik ben het even kwijt...

[marquis]

Heeft de gebruiker wel recht op de map om die logfile aan te maken ( denk aan logfile in SYSVOL map zetten) of laat je het als machine uitvoeren? (ff opletten ja???) Die time-out lijkt op een rechten probleem.
Of kijk eens naar de rechten van het uitvoeren van het scriptje.....

[ Voor 19% gewijzigd door marquis op 06-09-2006 15:54 . Reden: taalkundig voutje ;-) ]

[SierdW]

Ja, die rechten hebben ze wel. De vermelding in het logbestand word ook wel gemaakt, dus daar zit volgens mij de fout niet... Ik zal het nu een keer proberen zonder die regel in het script...

/edit Script heeft tot vandaag goed gewerken, en toen werden er ook al 2 bestanden in diezelfde map gekopieert, dus die rechten zijn aanwezig.

[ Voor 27% gewijzigd door SierdW op 06-09-2006 15:57 ]

[DennusB]

Wat is de code van dat bestand?
Ff posten:)

[SierdW]

echo LOGON %date% %time% Logon %username% op %computername% >> \\server\online\log.log

Maar aan die regel ligt het niet, want zonder die regel (REM) is het probleem nog steeds aanwezig...

[ Voor 37% gewijzigd door SierdW op 06-09-2006 16:00 ]

[marquis]

Wordt de tijd netjes gesynchroniseerd met de domain controler ? (doe maar een gok.... )
Heb je iets veranderd waardoor het niet meer werkt?
Een nieuwe scanner of een update?
Kik eens in het logboek van je scanner of er iets geblokt wordt?

Edit: REM is uitvoeren van regel niet laten uitvoeren.

[ Voor 55% gewijzigd door marquis op 06-09-2006 16:04 ]

[DennusB]

SierdW schreef op woensdag 06 september 2006 @ 15:58:


Maar aan die regel ligt het niet, want zonder die regel (REM) is het probleem nog steeds aanwezig...

Wat is die REM regel?

En wat heb je dan nog meer aangepast behalve die logregel?

[SierdW]

Ik heb rem voor de regel in het script gezet, zodat die regel wordt overgeslagen. Verder heb ik niks aangepast. Ik heb zojuist ergens anders gelezen dat een policy 'aan z'n einde kan komen', dus dat ie ineens niet meer werkt. Dat lijkt me niet zo aannemelijk, toch

[ Voor 27% gewijzigd door SierdW op 06-09-2006 16:06 ]

[DennusB]

SierdW schreef op woensdag 06 september 2006 @ 16:05:
Ik heb rem voor de regel in het script gezet, zodat die regel wordt overgeslagen. Verder heb ik niks aangepast. Ik heb zojuist ergens anders gelezen dat een policy 'aan z'n einde kan komen', dus dat ie ineens niet meer werkt. Dat lijkt me niet zo aannemelijk, toch

Ik draai hier al 1,5 jaar win 2003 server met domain controller en nog steeds dezelfde policy.
Werkt goed.

Trouwens aan die regel licht hier niet hier werkt ie goed!

Hoeveel users zitten in dat domein?

[ Voor 3% gewijzigd door DennusB op 06-09-2006 16:16 ]

[SierdW]

Er zijn iets van 5 users, het is maar een klein netwerkje:) Ik krijg dus duidelijk het idee dat de server iets verkeerd doet, dat die niet die group policy weggeeft. Al het andere binnen het domein verloopt vlekkeloos, exchange heeft geen problemen. Alleen het ophalen van de group-policy lukt niet lijkt het wel.

Het valt me nu trouwens ook op dat bij het starten van windows na "Bezig met voorbereiden van netwerkverbindingen" en "Bezig met toepassen computerinstellingen" het toepassen van het beveligingsbeleid niet gebeurd... Vreemd...

[ Voor 80% gewijzigd door SierdW op 06-09-2006 16:24 ]

[DennusB]

SierdW schreef op woensdag 06 september 2006 @ 16:21:
Er zijn iets van 5 users, het is maar een klein netwerkje:)

Hmm...en bij alle users komt de error naarvoren?

Edit: Server al opnieuw opgestart?

[ Voor 7% gewijzigd door DennusB op 06-09-2006 16:25 . Reden: Edit ]

[SierdW]

Jep, geen enkele gebruiker kan normaal inloggen. Allemaal krijgen ze een time-out. Ik kan natuurlijk een nieuwe group-policy gaan maken, maar als het even anders kan... Dan liever anders

/edit Server is ook al opnieuw gestart, en zelfs op de server heb ik het probleem met inloggen via extern bureaublad...

[ Voor 24% gewijzigd door SierdW op 06-09-2006 16:26 ]

[DennusB]

SierdW schreef op woensdag 06 september 2006 @ 16:25:
Jep, geen enkele gebruiker kan normaal inloggen. Allemaal krijgen ze een time-out. Ik kan natuurlijk een nieuwe group-policy gaan maken, maar als het even anders kan... Dan liever anders

/edit Server is ook al opnieuw gestart, en zelfs op de server heb ik het probleem met inloggen via extern bureaublad...

Lijkt wel of je server virus heeft of zelf problemen heeft met winlogon

Hebben je clients geen spyware of virusje zonder dat jij het weet?

[SierdW]

Ja, das een goeie... zonder dat ik het weet kan natuurlijk, maar het lijkt me niet aannemelijk. Voor zover ik weet is er niks binnengekomen qua mail en ik ben momenteel de enige die als gebruiker bezig is. (Zo goed als) uitgesloten lijkt me...

[DennusB]

SierdW schreef op woensdag 06 september 2006 @ 16:31:
Ja, das een goeie... zonder dat ik het weet kan natuurlijk, maar het lijkt me niet aannemelijk. Voor zover ik weet is er niks binnengekomen qua mail en ik ben momenteel de enige die als gebruiker bezig is. (Zo goed als) uitgesloten lijkt me...

Je weet maar nooit:
Virusscanner op de clients?

Virusscanner op je server?

WIndows geupdate?

[SierdW]

Alles is bij, en virusscanners overal aanwezig, zal ze nu ook laten draaien...

Verder vind ik nu ook nog op de clients de volgende fout:

Type gebeurtenis: Fout
Bron van gebeurtenis: Userenv
Categorie van gebeurtenis: Geen
Gebeurtenis-ID: 1091
Datum: 6-9-2006
Tijd: 16:16:27
Gebruiker: NT AUTHORITY\SYSTEM
Computer: PC2
Beschrijving:
De groepsbeleidsextensie van de client Internet Explorer Branding kan geen RSoP-gegevens (Resulterende verzameling beleidsregels) in het logboek registreren. Controleer of er al eerder fouten zijn gerapporteerd door deze extensie.

Zie Help en ondersteuning op http://go.microsoft.com/fwlink/events.asp voor meer informatie.

[DennusB]

Heb je nog genoeg ruimte op elke client en op de server?

Mischien deze error omdat ie geen ruimte meer in de log heeft!

Edit: Heb je een vuurmuur op de server? En op de clients?

Nog een edit: Zit er geen verkeerblokker in de virusscanner?

[ Voor 33% gewijzigd door DennusB op 06-09-2006 16:38 . Reden: Firewall ]

[SierdW]

* SierdW waardeert dat dennus2006 zo goed meedenkt

Firewall op de server staat uit, firewall op clients staat aan. De clients hebben voldoende ruimte dus dat kan het ook niet zijn... Ik denk toch dat er iets fout gaat met het uitdelen van die group-policy, maar wat weet ik nog niet...

/edit Ik heb niks veranderd behalve die regel, daarom is het ook zo vreemd. Er is niks wat iets in de weg staat of blokkeert. Op de server gaat het immers ook fout, en daar is het allemaal lokaal, daar gaat niks over het netwerk.

[ Voor 28% gewijzigd door SierdW op 06-09-2006 16:41 ]

[DennusB]

SierdW schreef op woensdag 06 september 2006 @ 16:40:
* SierdW waardeert dat dennus2006 zo goed meedenkt

Firewall op de server staat uit, firewall op clients staat aan. De clients hebben voldoende ruimte dus dat kan het ook niet zijn... Ik denk toch dat er iets fout gaat met het uitdelen van die group-policy, maar wat weet ik nog niet...

Wat gebeurt er als je de firewall als test even uitzet en dan inlogd?

Trouwens... op de clients staan tog wel de dnssen ingesteld?

[SierdW]

DNS staat allemaal goed, het heeft altijd goed gewerkt en daar is niks in veranderd. Ik heb helaas te weinig verstand van group-policies

[DennusB]

SierdW schreef op woensdag 06 september 2006 @ 16:44:
DNS staat allemaal goed, het heeft altijd goed gewerkt en daar is niks in veranderd. Ik heb helaas te weinig verstand van group-policies

Das heel erg jammer.
Mischien kan je even een poort openzetten in je router, ultravnc server instaleren, mij toevoegen op msn en dan kijk ik even als je wil!

[SierdW]

Nee, dat lijkt me geen goed idee (niet om jou, maar gewoon over het algemeen). Ik heb de viruscans laten lopen en er is niks gevonden met NOD32 (zoals ik wel had verwacht). Er is dus iets anders wat niet goed zit. Misschien is mijn probleem meer iets voor het Windows Servers en Software forum?

[DennusB]

SierdW schreef op woensdag 06 september 2006 @ 16:56:
Nee, dat lijkt me geen goed idee (niet om jou, maar gewoon over het algemeen). Ik heb de viruscans laten lopen en er is niks gevonden met NOD32 (zoals ik wel had verwacht). Er is dus iets anders wat niet goed zit. Misschien is mijn probleem meer iets voor het Windows Servers en Software forum?

Ja er zit iets mis:) Dat weet ik maar wat?

Ik denk toch dat je server een fout veroorzaakt in of de policy of in het script wat wordt gerunt bij het inlogge!

PS:Je heb een mail!

[SierdW]

Dat die policy niet start boeit me in de eerste instantie nog niet zoveel, ik irriteer me er nog het meest aan dat het zo verschrikkelijk lang duurt om in te loggen. Iemand een idee waar ik de time-out tijd kan instellen van de fout

Type gebeurtenis: Waarschuwing
Bron van gebeurtenis: Winlogon
Categorie van gebeurtenis: Geen
Gebeurtenis-ID: 1217
Datum: 6-9-2006
Tijd: 14:50:04
Gebruiker: n.v.t.
Computer: SERVER
Beschrijving:
Execution of GPO scripts has timed out and have been terminated.

Zie Help en ondersteuning op http://go.microsoft.com/fwlink/events.asp voor meer informatie.

Ik heb inmiddels in kunnen stellen dat de maximale tijd 60 seconden is om te wachten via:
Computer Configuration > Administrative Templates > System > Scripts > Maximum wait......

Het aanmelden duurt nu dus niet meer > 10 minuten, maar er zit nog steeds ergens een fout. Ik zal nu de Grouppolicy handmatig gaan dupliceren en dan alles nog maar een keer gaan proberen.

Ik vind het trouwens wel raar dat de group policy wordt overgenomen met gpupdate / force, en dat tijdens de login een time-out optreedt.

[ Voor 29% gewijzigd door SierdW op 06-09-2006 18:13 ]

[DennusB]

Hoelang doet hij er dan nu nog over om in te loggen?

[marquis]

Sorry, was even afwezig maar volg deze topic met grote intresse.
Die gpupdate/force laat niet het inlogscript draaien, alleen de policy wordt vernieuwd.
Als hij met inloggen dan op z`n plaat gaat, dan gaat het dus echt bij het inlogscript fout. (my 0,05 cents)

Edit: je doet toch nix met roaming profile, he?
PS: Om een GP te testen maak ik vaak even een nieuwe aan en link deze dan met de OU die ik wil testen. Je kunt namelijk meerdere GP`s op een OU toepassen, maar dat zal je wel weten.....
('k hou het in de gate, maar moet weer pleite....)

[ Voor 35% gewijzigd door marquis op 06-09-2006 20:25 ]

[alt-92]

SierdW schreef op woensdag 06 september 2006 @ 16:21:
Er zijn iets van 5 users, het is maar een klein netwerkje:) Ik krijg dus duidelijk het idee dat de server iets verkeerd doet, dat die niet die group policy weggeeft.

Welke GPO heb je het over?

[SierdW]

dennus2006 schreef op woensdag 06 september 2006 @ 19:55:
Hoelang doet hij er dan nu nog over om in te loggen?

Zo'n 30 seconden langer dan normaal...

marquis schreef op woensdag 06 september 2006 @ 20:17:
Edit: je doet toch nix met roaming profile, he?
PS: Om een GP te testen maak ik vaak even een nieuwe aan en link deze dan met de OU die ik wil testen. Je kunt namelijk meerdere GP`s op een OU toepassen, maar dat zal je wel weten.....
('k hou het in de gate, maar moet weer pleite....)

Ik werk wel met een roaming profile, maar dat werkt prima. Het profiel wordt wel geladen.

BackSlash32 schreef op woensdag 06 september 2006 @ 20:36:
[...]

Welke GPO heb je het over?

Ik heb het over de Default Domain Policy. De fout krijg ik bij alle gebruikers die in verschillende groepen zitten (waar trouwens ook weer verschillende Group Policies op van toepassing zijn).

Ik ben nu bezig een nieuwe Default Domain Policy aan te maken, en zal die, zodra ik die klaar heb testen. Misschien dat dat de oplossing is.

[ Voor 9% gewijzigd door SierdW op 06-09-2006 23:44 ]

[Question Mark]

TS: deze ook al gezien?

Computer Seems to Hang When You Log On

When you log on to a computer that uses a complex array of group policies, your computer may seem to stop responding (hang) at the "Applying your personal settings" screen after you supply your user name, password, and domain information.

A supported fix is now available from Microsoft...

[SierdW]

Nee die had ik nog niet gezien, echter blijft hij niet hangen op het scherm "Toepassen van persoonlijke instellingen" maar daarna. Hij heeft mijn profiel achtergrond al geladen, heeft al het "Login-geluidje" afgespeeld en blijft dan hangen. Omdat het probleem zich ineens op alle computers voordoet denk ik dus ook eerder dat er iets fout zit aan de serverkant en niet op client-niveau.

[Question Mark]

Je zou nog even debugging aan kunnen zetten op group-policy's en userprofiles om zo extra logging te krijgen van het applyen van group-policy's (en laden van profiles) op de clients:

How to enable user environment debug logging

[elevator]

Ik gok toch echt dat er iets mis is met je logon-script(s) - als je je logonscript nou eens renamed zodat deze niet meer gevonden kan worden, is het dan ook traag met inloggen?

Verder - Windows Clients >> Windows Servers en Software

[SierdW]

Question Mark schreef op donderdag 07 september 2006 @ 10:16:
Je zou nog even debugging aan kunnen zetten op group-policy's en userprofiles om zo extra logging te krijgen van het applyen van group-policy's (en laden van profiles) op de clients:

How to enable user environment debug logging

Ik zal daar eens naar kijken, bedankt!

elevator schreef op donderdag 07 september 2006 @ 10:38:
Ik gok toch echt dat er iets mis is met je logon-script(s) - als je je logonscript nou eens renamed zodat deze niet meer gevonden kan worden, is het dan ook traag met inloggen?

Verder - Windows Clients >> Windows Servers en Software

Naar mijn weten zijn mijn scripts prima, die worden ook wel goed doorlopen. Netwerk mappings worden prima gemaakt en de extra regel waarbij logon/logoff worden gelogd gaat ook goed. Op een of andere manier probeert ie de policy te refreshen na het inloggen, daar lijkt het mij tenminste op. Zodra ik de Default Domain Policy disable is de login procedure normaal en blijft hij niet hangen...

Logon:

code:

cls
@ECHO OFF
@TITLE Windows Server 2003 Aanmeldingsscript
@COLOR 1F
echo.
echo Windows Server 2003 Aanmeldingsscript voor %username% op %computername%
echo.
echo %username% wordt geregistreerd als online gebruiker...
copy \\server\online\online \\server\online\%username%@%computername%
echo.
echo LOGON %date% %time% Logon %username% op %computername% >> \\server\online\log.txt
echo Synchroniseren tijd met Servertijd
net time \\server /set /yes
net use * /delete /yes
echo Verbinden Y: met Myfiles Algemeen
net use y: \\server\myfiles
echo Verbinden V: met Download
net use v: \\server\download
echo Verbinden U: met Muziek
net use u: \\server\muziek

logoff:

code:

cls
@ECHO OFF
@TITLE Windows Server 2003 Afmeldingsscript voor %username% op %computername%
@COLOR 1F
echo.
echo Windows Server 2003 Afmeldingsscript voor %username% op %computername%
echo.
echo %username% wordt geregistreerd als offline gebruiker...
del \\server\online\%username%@%computername%
echo .LOGOFF %date% %time% Logoff %username% op %computername% >> \\server\online\log.txt
echo.
net use * /delete /yes
exit

De regels dat gebruikers als online/offline gebruiker worden geregistreerd werken ook prima, zo kan ik in een beveiligde dir via IIS zien welke gebruikers op welke computers zitten ingelogd

[Question Mark]

Je weet ook dat standaard users geen rechten hebben om de systeemtijd te wijzigen? Ook wordt de systeemtijd in een domain-omgeving al geregeld door de w32time service. Ik zou sowieso dat stukje uit je loginscript halen.

Op het moment dat een user aanlogt en een extra entry in de logfile schrijft, wordt deze file dan ook gelocked zodat andere users geen toegang hebben tot deze file?

[marquis]

Wij hebben ook een W2003 omgeving en hebben de netwerkschijven scripts via de accounts (logon scripts) lopen. Zou dat niet wat minder ontlasten van de GPO? Die zit nm aan een bepaalde tijd vast om dat hele gebeuren uit te voeren, dat wat je nu op 60 sec heb gezet.

Ook wordt de systeemtijd in een domain-omgeving al geregeld door de w32time service. Ik zou sowieso dat stukje uit je loginscript halen.

Volgens mij niet standaard, dit moet je ook meegeven maar kun je op een andere plek doen in de GP. Onder computer configuratie --> beheersjablomen --> windows-onderdelen --> windows time -service --> rtijdsprovider.

Edit: Question Mark, bedankt voor je verbetering.

[ Voor 45% gewijzigd door marquis op 07-09-2006 13:27 ]

[elevator]

SierdW schreef op donderdag 07 september 2006 @ 12:12:
Naar mijn weten zijn mijn scripts prima, die worden ook wel goed doorlopen.

Maar rename die nou gewoon eens om het uit te sluiten? Wat is nou meer werk - theoretisch gaan beredeneren en daar fouten in kunnen maken, of iets bewijzen door het te testen?

Zodra ik de Default Domain Policy disable is de login procedure normaal en blijft hij niet hangen...

In het algemeen zou ik je aanraden je default domain policy niet te bewerken maar gewoon een extra policy te maken

[SierdW]

* SierdW is nu helemaal de weg kwijt..

Het probleem is verholpen. Ik weet niet hoe het kan, maar goed.

Ik heb zoals elevator opperde de naam van het logon.bat veranderd naar logon1.bat en toen aangemeld. Tot mijn verbazing ging alles toen ineens goed. Vervolgens heb ik de client laten rebooten en de naam van het logon script weer veranderd in logon.bat en alles werkt weer. Ik weet niet wat nu het probleem is geweest, maar het is verholpen.

Ik heb nu nog de volgende melding in het logboek:

Type gebeurtenis: Fout
Bron van gebeurtenis: Userenv
Categorie van gebeurtenis: Geen
Gebeurtenis-ID: 1091
Datum: 7-9-2006
Tijd: 13:06:57
Gebruiker: NT AUTHORITY\SYSTEM
Computer: PC2
Beschrijving:
De groepsbeleidsextensie van de client Internet Explorer Branding kan geen RSoP-gegevens (Resulterende verzameling beleidsregels) in het logboek registreren. Controleer of er al eerder fouten zijn gerapporteerd door deze extensie.

Zie Help en ondersteuning op http://go.microsoft.com/fwlink/events.asp voor meer informatie.

[Question Mark]

marquis schreef op donderdag 07 september 2006 @ 12:54:
Volgens mij niet standaard, dit moet je ook meegeven maar kun je op een andere plek doen in de GP. Onder computer configuratie --> beheersjablomen --> windows-onderdelen --> windows time -service --> rtijdsprovider.

Da's om een externe time-source op te geven, bv. voor je PDC Operations Master. Alle overige servers en clients syncen dan automatisch met deze server via de standaard hiërarchie.

Windows Time Service Technical Reference

Every computer that is running the Windows Time service uses the service to maintain the most accurate time. In most cases, it is not necessary to configure the Windows Time service. Computers that are members of a domain act as a time client by default.

By default, Windows-based computers use the following hierarchy:
• All client desktop computers nominate the authenticating domain controller as their in-bound time partner.
• All member servers follow the same process as client desktop computers.
• Domain controllers may nominate the primary domain controller (PDC) operations master as their in-bound time partner but may use a parent domain controller based on stratum numbering.
• All PDC operations masters follow the hierarchy of domains in the selection of their in-bound time partner.

SierdW schreef op donderdag 07 september 2006 @ 13:12:
Ik heb nu nog de volgende melding in het logboek:
[...]

Eventid.net --> 1091

[ Voor 8% gewijzigd door Question Mark op 07-09-2006 13:19 ]