Domainbeitritt scheitert - Fehler 0x3a im NetSetup.log
- 19.04.2015 - 17:54
Link zu diesem Beitrag: | |||||
| Fehler beim Domänenbeitritt Umgebung: Windows 7 Professional Client (aktuell gepatched) Windows Server 2012 R2 (aktuell gepatched) inkl. AD DS und DNS Fremdhersteller DNS-Server mit AD-fremden Namespace Via DHCP wird der Domain Suffix des AD-fremden Namespaces an die Clients verteilt "Fehler beim Ändern des DNS-Namens für die primäre Domäne dieses Computers in "". Name "[..]" wird beibehalten. Fehler: Der angegebene Server kann den angeforderten Vorgang nicht ausführen." Der DomainJoin als solcher funktioniert wohl, da das Computerobjekt im Active Directory erstellt. Die Registrierung des DNS-Eintrages scheitert aber. Im Logfile "NetSetup.log" unter "C:\Windows\Debug" gibt es u. A. folgenden Fehler: NetpLdapBind: ldap_bind failed on \\ Tatsächlich ist der Domaincontroller aktiv und langweilt sich. Sicherheitshalber die Domaincontroller abwechselt neu gestartet. In aller Regel deutet dieser Fehler auf Netzwerkkonnektivitätsprobleme hin: siehe https://support.microsoft.com/en-us/kb/2018583 Analyse mittels PortQry (http://www.microsoft.com/en-us/download/details.aspx?id=17148) auf dem Client gegen den Domaincontroller bescheinigte aber einwandfreie Konnektivität. Ebenfalls wurde die Clientfirewall temporär deaktiviert, die Maßnahme half leider auch nicht. Auch eine Kürzung des Computernamens ergab keine Besserung. Die kurzfristige Lösung war schließlich folgende: - Hinzufügen des AD-Domain-Namespaces zur DNS-Suffix-Liste des Netzwerkadapters Hiermit wurde der Domainbeitritt zwar erfolgreich abgeschlossen, dennoch blieb der FQDN des Hostnamen weiterhin auf dem Namespace der AD-fremden DNS-Zone definiert. Nach einiger Recherche wurde klar, dass einige lokale Richtlinien definiert wurden, und zwar im Bereich Computerkonfiguration > Administrative Vorlagen > Netzwerk > DNS-Client. Die Richtlinie "Primäres DNS-Suffix" war mit einem Wert vorgegeben worden. (korrespondierender Registry-Pfad: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System\DNSClient) Selbst durch einen Domänenbeitritt ändert sich der FQDN der Maschine nicht, wenn die Richtlinie aktiviert ist. Da auch noch einige andere verstellt waren, wurden folgende Schritte unternommen:
Nach einem weiteren Neustart des Systems, wurde erneut einen manuellen DomainJoin durchgeführt. Siehe da, ohne Fehler und mit korrektem FQDN. 
Über den Autor
Thomas Windscheif arbeitet bei excITe Consulting und ist langjähriger Berater im Bereich IT-Infrastruktur und Groupware. Sowohl Kleinunternehmen z. B. im Handwerk als auch der größere fertigende Mittelstand gehören zu seinem Projektumfeld. Im Wesentlichen gehören die Planung von Infrastruktur-Migrationen, Cloud-Lösungen (Microsoft 365), Groupware-Umgebungen (z. B. Exchange) und deren Umsetzung zu seinen Aufgaben. Insbesondere im Umfeld hybrider Identitätsumgebungen mit Entra Connect und den Möglichkeiten zur Härtung der IT-Landschaft konnte er in vielen Projekten Erfahrungen sammeln. Neues begeistert ihn aber ebenso und so unterstützt Thomas Windscheif auch bei themenfremden IT-Systemen, überall da wo er helfen kann. Sein Ziel: Die Mehrwerte der heutigen IT-Lösungen für einfacheres und modernes Arbeiten beim Kunden einbringen.
|
 Sie haben ein ungelöstes Problem in Ihrer Exchange Server/Microsoft-Infrastruktur oder unter Microsoft 365?Treten Sie gerne mit mir in Kontakt. Sowohl bei einfachen Umgebungen, als auch bei komplexen Multisite/Cloud-Topologien unterstütze ich Sie -auch kurzfristig- sehr gerne. Nutzen Sie den Live Chat, xing, LinkedIn, das Kontaktformular oder den Mailkontakt | ||
|
[
 News als RSS-Feed abonnieren]News vom 22.09.2024 - 14:29 - Spontaner Administrationsverlust unter Exchange Online - Und wie man es behebt! - Weitere News: UPDATE - PowerShell Exchange Vererbung Postfachordnerberechtigungen
[alle News auflisten] |