cj_berlin

Wenn AppID und AppSecret verlangt werden, ist es nicht OAUTH, zumindest nicht mit den von Dir genannten Protokollen: https://learn.microsoft.com/de-de/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth

Habe ich jetzt nicht verstanden, aber Du wirst es schon ordentlich recherchiert haben. Was ist mit dem Referrals-Parameter? Habt ihr das versucht zu aktivieren und brachte das irgendeine Änderung? Das sollte eigentlich genau dafür da sein...

Moin, viel von ClearPass gehört, nie live gesehen, aber nach dem Überfliegen des Artikels (auf dem Phone) mal ganz b***d gefragt: kann man nicht zwei AD-basierte Authentication Sources hinzufügen?

Magst Du mal auf konkrete Ressourcen/Passagen in der CU-Beschreibung hinweisen, die Dich zu dieser Annahme verleitet haben?

So isses.

Also quasi den Job erledigt, für den sie bezahlt werden

Bis LocalKDC Realität wird, was bleibt in einer Workgroup übrig? Und in der Domäne kann man ja seit einigen Jahren auch SPNs verwenden, die auf IP-Adressen basieren Nicht dass ich das jetzt empfehlen würde...

Moin, *welche* Fehler hast Du denn behoben?

Moin, ad 1: vermutlich nicht, die Fehlermeldung wäre eine andere. ad 2: ja, aber Du wirst den Key im Activate-Portal konvertieren müssen, denn ein 2019er Lizenzserver kann maximal 2019er Lizenzen austeilen.

Moin, das ist die von VMware vorgeschlagene Vorgehensweise. Dagegen spricht nur die Dauer der Storage vMotion, aber irgendwann muss es ja gemacht werden

Es geht tatsächlich weniger um die Version des WSUS, sondern darum, was man darüber verteilt. Auch 2012er WSUSe mussten aufgebohrt werden, als man anfing, darüber Windows 10-Funktionsupdates auszurollen.

Moin, kein Lösungs-, aber vielleicht ein Denkansatz: Da es scheinbar nicht die Infrastruktur, sondern nur bestimmte Kombination von Postfächern betrifft und das Verhalten in OWA anders ist als in Outlook, könnte es an dem Autovervollständigungs-Cache liegen (was früher .NK2-Dateien waren). Diese werden seit Exchange 2010 (SP1?) im Postfach gespeichert und lokal nur aus Performance-Gründen gecached (erklärt, warum das neue Profil nichts bringt) und zwar separat für MAPI und OWA (erklärt, warum OWA funktioniert und MAPI nicht). Wenn ein betroffener User zustimmt, purge mal den Cache in seinem Postfach (Optionen --> E-Mail --> Nachrichten senden --> AutoVervollständigen-Liste leeren) und schau, ob's besser wird. Wenn er nicht zustimmt, könntest Du per MFCMAPI das ganze low-level durchfummeln, aber das ist mühsam und hässlich.

Dass er benutzt wird, stand nie in Frage. Aber ich kann mich an keinen Fall erinnern, dass die Deprecation Notice eines ganzen Features zurückgenommen worden wäre, nur weil es genutzt wird. Auch 8- und 16-Bit-Anwendungen werden noch von jemandem genutzt. Das hat Microsoft nicht daran gehindert, den QA-Aufwand zu halbieren, indem 32-Bit-Betriebssysteme nicht mehr ausgeliefert wurden.

Na, dann habt ihr ja bestimmt ein Profilmanagement am Start (FSLogix oder das neue UPM), welches Cache Mode auch unter diesen Umständen performant und zuverlässig ermöglicht.

So isses. Ein Standalone-MTA muss ja dann quasi an Protokollen und Verfahren alles können, was Exchange (Online) beherrscht, es wäre aber ein anderes Team dafür zuständig. Wirtschaftlich ergibt das überhaupt keinen Sinn. Aber es gibt ja zum Glück haufenweise Alternativen

Was heißt hier Telemetrie? SMTP war deprecated in Server 2012: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831568(v=ws.11)?redirectedfrom=MSDN#smtp Nun, nach 13 Jahren, ist er raus. Das ist genug Vorlauf, um MailEnable, hMail, PostFix, Exim oder was auch immer zu implementieren...

Moin, schau Dir mal Observium an. Gibt's auch als virtuelle Appliance von Turnkey Linux.

+1 Und weil DOS-Befehle in PowerShell-Skripten hässlich sind, ([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups

/admin war mal und wurde aus Kompatibilitätsgründen erhalten...

Das kannst Du auch am Client sehen

Wenn Du RD Gateway deployment in a perimeter network & Firewall rules - Microsoft Community Hub meinst, dann ist der Artikel vom 2009, und da hat wirklich noch keiner RODC verstanden, auch bei Microsoft.

Der Use Case für RODC ist genau der, für den MSFT das für das US-Militär entwickelt hat: Ein Standort mit schlechter physischer Sicherheit (Feind überrennt Stützpunkt), an dem dennoch lokale Authentifizierung vorhanden sein muss (Uplink ist nicht immer zuverlässig). Und das ist auch der einzige Use Case, in dem man *irgendwelche* Benefits vom RODC erwarten kann.

Den Kampf habe ich schon fast aufgegeben

Moin, kannst Du die FSMO-Rollen hin- und herschrieben? Ist die Replikation soweit auf allen DCs gesund?