cj_berlin

Aber es geht doch eigentlich eher um Reife als um Größe! Auch in einer Umgebung mit 30 Usern wäre eine separate VM für AADC dringend anzuraten, wenn dort der Begriff "Tier 0-System" eine technische Umsetzung erfahren hat und gelebt wird - Admin-Trennung, PAW, Netzsegmentierung usw. Das Argument ist aber nur in der Theorie so einfach und klar. In der Praxis sieht es doch so aus: Wenn man nach der Installation NICHTS gemacht hat, um die Umgebung zu härten, sind DCs durch die DDCP wenigstens etwas besser geschützt als normale Server, für die nichts höheres an Schutz gilt als für Workstations. Immerhin kann man sich als nicht-Domain-Admin nicht aus Versehen dort anmelden. Zurück zum aktuellen Thread: Der OP mutet schon so an, als wäre ansatzweise Tier 0-Schutz in der Umgebung vorhanden. Ist dem wirklich so, dann würde ich allein schon aus Backup-/Restore-Gründen für eine separate Maschine plädieren. Beim Backup muss man aber genau so aufpassen wie beim Backup der Domain Controller - wer einen System State-Backup eines AADC-Servers ergattern kann, ist in 5 Minuten DA, wenn sie weiß, was sie tut.

Moin, unpopular opinion: In Kleinstumgebungen, wo Server nach wie vor als "Pets" statt als "Cattle" behandelt werden, ist ein DC sogar der beste Ort für Azure AD Connect, denn dort ist immerhin die Wahrscheinlichkeit noch am Geringsten, dass jemand per Zufall Adminrechte bekommt, der es nicht soll. Die SQL-Instanz, die nur lokale Verbindungen akzeptiert, ist wurscht. Das schwerwiegendste Argument ist in meinen Augen tatsächlich das von @MurdocX angeführte Backup-/Restore-Thema. Du nimmst Dir damit im Prinzip die Möglichkeit, AADC nach einem fehlgeschlagenen Update per VM Restore wieder ans Laufen zu bringen. Das muss jeder für sich selbst bewerten. Ich würde sogar argumentieren, dass man in diesem Fall den "DC + AADC" am besten gar nicht erst sichern sollte.

Moin, zum Glück ist es nicht per GPO möglich. Du kannst es immer als Skript oder geplanten Task verteilen, aber das Kennwort musst Du *irgendwie* mitgeben. Dazu gibt es viele Ansätze, die zu diskutieren diesen Thread sprengen würde. Und am Ende des Tages sind sie alle unsicher.

Deine Ablagephilosophie für Skripte musst Du mir bei einem nächsten Meetup mal erklären... @BOfH_666

Überleg mal, wie dieses Zertifikat bei Exchange Online aussehen müsste Aber auch on premises kenne ich Installationen (jenseits von Hosted) mit einer hohen zweistelligen Anzahl SMTP-Domains. Wenn Outlook der Client der Wahl ist, solltest Du mit SRV Records hinkommen, ansonsten halt, wie oben bereits gesagt, Redirects.

Ja, Splatting braucht einen Variablennamen, bei dem Du $ durch @ ersetzt. Einen Wert dort zu übergeben, ist nicht vorgesehen.

Moin, vielleicht übersehe ich ja was, aber, sofern sich die Scopes zwischen den Standorten nicht überschneiden, ist es eine ganz normale Topologie???

OK, also 7 Knoten = 6 aktive. Was ist auf dieser Welt schon unbedingt. Aber wenn ich an 80% der Installationen denke, die ich so kenne, gibt es das folgende RBAC-Konzept: Es gibt nur die Rollen "root" und "nix", also "public". Pro Fachbereich müssen diese Rollen separaten Gruppen zugewiesen werden. Und ein solches "RBAC" ist pro Instanz mit ein paar Klicks eingerichtet - und produziert auch keinen Configuration Drift mit der Zeit. Ressource Governor ist ein Enterprise-Only Feature. Ich musste die Editionsdiskussion unzählige Male führen, aber nie war dies das Feature, das den Ausschlag für Enterprise gegeben hätte. AG ist ebenfalls Enterprise-Only. Und bei großen Datenbanken würde sich, um beim Beispiel 7 Knoten zu bleiben, der Storage-Bedarf versiebenfachen. Das ist nicht immer gewollt.

Hmmm. Am DC lokal anmelden dürfen sich im Default nur BUILTIN\Administrators, Server-Operatoren, Account-Operatoren oder Druck-Operatoren. Herunterfahren dürfen dieselben minus Account-Operatoren. In den BUILTIN\Administrators sind im Default Domain Admins und Enterprise Admins Mitglied, aber das könnte ja geändert worden sein. Vielleicht ist der User aber einfach in den "Protected Users" Mitglied und sein Token ist abgelaufen?

...wenn sie geclustert ist. Mir sind bisher vier stichhaltige Gründe für mehrere Instanzen begegnet: Mehrere Anwendungen fordern unterschiedliche Collations auf Server-Ebene (System Center-Produkte zum Beispiel), man möchte sie aber auf dem gleichen SQL-Server fahren, beispielsweise weil er physisch ist Berechtigungsvergabe per Instanz ist um Welten einfacher einzurichten als RBAC innerhalb einer Instanz Man möchte oder muss Datenbanken eine bestimmte Menge an RAM und/oder eine bestimmte Anzahl an CPU-Kernen garantieren können Man möchte in einem Cluster die Leistung aller Knoten im Regelbetrieb auch wirklich verbrauchen (Aktiv/Aktiv).

Ich würde sagen, das Konzept geht in der Tat nicht auf. Hier ist ein Dokument, das eine Multi-Tenant-Architektur für eine Bildungseinrichtung beschreibt, vielleicht könnt ihr euch für euer Design inspirieren lassen: https://docs.microsoft.com/en-us/microsoft-365/education/deploy/design-multi-tenant-architecture

Was heißt das? Vermutlich müsstest Du etwas tiefer in die Frames reinschauen. Nicht, dass der neue Access Point eine andere Auswahl an Cipher Suites mitbringt als die bestehenden, und sich nicht mit dem RADIUS-Server einigen kann.

Moin, eine Domain mehreren Tenants zuzuweisen wird nicht möglich sein. Das heißt, wenn die Anforderung besteht, dass ein User sowohl die Adresse ben.utzer@firma.de als auch ben.utzer@company.com am gleichen Postfach haben soll, müssen beide Domains im gleichen Tenant registriert sein. Ansonsten musst Du nur im jeweils anderen Tenant Kontakte für die Empfänger angeben und Availability Namespaces konfigurieren, am besten über eine Sharing Policy: https://docs.microsoft.com/en-us/exchange/sharing/organization-relationships/create-an-organization-relationship

Das kannst Du ja machen. Entweder per Journaling oder per Discovery Search.

Wenn Du ein anderes Mailsystem kennst, welches mit den eigenen Bordmitteln den Inhalt in einen externen Speicher so auslagern kann, dass es für die Nutzer weiterhin zugreifbar ist und dabei irgendeine Art von Zugriffskontrolle für den exportierten Inhalt erzwungen wird, solltest Du auf dieses System migrieren und glücklich werden.

Jede Archivlösung, die die Exchange Server entlastet, wird eine Third Party-Lösung sein, denn Exchange-Bordmittel schieben den Content nur von links nach rechts, da entlastest Du nichts. Hier zum Beispiel bei MailStore: https://help.mailstore.com/de/server/E-Mail-Archivierung_von_Microsoft_Exchange_2016#.C3.96ffentliche_Ordner_archivieren

Moin, wenn der User an der fraglichen Maschine schon angemeldet war und Du die Policy "lokale Kopie bei Abmeldung löschen" nicht aktiv hattest, dann hat er doch eine lokale Kopie des Profils. Wenn der User nach der Deaktivierung die Maschine wechselt und auf der neuen noch nie ein Profil hatte, wird dort natürlich ein neues leeres Profil erstellt.

Moin, ich würde als nächstes das Postfach in eine andere Datenbank verschieben und schauen, ob das hilft. Ansonsten versuche es mal in eine PST zu exportieren, schau, ob dabei Fehler auftreten, und lass den User prüfen, ob alles drin ist.

Da es um private Smartphones geht, kannst Du den Usern ja nicht vorschreiben, welche App sie benutzen sollen. Du müsstest die Einschränkung also backend-seitig umsetzen. Und hier würde ich mal vollmündig meinen, mit ActiveSync allein bekommst Du es nicht geregelt. Alles andere (Intune, AirWatch und wie sie alle heißen...) erfordert aber Managed Devices, also schon mal nichts für private Endgeräte...

Ja, ich habe mich wohl eher am Thema bzw. an den Fragen des TO als am Inhalt des Threads orientiert

Das ist richtig, aber das Zertifikat, wo was im SAN stehen muss, ist ja nicht in seinem lokalen Store gespeichert, sondern auf dem Webserver. Im lokalen Store steht nur die CA-Kette bis zu diesem Zertifikat und evtl. ein User-Zertifikat, falls die Webseite zertifikatsbasierte Authentifizierung verlangt.

...das betrifft aber die Webserver, nicht die Trusted Roots und User Certs, die für den Certstore im Browser relevant sind.

Klar. Alles minutiös in den Microsoft Docs dokumentiert. https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint?view=o365-worldwide

Moin, es kommt ja auch darauf an, was für euch "Managen" bedeutet. Die *Konfiguration* könnt ihr auch mit Gruppenrichtlinien ausbringen, dafür braucht ihr keinen SCCM. Ihr bekommt ohne die Cloud aber auch nur einige wenige Teile des Malware-Schutzes, und das ist viel gravierender als das Bisschen Management.

Hab's zwar schon länger nicht mehr gemacht, aber meines Erachtens erzeugst Du für die mit DISK2VHD erzeugten Platten eine VM Generation 1. Oder Du jagst die von DISK2VHD erzeugte Platte noch durch MBR2GPT, dann kannst Du auch Gen2-VMs damit nutzen.