オンプレADとAzureADのソフトマッチを失敗した場合の対応方法
こんにちは！
最近社内でオンプレADとAzureADのソフトマッチについて聞かれるケースが増えてきました。
そんな時、以下の記事を紹介してたのですが、マッチに失敗したときどうするの？？って聞かれる事がよくあります。
なので、今回は！！
「オンプレADとAzureADのソフトマッチを失敗した場合の対応方法」
について書いていきたいと思います。
- ソフトマッチの失敗でのありがちなケース３つ
- AzureADの管理者権限を持つユーザーのソフトマッチ
- マッチングミスによりAzureADに新たなユーザーが作成される
- マッチングミスによりAzureADの別ユーザーとマッチされる
ありがちなのは上記３つかなって思います。
上記の１，２は比較的すぐに何とかなりますが、３をやってしまうと直すのがめっちゃ大変！！
３の検証には時間がかかるので今回は１，２の対応については手順を記載します。
３は方法の概要だけ説明します。
順番に詳細を記載していきます。
※ここではAzureADConnectを利用した同期について記載しています。
構成はメールアドレス属性でのマッチ＋パスワードハッシュ同期にて検証しています。
１．AzureADの管理者権限を持つユーザーのソフトマッチ
図で言うとこんな状態になっているパターンです。
このケース何がありがちかというと、ソフトマッチのテストをする時って情報システム部のユーザーで先に同期したい！って言われる事が多いんですが、情報システム部のユーザーは管理者権限持ってることが結構あります。
※管理ユーザーと利用ユーザーを分けた方がよいとかは別の話なので一旦おいときます。
そのため、テスト同期するときにこの問題に直面して
あれ・・・同期できないぞ。。。ってなることがあります。
実際起きてしまっても、
１．管理者権限を外す
２．ID同期
３．管理者権限再付与
ってやればいいだけなので、結構簡単です！
※管理者権限を持つ別ユーザーでログインできる状態にしてからやらないと大変なことになります。
図で示すとこんな感じ
権限の変更はMicrosoft365管理ポータル内のユーザー設定から可能です。
また管理者権限を持ったまま同期するとどんなエラーが表示されてどこで確認できるかを記載しておきます。
エラーに限らず同期の詳細を確認するためには
AzureADConnectをインストールした際に一緒に導入される「Synchronization Service」を確認します。
表示された下記画面にてname列がxxx.localでProfileNameがDelta Importという表記になっている赤枠の箇所をクリックすると下の詳細画面が表示されます。
※xxx.localはオンプレADのドメイン名です。
図の下側の赤枠のAddsが1になっていることがわかります。
これは1ユーザー追加で同期したってことを示しています。
情報修正や名前変更、ユーザー削除もここに表示されます。
※本検証では1ユーザーでしかやっていないので1って表示されます。
Addsをクリックすると下図が表示されます。
ここから同期しようとしたユーザーがtesuuserってことがわかります。
testuserっていうユーザー作成したつもりが間違えてた・・・笑
次に実際に同期できたかどうかを確認します。
今度は対象のユーザーがAzureADに同期できたか確認するため
Nameはxxx.onmicrosoft,ProfileNameはExportの箇所を確認します。
すると右下のExport Errorsに情報があることがわかります。
これをクリックするとエラーが発生したユーザーの詳細が確認できます。
Export Errorタブを押すとエラー詳細がでます。
私のPCの解像度の問題で文字がつぶれてしまっていますが。。。。
このようにAzureADにて管理者権限を持つユーザーをソフトマッチしようとすると「Attribute Value Must Be Unique」というエラーが発生します。
２．マッチングミスによりAzureADに新たなユーザーが作成される
このケースはソフトマッチの特性上、オンプレADとAzureADの情報をイコールにしてから同期っていう手順を踏むため、ユーザーによる作業ミス等があると起きます。
下図のイメージです。
オンプレADの情報をAzureADに合わせる形で情報修正した際に、AzureAD上の同期したいユーザーIDと違った標記をしてしまったパターンです。
ここではドメイン名を打ち間違えた想定で記載しています。
同期する際に、オンプレADのユーザーAは誤ってメールアドレスをUserA@testtt.co.jpと入力して同期してしまうと、AzureAD側ではそんなドメインを知らないため、初期ドメイン「xxx.onmicrosoft.com」のユーザーとして作成します。
そのため、UserA@test.onmicrosoft.comというユーザーが作成されてしまうのです。
- 対応方法
この対応方法はAzureADConenctにて特定のOUのみを同期対象としていることが前提です。
ドメイン全体を同期している場合、別の方法の検討が必要です。
- オンプレADにて対象IDを同期対象外OUへ移動する
- Azure ADユーザーが削除済みユーザーへ移動される(同期の機能にて自動)
- Azure AD上にて削除済みユーザーの削除
- オンプレADユーザーの情報を修正し同期対象OUへ移動する(再同期)
この手順にて誤って作成されたUserA@test.onmicrosoft.comを一度削除してから再同期します。
下図のイメージです。
ここではtestshare@xxx.mlというユーザーを同期しようとしたのに、testshare@xxx.onmicrosoft.comというユーザーが作成されてしまったという例で画面ショットをとっています。
下図の通り、誤った同期が確認できます。
※同期の状態の箇所が四角のマークになっているものがオンプレADから同期されたユーザーという意味です。
ちなみにオンプレAD側のユーザーはこんな感じ
これを修正するために一度同期対象外のOUへユーザーをドラッグアンドドロップで移動
はいをクリック
※下記注意の通り、特定のOUのみにGPOを適用していると適用対象外になることもあるので注意ください。
デフォルトだと30分に一度の同期となるため、PowerShellにて以下のコマンドレットを実行し同期を即時実行
SuccessがでたらOK
同期に多少時間かかるので少し待ちます。
※変更量が多いとそれに応じて時間かかります。
ちゃんと同期状況追いかけたい方は上記に記載した「Synchronization Service」から確認してください。
管理センターにて削除済みのユーザーに格納されたことが確認できます。
ここに格納されると30日間は削除済みの状態で保持されます。
最近削除されたユーザーの復元または完全な削除 - Azure AD | Microsoft Docs
ただ、今回はすぐに削除したいのですが、Microsoft365管理センターからは削除できません。
そのため、AzureAD管理センターにうつります。
画面左したのAzureADをクリック
ユーザーをクリック
削除されたユーザーをクリック
対象のユーザーにチェックを入れ、完全に削除をクリックし、はいをクリック
オンプレADの対象ユーザーの情報を正しいものに修正
同期対象のOUへユーザーを移動
再度同期コマンドを実行
Microsoft365管理センターで再度確認すると
今度は正しく同期できていることが確認できました。
よかったよかった
３．マッチングミスによりAzureADの別ユーザーとマッチされる
これが最も修正が大変なケースです。
修正にもかなりの時間がかかるので今回の検証からは外しますが、
Microsoftの案内によると最大72時間かかる処理を実行することになります。
※実績的には1500ユーザーくらいで17時間で終わったこともありますが、、、、
72時間を覚悟する必要があります。
下図のパターンです。
このパターンの場合、AzureAD側のUserBを削除することが難しいので、上記にて記載した２の方法では対応できなくなります。
そのため、ID同期を切る必要があるのですが、ユーザー単位で同期停止ができません。
そのため、AzureADとオンプレADの同期を完全に停止する必要があります。
この行為自体にリスクが伴うので可能な限り避けたい方法です。
同期が停止した後、オンプレADの情報を正しく修正して同期を再度有効化します。
具体的な手順については下記のURLを参考にしてください。
Microsoft 365 のディレクトリ同期をオフにする - Microsoft 365 Enterprise | Microsoft Docs
無効化の処理が終わっているかどうかは以下のコマンドレットで確認
(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled
Falseが返ってきたら無効化されています。
オンプレADでの情報修正後、Set-MsolDirSyncEnabled -EnableDirSync $true
で再度有効化！です。
- まとめ
過去に私がソフトマッチでやらかした記事を書いた通り、ソフトマッチって実際結構大変です。
ユーザーが増えれば増えるほどきついですね。。。
起きてしまったら今回記載したような内容で対応はできますが、、、、
お願いだからMicrosfot365使用開始時にはオンプレADとID同期しといて！！！って言いたい！笑
- 最後に！
Twitterでも情報発信したいと思いますので、興味があったらフォローしてください！
IntuneでWindows10端末にインストールされたアプリケーションを収集し閲覧する(Win32アプリの収集)
こんにちは
先日Intuneを利用してWindows10端末にインストールされたWin32アプリの情報を取得できることを知りました！
ということで今回は
「Intuneを利用してWindows10端末にインストールされたアプリケーション情報を取得」
という部分にチャレンジしてみたいと思います。
- 前提
まずIntuneを利用してWindow10端末の情報を取得するには以下の状態のどれかになっていることが必要です。
- AzureADJoined＋Intune登録
- HybridAzureADJoined+Intune登録
- AzureAD Registered+Intune登録
１，２，３のどれになっているかで取得できる粒度に差が出ます。
また、どれを選択したかによって下記のIntune管理拡張の前提に差がでます！
※３だとほぼ無理！みたいなパターンがあるのでご注意を
また、今回IntuneよりPowershellの実行を実施するため以下も追加で必要です。
・Windows10のエディションがHome以外
・AzureADJoined
※この時点で上記の2,3がだめなんですね・・・笑
2は方法次第でやれそうな気もする・・・・
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2021/4/15追記
上記の3でも稼働しました！
やはり下記URLの前提をちゃんと確認する必要がありそう
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
さらにWin32アプリ(デスクトップにてmsiにてインストールされたアプリケーション)の管理には追加で以下が必要です。
①会社所有のデバイスである
②Intune管理拡張が対象デバイスに導入されている
細かい前提や取得対象はこっちを見てください
検出されたアプリ - Microsoft Intune | Microsoft Docs
今回は
- AzureADJoined＋Intune登録
にて検証を実施しており、Windows10のエディションはProを利用しています。
※サポート範囲外のWindows10はもちろんだめです笑
また、上記の①、②について
①は以下の画面の所有者が会社になっているかどうかということです。
②はIntune管理拡張が導入されている必要があります。
これに非常に悩んだのですが、上記のDocsによると
以下のポイントで自動的に導入されるらしい・・・・・
１．Intune管理拡張機能の前提条件が満たされる
２．Powershellスクリプト or Win32アプリがユーザーやデバイスに割り当てられる
なお１の前提条件っていうのが下記です。※これが結構細かいので確認必須です！
Microsoft Intune で Windows 10 デバイスに PowerShell スクリプトを追加する - Azure | Microsoft Docs
ということなので、今回はPowershellスクリプトをIntuneから実行してIntune管理拡張とやらが入っているか確認してみます。
ちなみに、アプリケーションの収集はサイクルがあって下記くらいの時間がかかる模様！気長にやらないといけない！！！笑
- 設定方法
今回はAzureADJoined＋Intune登録された端末を利用します。
※方法不明だ！！って方いたらコメントください。ご相談のれるかもしれません
まずはMicrosoft365管理センターよりMicorosoft Endpoint Manager管理センターにアクセス
デバイスをクリック
スクリプトをクリック
追加をクリック
Windows10をクリック
配布するスクリプトタスクのタイトルを入力し次へ
※今回はPowershell Test Deployとしています。
今回はTestDeploy.ps1ってファイルを対象にしています。
ちなみに中身はこんな感じ
Cドライブ直下にtemp2ってフォルダを作成するだけ！笑
その他はいいえの状態で次へをクリック
※作成するスクリプトによっては上記の「はい\いいえ」を適切に変えないと問題おきるのでご注意を！
グループを追加をクリック
スクリプトが実行されるべきユーザーがメンバーのグループを選択
※ここで指定するメンバーは以下のデバイス情報の下記ユーザーが含まれているグループです。
グループの追加を確認したら次へをクリック
情報を確認して追加をクリック
これで設定完了
スクリプトが実行されたか確認するには作成されたスクリプトタスクをダブルクリック
各デバイスでの実行状態が表示されます。
- クライアント側での確認方法
クライアントOS側でIntune管理拡張が展開されているか確認してみます。
スタートから設定をクリック
アカウントをクリック
職場または学校にアクセスするをクリックし、接続したアカウントをクリック
情報をクリック
ここでアプリケーションの導入が確認できます！
手動で同期とかしたい場合もこの中の同期ボタンをクリックします。
なお、ディレクトリとしては以下のパスにログファイルが展開されています。
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
- 確認方法
管理ポータルのデバイスから対象のデバイスを選択し「検出されたアプリ」の中に収集されます。Win32アプリは24時間ごとに収集の模様！
※Intune管理拡張が入っていないとモダンアプリ(UWPアプリ)しか表示されないのでご注意を
24時間後に再度確認すると赤枠が増えていた！
Visual C++やPS Remote Play、Windows Deployment Toolsがインストールされていることが確認できます！
WireSharkとかも入れてるんだけど出てこない・・・・一体どういう範囲分けなのだろう？？？
ここは確認できたら情報アップデートします。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2021/4/13追記
確認できた！
msi形式でのインストールは収集の対象だがexeでインストールしたアプリケーションはサポート外とのこと
全部MSIってパターンじゃないと完全には収集できないようだ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- おまけ
Intune管理拡張をダウンロードできないケースにはこんな内容があるらしい！
・デバイスがAuzreADに参加していない(そのほか前提を満たしていない)
・ユーザーまたはデバイスが属するグループにPowershellスクリプトやWin32アプリが割り当てられていない
・デバイスがIntuneサービスにチェックインできない。例えばインターネットアクセスしたりWindowsプッシュ通知サービスにアクセスできない
※プロキシ通さないといけない環境とかは要注意！
おそらくWinInetではなくWinHttpでアクセスしているはずなので、確認が必要！
ここを確認したい場合はスクリプト作成されている方がいるのでぜひ参照を
Test-DeviceRegConnectivity.ps1っていうスクリプトでデバイスからの一部URLへのアクセス可否を参照してくれます！
GitHub - Azure-Samples/TestDeviceRegConnectivity
・デバイスがSモードである(Intune管理拡張はSモード非サポートなんだそうだ！)
また、割り当てたPowershellスクリプト以下のタイミングで稼働するらしい！
②スクリプトを変更し、アップロードし、ユーザーまたはデバイスにそのスクリプトを割り当てるとき
どうやって確認してるのかな～と思って調べたところどうやらIntune管理拡張は対象のWindowsデバイスのサービスとして稼働しているようだ！
↓これね！
このサービスで1時間に1回Intuneでスクリプトやポリシーに変化があったかチェックしているらしい！
※これが手動とかになっていてサービスあがっていないと正しくうごかないことがあるかも！
ちなみにログはC:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.logに出力されています。
下記赤枠を見るとPowershellを実行しているのがわかります。
スクリプト実行自体はagentexecutor.exeが引数に対象のスクリプトを指定して実行しているみたいですね！
ログ見るときは前回記載した通り、CMTraceを利用しています。
下記です。
- まとめ
Windows10デバイスにインストールされたWin32アプリの情報がとれるには取れました。
ただ表示されなかったアプリケーションもいたのでこの辺がよくわからん！
ってことでこのあたりもう少し追いかけて情報アップデートしようと思います。
- 最後に！
Twitterでも情報発信したいと思いますので、興味があったらフォローしてください！
*1:2021/4/13に上記に追記、情報アップデート
IntuneでWindows10端末のどんなログが収集できるか確認
こんにちは
テレワークや社外からの業務が増えたことで社外PCの管理や問題発生時の対応に悩まれているって話をそこそこ耳にします。
社外にいるためWindowsのログ等が見れず対応に困っていたりするケースもあるかと思います。
今回はIntuneにてWindows10端末のログを収集してみたいと思います。
どんなログが参照可能か確認していきます。
- 前提
今回利用するのはAzureADJoined+Intune登録されたWindows10デバイスです。
- 収集方法
Microsoft管理センターよりMicrosoft Endpoint Managerをクリック
表示された画面にてデバイスをクリック
Windowsをクリック
対象のデバイスをクリック
ログの収集ボタンをクリック
完了したらログ取集をクリック
ダウンロードボタンをクリックしてログファイルをダウンロード
ダウンロードしたzipファイルを展開するとこんな感じになっています。
Intune管理拡張のログや
一部イベントログ情報や
NIC系の情報や
バッテリー情報や
その他こんな情報が取得できます。
なお、XMLファイルみるとこんな感じだったので
このあたりの情報を取得していると思われます！
もしIntuneでWindows管理してるよ！！って方は一度試してみると面白いかも！！
- おまけ
取得したログファイルなどを参照するときにみなさんはどんなツールで参照してますか？
僕はCMTraceっていうツールを利用してログ参照しています。
※SystemCenterConfigurationManager(今の名称はMicrosoft EndPoint Configuration Manager)を導入すると同梱されるツールなのですが、単体インストールも可能です。
Download System Center 2012 R2 Configuration Manager Toolkit from Official Microsoft Download Center
ちなみにWindowsupdate.logを参照するとこんな感じ
選択ラインを青表示してくれたり色変えしてくれたりと結構見やすいのでお勧めです！
※僕も友人に勧められて使い始めました
- 最後に！
Twitterでも情報発信したいと思いますので、興味があったらフォローしてください！
