cj_berlin

...aber das ist es ja gerade NICHT, worauf Du dich im OP beziehst. Einzelne Updates freigeben, zurückhalten, zu einem definierten Zeitpunkt installieren - alles reale Anforderungen des Patch Delivery, die mit WSUS, GPOs und ein paar Skripten zuverlässig bedient werden können, das machen wir alle in Umgebungen groß und klein seit Jahrzehnten. Niemand rät davon ab, WSUS für Patch Delivery zu benutzen, denn es gibt ja nur sehr wenige Alternativen, zumindest was die zugrundeliegende Technologie angeht. Du hingegen wolltest in Deinem OP Reports haben, und zwar zu einem von Dir gewünschten Zeitpunkt, und mittels eines Features, das dafür zwar leider irgendwann gebaut worden, aber noch nie wirklich gedacht gewesen ist. Wenn es Dich interessiert, ob bestimmte Updates auf einem bestimmten System installiert sind, und es Dir möglich ist, auf diesem System remote mit Adminrechten ein Skript auszuführen, dann kannst Du doch mit genau diesen Mitteln gezielt abfragen, ob die gesuchten Updates dort installiert sind oder nicht. Weniger Aufwand, sofortiges Ergebnis. Und der Report kommt irgendwann, so wie es schon immer bei WSUS der Fall war. Hier ein ganz grobes Beispiel: $session = New-Object -ComObject 'Microsoft.Update.Session' $history = $session.QueryHistory("",0,5000) if ($history | Select-Object -ExpandProperty Title | Select-String "KB5016616") { "August CU installed" } else { "August CU not installed" } lässt sich auch ohne irgendwelche erhöhten Rechte mit normalen Adminrechten aufrufen.

Und genau da liegt das Mißverständnis: WSUS hat nie versprochen, etwas zu sein, was besser oder mehr ist als Microsoft Update, nur halt lokal. Vor 20 Jahren war Bandbreite ins Internet, selbst in großen Umgebungen, noch wichtig. Dass jemand diese Reporting-Funktion da eingebaut hat, ist zwar nett, hilft aber - wie Beiträge wie der obige zeigen - nur bedingt, weil das einwandfreie Funktionieren dieser Funktion nicht Teil des Service-Versprechens ist. Und die Kleinumgebungen haben so viele Baustellen mehr, an die sie sich nicht trauen ( SMB1, NTLM, PKIs, die nach Weiter-Weiter-Finish ohne Sinn und Verstand eingerichtet wurden, Exchange per NAT ins Internet veröffentlicht, Adminkonten mit Mail-Postfächern, NT4- und SAMBA2-Maschienensteuerungen im gleichen Netz wie AD, SQL mit leerem SA-Kennwort und Service-Account in Builtin\Administrators, Azure AD Connect für alle User, Gruppen und Computer, Branchenanwendungen aus dem schwäbischen Hinterland, die nur bei ausgeschaltetem UAC funktionieren und pauschale Ausnahmen aus dem Virenscan für 1000 Ordner brauchen, und, und, und... ) Da muss ich meist wirklich schmunzeln, wenn die Menschen dann versuchen, jedes einzelne Update extra freizugeben und dann auch noch Reporting darüber erwarten, ob es denn auch sofort installiert wurde

...aber nur von Beiträgen wie diesem, nicht aus dem richtigen Leben. Und immer fehlt die Erklärung, warum es wichtig sein soll, dass die Reports zu einem bestimmten Zeitpunkt reinkommen. WSUS ist nicht Patch Management, sondern nur Patch Delivery. Und Patch Delivery funktioniert durchaus zuverlässig. In der Sache: 1. in dem Skript wird die Variable $criteria nicht gesetzt, sie ist aber wichtig! Da sollte stehen "IsInstalled=0 and Type='Software'" 2. warum sollte ein Skript, das ausschließlich REMOTE-Befehle enthält, LOKAL mit erhöhten Rechten ausgeführt werden? Es werden Adminrechte auf dem entfernten System benötigt, aber lokal kann es ganz normal gestartet werden.

Nö, das ist normal üblich. Eine herkömmliche Firewall kriegt ja keine Informationen zum Benutzer, der die Kommunikation auslöst, sondern nur die Quell-IP. Und um diese einem Benutzer zuzuordnen, überwacht sie Event 4624 auf sämtlichen DCs und nimmt die Zuordnung entsprechend vor. Gibt lustige Nebeneffekte, wenn man von einem Client RDP-Verbindungen mit anderen Accounts aufbaut und NLA aktiviert ist.

Naja, das Wandeln von Golf in Porsche geht ja auch: Golf weg, was dazu tun, Porsche ran. So ist es auch hier

Moin, nur aus Interesse: Wie stellst Du dir technisch das "Wandeln" eines Verteilers in ein Postfach vor? Was für Regeln sind das denn? Habt ihr das mal mit einer einzelnen einfachen Regel versucht? Werden die Regeln ausgeführt, wenn man sie aus Outlook heraus explizit startet?

Moin, dann braucht der Installer vermutlich Parameter für eine unbeaufsichtigte Installation. Sie musst Du ihm als Transform in der GPO mitgeben - oder Du installierst das Ding per Skript. Frag den Lieferanten nach der Parametrisierung für "silent install".

Wieso, ist doch nur des Angreifers. Und nicht registriert, ist also gespooft. Korrektur: Ist doch registriert, chinesisch. Anmeldetyp 3 ist Netzwerk-Anmeldung, kann also ein beliebiges authentifizierungspflichtiges Protokoll sein - RPC, SMB, HTTP, WinRM etc. Mach doch die Firewall komplett zu, wenn die Maschine ungefiltert im Internet steht.

Moin, wenn Du Archivmailboxen listen willst, musst Du es dem Cmdlet sagen: Get-Mailbox -Archive -Database <myarchdb>

Das hat aber keinerlei Funktion, reine - wenn auch in einer ordentlichen Umgebung notwendige - Kosmetik.

...und drei Wochen später ist sie auch drin:

Nein:

Wenn alle Leserechte aus Authenticated Users unverändert sind, sollte das langen.

Moin, AD Rechte kannst Du genau so setzen wie Dateisystemrechte, per Get-ACL/Set-ACL und AD-Laufwerk ("AD:<distinguishedName>")

Das ist ein altes Thema, und anscheinend immer noch nicht gelöst...

Da Du nicht schreibst, WARUM Du meinst, die Domäne neu aufsetzen zu wollen/müssen, ist es schwer zu sagen, ob es Sinn macht. Du solltest die Artefakte aus längst vergangenen Zeiten bereinigen, da helfen Tools wie PingCastle, den Überblick zu behalten. Einige dieser Artefakte wirst Du nicht bekommen, wenn Du die Domain neu auf 2019 oder 2022 aufsetzt, aber ob das die Arbeit rechtfertigt? Meiner Meinung nach, solltest Du die Arbeit lieber in folgende Punkte investieren: SMB1 überall loswerden und von den Windows Devices als Feature deinstallieren NTLM möglichst beschränken und am besten blockieren Berechtigungen auf AD-Containern und GPOs gerade ziehen und härten Alle nicht mehr vorhandenen PKI-Bäume aus dem AD entfernen, evtl. vorhandene Enterprise PKI härten Es gibt genug zu tun, und viele dieser Dinge werden an Deinen Usern unbemerkt vorbeiziehen, wenn Du es sauber umsetzt. Der Neuaufbau wird in der Regel Reibungsverluste verursachen.

Hallo zusammen, wir wollen versuchen, eine neue Community-Konferenz auf die Beine zu stellen. Bitte füllt die Umfrage aus und teilt uns mit, was ihr euch von einer Konferenz wünscht/erwartet: https://forms.office.com/r/mxVkVVJ3k7 Für Neuigkeiten, Daten, Orte, CfP usw. könnt ihr gern @WeConfDE auf Twitter folgen. ------------------------------------------- Hinweis der Moderation: Dies ist keine Aktion des MCSEboard.de und die Umfrage wird auch nicht von uns gehostet.

Danke, ist erledigt

So, wir probieren es mal mit einem neuen Format Ich habe mal eine Umfrage und einen Twitter-Account erstellt. Bitte teilnehmen und im Bekanntenkreis weiterverbreiten, damit wir möglichst viele Community-Stimmen sammeln können Hier die Umfrage: https://forms.office.com/r/mxVkVVJ3k7 @Mods: Falls ihr den Wunsch verspüren solltet, daraus einen Pinned Something zu machen, feel free! Ich werde zu gegebener Zeit berichten

Ja, aber diesmal als Aussteller

Nein.

Und, natürlich, wie immer: AUF CROSS-POSTS HINWEISEN! https://social.technet.microsoft.com/Forums/de-DE/4359ac0f-319c-4fd8-91e0-b9d074478a8a/rds-farm-und-rdweb-monitoring?forum=windows_Serverde

Moin, das Herunterstufen vom DC macht erst mal nichts mit den anderen Rollen. Wenn man einen nicht heruntergestuften DC einfach ausschaltet, wird es unter Garantie Nebeneffekte geben. Dokument-Links kann auch ein Fileserver bedienen, der nicht mehr DC ist. Ich würde niemals absichtlich einen noch aktiven DC für einen längeren (als für den Reboot benötigten) Zeitraum ausgeschaltet lassen.

Genau. Bei dieser Gelegenheit wird er Dir ans Herz legen, den DCPROMO-Assistenten auszuführen, was Du dann auch tust. Wenn alles so sauber ist, wie Du beschreibst, müsste er ohne Anpassungen mit den Standardeinstellungen das gewünschte Ergebnis erreichen.

Wichtig ist nicht "false", sondern dass "ForwardingSMTPAddress" leer ist Steht evtl. im AD dennoch etwas im targetAddress-Attribut bei dem Postfachbesitzer?