cj_berlin

Wo steht das denn bitte? Woraus leitet sich bei Dir dieser Anspruch ab? Der "Job" von Microsoft steht in der EULA, der die Admins bei der Installation des Produktes zugestimmt haben. Willst Du den Wortlaut der "Jobdefinition" nochmal hören? Gerne: The SOFTWARE is provided AS-IS. Für den Hersteller ist es eine Abwägung: Wenn ich 300 hochqualifizierte Leute mehr einstellen muss, um QA zu verbessern, kostet mich das im Jahr 50 Millionen. Wenn X Kunden zu Linux wechseln, kostet mich das im Jahr Y Millionen. an verlorenem Lizenzumsatz. Wir haben doch freie Marktwirtschaft, oder nicht? Die Theorie ist, der Kunde hat die Wahl

Der Vergleich mit dem Auto hinkt insofern, als dass der Hersteller das fertige Auto in seiner Gewalt hatte, bevor es an Dich ausgeliefert wurde, und somit eine Qualitätssicherung des gesamten Konstruktes prinzipiell möglich war. Bei Dir ist ja nicht "das Windows" in die Bootschleife gegangen, sondern ein von Dir gebauter und konfigurierter Server mit diesem Windows drauf, der auch noch Teil einer größeren Umgebung ist. Diesen Server als Ganzes hat der Hersteller noch nie gesehen, Und ja, vielleicht haben sie auch krass andere Server. Entzieht sich meiner Kenntnis. Sie sind aber definitiv nicht identisch mit unseren. Produktionsserver aus Backup zum Testen zurückholen ist ein Ansatz und wird auch bei manchen Firmen praktiziert, um den Preis der "doppelten TB". Natürlich wird es nicht händisch gemacht. Der andere Ansatz ist eine Testumgebung parallel zur Produktion zu betreiben, halt mit weniger Daten drin. Dort wird dann alles Neue zuerst eingespielt und geschaut, ob die Umgebung wieder hochkommt. Da Du in Deiner "Produktion" ja bestimmt Monitoring am Start hast, kannst Du doch maschinell beurteilen, wie der Gesundheitszustand der Umgebung so ist. Auch ich wünsche mir das mit der Patch-Qualität anders. Aber am Ende des Tages, wenn ich die Umgebung betreiben soll, kann ich nicht Teile dieser Betriebsverantwortung stillschweigend auf die Hersteller auslagern, ohne dass sie wissen, dass sie diese Verantwortung jetzt tragen, und dem zugestimmt haben.

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.