natscho

Hallo, ich habe folgendes Szenario und würde gern wissen ob dies so überhaupt praktikabel ist und auf was für Probleme ich mich einstellen muss: Ein Client hat ein Standort in Dortmund mit einem Exchange 2013 Server, CU10. Nun möchte er einen weiteren Standort in Münster neu eröffnen. Das hat er sich wie folgt vorgestellt: Ein dritten Domänencontroller in Münster installieren, der in der selben lokalen Domäne ist, wie in Dortmund. Das Netz ist dabei ein anderes und es wird ein ipsec basierender Vpn Tunnel beide Netze verbinden über jeweils 50mbit Sdsl Leitungen. Über den Tunnel gleicht sich der dritte DC somit ab. Soweit so gut. Nun kommt der Clou, der Client möchte gerne das im neuen Standort Münster, in der selben lokalen Domäne, ein zusätzlier Exchange Server 2013 installiert wird, mit gleicher Mail Domäne wie in Dortmund! Ich soll dann nur die Postfächer, von den Mitarbeitern, die nach Münster umziehen, von der Datenbank vom Dortmunder Exchange in die des Münster Exchange verschieben, sodass die Mitarbeiter dort immer arbeiten können, auch wenn der Tunnel mal zusammenbricht. In Dortmund werden die Mails via Pop abgeholt. Dies soll dann auch mit den Postfächern in Münster so geschehen, jeweils Pop Abholung von den jeweiligen Posrfächern, die auf die einzelnen Exchange Datenbanken vorhanden sind. Ich hab dem Clienten geraten mit unterschiedlichen Maildomänen zu arbeiten oder den Standort Münster, alle Outlook Clients einfach komplett über den Tunnel an den Exchange in Dortmund anzubinden und dann lieber in Dortmund einen zweiten Exchange mit DAG zu konfigurieren als Ausfallsicherheit und einen zweiten ipsec Tunnel nach Münster, mit einer gesonderten Sdsl Leitung zu bestellen. Leider ist er von seiner Idee nicht ab zubringen und ich soll das jetzt dementsprechend umsetzen. Ich hab mir nun gedacht das ich den zweiten Exchange in Münster trotzdem als DAG hinzufüge und dann die 2 einzelnen Datenbanken der Standorte, jeweils auf den anderen damit repliziere falls mal einer crasht. OWA und Active Sync weise ich dann jeweils separat, mit den entsprechenden public Ips der Standorte, den Usern zu sodass jeder an sein Postfach von extern kommt. Leider habe ich bisher nur Erfahrungen, mit 2 Exchange Server in derselben Domäne und mit gleicher Maildomäne, bei Exchange Migrationen gemacht, daher bin ich mir nicht sicher was ich bei diesem Szenario alles für Probleme kriegen könnte, seitens Routing zwischen den Exchange Severn, Owa und den Zertifikaten und der Mail Abholung auf beiden Serven oder mit dem DAG über den Tunnel, falls der mal down sein sollte. Der Mail Versand läuft über ein Smarthost, darum gibt es dort keine Probleme. Die Domänencontroller und Exchange Server haben jeweils MS Server 2012 R2 als OS, als Info am Rande. Kann ich dies ohne weitere Bedenken so installieren oder bekomme ich dann größere Probleme, die nicht überschaubar sind? Ich werde das ganze jedenfalls in einem Test Szenario nachbauen bevor ich mir das Live Sytem zerleg. Ich wäre um jede Info oder Erfahrung, die andere damit gemacht haben, dankbar. Beste Grüße Markus

Danke für den Hinweis! Ich hatte den Fehler ebenfalls und habe mich tot gesucht! Deinstalliert und alles war wieder gut. Das ist echt die Härte von Microsoft in so kurzer Zeit solchen Unsinn zu fabrizieren. Das brauchen die Kunden nicht und das brauch kein Techniker sich mit so einem Schrott zu befassen.

Hallo, @daabm du hattest mit deiner Vermutung recht. Ich hatte zwar wirklich alle Servergruppenrichtlinien durchforstet und nach deiner Einstellung gesucht aber dort war es bei jeder GPO nicht konfiguriert. Mit dem Richtlinienergebnissatz habe ich dann herausgefunden das an den lokalen Gruppenrichtlinien rum gewerkelt wurde weil die Einstellung von dort bezogen wurde. Ich habe das dem Kunden gezeigt und er meinte nur "Shit" da war mal was ^^ Naja ich habe das dann herausgenommen und siehe da, der Computer ist wieder im Datei Explorer vorhanden, es wird alles wieder richtig dargestellt. Danke für den Hinweis.

Hallo, vielen Dank für die Antworten aber die Gruppenrichtlinien sind recht überschaubar auf dem SBS. Ich bin alle durch gegangen und nichts in der Hinsicht gefunden. Shell Erweiterungen sind leider auch nicht installiert oder sonst irgendwelche Veränderungen, das ist ja das Kuriose.

Die Rechner waren voll gepatcht, das kann ich zu 100%ig sagen. Zu der netio.sys kann ich nichts sagen. Da habe ich zu wenig tiefgründiges Wissen was das angeht. Aber danke für das Feedback!

Moin, ich habe bei einem SBS2011 Server folgendes Phänomen: Im Windows Datei Explorer wird "Computer" nicht mehr angezeigt. Wenn man Computer manuell aufruft ist die Ansicht komplett leer (siehe Screenshot) Mein Kunde hat die Windows 10 Admx Dateien auf dem Server installiert. Kann es damit zusammenhängen? Von den Ansichteinstellungen ist alles richtig. Manuell kann man auch die C und D Partition öffnen und anzeigen lassen. Ich weiß ehrlich gesagt nicht wo ich da ansetzen soll. sfc /scannow hat keine Fehler generiert Beste Grüße Markus

Gelöst: Dieser Hotfix brachte nun endgültig die Lösung https://support.microsoft.com/de-de/kb/2664888 Seit der Installation des Hotfix auf alle Windows 7 Rechner, stürzt keiner mehr ab. Der Fehler ist damit behoben.

Update: Also diesen Fix konnte ich nicht auf den Windows 7 Pc installieren. Es erschien die Meldung das die Installation auf dem PC nicht möglich ist von daher wird der nicht relevant sein. Ich habe aber vom Eset Support einen anderen MS FIX bekommen, der diesen Fehler beheben soll. https://support.microsoft.com/de-de/kb/2664888 Diesen habe ich nun auf 3 betroffene Win 7 PCs installiert. Ich lasse mich überraschen :suspect:

Ich werde Eset einmal komplett entfernen auf einem PC, samt Agent und Registry Bereinigung. Und dann mal schauen Danke dafür, ich werde den Hotfix direkt ausrollen und schauen ob dieser Abhilfe schafft. Ich habe zwar kein Eset NOD32 im Einsatz sondern Eset Endpoint Antivirus aber schaden kann der Hotfix eigentlich auch nicht soweit ich das sehen kann. Ein Blue Screen habe ich auch nicht :-/

Moin, so ich habe nun weitere Maßnahmen getroffen. Ich habe den Windows Defender via GPO überall deaktiviert und andere Windows Task die nur im Leerlauf passieren ebenfalls, wie z.B. Win Defrag. Der Kunde hat mir bestätigt das dieser Fehler nur im Leerlauf des PC's auftritt, Das kann auch schon nach wenigen Minuten passieren wenn dieser nicht am PC arbeitet. Während des Betriebes passiert der Fehler nie. Die Energieverwaltung habe ich schon soweit via GPO angepasst. Die PC's werden nicht in den Ruhezustand oder Standbymodus versetzt. Die Festplatte und alle anderen Einstellungen habe ich auf "Nie" gesetzt, CPU min und max immer bei 100% Leistung. Ich habe aber noch neuen Zusammenhang gefunden. Zeitgleich mit der DC Migration habe ich Eset AV v6.2.xxx und einen Eset Remote Administrator Server installiert. Vorher war Symantec AV auf allen Server und Win 7 PCs im Einsatz. Das habe ich mit dem Eset Remote Administrator sauber entfernen lassen und dort sind auch keine Einträge mehr in der Registry zu finden. Heute Morgen um 05:26 Uhr meldete mein Monitoring Tool das ein virtueller Windows 7 wieder nicht erreichbar war. Ich konnte diesen dann auch nicht anpingen, keine RDP Verbindung herstellen oder auf administrative Freigaben zurückgreifen auf diesem PC. In der vSphere 6 Console war der Bildschirm komplett schwarz,die VMWare Tools liefen auch nicht mehr, ich musste ihn wieder administrativ ausschalten weil die "Gast Neustarten" Funktion auch nicht mehr funktionierte, wie immer. Nach dem Neustart habe ich die Ereignislogs geprüft: Absturz war ca. 05:26 Uhr Neustart war um 08:16 Uhr Vor dem Crash und nach dem Crash sind keine besonderen Events meiner Meinung zu sehen. Das einzige was mich jetzt stutzig macht ist der ESET RA Eintrag bei der MS SI Überprüfung kurz vor dem Absturz. Der Eset Remote Administrator könnte damit eine Rolle spielen. Ich werde dazu mal den Eset Support ausquetschen da Eset v.6 auch ziemlich neu ist. Ein wichtige Info habe ich noch die mir schwer auf dem Magen liegt dazu. Ich habe einen Windows 7 PC aufgesetzt und die Domäne gepackt, Eset Agent und Eset Av dort installiert, Office 2013 und einen Mitarbeiter dort dran arbeiten lassen. Dieser PC ist nun ebenfalls von diesem Absturz Problem betroffen. Der PC ist komplett Neuware mit frisch installiertem Win 7. Das heißt für mich um Umkehrschluss das ich den Fehler auch nicht weg bekomme wenn ich die PC's neu aufsetze. Ich hoffe jetzt nur noch das es an Eset liegt :(

Also dcdiag spuckt folgendes aus: Verzeichnisserverdiagnose Anfangssetup wird ausgeführt: Der Homeserver wird gesucht... Homeserver = DC01 * Identifizierte AD-Gesamtstruktur. Sammeln der Ausgangsinformationen abgeschlossen. Erforderliche Anfangstests werden ausgeführt. Server wird getestet: Standardname-des-ersten-Standorts\DC01 Starting test: Connectivity ......................... DC01 hat den Test Connectivity bestanden. Primärtests werden ausgeführt. Server wird getestet: Standardname-des-ersten-Standorts\DC01 Starting test: Advertising ......................... DC01 hat den Test Advertising bestanden. Starting test: FrsEvent ......................... DC01 hat den Test FrsEvent bestanden. Starting test: DFSREvent ......................... DC01 hat den Test DFSREvent bestanden. Starting test: SysVolCheck ......................... DC01 hat den Test SysVolCheck bestanden. Starting test: KccEvent ......................... DC01 hat den Test KccEvent bestanden. Starting test: KnowsOfRoleHolders ......................... DC01 hat den Test KnowsOfRoleHolders bestanden. Starting test: MachineAccount ......................... DC01 hat den Test MachineAccount bestanden. Starting test: NCSecDesc ......................... DC01 hat den Test NCSecDesc bestanden. Starting test: NetLogons ......................... DC01 hat den Test NetLogons bestanden. Starting test: ObjectsReplicated ......................... DC01 hat den Test ObjectsReplicated bestanden. Starting test: Replications ......................... DC01 hat den Test Replications bestanden. Starting test: RidManager ......................... DC01 hat den Test RidManager bestanden. Starting test: Services Die Remote-IPC für [DC01] konnte nicht geöffnet werden: Fehler 0x3b "Unerwarteter Netzwerkfehler." ......................... Der Test Services für DC01 ist fehlgeschlagen. Starting test: SystemLog ......................... DC01 hat den Test SystemLog bestanden. Starting test: VerifyReferences ......................... DC01 hat den Test VerifyReferences bestanden. Partitionstests werden ausgeführt auf: ForestDnsZones Starting test: CheckSDRefDom ......................... ForestDnsZones hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... ForestDnsZones hat den Test CrossRefValidation bestanden. Partitionstests werden ausgeführt auf: DomainDnsZones Starting test: CheckSDRefDom ......................... DomainDnsZones hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... DomainDnsZones hat den Test CrossRefValidation bestanden. Partitionstests werden ausgeführt auf: Schema Starting test: CheckSDRefDom ......................... Schema hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... Schema hat den Test CrossRefValidation bestanden. Partitionstests werden ausgeführt auf: Configuration Starting test: CheckSDRefDom ......................... Configuration hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... Configuration hat den Test CrossRefValidation bestanden. Partitionstests werden ausgeführt auf: hh Starting test: CheckSDRefDom ......................... hh hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... hh hat den Test CrossRefValidation bestanden. Unternehmenstests werden ausgeführt auf: Starting test: LocatorCheck ......................... ***** hat den Test LocatorCheck bestanden. Starting test: Intersite ......................... **** hat den Test Intersite bestanden. Ich denke das sieht soweit ganz gut aus bis auf den IPC Fehler, den ich aber erstmal nicht als gravierend einstufe. Im AD war der alte DC bereits entfernt und nur noch als Member Server unter Computer aufgelistet. Wo ich doch noch Einträge gefunden habe ist in der DNS Verwaltung. Da waren noch in verschachtelten Unterstrukturen einige Einträge des alten Domänencontrollers vorhanden. Ich habe nun endgültig dort alle entfernt. Nach wie vor suche ich noch nach einer Lösung wie ich in der Registry die NTDS Parameter korrigieren kann. So recht werde ich da nicht fündig. Bei den AD Standorten un Dienste sieht alles gut aus soweit. Ich habe den Workaround von Yusuf soeben abgearbeitet. Bei der Stelle: bin ich mir nicht sicher ob ich bei den alten oder den neuen DC eingeben muss? Es ist ja in dem Sinne eine Registrierung also muss ich nach meinem Verständnis dort den neuen DC angeben? Da ich aber was entfernen möchte, wäre auch logisch dort den alten anzugeben?

Update: Ich habe bei 2 betroffene Windows 7 PC's die gesamte Registry nach Einträge vom alten DC durchsucht, jeweils nach der Ip und nach dem Hostnamen. Dort habe ich wirklich nichts gefunden. Anschließend habe ich das ganze auf dem neuen 2012R2 DC gemacht und folgenden Eintrag gefunden: Ich habe nach dem Eintrag gegoogelt und das weist alles darauf hin das der alte DC nicht vollständig entfernt wurde beim herunter stufen. Nun bin ich gerade auf der Suche wie ich das behebe ohne das AD dabei zu beschädigen. Man findet sehr viel dazu im Internet, ich muss mich da erstmal durchwuseln. Wer dazu schon Erfahrungen hat kann mir die bitte mitteilen.

Hallo und danke für die vielen Antworten schon mal. also der alte Server wurde korrekt mit dcpromo heruntergestuft und auf dem neuen DC wurde dann zusätzlich alle Einträge vom alten DC entfernt, die noch über blieben an den verschiedensten Stellen wie in der DNS Verwaltung. Zum Thema Server/Domänenmigration: Es wurde ein neuer virtueller Server mit Win 2012R2 installiert und als DC in der bestehenden Domäne hinzugefügt, Dann wurden die FSMO Rollen korrekt übertragen und zu guter letzt dcpromo auf dem SBS ausgeführt. Das verlief auch ohne Probleme alles. Das war natürlich der ganz grobe Verlauf, ich hatte für die Migration mehrere Howto's verwendet u,a, von Franky's Web weil ich die mit am besten finde. Unter anderem habe ich auch den Exchange 2003 vom SBS auf einem separaten Exchange 2013 mit 2012R2 als BS migriert. Das verlief mit Zwischenschritt über Exchange 2010 auch alles sehr gut. Ok danke willy für den Hinweis dann werde ich das mit der Registry Durchsuchung mal machen.

Moin, ich habe ein seltsames Problem auf sämtliche Windows 7 Clients nach einer Migration von einem Domänencontroller SBS2003 auf einem Window Server 2012R2. Seitdem ich die FSMO Rollen vom SBS auf den 2012R2 DC übertragen habe und ich den SBS dann auch ausgeschaltet habe, bekomme ich auf die Windows 7 Clients folgenden Fehler im Ereignislog: Ereignis 10,WMI Ereignisfilter mit Abfrage "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" konnte im Namespace "//./root/CIMV2" nicht reaktiviert werden aufgrund des Fehlers 0x80041003. Ereignisse können nicht durch diesen Filter geschickt werden, bis dieses Problem gelöst ist. Das Hauptproblem besteht darin das die Windows 7 Maschinen, die nicht täglich ausgeschaltet werden sondern durchlaufen, in der Leerlaufzeit sporadisch abstürzen. Das ganze ist ein kompletter Freeze, der Bildschirm ist schwarz und man kann die Maschinen nur noch hart ausschalten. Das ganze habe ich auch bei 2 virtuelle Windows 7 Maschinen sowie bei Hardware Windows 7 PC's von Benutzern. Die Win 7 PC's sind auf den aktuellsten Stand was Windows Updates betrifft. Seitdem ich die Energieoptionen angepasst habe kommt der Fehler nicht mehr all zu häufig vor, teilweise aber noch alle 2-3 Tage einmal pro PC, Vorher war es täglich mehrmals. Ich kann mir den Grund bloß nicht erklären was das mit der Migration auf den neuen DC zu tun hat. Ich habe einige alte SBS2003 GPO's deaktiviert, die keinen Sinn mehr machten aber daran sollte es eigentlich auch nicht liegen. Ich habe schon einen Microsoft Fix ("MicrosoftFixit50688" installiert der das Problem mit der Ereignis ID 10 beheben soll aber damit hatte ich auch kein Erfolg. Ich weiß auch nicht ob der Freeze Fehler damit zu tun hat. Ich habe nun soviel Zeit in der Fehlersuche reingesteckt das ich einfach nicht mehr weiter weiß und kurz vor Neu Installation der Windows 7 Maschinen bin sodass alles einmal sauber ist. Vielleicht hat aber noch jemand eine Idee wie man den Fehler eingrenzen könnte. Das schlimme ist das vor dem Freeze kein Ereignis im Windows Log erzeugt wird. Es ist auch kein Blue Screen oder sonstiges und somit auch kein Dump File vorhanden woran man noch was heraus finden könnte. Einfach nur kurios. Beste Grüße Markus

gelöst siehe: http://www.msxforum.de/community/index.php/Thread/15336-Exchange-2013-CU9-langsam-im-online-Modus/