koem@

vor 1 Minute schrieb NorbertFe:

Weil ihr am Wochenende keine Mails bekommt? Temp Error. Wieviel Plattenplatz ist auf C: noch frei?

Da Mails bei Hosteurope landen und per POPcon abgeholt und über Empfangsconnector (Port 25) zugestellt werden und dies unter anderem nicht mehr klappt, sind sie dort gepuffert und werde da gesichert. C hat fast 500 GB frei.

vor 10 Minuten schrieb NorbertFe:

Und alle Daten die während dessen geändert wurden, sind euch egal? Ich versteh solche Hau Ruck Aktionen nicht. Das ist doch keine Datei die man mal eben überschreibt, sondern ein laufendes DAtenbanksystem, welches zudem noch ziemlich stark mit dem AD verzahnt ist. Da komme ich bei solchen Problemen auf ziemlich viele Ideen, aber nicht auf ein "Zurücksetzen". ;)

Ich habe oben bereits geschrieben: Schau ins Eventlog und ins SMTP Log. Versuch doch einfach mal ne Mail per Telnet an den Exchange zuzustellen. Nimmt er sie dir ab, dann sind wir schon mal einen Schritt weiter.

 

Bye

Norbert

Es wurde, weil Wochenende, nichts geändert. Deswegen hatten wir, wie immer, Wartung am Samstag gemacht. Mail per SMPT zustellen geht nicht, da kommt Fehler 451 4.7.0 Temporary Server error. Please Try Again Later. PRX Und zu dem gibt es viele Ideen im Internet. Habe alles geprüft, was ich dazu bekommen habe und wusste. Leider ohne Erfolg. 

15.00.1156.010 also Exchange 2013 CU 11

Den Provider hatte ich als Idee auch, aber das erklärt Empfangen und internes Mailing nicht, oder?

vor 4 Minuten schrieb NorbertFe:

Zurückgesetzt klingt irgendwie selten gut! Was steht in den Protokollen?

In welchen? Wir haben einfach da Backup von Freitag Nacht zurückgespielt und die VM überschrieben. 

Ich sehe beim Sendeconnector Winsock Error 10061. Server hat Verbindung verweigert

Also, Neustart bringt nichts. Server wurde per VEEAM auf Stand vor den Updates zurückgesetzt. Allerdings nicht die DC's. Das geht nicht so einfach. Virenscanner wurde zum Testen deinstalliert. Die Idee hatte ich (u.A.) auch schon

Moin zusammen,

wir betreiben einen Exchange 2013 auf einem WIN Server 2012 R2 in einer VM Umgebung. Die Externen Mails werden mit einem POP3 Connector (POPcon) abgeholt und dem Server über Empfangsconnector (Port 25)  zugestellt. Mails nach draußen gehen per Sendeconnector direct an Hosteurope. Der Exchange ist kein Domänencontroller sondern nur Mitglied. In der Dömäne gibt es 2 DC's welche DHCP und DNS als Failover konfiguriert hosten.

Am Samstag haben wir (allerdings nach längerer, betriebsbedingter Pause) nur bei den Betriebssystemen der Server normale Windows Updates gefahren. Kein Exchange Update. Seit diesen Updates ist der Exchange des mailens überdrüssig. Weder nimmt er die Mails von POPcon an, noch sendet er Mails nach draußen, noch stellt er interne Mails zu. 

Die eigentliche Anbindung per Outlook, per OWA, per Handy (ActiveSync) und auch von einem Client per AdminConsole klappen. 

Der DNS war sofort unsere Idee, dieser macht aber genau das, was er soll. Auch Reverse.

Was müsst Ihr wissen? Was sollen wir machen?

Danke für Eure Hilfe!!!

Ingo

So Nach hin und her kopieren sehe ich die edb Datei. eseutil /mh ergibt Clear shutdown

Ist eine VM

So, habe es hin bekommen.

Aus dem Mailbox Database Verzeichniss alles außer die EDB, die INTEG.RAW und das vorhandene Verzeichniss verschoben. Dann ließ sich die MDB mounten.

Nun konnte auch der Migrationsuser auf dem neuen (2013) Server aktiviert und gesetzt werden. Alles geht wieder, Mailboxen verschieben geht auch wieder.

SCHWITZ!!!!!!!

Danke an alle und alle Tips!!!

Datei in anderes Verzeichnis verschoben. Dann sehe ich sie auch in DOSBOX. Kopiere sie wieder in des Ursprungsverzeichniss.

Server hat nur eine Partition. Da liegt sie.

Habe in Hochkomma geschrieben

Mache mich solange an die zweite DB. Warum gibt es 2???

Im 2. Verzeichniss gibt es keine .edb Datei

Verstehe ich nicht

Im Ordner c:\programme\microsoft\exchange server\v15\mailbox finde ich 2 Verzeichnisse. Ist das normal? Ich habe nur eine Datenbank angelegt

Danke Norbert.

Punkt 1 bin ich gerade dran. Siehe Kommentar oben.

Ich habe Exchange 2013 KU 11

Wenn ich bei der ersten DAtenbank eseutil /mh nutze bekomme ich Jet Error -1811

Die Datenbank ist aber da und der Name lautet wie geschrieben

Komisch. Ich sehe die *.edb Datei im explorer. In der DosBox sehe ich sie nicht

Hallo zusammen,

habe folgendes Problem bei einer Migration von Exchange 2010 zu Exchange 2013.

Beide Server befinden sich in einer Domänenumgebung. Exchange 2013 läuft auf einem Server 2012 R2 und Exchange 2010 auf einem SBS2011.

Wir haben alle 14 Tage jeweils 8 User vom alten auf den neuen Server umgezogen, was auch 3 mal geklappt hat. Letztes Wochenende ist der Umzug nach 3 Usern abgebrochen. Danach konnte man nicht mehr auf den Reiter Migration in der Management konsole zugreifen. Fehler iet eigentlich bekannt. User Migration.8f3e7716-2011-43e4-96b1-aba62d229136 löschen. Exchange setup /preparead und /prepareschema neu ausführen und

Enable-Mailbox -Arbitration -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136"

Set-Mailbox "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" -Arbitration –Management:$true

Auf dem Exchange ausführen.

Hier komme ich zu dem problem.

Führe ich Enable-Mailbox -Arbitration -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" auf dem Exchange 2013 aus bekomme ich

Load balancing failed to find a valid mailbox database.
    + CategoryInfo          : NotSpecified: (0:Int32) [Enable-Mailbox], RecipientTaskException
    + FullyQualifiedErrorId : [server=SERVERNAME,RequestId=af35e271-a8dd-478f-a5ce-31843b3ed3cf,TimeStamp=15.02.201
   6 08:40:10] [FailureCategory=Cmdlet-RecipientTaskException] 92F0ADDA,Microsoft.Exchange.Management.RecipientTasks.
  EnableMailbox
    + PSComputerName        : SERVERNAME.DOMAENE.local

als FM.

Ich kann das Migrationspostfach auf dem SBS2011 so aktivieren, dann kann man aber keine Postfächer mehr verschieben mit der FM, dass das Postfach auf einem Exchange V15 aktiviert sin muss.

Jemand ne Idee?

Danke Schomma!!!

Habe selbst etwas gefunden. Die Mailbox Database ist nicht gemounted.

Beim Mounten Kommt folgende FM:

Fehler beim Einbinden der Datenbank "MBDB01". Fehler: Fehler bei Active Manager-Vorgang: Fehler bei der Datenbankaktion: Fehler bei Vorgang mit folgender Meldung: MapiExceptionDatabaseError: Unable to mount database. (hr=0x80004005, ec=1108) Diagnostic context: Lid: 65256 Lid: 10722 StoreEc: 0x454 Lid: 1494 ---- Remote Context Beg ---- Lid: 45120 dwParam: 0x1C0353 Lid: 57728 dwParam: 0x1C03C0 Lid: 46144 dwParam: 0x1C076A Lid: 34880 dwParam: 0x1C076A Lid: 34760 StoreEc: 0xFFFFFDE3 Lid: 41344 Guid: b5b04739-90b1-4872-81ac-aa81e7e3a1f9 Lid: 35200 dwParam: 0x1A4C Lid: 46144 dwParam: 0x1C0C3C Lid: 34880 dwParam: 0x1C0C3C Lid: 54472 StoreEc: 0x1388 Lid: 42184 StoreEc: 0x454 Lid: 1750 ---- Remote Context End ---- Lid: 1047 StoreEc: 0x454 .. [Datenbank: MBDB01, Server: SERVER.DOMÄNE.local]

 

 

Außerdem hast du in deinem Betreff einen Tippfehler, da ist ein "r" Zuviel :D

 

Ist mir raus gerutscht :-)

Norbert,

das ist mal ne Aussage. Dann mache ich mal weiter :-)

Danke!

Norbert,

ist also Normal und ich kann es ignorieren?

Hallo zusammen,

ich migriere einen Exchange Server 2007 (auf SBS2011) zu einem Exchange Server 2013 (auf Server 2012).

Beide Server (2008r2 und 2012) sind Mitgliedserver der selben Domäne. DNS ist sauber. Alle sehen alle :-) Alle Server sind virtualisiert. Beide Exchange laufen als VM auf dem selben Host.

Von den beiden Servern, um die es hier geht kann jeweils voll auf den anderen zugegriffen werden.

Nun habe ich folgendes Problem:

Gebe ich auf dem alten Exchange Server in der Mgmt Shell "get-mailboxdatabase" ein, bekomme ich als Antwort nur die Datenbank des alten Exchange-Servers selbst.

Gebe ich auf dem alten Exchange Server in der Mgmt Shell "get-exchangeserver" ein, bekomme ich als Antwort nur den alten Exchange Server selbst.

Gebe ich auf dem neuen Exchange Server in der Mgmt Shell "get-mailboxdatabase" ein, bekomme ich als Antwort nur die Datenbank des neuen Exchange-Servers selbst.

Gebe ich auf dem neuen Exchange Server in der Mgmt Shell "get-exchangeserver" ein, bekomme ich als Antwort beide Exchange Server.

Ich kann auf dem neuen Exchange Mailboxen von dem alten Exchange verschieben und diese funktionieren dann auch. Mails kommen von intern und extern an, gehen nach intertn und extern ab. Öffentliche Kalender können eingesehen und editiert werden.

Vom alten Exchange ist verschieben nicht möglich.

Wo ist der Fehler, was habe ich übersehen?

Was müsst Ihr noch wissen?

Danke

Also nichts was mich stört.

Diese Meldung:

Speicherplatz für das 'dbo.WMICollectedData'.'PK_WMICollectedData'-Objekt in der SBSMonitoring-Datenbank konnte nicht belegt werden, da die Dateigruppe 'PRIMARY' voll ist. Speicherplatz kann durch Löschen nicht benötigter Dateien, Löschen von Objekten in der Dateigruppe, Hinzufügen von Dateien zur Dateigruppe oder Festlegen der automatischen Vergrößerung für vorhandene Dateien in der Dateigruppe gewonnen werden.

Sollte hierfür unbedenklich sein.

Diese Meldung:

Prozess MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1952). Der Exchange Active Directory-Anbieter hat keine DNS-Einträge für die Gesamtstruktur DC=CETA,DC=local erhalten. DNS-Priorität und -Gewichtung für die globalen Katalogserver in dieser Gesamtstruktur werden auf die Standardwerte  0 (Priorität) und 100 (Gewichtung) festgelegt.

ist eine Folge das nicht funktionierenden Servers. Das das Problem der DNS, da bin ich mir zimlich sicher. Das ergibt meiner Meinung nach der DCDIAG Fehler mit dem uminösen Host der nicht aufgelöst werden kann.

Der Best Practice gibt diverse FM raus:

Titel:
Der Domänencontroller muss als LDAP-Server für die Domäne am zugehörigen lokalen Standort angekündigt werden.

Datum:
30.10.2015 17:04:47

Kategorie:
Konfiguration

Problem:
Der DNS-Dienst-Ressourceneintrag (SRV) "LdapAtSite", mit dessen Hilfe der Domänencontroller als verfügbarer LDAP-Server für die Domäne am zugehörigen lokalen Standort angekündigt wird, ist nicht registriert. Dieser Eintrag muss für alle beschreibbaren Domänencontroller und schreibgeschützten Domänencontroller (RODCs) registriert werden.

Auswirkung:
Der Domänencontroller wird von anderen Mitgliedscomputern und Domänencontrollern in der Domäne oder Gesamtstruktur am lokalen Standort nicht als LDAP-Server erkannt. Das Bereitstellen der gesamten Sammlung von Diensten ist mithilfe dieses Domänencontrollers nicht möglich.

Lösung:
Stellen Sie sicher, dass "LdapAtSite" weder über die Gruppenrichtlinie noch über die Registrierung in der Liste "DnsAvoidRegisteredRecords" konfiguriert ist. Starten Sie den Anmeldedienst neu. Stellen Sie sicher, dass der DNS-Dienst-Ressourceneintrag (SRV) "_ldap._tcp.Standardname-des-ersten-Standorts._sites.CETA.local", der auf den lokalen Domänencontroller "SBS2011.CETA.local" zeigt, in DNS registriert ist.

Weitere Informationen zu dieser bewährten Methode und den detaillierten Lösungsverfahren: http://go.microsoft.com/fwlink/?LinkId=126958

Und diverse andere, dass das AD gestört ist.

Titel:
Der Domänencontroller muss als KDC für die Domäne am zugehörigen lokalen Standort angekündigt werden.

Schweregrad:
Fehler

Datum:
30.10.2015 17:04:47

Kategorie:
Konfiguration

Problem:
Der DNS-Dienst-Ressourceneintrag (SRV) "KdcAtSite", mit dessen Hilfe der Domänencontroller als verfügbarer KDC-Server (Key Distribution Center, Schüsselverteilungscenter) für die Domäne angekündigt wird, ist nicht registriert. Dieser Eintrag muss von allen KDC-Servern in der Domäne registriert werden.

Auswirkung:
Der Domänencontroller wird von anderen Mitgliedscomputern und Domänencontrollern in der Domäne oder Gesamtstruktur am lokalen Standort nicht als KDC-Server erkannt. Das Bereitstellen der gesamten Sammlung von Diensten ist mithilfe dieses Domänencontrollers nicht möglich.

Lösung:
Stellen Sie sicher, dass "KdcAtSite" weder über die Gruppenrichtlinie noch über die Registrierung in der Liste "DnsAvoidRegisteredRecords" konfiguriert ist. Starten Sie den Anmeldedienst neu. Stellen Sie sicher, dass der DNS-Eintrag "_kerberos._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs.CETA.local", der auf den lokalen Domänencontroller "SBS2011.CETA.local" zeigt, in DNS registriert ist.

Weitere Informationen zu dieser bewährten Methode und den detaillierten Lösungsverfahren: http://go.microsoft.com/fwlink/?LinkId=126955

Titel:
Der Server muss sich selbst als Domänencontroller für die Domäne am zugehörigen lokalen Standort ankündigen.

Schweregrad:
Fehler

Datum:
30.10.2015 17:04:47

Kategorie:
Konfiguration

Problem:
Der DNS-Dienst-Ressourceneintrag (SRV) "DcAtSite", mit dessen Hilfe dieser Server als verfügbarer Domänencontroller für die Domäne am zugehörigen lokalen Standort angekündigt wird, ist nicht registriert. Dieser Eintrag muss von allen beschreibbaren und schreibgeschützten Domänencontrollern (RODCs) in der Domäne registriert werden.

Auswirkung:
Der Domänencontroller wird von anderen Mitgliedscomputern und Domänencontrollern in der Domäne oder Gesamtstruktur am lokalen Standort nicht erkannt. Das Bereitstellen der gesamten Sammlung von Diensten ist mithilfe dieses Domänencontrollers nicht möglich.

Lösung:
Stellen Sie sicher, dass "DcAtSite" weder über die Gruppenrichtlinie noch über die Registrierung in der Liste "DnsAvoidRegisteredRecords" konfiguriert ist. Starten Sie den Anmeldedienst neu. Stellen Sie sicher, dass der DNS-Dienst-Ressourceneintrag (SRV) "_ldap._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs.CETA.local", der auf den lokalen Domänencontroller "SBS2011.CETA.local" zeigt, in DNS registriert ist.

Weitere Informationen zu dieser bewährten Methode und den detaillierten Lösungsverfahren: http://go.microsoft.com/fwlink/?LinkId=126974

Titel:
Der Domänencontroller muss sich selbst als Kerberos-Server für die Domäne am zugehörigen lokalen Standort ankündigen.

Schweregrad:
Fehler

Datum:
30.10.2015 17:04:47

Kategorie:
Konfiguration

Problem:
Der DNS-Dienst-Ressourceneintrag (SRV) "Rfc1510KdcAtSite", mit dessen Hilfe dieser Domänencontroller als verfügbarer Kerberos-Server für die Domäne am zugehörigen lokalen Standort angekündigt wird, ist nicht registriert. Dieser Eintrag muss von allen Kerberos-Servern in der Domäne registriert werden.

Auswirkung:
Der Domänencontroller wird von anderen Mitgliedscomputern und Domänencontrollern in der Domäne oder Gesamtstruktur am lokalen Standort nicht als Kerberos-Server erkannt. Das Bereitstellen der gesamten Sammlung von Diensten ist mithilfe dieses Domänencontrollers nicht möglich.

Lösung:
Stellen Sie sicher, dass "Rfc1510KdcAtSite" weder über die Gruppenrichtlinie noch über die Registrierung in der Liste "DnsAvoidRegisteredRecords" konfiguriert ist. Starten Sie den Anmeldedienst neu. Stellen Sie sicher, dass der DNS-Eintrag "_kerberos._tcp.Standardname-des-ersten-Standorts._sites.CETA.local", der auf den lokalen Domänencontroller "SBS2011.CETA.local" zeigt, in DNS registriert ist.

Weitere Informationen zu dieser bewährten Methode und den detaillierten Lösungsverfahren: http://go.microsoft.com/fwlink/?LinkId=126963

Titel:
Der Domänencontroller muss sich selbst als generischer globaler Katalogserver für die Gesamtstruktur am zugehörigen lokalen Standort ankündigen.

Schweregrad:
Fehler

Datum:
30.10.2015 17:04:47

Kategorie:
Konfiguration

Problem:
Der DNS-Dienst-Ressourceneintrag (SRV) "GenericGcAtSite", mit dessen Hilfe dieser Domänencontroller als verfügbarer generischer globaler Katalogserver für die Gesamtstruktur am zugehörigen lokalen Standort angekündigt wird, ist nicht registriert. Dieser Eintrag muss von allen globalen Katalogen und schreibgeschützten globalen Katalogen in der Gesamtstruktur registriert werden.

Auswirkung:
Der Domänencontroller wird von anderen Mitgliedscomputern und Domänencontrollern in der Domäne oder Gesamtstruktur am lokalen Standort nicht als generischer globaler Katalogserver erkannt. Das Bereitstellen der gesamten Sammlung von Diensten ist mithilfe dieses Domänencontrollers nicht möglich.

Lösung:
Stellen Sie sicher, dass "GenericGcAtSite" weder über die Gruppenrichtlinie noch über die Registrierung in der Liste "DnsAvoidRegisteredRecords" konfiguriert ist. Starten Sie den Anmeldedienst neu. Stellen Sie sicher, dass der DNS-Dienst-Ressourceneintrag (SRV) "_gc._tcp.Standardname-des-ersten-Standorts._sites.CETA.local", der auf den lokalen Domänencontroller "SBS2011.CETA.local" zeigt, in DNS registriert ist.

Weitere Informationen zu dieser bewährten Methode und den detaillierten Lösungsverfahren: http://go.microsoft.com/fwlink/?LinkId=126961

Titel:
Der Domänencontroller muss als globaler Katalogserver für die Gesamtstruktur am zugehörigen lokalen Standort angekündigt werden.

Schweregrad:
Fehler

Datum:
30.10.2015 17:04:47

Kategorie:
Konfiguration

Problem:
Der DNS-Dienst-Ressourceneintrag (SRV) "GcAtSite", mit dessen Hilfe dieser Domänencontroller als verfügbarer globaler Katalogserver für die Domäne am zugehörigen lokalen Standort angekündigt wird, ist nicht registriert. Dieser Eintrag muss von allen beschreibbaren und schreibgeschützten globalen Katalogen in der Gesamtstruktur registriert werden.

Auswirkung:
Der Domänencontroller wird von anderen Mitgliedscomputern und Domänencontrollern in der Domäne oder Gesamtstruktur am lokalen Standort nicht als globaler Katalogserver erkannt. Das Bereitstellen der gesamten Sammlung von Diensten ist mithilfe dieses Domänencontrollers nicht möglich.

Lösung:
Stellen Sie sicher, dass "GcAtSite" weder über die Gruppenrichtlinie noch über die Registrierung in der Liste "DnsAvoidRegisteredRecords" konfiguriert ist. Starten Sie den Anmeldedienst neu. Stellen Sie sicher, dass der DNS-Diensteintrag (SRV) "_ldap._tcp.Standardname-des-ersten-Standorts._sites.gc._msdcs.CETA.local", der auf den lokalen Domänencontroller "SBS2011.CETA.local" zeigt, in DNS registriert ist.

Weitere Informationen zu dieser bewährten Methode und den detaillierten Lösungsverfahren: http://go.microsoft.com/fwlink/?LinkId=126953

Titel:
Vom Domänencontroller müssen die Ressourceneinträge des zugehörigen DNS-Hosts (A oder AAAA) für die Domäne registriert werden.

Schweregrad:
Fehler

Datum:
30.10.2015 17:04:47

Kategorie:
Konfiguration

Problem:
Die DNS-Datensätze (A/AAAA) für "LdapIpAddress", mit deren Hilfe der Domänencontroller als verfügbarer LDAP-Server in der Domäne angekündigt wird und die auf die zugehörigen IPv4- oder IPv6-Adressen zeigen, sind nicht registriert. Diese Einträge müssen von allen beschreibbaren Domänencontrollern in der Domäne (jedoch nicht von schreibgeschützten Domänencontrollern, RODCs) registriert werden.

Auswirkung:
Der Domänencontroller wird von anderen Mitgliedscomputern und Domänencontrollern in der Domäne oder Gesamtstruktur nicht als beschreibbarer LDAP-Server (Lightweight Directory Access-Protokoll) erkannt. Das Bereitstellen der gesamten Sammlung von Diensten ist mithilfe dieses Domänencontrollers nicht möglich.

Lösung:
Stellen Sie sicher, dass "LdapIpAddress" weder über die Gruppenrichtlinie noch über die Registrierung in der Liste "DnsAvoidRegisteredRecords" konfiguriert ist. Starten Sie den Anmeldedienst neu. Stellen Sie sicher, dass die Ressourceneinträge "CETA.local" für den Host (A/AAAA), die auf die IP-Adressen des lokalen Computers zeigen, in DNS registriert sind.

Weitere Informationen zu dieser bewährten Methode und den detaillierten Lösungsverfahren: http://go.microsoft.com/fwlink/?LinkId=126970

Titel:
Der Domänencontroller muss als LDAP-Server für die Domäne angekündigt werden.

Schweregrad:
Fehler

Datum:
30.10.2015 17:04:47

Kategorie:
Konfiguration

Problem:
Der DNS-Dienst-Ressourceneintrag (SRV) "Ldap", mit dessen Hilfe der Domänencontroller als verfügbarer LDAP-Server für die Domäne angekündigt wird, ist nicht registriert. Dieser Eintrag muss von allen beschreibbaren Domänencontrollern (jedoch nicht von schreibgeschützten Domänencontrollern, RODCs) registriert werden.

Auswirkung:
Der Domänencontroller wird von anderen Mitgliedscomputern und Domänencontrollern in der Domäne oder Gesamtstruktur nicht als beschreibbarer LDAP-Server (Lightweight Directory Access-Protokoll) erkannt. Das Bereitstellen der gesamten Sammlung von Diensten ist mithilfe dieses Domänencontrollers nicht möglich.

Lösung:
Stellen Sie sicher, dass "Ldap" weder über die Gruppenrichtlinie noch über die Registrierung in der Liste "DnsAvoidRegisteredRecords" konfiguriert ist. Starten Sie den Anmeldedienst neu. Stellen Sie sicher, dass der DNS-Dienst-Ressourceneintrag (SRV) "_ldap._tcp.CETA.local", der auf den lokalen Domänencontroller "SBS2011.CETA.local" zeigt, in DNS registriert ist.

Weitere Informationen zu dieser bewährten Methode und den detaillierten Lösungsverfahren: http://go.microsoft.com/fwlink/?LinkId=126957

Titel:
Von diesem Domänencontroller muss ein DNS-SRV-Ressourceneintrag registriert werden, der für die ordnungsgemäße Funktion der Replikation erforderlich ist.

Schweregrad:
Fehler

Datum:
30.10.2015 17:04:47

Kategorie:
Konfiguration

Problem:
Der DNS-Dienst-Ressourceneintrag (SRV) "DcByGuid", mit dessen Hilfe der Server als verfügbarer Domänencontroller in der Domäne angekündigt und die ordnungsgemäße Replikation sichergestellt wird, ist nicht registriert. Dieser Eintrag muss von allen Domänencontrollern (jedoch nicht von schreibgeschützten Domänencontrollern, RODCs) in der Domäne registriert werden.

Auswirkung:
Der Domänencontroller wird von anderen Mitgliedscomputern und Domänencontrollern in der Domäne oder Gesamtstruktur nicht gefunden. Das Bereitstellen der gesamten Sammlung von Diensten ist mithilfe dieses Domänencontrollers nicht möglich.

Lösung:
Stellen Sie sicher, dass "DcByGuid" weder über die Gruppenrichtlinie noch über die Registrierung in der Liste "DnsAvoidRegisteredRecords" konfiguriert ist. Starten Sie den Anmeldedienst neu. Stellen Sie sicher, dass der DNS-Dienst-Ressourceneintrag (SRV) "_ldap._tcp.e2cf040d-50f4-4283-ac2c-4c3c7b270ea0.domains._msdcs.CETA.local", der auf den lokalen Domänencontroller "SBS2011.CETA.local" zeigt, in DNS registriert ist.

Weitere Informationen zu dieser bewährten Methode und den detaillierten Lösungsverfahren: http://go.microsoft.com/fwlink/?LinkId=126968

Liest sich so, als wäre der DNS komplett ausgefallen. Ist er aber nicht. Alle Rechner lösen alle (internen und externen) Adressen auf. Möchte sich egal welcher Client auf ein Netzlaufwerk eines Mitgliedsservers verbinden. Kann man dieses nur per Administrator der Domäne verbinden.

WAs mich wundert ist, dass im DNS z.B. unter _msdcs.domäne.local keine weiteren reiter mehr sind. sollte hier nicht sowas wie "site" und "tcp" als ordner zu finden sein?

Ja, nur er selbst.

Es wurde gesucht, aber da der Server produktiv ist dann zurückgesichert. Nur tritt der Fehler immer wieder auf. Könnten am Wochenende wieder zurücksichern. Aber das ist ein Workaround und keine Lösung

Mir sagt der Fehler auch nichts. Habe schon DNS deinstalliert und neu installiert. Netlogon gestoppt und gestartet, ipconfig /registerdns auch. Bringt aber alles nichts. Ich denke es ist ein DNS problem, aber welches finde ich einfach nicht raus

Hallo,

wir haben einen SBS2011 am laufen, welcher plötzlich nicht mehr als DC zu erreichen ist und fungiert.

Ich bekommen bei DCDIAG folgende Meldung, mit welcher ich aber nichts anfangen kann:

Server wird getestet: Standardname-des-ersten-Standorts\SBS2011
   Starting test: Connectivity
      Der Host bc378b5f-0c40-4e33-8d46-023552dd35db._msdcs.CETA.local konnte
      nicht zu einer IP-Adresse aufgelöst werden. Überprüfen Sie DNS-Server,
      DHCP, Servername, usw.
      Fehler beim Überprüfen der LDAP- und RPC-Konnektivität. Überprüfen Sie
      die Firewalleinstellungen.
      ......................... SBS2011 hat den Test Connectivity nicht
      bestanden.

Ich habe keine Ahnung, was das für ein Host sein soll. Trage ich ihn  zum testen im DNS als A Host ein mit der Adresse des DC (192.168.16.200) geht es auch nicht.

Was müsst Ihr wissen? Was kan das sein?

Problem ist vor 2 Wochen und vor 3 Wochen schon mal aufgetreten (auch über Nacht) und konnte nur mit Backup WQiederherstellung behoben werden. Ist aber nicht befriedigend.

Danke

Wenn ich einen weiteren DC hochstufe, habe ich nur 30 Tage um den SBS abzulösen. Das wollte ich aus Zeitgründen anders herum machen. Hat ja auch eine ganze weile geklappt. Seit heute Nacht sieht das anders aus. Da ich an den Exchange nicht mehr dran komme, kann ich die Konten auch nicht wieder zurück verschieben, was, meine ich, auch nicht mehr geht, wenn die einmal zu einem Exchange 2013 verschoben wurden.

Normalfall geht hier also leider nicht. Laut Frankysweb sollte es aber auch so herum gehen.

Da es ein SBS ist, gibt es nur Member. Der 2. Exchange ist der erste Schritt um den SBS abzulösen. Dafür muss ich als erstes den Exchange umziehen. Das habe ich mit 8 Usern gemacht., zum Testen. Nun geht er plötzlich nicht mehr

Der 2. DNS ist schon hier gewesen, als ich anfing. Habe es nie geändert, damit ein 2. da ist, wenn dem einen mal "was passiert"

Redundanz :-)

Ich hatte gesagt, fragt was Ihr wissen wollt. Ich habe einen DC, einen SBS2011. Der ist auch DNS. Ein weiterer Mitgliedsserver ist 2. DNS. Beie sind an dem Server welcher nicht geht als primärer und sekundärer DNS eingetragen. Ich habe nach den änderungen den Exchange 2013 neu gestartet. Nun macht er wieder das selbe wie vorher. Ich öffner die Management Console, es kommt die Anmeldung und dann bleibt nach eingabe der Credentials das Fenster weiss. Öffne ich die Shell, versucht er auf den Exchange 2013 zu verbinden und es kommt folgende FM:

AUSFÜHRLICH: Verbindung mit CETASERVER002.CETA.local wird hergestellt.
New-PSSession : [cetaserver002.ceta.local] Beim Verarbeiten von Daten vom Remoteserver "cetaserver002.ceta.local" ist
folgender Fehler aufgetreten: Der WinRM Shell-Client kann die Anforderung nicht verarbeiten. Das an die Funktion
"WSMan Shell" übergebene Shellhandle ist ungültig. Das Shellhandle ist nur gültig, wenn die Funktion
"WSManCreateShell" erfolgreich abgeschlossen wird. Schließen Sie ein gültiges Shellhandle in die Anforderung ein, und
wiederholen Sie den Vorgang. Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting".
In Zeile:1 Zeichen:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
   gTransportException
    + FullyQualifiedErrorId : -2144108212,PSSessionOpenFailed

Das macht er 2 mal, dann verbindet edie shell zum Exchange auf dem SBS

Nach dem Neustart des Exchange 2013 ist das Eventlog, wie vorher auch schon, Fehlerfrei

Also das mit Der Zeit hat eine Änderung gebracht :-) Danke an NorbertFe. Der Host der Virtuellen Maschine hatte eine um eine Stund versetzte Zeit. Alles geändert. Der DC ist nun Zeitursprung für alles.

Nun die Adminconsole Exchange wieder gestartet und es kommt folgende Meldung:

Dazu soll man die GPO ändern und die Exchange Server hinzufügen. Die sind aber schon da.

Idee??? :-)

Eigentlich habe ich volle konnektivität. Ping auf DC, auf Domäne, auf Internet, auf jeden Rechner im Netz.

Habe gerade festgestellt, Pinge ich den Server in der DOS Box mit Namen, wird er aufgelöst und es kommt eine Antwort mit der richtigen IP. per nslookup auch. Gebe ich \\[sERVERNAME] in einen Explorer ein, um die Shares zu sehen, findet er ihn  nicht und löst nicht auf. mit \\[iP-Adresse] geht es. Selektive DNS Auflösung quasi.

Keine Fehler im Ereignisprotokoll.

Im Vsphere kann man einen Server mit "Migrieren" von einem Host auf den anderen umziehen

Hallo zusammen,

hier erst einmal rudimentäre Infos zur Umgebung:

SBS2011 mit Exchange 2010. AD alle Rollen

Mitgliedsserver 2013 mit Exchange 2012

Alle virtualisiert mit VMWare

Der Server 2012 ist mit dem VMWare Migrationstool auf einen anderen Host umgezogen (ich weis aber nicht, ob das die Ursache ist oder nur Zufall)

Server hat alte IP, ist Mitgliedsserver in der Domäne. Exchange auf diesem Server ist nicht zu erreichen. Es befinden sich 8 User auf dem 2013er Exchange.

Auch lokal am Server kann weder die Managementkonsole noch die Managementshell auf den Exchange zugreifen.

Ich habe alles schon ca 100 mal durchgesehen, ich finde keinen Fehler.

Welche Informationen braucht Ihr ?

Danke für eure Hilfe.

Ingo

Keiner eine Idee? Ich habe inzwischen festgestellt, dass Mails nach draußen irgendwann doch geschickt werden. Aber es ist immer stark verzögert. Zwischen den beioden Servern gibt es immer noch keine Kommunikation.