Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BitLockerRecoveryKey VolumeType Conversion from https request wrong #848

Open
kronsteinerPT opened this issue Jun 3, 2024 · 4 comments
Open
Labels
Bug: metadata type:bug A broken experience

Comments

@kronsteinerPT
Copy link

Describe the bug

Im trying to get all BitlockerRecoveryKey objects via Graph API using the GraphServiceClient library in the newest beta version 5.77.0-preview.
This is my request:
var allBitlockerRecoveryKeys = await GraphClient.InformationProtection.Bitlocker.RecoveryKeys.GetAsync(requestConfiguration => { requestConfiguration.Headers.Add("User-Agent", "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36"); });

This is one of the results:
image

The Volume Type is "FixedDataVolume" in every Result which is strange in itself but ok.
But if I now look at the same deviceId in Azure via my browser, the Volume Type is "Operating system drive".
image

Also if i go through the http data that my own GraphClient gets i get the Volume Type "1" (which stands for Operating System Drive according to the docu)

But somehow if it goes through the type from Microsoft.Graph.Beta.Models it gets converted to the wrong type.

Expected behavior

The VolumeType should convert the json data from the http request result to the correct value.
volumeType=1 => operatingSystemVolume
volumeType=2 => fixedDataVolume
...

How to reproduce

NuGet Package Microsoft.Graph.Beta 5.77.0-preview
Functioning and Authenticated GraphClient
Execute
var allBitlockerRecoveryKeys = await GraphClient.InformationProtection.Bitlocker.RecoveryKeys.GetAsync(requestConfiguration =>
{
requestConfiguration.Headers.Add("User-Agent", "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36");
});

SDK Version

5.77.0-preview

Latest version known to work for scenario above?

No response

Known Workarounds

Workaround is to just use a normal http request without GraphServiceClient Library

Debug output

Click to expand log ```
</details>


### Configuration

Windows 11, x64
Nothing Special. Using Visual Studio 22
net6.0

### Other information

_No response_
@kronsteinerPT kronsteinerPT added status:waiting-for-triage An issue that is yet to be reviewed or assigned type:bug A broken experience labels Jun 3, 2024
@andrueastman
Copy link
Member

Thanks for raising this @kronsteinerPT

Are you by any chance able to make the same the request using the Graph Explorer and view the json response value? It would be helpful to identify from the json response if the value returned by the API is correct to narrow this down to a deserialization error.

@andrueastman andrueastman added status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close and removed status:waiting-for-triage An issue that is yet to be reviewed or assigned labels Jun 4, 2024
@kronsteinerPT
Copy link
Author

Yes the Json from the API is correct.
I get VolumeType : "1" as a response from every device
image

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs: Attention 👋 and removed status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close labels Jun 5, 2024
Copy link
Contributor

No description provided.

@andrueastman
Copy link
Member

The generated SDK has the member names as the string representations while the API is returning number values.

[EnumMember(Value = "operatingSystemVolume")]

We'll need to follow this up with the metadata to get a picture of what the expecatation is here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug: metadata type:bug A broken experience
Projects
None yet
Development

No branches or pull requests

2 participants