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.

MIt IE7 das selbe Problem. Nutzer, die sich vom Client aus anmelden können, können es am Server ebenfalls nicht. Drei mal Passwortabfrage, dann 401.1. Auf den Clients funktioniert es mit IE6 und IE7 für einige User, für andere (u.a. den Chef) nicht. Notfalls muss ich mein Notebook übers VPN mal in die Domäne nehmen und versuchen, nur das Client-Anmeldeproblem in den Griff zu bekommen, aber lästig finde ich es schon (mich im Urlaub mit sowas rumzuärgern vor allem... aber in der ersten Woche danach hätte ich erst recht keine Zeit)

Moin, ich ärgere mich gerade mit einem SBS 2003 herum (aktueller Patchstand). Zum einen kann man sich lokal auf dem Server nicht am companyweb anmelden (das übliche Problem, aber der Hotfix aus der KB961143 geht ja leider beim deutschen SBS nicht). Aber leider funktioniert auch die Anmeldung von einigen Clients nicht. Auf den ersten Blick könnten das genau die Benutzer sein, die bereits vor der CRM 3.0 Installation schon bestanden, während die neuen Mitarbeiter problemlos ins CW kommen. Es liegt nicht an den Browsern auf den Clients-PCs, sondern hängt nur am Benutzeraccount. Hat jemand sowas schon mal gehabt und kann mir einen Hinweis geben, wie man es im Hintergrund lösen kann, ohne nach jedem Schritt die User erfolglos probieren lassen zu müssen? Wäre das Anmeldeproblem auf dem Server lösbar, könnte ich ja wenigstens über den Remote Desktop mit zwei Benutzeraccounts experimentieren, aber so bin ich ein wenig machtlos. Gruß Stefan

Hallo zusammen, ich habe auf einem 2k3 SBS das viel diskutierte Problem, dass mehrfach am Tag ein Schwall der bekannten Meldung mit der Event-ID 11 das Syslog überschwemmt. Es werden dabei grundsätzlich die Konten host, http und cifs protokolliert. Mit ldifde konnte ich keine exakten Duplikate dieser Konten ausmachen, wohl aber welche mit ähnlichen Namen. Daher wäre die erste Frage, worauf es überhaupt ankommt, wie gleich müssen die Principals sein, um zur fraglichen Meldung zu führen? Gibt es noch einen anderen Weg, dem Problem auf die Schliche zu kommen? Und zu guter letzt: kann ein Fehler bei der Installation von Dynamics CRM dazu geführt haben? Ich habe sehr viele Probleme rund um dieses Programm, zB. auch die ständigen Log-Einträge des CRM-Exchange-Routers. Die Berechtigungen sind soweit ich es bisher prüfen konnte aber richtig. Vielleicht fällt dazu ja auch jemandem was ein...? Gruß Stefan

Hallo alle, dieser SBS 2003 treibt mich zum WAHNSINN! Alles neu installiert mit geslipstreamter CD (SP2+Medley "Raid"-Treiber) - wunderbar, nur lässt sich der Serververwaltungskram dann nicht installieren (oder doch - habe es nicht geschafft) Also nochmal plattgemacht, Treiber mit F6 nachgeladen und von originaler prä-SP1 CD installiert. Im nächsten Schritt Domänendaten eingegeben, Neustart, Fehler 0xc00002e1. Syslog platzt vor NTDS-Fehlern aus allen Nähten. Torture-Test unter Windows, Prüfung des Platten-Spiegelsatzes und des Speichers einschl. Austausch gegen andere Module ohne Ergebnis. Hat da jemand spontan eine Idee?

Hallo, ich habe seit einigen Wochen ein Problem mit einer externen 1394-Festplatte an einem W2k-Rechner (eigentlich Server, aber das Problem tritt lt. Google wohl bei jedem 2k-Derivat und XP auf). Wenn ich testweise ein paar Gigabytes darauf kopiere oder nur etwas warte, funktioniert das Beenden des Gerätes immer. Wenn sie einen Tag gelaufen hat (nachts werden die Daten, die ich beim manuellen Test auch kopiert habe, per Batchdatei übertragen) lässt sie sich aber nicht mehr abmelden. Die Fehlermeldung lautet wie üblich " Das Gerät "Standardvolume" kann zurzeit nicht beendet werden " Ich habe bisher den Recycler für dieses Laufwerk abgeschaltet, ebenso den Indexdienst. Der Process Explorer zeigt keine offenen Handles auf das Laufwerk. Am USB-Anschluss ändert sich an dem Verhalten nichts. Irgendwelche Punkte, die ich noch einmal näher betrachten sollte? Danke!

Hallo zusammen, ich habe leider einen Kunden, bei dem in längeren Zeitabständen (>10Tage bis Monate) W2k Server crasht. Der Bluescreen verrät dann, dass ein Hardwareproblem vorzuliegen scheint (NMI: Parity Check / Memory Parity Error). Konfiguration: ML110 G4, Xeon 3040 (Dual Core 1.86GHz), versch. Speicherausbau s.u., 2x160GB SATA-I im Raid1 Verbund, DDS4-DAT am internen USB2.0, W2k Server und SQL Server 2000 auf letztem Updatestand Inzwischen habe ich: - die 2. Installation laufen, auf einem neuen Satz SATA-Platten, - die originalen 2x512MB HP-DDR2-Riegel gegen andere HP (512MB, 1GB) getauscht, half nichts, im Moment sind Kingston Intel-certified Riegel drin, alle -HP und Kingston- PC5300 mit ECC - die Installation auf einer anderen, baugleichen Maschine getestet - selbes Problem. Gibt es irgendwelche bekannten Probleme mit W2k oder sonst irgendwelcher Software im Zusammenhang mit dem ML110, speziell dem G4, speziell dem Xeon 3040, dem Intel E3000-Chipsatz,....? Heute habe ich beim Speichertausch nochmal den 2. Kern und Speedstep im BIOS abgeschaltet, nach 20h neige ich zu Verzweiflungstaten. Die Testmaschine, die sich ebenfalls auf die Nase gelegt hat, hat soeben wieder ihren Dienst als VMware-Host unter Linux angetreten, sowohl die Linux- als auch die XP Pro VM laufen auf vollen Touren und ich zweifle auch nicht daran, dass sie das auch die nächsten Wochen brav tun werden. Ideen? Danke!

Hallo zusammen, wir alle kennen die XP-Meldung dass die Registry-Datei SYSTEM beschädigt oder nicht vorhanden ist. Und wir kennen auch alle den KB-Eintrag Q307545, der das Vorgehen beschreibt. Nun habe ich hier gerade einen Patienten, der nach Einspielen der Kopie im Repair-Ordner dummerweise immer noch meint, eine fehlende oder beschädigte SYSTEM-Datei zu haben! Kann mir jemand den Mechanismus dieses Fehlers und ggf. weitere Ursachen ausser einer wirklich beschädigten Datei erklären? Die XP-Installation liegt auf multi(0)disk(0)rdisk(1)partition(0), vulgo 1. Partition auf Festplatte D. Danke!

Eben dieses, wireshark (ist ja jetzt vermutlich verboten, aber wie sang Georg Kreisler einst im Duett: "wir sind doch alle, alle terroristen"). Broadcasts nein, wins-Anfragen nein, DNS-Anfragen minimal. Nicht Verdächtiges. Ob sich das im Falle des Stillstands irgendwie ändert - ? Müsste mal längere Zeit mitprotokollieren.

Das Programm sehe ich mir mal an, bin bei MSSQL sozusagen ins kalte Wasser gesprungen, und eigentlich sollte der auch vom WaWi-System-Hersteller betreut werden. Bei anderen RDBMS (MySQL, PostgreSQL, notfalls Oracle oder DB2) wäre ich vielleicht schon einen Schritt weiter, wenngleich die auch alles andere als mein täglich Brot sind. Dass der Server irgendwas vermisst ist unwahrscheinlich. Das Problem bestand ja schon auf dem alten 1GHz-PIII und ist mehr oder weniger plötzlich aufgetreten (allerdings vor so langer Zeit, dass keiner mehr weiss, was u.U. kurz davor passiert sein könnte), nun steht da ein frisch aufgesetzter Dual-Core-Xeon, bei dem sich selbiges Problem sofort fortgesetzt hat. Ich habe auf den Clients schon alle Netzwerkkarten auf Vollduplex 100Mbit/s eingestellt, den Durchsatz jedes Clients zum Server bidirektional bei verschiedenen Paketgrößen über mehrere Minuten gemessen (konstant knapp 12MByte/s), den Switch getauscht, einen alten ISDN-Router vom Netz genommen... Als nächstes werde ich neben der Softwareebene noch mal den Server in den Verkaufsraum umstellen, da das Kabel von dort zum Lagerraum quer durch eine Baustelle läuft... Im worst case darf halt eine Zeit lang nur ein Client ans Netz (Kasse sinnigerweise) und die anderen nur bei dringendem Bedarf hochgefahren werden, wenn die Netzwerk-Trafficanalyse nichts hergibt.

Nun das nächste W2k-Problem (habe im Windows-Allgemein-Forum schon ein Problem beschrieben). In einem W2k-Netz (Server als AD-PDC, 7 Clients) treten von Zeit zu Zeit (mal nicht merkbar, mal zig-mal am Tag, Lastabhängigkeit nicht nachvollziehbar) erhebliche Stillstände auf, i.d.R. steht dann für 30-40 Sekunden alles still, danach läuft's ohne Meldung weiter als wäre nichts gewesen. Ich fürchte, diese sporadischen Latenzen betreffen nur den MSSQL-2000-Server, der auf dem PDC läuft, denn Versuche, große Dateien hin- und her zu kopieren zeigten keine Auffälligkeiten, die Messung des Netzwerkdurchsatzes war ebenfalls im grünen Bereich für ein geswitchtes 100MBit/s Netz. Ich habe sämtliche Netzwerkkarten inzwischen auf Vollduplex konfiguriert, den Switch getauscht, dem Netzwerkverkehr zugesehen, ob da irgendwas herumschwirrt, was da nicht hingehört - bisher alles Fehlanzeige. Es war bisher auch nicht möglich, einzugrenzen, ob es immer ein bestimmter Client ist, der den Stillstand initiiert, da während der Tests natürlich keine Fehler aufgetreten sind. Ach so: der Server wurde mittlerweile von PIII 1GHz auf einen Dual Core Xeon upgegraded, nun mit 2GB statt 786MB, schnellen SATA-Platten, alles frisch aufgesetzt und dann die Datenbank-Backups des WaWi-Systems durch die Systementwickler remote eingespielt. Natürlich wurde die Entwicklerfirma schon mehrfach auf das Problem angesetzt, allerdings konnten die auch keine Probleme feststellen - naja... Da das Problem den Serverwechsel unverändert überdauert hat, habe ich einen der Clients - Hard- oder Software - in Verdacht. Da sich aber mit Durchsatz- und Latenzmessungen, massivem Traffic, Beobachten und Simulieren nichts feststellen lässt, hoffe ich nun auf weitere Ideen. Gibt es vom MS irgendein Tool, um die Performance des MSSQL-Servers zu messen? Dienstag werde ich den Server erstmal umstellen, da nicht auszuschliessen ist, dass die Netzwerkleitung in Raum, in dem die Maschine steht, bei Bauarbeiten beschädigt wurde. Wenn das auch nichts hilft, werde ich einen Client nach dem anderen vom Netz nehmen oder besser noch: nur einen zur Zeit dran lassen, nur wird das schwer, da Ware eingebucht und natürlich auch verkauft werden muss. Die Netzwerkkarten in den Clients sind D-Link 530TX, wobei ich sagen muss, dass ich davon schon öfter welche gegen Realtek, 3Com usw getauscht habe, weil seltsame Netzwerkprobleme auftraten, die sich aber dann auch im Durchsatz zeigten.