Austausch unter IT-Professionals - Erfahrungen, Tipps, Fachsimpelei

xexex schrieb:
Vielleicht einfach keinen 17 Jahre alten Anleitungen folgen?
Vielen Dank für diesen wertvollen und produktiven Hinweis, werde ich auf jeden Fall befolgen. :)

charmin schrieb:
@morcego
Wenn dir der Master abraucht kannst du ja recht problemlos einen anderen DC zum Master machen. Sehe da jetzt nicht das Problem. In der Zeit kannst du DFS halt nicht verwalten, aber funktionieren sollte es noch.
Es geht primär nicht darum das der PDC ausfällt, sondern der Site2Site VPN. Ohne VPN ist der PDC faktisch im zweiten Standort "ausgefallen" da nicht erreichbar. Und "sollte" ist nett, in der Realität gibt es dieses "sollte" halt nicht. DFS ist schlicht tot.
Um das nochmal in kurz dazustellen:

Standort 1
  • DC1 mit allen FSMO und DFS mit Ziel auf NAS1
  • DC mit DFS mit Ziel auf NAS1
  • NAS1 mit Netzwerkfreigaben
  • für sich "autark" betreibbar mit lokalen Ressourcen

Standort 2
  • DC3 mit DFS mit Ziel auf NAS2
  • DC4 mit DFS mit Ziel auf NAS2
  • NAS2 mit Netzwerkfreigaben
  • ebenfalls für sich "autark" mit lokalen Ressourcen

Man würde jetzt erwarten, dass wenn der VPN zwischen den Standorten ausfällt, das beide Standorte für sich lebensfähig sind weil ja beide DCs mit DFS anbieten. Tun sie aber nicht, Standort 2 ist de facto vollständig unbrauchbar weil immer der PDC gesucht wird.

Und um im Sinne dieses Threads hier zu fragen: Entweder es hat irgendwer aus Erfahrung eine passable Lösung dafür parat, am liebsten in der DFS-Konfiguration, oder das ist wie eingangs geschildert ein Single Point of Failure by Design. (Und jein, die redundante Leitung hatten wir ja schon "als Lösung").
Da ich nix bei der Recherche gefunden habe, frag ich halt hier: nach Erfahrungen. :)
 
Hast du das so als Problem erlebt oder ist es deine Sorge das es sich wie von dir beschrieben verhält? Wir nutzen DFS und es gibt keinerlei Probleme mit Zugriffen wenn der PDC mal für Updates neu gestartet wird.

Wobei eine Backupleitung sicherlich eine gute Idee ist wenn ihr eine hohe Verfügbarkeit haben müsst. Ansonsten sehe ich da eigentlich nur ne eigene Domäne als Forest mit Vertrauensstellung wenn du das wirklich ordentlich trennen willst, bin aber gespannt was an Vorschlägen kommt. :)

Vielleicht ganz hilfreich:
https://learn.microsoft.com/en-us/w...space-servers-to-a-domain-based-dfs-namespace
https://learn.microsoft.com/de-de/windows-server/storage/dfs-namespaces/dfs-overview
 
Zuletzt bearbeitet:
Ich bräuchte mal Rat wie ich unseren Exch Server am einfachsten bzw. unkompliziertesten und Ausfallfrei auf was aktuelleres ziehe.

Exchange 2016 CU19
Build Number: 15.01.2176.014
Microsoft Windows Server 2016 Standard

Bei CU23 scheint ja Schluss zu sein. Oder einfach bei CU19 bleiben? Vor dem Exchange sitzt ein Proxmox Mailgateway.
 
Zuletzt bearbeitet:
charmin schrieb:
Hast du das so als Problem erlebt oder ist es deine Sorge das es sich wie von dir beschrieben verhält?
Jipp, gestern. Da war nämlich der Router mal unbeabsichtigt stromlos und damit der VPN tot.
charmin schrieb:
Ansonsten sehe ich da eigentlich nur ne eigene Domäne als Forest mit Vertrauensstellung wenn du das wirklich ordentlich trennen willst, bin aber gespannt was an Vorschlägen kommt.
In unserem konkreten Fall ist es genau das was wir abgeschafft haben. Es waren früher mal komplett separate Domains zweier Firmen die per Trust verbunden waren. Da Microsoft mit seinem AD Connect aber nicht mehrere Domänen in einen Tenant spielen kann und Cross Tenant eine leichte Katastrophe ist, und die Firmen als eine Art Konzern zusammenarbeiten sollen, haben wir genau diesen Trust aufgelöst und alles in eine Domäne migriert und praktisch AD Standorte mit ihren jeweiligen IP-Kreisen aufgemacht. Richtig schön nach MS Anleitung.
So und nu haste praktisch eine Firma die einfacher zu verwalten ist, aber leider am Hauptstandort hängt. Ist so bisschen Pest vs. Cholera. :-/

Und bevor der Standardsatz "Systemhaus" kommt, haben wir mit denen zusammen gemacht und die haben auch Erfahrung mit genau solchen Migrationen.
 
charmin schrieb:
Also bei CU19 würde ich auf gar keinen Fall bleiben, sondern den Exchange schleunigst Updaten:

Ist die Frage: Kann ich direkt von 19 auf 23 springen?

//Schleunigst muss ich nicht updaten. Der Exchange Server ist von außerhalb sowie so nicht erreichbar.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: LasseSamenström
Perfekt, danke. Das Update braucht noch .net 4.8. Das hab ich jetzt schonmal installiert. Werd dann am Samstag vorher einen Snapshot machen und gucken wie das Update sich so verhält. :D
 
LasseSamenström schrieb:
Das Update braucht noch .net 4.8. Das hab ich jetzt schonmal installiert. Werd dann am Samstag vorher einen Snapshot machen und gucken wie das Update sich so verhält.
Ein Tipp am Rande, da Exchange stark vom .Net Framework abhängt, immer vorher ein Snapshot machen und dann beides installieren. Ein .Net Update konnte dir früher den kompletten Exchange zerschießen und musste geblockt werden, diesmal hast du Glück gehabt, der Support für das .Net 4.8 ist bereits in deinem aktuellen Update inkludiert.
1683198787695.png
 
Und nicht vergessen dem User, mit dem du das upgrade durchführst, temporär die passende Admin Rechte zu geben. Domain Admin reicht dafür nicht.
Organisationsverwaltung, Schema-Admin und (Exchange Admin) auch, aber der Exchange Admin das sollte per default an einem Domain admin hängen (glaube ich).
Ich musste das letzte Mal ein CU nach dem anderen installieren.
Direkt auf die 23 hat am Ende dafür gesorgt, das ich überglücklich über den letzten Snapshot war...
Plan dafür sehr viel Zeit dafür ein, auch mit 16 schnellen vCPUs und 64 GB Ram hat es gefühlt ewig gedauert, bis das komplett durch war
Auf jeder Instanz -.-
Ausfallfrei also auf keinen Fall, außer zu hast die passenden DAG Groups und die passenden Dienste davor.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: charmin
Bei Exchange Installationen grätscht der Defender ziemlich rein, deshalb lohnt sich ein Deaktivieren während der Installation. Powershell und go: Set-MpPreference -DisableRealtimeMonitoring $true
 
  • Gefällt mir
Reaktionen: Mac_Leod
komplett anderes Thema,
hat wer eine Ahnung, ob ESET AV Cloud irgendo eine öffentliche Statistik hat für Dienstausfälle?
Ich suche gerad nach der Ursache warum am 13.04. ein Server nicht mit der ESET Cloud reden konnte.
Wollte jetzt aber nicht gleich ein Ticket dafür auf machen.
 
Das geht mit ziemlicher Sicherheit. Hatte ich genau so in der alten Firma und zu Azure AD migriert. Gab dabei und später keine Probleme.
 
morcego schrieb:
Jipp, gestern. Da war nämlich der Router mal unbeabsichtigt stromlos und damit der VPN tot.
Und die DCs vom 2. Standort sind im DFS Namespace? Laut Microsoft muss das ja funktionieren.
 
crashbandicot schrieb:
Laut Technet kann der AAD Connect das.

Multiple forests, single Azure AD tenant
https://learn.microsoft.com/en-us/a...ogies#multiple-forests-single-azure-ad-tenant
Grundsätzlich hast du recht, das geht. Aaaber: Wenn du zwei Domänen mit einem Trust verbunden hast und beide Domänen jeweils für sich bereits einen AD Connect mit eigenem Tenant laufen haben, dann bekommen die AD-Konten eine unique ID zusätzlich in die Attribute. Über diese UID sorgt Ad Connect für die Eindeutigkeit des Azure Ad Kontos wie sie im sonstigen Text des Artikels erwähnt wird.
Wenn man jetzt nicht schon Firmen hat die in der Wolke sind geht das, bei uns war das nicht der gewünschte Weg bzw. hätte andere Umbaumaßnahmen erfordert.

charmin schrieb:
Und die DCs vom 2. Standort sind im DFS Namespace? Laut Microsoft muss das ja funktionieren.
Sie sind nicht "im" Namespace, sie bauen ihren eigenen auf. Grob gesagt hat die Muttergesellschaft Zugriff auf alle DFS Ziele, die Töchter hingegen nur auf ihre eigenen "Ressourcen". Das heißt, jeder Standort hat einen oder mehrere eigene DFS Namespaces die auf den jeweiligen DCs gehostet werden. Die GPO verbindet dann je nach Firmenzugehörigkeit auf die entsprechenden DFS roots.

crashbandicot schrieb:
So wie der das geschrieben hat sollte das eigentlich gehen, ja, aber es ist vielmehr der Beitrag darunter der das Verhalten beschreibt. Der PDC ist nicht separat als eigener DC und wenn der dann fehlt bricht die Verbindung ab. In meiner naiven Welt sollten die DFS ja weiterlaufen gerade weil ich ja mehrere DCs habe die weiterhin vorhanden sind in den Standorten. Passiert aber nicht. Ist etwas frustrierend. :D
Ich bin weiter für Ideen und Vorschläge offen.
 
morcego schrieb:
Aaaber: Wenn du zwei Domänen mit einem Trust verbunden hast und beide Domänen jeweils für sich bereits einen AD Connect mit eigenem Tenant laufen haben
Aber ihr habt doch nur eine Domäne?!
morcego schrieb:
aben wir genau diesen Trust aufgelöst und alles in eine Domäne migriert
 
Hat jemand von euch SaphireRapids im Einsatz und wenn ja welches Modell und welche Erfahrung habt ihr damit?
 
Zurück
Oben