Add device lifecycle action helpers#18
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4c97389381
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Name = $DeviceI.DeviceName # : EVOMONSTER | ||
| Id = $DeviceI.Id # : 83fe122f-c51c-49dc-a0f3-cc11d9e7d045 | ||
| ManagedDeviceId = $DeviceI.Id | ||
| EntraDeviceObjectId = if ($DeviceA) { $DeviceA.Id } else { $null } |
There was a problem hiding this comment.
Get-MyDeviceIntune now emits EntraDeviceObjectId from $DeviceA.Id, but $DeviceA is only populated when -Type or -Synchronized is used earlier in the function. On the default path (Get-MyDeviceIntune with no filters), this property is always $null, so piping those objects into Disable-MyDevice or Remove-MyDevice fails during target resolution even though the new docs say these objects are supported.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ce50e44490
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } catch { | ||
| Write-Warning -Message "Get-MyDeviceIntune - Failed to get Azure device identifiers. Error: $($_.Exception.Message)" | ||
| return |
There was a problem hiding this comment.
The new default path now always calls Get-MgDevice, and this catch block immediately returns from Get-MyDeviceIntune. That means any failure in the Entra lookup step (for example, missing Entra read permissions or a transient Graph error) drops the entire Intune result set even though Get-MgDeviceManagementManagedDevice already succeeded. This is a regression from prior behavior and will break existing callers that only need Intune inventory; the function should degrade gracefully (e.g., keep emitting devices with EntraDeviceObjectId = $null) instead of exiting.
Useful? React with 👍 / 👎.
- keep missing guest sign-in activity distinct from true no-successful-sign-in cases - restore successful sign-in guest fields used by the external account report
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 79dd1dd34d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| if ($null -ne $Guest.SignInActivity) { | ||
| $NeverSignedIn = ($null -eq $LastSignInDaysAgo -and $null -eq $LastNonInteractiveSignInDaysAgo) |
There was a problem hiding this comment.
Get-MyGuest can now classify a user as SignInPattern = 'Successful sign-in only' when only LastSuccessfulSignInDateTime is present, but NeverSignedIn is still computed from interactive/non-interactive fields only. In that case the same record is marked as both having a successful sign-in and NeverSignedIn = $true, which will misclassify active guests in downstream cleanup/reporting logic that filters on NeverSignedIn.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6736b1b84a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if ($Type -or $Synchronized) { | ||
| try { | ||
| if (-not $Script:Devices -or $Force -or $Script:DevicesDate -lt (Get-Date).AddMinutes(-$CacheMinutes)) { | ||
| $DevicesAzure = Get-MgDevice -All -Property 'deviceId,onPremisesSyncEnabled,trustType' -ErrorAction Stop |
There was a problem hiding this comment.
id in filtered Entra lookup
In the -Type / -Synchronized branch, Get-MgDevice is called with -Property 'deviceId,onPremisesSyncEnabled,trustType', but later the output sets EntraDeviceObjectId from $DeviceA.Id. When this branch runs without a warm $Script:Devices cache, the selected payload can omit Id, so filtered Get-MyDeviceIntune results still lose EntraDeviceObjectId and cannot be piped into Disable-MyDevice/Remove-MyDevice. Adding id to this property list avoids that regression on the filtered path.
Useful? React with 👍 / 👎.
1 participant
Summary
EntraDeviceObjectIdandManagedDeviceIdpropertiesWhy
CleanupMonster now has a cloud-device cleanup workflow for AzureAD registered mobile devices. This PR provides the small Graph-facing action layer that workflow depends on, keeping device lifecycle operations reusable and isolated inside GraphEssentials.
Impact
Consumers can now script or reuse these device lifecycle actions directly:
Disable-MyDeviceInvoke-MyDeviceRetireRemove-MyDeviceRemove-MyDeviceIntuneRecordValidation
Invoke-Pester -Path Tests\\MyDeviceLifecycleActions.Tests.ps1 -Output Minimal