Fix for issue #5566 intune app configuration policy

[dannyKBjj]

Pull Request (PR) description

Have added a number of missing properties for the resource and added test/create support for 'Applications'

Unfortunately unable to fix 'update' due to what looks like an MgGraph issue. Added a verbose message to the code to warn the user..

reported here:
#5671

and here:
https://feedbackportal.microsoft.com/feedback/idea/c0940cc8-d7da-ef11-95f6-0022484d7a88

Similarly the module cannot support the 'Application Catalogue Settings' either. I can find them in Graph explorer but the related cmdlet doesn't work and cannot retrieve using invoke-mgGraph either.

Issue reported here
https://feedbackportal.microsoft.com/feedback/idea/f77feb49-11dc-ef11-95f6-0022484d7a88

and here
#5672

This Pull Request (PR) fixes the following issues

• Fixes IntuneAppConfigurationPolicy doesn't actually handle Any app settings #5566

Task list

• [x ] Added an entry to the change log under the Unreleased section of the file CHANGELOG.md.
  Entry should say what was changed and how that affects users (if applicable), and
  reference the issue being resolved (if applicable).
• [ x] Resource parameter descriptions added/updated in the schema.mof.
• [x ] Resource documentation added/updated in README.md.
• [x ] Resource settings.json file contains all required permissions.
• [x ] Examples appropriately added/updated.
• [x ] Unit tests added/updated.
• [x ] New/changed code adheres to DSC Community Style Guidelines.

[dannyKBjj]

Re-ran unit tests here. Work fine...

[dannyKBjj]

This seems to be the issue:
I need to call that command to retrieve the full App information, I don't think I can fix this at my end?!

[salbeck-sit]

@dannyKBjj You need to ensure that the command is defined in one of the stubs under Tests/unit/stubs. The unit-tests run by a PR won't have access to any modules

[dannyKBjj]

That seems to have fixed it. Thanks very much for your help!

[FabienTschanz]

I'm taking a look at the not working update method.

[FabienTschanz]

@dannyKBjj The following code works without issues and updates the apps on the policy:

if ($null -ne $Apps)
{
    $appsArray = @()
    foreach ($app in $Apps)
    {
        if ($null -ne $app.mobileAppIdentifier.bundleID)
        {
            $mobileAppIdentifierHashtable = @{
                '@odata.type' = "#microsoft.graph.iosMobileAppIdentifier"
                bundleId      = $app.mobileAppIdentifier.bundleID
            }
        }

        if ($null -ne $app.mobileAppIdentifier.packageID)
        {
            $mobileAppIdentifierHashtable = @{
                '@odata.type' = "#microsoft.graph.androidMobileAppIdentifier"
                packageId     = $app.mobileAppIdentifier.packageId
            }
        }

        if ($null -ne $app.mobileAppIdentifier.windowsAppID)
        {
            $mobileAppIdentifierHashtable = @{
                '@odata.type' = "#microsoft.graph.windowsAppIdentifier"
                windowsAppId  = $app.mobileAppIdentifier.windowsAppId
            }
        }

        $appsArray += @{
            'mobileAppIdentifier' = $mobileAppIdentifierHashtable
        }
    }

    $appsBody = @{
        appGroupType = $AppGroupType
        apps = $appsArray
    }

    Write-Verbose -Message "Updating Apps for Intune App Configuration Policy {$DisplayName}"
    $Uri = (Get-MSCloudLoginConnectionProfile -Workload MicrosoftGraph).ResourceUrl + "/beta/deviceAppManagement/targetedManagedAppConfigurations('$($currentconfigPolicy.Id)')/targetApps"
    Invoke-MgGraphRequest -Method POST -Uri $Uri -Body $($appsBody | ConvertTo-Json -Depth 10) -Verbose
}

I switched your Update-MgBetaXXX call to the Invoke-MgGraphRequest and slightly updated your hashtable that's used for the update. I didn't touch the create stuff, I trust that it works.

Btw, please remove the IsAssigned and DeployedAppCount properties, they are readonly and would only make the drift incorrect as soon as you change the app count.

[dannyKBjj]

Hi, I'd tried experimenting with invoke-mggraph myself, but had no luck. I copied your code into Set-TargetResource, and tried to use it to remediate a change I made to my 'apps' for one of my policies, but it doesn't seem to be working at my end:

[dannyKBjj]

M365TenantConfig - Example.txt

I've attached an export of my test policy if you want to try yourself. The policy will create just fine using the mgBeta cmdlet. If you edit the apps and try and try and update it will fail with both my code (which I commented out) and the invoke-mgGraph method you provided... or at least it is failing at my end?!

[dannyKBjj]

Should it be PATCH not POST to update an existing policy? I tried changing the code to PATCH instead, but got the same result.

[FabienTschanz]

Should it be PATCH not POST to update an existing policy? I tried changing the code to PATCH instead, but got the same result.

It's a POST request to /targetApps. You can figure those things out if you check in the Intune portal with your browser dev tools (F12 normally) in the network tab.

[ricmestre]

The app called Graph X-Ray it's also a good complement to the browser's dev tools

[dannyKBjj]

Thanks guys, I appreciate the tips. I've been thrown in the deep-end and learning as I go along, so all help is appreciated :-D

Unfortunately the provided code just doesn't seem to be working for me?! I copy&pasted it over the if ($null -ne $Apps){} in Set-TargetResource, so don't really understand what I could have done wrong (if anything).

It is definitely working at your end?

[FabienTschanz]

@dannyKBjj Sorry, I had a / too much. The Uri should be: $Uri = (Get-MSCloudLoginConnectionProfile -Workload MicrosoftGraph).ResourceUrl + "beta/deviceAppManagement/targetedManagedAppConfigurations('$($currentconfigPolicy.Id)')/targetApps", without the / right before beta.

[ricmestre]

@FabienTschanz If you use Invoke-MgGraphRequest then you can start the Uri on "/beta..." without having to worry to which Graph endpoint you're connected to (so no need for calling Get-MSCloudLoginConnectionProfile), this way it just works for any environment out of the box as long as the resource is available for that type of cloud.

[FabienTschanz]

@ricmestre Yeah that was my issue, I copy-pasted it from my test without Get-MsCloudLoginConnectionProfile and left the /beta, then added the full call to make it work in all clouds. It worked when I didn't prefix it with the full url. I added it because all Invoke-MgGraphRequest calls use the full prefix.

[ricmestre]

This was a problem in the past and I think you actually fixed them all, or at least most of them, where the calls had graph.microsoft.com hardcoded, but to be honest Get-MsCloudLoginConnectionProfile is not even needed, but as long as it works then it shouldn't matter and it's only a preference.

[dannyKBjj]

Hi guys, I'm sure I'm being stupid, but I experimented a fair bit with Invoke-MgGraph myself and couldn't get it to work. I also can't get the code you kindly provided to work either... I've tried everything I can think of at this point.

[FabienTschanz]

Please push the latest changes how you have them implemented in your resource, best with a descriptive visible error what's not working. Then I can take a look.

[dannyKBjj]

Oh, I so now it is working!!! I guess I was being stupid. No idea what I was doing wrong before, but hey-ho.

I've pushed the changes.

[FabienTschanz]

Looks good so far. Some minor formatting with a space between if and the brackets could be added and the commented lines removed, but otherwise, it's ok.

[dannyKBjj]

Thanks Fabien, do you want me to make those changes, or are we letting it slide :-)

[FabienTschanz]

Personally I'd like to have those changes in, but they are not required. Feel free to update it though to make it look even cleaner 😄

[dannyKBjj]

Done

[FabienTschanz]

LGTM 🚀