cj_berlin

Wir erzählen den Leuten seit 20 Jahren, dass man Patches testen soll, und alle nicken dabei verständnisvoll, tun's aber am Ende nicht oder höchstens als "Smoke-Test". Wer Code - egal ob es eine neue Anwendung oder ein Patch der bestehenden ist - ungetestet in die Produktionsumgebung rauslässt, hat keine Produktionsumgebung, sondern nur eine Testumgebung, die er produktiv benutzt.

Meinst Du, man muss sich die Cloud mit dem Nachtschichten-Kaffee schöntrinken?

So isses.

Greift das Intranet parallel auf eure Datenbank zu? Lässt sich da vielleicht nachts ein Abzug in eine andere Instanz machen und das Intranet von dort befeuern? Diese Instanz kann man dann CPU- und RAM-technisch beschneiden. Dann ist das Intranet zwar langsam, aber dafür muss die Hauptapplikation nicht leiden.

Da 2022 auch FL 2008 kann, geht es auch ohne Zwischenschritt.

Moin und herzlich Willkommen, <Disclaimer: Keine verbindliche Rechts- oder Lizenzberatung in einem freien offenen Forum möglich!> Die Befürchtung ist begründet. Sobald irgendwas auf den zweiten Knoten zugreift, ob lesend oder schreibend, ist er zu lizenzieren.

Ja, das sehe ich auch. Wenn das Update bzw. die Prüfung einmal fertig ist, beruhigt sich das wieder.

Moin, die Migration auf DFS-R musst Du vor dem dcpromo des neuen DC durchführen, da Server 2016+ kein NTFRS mehr können.

Darum: Du versuchst den String so aufzulösen (Kopie von oben): extensionAttribute1="BisherigerWertAus$User.department" Das bedeutet für den Parser: extensionAttribute1="BisherigerWertAus$($User).department" weil für ihn der Punkt ein Begrenzungszeichen für Variablennamen ist. Und für ein AD-Objekt löst sich die Variable im String in den distinguishedName auf. Wenn Du eine Property durch String Expansion verwenden möchtest, musst Du das dem Parser explizit mitteilen: extensionAttribute1="BisherigerWertAus$($User.department)"

In meinem Lab hat es von den >20 vorhandenen DCs auf beiden Plattformen keinen einzigen betroffen.

Updates sind raus: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-january-2022-exchange-server-security-updates/ba-p/3050699 Und Domain Controller nicht vergessen: https://dirteam.com/sander/2022/01/11/three-active-directory-vulnerabilities-were-addressed-during-microsofts-january-2022-patch-tuesday/

Verifiziere doch erst mal, dass es funktioniert. Start-ManagedFolderAssistant oder bis morgen warten und dann schauen, ob der Tag den Elementen zugewiesen wurde.

Wenn die im KB zitierte Ursache zuträfe (Folder ist Client-Only), hättest Du ja kein Issue, oder?

Moin, Du kannst einen Retention Policy Tag für SyncIssues anlegen und dann mittels Retention Policy die Vorhaltezeit auf ein paar Tage oder Wochen setzen.

Die Anmeldemaske zeigt doch seit Windows 8 nur eine Domäne an? *welche* das ist, dafür gibt es tatsächlich eine Richtlinie. Die ist aber computerbezogen.

also die GUID

Keine. Eine RD-Bereitstellung mit Connection Broker setzt Active Directory voraus. Die Absicherung über einen Gateway ist technisch auch unabhängig von der Domain-Mitgliedschaft machbar, aber: Für HTML5 brauchst Du Per-User-RDSCALs, außerhalb eines AD sind aber nur Per-Device-RDSCALs möglich. Und last but not least: Wenn der zusätzliche Server jetzt schon nur übers Internet erreicht werden kann, dann solltest Du auf diesem vielleicht einfach den RD Gateway mit implementieren und gut...

Es gibt kein "bei sich gucken" für globale Objekte. Du könntest das nur parallelisieren, wenn Du die Auswahl in Get-Mailbox bereits aufteilen kannst, z.B. pro OU oder Datenbank. Du sollst ja auch nicht Invoke-Command verwenden, sondern New-PSSession.

Moin, ein reines IPv6-Setup ist von Exchange nicht supported. Ansonsten: DNS einfach leer lassen?

Moin, was möchtest Du denn damit erreichen? Innerhalb einer Exchange-Organisation (=innerhalb eines AD-Forests) liefert Dir jeder Server alle Mailboxen. Ansonsten ist der korrekte Weg, remote mit Exchange-Servern zu kommunizieren, https://docs.microsoft.com/en-us/powershell/exchange/connect-to-exchange-servers-using-remote-powershell?view=exchange-ps#connect-to-a-remote-exchange-server

Wie meinen? Der Benutzer kann sich eh nur an der Domäne anmelden, zu der er gehört. Wenn Du auch Netzwerkzugriff beschränken willst, musst Du die Gruppe in alle Deny-Rechte stecken, die da angeboten werden: Remote Logon, Batch Logon und vor allem "Access this computer from network". Es bleibt aber natürlich die Frage Was willst Du mit dieser Übung wirklich erreichen? Die Security Boundary im AD ist der Forest, nicht die Domäne innerhalb des Forests.

Moin, User Rights Assignments --> Allow Log On Locally + Deny Log On Locally In allen "unzulässigen" Domänen diese Gruppe in das "Deny Log On locally"-Recht stecken und auf alle Member-Maschinen anwenden.

Moin, die Jobs schlagen wirklich fehl, d.h. sie werden nicht fortgesetzt, nachdem das Limit gerissen wurde. Soweit ich mich erinnere, werden die bereits importierten Elemente aber nicht wieder gelöscht. Die Praxis zeigt jedoch, dass die BadItems meist uralte Kalendereinträge sind, so dass sie in der Verarbeitung ziemlich am Anfang stehen und kaum etwas importiert wird.

Das würde ich anders formulieren: Das eingebaute Backupsystem macht exakt das, was man ihm sagt. Wenn man nicht sagt, dass man mit den Logs etwas machen möchte, macht es damit auch nix. Außer sichern natürlich Und bei 3rd Party-Produkten, so z.B. Veeam, muss man auch explizit angeben, dass die Logs abgeschnitten werden sollen.

Jedenfalls nicht nachhaltig. Man könnte anfangen, an MOFs herumzudoktorn oder Ähnliches, aber das ist evtl. mit einem Patch dann wieder weg...