cj_berlin

Moin, an NPS-Test, QM und Systemtechnik verknüpfen. Wenn aber in der OU "Computer" auch Computerobjekte von Maschinen drin sind, auf die die GPO wirken soll, müsstest Du entweder die OU "Entwicklung" aus "Computer" rausnehmen oder irgendwelche Sicherheitsgruppen zaubern (Schatten-Gruppen) und die GPO darauf filtern oder für Entwicklung eine Gegen-GPO bauen.

Die Idee ist, dass Deine Clients gar nicht mehr ins AD kommen, sondern nur zum Azure AD gejoined sind. Wenn sie zwingend ins AD müssen, dann kannst Du mit einem davon auch die GPOs verwalten - RSAT installieren und als Admin-User starten. Dafür muss man sich nicht an irgendwelchen Servern anmelden. Mit Cached Credentials kann ein Client beliebig ohne Verbindung zum Verzeichnis auskommen - bis es Zeit wird, das Kennwort zu ändern.

Wieso? Das Exchange-Team wird irgendwann die 2022er DCs freigeben, aber es ist bisher noch nicht erfolgt. Ein ganz normaler Vorgang - oder haben alle deine Branchensoftware-Anbieter bereits die Freigabe für 2022 gegeben? Um Dich endgültig zu verwirren: Exchange 2016 ist nur auf maximal Server 2016 installierbar.

Moin, was Jan gesagt hat. Ergänzend: 1. den lokalen Exchange *brauchst* Du, wenn die User per AADC synchronisiert werden sollen. Somit ist derzeit nur Server 2019 als DC zulässig. 2. Du kannst den UPN-Suffix contoso.de (und somit UPN=mail) auch dann verwenden, wenn die AD-Domain contoso.local heißt 3. In Abhängigkeit davon, was Du noch on-prem nutzen möchtest, solltest Du genau prüfen, ob ein lokales AD und somit überhaupt lokale Server wirklich notwendig sind. Wenn "weitere Server und Dienste" tatsächlich nur per LDAP (also nicht per AD) angebunden sind, kannst Du ein Azure AD DS im User Forest-Modus prüfen. Kostet ca. 80 € im Monat, und alle User und Gruppen werden aus dem Azure AD repliziert.

Da hast Du bald ganz viele neue Freunde

Moin, Re 1: Schwer zu sagen. Exchange vNext hat außerhalb von Microsoft noch niemand gesehen, und in allen derzeit unterstützten on-premises-Versionen ist EWS die einzige unterstützte API. Re 2: Definiere "genauso anfällig". Es sind unterschiedliche Anwendungen, die in unterschiedlichen Anwendungspools laufen. Ein Angriff, der auf OWA abzielt, wird bei EWS nicht unbedingt weiterkommen. Re 3: Wieviele Wochen hast Du Zeit zum Lesen? Portforwarding sollte heute wirklich ein No-Go sein. Ein Reverse Proxy, der den Traffic nicht bloss durchleichtet, sondern auch analysiert, also praktisch ein Web Application Proxy, ist das Mindestmaß bei Veröffentlichung. Wenn das Fachverfahren im Internet steht, wird dessen Anbieter nicht immer VPN zu den einzelnen Endkunden anbieten können oder wollen.

Ja, aber als angehender Akademiker sollte er schon in der Lage sein, diesen Wunsch zu artikulieren

...und was genau erwartest Du von der Community?

Mit einem Key konnte man noch nie irgendwas lizenzieren, sondern nur aktivieren. Und das geht mit dem ROK-Key tatsächlich nur, wenn das Branding im BIOS korrekt ist. Die erworbene Lizenz berechtigt tatsächlich dazu, zwei VMs zu lizenzieren. Wie man sie aktivieren soll, ist dem Erwerber dann selbst überlassen.

Viel mehr Rechte gibt es im AD auch nicht

"lokal" ja, aber halt nicht mit AD, sondern mit Exchange (PowerShell).

Eigentlich nicht. Get-* nach Set-* pipen sollte es auch bringen. Dass Du Exchange-Attribute nicht außerhalb von Exchange bearbeiten sollst, ist Dir bewusst, Du hast es zur Kenntnis genommen und weißt über die Auswirkungen bescheid?

Das ist nicht schlimm. Die CSV-Spezifikation schreibt es vor, dass Werte, die den Delimiter enthalten, in Anführungszeichen genommen werden müssen. PowerShell ist da noch rigoroser und setzt alle nicht-numerischen Werte in Anführungszeichen.

Wie gesagt, wenn Du nur Outlook im Einsatz hast, wird das funktionieren. Für jeden anderen Client ist es nicht garantiert.

Was hast Du denn schon versucht? EDIT: Und bitte Code als Code posten!

Jein. Die auf dem Endgerät gecachten Autocomplete-Streams kannst Du nicht zentral bearbeiten. Für OWA und neue MAPI-Profile (die dann den Autocomplete-Stream vom Server herunterladen) ginge es, Du müsstest Dich in die Tiefen von MAPI und EWS Managed API einarbeiten. Als Ausgangspunkt kann das Skript von Michel de Rooij dienen: https://github.com/michelderooij/Clear-AutoComplete/blob/master/Clear-AutoComplete.ps1

Moin, Nein. Du hast ja auch nur eine ausgehende IP (nehme ich an), Ja, wenn Du irgendein anderes Client-Szenario hast als Outlook auf einem Domain-Member, muss mail.domain1. autodiscover.domain1.de und autodiscover.domai2.de ins Zertifikat. Reverse DNS wird meist nur auf das Vorhandensein geprüft, höchstens darauf, ob der MX oder der sendende Server dem aus der IP-Adresse aufgelösten Namen entspricht. Und da weder der MX noch der sendende Server aus der SMTP-Domain stammen muss, reicht ein PTR-Eintrag. Gar nichts. Die hören alle auf mail.domain1.de. ...was allerdings außer Outlook nicht viele Clients unterstützen.

Wenn O365 das sagt, dann ist die Domain irgendwann schon mal zu einem Mandanten hinzugefügt worden. Im Zweifel Ticket aufmachen - wenn ihr schon M365-Seats gebucht habt, seid ihr ja zahlender Kunde und habt Anspruch auf den Support.

Beide Maschinen aus dem AD rausnehmen, umbenennen und nochmal zum AD joinen. Selbst wenn sie ohne newSID/sysprep geklont wurden, dürfte ich das nicht auf die Accounts im AD auswirken.

Aus genau diesem Grund ist es auch für Admins der richtige Ansatz

Moin, meines Erachtens war der openSSH-Server noch nie ein Feature, sondern immer ein separater Download.

Wenn das Programm von euch betreut wird, dann wisst ihr ja sicher, welche Technologie für den Zugriff verwendet wird. Dann weiß man auch, ob der SQL Browser unterstützt wird, um die Instanz zu lokalisieren etc. Normalerweise gehört ein Backslash zwischen Server und Instanz, aber vielleicht setzt euer Programm die INI-Datei ja so um, dass aus dem doppelten Backslash in der INI ein einfacher im Connection String wird... Der Hinweis auf die Firewall ist ebenfalls richtig - Der SQL-Installer fügt selbst keine Inbound-Regeln hinzu.

Das ist nicht korrekt. Bei ODBC 18 ist die Verschlüsselung in der Tat standardmäßig aktiviert. Sie kann aber im Connection String deaktiviert werden, genau dort, wo sie in den früheren Versionen aktiviert werden konnte.

Moin, Du kannst den Remoting-Aufruf in Dein PowerShell-Profil auf dem Management-Server stecken und hast das beste aus beiden Welten. EMS macht im Hintergrund ja auch Remoting, nur dass noch ein bisschen Zusatz-Zauber zur Auffindung eines passenden Servers zuerst kommt.

Ja, und immer daran denken: "eine Lizenz" (als Kauf-SKU) deckt maximal 16 Hardware-Cores ab! Wenn der Server 2x 12 Core CPUs verbaut hat, ist "eine Lizenz" = Basis-Lizenz PLUS 8 Cores, die von 16 bis 24 fehlen. "Zwei Lizenzen" wären somit insgesamt 48 Cores.