この記事でわかること

  • ▶ Jamf Pro から Iru(旧Kandji)へMDMを移行するときの全体フローと3ツールの役割分担
  • ▶ 「pkg」「Jamf側スクリプト」「Iru側スクリプト」をどの順番で流すのか
  • ▶ 実際に詰まったexit code 1（末尾スラッシュ）と、その原因の見つけ方
  • ▶ 移行後に「Self Serviceが消えない」がなぜ想定内なのか

ある会社で、Macの管理MDMを Jamf Pro から Iru（旧Kandji）へ移行する作業をやった。Iru側から移行キット（署名済みpkg + スクリプト2本）を受け取って、それを社内展開用の手順に落とし込むところまで一通り。

やってみて一番刺さったのは、「ツールが3つあって、それぞれ実行場所と実行タイミングが違う」という一点だった。ここを理解しないまま流すと、確実にどこかで事故る。逆にここさえ腹落ちすれば、あとは淡々と進む。この記事はその役割分担の整理と、実際に自分が踏んだ地雷の記録。

▼背景：MDM移行は「登録の付け替え」だけじゃ終わらない

MDM移行って、頭の中では「新しいMDMに登録し直すだけ」に見える。でも実際は、古いMDM（Jamf）の管理を”剥がす”作業がセットで必要になる。しかもJamfは、MDMプロファイルだけじゃなく、Jamf Connect・Self Service+・管理用ローカルアカウント・jamfバイナリ本体と、あちこちに根を張っている。

この「新規登録」と「旧管理の剥がし」を、Iruは3つのツールに分けて自動化している。まずはこの全体像から。

▼登場する3つのツールと役割分担

ツール実行場所役割・実行タイミング
Migration Agent
（署名済み.pkg）		Mac本体
（5分ごとに常駐実行）		Iruへの登録準備が整ったかを判定し、ユーザーに「登録 / 遅延」ダイアログを出す。登録が完了すると自動でアンインストールされる。
jamf_pro_removal.shJamf経由で配布Jamf Pro API経由で対象Macを unmanage（登録解除）する。移行ポリシーの中でpkgとセットで走らせる。
jamf_framework_
removal.zsh		Iru経由で配布
（移行後）		Iru登録後に、Jamf Connect / Self Service+ / 指定ローカルユーザー / jamfバイナリ本体を掃除する「お掃除スクリプト」。
ここが肝： 剥がし作業が2段階に分かれているのがポイント。
① Jamf側で jamf_pro_removal.sh が「MDM管理を外す」→ ② Iru登録後にIru側で jamf_framework_removal.zsh が「アプリやユーザーの残骸を掃除する」。
この①②を混同すると「なんでSelf Serviceがまだ残ってるの？」で確実に混乱する（詳細は後述）。

▼移行の実務フロー（Jamf側 → Iru側の順）

Jamf Pro側の準備

  • ▶ APIユーザーを作成：カスタム権限で「コンピュータ拡張属性」「コンピュータ」「ユーザー」にC・R・U、加えて「コンピュータの管理解除コマンドを送信する」アクションを付与
  • ▶ Migration Agent pkgをアップロード（パッケージとして登録）
  • ▶ jamf_pro_removal.shをスクリプトとして追加し、jss_url / api_user / api_pass / remove_record を設定
  • ▶ 移行ポリシーを作成（セルフサービス推奨）。pkg + スクリプト（優先度は必ず「後」）を紐付け

Iru側の準備

  • ▶ ABM連携・ADE設定を済ませ、既存デバイスをIru MDMサーバーに再割り当て（移行の24時間以上前にやる）
  • ▶ ブループリントを用途に合わせて設定
  • ▶ jamf_framework_removal.zsh をカスタムスクリプトライブラリアイテムとして追加。実行頻度は「デバイスごとに1回実行」、本文は「監査スクリプト」欄に貼る
ハマりどころ（ABM側）： デバイス再割り当て時に出る「期限を追加（Add Deadline）」オプションは使わないこと。Migration Agentはこのオプションを使わない設計で、付けると予期しない挙動を引き起こす可能性がある。ドキュメントに明記されてるのに見落としやすい。

デプロイの流れ

Migration Agent配布 → 動作確認（/Library/IruSE/standard.log をチェック）→ Jamf側からunmanageコマンド送信 → エンドユーザーへ通知。この順番を守る。

エンドユーザー通知は必須： Jamf管理を外した瞬間、Jamf経由で配っていたWi-Fi/ネットワークプロファイルが消えて、ネットワークが切れる可能性がある。移行中はゲストWi-Fiに繋ぐよう事前に案内しておかないと、「登録画面が出たのにネットが死んで進めない」という詰みが発生する。

▼実際に詰まったポイント①：exit code 1（末尾スラッシュ）

移行ポリシーを流したら、STEP 3のスクリプト実行でこれが出た。

Running script JamfPro Removal… Script exit code: 1 ERROR: Jamf URL failed validation. Please verify the URL contains http(s) and does not contain a trailing slash ‘/’

原因は jss_url の設定ミス。値がこうなっていた。

jss_url=”https://mycompany.jamfcloud.com/” ← 末尾にスラッシュ

スクリプト内のバリデーションはこの正規表現で、「末尾がスラッシュじゃないこと」を強制している。

url_test=’^https?://[^/]+[^/]$’

だから末尾に / があると確実に落ちる。正解はこう。

jss_url=”https://mycompany.jamfcloud.com” ← スラッシュを抜くだけ
教訓： このスクリプトのURLは「https(s)ありで、末尾スラッシュなし」が絶対条件。ダウンロードログに出ていた https://mycompany.jamfcloud.com/jcds/downloads/... の頭部分がそのまま正解の形。self-hostのJamfならポート番号（例: :8443）が必要な場合もあるので、環境に合わせて確認する。

▼実際に詰まったポイント②：APIパスワードの特殊文字

今回の直接原因ではなかったが、ドキュメントに「スクリプトエラーを避けるため、パスワードには英数字のみを使うことを推奨」と明記されている。

理由は、APIパスワードが後段でcurlのBasic認証に使われるため、& や $ のようなシェルで解釈され得る文字が混じると、エスケープ次第でトラブルの種になるから。jamf_pro_removal.sh側で特別なエスケープ処理はしていないので、APIユーザーのパスワードは最初から英数字のみで作っておくのが安全。ここは移行前に潰しておきたい。

▼実際に詰まったポイント③：移行後にSelf Serviceが残る

移行自体は成功したのに、Jamf ProのSelf Service+アプリがMacに残っていた。「移行失敗？」と一瞬焦るが、これは想定内。役割分担を思い出すと腹落ちする。

スクリプトSelf Service+を消すか？
jamf_pro_removal.sh（Jamf側）消さない。MDM管理を外すのとJamf Connect削除が担当。インストール済みアプリは自動では消えない。
jamf_framework_removal.zsh（Iru側）これが担当。remove_self_service_plus 関数がCLI経由でアンブランディング→アプリ削除→各ユーザーホームの残骸掃除まで実行する。

つまりSelf Service+が残っているのは、Iru側の jamf_framework_removal.zsh がまだ走っていないだけ。Iruテナントでこのスクリプトをカスタムスクリプトライブラリアイテムとして登録し、対象ブループリントに紐付ければ、次のチェックイン時にSelf Service+もJamf Connectの残骸も一緒に掃除される。

掃除スクリプトを流す前の確認事項：
  • USERS_TO_REMOVE のユーザー名が、自社環境で実際に使っているJamf管理用ローカルアカウント名と一致しているか（サンプル値のままだと何も消えない、あるいは名前が被ると想定外を消すリスク）
  • jamfバイナリがまだ端末に残っている前提の「Iru登録後」のタイミングで実行しているか（登録前に流すと意味がない）

▼終了コードの読み方（トラブルシュート早見表）

終了コード意味確認ポイント
1スクリプト内エラーログの ERROR 行を読む。今回の末尾スラッシュはこれ。
2Migration Agentのバックグラウンドプロセスが未起動削除スクリプトより先にpkgがインストールされる設定になっているか（ポリシー内の優先度）
3unmanage APIコマンドが失敗APIユーザーの権限 / パスワードの特殊文字 / URLの正しさ、の3点
「Jamf Management Still Present」ダイアログが出たら： jamf_pro_removal.shは正常完了したが、MDMプロファイルの削除に時間がかかっているサイン。10分待っても登録画面が出ない場合は、①Macを再起動 → ②Jamf管理画面から空プッシュを送信 → ③移行ポリシーを再実行、の順で対処する。

▼まとめ

  • ▶ Jamf→Iru移行は「pkg・Jamf側スクリプト・Iru側スクリプト」の3つで構成され、実行場所とタイミングが全部違う
  • ▶ 剥がしは2段階。Jamf側で管理を外し → Iru登録後にIru側で残骸を掃除する
  • ▶ jss_url は末尾スラッシュ厳禁。exit code 1 の定番
  • ▶ APIパスワードは英数字のみで作る。特殊文字は事故のもと
  • ▶ 「Self Serviceが残る」は失敗じゃない。Iru側の掃除スクリプトがまだ走ってないだけ

MDM移行は「登録の付け替え」ではなく「旧管理を丁寧に剥がしながら新管理に載せ替える」作業だ。役割分担と順番さえ押さえれば、詰まっても原因の切り分けは早い。これから移行する人の地雷回避になれば。

📄 Jamf運用の別事例についてはJamfでMITERASを展開した記事でも解説しています。
📄 MDM選定そのものを検討中の方はMicrosoft Intune解説の記事もどうぞ。

📅 30分無料相談、受け付けています

「MDMを乗り換えたいけど、旧環境をどう剥がせばいいか不安」「移行の段取りを一緒に設計してほしい」——そういった段階からお気軽にどうぞ。

📅 30分無料相談を予約する →