MENU

Microsoft Entra IDの古いデバイスを削除する前に確認すること｜Activityだけで判断しない整理手順

Active Directory

Microsoft Entra IDの「All devices」に長期間使われていないように見えるデバイスが大量に残っていても、Activityの日時だけを根拠に一括削除してはいけません。

Activityに表示される日時は、デバイスの正確な最終操作時刻ではなく、ApproximateLastSignInDateTimeという近似値です。実際に利用中のデバイスでも日時が古かったり、空欄になったりする場合があります。

さらに、Entra IDのデバイス削除は元に戻せません。デバイスオブジェクトに保存されているBitLocker回復キーも失われる可能性があります。そのため、古いデバイスは「候補抽出」「所有者・管理状態の確認」「BitLocker回復キーの保全」「一定期間の無効化」「削除」の順で整理するのが安全です。([Microsoft Learn][1])

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

結論：Activityは削除条件ではなく候補抽出に使う

Microsoft Entra IDで古いデバイスを整理するときは、Activityを次のように扱います。

情報適切な使い方避けるべき判断
Activity調査対象を絞り込む日時が古いという理由だけで削除する
Activityが空欄個別確認の対象にする未使用端末と決めつける
所有者情報利用実態を確認する手掛かりにする所有者欄だけで現利用者を断定する
参加方式削除元とライフサイクルを判断するハイブリッド参加端末をクラウド側だけで削除する
Intune管理状態MDM側の廃止処理が必要か確認するEntra IDの削除を端末廃止処理の代わりにする
BitLocker回復キー削除前に保全状況を確認する未確認のままデバイスオブジェクトを削除する

実務上の重要な考え方は、**Activityが古い端末は「削除対象」ではなく「調査対象」**ということです。

Entra IDのActivityが示している日時

All devicesに表示されるActivityは、Microsoft GraphではApproximateLastSignInDateTimeとして取得できます。

この日時は、端末で最後にマウスやキーボードを操作した時刻や、Windowsに最後にサインインした正確な時刻ではありません。Microsoft Entra IDがデバイスの認証や管理状態を評価した際に更新される、デバイスライフサイクル管理用の近似値です。

Microsoft Learnでは、次のようなタイミングでActivityが評価されると説明されています。

  • 管理対象デバイスなどを要求する条件付きアクセスが動作したとき
  • Microsoft Entra参加またはハイブリッド参加のWindows 10以降がネットワーク上でアクティブになったとき
  • Intune管理デバイスがサービスへチェックインしたとき

既存の日時と現在時刻の差が14日を超えた場合に更新されますが、前後5日程度の幅があります。そのため、数日単位の正確な利用状況を判断する情報には向きません。Microsoft Learnでも、21日未満のActivityを古いデバイスの判断材料にしない例が示されています。([Microsoft Learn][1])

Activityが古くても利用中の場合がある

Activityが古くなる理由は、端末の廃止だけではありません。

たとえば、次のような端末が古いデバイスに見えることがあります。

  • 長期休暇や休職中の利用者に割り当てられている
  • 季節業務や災害対応など、利用時期が限定されている
  • 予備機、共有端末、検証端末として保管されている
  • OS再インストールや再イメージによって新しいオブジェクトが作られた
  • ハイブリッド参加の信頼関係が壊れている
  • 登録が完了せずPending状態になっている
  • IntuneやオンプレミスADでは現在も管理されている

このため、「90日以上Activityが更新されていない」といった条件を設定しても、それだけで削除を確定させることはできません。([Microsoft Learn][1])

Activityが空欄でも未使用とは限らない

ApproximateLastSignInDateTimeが空欄のデバイスもあります。

Microsoft Learnは、アクティブなデバイスでもタイムスタンプが空欄になる場合があると注意しています。したがって、空欄のデバイスを一括して削除候補に含めるのは危険です。空欄は別グループとして抽出し、参加方式、登録日、所有者、Intuneのチェックイン状況などを確認します。([Microsoft Learn][1])

古いデバイスの安全な整理手順

安全な整理は、次の流れで進めます。

  1. Activityから候補を抽出する
  2. 所有者と端末のライフサイクルを確認する
  3. Intune、Autopilot、Universal Printなどの管理状態を確認する
  4. BitLocker回復キーを保全する
  5. デバイスを一定期間無効化する
  6. 問題が発生しなかったデバイスだけを削除する

削除を自動化する前に、この流れを組織の運用ルールとして定めておくことが重要です。

Activityから候補を抽出する

候補の抽出方法は、Microsoft Entra管理センターとMicrosoft Graph PowerShellの2つがあります。

All devicesのActivity列で確認する

少数のデバイスを確認する場合は、Microsoft Entra管理センターのAll devicesでActivity列を確認します。

この段階では削除せず、次の項目を記録します。

確認項目用途
表示名利用者や資産台帳との照合
オブジェクトIDGraph PowerShellでの更新・削除
デバイスID他システムや端末情報との照合
所有者利用状況の確認先
OS廃止対象や例外端末の判定
参加方式Entra参加、登録、ハイブリッド参加の判定
Activity候補抽出の基準
有効・無効猶予期間中かどうかの判定
Intune管理状態MDM側の処理要否
BitLocker確認状況回復キー消失の防止

大量のデバイスがある場合は、CSVへ出力して資産台帳やIntuneの情報と照合したほうが効率的です。

Get-MgDeviceで候補をCSV出力する

Microsoft Graph PowerShellでは、Get-MgDeviceを使ってActivityを取得できます。

次の例は、Activityが90日以上前のデバイスをCSVへ出力する読み取り専用の例です。90日は運用例であり、すべての組織に適用される必須値ではありません。

Connect-MgGraph -Scopes "Device.Read.All"

$cutoffDate = (Get-Date).AddDays(-90)

$properties = @(
    "id"
    "deviceId"
    "displayName"
    "accountEnabled"
    "operatingSystem"
    "operatingSystemVersion"
    "trustType"
    "approximateLastSignInDateTime"
)

$allDevices = Get-MgDevice -All -Property $properties

$staleCandidates = $allDevices |
    Where-Object {
        $null -ne $_.ApproximateLastSignInDateTime -and
        $_.ApproximateLastSignInDateTime -le $cutoffDate
    } |
    Select-Object `
        Id,
        DeviceId,
        DisplayName,
        AccountEnabled,
        OperatingSystem,
        OperatingSystemVersion,
        TrustType,
        ApproximateLastSignInDateTime |
    Sort-Object ApproximateLastSignInDateTime

$staleCandidates |
    Export-Csv `
        ".\entra-stale-device-candidates.csv" `
        -NoTypeInformation `
        -Encoding UTF8

Get-MgDeviceは-Allで全ページを取得でき、-Propertyで必要なプロパティを指定できます。読み取りの委任アクセス許可としてはDevice.Read.Allが案内されています。([Microsoft Learn][2])

このスクリプトでは、Activityが空欄のデバイスを意図的に除外しています。空欄のデバイスは、次のように別ファイルへ出力して確認します。

$allDevices |
    Where-Object {
        $null -eq $_.ApproximateLastSignInDateTime
    } |
    Select-Object `
        Id,
        DeviceId,
        DisplayName,
        AccountEnabled,
        OperatingSystem,
        OperatingSystemVersion,
        TrustType |
    Export-Csv `
        ".\entra-device-blank-activity.csv" `
        -NoTypeInformation `
        -Encoding UTF8

IdとDeviceIdを取り違えない

Microsoft Graphのデバイスには、IdとDeviceIdがあります。

Update-MgDeviceやRemove-MgDeviceの-DeviceIdパラメーターには、Microsoft Learnの例ではデバイスオブジェクトのIdを渡しています。CSVを作成するときは両方を残し、削除処理で取り違えないようにします。([Microsoft Learn][1])

削除候補ごとに確認する項目

Activityで候補を抽出した後は、端末のライフサイクルを確認します。

確認項目削除前に確認する内容
所有者・利用者在職中か、休暇・休職中ではないか
資産台帳廃棄、返却、紛失、予備機などの状態
端末名同じ端末名の重複オブジェクトがないか
再構築履歴OS再インストールや再イメージを実施していないか
参加方式Entra参加、Entra登録、ハイブリッド参加のどれか
登録状態Pendingや登録失敗のオブジェクトではないか
Intune現在もチェックインしていないか
オンプレミスADコンピューターオブジェクトが残っていないか
Autopilot再展開対象として登録されていないか
Universal Printプリンター管理に使用されていないか
BitLocker必要な回復キーが保全済みか
業務用途共有、予備、季節利用、緊急用ではないか

所有者欄だけに頼るのも危険です。異動や端末交換後に所有者情報が更新されていない場合があるため、資産台帳、Intune、利用部門への確認を組み合わせます。

BitLocker回復キーを削除前に保全する

Microsoft Entra IDにBitLocker回復キーが保存されている環境では、デバイスオブジェクトを削除すると、そのオブジェクトに関連付けられた回復キーも失われます。削除後に回復キーを復元することはできません。([Microsoft Learn][1])

削除前に、少なくとも次のどちらかを確認します。

  • 回復キーが組織の承認済みの保管先にバックアップされている
  • デバイスが廃棄済みであり、回復キーが今後不要である

候補一覧のCSVに回復キーそのものを書き出すのは避けます。CSVには「回復キー保全済み」「不要確認済み」といった確認結果だけを記録し、回復キーはアクセス制御された保管先で管理します。

Intune管理端末は管理側で先に廃止する

IntuneやほかのMDMで管理されているデバイスは、Entra IDから先に削除するのではなく、MDM側で廃止手続きを行います。

Microsoft Learnでは、MDM管理デバイスを無効化または削除する前に、管理システム側でリタイアするよう案内しています。端末の返却、再利用、紛失など、状況に応じてリタイアやワイプなどの処理を選びます。([Microsoft Learn][1])

Entra IDのデバイス削除とIntuneのワイプは、目的が異なります。

操作主な目的
Entra IDから削除デバイスIDオブジェクトをディレクトリから削除する
デバイスを無効化デバイスIDを使った認証を拒否する
IntuneでリタイアMDM管理から端末を廃止する
Intuneでワイプ端末を初期化し、データや設定を削除する

Entra IDからデバイスを削除しても、端末内のデータが消去されるわけではありません。端末を初期化する必要がある場合は、Intuneなどの管理機能で適切な操作を行います。IntuneのWipeは、対応端末を工場出荷時の状態へ戻し、データ、アプリ、構成を削除するための操作です。([Microsoft Learn][3])

AutopilotやUniversal Printを一律削除しない

Windows Autopilotに関連付けられたデバイスや、Universal Printなどで管理されるデバイスは、通常の古いデバイスと同じ条件で一括削除してはいけません。

特にAutopilot関連のEntraデバイスを削除すると、将来の再展開時にAutopilotのプロビジョニングが失敗する可能性があります。Microsoft Learnでは、システム管理デバイスを削除対象から除外し、それぞれの管理ポータルで整理するよう案内しています。([Microsoft Learn][1])

大量削除を行う場合は、最低でも次の対象を除外します。

  • Windows Autopilotに登録されているデバイス
  • Universal Printで使用されるデバイス
  • IntuneなどのMDMで現在も管理中のデバイス
  • オンプレミスADから同期されているハイブリッド参加デバイス
  • Activityが空欄のデバイス
  • 所有者や用途を確認できないデバイス

削除前に一定期間無効化する

調査の結果、利用されていない可能性が高いデバイスでも、すぐに削除するのではなく、最初に無効化します。

無効化したデバイスは、デバイスIDを使ったMicrosoft Entra IDへの認証が拒否されます。影響は参加方式によって異なります。

デバイスの種類無効化後に想定される影響
Microsoft Entra参加利用者がそのデバイスへサインインできなくなる可能性がある
ハイブリッド参加オンプレミスドメインへのサインインはできても、Microsoft 365などのEntraリソースへアクセスできなくなる
モバイルデバイスMicrosoft 365などのEntraリソースへアクセスできなくなる

無効化は単なる「削除予定」の印ではなく、実際にアクセスへ影響する操作です。実施前に利用部門とヘルプデスクへ周知し、問い合わせが発生した場合に復旧できる体制を用意します。([Microsoft Learn][1])

猶予期間の決め方

猶予期間は組織ごとに決めます。

たとえば、次のような運用が考えられます。

段階運用例
候補抽出Activityが90日以上前
事前確認所有者、資産台帳、Intune、BitLockerを確認
無効化確認済みのデバイスだけを無効化
猶予期間30日間、問い合わせや再利用がないか確認
削除無効のまま問題が発生しなかったデバイスを削除

Microsoft Learnのサンプルでも、90日以上前のデバイスを抽出し、無効化したうえで、120日以上前の無効なデバイスを削除する流れが示されています。ただし、90日や120日は必須の基準ではありません。長期休暇、季節業務、予備端末の保管期間などを考慮して決定します。([Microsoft Learn][1])

PowerShellで無効化する場合

無効化にはUpdate-MgDeviceを使用します。

次の例では、-WhatIfを付けて、実際には変更せず処理対象を確認します。

$params = @{
    accountEnabled = $false
}

Update-MgDevice `
    -DeviceId $device.Id `
    -BodyParameter $params `
    -WhatIf

対象が正しいことを確認した後、承認済みの変更作業として-WhatIfを外して実行します。

accountEnabledの更新には管理権限が必要です。Microsoft Learnでは、古いデバイスの整理に使用するアカウントとしてCloud Device Administratorなどの必要なロールを持つアカウントを使用するよう案内しています。([Microsoft Learn][1])

参加方式によって削除場所を変える

デバイスの削除方法は、Microsoft Entra IDへの参加方式によって異なります。

Microsoft Entra参加デバイス

Microsoft Entra参加デバイスは、Microsoft Entra ID側で無効化または削除します。

ただし、Entra IDのデバイスオブジェクトを削除しても、クライアント側の参加状態が自動的に解除されるわけではありません。デバイスIDを使ったリソースアクセスができなくなるため、端末側の参加解除や再登録が必要になる場合があります。([Microsoft Learn][1])

Microsoft Entra登録デバイス

Microsoft Entra登録デバイスも、Microsoft Entra ID側で無効化または削除します。

こちらも、クラウド側のオブジェクト削除だけではクライアント側の登録が自動的に消えるわけではありません。BYOD端末などでは、利用者側で職場または学校アカウントの登録解除が必要になる場合があります。([Microsoft Learn][1])

Microsoft Entraハイブリッド参加デバイス

ハイブリッド参加デバイスは、原則としてオンプレミスADのデバイスライフサイクルに合わせて管理します。

Windows 10以降のハイブリッド参加デバイスは、オンプレミスAD側で無効化または削除し、Microsoft Entra Connectによる同期でクラウド側へ反映させます。

クラウド側だけで削除すると、オンプレミスADから再同期され、新しいオブジェクトがPending状態で作成されることがあります。その場合、端末側で再登録が必要になります。([Microsoft Learn][1])

古いWindows 7やWindows 8が残る環境では、オンプレミスADで処理した後、Microsoft Entra ID側でも個別に無効化または削除が必要になる場合があります。

削除は無効化済みの承認対象だけに限定する

猶予期間が終了したら、次の条件をすべて満たすデバイスだけを削除します。

  1. 所有者または管理部門へ確認済み
  2. 資産台帳上も廃止、廃棄、紛失などの状態
  3. IntuneやほかのMDMで廃止処理済み
  4. AutopilotやUniversal Printの対象ではない
  5. BitLocker回復キーを保全済み、または不要確認済み
  6. ハイブリッド参加ではオンプレミスAD側の処理済み
  7. 組織で定めた期間、無効化しても問題が発生していない
  8. 削除対象として承認記録が残っている

Remove-MgDeviceは事前確認を付けて実行する

Remove-MgDeviceによる削除は元に戻せません。Microsoft Learnの古いデバイス管理ガイドでは、通常の実行では警告なしに削除され、削除したデバイスを復元できないと注意しています。([Microsoft Learn][1])

最初は-WhatIfで対象を確認します。

Remove-MgDevice `
    -DeviceId $device.Id `
    -WhatIf

確認後に実行する場合は、-Confirmを明示して確認プロンプトを表示できます。

Remove-MgDevice `
    -DeviceId $device.Id `
    -Confirm

Remove-MgDeviceは-WhatIfと-Confirmをサポートしています。ただし、コマンドのオプションだけに頼らず、承認済みCSVなどの明示的な対象リストを使うほうが安全です。([Microsoft Learn][4])

一括削除で避けるべき処理

次のように、Activity条件から直接Remove-MgDeviceへ渡す処理は避けます。

# このような直接削除は避ける
Get-MgDevice -All |
    Where-Object {
        $_.ApproximateLastSignInDateTime -le (Get-Date).AddDays(-90)
    } |
    ForEach-Object {
        Remove-MgDevice -DeviceId $_.Id
    }

この処理には、次の問題があります。

  • Activityの近似値だけで削除している
  • Activityが空欄の扱いが明確でない
  • 所有者確認を行っていない
  • IntuneやAutopilotの対象を除外していない
  • BitLocker回復キーを確認していない
  • ハイブリッド参加デバイスを区別していない
  • 無効化と猶予期間を挟んでいない
  • 削除対象の承認記録が残らない

自動化する場合も、候補抽出と削除を別の処理に分けます。

最初の処理では候補CSVを作成するだけにし、人による確認と承認を経た後、承認済みオブジェクトIDだけを無効化します。さらに猶予期間後、無効化済みであることを再確認してから削除します。

削除記録に残しておく項目

誤削除の防止と問い合わせ対応のため、削除記録には次の項目を残します。

記録項目内容
デバイス表示名対象端末を識別する名称
オブジェクトID実際に処理したEntraデバイスオブジェクト
デバイスID資産台帳や端末情報との照合用
参加方式Entra参加、登録、ハイブリッド参加
最終Activity候補抽出時の日時
所有者・部門確認先
廃止理由廃棄、交換、重複、紛失など
MDM処理リタイアやワイプの実施状況
BitLocker確認保全済み、不要確認済みなど
無効化日時猶予期間の開始日
削除承認者最終判断を行った担当者
削除日時実際の処理日時

回復キーや個人情報そのものは記録ファイルへ直接保存せず、確認結果と保管先の管理番号だけを残します。

Activityだけで削除せず、無効化期間を挟んで整理する

Microsoft Entra IDのActivityは、古いデバイスを見つけるためには便利ですが、正確な最終利用日時ではありません。

安全に整理するには、次の順序で進めます。

  1. All devicesまたはGet-MgDeviceで候補を抽出する
  2. Activityが空欄のデバイスは別に確認する
  3. 所有者、資産台帳、再構築履歴、参加方式を確認する
  4. Intune、Autopilot、Universal Printの対象を除外または管理側で処理する
  5. BitLocker回復キーを保全する
  6. 候補を一定期間無効化する
  7. 問題が発生しなかった承認済みデバイスだけを削除する

最初に行うべき作業は削除ではなく、読み取り専用の候補一覧を作成することです。候補一覧に所有者確認、MDM処理、BitLocker確認、無効化日時の列を追加し、組織のデバイス廃止フローとして運用すると、誤削除を防ぎながら古いデバイスを継続的に整理できます。
[1]: https://learn.microsoft.com/en-us/entra/identity/devices/manage-stale-devices “How to manage stale devices in Microsoft Entra ID – Microsoft Entra ID | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.identity.directorymanagement/get-mgdevice “Get-MgDevice (Microsoft.Graph.Identity.DirectoryManagement) | Microsoft Learn”
[3]: https://learn.microsoft.com/en-us/mem/intune/remote-actions/devices-wipe “Wipe devices with Microsoft Intune – Microsoft Intune | Microsoft Learn”
[4]: https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.identity.directorymanagement/remove-mgdevice “Remove-MgDevice (Microsoft.Graph.Identity.DirectoryManagement) | Microsoft Learn”

Active Directory
BitLocker デバイス管理 Microsoft Entra ID Microsoft Graph PowerShell

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次