Jump to content

koem@

Members
  • Content Count

    102
  • Joined

  • Last visited

Everything posted by koem@

  1. Das war auch meine Favoritenidee. Danke daabm! Das Equipment hängt zwar nicht direkt am PC, das bekomme ich aber hin. Ich werde wohl wirklich einen Benutzer auf den betreffenden (oder auf allen) Rechnern erstellen (per GPO?) und dann ein Abmeldescript erstellen, welches die generierten Daten auf einen Share der Domäne verteilt.
  2. Hallo zusammen. Ich habe folgendes Problem. Wir stellen Geräte her, mit welchen etwas getestet wird. Unser Service und unsere Produktion muss diese Geräte vor der Auslieferung ausgiebig testen und Kalibrieren. Diese Tests können schon mal mehrere Tage dauern. Nun kann es passieren, dass ein User, welcher diesen Test laufen lässt, ausfällt. Dadurch kann sich, würden die Kennwörter geheim gehalten werden, kein anderer am System anmelden und auf die Tests, die Ergebnisse und Ähnliches zugreifen. Aus diesem Grund hat mein Vorgänger auch keine Kennwortrichtlinie eingeführt. Dies möchte ich aber tun und dabei aber die Arbeitsabläufe der Abteilungen nicht beeinträchtigen. Aus diesem Grund überlege ich, Benutzerkennungen zu erstellen, welche von mehreren Usern genutzt werden. Diese haben dann nur die Berechtigung, auf ein Verzeichnis im Netzt zugreifen zu können. Oder es werden lokale Kennungen, die auch nur lokal schreiben können. Beides gefällt mir aber eigentlich auch nicht. Und nun kommt Ihr, gibt es noch andere Möglichkeiten und wenn ja, welche? Umgebung: AD, 2 DC, Win Server 2012 R2, WIN 7 und WIN 10 Clients, Ist hierfür noch was nötig? Dann Fragen. Danke allen im Voraus
  3. Habe ich, aber die Deinstallation ist wohl gelinde gesagt MIST. Der Agent war trotzdem noch da. Werde mal ein Wörtchen mit denen reden und den Mist kündigen. Jawohl. Werde ich machen
  4. Ich habe es gefunden und der Server läuft wieder. In meinem Fall war es der Avast Antivir. In der Exchange Management Shell findet man mit get-transportagent alle gestarteten Transport Agents. Ich habe, weil der Microsoft Transportdienst sich immer beendet hat den Avast verdächtigt. Hier fand ich "avast antispam for exchange" als Fehlermeldung im Eventlog. Diesen konnte ich aber mit disable-transportagent "avast antispam for exchange" beenden, weil er nicht dort war. Bei der suche fand ich aber den oben genannten Agenten, welchen ich mit disable-transportagent "avast plugin for exchange" beendete. Anschließend den Exchange Transportdienst starten und sofort wurden alle Mails zugestellt. Mit dem Exchange Toolkit konnte ich sofort sehen, wie sich die Warteschlangen geleert haben. Ich hoffe, das nützt anderen auch. Danke allen hier für die Hilfe. MFG Ingo
  5. Nein, auch nicht. Überhaupt kein Mail. Nicht rein, nicht raus, nicht von Kollege zu Kollege. Sonstige Konnektivität klappt. OWA, Outlook, Active Sync, Console
  6. Den Port sehe ich nur bei den Empfangsconnectoren unter "ClientProxy [SERVERNAME]" bei den Bereichsdefinitionen. Könntest Du Hellsehen, was ich für dich echt Cool fände, dann wärest Du wars***einlich DagobertDuckReich und würdest auf deiner eigenen Insel wohnen. *** bei wahrscheinlich? Was ich da wohl getippt habe???? Aaaah. ohne "h" entsteht ein a r s c h. LOL
  7. Norbert, DAS war meine erste Idee. Kannte den Fehler, weil ich den irgendwann mal bei Franky gelesen hatte. Reverse lookup läuft wie geschmiert. Fehler im Send Log lautet: 2018-11-13T10:22:01.488Z,Sendeconnector für Clientproxy,08D648D30CE3E545,1,,172.100.6.2:465,*,,"Failed to connect. Winsock error code: 10061, Win32 error code: 10061, Error Message: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 172.100.6.2:465" Beim Senden. Als DNS ist primär der erste DC als sekundär der zweite DC eingetragen. Haben weder den Router (FritzBox) oder einen externen als irgendeinen DNS eingetragen. Im DNS allerdings und natürlich eine Weiterleitung an den Router Die IP ist der Server selbst. Es geht um das interne senden. Scheinbar verweigert er sich gegen sich selbst (wie in jeder guten Ehe )
  8. Gut, das ist der Status Quo! Würde nun gerne, wenn das Update auf CU22 nicht unumgänglich ist (siehe meinen Post oben) mit dir durchgehen, ob ich etwas übersehen habe. Da der Server wieder auf dem Stand vor den Updates ist, befürchte ich, das er bei den beiden DC's liegt. Aber sicher bin ich mir nicht, weil die beiden meines Erachtens auch richtig funktionieren. Bin also für jede Idee offen und probiere gerne alles aus.
  9. Ja Nobby, das habe ich befürchtet. CU 22 habe ich schon einmal auf einer Testmaschiene versucht und das Ding dabei komplett zerlegt Von wegen perfekte Welt. Das Problem hier in der Firma ist Zeit. Die gibt es nicht. Noch nicht einmal um ein Update aus CU22 richtig zu testen. Meinst Du wirklich, dass kein Weg drum herum führt?
  10. Damit habe ich gerechnet. Ein Update auf CU22 ist zur Zeit nicht möglich. Keine Chance, aus betrieblichen Gründen. Er hat aber auch bist Freitag so funktioniert. Die Lösung mit POPcon ist hier durch das Unternehmen so entschieden worden. Kann ich nicht ändern. Muss ich auch nicht. Ist es wirklich relevant? Wäre diese Welt perfekt, müsste ich nicht Fragen, weil es perfekt wäre. Dann wäre dieses Forum auch obsolet. Du bist ein Profi, sogar ein wirklich guter, aber aus fast 30 Jahren IT Erfahrung weiß ich, und Du weist das auch, dass es auf jeder Baustelle anders ist. Da unser System am Freitag noch funktioniert hat, sollte es auch heute noch gehen. Auch mit CU11. Ich habe wirklich alles ausprobiert, was ich weiss, ohne erfolg. Deswegen Frage ich hier. Und Google spreche ich auch. Habe schon Sachen probiert, die eigentlich Unmöglich sind, weil sie im www standen. Nun Frage ich hier, weil Ihr gut seid und ich mit meinem Latein und meiner Erfahrung nicht mehr weiter weiss.
  11. Genau, ist hier so entschieden und wird auch nicht geändert. Die VM hat instgesamt 700 GB HDD, wovon genau 448 GB frei sind. Ein Laufwerk c:\ wo somit auch die Queue liegt
  12. 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.
  13. 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.
  14. 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? In welchen? Wir haben einfach da Backup von Freitag Nacht zurückgespielt und die VM überschrieben.
  15. 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
  16. 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
  17. 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!!!
  18. 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
  19. 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
  20. 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]
  21. Norbert, das ist mal ne Aussage. Dann mache ich mal weiter :-) Danke!
  22. Norbert, ist also Normal und ich kann es ignorieren?
  23. 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
  24. 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?
×
×
  • Create New...