haeckle

Hallo, folgendes Problem habe ich: Ich habe über zwei Lancomrouter eine VPN-Verbindung zwischen zwei Standorten (a und b) erstellt. Diese läuft schon seit Jahren stabil. Bisher waren an Standort B nur WIN98 Rechner, die sich über den WindowsTerminal Client am Standort A an einem Windows Terminalserver anmelden. Nun habe ich an Standort B einen neuen Rechner mit Windows XP installiert. Dieser greift nun über den Remotedesktop client auf den Terminalserver zu. Auch das klappt einwandfrei. Bisher war es so, dass die WIN98 nicht am eigenen Standort ins Internet gehen sollten. War auch nicht nötig, da die Rechner über den TS-Server ins Internet gehen/ gingen. Aus Sicherheitsgründen hatten die WIN98 Rechner weder CD noch Diskettenlaufwerke. Internet läuft bei diesen Clients wie gesagt nur über den Terminalserver. (Wir arbeiten mit DATEVNet zusammen, die stellen auch den Proxyserver.) Nun habe ich am Standort B aber diesen XP Rechner installieren müssen. Dieser muss auch lokal und nicht nur über den Terminalserver ins Internet, da er seinen Virenscanner aktualisieren muss. Bekanntlich arbeiten wir mit der Datev zusammen, wenn es um unsere Netzsicherheit geht. D.h., dass der neue Rechner am Standort B nur über den Proxyserver an Standort A ins Internet gehen darf. (Vorgabe der DATEV.) Ich habe nun das Problem, dass der neue Rechner an Standort B sich zwar an über den Remotedesktop an Standort A anmelden kann und dort auch ins Internet kommt, eine Internetverbindung über den Proxyserver kann ich aber nicht herstellen. Das Kuriose ist, dass ich unsere 4 Server, an Standort A, von Standort B aus anpingen kann den Proxyserver und andere Clients kann ich nicht anpingen. Ein Nslookup auf den Proxyserver funktioniert. Aber ich denke nur deshalb, da ich den DNS Server anpingen kann und dieser somit sauber im Netz ist. Ich habe an dem lokalen Rechner auch mal eine feste Route auf den Standort A eingetragen, auch das hat nicht geholfen. Auch diveres Einstellungen am lokalen Rechner (Proxyeinstellungen des Internet Explorers, LAN-Einstellungen) brachten mich nicht weiter. Es ist nun die Frage, warum kann ich die Server anpingen und alle anderen Rechner nicht. Ich Route doch in ein Netz, was ja funktioniert, und nicht auf bestimmte Rechner. Auf wenn auf beiden Routern die Firewall deaktiviert ist, kann ich nur die Server anpingen. Hat jemand eine Idee wo ich noch ansetzen kann?

Hi, das ist mir schon klar. Evtl. hab ich mich da nicht korrekt ausgedrückt. Ich möchte "Beim Hochfahren" eine Anzeige erhalten, welche Dienste/ Programme gerade gestartet/ initialisiert werden. Auch in der Reihenfolge wie Sie vom System gestartet/ initialisiert werden. Gibt es sotwas. Ich hab halt ein Problem, dass das System seit kurzem (kein Programm/ Dienst wurde hinzugefügt oder entfernt) sehr lange benötigt, biss es ganz hochgefahren ist. Nun möchte ich nicht nach und jeden Dienst/ Programm aus der Registrierkarte entfernen, um dann mit x-maligem Neustarten mühselig festzustellen, welches Programm wie lange zum starten benötigt. Also einfach eine Bildschirmanzeige beim Start die anzeigt, welcher Dienst/ welches Programm gerade gestartet wird. Gibt es soetwas, kann man so etwas z.B. mit VBA realisieren? Oder mit einer Batchdatei? Z.B. kann hab ich eine Batch-Datei, mit der ich unseren Exchange-Server manuell starte. Dort wir dann im dos-Fenster nach und nach angezeigt, welcher Dienst gestartet wird. Hier die Batch-Datei für den Start des Exchange-Servers. net start smtpsvc net start nntpsvc net start msexchangesa net start msexchangeis net start pop3svc net start imap4svc net start msexchangemta pause Es sollte doch auch evtl. in ähnlicher Weise möglich sein, dass Starten der Dienste/ Programm sich anzeigen zu lassen, oder? Hat jemand noch eine Tip.

Hallo, gibt es eine Möglichkeit, dass ich während des hochfahrens eines XP-Rechners mir anzeigenlassen kann, welche Dienste und Programme initialisiert/ gestartet werden. Hat XP eine solche Funktion.

Hi, hast Du schon mal den shutdown Befehl versucht. Die Schüler könnten dann mit einem Doppelklick den Rechner herutnerfahren und die Dateien würden vorher gesicher. Erster der Copy-Befehl, dann der Shutdown Befehl. So z.B. xcopy f:\sicherung_sql_server\sqlserver_ab_2006.bkf /y (der lokale Pfad) \\datsrv\serversicherungen (Der Zielpfad auf dem Netzwerk) shutdown -s (XP fährtdann nach 30 sec. runter)

Hi, hast Du mal probiert, ob Dein Script funktioniert, ohne das es beim herunterfahren ausgeführt werden soll. Also einfach eine Batch-Datei erstellen und dort mal ein Xcopy vom lokalen auf das Netzlaufwerk machen. Z.B. so: xcopy f:\sicherung_sql_server\sqlserver_ab_2006.bkf /y (der lokale Pfad) \\datsrv\serversicherungen (Der Zielpfad auf dem Netzwerk)

Hi, mit Hilfe haben wir das Problem nun behoben. Also, durch das einbrigen des Testrechners DC3 hat dieser auch das Administratorkennwort am DC2 geändert. Wir haben das Administrator Kennwort zurückgesetzt, den DC2 neu gestartet und dann funktionierte die Replikation wieder. Der Extene Admin wies mich darauf hin, ob beim Ausetzten des Test DC´s evtl. ein anderes PW als beim aktuellen DC vergeben wurde. Dem war so, da ich beim Aufsetzen des Test DC ein altes Adminkennwort, aus meinen Unterlagen, genutzt habe. Es ist nur nicht ganz klar, warum ich mich trotzdem als Admin mit dem aktuellen Konto anmelden konnte. Kann es sein, das durch die fehlerhafte Replikation eine Anmeldung immer am DC1 durchgeführt wurde, so dass das Problem mit dem aktuellen PW nicht festgestellt werden konnte? Es ist schon manchmal sehr seltsam wie sich die Dinge verhalten. Dank aber auch noch mal für die Hilfe! :) Auch für den Hinweis externe zu holen. Ist in jedem Fall sinnvoll gewesen.:wink2:

Hi, habe ich auch gemacht. Ein Admin einer Partnerfirma hat mir telefonisch zur Seite gestanden. Da das System dann einwandfrei lief, war das erstmal abgehakt. Das Problem mit der Replizierung ist heute erst festgestellt worden. Den Admin der Partnerfirma kann ich z.Z. nicht erreichen. Aber was soll´s, es muss auch so gehen.

Hallo, folgendes Problem haben wir. Ich habe eine Domäne mit zwei DC´s. DC1 = Erster Dc der Domäne DC2 = weiter DC der Domäne Betriebssysten W2K Nach einem schwerwiegenden Prombel mit Exchange, ist es uns gelungen, diesen wieder ins Leben zu rufen. Das Arbeiten am System funktioniert zur Zeit ohne Probleme. Nun mußte ich heute allerdings feststellen, das sich der DC2 nicht mehr mit dem DC1 repliziert. Es kommt folgnede Fehlermeldung: Ereignistyp: Fehler Ereignisquelle: NTDS Replication Ereigniskategorie: (5) Ereigniskennung: 1645 Datum: 30.03.2007 Zeit: 09:46:09 Benutzer: Jeder Computer: KATALOGSERVER Beschreibung: Fehler beim Durchführen eines authentifizierten RPC-Aufrufs an einen anderen Domänencontroller. Der gewünschte SPN (Service Principal Name) ist auf dem Zielserver nicht registriert. Server: 7955e30e-28ba-4ec0-abe3-123170021838._msdcs.bremicker.de, SPN: E3514235-4B06-11D1-AB04-00C04FC2DCD2/7955e30e-28ba-4ec0-abe3-123170021838/bremicker.de@bremicker.de. Stellen Sie sicher, dass die Namen des Zielservers und der Domäne richtig sind. Stellen Sie außerdem sicher, dass die SPN auf dem Computer- kontoobjekt für den Zielserver auf dem KDC, der die Anfrage bearbeitet, registriert ist. Wenn der Zielserver vor kurzem heraufgestuft wurde, müssen Daten dieser Identität des Computers auf den KDC repliziert werden, bevor dieser Computer authentifiziert werden kann. Was habe ich bisher gemacht: 1) Habe versucht eine Replikation der DC´s zu erzwingen. Mache ich das auf DC1, so kommt die Meldung "AD hat die Verbindung repliziert". Man will also meinen, das hat geklappt. Ein Replikation findet aber nicht statt. Habe einen Benuter auf DC1 angelegt, der ja nach einer erfolgreichen Replizierung dann auf dem DC2 zu sehen sein sollte. Hat er aber nicht gemacht. 2) Dann habe ich die Replizierung vom DC2 aus gestartet. Es kommt folgende Meldung: "Bei Synchronisierung der DC ist folgender Fehler aufgetreten: Anmeldung fehlgeschlagen, der Zielkontenname ist ungültig". Zudem wird im Ereignisprotokoll die o.g. Fehlermeldung generiert. Nun habe ich schon einiges geforscht (Forum, Google/ MS-KB), aber einen plausibelen Hinweis auf Fehlerbehebung konnte ich noch nicht finden. Die Ursache für das Problem wird wars***einlich folgende sein: Wie gesagt, ist unser Echgangeserver in die Knie gegangen. Da eine Reparatur auf dem Exchangeserver nicht möglich war, haben wir einen zweiten Identischen Server (DC3) aufgesetzt, um zu versuchen die DB dort zu retten. Durch einen unglücklichen Umstand, ist dieser DC3 in das Produktivsystem gerutscht und hat dort absolutes Chaos hinterlassen. Z.B. hat der DC3 die FSMO-Rollen übernommen und sich selber dort eingetragen. Da wir nicht gemerkt haben, dass DC3 im Netz war, hat dieser sich mit DC2 repliziert, währen DC1 zeitweilig vom Netz war, wegen Reparaturarbeiten. Ich habe es nun hinbekommen, dass die FSMO-Rollen wieder auf DC1 lauten, auch der Exchange läuft nun wieder. Nur die Replikation der zwei DC´s läuft nun nicht mehr. Hat einer von euch evtl. noch eine Idee, wo ich noch anseten kann.

Hi Günther, das hat geklappt. Nun habe ich aber noch das Problem, dass ich an das AD nur komme, wenn ich den Kerberos-Schlüsselverzeichnis Center auf dem DC deaktiviere. Ist er aktiviert, kommt der Fehler "Ziel-Principal Name ist falsch". Ich habe einen Artikel gefunden, in dem man mit Netdom das Adminkennwort zurücksetzen soll. Also mit Netdom resetpwd /servername:DC1 ... Bin mal gespannt ob es klappt. Sagt Dir diese Fehlermeldung etwas und kannst du Dir erklären, wie diese erzeugt wurde?

Hallo, ich habe das Problem, dass ich mein AD aud dem Domaincontroller nicht bearbeiten kann, wenn der Dienst Kerberos-Schlüsselverteilungscenter gestartet ist. Es kommt der Fehler "Ziel-Principal-Name ist falsch". Wo kann ich für diesen Dienst den Namen sehen bzw. ändern. Windows 2000 Server mit 2 DC´s

Hallo, habe mir nun Hilfe geholt. Auf DC1 habe ich die Rollen nun wieder übernommen. Wenn ich auf AD Benutzer- und Computer ging, konnte man nicht mehr drauf, da die Meldung "Ziel-Principal-Name nicht verfügbar" kam. Gut, was haben wir gemacht: 1) Über Ntsdutil wolle er die Rollen auf dem DC1 übernehmen. Das klappte nicht, da auch hier der"Ziel-Prinzipal" Feler kam. 2) Er hat bei Technet folgenden Link aufgetan. Sie können die Laufwerke eines Domänencontrollers von einem Clientcomputer aus nicht durchsuchen oder ihm ein Laufwerk zuordnen Die Infos haben wir abgearbeitet. Nun ist mein erster DC, DC1, wieder erreichbar. Puhhhh. Es schein auch alles zu funktionieren. Nun kann ich mich an den Exchange begeben. Danke nochmals für Eure Ansätze und Hilfestellungen. Echt ein tolles Board!!

Hi, So ist es, hole mir nun wirkilch externe Hilfe. AD so tiefIst halt nicht mein Tagesgeschäft. Ohne den ****en Testserver wäre ich wohl schon fertig. Gut, selbst Schuld, aber hoffentlich was gelernt!! Danke für Eure Hilfe bis hierhin.

Hallo, bewußt habe ich weder eine Änderung am Schema noch an den Rollen vorgenommen. 1) Wir hatten Probleme mit unserem Exchangeserver. Um die DB zu retten wollten wir einen zweiten gleichen DC erstellen um dort die DB zu retten. 2) Zuerst habe ich DC2 in die Domäne aufgenommen, um die Exchangedateien dorthin zu kopieren. (16GB) 3) Dann habe ich DC2 vom Netz genommen, so dachte ich zumindest! 4) Dann habe ich DC2 per Dcpromo zum DC seiner eingenen Domäne gemacht. Der Domänenname war bzw. ist in beiden fällen gleich! 5) Dann habe ich Densystemstatus von DC1 auf Dc2 kopiert um ein gleiches System zu erhalten. 6) Dann mußte ich feststellen, dass in unserem zweiten DC der Domäne (ich nenne diesen DC3) die der Testrechner D2 in den Betriebsmasterrollem eigetragen war. 7) Bei DC1 komme ich nicht mehr auf die AD Snap-Inss wie z.B. AD Benuter und Computer. Es wird folgendes angegeben: "Der Ziel-Principal-Name ist Falsch" 8) Ist es denn nun nicht am einfachsten, den Syststemstatus (von Vorgestern) auf DC1 zurückzusichern? Das wäre doch die einfachste Sache. Evtl. ist zu klären, wie ich dann bei DC3 noch die Rollen anpasse, wenn DC2 noch dort vohanden ist. Kann man die Änderung nicht erzwingen? So, ich hoffe das war ausfühlich genung.

Hi, warum ist denn ein Zurücksichern des Systemstatus für Dich keine Alternative? Dann müßte doch DC1 wieder sauber sein und auf DC3 kann ich dann mit Ntdsutil die Rollen erzwingen, oder?

Hi, also: 1) Zuerst habe ich DC2 in die Domäne aufgenommen, um die Dateien zu kopieren. 2) Dann habe ich DC2 vom Netz genommen, so dachte ich zumindes! 2) Dann habe ich DC2 per Dcpromo zum DC seiner eingenen Domäne gemacht. Der Domänenname war bzw. ist in beiden fällen gleich!

Hi, 1 und 2: Ja, ich war wohl sehr unachtsam. 3) DC2 ist definitiv nicht mehr da. 4) Ich denke das ich beim Dcpromo vom DC2, noch im Netz gewesen sein muss. Dann gab es zu diesem Zeitpunkt zwei Domänen mit dem gleichen Namen und beide haben dann auch die FSMO-Rollen für eine gleichlautende Domäne. 5) Das war wohl der Fall. 5) Wie kann ich feststellen, ob es je zwei FSMO´s gegeben hat? 6) Es gibt noch einen DC, ich nenne ihn DC3 in der Domäne. Bei dem konnte ich halt feststellen, dass dort als Betriebsmaster nun der Testserver DC2 eingetragen ist. Was versteht man unter authorativen Restore, bzw. wie muss ich da vorgehen? 7) Wie gehe ich am besten nun vor? Meine vorstellung nun: a) Alle User vom Netz b) DC3, zweiter DC der DC auch vom Netz nehmen c) Systemstatus zurücksichern d) DC1 hochfahren und überprüfen e) DC3 hochfahren und Replikation erzwingen. (Ändern sich daurch automatisch die Rollen auf DC3? Ist das so Sinnvoll?

Aber reicht es denn nicht, dass der DC2 vom Netz ist und ich den Systemstatus zurücksichere. Damit ist doch auch das komplette AD zurückgesichert, oder? Dc3 sollte sich dann wieder mit DC1 replizieren und gut ist, oder sehe ich da was falsch? Wo kann eine solche Rücksicherung scheitern?

Hi Woiza, wir haben den DC2 separat, als ersten DC der Domäne installiert, wie halt DC1, der erster DC der Domäne ist. Als erstes habe ich den DC2 in die Domäne aufgenommen, ohne Dcpromo auszuführen. Ich wolle die Exchangedateien (16GB) per Netzwerk auf den DC2 schieben. Dann habe ich DC2 vom Netz genommen und mit Dcpromo konfiguriert und Exchange aufgespielt. Zum Schluß habe ich von Band noch den Systemstatus vom DC1 auf den DC2 gespielt, damit DC1 und DC2 identisch sind (Fast gleiche Hardware vorhanden) Irgenwann müssen beide, im Netzgewesen sein. Und ich bin mir ganz sicher, das ich beim heraufstufen den DC2, diesem vom Netz hatte. Nun habe ich halt die beschriebenen Probleme. Im übrigen habe ich nun auch noch das Problem, dass der DC2, nach einspielen des Systemstauts von DC1 nun nicht mehr hochfährt, das ein inaccessible_boot_device vorhanden ist. Ich kapier nur nicht, warum dann auf einmal die Rollen des ersten DC weg waren?

Hi, sorry! also nochmal: DC 1 > Standard DC (Erster DC der Domäne) DC 2 > Test DC (Es gibt auch einen DC3, als Backup für die Domäne) DC 2 wurde wie DC 1 Konfiguriert. Es sollte dort eine Exchange DB repariert werden. Durch ein Mißgeschick hing der DC2, ohne es zu Bemerken, in laufenden Betrieb. Plötzlich gab es bei DC1 Probleme, und es wurde festgestellt, dass die Betriebsmasterrollen etc. nun den DC2 eingetragen hatte. DC1 ist unter AD Benutzer-und Computer etc. nicht erreichbar. Im DC3 habe ich dann bei AD Benutzer-und Computer festgestellt, dass dort der die Rollen nun auf DC2 lauten. DC2 wurde sofort aus dem Netz genommen. Kann ich nun mit Rücksicherung des Systemstauts dieses Problem beheben?

Hallo, ist es möglich, dass man durch Rücksicherung des Systemstatus folgendes Beheben kann: 1) Zu Testzwecken wurde ein Server al DC einer vorhandenen Domäne aufgesetzt. 2) Durch ein Mißgeschik ist er in den laufenden Betrieb gelandet. 3) Als das festgestellt wurde, hat man ihn sofort vom Netz genommen. 4) Nun hat dieser DC den eigentichen DC verdrängt. D.h. die Betriebsmasterrollen und Schemamaster lauten nun auf den Testserver. 5) Der eigentliche DC ist nun offline, bzw. er arbeitet nicht mehr korrekt. 5) Ich habe noch eine Sicherung von gestern, bei der auch der aktuelle Systemstatus des eigentlichen DC gesichert wurde. 6) Kann ich den Fehler beheben, indem ich den Systemstatus zurücksicher? Bin dankbar für jede Hilfe.

Hallo Günther, ich habe folgendes gerade festgestellt. Wir haben noch einen zweiten DC. Gehe ich dort auf AD Benutzer un Computer und dann auf Betriebsmaster, so steht dort nun dieser vermaledeite DatsrvNEU und nicht der eigentliche DC Datsrv. Ändern kann ich die Rollen nicht, es kommt folgende Fehlermeldung: Die Überdtragung der Funktion des aktuellen Betriebsmasters konnte nicht durchgeführt werden. Grund: Der angeforderte FSMO-Vorgang konnte nicht ausgeführt werden Der aktuelle FSMO-Inhaber war nicht erreichbar. Kann ich die Einträge irgenwie manuell per Console ändern?

Hallo Günther, ich kommen nun nicht mehr auf mein AD. Es kommt folgende Fehlermeldung: Der Ziel-Principal Name ist falsch Im Ereignisprotokoll sind noch folgende Meldungen: Im Anwendungsprotokoll laufend dieser Fehler: Ereignistyp: Fehler Ereignisquelle: Userenv Ereigniskategorie: Keine Ereigniskennung: 1000 Datum: 30.03.2007 Zeit: 02:56:52 Benutzer: NT-AUTORITÄT\SYSTEM Computer: DATSRV Beschreibung: Der Benutzer oder der Computername kann nicht ermittelt werden. Zurückgegebener Wert (1326). Im Systemprotokoll laufend dieser Fehler: Ereignistyp: Fehler Ereignisquelle: SAM Ereigniskategorie: Keine Ereigniskennung: 16650 Datum: 30.03.2007 Zeit: 07:21:36 Benutzer: Nicht zutreffend Computer: DATSRV Beschreibung: Die Kontenkennungszuweisung wurde nicht richtig initialisiert. Der Datensatz enthält den NT-Fehlercode, der den Fehler verursacht hat. Windows 2000 wiederholt den Initialisierungsvorgang, bis dieser durchgeführt werden kann. Bis dahin ist keine Kontenerstellung auf diesem Domänencontroller möglich. Suchen Sie eventuell nach anderen SAM-Ereignisprotokolleinträgen, die auf den exakten Fehlergrund hinweisen. Daten: 0000: a7 02 00 c0 §..À Nun bin ich völlig ratlos.

Hallo, habe noch ein Problem: Nachdem wir heute den Testserver installiert haben. W2K mit Exchange. War dieser kurz im Netz. Plötzlich Stand dann im AD unter Domaincontroller nicht mehr der eigentliche DC (Datsrv) sondern der zuvor aufgesetzte Server DatsrvNEU. Durch irgeneine Unachsamkeit muss das wohl passiert sein. Nun mußte ich darauf hin feststellen, dass in dem meinem Produktivsystem die Exchangedienste nicht mehr starten. Wie gesagt, das erste was ich feststellen konntewar, das der eigentliche DC (Datsrv) nicht mehr im AD als Server eingetragen war. Auch stand nun der DatsrvNEU als Server an verschieden anderen Stellen, in an der eigentlich der Datsrv stehen sollte. Ich habe das alles soweit korriegiert. Sprich habe den Datsrv wieder als DC unter DomainController im AD hinzugefügt. Außerdem habe ich an allen Stellen, wo ich sehen konnte, dass nun der DatsrvNEU eingtragen war, diesen gegen den Datsrv ersetzt. Trotzdem weigert sich der Dienst MsExchangeSystemaufsicht zu starten. Hat jemand eine Idee, wo ich noch suchen muss. Bin echt am Ende.

Hallo, nach einem Crash, muss ich einen DC wieder herstellen. Dazu haben wir einen Identischen Server bekommen können. Habe den Server installiert und getestet ob er so erstmal läuft. Alles o.k. Dann Exchange installiert, auch o.k. Zum Schluß noch das AD zurückgesichert. Das hat auch funktioniert. Nur beim Neustart kommt dann die Fehlermeldung Inaccessible_Boot_Device. Auf beiden Servern gleiches Mainboard, die gleichen Controller etc.. Die FP sind gleich groß (bzw. nur minimaler unterscheid von 47MB, was für das Starten aus dem Raid ja egal sein sollte) Im IPC Controller Menü sind Drive, ID etc. ebenfalls offensichtlich gleich, konnte keinen Unterscheid, bis minimalen FP Größeunterschied. Hier die Merkmale des Systems: Windows 2000 Server mit Exchange2000 Raid 5 FP-Größe 36GB Controller vom IPC Hat jemand eine Idee, wie ich diesen Fehler beheben kann?

Hallo Günther, da gebe ich Dir insoweit recht, als das Dinge, wie Eseutil.exe anwenden muss, hier finde. Habe ich auch benutzt, wolle nur zeigen, wie ich die Befehle genutzt habe! Doch liegt mein Problem hier, dass ich ja Fehler bekomme, die eben nicht damit gelößt werden können. Deine beiden Links zu hier geposteten Beiträgen, beziehen sich zwar auch auf die Offlinedefragmentierung, aber bei denen traten aber nicht die Fehler auf wie bei mir. Z.B. 1018 Mir geht es nun darum, wie ich weiter vorgehen soll. 1) Kann die Datenbank defekt sein, wenn ich offensichtlich noch drauf komme und z.B. Mails löschen kann bei den Usern. 2) Bei einer Onlinedefragmentierung bekommen ich gestern eine Fehlermeldung a) und heute die Meldung, dass diese korrekt durchgelaufen ist. b): Bedeutet das, dass die DB nun o.k. ist und ich kann offline defragmentieren, oder ist dass nun Zufall? Kann ein Hardware defekt vorliegen? Ich habe das Raid (IPC-Controller) überprüft. Eine FP hat 7 Grown-defekts, eine einen und eine keinen. Lt. Unteralgen ist das noch nicht kritisch. Chkdsk bringt einen Fehler. Hier die Meldungen a) Ereignistyp: Fehler Ereignisquelle: ESE Ereigniskategorie: Datenbankseitencache Ereigniskennung: 474 Datum: 28.03.2007 Zeit: 07:45:13 Benutzer: Nicht zutreffend Computer: DATSRV Beschreibung: Information Store (840) Überprüfung der aus Datei "D:\Programme\Exchange\mdbdata\priv1.edb" bei Offset 1141305344 (0x000000004406f000) für 4096 (0x00001000) Bytes gelesenen Datenbankseite ist durch eine Inkonsistenz der Seitenprüfsumme fehlgeschlagen. Die erwartete Prüfsumme war 2178664157 (0x81dbc6dd), die tatsächliche Prüfsumme 2447099613 (0x91dbc6dd). Fehler -1018 (0xfffffc06) bei Leseoperation. Wenn dieser Zustand andauert, stellen Sie die Datenbank aus einer vorherigen Sicherung wieder her. b) Ereignistyp: Informationen Ereignisquelle: ESE Ereigniskategorie: Onlinedefragmentierung Ereigniskennung: 701 Datum: 29.03.2007 Zeit: 05:00:00 Benutzer: Nicht zutreffend Computer: DATSRV Beschreibung: Information Store (2300) Onlinedefragmentierung hat einen vollständigen Durchlauf der Datenbank 'D:\Programme\Exchange\mdbdata\pub1.edb' abgeschlossen. 3) Wie gehe ich nun am besten vor? Was habe ich schon gemacht! a) Habe alle Postfächer gesichert. b) Die aktuelle edb und stm habe ich gesichert. c) Festplatten auf dem Produktivsystem überprüft. Per IPC kaum Fehler, Chkdsk liefert einen Fehler.