`-ExpandProperty` values are more difficult to work with and do not serialize to JSON
Consider this command:
Get-MgUser -All -ExpandProperty Manager | Add-Member -Force -MemberType ScriptProperty -Name Manager -Value {$this.PSBase.Manager['userPrincipalName']} -PassThru | Select -First 1 | ConvertTo-Json
In the JSON that is output, the Manager value will look something like this:
"Manager": {
"DeletedDateTime": null,
"Id": "b279c74f-392b-4f13-a076-3ecbc524e78d"
},
This makes the expansion of the manager property that was done in the Get-MgUser call completely useless, because none of the expanded properties are serializable.
Looking under the covers, it appears that when you get detailed property data for a certain property, such as Manager in this case, the object that conveys the expanded Manager information does so via a dictionary-like approach, but the properties inside the dictionary are not serialized.
My expectation when expanding a property is that I would see much more structured data, such that manager object associated with that property works much more like the user object that it is associated with, with members retrievable via Get-Member, properties accessible the dot-reference operator, and with the object data being serializable in a hierarchical format (i.e. manager properties that are arrays would serialize as such). Without this, the burden in making the data that comes from expanded properties in Graph is pushed on the caller, into every script where they need to do so.
Would you please consider improving this? Even if via an additional common parameter or a setting where someone could indicate that they want the Graph module bundle to work a little harder and make the expanded data a little more normal for easier use within PowerShell? AB#7372
I noticed that in Graph explorer, when I get all users with the Manager property expanded, it gives the overall structure I would expect. I don't understand why you would convert this structure into something that is difficult to work with. If you run https://graph.microsoft.com/beta/users?$expand=manager in Graph Explorer, you'll get back all of the details in an easy to digest structure. Please consider making it easy to browse the data in PowerShell like it is easy to browse it in Graph explorer. i.e. Don't do special type handling that obscures the actual information I need to work with, just give me back the structured object representation of the JSON data instead.
Related to #19
I just came across another issue with these expanded properties. If I invoke Get-MgGroup -ExpandProperty Members, I get back my groups and their members. Looking at the member metadata by dot referencing the Members property, some properties of those members are being filtered out and as a result they are not accessible via PowerShell. Specifically, the id property, but there may be some others. The id property on members is critical because it is the unique key for these objects, but it is not made available to PowerShell at all. I can tell that the ID is received by the REST API behind the scenes though, because it shows up in the $groups.ToJsonString() output. This is also wrong and needs to be corrected.
You should just expose the data returned from Graph as properties. All of the data. No hiding, no trying to be creative. Just make the information that Graph gives you available in an object structure so that we can access all of it by dot referencing properties. Then we can build solutions on top of this module much more easily.
Any update on this? @KirkMunro interesting find on the .ToJsonString(), are there any downsides if you do that and then use ConvertFrom-JSON?
I just came across another issue with these expanded properties. If I invoke
Get-MgGroup -ExpandProperty Members, I get back my groups and their members. Looking at the member metadata by dot referencing theMembersproperty, some properties of those members are being filtered out and as a result they are not accessible via PowerShell. Specifically, theidproperty, but there may be some others. Theidproperty on members is critical because it is the unique key for these objects, but it is not made available to PowerShell at all. I can tell that the ID is received by the REST API behind the scenes though, because it shows up in the$groups.ToJsonString()output. This is also wrong and needs to be corrected.You should just expose the data returned from Graph as properties. All of the data. No hiding, no trying to be creative. Just make the information that Graph gives you available in an object structure so that we can access all of it by dot referencing properties. Then we can build solutions on top of this module much more easily.
Is this being addressed in another bug report or request with a future update/release to MSGraph?
Closing as duplicate of #19.
As a workaround, one can today use $User.Manager.AdditionalProperties on the response object to access additional properties of a user's manager. The properties are not rendered by default because manager is declared as a DirectoryObject (has Id and DeletedDateTime properties) in the metadata - https://github.com/microsoftgraph/msgraph-sdk-dotnet/issues/571. The issue will be addressed in #19.