Eine solide Strategie zur Anwendungspaketierung beginnt lange bevor die Software die Endnutzer erreicht. Eine Anwendung kann sich in einem kurzen Test problemlos installieren lassen und dennoch in einer unternehmensweiten IT-Landschaft Probleme verursachen. Sie kann Aufforderungen anzeigen, einen unerwarteten Neustart auslösen, sich nicht ordnungsgemäß deinstallieren lassen oder beim nächsten Update fehlschlagen. Solche Probleme treten häufig erst auf, nachdem die Bereitstellung bereits als erfolgreich eingestuft wurde.

Deshalb sollte eine Strategie zur Anwendungspaketierung mehr als nur die Erstinstallation abdecken. Sie muss Konfiguration, Erkennung, Upgrades, Deinstallation, Sicherheit und Benutzererfahrung berücksichtigen. Der gewählte Ansatz muss außerdem überschaubar bleiben, wenn der Hersteller eine neue Version veröffentlicht.

In den meisten Fällen ist das Hersteller-Installationsprogramm der beste Ausgangspunkt. Ein Wrapper hilft, wenn die Bereitstellung zusätzliche Kontrolle rund um ein funktionsfähiges Installationsprogramm erfordert. Eine Neu-Paketierung ist sinnvoll, wenn das ursprüngliche Setup die Unternehmensanforderungen mit den unterstützten Optionen nicht erfüllen kann.

Warum die Paketierungsmethode wichtig ist

Hersteller-Installationsprogramme, Wrapper und neu paketierte Anwendungen können alle zum gleichen sichtbaren Ergebnis führen: Die Software erscheint auf einem Gerät. Hinter diesem Ergebnis stehen jedoch unterschiedliche Verantwortlichkeiten.

Das Original-Installationsprogramm bewahrt das vom Hersteller vorgesehene Installationsmodell. Ein Wrapper ergänzt die Bereitstellungslogik, ohne dieses Modell zu ersetzen. Durch die Neu-Paketierung entsteht ein neues Modell, das dem Unternehmen mehr Kontrolle, aber auch mehr Verantwortung überträgt.

Dieser Unterschied wird bei Upgrades und Supportfällen wichtig. Ein Hersteller-Updater erkennt ein aufgezeichnetes Paket möglicherweise nicht. Ein komplexer Wrapper muss eventuell angepasst werden, sobald sich der Setup-Prozess ändert. Die schnellste Option für eine einzelne Bereitstellung ist über einen Zeitraum von zwei Jahren nicht immer die einfachste.

Wann das Hersteller-Installationsprogramm die beste Wahl ist

Moderne Installationsprogramme für Unternehmen bieten häufig mehr Kontrolle, als Teams zunächst erwarten. Hersteller stellen möglicherweise Silent-Befehle, MSI-Eigenschaften, Konfigurationsdateien, Richtlinienvorlagen oder spezielle Bereitstellungstools bereit. Diese Optionen ermöglichen eine kontrollierte Einführung, ohne das Originalpaket zu verändern.

Microsoft 365 verwendet beispielsweise das Office Deployment Tool und eine XML-Konfiguration. Auch andere große Hersteller veröffentlichen Optionen für die unternehmensweite Bereitstellung ihrer Anwendungen.

Die Verwendung der Originalquelle hält die Bereitstellung nah an dem vom Hersteller getesteten und unterstützten Verfahren. Dadurch können auch Upgrades, Reparaturen und die Fehlerbehebung besser vorhersehbar werden. Dieser Ansatz eignet sich am besten, wenn das Installationsprogramm Folgendes bietet:

• Zuverlässige Silent-Installation und -Deinstallation
• Unterstützte Konfigurationsoptionen
• Aussagekräftige Exit-Codes und konsistente Erkennungsmerkmale
• Vorhersehbares Upgrade-Verhalten
• Geeignete Kontrolle über Aufforderungen und Neustarts

Die Standardeinstellungen des Herstellers müssen nicht unverändert bleiben. Eine MSI kann häufig öffentliche Eigenschaften oder eine MST-Transformation verarbeiten. Die Transformation ändert ausgewählte Einstellungen, während die zugrunde liegende MSI erhalten bleibt. Microsoft erläutert dieses Modell in seinen Hinweisen zu Windows Installer-Transformationen.

Für viele Anwendungen bietet dies die beste Balance. Das Unternehmen erhält die benötigte Konfiguration, ohne die Verantwortung für ein vollständig neues Installationsmodell zu übernehmen.

Wenn ein Wrapper die fehlende Kontrolle ergänzt

Im Rahmen einer Strategie zur Anwendungspaketierung eignet sich ein Wrapper, wenn das Installationsprogramm selbst funktioniert, die Bereitstellung jedoch mehr Kontrolle erfordert. Eine Anwendung benötigt möglicherweise eine Voraussetzung. Ein laufender Prozess muss eventuell beendet werden. Mitarbeitende brauchen unter Umständen auch Zeit, um ihre Arbeit zu speichern.

Ein Wrapper steuert diese Bedingungen rund um das Original-Installationsprogramm. PowerShell und Frameworks wie das PSAppDeployToolkit können die Installation koordinieren, während die Herstellerquelle unverändert bleibt.

Stellen Sie sich ein Update vor, das bei geöffneter Anwendung nicht fortgesetzt werden kann. Wird sie sofort geschlossen, könnte die Arbeit eines Mitarbeitenden unterbrochen werden. Bleibt sie geöffnet, kann die Bereitstellung fehlschlagen. Ein Wrapper kann eine Meldung anzeigen, eine kontrollierte Verschiebung ermöglichen, den Prozess später schließen und das Ergebnis protokollieren.

Wrapper können außerdem Voraussetzungen, Konfigurationsdateien, Neustartverhalten, Protokollierung und Prüfungen nach der Installation steuern. Sie eignen sich besonders, wenn die Herausforderung in der Orchestrierung der Bereitstellung und nicht im Installationsprogramm selbst liegt.

Zusätzliche Kontrolle bedeutet allerdings auch zusätzlichen Wartungsaufwand. Die Wrapper-Logik muss jede neue Herstellerversion berücksichtigen. Unnötige Skripte können eine einfache Bereitstellung in eine individuelle Lösung verwandeln, die nur wenige verstehen.

Wann Neu-Paketierung die bessere Option ist

Nicht jedes Installationsprogramm bietet einen zuverlässigen Weg für den Unternehmenseinsatz. Ältere Setups erfordern möglicherweise manuelle Eingaben, verfügen über keinen Silent-Modus oder bieten keine verlässliche Deinstallationsmethode. In solchen Fällen kann ein Wrapper die zugrunde liegenden Einschränkungen lediglich verdecken.

Bei der Neu-Paketierung wird die Installation aufgezeichnet oder in ein neues Format wie MSI oder MSIX konvertiert. Wenn die Originalquelle nicht ausreicht, kann dies eine konsistentere Bereitstellung ermöglichen. Typische Kandidaten sind Legacy-Software, interaktive Installationen und Anwendungen mit nicht unterstützten manuellen Schritten.

Mehr Kontrolle verändert auch das Verantwortungsmodell. Upgrades, Reparaturfunktionen, Lizenzierungskomponenten oder Deinstallationsprogramme des Herstellers erkennen die neu paketierte Anwendung möglicherweise nicht. Einige Hersteller können Änderungen außerdem einschränken oder den Support für veränderte Bereitstellungen ablehnen.

Auch saubere Aufzeichnungsbedingungen sind wichtig. Hintergrundprozesse können irrelevante Änderungen in ein Paket einbringen. Vorhandene MSI-Installationsprogramme sollten nur selten neu aufgezeichnet werden, wenn dokumentierte Eigenschaften oder eine Transformation die erforderliche Konfiguration bereitstellen können.

Neu-Paketierung bietet den größten Mehrwert, wenn sie ein echtes Bereitstellungshindernis beseitigt. Die Präferenz für ein bestimmtes Dateiformat allein ist kein ausreichender Grund.

Ist die Konvertierung einer Anwendung in MSIX immer ein Upgrade?

MSIX kann Paketidentität, Integritätsprüfungen, eine sauberere Deinstallation und moderne Verwaltungsoptionen bieten. Ob die Konvertierung diese Vorteile tatsächlich liefert, hängt jedoch von der Kompatibilität ab.

Treiber werden nicht unterstützt, für Dienste gelten zusätzliche Anforderungen und Paketdateien sind schreibgeschützt. Die Umleitung von Dateisystem und Registrierung kann sich ebenfalls auf ältere Anwendungen auswirken. Konvertierte Pakete benötigen vertrauenswürdige Zertifikate und müssen gründlich getestet werden.

Die drei Ansätze im Vergleich

Die richtige Wahl wird meist deutlicher, wenn Teams die Auswirkungen auf den gesamten Lebenszyklus vergleichen und nicht nur die Ausgabeformate.

Dieser Vergleich klärt auch ein häufiges Missverständnis: Durch das Erstellen einer .intunewin-Datei wird eine Anwendung nicht neu paketiert. Das Content Prep Tool von Microsoft legt ein Installationsprogramm oder Skript in einem Intune-Bereitstellungscontainer ab. Der darin enthaltene Inhalt steuert weiterhin die Installation.

Ebenso entsteht normalerweise ein Wrapper, wenn ein Installationsprogramm in PowerShell oder das PSAppDeployToolkit eingebunden wird. Das ursprüngliche Installationsmodell wird dadurch nicht ersetzt. Diese Unterscheidungen helfen Teams zu erkennen, welche Komponente einen Fehler verursacht hat und welche gewartet werden muss.ines Installationsprogramms in PowerShell oder das PSAppDeployToolkit in der Regel ein Wrapper erstellt. Das ursprüngliche Installationsmodell wird dadurch nicht ersetzt. Anhand dieser Unterscheidungen können Teams feststellen, welche Komponente einen Fehler verursacht hat und welche gewartet werden muss.

Eine Strategie zur Anwendungspaketierung am Lebenszyklus ausrichten

Keine einzelne Methode eignet sich für jede Anwendung in einer heterogenen IT-Landschaft. Ein Dienstprogramm mit einer gut dokumentierten MSI benötigt möglicherweise nur wenige unterstützte Eigenschaften. Eine geschäftskritische Anwendung kann einen Wrapper erfordern, um Benutzer während Upgrades zu schützen. Bei einem Legacy-Setup kann eine vollständige Neu-Paketierung gerechtfertigt sein.

Die richtige Option wird klarer, wenn die Diskussion über das Format hinausgeht. Kann die Quelle im erforderlichen Kontext im Silent-Modus installiert werden? Wird die richtige Konfiguration angewendet? Wie erkennt die Plattform eine erfolgreiche Installation und Deinstallation? Was geschieht, wenn die Anwendung geöffnet ist? Werden zukünftige Updates die bereitgestellte Version erkennen?

Ebenso wichtig ist die Zuständigkeit für Updates. Hersteller, Verwaltungsplattform und Patching-Dienst sollten nicht gleichzeitig versuchen, dieselbe Anwendung zu aktualisieren. Klare Zuständigkeiten verhindern widersprüchliche Änderungen und uneinheitliche Versionen in der gesamten IT-Landschaft.

Die Tests sollten diese umfassendere Perspektive widerspiegeln. Eine Neuinstallation ist nur ein Szenario. Upgrades, Deinstallationen, Neuinstallationen, Neustarts, Rollbacks und der Umgang mit Benutzerdaten können die endgültige Entscheidung beeinflussen.

Mit Apptimized einen einheitlichen Prozess schaffen

Bei manchen Anwendungen ist die Entscheidung einfach, bei anderen deutlich weniger offensichtlich. Große Anwendungslandschaften bringen eine weitere Herausforderung mit sich: Teams müssen über Hunderte von Anwendungen hinweg konsistente Entscheidungen treffen, ohne jede Anwendung demselben Prozess zu unterwerfen.

Apptimized unterstützt Unternehmen dabei, Anwendungsquellen zu bewerten, eine geeignete Paketierungsmethode auszuwählen und bereitstellungsfertige Anwendungen vorzubereiten. Paketierung, Tests, Dokumentation und laufende Wartung können gemeinsamen Standards folgen und zugleich das Verhalten der jeweiligen Anwendung berücksichtigen.

So erhalten interne Teams vorhersehbarere Ergebnisse und klarere Zuständigkeiten über den gesamten Lebenszyklus hinweg. Gleichzeitig wird unnötige individuelle Paketierung vermieden, wenn die vom Hersteller unterstützten Optionen besser geeignet sind.

Fazit

Eine wirksame Strategie zur Anwendungspaketierung beginnt nicht mit einem bevorzugten Dateiformat. Sie beginnt mit der Anwendung, der Bereitstellungsumgebung und der Frage, wie sich die Software im Laufe der Zeit verhalten muss.

Das Hersteller-Installationsprogramm ist in der Regel die beste Wahl, wenn es die Unternehmensanforderungen erfüllt. Ein Wrapper ergänzt die Kontrolle, wenn die Bereitstellung mehr Koordination erfordert. Eine Neu-Paketierung ist gerechtfertigt, wenn das ursprüngliche Setup weiterhin ein Hindernis darstellt und ein neues Installationsmodell einen klaren Mehrwert bietet.

Wer über die erste erfolgreiche Installation hinausblickt, reduziert vermeidbaren Wartungsaufwand, bewahrt nach Möglichkeit den Herstellersupport und sorgt für zuverlässigere Benutzererfahrungen.

Benötigen Sie einen einheitlichen Ansatz, um Unternehmensanwendungen zu bewerten, vorzubereiten, zu testen und zu warten? Vereinbaren Sie eine Demo mit unserem Spezialisten und erfahren Sie, wie Apptimized Ihren Anwendungslebenszyklus optimieren kann.

Author

Maryna Semesenko

ARM64 im Unternehmen: Gemischte Gerätelandschaften statt vollständiger Ablösung

Die Endpoint-Landschaft in Unternehmen ist architektonisch nicht mehr einheitlich. Jahrzehntelang war der x86/x64-Befehlssatz der unangefochtene Standard für Desktop-PCs, Laptops und Server. Heute haben ARM-basierte Prozessoren den Bereich mobiler Geräte verlassen und sind in gängiger Business-Hardware angekommen – vor allem durch Apples Chips der M-Serie und die Qualcomm-Snapdragon-X-Familie.

Es liegt nahe, dies als „Übernahme durch ARM“ darzustellen. Die Auslieferungszahlen stützen diese Aussage jedoch nicht, und für den IT-Betrieb ist sie ohnehin nicht die entscheidende Frage. ARM-basierte Clients machten im ersten Quartal 2026 rund 14 Prozent der PC-Auslieferungen aus; darin sind Chromebooks und Macs bereits enthalten. Zudem bezieht sich dieser Anteil auf neu ausgelieferte Geräte und nicht auf den installierten Bestand: Die bereits in großen Unternehmen eingesetzte x64-Flotte wird nicht innerhalb von ein oder zwei Beschaffungszyklen verschwinden.

Das realistische Szenario – und dasjenige mit konkreten Folgen für die Anwendungspaketierung – sieht so aus: Unternehmen werden über Jahre hinweg gemischte x86-/ARM-Umgebungen betreiben. Mit jeder Hardwareerneuerung kommen ARM64-Geräte zu einer Umgebung hinzu, die weiterhin Tausende x64-Endpoints umfasst. Beide Geräteklassen müssen gleichzeitig aus demselben Anwendungskatalog und nach denselben Qualitätsstandards versorgt werden. Genau dadurch wird die Paketierung für ARM von einer Nischenaufgabe zu einer dauerhaften operativen Disziplin.

ARM vs. x86: Warum die Architektur für die Paketierung entscheidend ist

Für x86 kompilierte Software kann nicht direkt auf einem ARM-Prozessor ausgeführt werden – und umgekehrt. Diese binäre Inkompatibilität ist die technische Grundlage des gesamten Problems: Eine Anwendungslandschaft migriert nicht automatisch, nur weil sich die darunterliegende Hardware ändert. Um diese Lücke zu schließen, stellen beide Plattformanbieter Übersetzungsschichten bereit.

• Rosetta 2 (macOS): Übersetzt x86_64-Code in ARM64-Code, damit die meisten Mac-Anwendungen aus der Intel-Ära weiterhin auf Apple Silicon ausgeführt werden können. Die Übersetzung erfolgt bei der Installation oder beim ersten Start; dynamisch erzeugter Code wird zur Laufzeit Just-in-Time übersetzt.
• Prism (Windows on ARM): Microsofts Emulationsschicht, die mit Windows 11, Version 24H2, eingeführt wurde. Sie führt vorhandene x64- und x86-Anwendungen auf ARM64-Hardware aus. Das Ende 2025 veröffentlichte Prism-Update erweiterte die Übersetzung um die Befehlssätze AVX, AVX2, BMI, FMA und F16C. Dadurch vergrößert sich die Zahl der Anwendungen deutlich, die unter Emulation akzeptabel funktionieren. Diese Erweiterungen stehen nur 64-Bit-x86-Anwendungen zur Verfügung: 32-Bit-Anwendungen sowie x64-Anwendungen, die zur Erkennung von CPU-Funktionen einen 32-Bit-Hilfsprozess verwenden, können sie nicht nutzen. Windows 10 on ARM unterstützt dagegen nur die x86-Emulation.

Emulation ist wirkungsvoll, aber nicht kostenlos. Sie geht zulasten von Leistung und Akkulaufzeit, und Anwendungen mit Hardwareabhängigkeiten oder tiefer Systemintegration können weiterhin fehlerhaft funktionieren. Für geschäftskritische Software bleibt die native ARM64-Paketierung der zuverlässigste Weg zu vorhersehbarer Leistung und Stabilität.

Arm64EC: Nativer ARM64- und x64-Code in einer Binärdatei

Für die Neu-Paketierung bestehender Windows-Anwendungen ist Arm64EC („Emulation Compatible“) das wichtigste Konzept – und zugleich dasjenige, das in Diskussionen über ARM-Migrationen am häufigsten fehlt. Arm64EC ist eine binäre Anwendungsschnittstelle (Application Binary Interface, ABI), über die nativer ARM64-Code und emulierter x64-Code gemeinsam innerhalb desselben Prozesses ausgeführt werden können.

In der Praxis bedeutet das, dass eine Anwendung nicht „vollständig ARM64 oder gar nicht“ sein muss. Die Hauptanwendung kann nativ ausgeführt werden, während ein x64-Add-in, Plug-in oder eine Drittanbieterkomponente ohne ARM64-Build im selben Prozess weiterhin unter Emulation läuft. Anwendungen lassen sich dadurch schrittweise und Modul für Modul auf ARM umstellen, anstatt zu warten, bis jede Abhängigkeit neu erstellt wurde. Für Paketierungsteams kommt bei der Bewertung jedes Hersteller-Builds außerdem eine weitere Frage hinzu: Handelt es sich um eine reine ARM64-Binärdatei, um Arm64EC oder weiterhin um x64?

Technische Herausforderungen bei der Paketierung für ARM

Die Migration eines Anwendungsportfolios auf eine neue Architektur ist erheblich komplexer als die bloße Neukompilierung von Code. Die zentrale Schwierigkeit besteht im Wechsel von einer homogenen x64-Umgebung zu einer heterogenen Umgebung, in der jedes Paket die richtige Architektur erreichen muss, ohne die Benutzererfahrung zu beeinträchtigen.

Zu den wichtigsten Herausforderungen gehören:

• Ermittlung von Abhängigkeiten: Viele Anwendungen sind auf ein Geflecht aus externen Laufzeitumgebungen, Bibliotheken und Middleware angewiesen. Die Hauptanwendung kann durchaus ARM-kompatibel sein, während bereits eine einzige veraltete x86-Abhängigkeit das gesamte Paket zum Scheitern bringt.
• Installer-Management: Es muss entschieden werden, ob separate ARM64- und x64-Installer oder ein einziges universelles Paket mit Code für beide Architekturen erstellt werden. Jeder Ansatz wirkt sich auf Paketgröße, Bereitstellungslogik und Wartungsaufwand aus.
• Umfassende Tests: ARM erhöht den Testaufwand nicht nur – es vervielfacht ihn. Grundsätzlich benötigt nun jede Anwendung drei Validierungsdurchläufe statt eines einzigen: nativ unter ARM64 auf ARM-Hardware, dieselbe Anwendung unter Emulation auf ARM sowie der unveränderte x64-Build auf älterer Hardware. Das verdreifacht das QA-Volumen für jede Anwendung und jede Version – und genau hier wird die Paketierungskapazität, nicht das Paketierungswissen, zum Engpass.

Hürden bei Abhängigkeiten und Middleware

Der häufigste Fehlerpunkt bei einer ARM-Migration ist nicht die ausführbare Hauptdatei, sondern ihre Abhängigkeiten. Veraltete Komponenten, die tief in einem Installer verborgen sind, bringen den Prozess zum Stillstand.

• Inkompatible Laufzeitumgebungen: Für ältere Versionen von Frameworks wie .NET, der Java Virtual Machine (JVM) und den Microsoft Visual C++ Redistributables gibt es möglicherweise kein natives ARM64-Pendant. Im Paketierungsprozess müssen diese Komponenten identifiziert und auf ARM-kompatible Versionen aktualisiert werden.
• Veraltete 32-Bit-Komponenten (x86): Windows on ARM kann 32-Bit-x86-Code weiterhin emulieren, Apple hat die Unterstützung für 32-Bit-Anwendungen jedoch mit macOS Catalina vollständig eingestellt. Jedes Paket für Apple Silicon, das 32-Bit-Binärdateien enthält, kann nicht ausgeführt werden; die betroffene Komponente muss aktualisiert oder ersetzt werden.
• Drittanbieterbibliotheken: Anwendungen binden regelmäßig Open-Source- oder kommerzielle Bibliotheken ein. Das Paketierungsteam muss prüfen, ob für jede davon eine ARM64-Version verfügbar ist, und den Build-Prozess entsprechend anpassen.

Hinweise zu Installer-Formaten: MSIX, Win32 (.intunewin) und PKG

Die Wahl des Installer-Formats bestimmt, wie reibungslos eine Anwendung in einer Umgebung mit mehreren Architekturen bereitgestellt werden kann.

• MSIX für Windows on ARM: MSIX ist Microsofts modernes Paketierungsformat für Windows-Anwendungen, einschließlich ARM. Ein Bundle kann Pakete für mehrere Architekturen (x86, x64, ARM64) enthalten; das System installiert nur das Paket, das das Zielgerät tatsächlich benötigt. Dadurch bleibt die Bereitstellungslogik einfach.
• Paketierung für macOS: Für Apple Silicon arbeiten IT-Teams hauptsächlich mit zwei Formaten. Einfache Drag-and-drop-Anwendungen werden als .app-Bundles ausgeliefert, während Software mit Skripten und definierten Installationspfaden .pkg-Installer verwendet. Eine Universal-Binärdatei, die sowohl den Intel- als auch den Apple-Silicon-Build in einem Paket enthält, bleibt die bevorzugte Lösung für eine nahtlose Bereitstellung.

Hinweis zur Terminologie: .intunewin ist eine Dateiendung und kein Bereitstellungstyp. Der entsprechende Intune-Bereitstellungstyp ist die Win32-App. Deshalb wird in diesem Leitfaden durchgehend die Bezeichnung Win32 (.intunewin) verwendet. Unabhängig vom Format gilt ein Grundsatz: Die Bereitstellung muss sicherstellen, dass jedes Gerät das für seine Architektur erstellte Paket erhält. Wie dies umgesetzt wird, hängt von der Managementplattform ab und sollte anhand ihres aktuellen Verhaltens überprüft und nicht einfach vorausgesetzt werden.

Die Neu-Paketierung für ARM ist ein wiederkehrender Zyklus und kein einmaliges Projekt

Der am meisten unterschätzte Aspekt einer ARM-Migration ist, dass sie nie wirklich endet. Die erstmalige Umstellung einer Anwendung ist ein einmaliges Ereignis; sie dauerhaft funktionsfähig zu halten, ist eine fortlaufende Aufgabe. Jedes Herstellerupdate für eine ARM64-Anwendung löst denselben Arbeitsablauf erneut aus: neue Quelldateien beschaffen, das Paket neu erstellen oder konfigurieren, es auf allen relevanten Zielsystemen validieren und erneut bereitstellen. Multipliziert man dies mit der Größe des Katalogs und der Anzahl der Releases pro Jahr, zeigt sich: Der eigentliche Aufwand liegt im wiederkehrenden Zyklus, nicht in der ersten Migration.

Genau deshalb gibt es das Packaging-Factory-Modell – und ARM macht es relevanter, nicht weniger relevant:

• Kontinuierliches Update-Management: Wenn Hersteller neue Versionen und Sicherheitspatches veröffentlichen, müssen ARM-Pakete im gleichen Rhythmus wie ihre x64-Pendants neu erstellt und erneut validiert werden, damit das Portfolio sicher und kompatibel bleibt.
• Proaktive Kompatibilitätsüberwachung: Plattformänderungen in Windows und macOS – etwa ein neues Emulationsverhalten oder geänderte Anforderungen an Signierung und Installer – können Pakete unbrauchbar machen, die gestern noch funktioniert haben. Diese Änderungen zu verfolgen und Pakete anzupassen, bevor Benutzer Probleme bemerken, ist eine fortlaufende Aufgabe.
• Integriertes Patch-Management: Bei Drittanbieteranwendungen sollten ARM-Pakete in denselben Patch-Prozess wie alle anderen Pakete einfließen, damit die Architektur niemals der Grund dafür ist, dass ein Endpoint bei Updates zurückbleibt.

Strategischer Rahmen für die Migration von Anwendungen auf ARM

Ein praktikabler ARM-Ansatz erfordert keine neue Methodik; die bestehende Methodik muss lediglich architekturbewusst werden. Im Inventar sollten nicht nur Name und Version jeder Anwendung, sondern auch ihre Architektur und Abhängigkeiten erfasst werden. Die Priorisierung sollte sich am Hardware-Rollout orientieren: Zuerst kommen die Anwendungen, die von den Gruppen genutzt werden, die tatsächlich ARM-Geräte erhalten – nicht die größten Anwendungen im Katalog. Die Paketierung muss standardisiert sein, damit ARM64- und x64-Builds derselben Anwendung synchron bleiben. Und die Validierung muss alle relevanten Zielsysteme abdecken, denn „es wurde installiert“ hat auf ARM nicht dieselbe Aussagekraft wie auf x64.

Erfassung und Bewertung der Anwendungslandschaft

Was nicht sichtbar ist, kann auch nicht verwaltet werden. Der erste Schritt ist eine detaillierte Bestandsaufnahme aller eingesetzten Anwendungen – nicht nur eine Namensliste, sondern eine Analyse der zugrunde liegenden Architektur und Abhängigkeiten jeder Anwendung.

• Automatisiertes Scanning: Eine manuelle Bewertung ist für eine große Anwendungslandschaft unrealistisch. Durch die automatisierte Analyse von Installern und Binärdateien werden architektonische Abhängigkeiten, veraltete 32-Bit-Komponenten und wahrscheinliche Kompatibilitätsrisiken sichtbar.
• Anwendungskategorisierung: Jede Anwendung sollte einer von vier Kategorien zugeordnet werden:
  • Natives ARM64: Der Hersteller stellt bereits einen nativen ARM-Build bereit.
  • Emulationskompatibel: Die Anwendung ist für x64 ausgelegt, läuft aber zuverlässig unter Rosetta 2 oder Prism.
  • Neu-Paketierung erforderlich: Die Anwendung ist geschäftskritisch und benötigt ein natives ARM64-Paket.
  • Ersetzung erforderlich: Die Anwendung ist inkompatibel und muss durch eine ARM-native oder SaaS-Alternative ersetzt werden.

Diese Einteilung in vier Kategorien macht die weitere Migration planbar: Sie verwandelt eine undifferenzierte Anwendungsliste in einen Arbeitsvorrat mit bekanntem Umfang.

Der Paketierungsworkflow für ARM64

Nach der Bewertung und Priorisierung der Anwendungen sorgt ein standardisierter Workflow für planbare Qualität und einen vorhersehbaren Aufwand.

1. Beschaffung der Quelldateien: Beschaffen Sie die neuesten stabilen Installationsmedien und prüfen Sie zunächst, ob der Hersteller bereits einen ARM64- oder Arm64EC-Build anbietet. Richten Sie saubere Paketierungsumgebungen für ARM64 und x64 ein, damit die Ergebnisse nicht durch andere Software beeinflusst werden.
2. Konfiguration und Neu-Paketierung: Wenn kein universeller Installer verfügbar ist, erstellen Sie ein eigenes ARM64-Paket mit ARM-nativen Abhängigkeiten und Laufzeitumgebungen. Bei MSIX bedeutet dies, die ARM64-Binärdateien einzubinden und das Paketmanifest entsprechend zu aktualisieren.
3. Automatisierte Tests: Führen Sie vor allen Benutzertests skriptbasierte Smoke-Tests für Installation, Start und Kernfunktionen aus. So werden offensichtliche Fehler frühzeitig und nicht erst im produktiven Einsatz erkannt.
4. Gezielte Bereitstellung: Stellen Sie die Pakete über die vorhandene Managementplattform bereit und sorgen Sie dafür, dass ARM64-Pakete ARM64-Geräte erreichen, während x64-Pakete weiterhin ältere Hardware versorgen. Der Mechanismus unterscheidet sich je nach Plattform und Version; die Anforderung bleibt gleich.

ARM-Paketierung mit Apptimized

Der Aufbau eigener Kapazitäten für die ARM-Paketierung ist genau in den Ressourcen kostspielig, die den meisten IT-Abteilungen fehlen: Fachwissen, Testhardware und Zeit. Apptimized begegnet diesem Problem mit einem Managed Service für die ARM64-Softwarepaketierung, der den gesamten Workflow übernimmt – von der Quellenanalyse und Neu-Paketierung bis zur dokumentierten, bereitstellungsfertigen Ausgabe.

Statt Abhängigkeitskonflikte und parallele Build-Umgebungen intern aufzufangen, können Unternehmen über ein Packaging-Factory-Modell ARM64-Pakete bei Bedarf beziehen. Das reduziert den manuellen Aufwand und hält Migrationsprogramme wie einen Windows-11-Rollout im Zeitplan.

Komplexität an eine dedizierte Packaging Factory auslagern

• Zugang zu erfahrenen Paketierungsingenieuren: Experten, die regelmäßig an ARM-Migrationen arbeiten – von der Lösung von Abhängigkeitskonflikten bis zur Strukturierung von Universal-Binärdateien für macOS und Multi-Architektur-MSIX-Paketen für Windows.
• Planbare Qualität und SLAs: Pakete werden nach definierten Qualitätsstandards und vereinbarten Service Levels bereitgestellt. Dadurch lässt sich der Output für die Bereitstellungspipeline zuverlässig planen.
• Standardisierte Ergebnisse für Intune und SCCM: Die Pakete werden für das eingesetzte Endpoint-Management-System vorbereitet und dokumentiert, einschließlich der Skripte und Erkennungslogik, die für eine unbeaufsichtigte Bereitstellung erforderlich sind.
• Kapazität passend zum Refresh-Zyklus: Der Paketierungsbedarf ist nicht konstant. Er erreicht Spitzen bei Hardware-Rollouts und Release-Wellen der Hersteller. In diesen Phasen übernimmt eine externe Factory die zusätzliche Last, für die ein internes Team sonst dauerhaft Personal vorhalten müsste.

Häufig gestellte Fragen

Können ARM-basierte Windows-Geräte herkömmliche 64-Bit-Software (x64) ausführen?

Ja. Windows 11 on ARM enthält die Prism-Emulationsschicht, über die die meisten x64- und x86-Anwendungen ausgeführt werden können. Windows 10 on ARM unterstützt nur die x86-Emulation. In beiden Fällen bieten nativ für ARM64 paketierte Anwendungen eine bessere Leistung und Kompatibilität.

Worin unterscheidet sich die native ARM64-Paketierung von der Emulation?

Bei der nativen ARM64-Paketierung wird der Anwendungscode für den ARM-Befehlssatz kompiliert und direkt auf dem Prozessor ausgeführt. Bei der Emulation wandelt eine Übersetzungsschicht (Prism oder Rosetta 2) x64-Anweisungen zur Laufzeit in ARM64-Anweisungen um. Das kostet Leistung und kann bei komplexer Software zu Kompatibilitätsproblemen führen.

Benötige ich unterschiedliche Pakete für Intel-basierte Macs und Macs mit Apple Silicon?

Im Idealfall nicht. Für macOS gilt ein Universal-Paket als Best Practice. Es enthält sowohl die x86_64-Binärdatei für Intel-Macs als auch die ARM64-Binärdatei für Apple Silicon; macOS führt automatisch die passende Version aus. Ist keine Universal-Binärdatei verfügbar, sind separate Pakete erforderlich.

Wie stellt Microsoft Intune Anwendungen auf ARM-Geräten bereit?

Intune stellt Anwendungen auf ARM64-Geräten in denselben Formaten wie auf anderen Geräten bereit: Win32 (.intunewin) und MSIX. Entscheidend ist, dass jedes Gerät den zu seiner Architektur passenden Build erhält. Die verfügbaren Optionen für das ARM64-Targeting ändern sich zwischen Service-Releases. Deshalb sollte das aktuelle Verhalten im eigenen Tenant überprüft werden, statt sich auf Dokumentation zu einem älteren Stand zu verlassen.

Ist MSIX das richtige Format für die Paketierung von Windows-on-ARM-Anwendungen?

MSIX ist Microsofts modernstes und empfohlenes Format. Die Multi-Architektur-Bundles sind tatsächlich nützlich: Ein Bundle kann x86-, x64- und ARM64-Pakete enthalten, wobei nur das relevante Paket installiert wird. Im Unternehmensalltag ist Win32 (.intunewin) für ARM-Bereitstellungen jedoch weiterhin häufiger anzutreffen. Die Wahl sollte sich daher an der bestehenden Anwendungslandschaft und nicht am neuesten Format orientieren.

Wie kann ich die Konvertierung von SCCM-Paketen für ARM-basierte Intune-Geräte automatisieren?

In mehreren Schritten. Prüfen Sie zunächst, welche SCCM-Pakete realistische Kandidaten für ARM sind. Paketieren Sie die Anwendung anschließend aus ihrem ursprünglichen Format (.exe oder .msi) in ein ARM64-kompatibles MSIX- oder Win32-Paket (.intunewin) neu. Importieren Sie das Paket abschließend in Intune und konfigurieren Sie die Bereitstellung so, dass es ausschließlich ARM64-Geräte erreicht.

Author

Stefan Lang