1030 und 1058, eine neue Variante

[Huebner.IE 10]

Hallo zusammen,

 

nachdem ich alle persönlich bekannten ITler damit zum Wahnsinn getrieben habe frage ich nun auch hier einmal.

 

Ein 2k3-SBS (SP2) erzeugt auf allen XP-Clients 1030 und 1058-Einträge der bekannten Art: die Verarbeitung der GP wird abgebrochen, weil nicht darauf zugegriffen werden kann.

 

Im Gegensatz zu den häufig beschriebenen Probleme kann ich die jeweilige gpt.ini im Windows-Explorer des jeweiligen Clients über \\domäne.local\SYSVOL\domäne.local\Policies\{GUID}\gpt.ini aber problemlos öffnen!

 

Wenn ich die angemeckerte GPO in der Reihenfolge verschiebe, ist es die dann erste, die zum Abbruch führt.

 

Das Problem tritt auf dem einzigen Windows 7 Professional Rechner NICHT auf, dort werden alle Gruppenrichtlinien einwandfrei angewendet.

 

Alle auffindbaren KB-Einträge habe ich gelesen, alles probiert - SMB-Einträge geändert, MUP-Cache gepurged, diverse Einträge in die Client-hosts geschrieben (DNS-Auflösung funktioniert aber einwandfrei), DFS-Dienst geprüft, Datei- und Druckerfreigaben geprüft.

 

Bisher ist das Problem wohl nicht aufgefallen, weil die GPs nicht aktiv genutzt wurden, nun werden aber Updates GPO-gesteuert verteilt und schon war das Problem akut.

 

Hat dazu noch jemand eine Idee?

[dmetzger 10]

Handelt es sich bei den Clients um XP SP3?

[Sunny61 773]

Ein 2k3-SBS (SP2) erzeugt auf allen XP-Clients 1030 und 1058-Einträge der bekannten Art: die Verarbeitung der GP wird abgebrochen, weil nicht darauf zugegriffen werden kann.

 

Ein SBS kann keine Einträge auf dem Client erzeugen. Der Client hat ein Problem bei der Übernahme der Einstellungen.

 

Bisher ist das Problem wohl nicht aufgefallen, weil die GPs nicht aktiv genutzt wurden, nun werden aber Updates GPO-gesteuert verteilt und schon war das Problem akut.

 

Erstell eine neue OU und verlinke keine GPO darauf, außer der Default Domain Policy. Client dorthin verschieben, gpupdate, neu starten. Werden immer noch die beiden Einträge erzeugt?

[Huebner.IE 10]

@metzger: ja, durch die Reihe XP SP3.

 

@sunny: sorry für die wirklich schwammige Formulierung. Erzeugt werden die Einträge im Event Log natürlich nicht vom SBS. Aber Du weisst, was gemeint war.

 

Deinen Hinweis greife ich auf und werde morgen mal remote auf einen der fraglichen Clients schauen, ob beiden Einträge wie gehabt auftreten.

[dmetzger 10]

Ein zusätzlicher Vorschlag, anschliessend an Sunny61: ausschliesslich Link des betreffenden GPO deaktivieren -> gpupdate /force auf XP SP3-Client und diesen neu starten. Werden immer noch die beiden Einträge erzeugt?

 

Falls ja: GPO neu erstellen und testen.

 

Ich nehme an, ihr habt mehr als nur dieses eine GPO plus die beiden Standard-GPO für Domäne und Domänencontroller?

[Huebner.IE 10]

Von hinten nach vorne: wenn ich die Reihenfolge ändere ODER den Link auf die jeweils beanstandete GPO deaktiviere wird immer die erste zu übernehmende GP in der Fehlermeldung erwähnt.

Anders gesagt: es betrifft JEDES GPO, immer das, was in der Priorität oben steht und als erstes übernommen werden soll führt zu Fehlermeldung und Abbruch der Verarbeitung.

 

Und zum Tipp von Sunny: ich habe alle Links, die direkt unter der Domäne lagen, deaktiviert, alle anderen Maschinen aus Computers in SBSComputers gezogen und die GPO-Links entsprechend neu gesetzt und den einen Test-Client in eine neu angelegte OU verschoben. Auch dort führt der Versuch der GP-Verarbeitung zum bekannten Verhalten.

[Sunny61 773]

Und zum Tipp von Sunny: ich habe alle Links, die direkt unter der Domäne lagen, deaktiviert, alle anderen Maschinen aus Computers in SBSComputers gezogen und die GPO-Links entsprechend neu gesetzt und den einen Test-Client in eine neu angelegte OU verschoben. Auch dort führt der Versuch der GP-Verarbeitung zum bekannten Verhalten.

 

In Computers sollten eigentlich keine Clients abgelegt sein. Dafür gibts ja die OU SBSComputers. Hast Du bei dem Testclient in der TestOU eine neue GPO erstellt oder die alten verwendet? Probiers doch mal mit einer neuen. Auch würde ich den Client aus der Domain nehmen, das Konto im AD löschen und nach einem Neustart den Client wieder aufnehmen.

 

Sind die Treiber für die NIC auf den XP-Clients aktuell? Was ist an weiterer Technik zwischen Server und Client? Switch? Hub? Hast Du es schon mit einem nackten XP-Client probiert? Oder auch via msconfig im Systemstart alles deaktvieren und auch die Nicht-MS-Dienste deaktivieren.

 

SMB-Signing gem. BestPraxis in den beiden Default Domain Policys eingestellt? Auf einem XP-Client die Einstellungen notfalls per Hand machen. SMB Signing - Einstellungen für: Kommunikation digital signieren

[Huebner.IE 10]

Das ging ja schnell :)

 

Dass die Maschinen nicht in den Sub-OUs von MyBusiness liegen ist mir schon lange ein Dorn im Auge. Die Clients wurden wohl nicht per connectcomputer ins Netz genommen, sondern über den Domänenbeitritt in der Systemsteuerung.

Dem Windows 7 Client macht das auch nichts, der hat connectcomputer nie zu sehen bekommen und wendet die GP trotzdem brav an.

 

Der Hinweis mit dem "nackten XP" ist vermutlich der beste Weg, bisher hatte ich gehofft, darauf verzichten zu können, aber dem ist wohl nicht so.

 

Die SMB-Einstellungen sind wie Du sagst angepasst worden (das ist ja der erste und meistgepostete Hinweis zu dem 1030/1058 Problem), ohne dass es etwas geändert hätte. Sowohl auf dem SBS als auch dem Client, an dem ich im Moment teste, sind die Einstellunge angeglichen.

 

Die NIC-Treiber sind zumindest auf dem besagten Client aktuell, frisch von Intel geladen. Technik zwischen Clients und SBS ist ein Gigabit-Switch von Cisco (Layer 2, da sollte also kein Eingriff erfolgen).

 

Wie gesagt, der Zugriff vom Windows Explorer aus auf die gpt.ini verläuft reibungslos, auch mit \\domänname.local\. Was ist eigentlich der Unterschied zwischen dem Zugriff? Mit welchem Konto lädt Windows die GP beim Start? Dem des sich anmeldenden Computers?

 

Ergänzung: nein ich habe das GPO nicht neu erstellt, sondern das bestehende in die neu angelegte OU verlinkt. Probiere aber auch noch den anderen Weg.

[Sunny61 773]

Dass die Maschinen nicht in den Sub-OUs von MyBusiness liegen ist mir schon lange ein Dorn im Auge. Die Clients wurden wohl nicht per connectcomputer ins Netz genommen, sondern über den Domänenbeitritt in der Systemsteuerung.

 

Dann kann man die Clients aber manuell verschieben. Ist ja auch nicht so viel Arbeit. ;)

 

Dem Windows 7 Client macht das auch nichts, der hat connectcomputer nie zu sehen bekommen und wendet die GP trotzdem brav an.

 

Weil die GPOs alle auf der Domain Ebene abgelegt sind. Ich persönlich würde das nicht machen. Lieber alle GPOs auf die SBS-OUs verlinken. Dort müssen sie auch wirken, nicht auf der kompletten Domain.

 

Der Hinweis mit dem "nackten XP" ist vermutlich der beste Weg, bisher hatte ich gehofft, darauf verzichten zu können, aber dem ist wohl nicht so.

 

Lässt sich ja relativ schnell mit einem alten Gerät testen.

 

Die SMB-Einstellungen sind wie Du sagst angepasst worden (das ist ja der erste und meistgepostete Hinweis zu dem 1030/1058 Problem), ohne dass es etwas geändert hätte. Sowohl auf dem SBS als auch dem Client, an dem ich im Moment teste, sind die Einstellunge angeglichen.

 

OK.

 

Wie gesagt, der Zugriff vom Windows Explorer aus auf die gpt.ini verläuft reibungslos, auch mit \\domänname.local\. Was ist eigentlich der Unterschied zwischen dem Zugriff? Mit welchem Konto lädt Windows die GP beim Start? Dem des sich anmeldenden Computers?

 

Überprüf doch auch die Zugriffsrechte auf das Sysvol. Die Authentifizierten Benutzer sollten Leserechte haben, nicht mehr.

 

Ergänzung: nein ich habe das GPO nicht neu erstellt, sondern das bestehende in die neu angelegte OU verlinkt. Probiere aber auch noch den anderen Weg.

 

Genau, nicht das die alten GPOs einen Fehler haben.

[Huebner.IE 10]

Dann kann man die Clients aber manuell verschieben. Ist ja auch nicht so viel Arbeit. ;)

 

Na wenn das mal das selbe ist wie neu anlegen ;)

Ich habe sie bisher ja manuell verschoben, um sicher zu gehen, dass das nicht doch das Problem ist, werde ich den Test-Client mal über die SBS-Webpage anmelden.

Nächste Woche nehme ich mir mal einen Rechner mit und teste das, muss ja mal fertig werden...

 

Weil die GPOs alle auf der Domain Ebene abgelegt sind. Ich persönlich würde das nicht machen. Lieber alle GPOs auf die SBS-OUs verlinken. Dort müssen sie auch wirken, nicht auf der kompletten Domain.

 

Darum sind die Links unter der Domain nun ja auch deaktiviert, dass sie dort lagen, ist ein Relikt aus der Zeit vor meiner Zeit ;)

 

Überprüf doch auch die Zugriffsrechte auf das Sysvol. Die Authentifizierten Benutzer sollten Leserechte haben, nicht mehr.

 

So ist es auch.

 

Genau, nicht das die alten GPOs einen Fehler haben.

 

Ich habe nun ein neues GPO angelegt und als einziges mit einem Client verknüpft und prompt ist es das, bei welchem der Abbruch erfolgt.

Auf dem W7 Rechner übrigens wieder mal nicht, der frisst die GP.

Auch mit dem neuen Test-GPO.

[dmetzger 10]

Ich glaube nicht, dass es in diesem Fall eine Rolle spielt, wie die Clients in die SBS-Domäne eingefügt wurden und ob die Computerobjekte in der OU-Struktur MyBusiness positioniert sind oder in einer anderen, manuell erzeugten OU, auf die die GPO direkt oder durch Vererbung wirken (so lange es nicht die OU für Domänencontroller ist oder der Container "Computers" an Stelle einer OU).

 

Es spielt auch keine Rolle, ob die fraglichen GPO direkt mit der Domäne verknüpft sind oder direkt mit der OU, in der die fraglichen Computerobjekte residieren. SBS 2003/2008 erzeugen automatisch mehrere GPO auf Domänenebene, deren Fokus bei Bedarf mittels Sicherheitsfilterung und/oder WMI-Filter definiert ist. Das tun wir auch in viel grösseren Umgebungen täglich ohne Event IDs 1030 und 1058.

 

Was mich interessiert:

 

- Hat der SBS zwei Netzwerkkarten?

- Werden die Fehler auch mit gpupdate /force protokolliert?

- Was sagt gpresult?

 

Mich macht der Windows 7-Client stutzig.

[Sunny61 773]

Ich habe sie bisher ja manuell verschoben, um sicher zu gehen, dass das nicht doch das Problem ist, werde ich den Test-Client mal über die SBS-Webpage anmelden.

 

Ich hab bisher noch keinen Client via SBS-Website hinzugefügt und es hat bisher immer funktioniert.

 

Nächste Woche nehme ich mir mal einen Rechner mit und teste das, muss ja mal fertig werden...

 

Jepp, hast Du schon mal einen Client neu installiert?

 

Darum sind die Links unter der Domain nun ja auch deaktiviert, dass sie dort lagen, ist ein Relikt aus der Zeit vor meiner Zeit ;)

 

Wie dmetzger schon schrieb gibts ja die SBS-GPOs, die auf Domain Ebene verlinkt sind. Die fasse ich auch nicht an. Selbst erstellte GPOs verknüpfe ich nur direkt auf die passende OU.

 

Ich habe nun ein neues GPO angelegt und als einziges mit einem Client verknüpft und prompt ist es das, bei welchem der Abbruch erfolgt.

Auf dem W7 Rechner übrigens wieder mal nicht, der frisst die GP.

Auch mit dem neuen Test-GPO.

 

Hmm, hast Du den Client auch via MSCONFIG von Ballast befreit? Mir dünkt es ist irgendein zusätzlicher Dienst der dir das Leben schwer macht.

[Huebner.IE 10]

Erstmal danke an euch beiden Haupt-Mitdenker, meine beiden Kollegen haben auch schon die Stirn gerunzelt ob dieses Problems.

 

Vorab: auf einem alten länger stillgeleten Client sind die Meldungen nicht im Log.

Zwischenzeitlich ist das CRM upgedatet worden (Dynamics 3 auf 4), der ausführende Techniker wurde natürlich gefragt, kann sich aber keinen Zusammenhang vorstellen. Nun gut, das wird sich erst be- oder widerlegen lassen, wenn die Ursache gefunden ist.

 

@metzger:

- nein der SBS hat nur einen NIC.

- gpupdate /force auf dem Client verursacht dieselben Einträge, damit habe ich zum Schluss nur noch getestet, als ich Stück für Stück jedes GPO einzeln geprüft habe (mit bekanntem Ergebnis - für jedes wird die Meldung generiert)

- gpresult lässt die nicht angewandten GPOs unerwähnt

 

Dass der W7 keine Probleme macht wundert mich auch, nächste Woche gibt es evtl Gelegenheit das eine oder andere zu verifizieren, da ein Client ersetzt wird, nur die Entscheidung fürs OS steht noch nicht fest.

 

@sunny

- es werden ja auch die vom SBS angelegten GPOs bemeckert

- ja ich habe einen Client in einer VM (MSVPC) testweise installiert und keinerlei Drittanbieter-Software drauf, nur Win XP SP3. Selbes Ergebnis - nur gebe ich da gerade nicht so viel drauf, da auch NIC-Treiber schon als Ursache ausgemacht worden zu sein scheinen

- die Maschine, auf der der Fehler zum ersten Mal bemerkt wurde ist relativ frisch aufgesetzt mit XP SP3, allen Updates und Office 2003, zum Testzeitpunkt war an Drittanbietersoftware nur der Firefox drauf, noch keinerlei Druckertreiber, CRM usw.

- alle Nicht-MS-Dienste deaktiviert -> keine Änderung

 

Es betrifft vom alten Dell mit Sockel 423-P4 bis zum Core2Quad alle Systeme gleichermaßen, verschiedenste NICs natürlich.

[Sunny61 773]

Dass der W7 keine Probleme macht wundert mich auch, nächste Woche gibt es evtl Gelegenheit das eine oder andere zu verifizieren, da ein Client ersetzt wird, nur die Entscheidung fürs OS steht noch nicht fest.

 

Das mit dem W7 verwundert mich allerdings auch sehr.

 

- alle Nicht-MS-Dienste deaktiviert -> keine Änderung

 

Schnapp dir doch auch Autoruns und prüf damit auf Treiber deren Dateien nicht vorhanden sind.

 

Es betrifft vom alten Dell mit Sockel 423-P4 bis zum Core2Quad alle Systeme gleichermaßen, verschiedenste NICs natürlich.

 

Mit den einzustellenden Geschwindigkeitswerten hast Du schon gespielt? Fehlermeldungen auf dem SBS im Eventlog?

[Huebner.IE 10]

Nein, mit den Geschwindigkeiten habe ich nicht gespielt, die alten Clients sind alle mit 100Mbit/s angebunden, der XP-Client, bei dem es zuerst auffiel und der W7 Rechner mit Gigabit.

Autorun kann ich auch mal durchforsten, allzu viel Hoffnung habe ich dabei aber nicht ... trotzdem, wird gemacht!