Huebner.IE

Etwas verspätete Antworten: - Clientinstallation: die ältesten mit XP ohne SP und dann inkrementell auf SP3 hochgezogen, der neueste von einer orig. XPP CD-ROM mit SP3 (also kein Eigen-Slipstream), Domäneneinbindung über Systemsteuerung, d.h. nicht connect-Website vom SBS - Virtuelles XP auf W7: auf dem W7-Rechner läuft sogar VPC2007 mit XPP SP3 für eine Abrechnungssoftware, die unter W7 partout nicht will. Morgen baue ich noch zwei W7 Rechner auf, ggf ergibt sich da die Chance 1.) die W7-geht-immer-These zu verifizieren und 2.) ein frisches virtuelles XP anzutesten - Server-IP wurde nicht geändert, DNS nicht angefasst, Auflösungen funktionieren soweit ich getestet habe, die genannte Zone existiert und ist "bevölkert". Auf dem DC gibt es keine Log-Einträge wenn sich die Clients anmelden. - DFS- und abhängige Dienste laufen auf den Clients Wie gesagt, morgen bin ich in anderer Sache an diesem Netzwerk, dann kann ich vielleicht neue Informationen erzeugen.

Ja, definitiv. Mehrfach geprüft, auch andere Konstellation (jeweils zwischen SBS und Client abgeglichen) - keine Chance. Ich habe den Testclient und den funktionierenden W7-Client nun in die SBSComputers gezogen und die GPOs, auf die es ankommt, dorthin verknüpft, inkl. derer für WSUS. Ergebnis: Der Testclient wirft nach wie vor die Meldungen, während der W7 brav in der WSUS-Konsole auftaucht.

Nein, gibt es nicht. Sobald ich für einen der XP-Clients eine verlinke, wird die erste in der Liste abgebrochen und deren GUID in den berühmten Meldungen dokumentiert. Die gpt.ini aller GPOs lässt sich im Explorer über den UNC-Pfad (auch mit \\domäne.local\) problemslos einsehen.

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!

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.

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... Darum sind die Links unter der Domain nun ja auch deaktiviert, dass sie dort lagen, ist ein Relikt aus der Zeit vor meiner Zeit ;) So ist es auch. 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.

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.

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.

@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.

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?

IPv6 ist aktiviert. Der BPA meckert lediglich, dass der Gastuser bestimmte Dinge nicht darf und greift das geloggte Event 10016 nochmal auf. Die Berechtigungen für den IIS WAMREG habe ich aber schon korrigiert. Der Server hat sich übrigens schon mal auf die Nase gelegt, und zwar während des letzten großen Exchange-Updates. Danach war auf einmal die Datei- und Druckerfreigabe komplett inaktiv.

Als er rund lief -also die 14 Tage vor dem Malheur - fand der das System ganz toll. Will heissen: keine Probleme. Im aktuellen Zustand muss ich ihn erst noch ausführen, habe gerade erst die Remote-Zugangsdaten bekommen.

Hallo zusammen, ich bin im Moment etwas ratlos ob des scheinbaren Eigenlebens, welches ein frisch aufgesetzter W2k8 SBS zeigte, der mir gerade präsentiert wurde. Nachdem er zwei Wochen problemlos im Probebetrieb lief, konnte man sich von einer Minute auf die andere nicht mehr an Exchange anmelden. Ein Blick ins Anwendungsprotokoll zeigte: lange vor dem Crash alle 15min. eine ID 2114 (MSExchange ADAccess, verschiedene Komponenten melden hier einen Fehler bei der Topologieerkennung). Unmittelbar beim Ausfall dann eine ID 2501, gefolgt von 1003 (keine Verbindung zum AD), wiederholt im Wechsel mit "keine Antwort (...) DC-Servern". Beim daraufhin angesetzten Neustart stand die Maschine dann gut 2 Stunden auf "Computereinstellungen werden übernommen". Daraufhin wurden die zwei bekannten Einstellungen am NG TCP/IP Stack vorgenommen und die Netzwerkkartentreiber aktualisiert. Ergebnis: keins, wieder 2 Stunden waren. Die daraufhin gestarteten Updates hingen dann einen halben Tag auf 67% beim 3. von 3 Schritten fest; erst das Trennen des Netzwerkkabels hat hier binnen Sekunden zur Fertigstellung geführt. Danach hing er dann beim Herunterfahren fest und wurde brutal resettet. Ergebnis hier: im abgesicherten Modus verweigert er die Anmeldung des zuvor noch funktionierenden lokalen Admins. Also nochmal normal neu gestartet und nach 10 Minuten lief dann alles bis auf DNS, Exchange Datenspeicher und den Connectoren. Diese liessen sich manuell starten und das Ding tut so als wäre nichts gewesen. Aber wann "knallt" es das nächste Mal? So ist das ein sehr unbefriedigender Zustand. Neben dem Versuch, die Häufung der Protokolleinträge nachzuvollziehen hat dcdiag keinen Fehler gemeldet; eine Domänenanmeldung der Clients war während des vermeintlich nicht verfügbaren DC-Servers (lt. Exchange-Fehlermeldung) auch möglich. Das Ding ist zum Glück nicht unter meinen Fittichen, aber ich möchte diese Erfahrung gerne nutzen, mehr Informationen über das jüngste Kind der Serverfamilie zu bekommen. Hat jemand das beschrieben Szenario schon hinter sich und eine Idee, wo hier etwas im Argen sein könnte?

So, auf dem Server (SBS2003 SP2, IE7) habe ich nun den KB963027 wieder deinstalliert und kann wieder auf das Companyweb zugreifen. Die Registryänderung bzgl. der Loopback-Geschichte hat nichts gebracht. Wenn das nun auf den Clients auch seinen Zweck erfüllt, soll dem so sein. ABER: ich kann das Companyweb von einem VPN-Client leider überhaupt nicht erreichen, auch nicht über den vielfach genannten weg https://server:444; auch auf dem Server nicht. Wo ist dieser Virtuelle Host oder was immer das bei IIS ist (genauso wie das Routing von http://companyweb auf den entsprechenden Folder) eigentlich konfiguriert? Der Weg über den explizit anzugebenden Port wäre für die VPN-Worker ja ok, v.a. wenn ich ihn in der Startseite der Firmenhomepage anpasse. Jemand 'ne Idee...?

Stimmt, und um das noch mal zu betonen: was bisher gesagt wurde heisst zusammengefasst, Du installierst einen "Router" deiner Wahl in einer zusätzlichen VM, gibst diesem ein NIC mit einer IP aus dem Firmennetz und weitere (echte oder virtuelle, die nur lokal innerhalb der Virtualisierung sichtbar sind) und erschlägst damit Routing, Sicherheit usw. Der ESXi selbst kann Dir das nicht abnehmen. Übrigens bin ich von der Performance des ESXi durchaus begeistert. Wir hatten vor einem halben Jahr die Idee, einen VMWare Server unter Linux aufzusetzen und darin zwei Windows-Maschinen (W2k Server, XP Pro) für ein Bibliotheksmanagment aufzusetzen. Ergebnis: grottig. Die Fileservice-Performance vom W2k war schlecht, der Internet-Katalog unter XP dito. So standen dann also 6 Monate lang wieder zwei Maschinen im Schrank, bis ich auf derselben Maschine (kleiner Proliant, E2160 CPU, 4GB) den ESXi installiert habe - die gefühlte Leistung des Netzes toppt nun durchaus die der Lösung aus einem P4 2,4GHz als Fileserver plus Athlon-XP-Kiste für den Webserver. Die schnelle "Netzwerk"-Verbindung zwischen den Maschinen reisst einiges.