testperson

Mit Netzwerk wäre ggfs. Intune oder ein selbst gehostetes Endpoint Management evtl. ein Ansatz oder eine AV Lösung, die ein Remote Management mitbringt. Mit abgeschottetem Netzwerk könnte man evtl. eine Domäne in Betracht ziehen. Ohne Netzwerk bleibt halt dein Script oder ggfs. gibt es bei einem Anbieter für (Privileged) Identity Management etwas im Regal. Um hier evtl. noch mit Ideen zu kommen, wäre wohl das "Warum muss der Rechner Standalone ohne Netzwerk betrieben werden?" zu klären bzw. müsste da wohl dran gerüttelt werden.

Hast du es einmal per Publisher Rule anstatt Path Rule getestet? Hast du es einmal ohne die AppLocker Variable %PROGRAMFILES% getestet und den aufgelösten Pfad "C:\Program Files\Mozilla Thunderbird\*" benutzt? Wenn da in der Regel kein "Copy&Paste Fehler" oder Typo drin ist, wäre ich bei dir und würde ebenfalls sagen, dass es so funktionieren sollte.

Und daran ist absolut nicht zu rütteln? Ansonsten könntest du - je nach dem was an Software zur Verwaltung vorhanden ist - nur diese Netzwerkverbindung erlauben. Ansonsten kann das so ja durchaus eine gute und passende Lösung sein. In der Theorie könnte jetzt noch ein WinPE / Linux von CD / USB gebootet werden und darüber das Script manipuliert werden. Mit Applocker könntest du noch alles an Scripts sperren und nur dieses per Dateihash freigeben. Alternativ / Zusätzlich das PowerShell Script signieren.

Hi, was ist denn genau? Kein Internet, kein Netzwerk, gar nix? Gruß Jan

Hi, was wird denn beim Aufruf von AppLocker laut Eventlog überhaupt geblockt? Gruß Jan

Hi, ich wäre skeptisch, ob Exchange (2019) auf Windows Server (2019) Essentials supported ist. (Integrate an On-Premises Exchange Server with Windows Server Essentials | Microsoft Learn) Auch wenn das eher nichts mit dem Problem zu tun hat. Gruß Jan

Hi, "bis nächstes Jahr" ist ja noch was Zeit. Was spricht dagegen, jetzt einen neuen Rechner zu organisieren und dort die Anwendungen nach und nach neu zu installieren? Dabei dann prüfen, welche Konfigurationsdateien / Einstellungen mit auf den neuen Rechner müssen und am Ende des Jahres mit einem entsprechenden Plan alle Rechner neu installieren und die Anwendungen koordiniert ausrollen. Gruß Jan

Dann sind wir jetzt wohl am Punkt von @daabm angekommen:

Meine Zeit, wo ich "viel" programmiert habe ist schon was länger rum und war noch in der vor PowerShell Zeit. Würde es aber laienhaft genau wie du beschreiben: Du erstellt das Userobjekt einmalig und fügst dann nur eine Referenz / einen Zeiger in die Userliste hinzu. Wenn du jetzt das Objekt änderst, zeigt der Pointer in der Userliste an allen Stellen ja auf das eine Objekt.

Die User haben sich nach der Aufnahme in die entsprechenden Gruppen auch vom Client ab- und wieder angemeldet? Ich habe mich bei AppLocker an diesem "Konzept" orientiert (UltimateAppLockerByPassList/AppLocker-BlockPolicies at master · api0cradle/UltimateAppLockerByPassList · GitHub). Hier müssen nur zwei anstatt ggfs. drei oder mehr Stellen geprüft werden. Generell sollte das aber wie von dir skizziert funktionieren: Understanding AppLocker rule exceptions - Windows Security | Microsoft Learn

Hi, wenn ich dich richtig verstehe, ist das so korrekt (Understanding AppLocker allow and deny actions on rules - Windows Security | Microsoft Learn): Gruß Jan

Hi, dann lag ich richtig. Pack die Erstellung des $Userobjekt in dein foreach. Gruß Jan

Hi, ich vermute, du erstellt einmalig dein Userobjekt und änderst dieses immer wieder mit neuen Daten aus der CSV. Dann ist das AFAIK by Design. Du wirst ja vermutlich die importierte CSV Datei per foreach-Schleife durchlaufen und so der Userliste deine Userobjekte hinzufügen. _Vermutlich_ erstellst du _vor_ der Schleife das Userobjekt und nicht _in_ der Schleife: # Vermutlich so / "falsch" $Inhalt = Import-Csv .... $Userliste = ... $Userobjekt = New-Object -TypeName User foreach($i in $Inhalt){ $Userobjekt.Vorname = $i.Vorname ... $Userliste.Add($UserObject) } # Sollte vermutlich zu deinen Erwartungen führen: $Inhalt = Import-Csv .... $Userliste = ... foreach($i in $Inhalt){ $Userobjekt = New-Object -TypeName User $Userobjekt.Vorname = $i.Vorname ... $Userliste.Add($UserObject) } Gruß Jan

Hi, du kannst im DNS doch einfach verschiedene Hostnamen (A-Records) mit der gleichen IP Adresse haben. Der Port hat ja am Ende nichts mit dem Hostnamen / FQDN / dem SSL Zertifikat zu tun. Am sinnvollsten dürfte es aber sein, einen Loadbalancer / Revers-Proxy "vor den Containern" bereitzustellen, der die Verbindung proxied und anhand des DNS Namens dann zur passenden Anwendung "routet". So kannst du die Services auch alle per https / 443 ansprechen und musst an den Clients die Ports nicht verbiegen. Gruß Jan

Hi, in meinen Augen ist das Ansichtssache und dürfte recht stark am Projektantrag hängen. In der Praxis erlebe ich tatsächlich häufig VPN Lösungen, die weit weg von "komplex" sind. Die sind dann aber i.d.R. auch eher weit weg von "sicher". Wenn es um Road Warrior geht, ist ja alleine schon die Entscheidungsfindung für "IPSec", "OpenVPN", "SSL VPN", "L2TP", "SSTP" oder Wireguard ein abendfüllendes Programm. Ebenso die Überlegung Linux Server oder fertige Firewall/Router/VPN Appliance (kostenlos / kommerziell) dauert seine Zeit in einem Abschlussprojekt. Ich würde behaupten, dass man mit einem der Punkte die 40 Stunden bereits sprengen kann und bis hier her ist noch gar nichts konfiguriert. Wenn man sich jetzt noch Gedanken um das Thema "Firewalling" im VPN macht, könnte das - je nach Anforderung - für ein weiteres Projekt reichen und weitere Komplexität mitbringen. (Eine Idee von mir in Richtung deines VPN Themas: "legacy VPN" vs. ZTNA bzw. "Zero Trust Network Access". Allerdings sicherlich sehr sportlich, dass in diesem Monat noch Projektantrag-fähig zu bekommen.) Gruß Jan

Hi, du wirst allerdings nirgendwo mehr die alten Zwischen CUs finden. Entweder direkt auf .Net 4.8, aktuelle VC Redist und dann CU23 + neuestes SU oder evtl. einen neuen Windows Server mit neuem und aktuell gepatchtem Exchange 2016 aufsetzen und dann migrieren. Gruß Jan

Dann schmeiß den Prozessmonitor an und prüfe, wo die Verzögerungen auftreten: Prozessmonitor - Sysinternals | Microsoft Learn

Ich teste das derzeit mit der neuesten Build vom Windows Server 2025. Erstelle mir aber auch gerade eine ISO für Win 11, um damit zu testen. Aus der ISO erstelle ich mit Convert-WindowsImage (GitHub - x0nn/Convert-WindowsImage: Creates a Windows VM for Hyper-V from a Windows-ISO) eine VHDX woraus dann die neue VM erstellt wird. Ausgeführt wird das von einem Hyper-V Host in einer PS Session in die VM. Direkt in einer administrativen Kommandozeile in der VM funktioniert es allerdings auch nicht. Ich muss tatsächlich einmal auf "Check for updates" klicken oder warten bis der Server automatisch die Suche angestoßen hat und ich in der GUI auf "Install" klicken kann. Das Script oben, PSWindowsUpdate, ABC Update suchen, laden und installieren zwar die Updates, hilft aber auch nicht für die "Install-Language".

Danke für die Antwort. Das Script hilft hier leider nicht. Ich habe gerade testweise das PowerShell Modul installiert und mir die Konfiguration vor dem Klick auf "Check for updates" angesehen und danach: # Vorher: ServiceID IsManaged IsDefault Name --------- --------- --------- ---- 8b24b027-1dee-babb-9a95-3517dfb9c552 False False DCat Flighting Prod 855e8a7c-ecb4-4ca3-b045-1dfa50104289 False False Windows Store (DCat Prod) 9482f4b4-e343-43b6-b170-9a65bc822c77 False True Windows Update #Nachher: ServiceID IsManaged IsDefault Name --------- --------- --------- ---- 7971f918-a847-4430-9279-4a52d1efe18d False True Microsoft Update 8b24b027-1dee-babb-9a95-3517dfb9c552 False False DCat Flighting Prod 855e8a7c-ecb4-4ca3-b045-1dfa50104289 False False Windows Store (DCat Prod) 9482f4b4-e343-43b6-b170-9a65bc822c77 False False Windows Update Clever wie ich bin, habe ich vorher natürlich keinen Snapshot gemacht und werde die VM dann mal neu deployen..

Hi, zu 1) Das könnte auch ein Thema für eine Cyberversicherung sein. Gruß Jan

Nein. Viel Erfolg.

Hi, du hast den Lösungsansatz doch schon selber gefunden: boote den RDSH "notfalls" jede Nacht durch. Gruß Jan

Hi, hat jemand eine Idee, wie ich per Script eine Windows Update Suche starten kann? Mit "wuauclt" und "UsoClient" funktioniert es leider nicht. Klicke ich händisch auf "Updates suchen" oder warte ab, bis WU von alleine getriggert hat, funktioniert das CMDlet direkt. Hintergrund ist, dass ohne vorherige Suche(?) das CMDlet Install-Language die Sprache anscheinend nicht laden kann. Auf das PowerShell Modul "PSWindowsUpdate" würde ich - wenn möglich - gerne verzichten. Danke und Gruß Jan

Was mich hier generell daran verwirrt: Hyper-V so grob aus 2008 Pre-Windows 2000 Compatible Access Aber auch damit werde ich leben können. ;)

Ja, mit den o.g. Ausnahmen läuft er. ;) "Kerberos only" konnte der Cluster nach einem Shutdown nur per Powershell gestartet werden. Die Failover Cluster MMC scheint noch etwas an NTLM zu hängen, würde mich aber auch nicht wundern. Auf meiner Agenda steht derzeit noch ein Test, wie sich alles mit dem Windows Admin Center verhält. Beide Clusterknoten haben auch problemlos das In-Place Upgrade über Windows Update mitgemacht. BTW.: Auf frisch installierten Systemen mit der Build 26063 ist Copilot überall "aktiv".