none
ERR_NETWORK_UNREACHABLE (1231) - keine Verbindung vom DC zu anderen PCs RRS feed

  • Allgemeine Diskussion

  • Hallo,

    folgende Situation: in meinem kleinen lokalen Netz gibt es

    - Rechner 1 (Orion3) mit Win Server 2012 R2 - Domänencontroller
      darauf Hyper-V-Server 2012 R2 (Jupiter3)

    - Rechner 2 (Sonne2) mit Win 8.1
      darauf VMWare Workstation Maschine Win Server 2008 R2 (Saturn2)

    - Notebook (Metaluna4) mit Win 8.1

    Bis gestern Mittag konnte ich wunderbar von Orion3 auf die freigegebenen Verzeichnisse auf Sonne2 zugreifen. Die gemappten Laufwerke funktionierten einwandfrei.

    Leider änderte sich dies im Laufe des Nachmittags. Die gemappten Laufwerke auf Orion3 hatten ein rotes Kreuzchen (nicht verfügbar). In der Ereignisanzeige häuften sich GroupPolicy-Fehler mit ErrorCode 1231 ('Die Netzwerkadresse ist nicht erreichbar) immer mit Verweis auf eine Datei in Sysvol (kann man die löschen?).

    Ich nehme an, dass die Änderung im Rahmen der Einrichtung des Hyper-V-Servers, insbesondere bei der Überprüfung der Einstellungen für die 2. Netzwerkkarte, eingetreten sein muss. Hier wurde alles, was zwischenzeitlich geändert wurde, auch wieder zurückgenommen.

    Interessanterweise funktioniert der Zugriff von Sonne2 und Metaluna4 auf Orion3 problemlos. Metaluna4 zeigt sogar Jupiter3 an. Orion3 sieht Saturn2, kann aber nicht auf den dortigen freigegebenen Ordern zugreifen.

    Alle Ausführungen wurden übrigesn unter dem selben Domänenbenutzer gemacht.

    Die Netzwerkerkennung ist auf allen Geräten eingeschaltet.

    Wie schon gesagt, gestern liefs noch. Wraum jetzt nicht?


    Grüße aus Köln am Rhein - Klaus Trapp

    • Typ geändert Alex Pitulice Donnerstag, 29. Mai 2014 10:08 Warten auf Testen
    Mittwoch, 21. Mai 2014 11:54

Alle Antworten

  • Moin,

    der Vollständigkeit halber sei gleich mal gesagt, dass Hyper-V auf einem DC kein unterstütztes Szenario ist.

    Die zweite Netzwerkkarte der Hosts dient einzig und allein für Hyper-V und ist auch nicht für die Verwaltung freigegeben? Sprich es ist sichergestellt, dass der Domänencontroller nicht multihomed ist?

    Vielleicht mal von allen Verdächtigen die wichtigen Informationen posten, die dem Befehl ipconfig /all zu entnehmen sind.

    Kann jede Maschine jede anpingen? Wurden alle mal neu gestartet?

    Falls irgendwo ein Broadcom-Adapter installiert ist, der kürzlich aktualisiert wurde - mal den Treiber zurückrollen. Mit hatte das mal einen Server komplett vom Netz genommen.

    Viele Grüße
    Olaf

    Mittwoch, 21. Mai 2014 12:39
  • Hallo Olaf,
    danke für Deine Bemühungen

    Ping auf Orion3 (2012R2, DC) an Sonne2, Saturn2 und Jupiter3 geht problemlos,

    ping auf Sonne2 (8.1) an Orion3, Jupiter3 und Saturn2 dito
    ping auf Saturn2 (2008R2 VM) an Orion3, Jupiter3 und Sonne2 dito.
    ping auf Jupiter3 (Hyper-V 2012R2) an Orion3, Sonne2 und Saturn2 dito.

    hier ipconfig/all

    Windows-IP-Konfiguration

       Hostname  . . . . . . . . . . . . : Orion3
       Prim„res DNS-Suffix . . . . . . . : trapp.dv
       Knotentyp . . . . . . . . . . . . : Hybrid
       IP-Routing aktiviert  . . . . . . : Nein
       WINS-Proxy aktiviert  . . . . . . : Nein
       DNS-Suffixsuchliste . . . . . . . : trapp.dv

    Ethernet-Adapter Ethernet:

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8056 PCI-E-Gigabit-Ethernet-Controller
       Physische Adresse . . . . . . . . : 00-1D-60-E7-CF-1A
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja
       Verbindungslokale IPv6-Adresse  . : fe80::2452:17:ea7e:b803%12(Bevorzugt)
       IPv4-Adresse  . . . . . . . . . . : 192.168.2.104(Bevorzugt)
       Subnetzmaske  . . . . . . . . . . : 255.255.255.0
       Standardgateway . . . . . . . . . : 192.168.2.1
       DHCPv6-IAID . . . . . . . . . . . : 301997408
       DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1A-F5-0E-F1-00-1D-60-E7-CF-1A
       DNS-Server  . . . . . . . . . . . : ::1
                                           192.168.2.104
                                           192.168.2.1
       NetBIOS ber TCP/IP . . . . . . . : Aktiviert

    Tunneladapter isatap.{7D8AB227-5D01-4BCA-BFCF-58CDA7DA0193}:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
       Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Wozu kann man eigentlich einen PC, auf dem ein DC installiert ist, sonst noch gebrauchen??
    SQL oder Exchange Server geht ja schon mal gar nicht. Etwa als Fileserver?

    Nachtrag:

    1. Gebootet: Orion3 mindestens ein Dutzend mal, Sonne2 mindestens eine halbes Dutzend mal.

    2. Die 2. Netzwerkkarte ist ein Controller der Familie Realtek PCI GBE.

    3. Das Ärgerlichste ist eigentlich, dass es wunderbar funktioniert hat und durch wenige, kaum nachvollziehbare und möglicherweise sogar irreversibler Schritte ruiniert wurde.


    Grüße aus Köln am Rhein - Klaus Trapp


    Mittwoch, 21. Mai 2014 13:24
  • Moin Klaus,

    mir sticht der DNS-Server etwas ins Auge. Erst mal, dass er auf der localhost-IP Adresse für IP v6 bevorzugt lauscht, zum zweiten, haben die Clients den auch als einzigen DNS-Server eingetragen?

    (Ich würde da IP v6 mal ganz rausnehmen.)

    Zum anderen, dass Dein Router da drin steht. Der hat bei Domänenmitgliedern und natürlich auch Controllern nichts an der Stelle zu suchen. Denn wenn das Netzwerkinterface und später AD hochkommt, versuchen die ihre Records beim ersten erreichbaren DNS-Server zu registrieren, und das ist dann nicht der Server (solange AD nicht gestartet ist, kann der integrierte DNS-Server ja auch keine Registrierungen annehmen). Da aber Dein Router damit nix anfangen kann, schlägt die Registrierung fehl. Die Reihenfolge spielt an der Stelle keine Rolle, da sich Windows gern den letzten erfolgreich angesprochenen DNS-Server merkt.

    Du müsstest also dafür sorgen, dass sowohl der Server als auch die Clients nur die IP-Adresse des Domänencontrollers als DNS eingetragen haben und dass der DNS-Server den Router als Forwarder zur Auflösung unbekannter Adressen eingetragen hat. Danach die AD-Dienste oder den Server neu starten.

    Viele Grüße
    Olaf

    Mittwoch, 21. Mai 2014 18:42
  • Hallo Olaf,

    habe auf dem Server und in allen Clients IP6 deaktiviert, den Router als alternativen DNS Server enfernt und schließlich den Router als Weiterleitung für unbekannte Adressen eingerichtet (ohne dies gab's z.B. keinen Store), aber leider ohne Erfolg.

    Ich habe inzwischen mal die eingangs erwähnte Datei aus den Fehlermeldungn in der Ereignisanzeige  angeschaut: \\trapp.dv\sysvol\Policies\{<GUID?>}\Machine\registry.pol.

    Interessanterweise komme ich da von meine Client (Sonne2) problemlos hin während mit das auf der Server nicht gelungen ist. Ich schließe mal aus dem kryptischen Inhalt, dass diese Datei mit Zertifikaten und EFS zu tun hat; dort fand ich u.a.:  S o f t w a r e \ P o l i c i e s \ M i c r o s o f t \ S y s t e m C e r t i f i c a t e s \ E F S

    Möglicherweise hat es damit zu tun, dass ich vor einigen Tagen auf dem DC den Zertifikatsdienst installiert haben. (Vermutlich kommt jetzt wieder, dass das Szenario DC und AD CS nicht unterstützt wird.) Ich wollte dies für das App 'My Server 2012 R2' nutzen. Nach langwierigen Versuchen und komplizierten Anleitungen habe dann auch wohl ein RootCA-Zertifikat produziert aber ohne den gewünschten Erfolg. Auf dem Client (Sonne2) habe ich ein Zertifikat vorgefunden (Token Signing Public Key), dass vorgestern ablief, also in der Zeit, in der der Zugriff vom Server aus (Orion3) nicht mehr funktionierte. Kann das damit zusammenhängen?

    Übrigens: auf meine Client-PC ist ein Broadcom-Netzwerkkarte, Treiberdatum 29.1.13; das wird's wohl kaum sein. Und nochmals: bis vorgestern Mittag lief es.


    Grüße aus Köln am Rhein - Klaus Trapp


    • Bearbeitet Klaus Trapp Donnerstag, 22. Mai 2014 09:33
    Donnerstag, 22. Mai 2014 08:48
  • Noch eine Frage: hängt bei einer der Maschinen die Systemzeit (Datum, Uhrzeit, Zeitzone) zurück oder rennt sie voraus?

    Viele Grüße
    Olaf

    Donnerstag, 22. Mai 2014 20:45
  • Hallo Olaf,

    meine Rechner ticken alle gleich, wie man bei der Minutenumschaltung auf den verschiedenen Bildschirmschonern und Zeitanzeigen sehen kann und alle haben auch UTC-01:00 als Zeitzone.


    Grüße aus Köln am Rhein - Klaus Trapp

    Freitag, 23. Mai 2014 06:02
  • Moin Klaus,

    gut, denn Zeitabweichungen von mehr als 5 Minuten führen zu Kommunikationsproblemen, weil der Zeitstempel Teil der verschlüsselten Kommunikation ist.

    Also zurück zu 1231. Hast Du mal wie empfohlen bei allen Maschinen das IP v6-Protokoll in den Eigenschaften des Netzwerkadapters deaktiviert?

    Client für Microsoft Netzwerk ist aktiv?

    Der virtuelle Netzwerkadapter ist nicht fürs Management freigegeben? (Ich vermute zwar, dass das so ist, da er sonst bei IPCONFIG /all aufgetaucht wäre, aber besser noch mal nachgefragt.)

    Wie ist die Reihenfolge der Bindungen der Netzwerkkarten (Netzwerk- und Freigabecenter/Adaptereinstellungen - Menü Erweitert-Erweiterte Einstellungen. (wenn kein Menü sichtbar, dann mal kurz Alt antippen)

    Dort sollte der aktive Netzwerkadapter aller beteiligten Geräte ganz oben stehen, und natürlich auch IP v4, falls da mehrere Einträge vorhanden sind.

    In der Eingabeaufforderung der Problemmaschine den folgenden Befehl aufrufen:

    nslookup

    Wird die IP des Servers korrekt angezeigt als DNS-Server?

    Dann versuche, ob sich a) der Servername, b) der Domänenname c) ein Client und d) eine beliebige Adresse sauber auflösen lassen.

    Physische Netzwerkprobleme sind natürlich auch immer schlecht ausschließbar.

    Gibt die Ereignisanzeige sonst noch was her?

    Was passiert, wenn Du mit einem Problemclient die Domäne mal verlässt und ihr dann erneut beizutreten versuchst?

    Viele Grüße
    Olaf

    Freitag, 23. Mai 2014 06:59
  • Hallo Olaf,

    bis auf das Ab- und erneut Anmelden an der Domäne (geht dsa problemlos?) bin ich mt allen Deinen Vorschlägen durch.

    An DNS liegt es ziemlich sicher nicht. nslookup mit Computername oder IP-Adresse reagierte auf Server- und Client-Maschine einwandfrei.

    IP 6 ist definitv überall verschwunden.

    Beim 2. Netzwerkadapter ist lediglich Hyper-V aktiv.

    Die Reihenfolge der Bindungen wurde von mir etwas geändert, aber ohne Auswirkung auf das Problem:
    Adapter und Bindungen:
    - Ethernet (das ist die 'normale' Netzwerkkarte) - mit Häkchen bei IP4
    - Ethernet 2 (die für Hyper-V) - kein Häkchen
    - vEthernet ... (der virtuelle Switch)
    - [RAS-Verbindungen]

    Anbieterreihenfolge:
    Netzwerkanbieter
    - Microsoft Remotedesktop-Hostserver-Netzwerk
    - Web Client Network

    Letzteres war auch ursptünglich so und wurde temporär von mir vertauscht - ohne Änderungserfolg.

    Dass bei den Adaptern und Bindungen RAS aufgeführt ist, erscheint mir seltsam.

    Im Ereignisprotokoll gibt es zwei Fehler:
    1. der eingangs erwähnte Errorcode 1231 'Die Netzwerkadresse ist nicht erreichbar' und

    2. Quelle SceSrv, Eregnis-ID 1003, Die Benachrihtigung der Richtlinienänderung von LSA/SAM wurde wiederholt und ist fehlgeschlagen. Der Fehler 4312 ist beim Speichern der Richtlinieänderung für das Konto ... aufgetreten... Debuginformationen unter .. security\logs\scepol.log

    Der 1. Fehler tritt etwa alle 5 Minuten auf. Wie schon letzthin geschildert immer mit Verweis auf eine Datei, in der sich z.B. ein solcher Textfetzen findet: S o f t w a r e \ P o l i c i e s \ M i c r o s o f t \ S y s t e m C e r t i f i c a t e s \ E F S \ C R L s   ;   ;     ;     ; ] [ S o f t w a r e \ P o l i c i e s \ M i c r o s o f t \ S y s t e m C e r t i f i c a t e s \ E F S \ C T L s   ;   ;     ;     ; ] [ S o f t w a r e \ P o l i c i e s \ M i c r o s o f t \ W i n d o w s   N T \ R e l i a b i l i t y   ; S h u t d o w n R e a s o n O n   ;    ;    ;     ] [ S o f t w a r e \ P o l i c i e s \ M i c r o s o f t \ W i n d o w s   N T \ R e l i a b i l i t y   ; * * d e l . S h u t d o w n R e a s o n U I  

    Der 2. Fehler tritt 1 bis 2 mal pro Boot-Vorgang auf. Die Datei scepol.log gibt es übrigesn nicht in dem angegebenen Verzeichnis, nur ähnliche namige (scedcpro.log, scesetup.log).

    Danke für Deinen Einastz!

    Nachtrag: eine physikaliachen Defekt halte ich für unwahrscheinlich, denn in Gegenrichtung geht es ja, wie schon gesagt, sehr gut.


    Grüße aus Köln am Rhein - Klaus Trapp


    Freitag, 23. Mai 2014 14:48
  • bis auf das Ab- und erneut Anmelden an der Domäne (geht dsa problemlos?)


    eigentlich ja ... wenn denn da nicht noch ein weiteres Problem die Kommunikation nachhaltig behindert.

    Du hattest zwar die ipconfig /all vom DC gepostet, aber ein Vergleichsexemplar eines Clients wäre auch nicht verkehrt.

    Auf allen virtuellen Maschinen sind die aktuellen Hyper-V-Integrationsdienste installiert?

    Stand zwischen dem Funktionieren und dem ersten Auftreten des Problems ein Windows Update?

    Viele Grüße
    Olaf

    Sonntag, 25. Mai 2014 11:21
  • Hallo Olaf,

    habe nun doch mal den Client-PC (Sonne2) in eine Arbeitsgruppe versetzt, worauf Sonne2 plötzlich im Windows Exlporer auf Orion3 scihtbar war. Dort ist im Übrigen sonst als einziges Gerät der Mutimedia-Dienst des Windows Media-Players sichtbar - nicht einmal Jupiter3, der Hyper-V-Server auf Orion3.

    Nach erneutem Beitritt zur Domäne, war der Zustand wie zuvor. Zwischenzeitlich hatte ich auch den DC mehrfach gebootet.

    Die (einzige) Hyper-V-Maschine verwendet den neusten Integrationsdienst (Version 6.3.9600.16384).

    Der Fehler liegt seit dem 20.5. vor. Der Windows-Update-Verlauf auf dem DC zeigt zuletzt einen Eintrag am 14.5. auf; auf Client-PC gab es eine fehlgeschlagenen Update (betreffs Visual C++) am 20.5. und mehrere erfolgreiche am 21.5. zu Visual Studio. Auf der Hyper-V-Maschine konnte ich den Update-Verlauf nicht finden.

    Hier die ipconfig-Berichte:

    Der DC

    Windows-IP-Konfiguration

       Hostname  . . . . . . . . . . . . : Orion3
       Prim„res DNS-Suffix . . . . . . . : trapp.dv
       Knotentyp . . . . . . . . . . . . : Hybrid
       IP-Routing aktiviert  . . . . . . : Nein
       WINS-Proxy aktiviert  . . . . . . : Nein
       DNS-Suffixsuchliste . . . . . . . : trapp.dv

    Ethernet-Adapter Ethernet:

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8056 PCI-E-Gigabit-Ethernet-Controller
       Physische Adresse . . . . . . . . : 00-1D-60-E7-CF-1A
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja
       IPv4-Adresse  . . . . . . . . . . : 192.168.2.104(Bevorzugt)
       Subnetzmaske  . . . . . . . . . . : 255.255.255.0
       Standardgateway . . . . . . . . . : 192.168.2.1
       DNS-Server  . . . . . . . . . . . : 192.168.2.104
       NetBIOS ber TCP/IP . . . . . . . : Aktiviert

    Tunneladapter isatap.{7D8AB227-5D01-4BCA-BFCF-58CDA7DA0193}:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
       Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Der Hyper-V-Rechner

    Windows-IP-Konfiguration

       Hostname  . . . . . . . . . . . . : Jupiter3
       Prim„res DNS-Suffix . . . . . . . : trapp.dv
       Knotentyp . . . . . . . . . . . . : Hybrid
       IP-Routing aktiviert  . . . . . . : Nein
       WINS-Proxy aktiviert  . . . . . . : Nein
       DNS-Suffixsuchliste . . . . . . . : trapp.dv

    Ethernet-Adapter Ethernet 2:

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft Hyper-V-Netzwerkadapter
       Physische Adresse . . . . . . . . : 00-15-5D-02-68-00
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja
       Verbindungslokale IPv6-Adresse  . : fe80::3db3:d471:9242:43a6%13(Bevorzugt)
       IPv4-Adresse  . . . . . . . . . . : 192.168.2.128(Bevorzugt)
       Subnetzmaske  . . . . . . . . . . : 255.255.255.0
       Standardgateway . . . . . . . . . : 192.168.2.1
       DHCPv6-IAID . . . . . . . . . . . : 318772573
       DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1B-07-7F-7E-00-15-5D-02-68-00
       DNS-Server  . . . . . . . . . . . : 192.168.2.104
       NetBIOS ber TCP/IP . . . . . . . : Aktiviert

    Tunneladapter isatap.{E66407CC-E123-4243-9271-74363743165E}:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
       Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Und der Clinet-PC Sonne2

    Windows-IP-Konfiguration

       Hostname  . . . . . . . . . . . . : Sonne2
       Prim„res DNS-Suffix . . . . . . . : trapp.dv
       Knotentyp . . . . . . . . . . . . : Hybrid
       IP-Routing aktiviert  . . . . . . : Nein
       WINS-Proxy aktiviert  . . . . . . : Nein
       DNS-Suffixsuchliste . . . . . . . : trapp.dv

    Ethernet-Adapter Ethernet:

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Broadcom NetLink (TM)-Gigabit-Ethernet
       Physische Adresse . . . . . . . . : BC-5F-F4-0E-83-47
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja
       IPv4-Adresse  . . . . . . . . . . : 192.168.2.111(Bevorzugt)
       Subnetzmaske  . . . . . . . . . . : 255.255.255.0
       Standardgateway . . . . . . . . . : 192.168.2.1
       DNS-Server  . . . . . . . . . . . : 192.168.2.104
       NetBIOS ber TCP/IP . . . . . . . : Aktiviert

    Tunneladapter isatap.{35F8AEAB-B906-4DE7-8E0C-A2ACBBB63112}:

       Medienstatus. . . . . . . . . . . : Medium getrennt
       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
       Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP aktiviert. . . . . . . . . . : Nein
       Autokonfiguration aktiviert . . . : Ja

    Die restlichen Maschinen sind alle VMware-VMs


    Grüße aus Köln am Rhein - Klaus Trapp


    Sonntag, 25. Mai 2014 17:51
  • Hallo Olaf,

    inzwischen habe ich auf dem DC in der Gruppenrichtlinienverwaltung herumgeklickt.

    Es ging gleich los mit der Fehlermeldung: Die Netzwerkadresse ist nicht erreichbar. Weitere Informationen ...
    Das kam mir doch sehr bekannt vor.

    Unter Gruppenrichtlinien
    a) Default Domain Controllers Policies und
    b) Default Domain Policy
    erhielt ich die gleiche Meldung erneut.

    Unter b), Registerkarte Details, fand sich als eindeutige ID die GUID wieder, die auch in den Details der eingangs erwähnten Fehlermeldung im Sysvol-Pfad auftaucht (sysvol\trapp.dv\Policies\{GUID}\Machine\registry.pol).

    Da ich mich mit Gruppenrichtlinien nur sehr zaghaft beschäftig habe, möchte ich dort nicht ohne Weiteres Änderungen vornehmen. Ich denke, es wäre aber ganz sinnvoll, die Gruppenrichtlinien wieder in in den Urzustand zu versetzen.


    Grüße aus Köln am Rhein - Klaus Trapp

    Sonntag, 25. Mai 2014 23:12
  • Moin Klaus,

    IP-mäßig sieht auf den ersten Blick alles gut aus (auch wenn da noch IP v6 rumhängt, aber ich glaub nicht, dass das daran liegt, wenn Du die Problematik schon auf dem DC hast).

    Was meint denn die Ereignisanzeige des DC (besonders auch in den Anwendungs- und Dienstprotokollen in den AD-spezifischen Logs)?

    Unter C:\SYSVOL\domain\Policies sind die Richtlinien soweit vorhanden?

    Ein Zurücksetzen der Richtlinien kannst Du mit dem Befehl

    dcgpofix

    in einer administrativen Eingabeaufforderung ausgeführt, probieren.

    Viele Grüße
    Olaf

    Montag, 26. Mai 2014 08:13
  • Hallo Olaf,

    cdgpofix gibt mir folgenden Fehler zurück:

    Es konnten keine EFS-Zertifikate aus der Datei Registr.pol von Default Domain Policy gelesen werden. Der Fehler war: Die Netzwerkadresse ist nicht erreichbar ....

    Ich hatte zwar auf dem DC den Zertifizierungsdienst aktiviert, aber meines Wissens nichts mit EFS verschlüsselt.

    Nun habe ich AD CS wieder entfernt, aber ohne Änderung: Nach wie vor der gleiche Fehler in der Ereignisanzeige.

    Ich hatte mal anhand eines Leitfadens ein Root-Zertifikat erstellt (mizitechinfo.wordpress.com/2013/08/29/step-by-step-deploying-a-standalone-root-ca-in-server-2012-r2-part-1)

    Vielleicht ist in diesem Zusammenhang irgendwelcher Zertifikats-Kuddelmuddel entstanden.



    Grüße aus Köln am Rhein - Klaus Trapp

    Montag, 26. Mai 2014 10:02
  • Moin,

    viele Ideen bleiben mir grade nicht mehr, vielleicht noch die, ob Du an den Einstellungen fürs SMB-Signing was geändert hast.

    Viele Grüße
    Olaf

    Montag, 26. Mai 2014 12:37
  • Hallo Olaf,

    werde mich erstmal anderen Dingen widmen müssen und mich später um SMB-Signing kümmern.

    Besten Dank.


    Grüße aus Köln am Rhein - Klaus Trapp

    Montag, 26. Mai 2014 14:02