Graph API permission
Upload doesn't work. Is App registration required? which permissions are needed? delegated or application? If needed, how can i import ClientID and ClientSecret ?
I have probaly similiar issue...
Upload doesn't work. Is App registration required? which permissions are needed? delegated or application? If needed, how can i import ClientID and ClientSecret ?
Microsoft has complicated this early this year by terminating Microsoft intune Powershell enterprise application.
instead you need to create an app registration yourself. Follow this article https://techcommunity.microsoft.com/t5/intune-customer-success/update-to-microsoft-intune-powershell-example-script-repository/ba-p/3842452
So the app is not working at the moment... Correct?
So the app is not working at the moment... Correct?
Correct. I found https://github.com/Romanitho/WingetIntunePackager , the last PR includes App registration Id field. (more info at pull request https://github.com/Romanitho/WingetIntunePackager/pull/30
Not tried yet, let me know if this works
Well... I tried that one before yours. With that one I cannot even connect. Even after creating an app in entra and giving the right permissions and the uri. So that's why I gave this one a try. I guess I am out of options.
Well, i'm gonna create it on my own :).
I fixed the issues which occured after the MS App Registration change within the script and added as well to the GUI to set your own non default Client ID and Redirect URI. If the app registration doesn't have the permission, you will be asked with Connect-MgGraph to give the permission.
You can get my version in my fork: https://github.com/InnovationForge-com/WinGet-Wrapper I will create a pull request after optimizing it a bit more.
If you want the GUI options then you need to start WinGet-WrapperImportGUI.ps1 and not WinGet-WrapperImportGUI.exe. Even without setting it in the GUI, WinGet-WrapperImportFromCSV.ps1 will use App ID "14d82eec-204b-4c2f-b7e8-296a70dab67e" and Redirect URI "https://login.microsoftonline.com/common/oauth2/nativeclient", which is used by the .exe as well.
I fixed the issues which occured after the MS App Registration change within the script and added as well to the GUI to set your own non default Client ID and Redirect URI. If the app registration doesn't have the permission, you will be asked with Connect-MgGraph to give the permission.
You can get my version in my fork: https://github.com/InnovationForge-com/WinGet-Wrapper
I will create a pull request after optimizing it a bit more.
If you want the GUI options then you need to start WinGet-WrapperImportGUI.ps1 and not WinGet-WrapperImportGUI.exe.
Even without setting it in the GUI, WinGet-WrapperImportFromCSV.ps1 will use App ID "14d82eec-204b-4c2f-b7e8-296a70dab67e" and Redirect URI "https://login.microsoftonline.com/common/oauth2/nativeclient", which is used by the .exe as well.
Great work! Feel free to create a pull request and i will be sure to test it and add it to the main branch.
@huuub @Ivanodib @SorenLundt I just checked the Release again and the PR i posted. For me it works fine, im not sure what issues you are facing? You can just create your own Application, give Group Read All, Apps ReadWrite All and ManagedDevices ReadWrite All. Then you can connect to the App with the Application (client) ID and the default Redirect URI https://login.microsoftonline.com/common/oauth2/nativeclient which you ofcourse have to add in your App aswell as an Redirect Mobile and Desktop App URI.
created PR https://github.com/SorenLundt/WinGet-Wrapper/pull/23
Azure AD Application Configuration for WinGet-Wrapper
Background
The WinGet-Wrapper tool uses Microsoft Graph API to interact with Intune. By default, it uses a built-in application ID, but due to recent Microsoft infrastructure changes and security policies, it's recommended to create your own Azure AD application registration. This ensures:
- Better security control over the application
- Avoidance of potential throttling issues
- Clear audit trails in your Azure environment
- Prevention of authentication issues related to Microsoft's first-party app verification changes
Creating Your Azure AD Application
Step 1: Create the Application Registration
- Log in to the Azure Portal (portal.azure.com)
- Navigate to Azure Active Directory → App registrations
- Click "New registration"
- Configure the following:
- Name: "WinGet-Wrapper-App" (or your preferred name)
- Supported account types: "Accounts in this organizational directory only"
- Click "Register"
- After creation, note down the "Application (client) ID" - you'll need this later
Step 2: Configure Authentication
- In your app registration, go to "Authentication" in the left menu
- Click "Add a platform"
- Select "Mobile and desktop applications"
- Check the box for "https://login.microsoftonline.com/common/oauth2/nativeclient"
- Click "Configure"
This configuration is crucial because the PowerShell scripts use interactive authentication, which requires a proper redirect URI.
Step 3: Configure API Permissions
- Go to "API permissions" in the left menu
- Click "Add a permission"
- Select "Microsoft Graph"
- Choose "Application permissions"
- Search for and select "DeviceManagementApps.ReadWrite.All"
- Click "Add permissions"
- Click "Grant admin consent" and confirm
Updating the Scripts
You need to update the ClientID in the following files:
Option 1: Modify the Script Directly
Update WinGet-WrapperImportFromCSV.ps1:
#ClientID to connect to MSGraph/InTune with Connect-MSIntuneGraph
[Parameter(Mandatory = $False)]
[string]$ClientID = "your-application-id-here"
Option 2: Pass ClientID as Parameter
Run the script with your ClientID:
.\WinGet-WrapperImportFromCSV.ps1 -TenantID "yourtenant.onmicrosoft.com" -ClientID "your-application-id" -csvFile "your-csv-file.csv"
Troubleshooting
Common Issues
-
"No reply address is registered for the application"
- Cause: Missing redirect URI configuration
- Solution: Follow Step 2 in the configuration process
-
"Application is not authorized to perform this operation"
- Cause: Missing or unauthorized API permissions
- Solution: Ensure Step 3 is completed and admin consent is granted
-
"AADSTS700016" or "AADSTS90099"
- Cause: Application not properly authorized in tenant
- Solution: Ensure admin consent is granted and the account has proper roles (Global Admin or Intune Administrator)
Best Practices
-
Security:
- Regularly review and audit application permissions
- Use separate applications for development and production
- Follow the principle of least privilege when assigning permissions
-
Maintenance:
- Document your application ID and configuration
- Regularly review and update permissions as needed
- Monitor application usage through Azure AD audit logs
Required Azure AD Roles
The user account running the scripts needs one of these roles:
- Intune Administrator
- Global Administrator