3
Exchange 2016 verliert NTFS Rechte auf mail.que
Hallo zusammen,
wir haben seit kurzem von einem W2k8R2 mit Exchange 2010 auf W2k12R2 mit Exchange 2016 RU5 upgedatet. Die Migration ist soweit auch gut durch gelaufen, aber nun haben wir schon zum vierten mal das Problem, das der Exchange Server irgendwann nicht mehr in die Mail.que schreiben kann und dann der Transport Dienst beendet wird. Den kann man dann versuchen neu zu starten, dieser beendet sich dann aber nach wenigen Sekunden wieder.
Wenn ich dann in die NTFS Rechte für das Verzeichnis/Laufwerk schaue sehe ich, das der Netzwerk Dienst Vollzugriff hat sowohl auf das Laufwerk als auch auf die Datei. Wenn ich dann aber mit ESEUTIL auf die mail.que zugreifen möchte sagt er mir das ich schreibrechte brauche. Entferne ich nun den Netzwerkdienst und füge Ihn wieder hinzu bringt das nichts. Füge ich aber Jeder hinzu kann ich die DB plötzlich beschreiben und die Mail.Que wieder reparieren.
Das ganze hält dann wieder ein paar Tage und dann kommt der selbe mist wieder.
Hier die Fehler beim start des Transport Dienstes kurz nachdem der Fehler bemerkt wurde
Fehler ID 494
edgetransport (7860) Transport-E-Mail-Datenbank: Fehler beim Wiederherstellen der Datenbank (Fehler -1216), da Verweise auf die nicht mehr vorhandene Datenbank "D:\Queue\Logs\mail.que" festgestellt wurden. Die Datenbank wurde nicht in den Status "Clean Shutdown" versetzt, bevor sie entfernt (oder möglicherweise verschoben oder umbenannt) wurde. Das Datenbankmodul lässt den Abschluss des Wiederherstellungsvorgangs für diese Instanz erst dann zu, wenn die fehlende Datenbank wieder verfügbar gemacht wird. Wenn die Datenbank tatsächlich nicht mehr verfügbar und auch nicht mehr erforderlich ist, finden Sie Informationen über Verfahren zum Wiederherstellen nach diesem Fehler in der Microsoft Knowledge Base oder über den Link "Weitere Informationen" am Ende dieser Meldung .
Fehler ID 454
edgetransport (7860) Transport-E-Mail-Datenbank: Fehler bei der Datenbankwiederherstellung mit dem unerwarteten Fehler -1216.
Fehler ID 17007
Transport-E-Mail-Datenbank: The database could not be opened because the database file does not match the log files. The Microsoft Exchange Transport service is shutting down. The exception is Microsoft.Isam.Esent.Interop.EsentAttachedDatabaseMismatchException: An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info
bei Microsoft.Isam.Esent.Interop.Api.Check(Int32 err)
bei Microsoft.Exchange.Transport.Storage.DataSource.InitInstance().
Fehler ID 490 Kommt wenn man dann versucht die DB anzupacken
eseutil (26412) Fehler beim Öffnen von Datei "D:\Queue\DB\mail.que" für Lese/Schreibzugrifft mit Systemfehler 5 (0x00000005): "Zugriff verweigert ". Fehler -1032 (0xfffffbf8) bei der Operation zum Öffnen von Dateien.
Folgende Dinge habe ich schon versucht:
1. Wiederherstellung der NTFS Rechte und Reperatur ( hat nur 4 Tage gehalten)
2. Ursprünglich lag die DB auf einer ganz eigenen VMWare Partition, danach habe ich die Que auf das gleiche Laufwerk gelegt wie auch der Informationsspeicher gelegt (Hat auch nur 3 Tage gehalten)
Komisch ist, das es nachdem ich es gefixt habe erst mal ein paar tage läuft, auch wenn ich den Server neu starte.
Ich hoffe jemand kann mir da weiter helfen.
Gruß
Floh
wir haben seit kurzem von einem W2k8R2 mit Exchange 2010 auf W2k12R2 mit Exchange 2016 RU5 upgedatet. Die Migration ist soweit auch gut durch gelaufen, aber nun haben wir schon zum vierten mal das Problem, das der Exchange Server irgendwann nicht mehr in die Mail.que schreiben kann und dann der Transport Dienst beendet wird. Den kann man dann versuchen neu zu starten, dieser beendet sich dann aber nach wenigen Sekunden wieder.
Wenn ich dann in die NTFS Rechte für das Verzeichnis/Laufwerk schaue sehe ich, das der Netzwerk Dienst Vollzugriff hat sowohl auf das Laufwerk als auch auf die Datei. Wenn ich dann aber mit ESEUTIL auf die mail.que zugreifen möchte sagt er mir das ich schreibrechte brauche. Entferne ich nun den Netzwerkdienst und füge Ihn wieder hinzu bringt das nichts. Füge ich aber Jeder hinzu kann ich die DB plötzlich beschreiben und die Mail.Que wieder reparieren.
Das ganze hält dann wieder ein paar Tage und dann kommt der selbe mist wieder.
Hier die Fehler beim start des Transport Dienstes kurz nachdem der Fehler bemerkt wurde
Fehler ID 494
edgetransport (7860) Transport-E-Mail-Datenbank: Fehler beim Wiederherstellen der Datenbank (Fehler -1216), da Verweise auf die nicht mehr vorhandene Datenbank "D:\Queue\Logs\mail.que" festgestellt wurden. Die Datenbank wurde nicht in den Status "Clean Shutdown" versetzt, bevor sie entfernt (oder möglicherweise verschoben oder umbenannt) wurde. Das Datenbankmodul lässt den Abschluss des Wiederherstellungsvorgangs für diese Instanz erst dann zu, wenn die fehlende Datenbank wieder verfügbar gemacht wird. Wenn die Datenbank tatsächlich nicht mehr verfügbar und auch nicht mehr erforderlich ist, finden Sie Informationen über Verfahren zum Wiederherstellen nach diesem Fehler in der Microsoft Knowledge Base oder über den Link "Weitere Informationen" am Ende dieser Meldung .
Fehler ID 454
edgetransport (7860) Transport-E-Mail-Datenbank: Fehler bei der Datenbankwiederherstellung mit dem unerwarteten Fehler -1216.
Fehler ID 17007
Transport-E-Mail-Datenbank: The database could not be opened because the database file does not match the log files. The Microsoft Exchange Transport service is shutting down. The exception is Microsoft.Isam.Esent.Interop.EsentAttachedDatabaseMismatchException: An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info
bei Microsoft.Isam.Esent.Interop.Api.Check(Int32 err)
bei Microsoft.Exchange.Transport.Storage.DataSource.InitInstance().
Fehler ID 490 Kommt wenn man dann versucht die DB anzupacken
eseutil (26412) Fehler beim Öffnen von Datei "D:\Queue\DB\mail.que" für Lese/Schreibzugrifft mit Systemfehler 5 (0x00000005): "Zugriff verweigert ". Fehler -1032 (0xfffffbf8) bei der Operation zum Öffnen von Dateien.
Folgende Dinge habe ich schon versucht:
1. Wiederherstellung der NTFS Rechte und Reperatur ( hat nur 4 Tage gehalten)
2. Ursprünglich lag die DB auf einer ganz eigenen VMWare Partition, danach habe ich die Que auf das gleiche Laufwerk gelegt wie auch der Informationsspeicher gelegt (Hat auch nur 3 Tage gehalten)
Komisch ist, das es nachdem ich es gefixt habe erst mal ein paar tage läuft, auch wenn ich den Server neu starte.
Ich hoffe jemand kann mir da weiter helfen.
Gruß
Floh
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 342558
Url: https://administrator.de/forum/exchange-2016-verliert-ntfs-rechte-auf-mail-que-342558.html
Ausgedruckt am: 22.12.2024 um 22:12 Uhr
3 Kommentare
Neuester Kommentar
Moin Floh,
Gruß,
Dani
wir haben seit kurzem von einem W2k8R2 mit Exchange 2010 auf W2k12R2 mit Exchange 2016 RU5 upgedate
virtuell oder physikalisch? VMWare oder Hyper-V? Wo liegen die Datenbanken. Auf einem SAN oder auf einem VMWare Datastore welcher aus lokalen Festplatten besteht?!Gruß,
Dani
Hallo Dani,
Das ist nun eine VMWare 5.5 U2 Maschine. Der alte Server war eine Hyper V Maschine. Das ganze befindet sich in VMDKs auf einem SAN. Das SAN besteht aus 24 10K SAS HDDs welche in einem WideStripe R5 angelegt sind.
Ich glaube nicht das es an der Umgebung liegt. Die ändert keine NTFS Rechte auf einem Ordner oder einer Datei. Bei den anderen Servern gibt es keine vergleichbaren Probleme.
Gruß
Florian
Das ist nun eine VMWare 5.5 U2 Maschine. Der alte Server war eine Hyper V Maschine. Das ganze befindet sich in VMDKs auf einem SAN. Das SAN besteht aus 24 10K SAS HDDs welche in einem WideStripe R5 angelegt sind.
Ich glaube nicht das es an der Umgebung liegt. Die ändert keine NTFS Rechte auf einem Ordner oder einer Datei. Bei den anderen Servern gibt es keine vergleichbaren Probleme.
Gruß
Florian
Das Problem konnte nicht durch MS im Rahmen eines Business Critical Calls gelöst werden. Die haben alle auf das CU6 verwiesen welches dann nun auch die Lösung war.
