ブログ

Ivanti DSMのサポート終了:IntuneとRealmJoinで新しく始める

Ivanti DSMは2026年12月31日にサポート終了を迎えます。RealmJoinとともにMicrosoft Intuneへ移行する計画の立て方、再パッケージ化の手間を小さく抑える方法、そしてその過程でソフトウェア配布を刷新する方法。

Ivanti DSMは2026年12月31日にサポート終了を迎えます。その日を過ぎると、更新プログラムもセキュリティパッチもベンダーサポートもありません。まだDSMを使っている組織には、いまDSMが担っている役割をゼロから作り直すことなく置き換え、しかも現在のIT運用のかたち、つまりクラウドで管理されるデバイス、セルフサービス、継続的な更新に合った移行戦略が必要です。

RealmJoinはMicrosoft Intuneを補完するために作られており、DSM環境ではIntuneが埋めない部分、すなわちパッケージング、パッチ適用、セルフサービス、自動化を引き受けます。この記事では、Ivanti DSMからIntuneとRealmJoinへの移行を、最初のアセスメントからDSMを停止する日まで順に追います。

Ivanti DSMのサポート終了後に起きること

サポート終了日を過ぎてもIvanti DSMを動かし続けること自体は技術的に可能で、ソフトウェアが一夜にして止まるわけではありません。ただし、リスクは大きくなっていきます。

  • セキュリティ脆弱性が修正されなくなります
  • セキュリティ関連ではないものの業務に不可欠な重要なソフトウェア更新も、展開できなくなります
  • ISO 27001のようなコンプライアンスフレームワークでは、サポートの切れたDSMが許容できないリスクと判定される可能性があります
  • 不具合や連携の問題は、ベンダーサポートなしで自社で解決することになります
  • 期限が近づくほど、移行を支援するパートナーと知見は手に入りにくくなります

期限は動きません。その日にどれだけDSM上に残っているかは、動かせます。

Ivanti DSMのあとのソフトウェア配布

Ivanti DSMは従来型のIT、つまりオンプレミスのインフラ、ドメイン参加したWindowsデバイス、中央集権的でほとんど手作業のプロセスを前提に設計されました。いまの環境が求めるものは違います。

  • 社内ネットワークに依存せず、クラウドで管理されるデバイス
  • 利用者がソフトウェアを自分で入手できるセルフサービス
  • サードパーティアプリケーションの継続的な更新
  • 手作業のパッケージングと保守の削減

問いはすでに「Ivanti DSMの代わりは何か」ではなく、「これからのIT運用モデルを支えるものは何か」に変わっています。

Microsoft Intuneを基盤にする理由

Microsoft Intuneは、Microsoft 365に含まれるクラウドネイティブなエンドポイント管理サービスです。デバイスの登録とライフサイクル管理、セキュリティポリシーとコンプライアンスの適用、Microsoft Entra IDと組み合わせたConditional Access、そしてWindows、macOS、iOS、Androidへのクロスプラットフォーム対応を提供します。すでにMicrosoft 365を使っている組織にとって、DSMの置き換え先としては自然な基盤です。

Intuneだけでは十分に埋まらない部分があります。

  • 規模に見合ったアプリケーションのパッケージング
  • サードパーティ製品のパッチ適用の自動化
  • セルフサービスでのアプリケーション配布
  • 大規模なソフトウェアカタログの効率的な管理

RealmJoinがIntuneに加えるもの

RealmJoinはMicrosoft Intuneをアプリケーションライフサイクルと自動化のプラットフォームへ拡張し、いま挙げた空白をそのまま埋めます。DSM移行でいちばん効いてくるのはアプリとパッチ適用のモジュールで、自動化、ヘルプデスク向けのツール、ローカル管理者アカウントの管理もあわせて使えます。

あらかじめ用意されたメンテナンス済みのアプリケーションパッケージ

  • 3,000本を超える法人向けアプリケーションが、そのまま配布できる状態で揃っています
  • 数百本のmacOSアプリを、Intune経由で配布できます
  • iOSとAndroidのアプリストア全体を、同じコンソールから管理できます(近日提供)
  • ベンダーの新しいバージョンは15分以内に検出され、指定した待機期間に従ってPreviewチャネルとMainチャネルへ展開されます

カタログにないものは依頼すれば短期間でパッケージ化され、あるいは自前のインストーラーをorganicパッケージとしてアップロードできます。それがDSM移行の再パッケージ化の手間をどれだけ小さくするかは、パッケージカタログの規模で扱います。独自アプリケーションは、監査されたGitリポジトリ、CI/CDベースのパッケージングパイプライン、標準化された品質管理によって支えられています。カタログに何があり、パッケージがどう保守されているかはPackage Storeのドキュメントに書かれています。

セルフサービスのソフトウェアポータル

利用者はデバイス上のApp Catalogから、承認済みのアプリケーションを自分でインストールします。ヘルプデスクの負荷が下がり、移行中も移行後も利用者にとって切り替えが楽になります。仕組みはセルフサービスポータルのドキュメントで確認できます。

サードパーティ製品のパッチ適用の自動化

アプリケーションを一度サブスクライブすれば、あとはRealmJoinが最新に保ちます。更新は継続的に行われ、セキュリティ上の露出は小さくなり、手作業の保守はなくなります。

ソフトウェアライフサイクル管理

バージョン管理と段階的な自動展開、利用状況の計測とレポート、そして各デバイスにあるソフトウェア資産の可視化。独自ツールを作らずに、ライフサイクル全体を管理できます。

Runbookによる自動化と修復

RealmJoinには、GitHubで保守されている175本のRunbookと修復スクリプトのライブラリが付属します。Intune、Entra ID、Exchange Online、TeamsといったMicrosoft 365まわりの定型的な構成、設定の作業を一通りカバーします。

Runbookは、自社のサブスクリプションにあるAzure Automationで動き、RealmJoinのポータルから起動されるPowerShellスクリプトです。管理者やサポート担当は、Intuneの専門家である必要も、IntuneやEntraの強い権限を持つロールを保有する必要もなく実行できます。誰が何を実行してよいかは、細かく分かれたアクセス許可が決めます。

修復スクリプトはそれを補い、管理下のクライアント上で構成の問題を直接修正します。Runbookと同じくGitHubでホストされ、ポータルから管理します。

ライブラリには、レポートと監査のためのスクリプトも含まれます。あらゆる操作は、自社テナント内のAzure Log Analyticsに一元的に記録できます。

クラウドで管理されるデバイスのためのLAPS

Microsoft EntraとIntuneには標準のLAPSがありますが、デバイスごとにローカル管理者アカウント1つに限られます。RealmJoinはエージェントによる独自の実装を加え、用途の異なる3種類のアカウントを用意します。

  • 緊急用アカウント:ネットワークにもIntuneにも到達できない状態で使う、ブレークグラス用の常設ローカル管理者アカウントです。
  • サポート用アカウント:日々のサポート作業のために必要なときだけ作成され、設定した有効期限が過ぎると自動的に削除されるため、管理者の資格情報が残り続けることはありません。
  • 特権アカウント:パワーユーザーがSelfLAPSを使って、IT部門の手を借りずに自分の一時的なローカル管理者権限を申請できます。

どのアカウント種別も、必要に応じた作成、有効期限、パスワードの既定値を含めてRealmJoinのポータルで設定します。パスワードは自社テナント内のAzure Key Vaultに暗号化して保管され、パスワードの要求はすべて監査のために記録されます。

ヘルプデスクと運用のためのコンソール

さらにRealmJoinは、ヘルプデスクと運用のための統合コンソールを加えます。デバイスのインベントリ、統合されたヘルプデスクツール、ワンクリックで実行できる管理操作です。

Ivanti DSM、Intune、Intune + RealmJoinの比較

機能Ivanti DSMIntuneIntune + RealmJoin
ソフトウェア配布✓✓✓
Entra IDとの連携限定的✓✓
モバイルデバイス管理限定的✓✓
クラウドネイティブなアーキテクチャ—✓✓
サードパーティ製品のパッチ適用✓限定的✓
あらかじめ用意されたアプリカタログ限定的限定的✓
2026年以降のサードパーティアプリのセキュリティ更新——✓
セルフサービスポータル限定的限定的✓
Runbookによる自動化——✓
クラウドデバイスのLAPS—限定的✓
配布状況の可視化✓限定的✓
2026年以降のベンダーサポート—✓✓

Intuneの行でカタログとパッチ適用が「限定的」なのは、Intune SuiteのEnterprise App Managementアドオンを指します。厳選されたカタログと、そこに含まれるアプリの更新が対象で、ライセンスは別途必要です。

RealmJoinがIvanti DSMの有力な代替になる理由

企業はRealmJoinを使って、Intune環境のソフトウェア配布を刷新し、規模が大きくなっても運用の負担を抑えています。Ivanti DSMを一対一で置き換えるものではなく、Microsoft Intuneを現代的にするための層です。

  • アプリケーションの再パッケージ化の手間をほとんどなくします
  • 移行のスケジュールを前倒しできます
  • Intuneまわりの定型作業に自動化を加えます
  • クラウドネイティブなソフトウェア配布を可能にします
  • 利用者の体験を改善します

DSMをそのまま再現するのではなく、その過程でIT運用モデルそのものを新しくすることになります。

Ivanti DSMの置き換えで決めるべきこと

パッケージカタログの規模

DSM環境には、長年かけて積み上がった数百本のアプリケーションが入っていることがよくあります。それらの再パッケージ化は、DSM移行でいちばん手間のかかる部分になりがちです。

RealmJoinはこれに3つの層で対応します。Package Storeには、そのまま使えて継続的にメンテナンスされるパッケージが3,000本以上あり、RealmJoin AgentからでもIntuneからでも配布できます。よく使われる法人向けアプリケーションの大半は、パッケージングの手間なしにここで賄えます。ストアにないアプリケーションは、依頼すればパッケージングチームが作成します。genericパッケージには顧客固有の設定が入らず、追加費用なしで全顧客が利用でき、顧客固有のカスタマイズが必要なパッケージだけがcustomパッケージングの枠を消費します。そしてorganicパッケージでは、自前のインストーラーをZIPファイルとしてポータルからアップロードし、固定の構成のままバイナリを配れます。数分で自動的にビルドされ、チケットも追加費用も要りませんが、インストール先のパスは固定で、作成後に更新はできません。

つまりDSMカタログの大半は、再パッケージ化の大きな手間も費用もかけずに賄えます。ストアから、genericパッケージの依頼から、あるいは単純なバイナリならorganicパッケージからです。

刷新か、そのまま移すか

Ivanti DSMのサポート終了は、クラウドネイティブな基盤へ移り、レガシーな依存関係をなくし、運用の負担を減らし、拡張性を得る機会でもあります。刷新する組織のほうが、既存のしくみをそのまま写し取る組織より、長期的な成果は大きくなります。

移行を構成する要素

DSMからIntuneへの移行を一通り終えるには、アプリケーションパッケージ、ソフトウェア配布のワークフロー、デバイスとセキュリティのポリシー、ユーザーとグループの構成、そしてパッチ管理のプロセスが対象になります。IntuneとRealmJoinの組み合わせは、そのすべてに現代的な対応物を用意しています。

Ivanti DSMからIntuneへの移行、10のステップ

1. 既存のDSM環境をアセスメントする

アプリケーション、配布のワークフロー、依存関係、インフラといった現状を分析します。ここで移行の範囲と複雑さが決まり、プロジェクトの途中で驚くこともなくなります。

2. 業務に不可欠なアプリケーションとユースケースを洗い出す

日々の業務に欠かせないアプリケーションに優先順位を付けます。事業を止めずに済み、広く展開する前にどのワークロードから検証するかも決まります。

3. 目指すアーキテクチャを定義する

Microsoft Intuneをクラウドネイティブな管理基盤として据え、RealmJoinがアプリケーションライフサイクル管理、自動化、ソフトウェア配布でそれをどう拡張するかを定めます。ほかに手を付ける前に、この構成を書き出しておきます。

4. Intuneの構築とRealmJoinの評価を並行して進める

RealmJoinはMicrosoft Intuneを土台として必要とします。まだIntuneを使っていない組織では、このステップは2本の並行した作業になります。Microsoft 365テナントでIntuneを有効にする作業と、RealmJoinのオンボーディングです。現在の環境に照らして移行を検討するには、デモを予約してください。

5. DSMのアプリケーションをRealmJoinのパッケージに対応付ける

現在のアプリケーション一覧とRealmJoinのカタログを突き合わせます。どのアプリケーションがすでにgenericパッケージでカバーされているかを確認し、パッケージングが必要な不足分に印を付けます。この対応付けが移行計画の土台になります。

6. 足りないアプリケーションのパッケージングを依頼する

RealmJoinはサービスとしてのパッケージングを提供します。カタログでカバーされないものは依頼します。genericパッケージは全顧客で共有され、サブスクリプションに含まれます。organicパッケージは数分で仕上がります。customパッケージングの枠を消費するのは、顧客固有のカスタマイズだけです。DSM移行における社内のパッケージング作業は、そのほとんどがこのステップで消えます。

7. 配布に向けてIntuneとRealmJoinを構成する

Intuneのポリシーとコンプライアンス設定を構成し、RealmJoinを接続し、パッケージの割り当てと配布グループを定義します。RealmJoinのパッケージは決まった割り当てと構成のワークフローに従うため、監査でき、同じ手順を繰り返せます。

8. パイロットで配布を検証する

広く展開する前に、実際の使い方で試します。インストール時の挙動、割り当ての条件と対象、更新とパッチ適用のワークフローです。RealmJoinはPreviewチャネルとMainチャネルを通じて段階的に展開するため、規模を広げる前に管理された範囲で挙動を確かめられます。

9. セルフサービスを有効にし、展開を広げる

パイロットの検証が終わったら、セルフサービス用にApp Catalogを有効にし、段階を管理しながら配布を広げます。ヘルプデスクの出番が減り、移行中の利用者の体験がよくなり、IT部門は展開の進み具合を把握できます。

10. Ivanti DSMを停止する

すべてのアプリケーションがRealmJoinのパッケージに移り、Intuneから配布でき、ライフサイクルの自動化で管理されるようになったら、Ivanti DSMを役目から外して移行を完了します。このステップは検証がすべて終わるまで進めないでください。早すぎる停止は、移行でよくある失敗の一つです。

まだ間に合います

Ivanti DSMのサポート終了は近づいていますが、慌てる必要はありません。その日までに終えている必要はなく、始まっていればよく、始めるのは早く済みます。Microsoft Entraの管理者同意を1回行えばRealmJoinが自社テナントにつながり、カタログの大半はすでにPackage Storeにあり、ゼロから最初のパイロット配布まで8時間かからなかったお客様もいます。そこから先は自分たちで管理できる段階に分けて進みます。まずパイロットグループ、次にPreviewチャネルとMainチャネル、準備ができたらセルフサービスです。年末の時点でDSMに残っているものは、リスクではなく、減っていくリストです。デモを予約いただければ、お客様のカタログから始めます。

Ivanti DSMの移行についてよくある質問

Ivanti DSMのサポート終了はいつですか

2026年12月31日です。

サポート終了後もIvanti DSMを使い続けられますか

使えますが、更新プログラム、セキュリティパッチ、ベンダーサポートはありません。セキュリティ、コンプライアンス、運用上のリスクを抱えることになります。

DSM移行プロジェクトでは何を優先すべきですか

アプリケーションカタログの規模、パッケージングの手間、セルフサービスの機能、パッチ適用の自動化、そして移行先がクラウドで管理される環境にどれだけ合っているかです。

RealmJoinとは何ですか

RealmJoinは、Microsoft Intuneのためのアプリケーションライフサイクルと自動化のプラットフォームです。あらかじめ用意されたアプリケーションパッケージ、パッチ適用の自動化、セルフサービスのApp Catalog、Runbookによる自動化、そしてローカル管理者アカウントの管理(LAPS)を提供します。

RealmJoinは移行の手間をどう減らしますか

再パッケージ化のほとんどをなくすことによってです。継続的にメンテナンスされる大規模なWindowsとmacOSのアプリケーションカタログが共通部分を押さえます。足りないものは依頼すればパッケージ化され、顧客固有の設定が絡まない場合は追加費用なしのgenericパッケージとして共有され、あるいは数分でorganicパッケージとしてアップロードできます。customパッケージングの枠を消費するのは、顧客固有のアプリケーションだけです。

Ivanti DSMの移行にはどれくらいかかりますか

最初のパイロット配布にかかるのは四半期ではなく1日です。テナントの接続は管理者の同意1回で済み、カタログの大半はすでにPackage Storeにあります。移行全体にどれだけかかるかは、カタログの規模と選んだペース次第で、進み方は自分たちで管理できます。

RealmJoinにオンプレミスのインフラは必要ですか

必要ありません。RealmJoinは、欧州のMicrosoft AzureでホストされるSaaSプラットフォームです。管理者の同意1回でMicrosoft IntuneとMicrosoft 365につながり、Runbook、ローカル管理者パスワード、ログといった機微な部分は自社テナントで動きます。

それ以外の質問は

ドキュメントのFAQをご覧いただくか、お問い合わせください。

出典

DSMは置き換える。作り直さない。

RealmJoinはMicrosoft Intuneを補完します。3,000本以上のメンテナンス済みパッケージ、依頼に応じたパッケージング、段階的な更新、セルフサービス、そして175本のRunbookが、管理者の同意1回で自社テナントにつながります。多くのDSMカタログは、最初のcustomパッケージが必要になる前にカバーされます。

RealmJoinの動作を見る始める