新しい PC をキッティングするたびに、メーカーのサイトから複合機のドライバーを落として、IP アドレスを指定して1台ずつ登録している。地味だが、毎回15分は取られる作業だ。
ある会社（Windows PC 約50台、Intune 管理）で、オフィスの複合機2台のドライバーを Intune から自動で配る準備をした。メーカーの配布ファイルは、そのままでは無人で入らなかった。しかも梱包は Mac でやった。この記事はパイロットの前、梱包まで終えた段階の記録だ。Windows での実行はまだ検証していないので、そこは未検証と書く。結果は追記する。
この記事でわかること
- ▶ メーカーのインストーラーをそのまま包んでも、無人で入らない理由
- ▶ INF から入れるインストールスクリプトと、重複させない工夫
- ▶ 検出ルールに日本語を使わない理由
- ▶ Mac で .intunewin を作るときの落とし穴
▼背景：なぜ Intune で配るのか
この会社では、Windows のアプリ配布を Intune に一元化する方針にしている。プリンターも「配れるものは Intune で配る」。目的は3つある。
- ▶ 新しい PC は Intune に登録するだけで、複合機が使える状態にする
- ▶ キッティングの手順書から、手作業を1つ消す
- ▶ 誰がやっても同じ名前・同じ設定で入る
Business Premium には Universal Print も含まれる。だが、この複合機がそのまま対応しているかは確認できておらず、非対応なら中継用に常時起動の PC が要る。社内ネットワークから IP で直接印刷している今の構成なら、Win32 アプリとして配る方が素直だと判断した。
▼メーカーの配布ファイルは、そのままでは無人で入らない
メーカーのサイトから落とせるドライバーは、1つの exe だった。中身を調べると、RAR 形式の自己解凍ファイルで、その中に GUI のインストーラーと、署名付きの INF 一式が入っていた。
GUI のインストーラーは、画面でプリンターを選ばせる作りだ。exe をそのまま Intune で包んでも、無人では入らない。そこで、中の INF を直接使ってドライバーを登録する方式にした。
展開ツールで黙って壊れる
この自己解凍ファイルを 7-Zip で展開すると、0バイトのファイルが黙って作られた。エラーは出ない。unar で展開し直したら、正しく展開できた。展開したら、INF に書かれたドライバー名・バージョン・署名カタログが中身と合っているかを必ず確かめる。
▼インストールスクリプトの中身
インストールは PowerShell のスクリプトで行う。
① pnputil で INF をドライバーストアに登録する
② Add-PrinterDriver でドライバーを追加する
③ 複合機ごとに IP のポートを作る
④ プリンターを作る。同じ名前のプリンターがすでにあれば、作り直さずにドライバーとポートを付け直す
⑤ 最後にレジストリにパッケージのバージョンを書く（検出ルールで使う）
④がポイントだ。これまで手作業で入れてきた PC には、同じ名前のプリンターがすでにある。新しく作ると「入口」が2つ並ぶ。名前で探して付け直せば、重複しない。ただし、別の簡易インストーラーで入れた PC は、プリンター名が既定のまま（機種名）になっている可能性がある。その場合は並んでしまうので、パイロットのあとで個別に消す。
32ビットで起動されると pnputil が見えない
Intune の管理エージェントが PowerShell を32ビットで起動すると、System32 の pnputil が見えない。スクリプトの先頭で64ビットのプロセスかを確認し、32ビットなら64ビットの PowerShell で起動し直すようにした。
ログは Intune で回収できる場所に
ログは、Intune の管理エージェントのログフォルダに書く。こうしておくと、「診断の収集」で Intune の管理画面から取り寄せられる。現地に行かなくても、失敗の理由を追える。
▼検出ルールに日本語を使わない
Intune は、検出ルールで「入っているか」を判定する。プリンター名は「【入口】」のような日本語なので、名前で判定したくなる。だが、検出スクリプトに日本語のリテラルを入れると、Intune 側で文字が崩れて判定を誤るおそれがある。
そこで、レジストリのバージョン・ドライバー名・ポート名（IP ベース）で判定するようにした。スクリプト自体は日本語のプリンター名を含むので、UTF-8（BOM 付き）で保存した。スクリプトやドライバー、IP を変えたときは、インストールと検出の両方のバージョンを上げる。検出が外れて、入れ直しが走る。
▼Mac で .intunewin を作るときの落とし穴
Win32 アプリは、.intunewin という形式に梱包して Intune に登録する。公式の梱包ツールは Windows 専用だ。今回は Mac で梱包した。
Mac 用の梱包ツールもあるが、形式を確かめたところ、暗号化のモードが公式と違うツールがあった。公式の形式は AES-256 の CBC モードだが、CTR モードで作るツールもある。形式が違うと、配布先で復号できずに失敗する。今回は、Intune で実際に配布できた公式ツール製のパッケージを復号して形式を確かめ、それに合わせて梱包するスクリプトを書いた。
迷ったら公式ツール
Mac で梱包するのは、Windows の環境が手元にないときの手段だ。形式を確かめずに非公式のツールを使うと、配布の段階で原因のわかりにくい失敗になる。Windows が使えるなら、公式ツールで梱包するのが確実だ。
▼これから：パイロットと全社展開
- ▶ パイロットは、新入社員の PC のキッティングで行う（手作業の手順と置き換えられるかを見る）
- ▶ 要件は64ビット・Windows 10 22H2 以上。Windows 10 のままの PC が数台残っている
- ▶ 全社展開の前に、手作業で入れた PC で重複しないかを確認する
- ▶ FAX のドライバーは、必要な人だけが自分で入れられる「利用可能」として出す
パイロットの結果は、この記事に追記する。
▼まとめ
- ▶ メーカーの exe は無人で入らないことが多い。中の INF を使う
- ▶ 展開ツールが黙って0バイトを作ることがある。展開後に中身を確かめる
- ▶ 同名のプリンターがあれば付け直す。手作業の PC と重複させない
- ▶ 検出ルールは日本語を避け、バージョン・ドライバー名・ポートで判定する
- ▶ Mac で梱包するなら、暗号化の形式が公式と同じか確かめる
📅 30分無料相談、受け付けています
「PC のキッティングに毎回手作業が残っていて、人によって設定がばらつく」——そういった段階からお気軽にどうぞ。Intune でのアプリ配布から、キッティングの自動化まで対応しています。
📅 30分無料相談を予約する →