Tech Community Live: Microsoft Intune
Jun 22 2023, 07:30 AM - 11:30 AM (PDT)
Microsoft Tech Community

Get-IntuneDeviceConfigurationPolicy returns only some of my policies

Regular Contributor

FYI: I also opened an issue on the GitHub repo for the module


When I run Get-IntuneDeviceConfigurationPolicy, I'm getting 5 device configuration policies back, but I actually have 10:

>Get-IntuneDeviceConfigurationPolicy |select displayName

Android Enterprise - Work profile
Essential Settings
Wi-Fi - Android Enterprise - Work profile

Device Configuration Profiles (GUI)Device Configuration Profiles (GUI)

It's the same behavior when I use MS Graph directly without the Microsoft.Graph.Intune module:

>New-MSGraphRequest -AccessToken $NT -Request /deviceManagement/deviceConfigurations |select -ExpandProperty Value |select displayName                                                           
Android Enterprise - Work profile
Essential Settings
Wi-Fi - Android Enterprise - Work profile

All 10 device configuration policies are assigned, and have settings configured etc. (obviously I suppose), so I can't seem to figure out what's up with this.


I get no results back for many of the cmdlets, for example there is no sign of my App Configuration policies for Managed Devices; only policies for Managed Apps come back. So it feels like I'm missing something big here, but it's not jumping out at me.  Is there any kind of known issue that makes MS Graph unable to see certain items in Intune?


I am using the same account to login to as I am when obtaining the access token in PowerShell (i.e. Connect-MSGraph, when using the module).


Thanks in advance.

9 Replies

@Jan Bakker  Thanks for the idea, and I just checked/confirmed that indeed it's the same behavior in Graph Explorer.  This is logged into Graph Explorer as the same user described in the first post, and having added the permission DeviceManagementConfiguration.Read.All (and DeviceManagementConfiguration.ReadWrite.All which got added automatically, so I consented to it too, just as a hail-mary).  Still just getting the usual 5 policies back in the results:



    "@odata.context": "$metadata#deviceManagement/deviceConfigurations(displayName)",
    "value": [
            "@odata.type": "#microsoft.graph.androidWorkProfileGeneralDeviceConfiguration",
            "displayName": "Android Enterprise - Work profile"
            "@odata.type": "#microsoft.graph.windows10EndpointProtectionConfiguration",
            "displayName": "Bitlocker"
            "@odata.type": "#microsoft.graph.windowsUpdateForBusinessConfiguration",
            "displayName": "Broad"
            "@odata.type": "#microsoft.graph.windows10CustomConfiguration",
            "displayName": "Essential Settings"
            "@odata.type": "#microsoft.graph.androidWorkProfileCustomConfiguration",
            "displayName": "Wi-Fi - Android Enterprise - Work profile"


 So strange.  There's nothing consistent about these 5 policies which do return either.  Some are old, some relatively new, they're of different types, and of the types they are, I have other policies of the same type which do not return.  But these 5 are consistently the only ones returned.

@Jeremy Bradshaw did you ever find a solution to this? I am having the same issue.

@jhl_2012 I hadn't tried in some time but just did now to check.  I still have the same problem indeed.  Strangely, I now get 8 profiles back with this:


[PS]> $devConfigs = New-MSGraphRequest -AccessToken $RT -Request devicemanagement/deviceConfigurations

[PS]> $devConfigs.value.Count

[PS]> $devConfigs.value.displayName
Android Enterprise - Work profile
DU - Windows 10 Device Restrictions
Essential Settings
Local Administrators (Windows 10 20H2 and newer)
Wi-Fi - Android Enterprise - Work profile
Windows 10 Home > Education


But in reality there are 16 profiles in my Intune tenant, 12 for "Windows 10 and later", 4 for "Android Enterprise".  The list of 8 that I get back are a mix from both.  In other words, the issue itself is inconsistent, and the results that are given back have no common trait that makes sense of why these 8.


Being that I use MS Graph a lot for other things and never have this kind of issue, I'm thinking the Intune underlying API that MS Graph interfaces directly with is where the problem likely lies.  I don't have a support-enabled tenant available where I can get official support for this unfortunately.  So I just forget about it and consider Intune broken in this regard.  Many things in Intune simply don't work in similar mysterious fashion (**bleep** you Intune!:face_with_tears_of_joy:).

@Jeremy Bradshaw 


It depends on what you want to know... If you are launching this command:
Get-IntuneDeviceConfigurationPolicy |select displayName


You will get back your and of course its missing the administrative templates




When you want to get them back you should query the





The same with the settings catalog that would be


But I must agree it's missing some other stuff :)  Like identity protection device configuration profiles... I am going to take a good look why they are not  showing



best response confirmed by Jeremy Bradshaw (Regular Contributor)

What happens when you run this script? It shows me the stuff the other command didn't showed me

#oauth token
$clientId = "d1ddf0e4-d672-4dae-b554-9d5bdfd93547"
$redirectUri = "urn:ietf:wg:oauth:2.0:oob"
$resourceURI = ""
$authority = ""
$AadModule = Import-Module -Name AzureAD -ErrorAction Stop -PassThru
$adal = Join-Path $AadModule.ModuleBase "Microsoft.IdentityModel.Clients.ActiveDirectory.dll"
$adalforms = Join-Path $AadModule.ModuleBase "Microsoft.IdentityModel.Clients.ActiveDirectory.Platform.dll"
[System.Reflection.Assembly]::LoadFrom($adal) | Out-Null
[System.Reflection.Assembly]::LoadFrom($adalforms) | Out-Null
$authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" -ArgumentList $authority
$platformParameters = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.PlatformParameters" -ArgumentList "Always"
$authResult = $authContext.AcquireTokenAsync($resourceURI, $ClientID, $RedirectUri, $platformParameters)
$accessToken = $authResult.result.AccessToken

$apiUrl = ''

$Data = Invoke-RestMethod -Headers @{Authorization = "Bearer $($authResult.result.AccessToken)"} -Uri $apiUrl -Method get



THe script I posted is connecting to the beta and shows it all, but the msgraph is connecting to the v1.0 




So if you want the get-intunedeviceconfiguraitonpolicy to connect to the beta:


Update-MSGraphEnvironment -SchemaVersion beta




@Rudy_Ooms_MVP Good catch - when I target the Beta endpoint, I get all 16 device configuration profiles back.  I didn't use your script but instead used my New-MSGraphRequest and add -Endpoint Beta to it:


> $devConfigs = New-MSGraphRequest -AccessToken $RT -Request devicemanagement/deviceConfigurations -Endpoint beta

> $devConfigs.value.Count


All 16, which as an FYI are of many different types, but are all showing in Devices > Device Configuration Profiles in MEM, so I assumed they should all come back when requesting to /devicemanagement/deviceConfiguration.  When I was reading your first bit, I was thinking you were onto something with having to send separate requests for each of the different types' resources (e.g., .../deviceConfigurations, .../groupPolicyConfigurations, etc.).  But since all types come back from just .../deviceConfigurations when using the Beta endpoint, I guess I'm back to assuming that it should (eventually at least) work on v1.0 too.


Here are all 16 of my profiles as returned from Beta (see all the different types):

> $devConfigs.value |select displayName, '@odata.type'

displayName                                      @odata.type
-----------                                      -----------
10 Pacer Ave                                     #microsoft.graph.androidDeviceOwnerWiFiConfiguration
Android Enterprise - Work profile                #microsoft.graph.androidWorkProfileGeneralDeviceConfiguration
Android Enterprise (Corporate)                   #microsoft.graph.androidDeviceOwnerGeneralDeviceConfiguration
Autopilot Domain Join                            #microsoft.graph.windowsDomainJoinConfiguration
Bitlocker                                        #microsoft.graph.windows10EndpointProtectionConfiguration
Broad                                            #microsoft.graph.windowsUpdateForBusinessConfiguration
DU - Windows 10 - VPN (Cisco AnyConnect)         #microsoft.graph.windows10VpnConfiguration
DU - Windows 10 Delivery Optimization            #microsoft.graph.windowsDeliveryOptimizationConfiguration
DU - Windows 10 Device Restrictions              #microsoft.graph.windows10GeneralConfiguration
Essential Settings                               #microsoft.graph.windows10CustomConfiguration
Intune data collection policy                    #microsoft.graph.windowsHealthMonitoringConfiguration
Local Administrators (Windows 10 20H2 and newer) #microsoft.graph.windows10CustomConfiguration
Wi-Fi - Android Enterprise - Work profile        #microsoft.graph.androidWorkProfileCustomConfiguration
Wi-Fi - Windows 10                               #microsoft.graph.windowsWifiConfiguration
Windows 10 Home > Education                      #microsoft.graph.editionUpgradeConfiguration
Windows Hello for Business                       #microsoft.graph.windowsIdentityProtectionConfiguration

 Thanks for pointing us to the Beta endpoint!

Thank you very much! Using the Beta endpoint helped me as well. I wonder why this has not been resolved on the production endpoint yet.

Well, the issue has a minimum 1-year vesting period before any attention can be spent towards addressing it. We're only at 11.9 months :face_with_tears_of_joy:.

But seriously, glad the beta suggestion from Rudy helped another victim.