インストーラーのない社内システムを Intune へ。Oracle は納品物を見て外した

Intune を入れて、PC のアプリの多くは Intune から配れるようになった。それでも、業者が作った社内の業務システムだけは、新しい PC のたびに手で入れている。インストーラーがなく、「納品フォルダを C:\ にコピーして、ショートカットを作る」作りだからだ。

インストーラーがないことは、Intune で配れない理由にならない。コピーとショートカットの作成をスクリプトにして包めば、Win32 アプリになる。難しいのは包む作業より、前任の手順書のどこが今も要るかを見極めるほうだった。

ある会社（30名規模）で、新入社員の PC のキッティングに合わせて、この業務システムを Win32 アプリにした。手順書には Oracle クライアントの導入と設定が並んでいたが、納品フォルダの中身を見て「要らない」と見立て、パイロットの1台で確かめた。Oracle クライアントを入れずに起動し、1本目のアプリにはログインできた。2本目のログインは、ID の発行待ちでまだだ。

この記事でわかること

▶ 手順書より先に納品フォルダを見て、要らない手順を見極める方法（今回は Oracle クライアントの導入を外した）
▶ インストーラーのないアプリを Win32 アプリにするスクリプトの中身と、検出の目印の作り方
▶ アンインストールでフォルダを消さないと決めた理由
▶ パイロット1台で確かめたこと・まだ確かめていないこと

▼背景：業務システムだけは、NAS の納品フォルダから手で入れていた

この業務システムは、業者が作ったものが「納品フォルダ」の形で渡されていた。同じ作りのアプリが2本あり、それぞれ別のデータベースにつなぐ。インストーラーはない。

前任の手順書では、新しい PC に入れる作業が8つあった。

#	前任の手順書の作業
1	NAS で最新の納品フォルダを探す
2	2本のフォルダを C:\ 直下にコピーする
3	exe へのショートカットをデスクトップに作る
4	（必要なら）Access Runtime（32ビット）を入れる
5	（必要なら）Oracle クライアントを入れ、Net Manager で接続先を登録し、sqlnet.ora を書き換え、ファイアウォールで許可する
6	Access の「信頼できる場所」に2本のフォルダを登録する
7	確認用の ID でログインし、決まった画面で検索して動作を確かめる
8	利用者の ID を発行してもらう

手順書には「（必要なら）」が多く、どの PC で何が要るのかは書かれていない。

ただ、困っていたのは手作業の多さより、配る元が NAS と前任の手順書にしか無いことだった。この会社は NAS を止める方針で、止めれば納品フォルダの置き場所が無くなる。新入社員の PC をキッティングする機会に、配る元ごと Intune に移すことにした。

▼手順書の8つのうち、Oracle まわりは納品フォルダを見て外した

前任の手順書は、古い版の前提を引きずっていることがある。今の納品物が何に依存しているかは、手順書ではなく中身で判断する。今回見たのは、同梱されているライブラリ（DLL）と、exe の設定ファイル（.exe.config）の2つだ。

同梱の DLL と設定ファイルで、Oracle クライアントの要否が分かる

納品フォルダを開くと、起動する exe は .NET Framework 4.8 のアプリだった。同じフォルダに Oracle.ManagedDataAccess.dll が置かれていた。Oracle が出している .NET 用の接続ライブラリ（ODP.NET）の、Managed Driver と呼ばれる版だ。Oracle が NuGet で配っているこのパッケージの説明には、接続に Oracle クライアントの追加インストールは要らない、と書かれている。

次に設定ファイルを見た。接続先は「TNS の別名」ではなく、ホスト・ポート・サービス名を含む接続記述子がそのまま書かれていた。2本のアプリは同じ名前の exe と同じ接続ライブラリを持ち、接続先のサービス名が違う。tnsnames.ora も sqlnet.ora も、フォルダには入っていなかった。

この2つがそろえば、PC 側に Oracle クライアントを入れる必要も、Net Manager で接続先を登録する必要もない、と見立てた。見るところを表にしておく。「Oracle クライアントが要るか」と「tnsnames.ora が要るか」は別の問いなので、列を分けた。

見るところ	こうなっていたら	Oracle クライアント	tnsnames.ora
同梱の DLL	`Oracle.ManagedDataAccess.dll`（マネージド） ← 今回	不要	下の「接続先」で決まる
同梱の DLL	`Oracle.DataAccess.dll`（非マネージド）	要る（Oracle クライアントのライブラリを読み込む作り）	クライアント側の設定に従う
設定ファイルの接続先	接続記述子（ホスト・ポート・サービス名）か Easy Connect の形で直接書いてある ← 今回	—	不要
設定ファイルの接続先	別名だけ。ただし同じ設定ファイルの `dataSources` に別名と記述子が書いてある	—	不要
設定ファイルの接続先	別名だけで、`dataSources` もない	—	要る（置き場所を `TNS_ADMIN` で示す）。マネージドならファイルを置くだけで、クライアントのインストールは要らない

手順書の Oracle の手順は、今の納品物より前の版に合わせたものだった。sqlnet.ora の書き換え（認証の方式を NTS から NONE に）やファイアウォールの許可が何のためだったのかは、手順書に書かれていない。目的が分からないまま「たぶん要らない」と消すのではなく、今の納品物の中身から要らない理由を言えるかどうかで判断した。言えたのは、上の2つ（Managed Driver と、接続記述子が設定ファイルにあること）がそろっていたからだ。

見立ては見立て。確かめたのは1本目のログインまで

中身から言えるのは「見立て」までだ。確定は、パイロットの1台に入れて起動させてからになる。見立てが外れても、影響はパイロットの1台で止まる。

結果、Oracle クライアントを入れていない PC で起動し、1本目のアプリに確認用の ID でログインして、中身を見られた。1本目については、Oracle クライアントは要らないことが確定した。

2本目は同じ作りで、接続先のサービス名が違う。こちらのログインは、ID の発行待ちでまだ確かめていない。

Access は残る：帳票が Access のファイルだった

削れない前提もあった。帳票は Access のファイル（.accdb）で、Access で開く。だから Access と「信頼できる場所」の設定は今も要る。前任の手順書にも「Windows 11 では信頼できる場所が未設定だと、帳票の印刷でエラーになる」と書かれていた。

手順書の4つ目にあった Access Runtime（32ビット）は、パイロットの PC には入れていない。手順書は Access の32ビット版を前提にしていた。今の PC の Microsoft 365 の Access で帳票が動くかは、印刷と合わせてまだ確かめていない。PC の Office が64ビット版なら、確かめるときに最初に疑うのは、帳票の VBA の Declare 文に PtrSafe が無いとコンパイルエラーになる点だ。

1.3GB のうち 1.1GB は過去のログ。配るものを決めてから包む

納品フォルダの大きさは、2本で 1.2GB と 105MB、合わせて約 1.3GB あった。ところが、そのうち 1.1GB はアプリの中のログのフォルダに溜まった過去のログだった。

ログの中身を除いて（フォルダだけは空で残して）コピーすると、約 220MB になった。それを Win32 アプリとして梱包すると 69MB になった。納品フォルダを「そのまま」包まず、何を配るかを決めてから包む。

▼インストーラーがなくても、コピーとショートカットをスクリプトにすれば Win32 アプリになる

Win32 アプリは「インストーラーを包むもの」と思われがちだが、実際は「スクリプトを包めるもの」だ。手順書の手作業をそのまま PowerShell のスクリプトにして、何度実行しても同じ状態になるように書く。インストールは「システム」として実行する。

梱包（.intunewin）の作り方、32ビットで起動されたときに64ビットで起動し直す処理、ログの置き場所は、同じ会社でプリンターのドライバーを配ったときと同じなので、こちらの記事に任せる。

インストールでやること（検出の目印は自分で作る）

①　2本のフォルダを C:\ 直下にコピーする（robocopy。上書きなので、すでに手で入れた PC のログは残る）
②　一般ユーザー（Users）に、2本のフォルダの変更の権限を付ける（アプリがフォルダの中にログを書くため。C:\ 直下は既定でも一般ユーザーが書ける可能性が高く、この手順が要るかは確かめていない）
③　共通のデスクトップ（Public Desktop）に、2本の exe へのショートカットを置く
④　レジストリ（HKLM）にパッケージの版を書く

④が検出の目印になる。MSI やインストーラーで入れたアプリなら、Windows の「アプリと機能」に名前と版が登録され、Intune はそれで「入っているか」を判定できる。フォルダをコピーしただけのアプリは、どこにも何も登録されない。だから検出の拠り所を自分で作る。

検出のスクリプトは、目印の版・2本の exe・2つのショートカットがすべてそろっていれば「入っている」と返す。版は「納品日＋パッケージの版」の形（例：20250401.1）にした。開発元から新しい納品物が来たら、インストールと検出の両方の版を上げる。検出が外れて、入れ直しが走る。

# 検出スクリプトの骨組み（名前・パスはダミー）
$PackageVersion = ‘20250401.1’   # インストール側と揃える
$MarkerKey      = ‘HKLM:\SOFTWARE\Example\IntunePackages\BizApp’

$marker = Get-ItemProperty -Path $MarkerKey -Name ‘Version’ -ErrorAction SilentlyContinue
if ($marker.Version -ne $PackageVersion) { exit 1 }
foreach ($dir in ‘C:\BizApp1’, ‘C:\BizApp2’) {
    if (-not (Test-Path “$dir\bin\BizApp.exe”)) { exit 1 }
}
foreach ($name in ‘BizApp 1’, ‘BizApp 2’) {
    if (-not (Test-Path (Join-Path “$env:PUBLIC\Desktop” “$name.lnk”))) { exit 1 }
}
Write-Output ‘Detected’
exit 0

アンインストールでフォルダを消さない

アンインストールのスクリプトで消すのは、ショートカットと目印だけにした。C:\ のフォルダは残す。

フォルダの中のログは、利用者の操作の記録だ。Intune の割り当てを外しただけでそれが消えると困る。アンインストールは「元に戻す」ではなく「Intune の管理から外す」と決めて書いた。フォルダを消すかどうかは、人が判断して手で消す。

「信頼できる場所」は Win32 に入れず、設定カタログで配った（効いたかは未検証）

Access の「信頼できる場所」は、利用者ごとの設定（HKCU）だ。一方、インストールのスクリプトは端末に一度走れば終わり、検出が通っている限りもう走らない。あとからその PC にサインインする人の分まで面倒を見られない。そこで、この設定はスクリプトに入れず、設定カタログで配った。

項目	単位	配り方
フォルダのコピー・権限・ショートカット・目印	端末	Win32 アプリ（インストールのスクリプト）
Access の信頼できる場所（2本のフォルダ）	利用者	設定カタログ（Access の「Trusted Location #1・#2」）

設定カタログの Access の項目には「Trusted Location」が #1 から #20 まである。#1 と #2 にそれぞれフォルダのパスを入れ、サブフォルダも許可した。このポリシーは、Win32 アプリと同じ端末のグループに割り当てた。Microsoft Learn には、利用者単位の設定を端末に割り当てると、その端末を使うすべての利用者に適用される、と書かれている。新しい PC は、グループに入れるだけでアプリと設定の両方が来る形になる。

未検証：この設定が効いたかは、まだ確かめていない

効いたかどうかは、帳票を印刷してエラーが出ないかで確かめる。その印刷を、まだやっていない。効かなかったときは、①最初の同期では利用者単位の設定が「適用外」と出ることがある（サインイン後の同期を待つ）、②別のポリシーで「すべての信頼できる場所を無効にする」が有効になっていないか、③そもそも帳票が今の Access で動くか（前の節）、の順に見る。

▼パイロット1台で確かめたこと・まだのこと

パイロットは新入社員の PC の1台だけで行った。「入った」「起動した」で終わらせず、手順書の動作確認のうち、確認用の ID でのログインまでやった。VPN につないだ状態でも、1本目にログインできた（VPN 側の受信量が増え、VPN 経由で DB に届いたことも確かめた）。

確かめていないことは、こうだ。

まだのこと	状態
2本目のログイン	ID の発行待ち
帳票の印刷（信頼できる場所が効いたか、今の Access で帳票が動くか）	未確認。印刷のエラーが出るのは2本目の側なので、2本目の ID が出てから
すでに手で入れた PC への展開	まだ。割り当てはパイロットの1台だけ

▼配る元が NAS から Intune に移った。更新はこう回す

一番の成果は、手作業が減ったことより、配る元が NAS から Intune のパッケージに移ったことだ。NAS を止める計画の障害が、1つ消えた。前任の手順書の8つは、今こうなっている。

前任の手順書の作業	今
NAS で納品フォルダを探す	Intune のパッケージが原本
コピー・ショートカット	Win32 アプリ（グループに入れるだけ）
Access Runtime（32ビット）	入れていない。要るかは帳票の印刷で確かめる
Oracle クライアント・Net Manager・sqlnet.ora・ファイアウォール	不要（1本目のログインで確認）
信頼できる場所	設定カタログ（効いたかは未検証）
動作確認・利用者の ID の発行	残る（ここは人がやる）

開発元から新しい納品物が来たときは、こう回す。

①　新しい納品物から、ログの中身を除いてパッケージの中身を差し替える
②　インストールと検出のスクリプトの版を上げて、梱包し直す
③　Intune の既存のアプリに、新しい版として上げる

このアプリは「必須」で割り当てているので、新しい版を上げれば、すでに入っている PC にも入り直す。同じ日に、勤怠のアプリ（KING OF TIME）も Intune 側の版を上げたが、こちらは「利用可能」の割り当てなので、すでに入っている PC には自動では入らない。

まだ終わっていないこと：パッケージの原本の控えを SharePoint に置く作業は、まだやっていない。原本が Intune の中にしか無いのも、それはそれで一か所に頼っている。控えを置いて、初めて NAS から卒業できる。

▼まとめ

▶ インストーラーがなくても、「コピーしてショートカット」の作りならスクリプトで包めば Win32 アプリになる
▶ 手順書の前提は、納品物の中身（同梱の DLL と設定ファイル）で確かめる。Managed Driver で、接続記述子が設定ファイルにあれば、Oracle クライアントの導入は要らない
▶ 中身から言えるのは見立てまで。パイロットの1台で起動とログインまで確かめて確定させる
▶ 納品フォルダはそのまま包まない。ログを除いて 1.3GB が約 220MB に、梱包して 69MB になった
▶ 検出の目印は自分で作り、更新のたびに版を上げる。アンインストールはフォルダを消さない

📄 同じ会社で、複合機のドライバーを Intune の Win32 アプリにしたときの話（梱包・32/64ビット・検出の詳細）はこちらの記事で書いています。

📄 前任の手順書と今の運用のずれを一覧にしたときの話はこちらの記事で書いています。

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

「業者が納品したフォルダを、手順書どおりに毎回手で入れている。Intune で配れるのか、手順のどこまで削っていいのか判断できない」——そういった段階からお気軽にどうぞ。納品物の中身を見るところから一緒に整理します。

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