The isEncrypted with Steve Zissou

The isEncrypted with Steve Zissou

This short blog will be about a question I received on Linkedin. The question was about Graph Explorer and why it wasn’t returning the OMA-URI values configured. It only showed some nice ****

Afbeelding met tekst  Automatisch gegenereerde beschrijving

I will divide this blog into multiple parts

  1. Replicating the Problem
  2. What Happening?
  3. Fixing the Problem
  4. Applicatation VS Delegated Permissions
  5. Microsoft Has fixed the Application Permissions Issues!
  6. I guess Microsoft didnt fix all the Application Permission issues!

1.Replicating the Problem

If we need to fix the problem, we need to experience the problem ourselves. To start replicating the problem I opened the graph explorer first.

Graph Explorer is an excellent tool when you are starting with creating Graph API requests. So the tool can be used when you need to check some settings.

Let’s take a look at what settings are returned when we run this query.

As shown above, the value has some nice **** instead of the real values. So what’s happening?

2. What’s Happening?

When taking another good look at the screenshot above, you could also have noticed another funny setting: “IsEncrypted”: True

Please Note: The Isencrypted and SecretReferencevalueid are only shown in the Beta version and not in the V1.0 of Graph

I guess it’s obvious what “isencrypted” means when it’s configured to 1. If not… the official documentation says the value field is encrypted.

So, Microsoft has suddenly switched the default value of isencrypted to 1 last month? I guess I missed that announcement? But okay, no problem… Encryption is always a good thing. How are we going to decrypt it?

When looking at the outcome of the query, we also noticed the “Secretreferencevalueid” in it.

Okay… So we can use this “id/key” to decrypt the oma settings value. But luckily there is no official documentation to tell us how?

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Looking back at the wonderful history of GitHub commits, I noticed the “isencrypted” and the needed “secretreferencevalueid” appeared in the commit from 14 April

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Okay, but how are we going to get back the URI we need? Fiddler to the rescue! When we need some more information about what happens when we are configuring Intune, we need to use fiddler. If you want to know how it works, please visit this blog.

So how does the URI looks like?

I guess we have everything we need now, let’s create a PowerShell script to get back the values ourselves.

PLEASE NOTE: Uploading new device configuration policies with PowerShell is totally not a problem, as long as you don’t add the “isencrypted” key etc. So when you have a backup of your Intune tenant and the “isencrypted” part is in it, remove it!

Take a look at my GitHub enrollment page for some examples

Enrollment/Windows10_TimeZone.json at main · Call4cloud/Enrollment (

3.Fixing the problem

And the PowerShell script with all the stuff in it, we discussed in this blog. Please test it out yourself but don’t forget to change the device configuration id to your liking

$authResult = Get-MsalToken -ClientId 'd1ddf0e4-d672-4dae-b554-9d5bdfd93547' -Scopes ''
$headers1b = @{
'Authorization'="Bearer " + $authResult.AccessToken

$deviceconfigid = "99b324ca-937e-4494-ac54-b06d889b04e8"

#get the device configuration
$url = "$deviceconfigid"
$deviceconfiguration = Invoke-RestMethod -Uri $url -Headers $headers1b -Method get

#get the secretid needed to unencrypt the data
$secretid = $deviceconfiguration.omasettings.secretReferenceValueId

#parsing the secretid to unencrypt it
$Value = Invoke-restmethod -Headers $headers1b -Method get -uri "$deviceConfigid/getOmaSettingPlainTextValue(secretReferenceValueId='$($secretid)')"
$value | fl

4. Application VS Delegated Permissions

The day after this blog, I received another question about this nice problem: “Why doesn’t it work with an App Registration”

First, we need to know the difference between the script I used and the script that didn’t work. Let’s take a look at the possible Graph Permissions.

So when getting the token with the script I used, you will be using Delegated permissions because I am accessing it by signing in with a username/password and using the Microsoft Intune PowerShell App with the well known d1ddf0e4-d672-4dae-b554-9d5bdfd93547 id.

When you are using this script below, you are “Application Permissions” because it’s doesn’t prompt you to login but uses the clientid and clientsecret to login.

#Define Client Variables Here
$TenantName = "*****"
$clientID = "*****"
$clientSecret = "*******"
$Scope = ""

#Define deviceconfig here
$deviceconfigid = "99b324ca-937e-4494-ac54-b06d889b04e8" 

#Construct Auth call to get Access Token 
$Body = @{
    Grant_Type = "client_credentials"
    Scope = $Scope
    client_Id = $clientID
    Client_Secret = $clientSecret
$authUri = "$TenantName/oauth2/v2.0/token"
$TokenResponse = 
Invoke-RestMethod -Uri $authUri -Method POST -Body $Body
$token = $tokenresponse.Access_token

There normally should be no difference but the Application App PowerShell script will return a (403) Not authorized error when you try to get back the omasettings value.

Looking at it with Fiddler, you will notice a weird not googleable error: UnknownInConvertApiError


So we can assume that running the same script with a token with Delegated permissions works but it fails when running the same script with a token with Application permissions!

So what else can we do? If you want to automate the backup of your Intune tenant and you need to use an App Reg to do it, you could add a user for delegated permissions in the body.

$client_id = "*"
$client_secret = "*"
$tenant_id = "*"
$resource = ""
$authority = "$tenant_id"
$tokenEndpointUri = "$authority/oauth2/token"


$content = "grant_type=password&client_id=$client_id&client_secret=$client_secret&username=$UserForDelegatedPermissions&password=$Password&prompt=admin_consent&resource=$resource";
$response = Invoke-RestMethod -Uri $tokenEndpointUri -Body $content -Method Post -UseBasicParsing
$access_token = $response.access_token

$headers1b = @{
'Authorization'="Bearer " + $Access_token

Hopefully, we can get back a good answer why it isn’t working with Application Permissions… So stay tuned!

5. Microsoft has Fixed the Application Permissions Issue

Yes!!! Microsoft has fixed the problem with the UnknownConvertApiError when you want to return the encrypted oma settings value.

Of course, I did a test run myself… As shown below, it returned the proper values now!

6. I guess Microsoft didn’t fixed all the Application Permissions!

When you are using automation to get the device reports like mentioned in this MS Doc below, you are also going to end up with a nice new error

Use Graph APIs to export Intune Reports | Microsoft Docs

This is the code I used to generate the CSV for the device reports

#get the token
$token = Get-MsalToken -ClientId '*' -ClientSecret (ConvertTo-SecureString '*' -AsPlainText -Force) -TenantId '*' -Scope ''
$headers1b = @{
          'Authorization'="Bearer " + $token.AccessToken

#get the device configuration
$url = ""
$body =
{"reportName":"Devices","filter":"(OwnerType eq '1')","localizationType":"LocalizedValuesAsAdditionalColumn","select":["DeviceName","managementAgent","ownerType","complianceState","OS","OSVersion","LastContact","UPN","DeviceId"]}

$deviceconfiguration = Invoke-RestMethod -Uri $url -Headers $headers1b -Method post -body $body

And the error I got: CustomApiErrorPhrase .

That’s not good at all.. when you need to have the reports generated now, you could use the script I mentioned earlier, to pass a user with credentials for the delegated permissions.


When I need to choose between spending my free evening watching some series or helping someone with a question I didn’t have the answer for? (at that time)

What You're Thinking When Painting | Steve zissou, Giphy, Zissou

I guess you all know what my choice was.

9 thoughts on “The isEncrypted with Steve Zissou

  1. Hey Rudy, thanks again for yesterday.

    I’ve been following what you posted and works perfectly on my Graph Explorer, however I seem to be getting a error when running it on PowerShell (Invoke-restmethod : The remote server returned an error: (403) Forbidden.)

    Which is odd as my App Registration has the same permissions as my Graph Explorer, any idea where I could be daft?

    If needed I can provide my App Registration API Permissions export

    1. That’s odd indeed.. You would expect a app registration could do the same, as it are intune device config policies. Could you show me your API persmissions export? So i can simulate it at my end?

      1. Thanks Rudy, will post the output below. But let me know if you want the export file for easier readability.
        Delegated Microsoft Graph Policy.ReadWrite.ConditionalAccess
        Delegated Microsoft Graph Policy.Read.All
        Delegated Microsoft Graph Agreement.Read.All
        Delegated Microsoft Graph DeviceManagementConfiguration.Read.All
        Delegated Microsoft Graph DeviceManagementConfiguration.ReadWrite.All
        Delegated Microsoft Graph Reports.Read.All
        Delegated Microsoft Graph Directory.Read.All
        Delegated Microsoft Graph Directory.AccessAsUser.All
        Delegated Microsoft Graph Application.Read.All
        Delegated Microsoft Graph ServiceHealth.Read.All
        Application Microsoft Graph Policy.ReadWrite.ConditionalAccess
        Application Microsoft Graph Device.ReadWrite.All
        Application Microsoft Graph Directory.ReadWrite.All
        Application Microsoft Graph ServiceMessage.Read.All
        Application Microsoft Graph Group.ReadWrite.All
        Application Microsoft Graph DeviceManagementServiceConfig.ReadWrite.All
        Application Microsoft Graph Organization.ReadWrite.All
        Application Microsoft Graph DeviceManagementConfiguration.Read.All
        Application Microsoft Graph DeviceManagementManagedDevices.ReadWrite.All
        Application Microsoft Graph Organization.Read.All
        Application Microsoft Graph Policy.Read.All
        Application Microsoft Graph DeviceManagementConfiguration.ReadWrite.All
        Application Microsoft Graph ServiceHealth.Read.All
        Application Microsoft Graph DeviceManagementApps.ReadWrite.All
        Application Microsoft Graph Reports.Read.All
        Application Microsoft Graph DeviceManagementRBAC.ReadWrite.All
        Application Microsoft Graph Policy.ReadWrite.TrustFramework

        1. That’s really odd
          When using a token with delegated permissions it works, when making the exact same graph call using application permissions it will fail with a 403 error…
          And as you are using an App reg… you could guess what’s using…

          1. Thanks for the update Rudy,
            I got a response from Microsoft on this and they gave me the same steps you did (only 3 weeks slower).
            I queried the Application permissions now as I can’t use my Automation Scripts against multiple tenants with Application Authentication 🙂
            Will update if I get an answer before you get one.

    1. The v1.0 Endpoint doesn’t have the isencrypted part, you will need to switch to the beta to see it.
      As mentioned in the blog, uploading a new device policy isn’t an issue as long as you don’t specify those 2 keys.

  2. So I was able to fix my oma file upload in my automation runbooks again!
    After Microsoft came back and said the encryption is not on v1.0 yet, I had a look at my json export and it had x2 lines under each omaURI setting:
    “secretReferenceValueId”: “FullID”,
    “isEncrypted”: true,

    Removed these from a 5000 line json file and it uploaded against my tenants again.
    So I am back up and running with my config baseline again.

    1. Hi that’s totally correct, uploading a new device config isn’t a problem so long you remove those 2 specific lines indeed. Just like I am showing at my githnb page

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  72  =  74