-
Notifications
You must be signed in to change notification settings - Fork 523
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
IntuneAppConfigurationDevicePolicy: Not working #4724
Comments
@ricmestre Will do, but honestly I don't have any idea why it worked for all settings I checked with. Sorry about that. |
@ricmestre I created a pull request to address the assignments and the MOF compilation. Your error with the Android policy is because you probably want to target the Outlook app, but the By the way: Thank you for the hint with the |
@FabienTschanz Thank you for looking into this so quickly :) The assignments are being exported with the display name and can use them to apply the policy to another tenant now, but the comparison still fails, if I change that chunk for what's in IntuneDeviceConfigurationPolicyWindows10 then it works, please check it here. EDIT: Maybe it's also a good candidate to include in the DRG since the one placed there is the same one you used here. Line 4640 in cb4a741
Regarding the Android policy thanks for the tip but unfortunately it still fails with the same error message even after using the correct Id. |
@ricmestre I updated the logic to be pretty much the same as in the code you mentioned, but with an existing comparison function for the assignments. I'll check your Android policy again. |
@ricmestre I took your configuration and only changed the id in |
I struggled a bit here syncing the managed android store, but basically I'm now able to apply the policy with one caveat, the Id of the targeted app actually is always different per each tenant so after applying the correct one assigned to mine it worked. For some reason the iOS policy doesn't complain but after opening it in the admin portal it says that the targeted app doesn't exist anymore and therefore the policy can be deleted. So the missing link here is to also export the names of the apps along with their GUIDs, and then in Set-TargetResource search for the GUID and if not found search by display name. EDIT: Forgot to add, but what if there are apps with the same name, which there will be like the ones from Microsoft per each OS? Is there a way to differentiate? Would it be better to split this resource into different OSes? EDIT2: Just having the app's display name exported might not be enough, I forgot that even for the same OS might be separate apps per each store from where you can install them, e.g. since I synced my managed google play store I now have 2 "Microsoft Outlook" apps, one for the managed store and another for the regular store (note that I still have yet another one just for iOS). Get-MgBetaDeviceAppMgtMobileApp gives you this information. |
@ricmestre Thanks a bunch for the analysis. My 2 cents: A differentiation into different OSes shouldn't be necessary. Policies for iOS either contain the property Will test that and provide an updated version. Sure hope that's the last thing we have to fix before it finally works as intended 😢 |
In that case it's easy to differentiate and filter the OSes, nevertheless please remember about the different stores for Android. See below, the first entry #microsoft.graph.managedAndroidStoreApp is for the regular store, the second entry is iOS which you can ignore for now and the last entry #microsoft.graph.androidManagedStoreApp is for the managed google play store, so we both now that it's exactly the same app but it's actually not since they are from different stores! Also it's very confusing why they used so similar names for both stores, but it is what is. |
@ricmestre Got it, thanks a bunch for the hint. I just analyzed the Intune portal and found out that only apps of type |
@ricmestre Should all be done now. If you want, you can try it again with the latest changes in my PR. I set it to Draft to prevent a merge if it doesn't work correctly, but from my testing it works. |
@FabienTschanz Code looks good but more importantly everything is working now :) I tried to export my current policies from tenant A, apply them to a tenant B, change their settings to something else and then finally remove them and everything worked. The admins who will be using this will probably not understand what they're even looking at in the Android's payloadJson, would it be too much to probably convert it to json in exports and then back to jwt when setting it? Something like the below, if it's too much to ask I can do it myself after your PR is approved. # Convert to $payloadJson to JSON
[Text.Encoding]::ASCII.GetString([Convert]::FromBase64String($payloadJson))
# Convert $json to JWT
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($json)) |
@ricmestre Awesome, thanks for the feedback. I agree that the real JSON content would be better, unfortunately ReverseDSC has an issue with nested double quotes ("), which get all deleted if they are in a property block. I have microsoft/ReverseDSC#36 open that addresses that issue, but unfortunately it is not yet merged 😢 In my opinion, as soon as that one is merged, we can switch to the real JSON string in the configuration. @NikCharlebois Can you help us with merging the PR over in the ReverseDSC repository? |
Description of the issue
I have 2 policies of this kind, one for Android and another for iOS and they have 2 different problems. I'm able to export them but:
Cannot apply the Android policy to a different tenant, the error message like whenever something bad happens in Graph side is not conclusive, and no, there's nothing additional in event viewer to debug this further.
For the iOS policy it's easy, the module is calling Get-M365DSCDRGComplexTypeToString on MicrosoftGraphappConfigurationSettingItem1 instead of MicrosoftGraphappConfigurationSettingItem as referred in the schema so it complains when trying to compile the blueprint to MOF that that type doesn't exist. After changing the blueprint manually to the correct type I was able to compile it and apply the policy to another tenant but then there's another problem, Test-DscConfiguration returns false, it looks like Assignments is not working, this is because groupDisplayName is not being exported, only the groupId, and of course won't work when applying to a different tenant since those Ids don't exist in the target tenant.
@FabienTschanz Could you please have a look?
Microsoft 365 DSC Version
1.24.529.1
Which workloads are affected
Intune
The DSC configuration
Verbose logs showing the problem
Environment Information + PowerShell Version
The text was updated successfully, but these errors were encountered: