Atrae Tech Blog

People Tech Companyの株式会社アトラエのテックブログです。

「Jamf 何も分からん」からゼロタッチデプロイへ

f:id:atrae_tech:20210822145153p:plain

こんにちは、Docker の申し子小倉(@haaaayhay)です。今回はデバイス管理ツール Jamf Pro を使ってゼロタッチデプロイができるようになるまでの過程を書いていきます。

弊社では Jamf Pro を使ってゼロタッチデプロイ(管理者が行うキッティングを自動化すること)を行っています。これができるようになってからこれまで数十分かかっていたキッティング作業がすぐ終わるようになり、働き方の幅を広げると言っても過言ではないような成果を得られました。

ちなみに後述する DEPNotify を使うとこんなかんじにセットアップを自動化出来ます。

f:id:atrae_tech:20210826095609p:plain

ゼロタッチデプロイをすることが全てではありませんが、デバイス管理の主要なタスクの1つにキッティングがあることは自明であり、これをいかに効率化しミスを無くしていくかは重要な問題になってくるはずです。特に企業規模が大きくなってくるとキッティングの回数が増えてくるため、その兆しが見えてきた時にやっておくことでキッティング自体が組織成長のボトルネックになることを防ぐことができます。

弊社でもその課題感はあったので「Jamf Pro でゼロタッチデプロイや〜!」と意気込んでいましたが、何をやったらいいか分からず時間がかかってしまいました。ググると他の企業さんの「ゼロタッチデプロイ導入した話」というのがいくつかヒットしました。ゼロタッチデプロイによってどのような恩恵が得られたかは分かったのですが、どのようにしてそこにたどり着くべきかが分かりませんでした(決して dis ではないです!あくまで趣旨ではないと理解しています)。もちろんゼロタッチデプロイを達成していく上での大きなモチベーションになりましたが、どうせならそのニーズを満たせるような記事を書こうということで今回筆を執っています。

この記事ではゼロタッチデプロイできるようになったことの恩恵というより、Jamf Pro がよくわからない状態からどうやってゼロタッチデプロイにたどり着いたのかという過程にフォーカスします。

前提

  • Jamf Pro クラウド版を利用しています。
  • 利用している Jamf Pro のバージョンは10.31.1です。
  • iOS 端末の管理は今回対象にしておらず、OSX 端末の管理とゼロタッチデプロイをすることをゴールにし、そのために必要な概念を中心に書いています。

ゼロタッチデプロイのために

まだ Jamf Pro を導入していない、したばかり、という方はゼロタッチデプロイを実施するために何が必要になるかを知る必要があります。個人的には3ステップかなと考えています。

  1. エンロールを通して全端末を Jamf Pro の管理下に置くこと
  2. 構成プロファイルやポリシーをもとに各端末に設定を適用すること
  3. ABM と DEPNotify を利用して必要な設定を適切な順番で読み込ませること

もちろん 1~3のそれぞれで覚えることがたくさんありますが、3つだけと考えればそこまで大変ではないかなと。

また上記は以下のようにも言い換えられると思います。これらは Jamf Pro でできることを3つに大別したものと言っても大げさではないはずです。

  • 端末の登録と管理、情報の可視化
  • 端末の設定と制限の適用
  • ゼロタッチデプロイのための設定の作り込み

例えばゼロタッチデプロイは2つ目と3つ目を利用したものです。

端末の登録と管理、情報の可視化

エンロール

Jamf Pro におけるエンロールとは、対象端末を Jamf Pro に登録することを指します。

エンロールには UIE(User-Initiated Enrollment)とADE(Automated Device Enrollment)とに分けられます。前者は端末を手動で操作し、遷移先の URL からプロファイルをインストールすることで Jamf Pro と当該端末を連携させる方法です。後者は Prestage Enrollment という機能を利用し、PC を起動するに Jamf に登録しておく方法です。特に後者はゼロタッチデプロイを実施する上で必要になってきます。

弊社では基本的に ADE というかゼロタッチ経由でエンロールし、端末がうまく Jamf Pro と接続できていない場合や ABM 経由で購入していない端末をキッティングする時に私が手動で UIE する方式をとっています。

いずれの方法でもいいですが、とにかく Jamf Pro と端末が疎通してる状態をつくることが第一歩です。

コンピュータとユーザとインベントリ

端末が Jamf Pro に登録されると、コンピュータ情報として Jamf Pro 上で各種情報を閲覧できます。プロセッサーやメモリの情報、ローカルユーザ情報など MacBook 上で確認できる情報であればほぼ全ての情報を取得できます。これをインベントリと呼んでいます。

またインベントリには管理者が任意で作成、入力できるものもあります。弊社では購入日や利用開始日などの情報を attiribute として手動入力しています。

ただしこれらだけだとあくまで端末の情報だけなので、別にユーザー情報を作成し、それを端末と紐付ける必要があります。誰がどの端末を利用するかは管理者が明示的に設定する必要があるためです。

グループとダッシュボード

Jamf Pro では端末をグルーピングする機能として Smart Computer Groups と Static Computer Groups という機能を持ちます。

前者は予め設定した条件に引っかかる端末を取得し、後者は明示的に選択した端末を取得します。特に前者の使い所としては以下があります。

  • 購入日から3年経過した端末を確認するために Smart Computer Groups を作成
  • BigSur の端末を確認するために Smart Computer Groups を作成
  • M1 チップの端末を確認するために Smart Computer Groups を作成
  • FileVault が適用されていない端末を確認するために Smart Computer Groups を作成

グループはダッシュボードに表示することもできます。各グループの右上にある Show in Jamf Pro Dashboardをクリックすると、そのグループのダッシュボードが表示されます。

f:id:atrae_tech:20210822150446p:plain
グループの設定画面

Jamf Pro の管理者からすると、各端末の細かい情報だけではなく組織内の端末のオーバービューを確認し、異常な端末を知りたいはずです。例えば FileVualt が適用されていない端末を確認できれば、その個人に声がけするだけです。まず少なくともこれだけで MDM の価値はあるはずです。

端末の設定と制限の適用

ポリシー

ポリシーとは対象端末に適用する機能のことです。例えばコンピュータ名を変更したり、セキュリティツールをインストールしたりすることができます。

後述する構成プロファイルにも言えることですが、基本的にはポリシーを作成し、対象スコープに適応したタイミングで対象端末にその設定が読み込まれます。

ただしポリシーは読み込まれた後、それを発動させるトリガーの設定が可能です。「端末の起動時」「ログイン時」「ログアウト時」などを設定できます。想像するに、ポリシーは構成プロファイルと比べて破壊的な設定が多いため、端末利用者のタイミングに合わせて適用できるように設計されているのかもしれません。

構成プロファイル

構成プロファイルはポリシー同様、PC に望ましい設定を読み込ませることができる機能です。例えばパスワードをマスクしたまま WiFiSSID とパスワードを配布したり、Chrome の一部機能を無効化できたりします。

ポリシーと異なる点としては、構成プロファイルは対象スコープに入れて適用したタイミングで対象端末にその設定が読み込まれることが挙げられます(また前提として構成プロファイルとポリシーとで設定できる項目自体が異なります)。

ポリシーと構成プロファイルを使うと MacBook に対する設定の適用や制限を一通り実施することが出来ます。ここまでくると一元管理をしている感覚もあるはずです。

OS のアップデート制限

管理者が気にすることの1つに OS のアップデート制限や管理があるはずです。特にメジャーアップデート(Catalina から BigSur とか)は Restricted Software という機能を利用することで制限できます。

ただし BigSur になってからはマイナーバージョンの制御の方法が変わってしまったので簡単に説明します。

構成プロファイルを使ったマイナーバージョンの制限方法は2つあります。

一つは Restrict items in System Preferences を利用する方法。もう一つは Defer updates of Applications(macOS 11 or later) for N days を利用方法です。

前者は Mac のシステム環境設定から ソフトウェアアップデート をクリックできないようにする機能です。対象グループにこの設定があたっている間はクリックできない状態になるので楽ですが、OS のパッチだけではなく Safari 等のアプリケーションも一緒にアップデートできなくなるのがデメリットかもしれません。

f:id:atrae_tech:20210822150908p:plain
Restrict items in System Preferences で制限した時の画面

後者はマイナーバージョンがリリースされてから X 日間はアップデートができなくなる機能です。例えば90日と設定すると、90日以内にリリースされたマイナーはユーザーには通知されず、91日目になった時に通知されるようになります。ただしマイナーではなくパッチは対象外になるので普通に通知されます。

f:id:atrae_tech:20210822150959p:plain
Defer updates で制限した時の画面。ちなみにこの時の最新は 11.5.2

Jamf Nation

Jamf の公式コミュニティとして Jamf Nation があります。ここでは Jamf に関するユーザー同士のやりとりがされます。

かなり大規模なコミュニティなので、自分が設定したいニッチな構成プロファイルやポリシーの例がここにあることが多いです。

自分も困ったらまずはここで関連するやり取りがないかを探すようにしています。

community.jamf.com

その他テクニック

構成プロファイルやポリシーを利用して端末に設定を展開しますが、この際にいくつかテクニックがあります。自分はこれらを知らず有識者に色々教えてもらい助かりました。

  • plist という Apple で用いているプロファイルリストの配布が必要な場合がある。
  • 設定は PKG や DMG の配布が必要な場合がある。
  • plist や PKG や DMG の作成には Jamf Composer や Jamf Admin が必要になる場合もある。
  • etc

Composer や Admin は無料で利用できるツールですが、脳死で操作すると動かない可能性があるのでしっかり学習して臨むほうがいいです。

ここまでくれば管理している端末に、望ましい設定を適用したり制限したりできるようになります。あとはこれを開封時に人の手を介さずに展開してあげればいいだけです。

ゼロタッチデプロイのための設定を作り込む

Apple Business Manager

ゼロタッチデプロイをしようとすると構造的な矛盾を感じると思います。それはゼロタッチデプロイは設定の展開をするのに人を介さず自動化するものなのに、Jamf Pro で設定を展開するのには端末を Jamf Pro に登録しないといけないからです。

これを解決するには端末を Apple Buisness Maneger(通称 ABM)で購入する必要があります。ABM で端末を購入すると対象端末にはフラグが立ちます。ゼロタッチデプロイに際して適用したいポリシーや構成プロファイルの対象を「ABM経由で購入した端末」としておけば、その端末がネットワークに繋がった瞬間に設定を読み込ませることができます。

ABM での購入には追加費用がかかったり、別途利用コストが掛かったりするわけではないので、Jamf Pro を利用中の企業で ABM を利用しない理由はあまりないかなと考えます。

DEPNotify

ゼロタッチデプロイを実施するには DEPNotify というツールを利用する必要があります。GitHubGitLab からクローンできます。

DEPNotify を使わない場合、構成プロファイルやポリシーの設定がバックグラウンドで行われユーザーには見えないようになっています。するとどの設定が終わったのか、失敗しているのかが少し見えにくいという若干のデメリットがあります。

DEPNotify を使うと

  1. まず端末がネットワークに繋がると構成プロファイルが読み込まれる
  2. ユーザー自身でコンピュータ名やパスワードを設定する
  3. 進捗バーとともにポリシーが読み込まれる
  4. 3の進捗バーが全て埋まると全ての設定が完了する

というようにユーザーの UX が向上します。特に4に関しては、進捗バーの進み具合から、完了までどれくらいの時間がかかるか予想しやすくなるので手持ち無沙汰な時間を削減できます。

またこの DEPNotify ではポリシーを順番に展開できます。ポリシーに依存関係がある場合、依存関係を考慮せずに適用するとコケる可能性が減ります。前述したポリシーのトリガーとは別に Custom があるのでこれを指定すればシェルと組み合わせて順序を保存して実施可能です。

最近の困りごと

ゼロタッチデプロイができるようになるこの記事で書くのもあれですが、BigSur にてゼロタッチデプロイをすると高確率で Mac が文鎮になるバグがあります。自分も何台かを文鎮にしました(もちろん修復可能なので問題なし)。

どうやら Jamf Pro のバグらしく現在調査・対応中とのことです。

Jamf Nation にあるワークアラウンドとしては Prestage Enrollment を使ってデプロイする時に AppleID とデータ転送のチェックを外す(=それらの項目をユーザーに表示させる)ことらしいです。実際に自分もそれで実施したところ、今の所は当該端末は文鎮になっていません。

運用でカバーすることが増えるので早期解決を望みますが、一旦はワークアラウンドの URL をここに添付します。タイトルでは Intel の PC を指して問題提起していますが、M1 にも発生しています。

community.jamf.com

最後に

色々書きましたが、結局は

  • 組織内の各端末が Jamf に登録される方法を知り
  • 構成プロファイルやポリシーで設定を読み込ませる方法を知り
  • それを未開封端末に適用する方法を知る

という流れになっていたと思います。公式ドキュメント等と組み合わせればきっとゼロタッチデプロイができるようになっているはずです。

ゼロタッチデプロイはできるようになると改めてメリットが大きいように感じます。

自動化することでミスを減らすのはもちろん工数削減に繋がります。工数削減に繋がると予定の組み方も柔軟になります。これまで30分程度かかっていたものが一瞬になるだけでなく、急な PC の故障等にも対応しやすくなります。

リモートで働くメンバーの自宅へ直接配送することが出来ることから、海外で働くメンバーにも優しい運用になります。国際郵便約款の制限により飛行機で郵送できるリチウムイオンバッテリーの大きさが決まっています。15インチと16インチの Macbook は対象になっているため、飛行機を使って配送することは出来ない決まりになっています。ただし、海外の支店から直接送ってしまえば問題ないのでこの点でもゼロタッチデプロイが寄与していると言えます。

多くの企業がゼロタッチブをブログにする理由も分かります。分かりやすい成果であると同時に、構成プロファイルやポリシーなどを作りきらないとそもそもゼロタッチデプロイをするどころではないので、ある意味最終到達地点の類なんだろうなとも思っています。もちろんパッチ管理やセルフサービスなど他にも多くの機能が Jamf Pro にはあるので、ゼロタッチはゴールの1つということだと認識しています。

参考にさせて頂いた資料

多いに参考にさせて頂きました。また自分にとって大きなモチベーションになったことも間違いありません。