Windowsアプリケーションパッケージング vs アプリケーション公開

紹介

Windowsアプリケーションは、アプリケーションおよびインフラストラクチャの要件に応じて、個々のエンドポイントにインストールおよび管理することも、中央でホストしてユーザーにリモートで配信することもできます。これらのモデルの選択は、技術を比較する以上のものを必要とします。この記事では、Windowsアプリケーションパッケージングの仕組み、アプリケーション公開との違い、各アプローチが適切な場合、ITチームがどのように両方を同じアプリケーション配信戦略内で組み合わせることができるかを説明します。

Windowsアプリケーションパッケージングとは何ですか？

Windowsアプリケーションパッケージングは、予測可能なインストールと管理のために必要なアプリケーションとそのファイル、構成、メタデータの準備を含みます。

すべてのターゲットシステムでアプリケーションを手動で構成するのではなく、ITチームは標準化されたパッケージを使用して、インストール、構成、更新、および削除をより一貫性のあるものにすることができます。

マイクロソフトの最新のWindowsパッケージングモデルにはMSIXが含まれており、パッケージのアイデンティティの提供、予測可能なインストールと削除、制御された更新、およびWindows機能との統合を可能にします。

従来のWin32アプリケーションは、MSIやEXEインストーラーなどの技術を活用できます。

アプリケーションパッケージングは、何をインストールする必要があるか、インストールと削除がどのように行われるべきか、ユーザーに提供される設定は何か、アップグレードがどのように行われるかを決定します。その目的は、アプリケーションの展開をターゲットのWindows環境全体で繰り返し可能で管理可能にすることです。

アプリケーションパッケージには何が含まれていますか？

アプリケーションパッケージの内容は、パッケージング技術およびアプリケーション自体に依存します。

アン MSIXパッケージ 例えば、アプリケーションのペイロードを、パッケージのアイデンティティ、依存関係、機能などの要素を定義するマニフェストと組み合わせます。ここでの重要な区別は、パッケージがアプリケーションが実行される場所を指定するのではなく、配布と展開の単位を定義することです。

従来の企業向けパッケージには、既存のインストーラーを変換またはラッピングし、構成を追加し、展開のロジックを定義し、展開前に最終パッケージを検証することも含まれます。

アプリケーションパッケージングは、単にアプリケーションファイルを別のファイルに入れること以上のものです。それは、ソフトウェアのインストールを繰り返し可能で、管理可能で、サポート可能にすることを目的としています。

Windowsアプリケーションパッケージング: どのように機能しますか?

アプリケーション、パッケージ形式、管理プラットフォームによってパッケージングワークフローは異なります。ただし、ほとんどのパッケージングワークフローは一般的に、発見、パッケージ作成、展開前のテストという3つの異なる段階に分かれています。

アプリケーションの発見と要件

既存のアプリケーションの再パッケージを実行する前に、管理者はアプリケーションのインストーラーが何を変更し、アプリケーションが実行時に何を必要とするかを理解することが重要です。

発見活動には、以下が含まれますが、これに限定されません：

• ファイルとディレクトリ
• レジストリエントリ
• Windowsサービス
• ランタイム依存関係
• 環境変数
• ファイル関連付け
• 権限
• ショートカットと設定ファイル

アプリケーションが展開される環境は、インストーラーと同じくらい重要です。開発者のワークステーションで開発およびテストされたアプリケーションは、標準ユーザー権限で実行した場合、クリーンなエンタープライズWindowsイメージ上で、または上で異なる動作をする可能性があります。 マルチユーザー Windows Server 環境 .

パッケージの作成と構成

ITチームは、そのソフトウェアと展開モデルに適したパッケージング技術を使用してアプリケーションを準備します。

Windowsアプリケーションの場合、これはMSIXパッケージを作成することを意味するかもしれません。これには、MSIまたはEXEインストーラー形式でWin32を使用している既存のソフトウェアをそのまま残すか、一部のアプリケーションをMSIXに変換することが含まれる可能性があります。パッケージングに対する異なるアプローチは、ソフトウェアが既存のインストールモデルの要素を維持しながら、パッケージのアイデンティティを提供することができます。

したがって、すべてのWindowsアプリケーションに適した単一のパッケージ形式は存在しません。アプリケーション、その環境、および管理ニーズがパッケージングアプローチを決定する必要があります。

テストと展開

パッケージは次のようにするべきです クリーンシステムでテスト済み ターゲットの生産環境を再現する。

テストプロセスには、インストール、初回起動、依存関係、更新、アプリケーションの機能、およびアンインストールの動作が含まれるべきです。管理者は、特にアプリケーションをパッケージ化する際に発生する可能性のあるファイルやレジストリのリダイレクションの場合に、権限やユーザー固有の設定が正しく処理されていることも確認する必要があります。

検証後、パッケージは組織の好みのソフトウェア配布またはエンドポイント管理プラットフォームを介して配布できます。

さて、一歩引いて微妙だが非常に重要な区別を明確にしましょう。

アプリケーションはパッケージ化され、その後展開されます。

これらの機能の分離は重要です。なぜなら、アプリケーションの公開に自然な移行ポイントを作るからです。

Windowsアプリケーションの公開とは何ですか？

Windowsアプリケーションの公開 中央集権的なWindowsインフラストラクチャにインストールされたアプリケーションを、ネットワークまたはインターネットを介して認可されたユーザーに公開するために使用されます。

アプリケーションは各ユーザーのエンドポイントで実行されるのではなく、リモートのWindowsホスト上で実行されます。この場合、ユーザーは互換性のあるクライアント、ショートカット、またはウェブブラウザを通じてリモートで実行されるアプリケーションにアクセスできます。

サーバーにインストールされたアプリケーション → ユーザーにアクセスが付与される → サーバー上でアプリケーションが実行される → ユーザーにアプリケーションインターフェースが提供される

このアプローチは異なります。各エンドポイントにビジネスアプリケーションをインストールおよび維持する代わりに、管理者はユーザーのセッションをホストするサーバー上でそれを維持する必要があります。そのため、ユーザーは中央集権的なインフラストラクチャ上でホストされているにもかかわらず、自分の作業環境にシームレスに溶け込んでいるように見えるアプリケーションにアクセスできます。

Windowsアプリケーションパッケージングとアプリケーション公開の違いは何ですか？

最も簡単な区別は次のとおりです。

アプリケーションパッケージングは、ソフトウェアがインストールおよび管理のためにどのように準備されるかを決定します。アプリケーションパブリッシングは、ユーザーが集中管理されたインフラストラクチャ上で実行されるソフトウェアにどのようにアクセスするかを決定します。

そのため、技術はアプリケーション配信の異なる段階で機能します。

質問	Windowsアプリケーションパッケージング	アプリケーション公開
主な目的	ソフトウェアを繰り返しインストールおよびメンテナンスできるように準備する	ユーザーに中央ホストされたアプリケーションへのアクセスを提供します
主なITの質問	このアプリケーションをどのようにインストールし、管理すればよいですか？	このアプリケーションにユーザーはどのようにアクセスして実行すべきですか？
アプリはどこで実行されますか？	アプリケーションを受信するシステム上で	発行またはセッションホスト上で
ユーザーエンドポイントへのローカルインストールですか？	エンドポイント展開に通常必要です	アプリケーションのインストールは通常必要ありません
更新情報	適用可能な展開目標に達する必要があります	ホスティングの公開に中央集権的に適用できます
エンドポイント要件	エンドポイントはローカルで実行されるアプリケーションをサポートする必要があります	エンドポイントは主に互換性のあるアクセス方法を必要とします
典型的な範囲	ソフトウェアライフサイクルとエンドポイント/サーバー管理	中央集権的なアプリケーション配信
一般的な使用例	管理されたPC、標準化されたソフトウェア、制御された展開	リモートユーザー、BYOD、レガシーアプリ、集中型アプリケーションアクセス

一つの条件: アプリケーションパッケージングは、該当するソフトウェアがどこで運用されるかを決定しません。

MSIX、MSI、またはその他のパッケージ形式は、ワークステーション、ラップトップ、仮想マシン、またはサーバーに展開できます。パッケージングは、ソフトウェアがどのようにインストールされ、サービスされるかを決定します。したがって、ターゲット展開は、アプリケーションがどこにインストールされるかを決定します。

アプリケーションの公開は、さらなるアーキテクチャの考慮事項を導入します。アプリケーションは集中型インフラストラクチャ上で処理され、そのインターフェースは認可されたユーザーのためにリモートエンドポイントに配信されます。

アプリケーションパッケージングと公開を一緒に使用する場合はどのようなケースですか？

はい。彼らはアプリケーション配信ライフサイクルの異なるポイントに対処しており、独立してまたは組み合わせて使用できます。

ビジネスラインのWindowsアプリケーションを持つ組織を考えてみてください。ローカルで実行する必要がある場合、それはすべての管理されたエンドポイントにパッケージ化して展開できます。

パッケージ → エンドポイントにデプロイ → アプリケーションがローカルで実行される

組織が集中管理する必要がある場合、関連するセッションホストにパッケージ化またはインストールされ、その後公開される可能性があります。

パッケージまたはインストール → 中央ホストにデプロイ → 公開 → アプリケーションが中央で実行される

この場合、アプリケーションパッケージングは必ずしも放棄されるわけではありません。これは、すべてのユーザーのデバイスではなく、集中ホストに適用されるだけであり、複数の公開サーバーでアプリケーションを一貫して保つことを簡素化できます。

アプリケーションパッケージングとアプリケーション公開は相互排他的ではありません：パッケージングはアプリケーションのインストールとメンテナンスを標準化し、公開はそのアクセス方法を決定します。アプリケーションのニーズに応じて、ITは1つの方法、別の方法、または両方を組み合わせて使用することができます。

Windowsアプリケーションパッケージングを使用する方が良い場合は？

Microsoft Windowsアプリケーションのパッケージングは、ローカル実行が有益であり、ITがアプリケーションがホストされているデバイスを効果的に管理できる場合に最も適しています。このような場合、インストールとメンテナンスの標準化を可能にし、アプリケーションの実行場所をユーザーに委ねます。

ユーザーはオフラインアクセスが必要です

ローカルにインストールされたアプリケーションは、中央リソースにアクセスできない場合でも効果的に動作することができ、これはモバイル従業員、現場作業者、その他のノマドワーカーにとってよくあることです。

パッケージングは、IT組織が管理されたエンドポイントでのインストール、構成、更新を標準化することによって、このアプローチが一貫して使用されることを保証するのに役立ちます。

アプリケーションはローカルハードウェアまたは処理に依存します

一部のアプリケーションは、エンドポイントのリソースに本質的に依存しているか統合されているため、ローカルで実行されると最も効果的に機能します。

ローカルデプロイメントは、アプリケーションとリソースの間にリモートセッションを導入することを回避し、パッケージングはローカル実行をサポートできるエンドポイントにアプリケーションをインストールおよび構成するための繰り返し可能な方法を提供します。

エンドポイントは標準化され、中央管理されています

パッケージングは、組織がすでに制御されたWindowsデバイスのセットとそれらを管理するためのエンドポイント管理プラットフォームを持っている状況でも意味があります。環境が主に同様のデバイスと同じ構成レベルのオペレーティングシステムで構成されている場合、ローカルアプリケーションの展開と管理は特に困難ではないかもしれません。

パッケージはアプリケーション管理に対する整理されたアプローチを提供し、エンドユーザーのデバイスにアプリケーションをインストールおよびサービスする作業を容易にします。このシナリオでは、中央実行を導入する必要はなく、実際にそのような措置が必要なビジネス上の理由がない限り、余分な複雑さを加えることになります。

したがって、重要な質問はアプリケーションをパッケージ化できるかどうかではなく、特定の環境と要件を考慮して、すべてのターゲットデバイスにインストール、更新、管理することが実行可能かどうかです。

アプリケーションの公開はいつより理にかなうのか？

アプリケーションの公開は、ローカルインストールが不当な運用上の複雑さや互換性の問題を引き起こす場合、より望ましいものになります。

いくつかの典型的な状況は考慮に値します。

リモートおよび分散ユーザー

リモートワーカー、支社の職員、契約者は、常に企業のPCのような適切に管理された場所やデバイスから作業するわけではありません。

アプリケーションの公開は、中央サーバー上でWindowsアプリを保持しながら許可します。 リモートアクセス 認可されたユーザーによって、したがって管理者がすべてのリモートデバイスでアプリケーション環境を複製する負担を軽減します。

BYODおよび混合エンドポイント環境

特定の組織が使用するすべての種類のデバイスで、Windowsアプリケーションが必ずしも実行されるわけではありません。

アプリケーションの公開は、実行環境をエンドユーザーから切り離します。このような方法を使用することで、個人は自分のマシン上の承認されたブラウザまたはクライアントを介して、中央でホストされたWindowsアプリにアクセスできるようになります。そうでなければ、そのアプリケーションを実行することはできません。

この戦略は、持ち込みデバイス（BYOD）および複数のエンドポイントオペレーティングシステムが存在する他の環境の両方に最適です。

レガシーWindowsアプリケーション

レガシーアプリケーション 展開の努力を複雑にする可能性があり、オペレーティングシステムの依存関係、老朽化したコンポーネント、および困難な構成制約に依存しています。

アプリケーションを集中管理することで、ITがソフトウェアを機能させる必要がある環境を減らすことができます。必ずしもアプリケーションの互換性の問題を解決するわけではありませんが、その問題を制御されたWindowsホストに制限することができ、広がりを持つエンドポイントのコレクションを避けることができます。

これは、組織が長期的な近代化計画に向けて取り組む中で、レガシーアプリケーションへのアクセスの標準化を簡素化することができます。

頻繁に更新が必要なアプリケーション

アプリケーションの頻繁な変更は、特にエンドポイントの数が増えると、ローカル展開をより困難にします。

アプリケーションの公開により、管理者は関連する中央ホストでアプリケーションを更新します。ユーザーは、すべてのエンドポイントでソフトウェアを更新する必要なく、更新されたアプリケーションにアクセスします。

このプロセスは、多くのユーザーが同じアプリケーションに依存しているが、ローカルで使用する必要がない場合に特に有利です。

ITチームはパッケージングと公開のどちらを選ぶべきか？

ITチームは技術の選択ではなく、アプリケーションの運用要件に目を向けるべきです。

ローカルインストールが簡単に維持でき、エンドポイントが厳密に管理され、ユーザーがオフラインまたはハードウェア依存の機能を必要とする場合、パッケージ化されたエンドポイント展開が最も理にかなっています。ユーザーが分散している場合、エンドポイントが異種であり、ローカルインストールが困難であるか、アプリケーションを中央で最新の状態に保つ方が簡単な場合、アプリケーションの公開はエンドポイント管理のオーバーヘッドを削減できます。

多くの企業は両方のモデルを必要とします。管理されたデスクトップユーザーはローカルに展開されたアプリケーションを利用できるかもしれませんが、契約者、テレコミューター、または管理されていないデバイスを使用している人々は、特定のビジネスソフトウェアへの中央発行されたアクセスを得るかもしれません。

ITが3つの質問を切り離すと、選択肢がはるかに明確になります。

1. アプリケーションはどのようにパッケージ化され、維持されるべきですか？
2. アプリケーションはどこに展開して実行すべきですか？
3. ユーザーはどのようにアクセスすべきですか？

パッケージング、展開、アクセスを別々の決定として見ることは、根本的に異なる2つの技術を同じソリューションであるかのように比較することを妨げます。

TSplus Remote Accessはどのように解決策となるか？

中央集権的なWindowsアプリケーション配信を望む組織は、すべてのエンドポイントに完全なアプリケーションを展開することなく利用できます。 TSplus リモートアクセス 選択したWindowsアプリケーションを公開するか、集中管理されたWindowsインフラストラクチャからフルリモートデスクトップを提供します。

管理者は、特定のユーザーまたはグループにアプリケーションを割り当て、サポートされているリモートクライアントまたはブラウザベースのHTML5接続を通じてアクセスを提供できます。これにより、リモートユーザー、BYOD環境、または中央での管理が容易なWindowsアプリケーションをサポートする組織にとって、アプリケーションの公開が選択肢となります。

結論

Windowsアプリケーションパッケージングは、ソフトウェアをインストール、構成、維持するための繰り返し可能な方法を提供し、一方でアプリケーション公開は、ユーザーに集中管理されたインフラストラクチャ上で実行されるアプリケーションへのアクセスを提供します。どちらのアプローチも本質的に他を置き換えるものではなく、両方とも同じアプリケーション配信戦略の一部を形成することができます。

適切なモデルは、アプリケーションの要件、エンドポイント管理、およびユーザーアクセスのニーズに依存します。パッケージング、展開場所、アクセスを別々に考慮することで、ITチームはアプリケーションをローカル、中央、または両方のモデルの組み合わせで実行するかどうかを決定できます。