cj_berlin

Moin, nein, Du musst nicht alle physischen Cores lizenzieren. Du musst die vCPUs lizenzieren und, sofern Du SA abgeschlossen hast, bist Du durch. Wenn Du keine SA abschließt, musst Du mit technischen Mitteln verhindert, dass die VM häufiger als alle 90 Tage den Host wechseln kann. Der von Dir zitierte Passus ist quasi die Umkehrung von Multithreading - ich wüßte nicht auf Anhieb, welcher Hypervisor das macht, und Hyper-V macht es bestimmt nicht.

Ja, clientseitig auf einem Stand zu bleiben, den diese Serverversion noch unterstützt, wie Du auch selber festgestellt hast. Und wenn dann auch die Outlook-Version N+2 aus dem Support ist, weißt Du, dass die Stunde geschlagen hat und Du auch nicht mehr wirst migrieren können, weil es keinen unterstützten Migrationspfad mehr gibt, außer Cross Forest mit Third Party-Tools.

Ja, aber es ist nicht gottgegeben. Und der Lösungsansatz kann nicht sein, dass der Endkunde die ganze Maschine tauschen muss, sondern der Hersteller ist in der Pflicht, seinen Shit sicherer zu machen. Wenn deren Laser den Strahlenschutzanforderungen nicht mehr entsprechen, bessern sie ja auch nach. Warum die IT-Sicherheitsanforderungen hier anders behandelt werden sollen, ist mir unklar. So eine Industrie-Maschine läuft 15 Jahre und wird auf maximal 11 Jahre abgeschrieben. Vor 11 Jahren war das SMB1-Thema schon ein alter Hut. Und wenn euch vor 15 Jahren jemand Windows NT verkauft hat, ist es nicht mehr nur grob fahrlässig. Und ja, ich weiß, dass es in der Praxis überall so ist. Aber wie Mark Minasi in "the software conspiracy" schrieb, nur die Kunden können das ändern, denn die Hersteller haben kein Incentive dazu.

Ja, aber sie ist eher langfristig ausgelegt. Dem Hersteller der Anwendung, die SMB1 verwendet, so lange in den A**** treten, bis das endlich gefixt wird. Ansonsten, wenn es "sicher" sein soll: SMB1-Zugriffe auf ein VLAN begrenzen, und alle Systeme, die diesen Zugriff wirklich brauchen, sollen ein Bein in diesem VLAN haben, und möglichst nur dort. Jetzt wirst Du sagen: Das sind aber alle Clients Dann hast Du verloren. Eine VM, außerhalb der Domain, möglichst als SAMBA - je mehr Halbmaßnahmen man übereinander häuft, desto schwieriger wird es zu debuggen, wenn etwas schief läuft.

Moin, die "händische Variante" lässt sich durchaus skripten: Du gehst alle Unterschlüssel von HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList durch und setzt in jedem den Wert "State" auf 0. Aber in meiner Erfahrung ist die Ausschussquote hier minimal.

Teams ist ein schwieriger Fall. Der Service entwickelt sich feature-mäßig so rasant, dass selbst der Gedanke einer "LTSR-Edition" des Clients, die nicht alle Features hätte, dafür aber fix installierbar wäre, vermutlich häufigere Updates bedeuten würde als einem lieb ist. Ist halt "perpetual beta"-Software, auch bekannt als "agiles Development". Andererseits, nur so haben Office Apps & Services MVPs genug zum Bloggen Warum allerdings jeder andere Mist unbedingt über den Store und somit im User-Kontext verteilt werden muss, obwohl er alle Jubeljahre mal Updates erfährt, frage ich mich auch jedes mal. Windows Terminal, zum Beispiel.

Hatte ich vor zwei Wochen, Landesbehörde. Und selbst da hat es einer geschafft, sich innerhalb von 20 Minuten nicht einwählen zu können.

Moin, welche Rollen sind denn bereits auf dem Server installiert? Wenn da Routing & RAS drauf ist, bindet es in manchen Konstellationen auch an den DNS-Port.

Moin, mit der richtigen Konfiguration ist es aber auch nicht nötig, viele Systeme ins AD aufzunehmen. Kommt immer darauf an, ob man Gott-Accounts haben möchte oder nicht. "Geht alles" beinhaltet in letzter Konsequenz immer SIEM und jemanden, der die Ereignisse dort 24x7 nahezu in Echtzeit auswertet, denn nur so kannst Du ein Gott-Account aufhalten. Viele einzelne systemspezifische Admins (ohne password reuse eingerichtet ) zu knacken dauert schon deutlich länger und hinterlässt auch mehr Spuren. Leider sind genau die Organisationen, die kein Geld für SIEM und SOC haben, diejenigen, welche auch kein Geld für ordentliches Configuration Management haben und deshalb das AD dafür missbrauchen, mit den bekannten Folgen.

Alternativ natürlich, falls @yoda123 keine Lust hat, PowerShell zu lernen, gäbe es auch https://docs.microsoft.com/de-de/windows-server/administration/windows-commands/forfiles

Nur, dass es die Domain-Maschine ist, die den AV-Manager fährt

Was Norbert sagt. Das Stichwort für die on-prem-Variante ist "centralized Mailflow".

Moin, das (oder so ähnlich) sollte per "Library Sharing" möglich sein. Die DPM-Instanzen teilen sich dann aber nicht eine DB, sondern greifen auf die Datenbank des jeweils anderen DPM-Server zu. https://robertanddpm.blogspot.com/2013/11/tape-library-sharing.html

...und die Frage ist?

Moin, wenn manueller "Transfer from Master" geklappt hat und automatische Replikation nicht, dann fehlen Dir vermutlich Update Notifications. Dies stellst Du in den Eigenschaften der Zone ein, dort, wo Du angibst, an wen sie transferiert werden darf.

Moin, alles unter "RBAC" beschrieben: https://docs.microsoft.com/en-us/exchange/understanding-role-based-access-control-exchange-2013-help

Friends don't let friends run unsigned binaries in production

Moin, solange Du nicht auch noch die Policy "lokale Kopie des servergespeicherten Profils bei Abmleden löschen" gesetzt hast, wird ja gar nichts verschoben, sondern nur kopiert. Policy deaktivieren, Anwendung abwarten, Serverkopie löschen, fertig. Hast Du die o.g. Policy aktiviert, so musst Du sie zuerst deaktivieren, dann muss sich jeder User einmal an jedem Computer anmelden, wo er gern ein Profil hätte, und dann deaktivierst Du die Policy für den Profilpfad.

Moin, Du verwendest die Variable $listViewItem mehrfach, für verschiedene Zwecke. AD-Zeit ist FileTime, Du brauchst [datetime]::FromFiletime($item.lastlogon) Und bedenke: Wenn Du mehr als einen Domain Controller hast, ist LastLogon nicht notwendigerweise bei jedem User auf jedem DC belegt. Du könntest auf LastLogonTimestamp ausweichen - das ist überall gleich, ist aber nicht zwangsläufig der allerletzte Logon.

https://lmgtfy.app/?q=get-acl+permissions+report

Moin, Laufwerksrechte werden nicht im AD, sondern im NTFS-Dateisystem vergeben. Deine Freunde sind Get-ChildItem und Get-ACL.

Nein, wenn es nicht "remote" ist. Remote = von einem Server kommend, der in den Internet Explorer Security Zones nicht "Intranet" ist. Da ein Logon-Skript in der Regel aus SYSVOL kommt, wäre es im Zweifel nicht "remote". Außerdem, wenn Du das Skript im GPO-Zweig "Scripts" ausführst, wird die Execution Policy für diese Ausführung aus "Bypass" gestellt.

Wenn weder AppLocker noch Execution Policy das erzwingen, dann musst Du es auch nicht signieren.

Moin, da es eine filebasierte Zone ist, ist offenbar DC-DOM01-01 der Primary und DC-DOM02-01 der Secondary. Was passiert denn, wenn Du auf DOM02-01 "Transfer from master" sagst? An wen sind Zone Transfers in den Eigenschaften der Zone erlaubt?

Moin, vielleicht beschreibst Du etwas weniger emotional, aber dafür mit mehr Fakten (Screenshots, Logs, Fehlermeldungen usw.), was tatsächlich passiert ist. Auch das Einspielen des Hotfixes hinterlässt massenhaft logs - findet sich da irgendwas sinnvolles?