none
Migration von 2003 auf 2008R2: Den letzten 2003-DC herunterstufen, seltsames Verhalten der Clients bezüglich Logon-Server und Zeitsynchronisation RRS feed

  • Frage

  • Ich bin dabei, unsere Domäne von 2003 auf 2008R2 zu migrieren. Bevor ich jedoch den letzten Schritt wage, möchte ich noch einige Ungereimtheiten klären, die mir in unserem Netzwerk aufgefallen sind.

    Ausgangslage:

    Domäne mit 4 Standorten, an jedem Standort ein

    • Windows Server 2003 DC
    • Jeder DC führt die Dienste DNS, DHCP und WINS aus
    • Domänen- und Gesamtstrukturebene war und ist (noch) Windows Server 2003

    Die Migration habe ich mit den folgenden Schritten begonnen:

    • zunächst das Schema aktualisiert
    • einen neuen Server mit Windows Server 2008 R2 installiert und als DC der Gesamtstruktur hinzugefügt
    • AD-integriertes DNS und WINS konfiguriert
    • DHCP mit den angepassten Einstellungen konfiguriert und auf den Switches die ip helper Adressen angepasst
    • den Globalen Katalog auf dem neuen Server aktiviert und auf dem alten Server deaktiviert
    • die FSMO-Rollen auf den neuen Server verschoben
    • Zeitserver konfiguriert
    • DNS, WINS und NTP-Einstellungen an diversen Geräten angepasst und das Ganze eine Zeit lang so laufen lassen

    Im nächsten Schritt haben wir

    • jedem 2003-DC einen 2008R2-DC zur Seite gestellt
    • AD-integriertes DNS- und WINS auf den neuen Servern aktiviert
    • sämtliche DHCP Server auf die neuen Server gelegt und mit den angepassten Einstellungen konfiguriert
    • sämtliche ip helper Adressen auf den Switches aktualisiert
    • die Globalen Kataloge auf den neuen Servern aktiviert und auf den alten deaktiviert

    Im letzten Schritt bin ich nun dabei, die 2003-DCs herunterzustufen, was auch bis jetzt problemlos klappte. Aber beim letzten 2003-DC bin ich nun doch etwas unsicher:

    Dieser Server war der erste installierte DC der Domäne und über Jahre der "Hauptdomänencontroller" in der Domäne, er hielt sämtliche Rollen, war damit auch der Zeitgeber der Domäne. Seltsamerweise melden sich die Clients im selben Subnetz weiterhin bei diesem alten Server an, obwohl auch die Clients vor Kurzem ersetzt wurden (nachdem der 2008R2-DC schon installiert und konfiguriert war). Und nicht nur das: Sie holen sich auch ihre Zeit von diesem Server, und zwar über alle Standorte hinweg.

    Auch die DCs aktualisieren sich ihre Zeit über den alten Server, dessen Zeitkonfigurationen ich inzwischen aus der Registry entfernt bzw. zurückgesetzt habe. Durch Eingabe des Befehls <net time> wird auf Clients, Memberservern und DCs ergibt immer die aktuelle Zeit von diesem alten 2003-DC angezeigt. Einzig, wenn ich diesen alten DC herunterfahre, melden sich die Clients im selben Subnetz nun endlich bei dem neuen 2008R2-Server an und holen auch dort ihre Zeit. Frage ich aber die Zeit von einem anderen Standort (anderes Subnetz) aus ab, wird sie nun auch vom neuen 2008R2-PDC angezeigt, aber es dauert recht lange, bis der Befehl ein Ergebnis liefert. Clients in anderen Subnetzen melden sich weiterhin bei den DCs in ihrem Subnetz an, holen sich dann auch die Zeit vom neuen 2008R2-PDC.

    Fahre ich den alten Server wieder hoch, ändert sich die Situation sofort und alles ist wie gehabt: Selbes Subnetz = Alle Clients melden sich beim alten Server an und holen auch von dort ihre Zeit; anderes Subnetz = Clients melden sich bei dem jeweils lokalen DC an, holen sich aber wieder vom alten 2003-PDC ihre Zeit.

    Ein Neustart der DCs, eines Servers oder Clients bringt da keine Veränderungen.

    Nun bin ich etwas in Sorge, ob es zu Problemen führen könnte, wenn ich den letzten 2003-DC herunterstufe, bevor ich dieses Verhalten geklärt habe? Woran kann es liegen, dass die Clients sich so seltsam verhalten? Wie kann ich das im Vorfeld "gerade" ziehen bzw. was habe ich noch vergessen? Oder ist das normal und wird sich richten, wenn der alte und letzte 2003-DC erstmal heruntergestuft wurde?

    Und eine weitere Frage: Der Punkt, die Zertifikate der Wiederherstellungsagenten etc. vom ersten DCs zu sichern, ist mir nicht ganz klar. Wenn wir kein EFS einsetzen, kann ich den Punkt doch getrost vergessen und mir einfach, falls notwendig, ein neues EFS-Zertifikat ausstellen lassen bzw. einen neuen Wiederherstellungsagenten bestimmen, oder?


    • Bearbeitet Shisu.Ado Dienstag, 7. August 2012 11:54
    Dienstag, 7. August 2012 11:54

Antworten

  • Update: Auch nach Eingabe des Befehls net time wird jetzt der neue Win2008R2-PDC ausgegeben - egal von welchem Server oder DC und egal aus welchem Standort ich ihn ausführe. Zudem kommt die Ausgabe sehr schnell. Sieht bis jetzt also alles gut aus :)
    Donnerstag, 9. August 2012 06:17

Alle Antworten

  • Hallo,

    alles DCs sind GC und DNS, das ist auch angeraten von Microsoft.

    Hast Du mit DCDIAG, REPADMIN, ADREPLSTATUS und DNSLint die Domäne und DCs auf Fehler geprüft? Falls nicht, wäre jetzt der Zeitpunkt gekommen:

    dcdiag /v /c /d /e /s:dcname >c:\dcdiag.txt
    repadmin /showrepl dc* /verbose /all /intersite >c:\repl.txt  ["dc* ist hier als Platzhalter gesetzt wenn alle DCs den gleichen Namensbeginn haben]
    dnslint /ad /s "DCipaddress" (http://support.microsoft.com/kb/321045)
    ADREPLSTATUS: http://www.microsoft.com/en-us/download/details.aspx?id=30005

    Der erste DC ist normalerweise der welcher für das EFS Zertiikat verantwortlich ist vom EFS Recovery agent http://technet.microsoft.com/de-de/library/cc755157(WS.10).aspx und http://support.microsoft.com/kb/241201 geben die Details hierzu und falls Ihr den benutzt habt bitte sichern.

    Die Zeitkonfiguration muss auf dem alten und neuen PDCEmulator angepasst werden damit es sauber funktioniert. Bin jetzt übersetzungsfaul und poste hier mal meinen Artikel in Englisch http://msmvps.com/blogs/mweber/archive/2010/06/27/time-configuration-in-a-windows-domain.aspx der die Befehle enthält für die Umsetzung. Wichtig ist das Firewalls den UDP Port 123 offen haben.

    Net time solltest Du vergessen, w32tm ist der Befehl welcher für die Zeiteinstellungen benutzt werden soll. Gruppenrichtlinien habt Ihr nicht für die Zeiteinstellungen definiert?


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Dienstag, 7. August 2012 12:47
  • Hallo Meinolf,

    vielen Dank für deine Antwort. Ich hatte zwar dcdiag und repadmin schon ausgeführt, ohne dass mir Probleme ins Auge gesprungen wären, werde es aber noch einmal mit den von dir empfohlenen Schaltern wiederholen. dnslint und adreplstatus kannte ich noch nicht, werde mich auch da durcharbeiten.

    Wie gesagt: Wir haben kein EFS im Einsatz, nur eine CA für unser OWA und einige andere Dienste. Das alte EFS-Zertifikat für den EFS Recovery Agent ist übrigens seit 2005 abgelaufen...

    Zeitkonfiguration habe ich natürlich über w32tm bzw. auf dem PDC über die Registry geregelt. Über Gruppenrichtlinien ist da meines Wissens noch nichts konfiguriert. Sollte ich das tun? Auch für die Server? Ich hatte einen Beitrag gefunden, aber noch nicht umgesetzt:

    http://www.gruppenrichtlinien.de/index.html?/howto/zeitserver_per_gpo.htm

    Meinst du das? Sollte ich das so machen?

    Hm, net time vergessen? Komplett?

    Gebe ich w32tm /monitor ein, ist alles ok, alle DCs synchronisieren sich mit dem neuen PDC und der (neue) PDC mit einer externen Zeitquelle. Bei Eingabe von net time sieht das anders aus - oder interpretiere ich das alles falsch?

    P.S.: Artikel auf Englisch sind nicht nur kein Problem, sondern gewünscht! Die maschinellen Übersetzungen von MS kann man nämlich in die Tonne kloppen, ich muss sie eh immer auf das Original zurückstellen.

    Na ja, ich werde mich erstmal durch deine Tipps durcharbeiten und mich dann zurückmelden.

    Dienstag, 7. August 2012 13:10
  • Hallo,

    wenn nichts anders in der Registry der Systeme eigestelt ist, ziehen die sich die Zeit von dem PDC Emulator (FSMO Rolle). Für den könntet ihr dann Anpassungen in der Registry vornehmen. Somit sollte also dem herunterstuffen nichts mehr im wege stehen. 

    Ein Tipp aus erfahrung, kontrolliert hinterher mal die DNS Zone _msdcs.Domain.tld gelegentlich sind da bei Kunden von mir noch Einträge zurück geblieben und haben Probleme gemacht.

    Gruß Fabian

    Mittwoch, 8. August 2012 12:09
  • Hi Fabian,

    danke für den Hinweis mit den DNS-Einträgen, ich hatte ihn auch schon im Internet gefunden und tatsächlich ist dieses Problem auch nach dem Herunterstufen eines DCs aufgetreten.

    Was die Zeitsynchronisation angeht, ist ja eben das genau mein Problem: Der PDC-Emulator ist ein neuer Win2008R2-DC, der auch sämtliche anderen Rollen innehat. Um den neuen PDC zu konfigurieren, bin ich nach der folgenden Anleitung vorgegangen:

    http://support.microsoft.com/kb/816042/de#method2

    Die entsprechenden Einstellungen auf dem alten PDC habe ich zurückgesetzt (nach Vorlage eines anderen Mitgliedservers).

    Aber wenn ich an irgendeinem Client oder einem Server (auch DC!) den Befehl net time eingebe, erhalte ich die folgende Meldung:

    C:\Windows\System32>net time
    Aktuelle Zeit auf \\Win2003-DC ist <Datum Uhrzeit>
    Der Befehl wurde erfolgreich ausgeführt

    Weshalb wird hier die Zeit vom alten PDC angezeigt?

    Die Eingabe des Befehls w32tm /query /status ergibt die folgende Ausgabe:

    C:\Windows\System32>w32tm /query /status
    Sprungindikator: 0(keine Warnung)
    Stratum: 3 (Sekundärreferenz - synchr. über (S)NTP)
    Präzision: -6 (15.625ms pro Tick)
    Stammverzögerung: 0.0625000s
    Stammabweichung: 0.0971612s
    Referenz-ID: 0xC0A80102 (Quell-IP:  xxx.xxx.xxx.xxx)
    Letzte erfolgr. Synchronisierungszeit: 08.08.2012 14:38:51
    Quelle: Win2008R2-DC1.domain.tld
    Abrufintervall: 15 (32768s)

    Bei Eingabe von w32tm /monitor erhalte ich die folgende Meldung:

    C:\Windows\System32>w32tm /monitor
    Win2003-DC1.domain.tld[xxx.xxx.xxx.xxx:123]:
        ICMP: 0ms Verzögerung
        NTP: -0.0031749s Offset von Win2008R2-DC1.domain.tld
            RefID: Win2008R2-DC1.domain.tld [xxx.xxx.xxx.xxx]
            Stratum: 3
    Win2008R2-DC1.domain.tld *** PDC ***[xxx.xxx.xxx.xxx:123]:
        ICMP: 0ms Verzögerung
        NTP: +0.0000000s Offset von Win2008R2-DC1.domain.tld        RefID: ptbtime3.ptb.de [192.53.103.103]
            Stratum: 2
    Win2008R2-DC2.domain.tld[xxx.xxx.xxx.xxx:123]:
        ICMP: 0ms Verzögerung
        NTP: +0.0060312s Offset von Win2008R2-DC1.domain.tld
            RefID: Win2008R2-DC1.domain.tld [xxx.xxx.xxx.xxx]
            Stratum: 3
    Win2008R2-DC3.domain.tld[xxx.xxx.xxx.xxx:123]:
        ICMP: 38ms Verzögerung
        NTP: +0.0124248s Offset von Win2008R2-DC1.domain.tld
            RefID: Win2008R2-DC1.domain.tld [xxx.xxx.xxx.xxx]
            Stratum: 3
    [Warnung]
    Die Reversenamenauflösung ist die beste Möglichkeit. Sie ist ggf. nicht
    korrekt, da sich das Ref-ID-Feld in Zeitpaketen im Bereich von
    NTP-Implementierungen unterscheidet und ggf. keine IP-Adressen verwendet.

    Gebe ich an einem Client oder Server set l ein, erhalte ich die folgende Meldung:

    C:\Windows\System32>set l
    LOCALAPPDATA=C:\Users\<User>\AppData\Local
    LOGONSERVER=\\win2003-DC1

    Weshalb melden sich die Clients immer noch am alten DC an und weshalb scheinen sie auch von dort die Zeit zu erhalten? Oder sehe ich den Wald vor lauter Bäumen nicht?





    • Bearbeitet Shisu.Ado Mittwoch, 8. August 2012 13:08
    Mittwoch, 8. August 2012 12:42
  • Hallo,

    die Zeineinstellungen der Domäne benötigen KEINE manuellen Änderungen in der Registrierung des Rechners außer Ihr habt irgendwelche besonderen Einstellungen vorzunehmen.

    W32tm ist in der Lage die Einstellungen mit einer Befehlszeile korrekt zu setzen. Seit Windows Server 2003 machen wir das so und es funktioniert einwandfrei.

    Gruppenrichtlinien habe ich für die Zeiteinstellung noch nicht benötigt und dies muss auch nicht gemacht werden.

    W32tm löst wie Du siehst alle DCs auf, da diese alle als Zeitserver in Frage kommen. Net time ist NICHT akkurat, auch schon von Microsoft bestätigt und daher wird davon abgeraten, und meldet einen verfügbaren Zeitserver. Bei Net time bekomme ich auch einen verfügbaren DC angezeigt, welcher nicht mein Anmeldeserver ist.

    Wichtig in der w32tm Ausgabe ist das alle DCs gelistete sind und der PDCEmulator als Stratum2 Gerät angezeit wird, somit die höchste Zeitquelle in der Domäne. Alle anderen DCs sind Stratum3 und somit können-werden alle Maschinen mit einem verfügbaren DC synchronisieren.

    Lass mal "w32tm /config /syncfromflags:domhier /update" und danach "net stop w32time" und "net start w32time", dann starte die Ereignisanzeige und "System" und schau Dir die Einträge mit den IDs 37 und 35 vom Zeitservice an. Hier sollte der Server gelistet sein welcher die Zeit vorgibt.


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Mittwoch, 8. August 2012 13:19
  • Hallo Meinolf,

    vielen Dank für die Antwort. Ich habe die Befehle auf einem Win7-Client durchgeführt und erhalte das folgende Ergebnis für ID 35 und ID 37:

    ID Der Zeitdienst synchronisiert die Systemzeit mit folgender Zeitquelle: Win2003-DC1.domain.tld (ntp.d|0.0.0.0:123->xxx.xxx.xxx.xxx:123).

    Das ist immer noch der falsche, alte Win2003-DC1, der kein PDC mehr ist. Ich bin echt ratlos, vielleicht ist es auch kein so großes Problem bzw. es löst sich von selbst, wenn ich den Server herunterstufe. Aber ich kann - nicht nur momentan - keine zusätzlichen Probleme gebrauchen...hast du eine Idee, was da schief laufen könnte? Habe ich vielleicht eine Registry-Einstellung auf dem alten PDC übersehen, durch die er immer noch als Zeitserver angesehen wird?


    • Bearbeitet Shisu.Ado Mittwoch, 8. August 2012 13:30
    Mittwoch, 8. August 2012 13:28
  • Hm, ich habe gerade eine Änderung herbeigeführt: Nach Eingabe des Befehls w32tm /resync /rediscover erhielt ich folgende Meldungen:

    ID 1, Kernel-General
    Die Systemzeit wurde von ‎2012‎-‎08‎-‎08T13:34:52.415430000Z auf ‎2012‎-‎08‎-‎08T13:34:52.415000000Z geändert.
    ID 37, Time-Service
    Der Zeitanbieter "NtpClient" empfängt derzeit gültige Zeitdaten von Win2008R2-DC1.domain.tld (ntp.d|0.0.0.0:123->xxx.xxx.xxx.xxx:123).
    ID 35, Time-Service
    Der Zeitdienst synchronisiert die Systemzeit mit folgender Zeitquelle: Win2008R2-DC1.domain.tld (ntp.d|0.0.0.0:123->xxx.xxx.xxx.xxx:123).

    net time gibt seltsamerweise immer noch den Win2003-DC1 als Zeitquelle an.

    So stelle ich mir das eigentlich vor, so sollte es eigentlich sein. Ich werde den Befehl mal auf einigen anderen Clients und Servern durchführen, ob sich da genauso etwas ändern/korrigiert. Und dann mal sehen, ob diese neue Konfiguration auch einen Neustart überlebt.





    Mittwoch, 8. August 2012 13:40
  • Am 07.08.2012 schrieb Shisu.Ado:

    * die FSMO-Rollen auf den neuen Server verschoben
    * Zeitserver konfiguriert

    Du könntest den Zeitserver per GPO einstellen. Dann ist dir in Zukunft
    egal welcher Server es ist, er muß nur die FSMO Rollen innehaben.
    http://www.gruppenrichtlinien.de/HowTo/Zeitserver_per_GPO.htm

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Mittwoch, 8. August 2012 19:15
  • Ja, den Link hatte ich ja oben auch schon angegeben. Werde ich wohl genauso umsetzen. Ich habe gestern Abend den alten DC heruntergefahren. Zumindest gab´s bis jetzt noch keine Meldung von den Usern, das ist ja schon mal was. Die Logs checke ich gleich, klar wird´s jetzt einige Fehler wegen des fehlenden DC geben, aber mal sehen, ob´s ansonsten ruhig bleibt. Denn werde ich ihn wohl zum WE herunterstufen.

    Vielen Dank für eure Hilfe!


    • Bearbeitet Shisu.Ado Donnerstag, 9. August 2012 06:12
    Donnerstag, 9. August 2012 05:51
  • Update: Auch nach Eingabe des Befehls net time wird jetzt der neue Win2008R2-PDC ausgegeben - egal von welchem Server oder DC und egal aus welchem Standort ich ihn ausführe. Zudem kommt die Ausgabe sehr schnell. Sieht bis jetzt also alles gut aus :)
    Donnerstag, 9. August 2012 06:17
  • Hallo,

    gut zu hören dass alles passt. Persönlich finde ich die Gruppenrichtlinien Variante zu umständlich und beim Verschieben von FSMO Rollen muss ich immer anpassen. Der "natürliche" Weg funktioniert einwandfrei in allen Netzen die ich bis jetzt betreut habe. Aber das mag auch eine Philosophie von Admins zu sein ob per Gruppenrichtlinie oder nicht. :-)


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Donnerstag, 9. August 2012 07:07
  • Am 09.08.2012 schrieb Meinolf Weber [MVP]:

    gut zu hören dass alles passt. Persönlich finde ich die Gruppenrichtlinien Variante zu umständlich und beim Verschieben von FSMO Rollen muss ich immer anpassen.

    Wo mußt Du was anpassen? Wenn Du die FSMO Rollen verschiebst, greift
    der WMI Filter der GPO. Also muß man nichts anpassen.

    Der "natürliche" Weg funktioniert einwandfrei in allen Netzen die ich bis jetzt betreut habe. Aber das mag auch eine Philosophie von Admins zu sein ob per Gruppenrichtlinie oder nicht. :-)

    Sicherlicht funktioniert der natürliche Weg, aber wenn der schon
    verändert wurde, zieht die GPO das wieder gerade.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Donnerstag, 9. August 2012 21:33
  • Freitag, 10. August 2012 08:44
  • Nicht so schnell mit den jungen Pferden... ;) Ein wenig Geduld bitte.
    Freitag, 10. August 2012 08:46
  • Hast Du mit DCDIAG, REPADMIN, ADREPLSTATUS und DNSLint die Domäne und DCs auf Fehler geprüft? Falls nicht, wäre jetzt der Zeitpunkt gekommen:

    Hallo Meinolf,

    Ich gehe gerade mal deine Empfehlungen durch. Leider wirft dcdiag einige Fehler heraus, an denen ich mir gerade die Zähne ausbeiße. Die jeweiligen Win2008R2-DCs stehen in verschiedenen Subnetzen, der Win2008R2-DC3 ist zudem noch über S2S-VPN angebunden. Ich habe dcdiag auf dem Win2008R2-DC1 ausgeführt.

    Starting test: FrsEvent 
             * Der Ereignisprotokollierungstest für den Dateireplikationsdienst 
             Das Ereignisprotokoll File Replication Service auf dem Server 
             Win2008R2-DC2.domain.tld konnte nicht abgefragt werden. Fehler: 0x6ba 
             "Der RPC-Server ist nicht verfügbar." 
             ......................... Win2008R2-DC2 hat den Test FrsEvent nicht 
             bestanden. 
    Starting test: KccEvent 
             * The KCC Event log test
             Das Ereignisprotokoll Directory Service auf dem Server 
             Win2008R2-DC2.domain.tld konnte nicht abgefragt werden. Fehler: 0x6ba 
             "Der RPC-Server ist nicht verfügbar." 
             ......................... Win2008R2-DC2 hat den Test KccEvent nicht 
             bestanden. 

    Dasselbe für den Win2008R2-DC3.

    Interessant dabei ist, dass die Tests von den Remote-Servern bestanden werden, wenn ich die Firewall auf den DCs deaktiviere. Ich war davon ausgegangen, dass MS schon dafür sorgt, dass die eigenen Dienste durch die Firewall kommunizieren können, aber das scheint sich nicht so zu verhalten. Außerdem kann ich von einem Subnetz heraus z. B. die Ereignisanzeige (mmc) eines Remoteservers nicht öffnen. Seltsamerweise funktioniert das innerhalb eines Standortes.

    Hast du eine Idee, was ich wo konfigurieren muss, damit diese Tests auch mit eingeschalteter Firewall erfolgreich sind?



    • Bearbeitet Shisu.Ado Dienstag, 14. August 2012 10:16
    Dienstag, 14. August 2012 08:39
  • Hallo Shisu.Ado,
     
    Die Firewalls MÜSSEN für alle AD benötigten Ports offen sein, egal ob VPN
    oder direkt verbunden. Schau bitte in http://technet.microsoft.com/en-us/library/dd772723(WS.10).aspx
    für alle benötigten Schritte und konfiguriere die Firewalls.
     
    Best regards
     
    Meinolf Weber
    Disclaimer: This posting is provided "AS IS" with no warranties, and confers
    no rights.
    ** Please do NOT email, only reply to the Forum
    ** Send from Omea Reader 2.2
     
     

    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Dienstag, 14. August 2012 12:20
  • Vielen Dank für die Antwort. Aber muss man da tatsächlich noch manuell etwas konfigurieren? Lt. MS sollen die Firewalls eingeschaltet bleiben, also sollte es doch eigentlich zum Hochstufungsprozess gehören, die internen Firewalls auch entsprechend zu konfigurieren, so dass alles reibungslos funktioniert? Immerhin gibt es ja einige Standardfirewallregeln mit Standardeinstellungen (AD-LDAP, -NetBIOS, -SAM etc. pp).

    Oder anders gefragt: Weshalb ist es bei uns NICHT so? Die Firewalls sind noch in der Standardkonfiguration.

    Dienstag, 14. August 2012 12:26
  • Hm, hat keiner eine Idee? Wie ist es denn bei euch (DCs in verschiedenen Subnetzen vorausgesetzt, VPN lassen wir mal außen vor)? FWs aktiviert und keine Fehlermeldungen bei dcdiag (Befehl oben, erste Antwort von Meinolf), insbesondere KccEvent und FrsEvent?

    Leider kann ich DNSlint von der MS-Webseite nicht herunterladen. Sämtliche anderen Downloadmöglichkeiten, die ich als vertrauenswürdig ansehe, leiten auf die MS-Webseite um - natürlich mit demselben Ergebnis. Kennt jemand eine weitere vertrauenswürdige Quelle, um dieses Tool herunterzuladen?


    • Bearbeitet Shisu.Ado Donnerstag, 16. August 2012 06:44
    Donnerstag, 16. August 2012 06:43