Get-EntraDirectoryObjectOnPremisesProvisioningError output is very poor and not actionable #1290
Comments
|
Hi @NuAlex, thank you so much for your feedback! We’ll prioritize improving this command and will tag you for review/testing. PS: We appreciate the clarity and detailed framing of the issue. |
|
This is a great point about usability of the function's output, and it also raises some important questions about the design of PowerShell modules and functions. How much work should one function do, and what data is available in the Graph API? Updating the script to provide rich object output is fairly simple with something like this: end {
if ([string]::IsNullOrWhiteSpace($response)) {
Write-Output 'False'
} else {
$Results = New-Object -TypeName System.Collections.Generic.List[PSObject]
foreach ($item in $response) {
$Results.Add(
[PSCustomObject]@{
Category = $item.category
Value = $item.Value
OccurredDateTime = $item.OccurredDateTime
PropertyCausingError = $item.PropertyCausingError
}
)
}
$Results
}
}And with the function's OutputType attribute changed to I agree 100% with the intent of wanting to make it easier to identify the object that the provisioning error was found on. However, it may be worth creating that functionality in a new, separate function. The current function is relatively simple because it does one thing and pulls a specific resource type: onPremisesProvisioningError. This Graph resource type only includes the four properties already included in the output: category, value, occuredDateTime, and PropertyCausingError (see Microsoft Learn: onPremisesProvisioningError resource type It would be extremely useful to create a new function that takes the output of this one and maps the found value/property to any items that have that value. Did the |
Describe the bug
Summary
The Get-EntraDirectoryObjectOnPremisesProvisioningError outputs an array of hashtables with insufficient information.
There are 4 main issues with the output of this cmdlet:
Description
When there's multiple objects with OnPremisesProvisioningError, it's hard to understand where each object starts and ends since the output is an array of hashtables with a Name/Value header, instead of an array of objects with columns separating each property.
For example:
The output is missing objects. On my case the
Get-EntraDirectoryObjectOnPremisesProvisioningErroris returning 7 entries whileGet-MsolDirSyncProvisioningErrorreturns 10 objects. (see my output from the legacy MSOL module at the end of this text).The output does not include any identifier of what is the Entra ID object holding the OnPremisesProvisioningError. This leaves up to the user to go find out which object have these conflicts based on the conflict value. On top of the hassle of try searching for the object with the value in conflict (which could be in UPN or ProxyAddresses attributes of a user, group or contact), this will only return the user currently owning that value and will not be possible to determine what is the other object causing the conflict since that object's value is "quarantined" (automatically removed to prevent the conflict), i.e. the conflicting object does not have that value so it's not possible to search for it.
So, this cmdlet must also output the ObjectID and UserPrincipalName of the directory object that contains each OnPremisesProvisioningError, similarly to what existed in the legacy MSOL module (see my output from the legacy MSOL module at the end of this text).
As an IT Pro I would expect to see some parameters in the cmdlet similar to what was available on the legacy MSOL module. The main ones would be:
-ErrorCategory The error category that needs to be searched.
-PropertyName The property whose conflicts will be searched.
-PropertyValue The property value on which conflicts will be searched.
-SearchString The search string to be used in the search. Only objects with DirSyncProvisioningErrors due to a PropertyConflict returned from a search on this string will be returned.
Note: ok, this one might be nit picking because we can achieve the same filtering by pipelining the results to Select-Object, but having these parameters can help in terms of usability, backward compatibility and it's a more efficient service-side query.
To Reproduce
Steps to reproduce the behavior:
Import-Module -Name Microsoft.Graph.Entra.BetaConnect-Entra -Scopes 'User.Read.All', 'Directory.Read.All', 'Group.Read.All', 'Contacts.Read'Get-EntraDirectoryObjectOnPremisesProvisioningErrorExpected behavior
The expected output (like any other normal PowerShell cmdlet) would be an array of objects, plus the identifiers of each object line ObjectId and UPN:
For example (mock output):
Debug Output
Module Version
Environment Data
Screenshots
Additional context
Please compare with the output from the legacy module MSOnline module:
The text was updated successfully, but these errors were encountered: