Intuneスクリプトと修復設定のトラブルシューティング

Intuneスクリプトと修復設定のトラブルシューティング

Microsoft IntuneにはPowerShellスクリプトをデバイスに展開する方法にはさまざまなものがあり、思いつくだけでもこれだけのものがあります。

・プラットフォームスクリプト
・スクリプトと修復
・アプリとして展開
・(ちょっと用途は違うけど)コンプライアンスポリシー

今日はこの中からスクリプトと修復について話をするのですが、スクリプトと修復そのものについては過去の投稿であったり、安定の山市さん改め山内さんが解説してくれているので、そちらが十分参考になるのではないかと思います。

これらのスクリプトが正しく動作しているうちはほっとけば良いのですがトラブルが起きたら問題解決を図らなければなりません。そこで今回はそのトラブルシューティングのヒントとなるようなトピックをお伝えします。
今回は話を分かりますするためにMS Learnに登録されている修復スクリプトから期限切れの証明書を検出するスクリプトと、修復 (通知) を行うスクリプト(Detect_Expired_Issuer_Certificates.ps1 / Remediate_Expired_Issuer_Certificates.ps1)を実際に登録して話を進めたいと思います。

実行結果の確認

Microsoft Intune管理センターのデバイス > スクリプトと修復 メニューから検出スクリプトと修復スクリプトをそれぞれ登録すると、登録したスクリプトのプロパティから実行状況を確認できます。

この画面ですが、検出スクリプトを実行してexit 0であれば問題なし、exit 1であれば問題ありに分類されてそのまま続けて修復スクリプトを実行するのですが、その結果を見ることができます。
参考までに、ここで登録したスクリプトは前述のDetect_Expired_Issuer_Certificates.ps1ファイルでMS Learnのサイトに記載している内容をコピペしただけの状態なのですが、ご覧のようなスクリプトになっています。

#=============================================================================================================================
#
# Script Name: Detect_Expired_Issuer_Certificates.ps1
# Description: Detect expired certificates issued by "CN=<your CA here>" in either Machine
# or User certificate store
# Notes: Change the value of the variable $strMatch from "CN=<your CA here>" to "CN=..."
# For testing purposes the value of the variable $expiringDays can be changed to a positive integer
# Don't change the $results variable
#
#=============================================================================================================================# Define Variables
$results = @()
$expiringDays = 0
$strMatch = "CN=<your CA here>"</pre>
try
{
$results = @(Get-ChildItem -Path Cert:\LocalMachine\My -Recurse -ExpiringInDays $expiringDays | where {$_.Issuer -match $strMatch})
$results += @(Get-ChildItem -Path Cert:\CurrentUser\My -Recurse -ExpiringInDays $expiringDays | where {$_.Issuer -match $strMatch})
if (($results -ne $null)){
#Below necessary for Intune as of 10/2019 will only remediate Exit Code 1
Write-Host "Match"
Return $results.count
exit 1
}
else{
#No matching certificates, do not remediate
Write-Host "No_Match"
exit 0
}
}
catch{
$errMsg = $_.Exception.Message
Write-Error $errMsg
exit 1
}

この中の14行目以降にある try~ 以降が検出結果を判定しているところで、スクリプトの22,27行目では Write-Host “Match” とか Write-Host “No_Match” と書かれているところがあります。これがスクリプトの実行結果を出力するところになっています。ちなみに30行目にあるcatch~ 以降が “Match” と “No_Match” のどちらにも当てはまらない場合の処理を表しています。このスクリプトではどちらにも当てはまらない場合も exit 1 にしているので修復スクリプトが実行されるようになっています。

話を管理センター画面に戻します。
では出力したものはどこに表示されるかというと、実行結果画面の列ボタンをクリックして、列のカスタマイズ画面から[修復前の検出の出力]と[修復後の検出の出力]にチェックを付けると
Write-Hostで出力した文字列が確認できます。

ログからトラブルシューティングを行う

検出スクリプトと修復スクリプトは実行されるとデバイス側の C:\ProgramData\Microsoft\IntuneManagementExtension\LogsフォルダーのAgentExecutor.log ファイルにその様子がログとして記録されます。
こちらは AgentExecutor.log ファイルから一部を切り取った様子です。

<![LOG[Powershell script is successfully executed.]LOG]!><time=”04:04:00.6703963″ date=”11-3-2025″ component=”AgentExecutor” context=”” type=”1″ thread=”1″ file=””>
<![LOG[write output done. output =
No_Match

ログのこの行では No_Match と書かれていることからスクリプトが問題なしと判定されたことがわかります。ただ、スクリプトと修復設定のどのスクリプトを実行した結果、No_Matchだったのかがログからは判断できないのです。
そこでお勧めなのは MS Learn のサイトからスクリプトをコピペするときは No_Matchなどという名前にするのではなく、どのスクリプトを実行した結果が問題なかったのかを明確になるように書いておくことです。例えばこんな感じ。

Expired_Issuer_Certificates_Not_Found

そうすれば、どのスクリプトを実行した結果、問題がなかったのかがわかりますよね。

どちらの結果にも当てはまらない場合は exit 1 にしない

例えば、あるアプリケーションをインストールして、その結果として特定のフォルダーができるとしましょう。検出スクリプトで
アプリケーションがインストールされている and フォルダーがあることを確認するような設定にした場合、
アプリがインストールされている and フォルダーがあれば exit 0 なので問題なし、
アプリがインストールされている and フォルダーがないということであれば exit 1 なので修復スクリプトへという条件分岐を行うことになります。

ではそもそもアプリケーションがインストールされていなかった場合はどうでしょう?
スクリプトの作り方によってはどちらにも当てはまらない場合があります。
このような場合には catch 以降の処理が実行され、exit 1 になります。
しかし考えてみてください。そもそも特定のアプリケーションがインストールされていないのであれば、フォルダーがないのはある意味、当たり前なのです。
ですからこのような場合には exit 0 になるように構成し、成功したのか、または両方失敗した(どちらにも当てはまらなかった)のかがわかるような条件分岐を作ってあげて、どちらにも当てはまらなかったことがわかるようなメッセージを No_Match の代わりに書いてあげれば良いのです。

おまけ

ログファイルからトラブルシューティングを行うときはc:\ProgramData\Microsoft Intune Management Extension\Logs フォルダー内に格納されている「healthcripts.log」ファイルから詳細が確認できます。これについてはまたの機会に。

参考URL
https://zenn.dev/santafs/articles/82afeefcecdbd8