The agenda for our M.A.D. Day is finally available, including a description. Here you can find all necessary information.
Buch
- App-V Infrastruktur
- App-V Client
- App-V Sequenzierung
- Tools & Troubelshooting
- PowerShell mit App-V
The agenda for our M.A.D. Day is finally available, including a description. Here you can find all necessary information.
In diesem Artikel zeige ich Ihnen, welche PowerShell-Befehle Sie benötigen, um moderne Anwendungen wie AppX und MSIX auf Windows 11 und Windows Server bereitzustellen. Wir sprechen in diesem Zusammenhang von Modern-Applications, die isoliert, also virtuell, mit eigenem Dateisystem und eigener Registrierung unter Windows arbeiten.
In diesem Blog möchten wir den aktuellen Stand der MSIX-Kompatibilität beleuchten und eine Einschätzung geben, ob MSIX ein guter Ersatz für App-V ist. Dabei ist zu betonen, dass MSIX absolut lizenzfrei genutzt werden kann. Es ist in jeder Windows Edition enthalten und funktioniert auch in der Home Edition. MSIX ist für Remote Desktop Services Umgebungen und VDI auch für kleine und mittlere Umgebungen sehr interessant. Mit einfachen Mitteln können die Systemabbilder klein gehalten werden und die Anwendungen werden ressourcenschonend just-in-time den Benutzern bei der Anmeldung zur Verfügung gestellt.
Vor einigen Wochen hat mich ein Kunde angeschrieben, dass App-V nun doch 2026 aus dem Support gehen soll. 2026? Woher kommt das neue Datum? Es gab das Problem, dass viele gedacht haben, App-V gehe 2025 aus dem Support, weil für diesen Zeitpunkt das Microsoft Desktop Optimization Pack (MDOP) abgekündigt war. Im MDOP ist u.a. die App-V Infrastruktur zur Verteilung von App-V Paketen an Endgeräte enthalten. Aber der App-V Client selbst wurde ab Windows 10 1607 in das Betriebssystem integriert (damals auch in Windows Server 2016). App-V Pakete können auch mit anderen Mitteln (PowerShell) oder einer anderen Deployment-Methode wie dem Endpoint Configuration Manager verteilt werden. Also nichts, worüber wir uns Sorgen machen müssen.
In den Anfangstagen von PowerShell meinten wir mit PowerShell Cmdlets immer die PowerShell Funktionen, die mit einer DLL importiert werden. Zu diesem Zeitpunkt war das quasi der Standard. Das hat sich heute erheblich geändert. In den seltensten Fällen sehe ich heute Module, die als DLL erstellt wurden. Nun wollte ich gerade einige hardwarenahe Funktionen in PowerShell nutzen, die in der Kernal32 DLL hinterlegt sind. Natürlich kann man das auch alles direkt in PowerShell integrieren aber leider ist mein Antivirus bei einigen Ausdrücken mit einmal recht aggressiv geworden. Klar, als C++ Programm sind hardwarenahen Geschichten ok nur wurden diese Funktionen scheinbar in letzter Zeit in PowerShell für böse Dinge genutzt. Daher habe ich mich entschlossen, alles in eine C# DLL zu verpacken. Dieser Blog beschriebt nun, wie man so etwas macht. Also ein PowerShell Modul als C# DLL.