Get-IntuneDeviceConfigurationPolicy returns only some of my policies

[Jeremy Bradshaw]

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

displayName
-----------
Android Enterprise - Work profile
Bitlocker
Broad
Essential Settings
Wi-Fi - Android Enterprise - Work profile

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                                                           
displayName
-----------
Android Enterprise - Work profile
Bitlocker
Broad
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 endpoint.microsoft.com as I am when obtaining the access token in PowerShell (i.e. Connect-MSGraph, when using the module).

Thanks in advance.

[#2]

@Jeremy Bradshaw Do you get the same result if you run it from Graph Explorer (aka.ms/ge)

GET https://graph.microsoft.com/v1.0/deviceManagement/deviceConfigurations?$select=Displayname

[#3]

@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": "https://graph.microsoft.com/v1.0/$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.

[#4]

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

[#5]

@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
8

[PS]> $devConfigs.value.displayName
Android Enterprise - Work profile
Bitlocker
Broad
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:).

[#6]

@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

https://graph.microsoft.com/beta/deviceManagement/deviceconfigurations... and of course its missing the administrative templates

When you want to get them back you should query the

https://graph.microsoft.com/beta/deviceManagement/grouppolicyconfigurations

The same with the settings catalog that would be 

https://graph.microsoft.com/beta/deviceManagement/configurationPolicies

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

[#7 · Accepted solution]

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 = "https://graph.microsoft.com/"
$authority = "https://login.microsoftonline.com/common"
$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 = 'https://graph.microsoft.com/beta/deviceManagement/deviceconfigurations'

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

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

connect-msgraph

[#8]

@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
16

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!

[#9]

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.

[#10]

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.