cj_berlin

Ich würde nebenbei auch noch in die Ausschreibung von der F123 schauen. Eventuell ist da die Verpflichtung zur Nachlieferung drin, wie man es in einer besseren Welt erwarten würde. Und dann wandert das Problem dorthin, wo es hingehört, ohne übermäßig hohe Kosten für den Steuerzahler EDIT: Die Specs sind ja da, ich kann mir nicht vorstellen, dass die Erstellung eines Diskettenlaufwerks oder des Mediums ein verloren gegangenes okkultes Wissen darstellt... Aber ich bin halt ein Idealist - natürlich wurde jedweder After-Sales-Support dort ausgeschlossen, wie bei jeder Public-Private-Partnership. Drum halten einige Parteien die PPPs ja auch heute noch für ein Erfolgsmodell.

Naja, im letzten Jahrhundert konnte ja wirklich niemand ahnen, dass man sich mit einer Branche ins Bett legt, die vom Consumer-Verhalten getrieben wird. Es sind halt ganz andere Produktzyklen - die TU-95 und die B-52 werden, wenn der Plan aufgeht, fast 100 Jahre im Dienst gewesen sein. In der IT indes unterstützt Apple eigene Produkte nicht mehr, die vor fünf Jahren vom Stapel gelaufen sind. Da prallen halt Welten aufeinander. In Aerospace ist es üblich, die gesamte Entwicklungsstrecke eines Produkts bis zu dessen Verglühen bei Wiedereintritt zu konservieren. Da können gut und gern 20-30 Jahre vergehen. Weiß jemand, ob man dann noch USB-A und RJ-45-Stecker findet, falls mal Ersatzteile benötigt werden? Nein, das weiß kein Mensch. Will sagen, vielleicht sind "unsere" Produktzyklen zu kurz und nicht die anderen zu lang?

Moin, der RDP-Client läuft im Kontext des Users. Du kannst ihm kaum verbieten, einen Prozess, den er gestartet hat, zu beenden. Insofern, selbst wenn Du den X-Button irgendwie weg operiert bekommst, bleibt immer noch taskkill

Moin, Du meinst vermutlich VAMT? Das ist Teil des Windows ADK: Install VAMT - Windows Deployment | Microsoft Learn

Hmmm. Ich sehe den Download.

$schemaNC = ([ADSI]"LDAP://RootDSE").schemaNamingContext[0] $dS = New-Object System.DirectoryServices.DirectorySearcher $ds.SearchRoot = New-Object System.DirectoryServices.DirectoryEntry(('LDAP://{0}' -f $schemaNC)) $ds.SearchScope = [System.DirectoryServices.SearchScope]::Subtree $ds.Filter = '(&(objectClass=attributeSchema)(isMemberOfPartialAttributeSet=TRUE))' $null = $ds.PropertiesToLoad.Add('name') $ds.FindAll().ForEach({$_.Properties['name'][0]})

Moin, nur um ganz sicher zu gehen: Die Einträge haben auch ein Ablaufdatum? Worauf ist Refresh und NoRefresh eingestellt?

How to Seize a FSMO Role with NTDSUtil (briandesmond.com)

Moin, nein, diesen Unterschied hat es als funktionalen Unterschied nicht gegeben. Kann der User sich über RDP anmelden, wenn Du ihn in die lokalen Admins steckst? Kann ein anderer User, der Mitglied in "Remote Desktop Users" ist, sich über RDP anmelden?

Ja

Moin @wznutzer, vielleicht merkst Du es schon: Die ultimative Antwort auf Deine Herausforderung wäre ein Web-Frontend für das ERP, idealerweise mit MFA. Dann musst Du niemanden in Dein Netz lassen, und das Thema ist erledigt. Vielleicht kann der Anbieter der ERP-Software so etwas ermöglichen, zumindest für den Teil der Arbeit, welcher an Externe rausgegeben wird? Ist es nicht möglich, dann hast Du User, die sich in Deinem Netz anmelden und deren Credentials theoretisch abhanden kommen könnten. Und an dieser Stelle gibt es keine Empirik, die nahelegt, dass Externe dort weniger Sorgfalt an den Tag legen würden als Interne, eher im Gegenteil. Somit musst Du für jeden User, intern wie extern, eine Blast Radius-Analyse betreiben und die Angriffsfläche entsprechend einschränken. Da sprechen wir aber nicht primär über IP-Adressen und Ports, sondern über Berechtigungen. Für IP-Adressen und Ports gibt es zwar auch einige leicht umzusetzende Vorschläge, welchje die Sicherheit erhöhen (Clients dürfen nicht miteinander sprechen, Client-, Drucker- und VPN-Netze dürfen nicht in Management-Netze sprechen usw.) aber das ist unabhängig von diesem Thread. Mein Lieblingsbeispiel: Es gibt NULL Notwendigkeit für Otto Normaluser, egal ob kaufmännisch gesehen intern oder extern, Admin-Accounts, Admin-Gruppen oder Computer-Objekte per LDAP im AD zu lesen. Betrachtet man es genauer, ist es in 95% der Fälle für Otto Normaluser nicht notwendig, IRGENDEIN AD-Objekt aus der Domain-Partition außer dem eigenen User-Objekt zu lesen. Und wenn man das verinnerlicht hat und sich dann den Schreibrechten zuwendet, kann man weiter härten Druckspooler überall deaktivieren, wo nicht gedruckt wird. EDIT: Auf Tier 0-Systemen auch dann, wenn dort gedfdruckt wird, und das Drucken von dort entfernen. Wie, ist egal. Alle Webdienste aus dem Repertoire von ADCS rigoros deinstallieren, bis auf HTTP-CDP und OCSP. Last but not least: Ich weiß nicht, ob die Vertragslage sich geändert hat, aber früher war es nicht ohne weiteres zulässig, Personen auf seiner Windows-/SQL-Infrastruktur dauerhaft arbeiten zu lassen, die wirtschaftlich nicht zu dem Lizenznehmer-Unternehmen gehören. Vielleicht kann @lizenzdoc das auch noch bewerten.

Das nicht, aber ich kenne einige, die länger benötigen würden, das optimierte Skript zu entwickeln, als die Laufzeit des unoptimierten gewesen wäre

Musst Du nicht. Viele haben sich die Arbeit bereits gemacht, hier ein Beispiel: Selbst wenn das der einzige Vorteil wäre, wäre es in vielen Situationen ein enormer Vorteil Beispiel: Information aus dem AD wird in einem Login-Skript benötigt. Installierst Du dann auf 10.000 Clients AD-RSAT?

Du hast aber auch den Anfang der PURE-Seite gelesen, gell? Die einzige Situation, wo es wirklich ars***rettend ist zu wissen, wie man Dinge ausschließlich mit PowerShell-Cmdlets löst, tritt dann ein, wenn Du dich als Skripter plötzlich unter Constrained Language Mode wiederfindest. An der interaktiven Kommandozeile ist es in der Regel auch einfacher, Cmdlets als .NET-Klassen zu verwenden. Beim Skripten jedoch spielen andere Faktoren eine Rolle: Performance und ihre Komplementärdisziplin, der Ressourcenverbrauch Portabilität Robustheit und da ist man gut beraten, die dem ganzen zugrundeliegenden .NET-Techniken zu beherrschen.

Nein, das sollte auf das stehen, was funktioniert. Probier's mal mit RemoteSigned, denn das ist die Standardeinstellung bei Servern.

Ich würde sagen, Du hast die Execution Policy auf dem Exchange Server hochgesetzt. Was gibt Get-ExecutionPolicy -List zurück?

Moin, aus Erfahrung von mehreren Projekten mit Windows 10 Rollouts im öffentlichen Dienst kann ich von LTSC nur abraten. Ich weiß nicht, ob die Windows 11 LTSC-Variante, so die sich irgendwann manifestiert, von besserer Qualität sein wird, aber Win 10 LTSC war eine Katastrophe. Bluescreens, fehlende Treiber für ganz grundlegende Geräte, Drucker lassen sich zwar installieren, verschwinden dann aber gleich, Third Party-Software, die nicht macht, was sie soll. Umstieg ist eine Neuinstallation, da ein separates OS. Irgendjemand wird damit bestimmt auch gute Erfahrungen gemacht haben, wenn er DAS PC-Modell erwischt hat, mit dem Microsoft auch getestet hat. In "meinen" Projekten hatten wir aber ausschließlich Mainstream Business-Hardware von HP und DELL mit allen oben aufgelisteten Schweinereien. Aber John Wilcox in LTSC: What is it, and when should it be used? - Microsoft Community Hub bringt es auf den Punkt: Wenn Du die Hardware-Konfiguration für 10 Jahre fixieren kannst, bietet LTSC die Möglichkeit, auch die Software-Konfiguration für 10 Jahre zu fixieren. Andernfalls ist es die falsche Wahl.

Korrekt.

Naja, es gibt ja die Policy "wait for network", nur traut man sich in VPN-Szenarien meistens nicht, sie zu aktivieren... Beste Lösung bisher: Clients raus aus dem AD, cloud-joined und Kerberos für den Zugriff auf on-prem Ressourcen einrichten...

Moin, ich würde sagen, voicewarmupx, einmal manuell durchinstallieren, einmal mit der MST, und die Logs vergleichen.

Es geht bei der Frage aber nicht um S2D. Storage Spaces, ohne Direct, existieren sogar auf Client-OS, wenn ich das noch richtig im Kopf habe. Um das Konzept im Feld zu erproben, hat Microsoft jahrelang den Home Server verkauft 😊

Das BSI ist nur involviert, wenn Behörden oder KRITIS-Unternehmen betroffen sind. Wenn TeamViewer also nachweisen kann, was sie behauptet haben (Produkt und Kundendaten sind nicht betroffen), hat das BSI nichts damit zu tun.

Ich weiß nicht, ob es im Buch steht, aber viele Hypervisor erlauben es, TPM einer VM hinzuzufügen. Von dem, was die Leute so in ihren Homelabs haben, ist das einzige verbreitete System, auf dem es NICHT geht, ESXi ohne vCenter. Hyper-V kann das, VirtualBox kann das, VMware Workstation und Fusion kann das auch...

Moin, ist denn das BitLocker *Feature* auf der Maschine installiert bzw. aktiviert?

Dann kannst Du ja genau die Module nachinstallieren, die Du nutzen willst. [Ctrl+C] --> [Ctrl+V] Welches wäre denn von solch einem existenziellen Interesse? Und Module, die nur in der eigenen Interaktiven Session was bringen, brauchst Du nicht an den vielen kopflosen Servern, zu denen Du hin remoten würdest... Gegen die Installation von pwsh auf einigen wenigen Admin-Workstations hat, glaube ich, niemand was, und gerade in Verbindung mit Graph oder PowerCLI kann es zu einer verbesserten Performance führen. Aber halt nicht auf den vielen Zielsystemen!