In this blog post, we’ll explore how to retrieve app configuration settings for Android devices managed via Intune, using PowerShell and the Microsoft Graph API. First, we’ll break down what app configuration settings are and their significance in modern device management. Then, we’ll dive into a step-by-step process to fetch these settings programmatically, providing practical insights along the way.
As a bonus, we’ll uncover a clever technique using developer tools to troubleshoot challenging scenarios. Whether you’re an IT admin, developer, or Intune enthusiast, this guide will equip you with the tools and knowledge to navigate app configuration retrieval with confidence. The goal here isn’t just to get things done but to truly understand how to do them. After all, knowledge is what turns tasks into skills—and skills into mastery!
This post is packed with useful insights, but we get it—you’re busy, and time is precious. Feel free to skip around and dive straight into the sections that tickle your fancy.
Table of Contents
What are app configuration policies and where to find them?
App configuration policies in Microsoft Intune allow IT administrators to predefine and automate the setup of application settings for managed apps on user devices. These policies simplify the onboarding process by ensuring the correct configurations are applied to apps without requiring users to manually input settings. Commonly configured settings include server addresses, language preferences, branding elements like company logos, and security parameters. This approach reduces setup errors, improves consistency across the organization, and minimizes helpdesk calls.
App configuration policies are particularly useful for apps that support custom settings through Intune. For Android and iOS devices, these settings are often provided by app developers, and Intune may display the available configuration options directly within its interface. Admins can assign these policies to devices or user groups, ensuring a seamless deployment of applications with the necessary configurations pre-applied.
To create or manage app configuration policies, navigate to the Intune portal, go to Apps > App configuration policies. Here, you can view existing policies, create new ones, or edit configurations for supported apps. For further guidance on creating these policies, you can refer to Microsoft’s official documentation. You can also check my blog about Managed Home Screen that gives a better understanding of the above.
Now what about app configuration settings?
Let’s say you’ve created an app configuration policy and deployed it to a few endpoints. Most app configuration policies push distinct settings to devices (grouped under the app configuration profile) e.g. an app configuration could set the settings for screen brightness levels, lock screen timeouts and default app behavior.
To find these settings, you can navigate to a specific device in the Intune portal and check the App configuration blade. There you’ll find a list of deployed app configurations. Clicking on any of these configurations opens a treasure trove of details—allowing you to explore the individual settings applied to that device. This granular visibility can be invaluable for troubleshooting, fine-tuning configurations, or simply satisfying your inner tech detective!
Check the below screenshots to get a better understanding.
As shown in the screenshot above, the app configuration policy “MHS App Configuration” includes an underlying setting labeled “com.microsoft.launcher.enterprise”. This specific setting plays a crucial role in defining how the app behaves on the managed device.
In the chapters ahead, we’ll uncover the mystery behind how Intune retrieves these settings. More importantly, we’ll show you how to leverage PowerShell to programmatically access these configurations, empowering you to gain deeper insights and streamline your management processes.
But you might be wondering: “Why would we even need to retrieve these settings using PowerShell?”
Why using PowerShell to get app configuration settings?
That’s a great question! While the Intune portal provides a user-friendly interface to view and manage app configurations, PowerShell offers something more: automation, scalability, and flexibility. Imagine manually checking app settings for hundreds of devices—time-consuming? Absolutely. Impossible? Maybe!
With PowerShell, you can:
- Automate the retrieval of app configuration settings across multiple devices.
- Analyze data programmatically for reporting, troubleshooting, or compliance audits.
- Scale your operations efficiently, especially in large enterprise environments.
- Integrate the retrieved data into broader workflows or tools.
In short, PowerShell unlocks the potential to streamline your operations and empowers you with the magic of automation. The following chapters will guide you step-by-step—transforming a potentially tedious task into a swift and effective process.
Behind the Scenes: How Intune Operates
When we click on almost anything in the Intune portal, it performs requests such as POST, GET, and others to Microsoft Graph API in order to retrieve the required information. If you need a refresher on how this works, check out my previous post for a more detailed explanation.
This is exactly what happens when we navigate to the App Configuration Settings in Intune. Behind the scenes, Intune sends a POST request to the Graph API to fetch the configuration data.
The tricky part, however, is identifying the specific request Intune makes to get this information. While Intune abstracts much of this process from users, we can dig into these requests by using developer tools like the Network tab in Developer Tools or Fiddler. This allows us to see the exact API calls being made and understand the flow of data.
So let’s see how to identify the above request.
As shown in the screenshots above, Intune performs a POST request to a specific URL in order to retrieve the app configuration settings. This request is part of how Intune communicates with the Microsoft Graph backend to fetch the required details.
Here’s where things get interesting: if we use the “Copy as PowerShell” option available in developer tools, we can extract the PowerShell code that replicates this exact request. By tweaking this code slightly—adjusting headers, request formatting, or authentication—we can transform it into a fully functional script. This script can then programmatically perform the request to retrieve app configuration settings, saving us time and effort when working with multiple devices or automating tasks.
The beauty of this approach is that it bridges the gap between manual exploration in the Intune portal and scalable automation using PowerShell. In the following sections, we’ll see step-by-step how to refine and use this script to unlock the power of programmatic data retrieval.
The PowerShell Script
Now that we’ve laid the groundwork and explained everything happening behind the scenes, it’s time to get to the star of the show: the PowerShell script!
You can find the code in my GitHub page too!
This script will bring together everything we’ve discussed so far—from understanding how Intune retrieves app configuration settings to using PowerShell to replicate that process programmatically. By following the steps outlined earlier, we were able to identify the necessary POST request and adapt it into a fully functional script.
So, without further ado, let’s dive into the code that does all the heavy lifting for us!
The script uses the module Microsoft.Graph. Do not forget to install it using install-module Microsoft.Graph.
You also must have the required permissions to perform the request.
# Connect to Microsoft Graph using the current account's credentials.
# This establishes a session with Microsoft Graph to allow API requests.
Connect-MgGraph
# Define the Device ID and Policy ID for which the compliance data will be queried.
# These values act as filters in the API request to narrow down the results.
$deviceID = "fe7f320b-610f-456a-ac9d-c9cd9e9d8e1e"
$policyID = "079f6ffa-77ff-4e59-90c8-3758418972bc"
# Define custom request headers to control the behavior of the HTTP request.
# Headers include metadata like accepted content types and localization preferences.
$headers = @{
"Referer" = "" # Empty Referer header (can be omitted if unnecessary)
"Accept-Language" = "en" # Set the language preference to English
"X-Content-Type-Options" = "nosniff" # Prevent MIME type sniffing
"Accept" = "*/*" # Allow any content type to be accepted
"x-ms-effective-locale" = "en.en-us" # Set the locale to English (US)
}
# Define the request body as a PowerShell object.
# This object specifies the query parameters for the API call:
# - 'filter': Filters data based on PolicyId, DeviceId, and UserId
# - 'top': Limits the result set to 50 items
# - 'orderBy': Sorts the results by 'SettingName'.
$bodyObject = @{
select = @() # Empty 'select' property to retrieve all available fields
filter = "(PolicyId eq '$policyID') and (DeviceId eq '$deviceID') and (UserId eq '00000000-0000-0000-0000-000000000000')"
top = 50 # Limit the response to 50 records
orderBy = @("SettingName") # Sort the results by SettingName
}
# Convert the PowerShell object to a JSON string as required by the Microsoft Graph API.
# The JSON format is necessary for the request body in the HTTP POST call.
$bodyJson = $bodyObject | ConvertTo-Json -Depth 3 -Compress
# Define the HTTP request parameters:
# - 'POST' is the HTTP method used to send data.
# - 'application/json' is the content type of the request body.
# - The URI is the endpoint for the non-compliance report.
$method = "POST"
$contentType = "application/json"
$uri = "https://graph.microsoft.com/beta/deviceManagement/reports/getConfigurationSettingNonComplianceReport"
# Send the HTTP request to the Microsoft Graph API and store the response.
# - The body is passed in JSON format.
# - The content type specifies that the body is JSON.
$response = Invoke-MgGraphRequest -Method $method -Uri $uri -Body $bodyJson -ContentType $contentType #-Headers $headers
# Create an empty array to store custom objects that will represent the report data.
$dataArray = @()
# Loop through each item in the 'Values' property of the response.
# The 'Values' property is an array of rows returned from the API query.
foreach ($item in $response.values) {
# Output the current item to the console for debugging or informational purposes.
Write-Host $item -ForegroundColor Yellow
# Create a custom PowerShell object with properties corresponding to relevant fields.
# The 'item' array contains data in a specific order; we use indexes to map it.
$customObject = New-Object -TypeName PSObject -Property @{
SettingStatus = $item[8] # Index 8: Status of the setting
ErrorType = $item[9] # Index 9: Type of the error
ErrorCode = $item[10] # Index 10: Specific error code
SettingName = $item[12] # Index 12: Name of the setting
ErrorMessage = $item[11] # Index 11: Detailed error message
DeviceID = $deviceID # Add the Device ID as part of the output for reference
}
# Add the custom object to the data array.
$dataArray += $customObject
# Output a separator line to the console for better readability.
Write-Host "-------" -ForegroundColor Blue
}
# Export the data array (containing all custom objects) to a CSV file named 'output.csv'.
# -NoTypeInformation ensures that no type metadata is added to the CSV file.
$dataArray | Export-Csv -Path 'output.csv' -NoTypeInformation
# Optionally, display the results in an interactive grid view for easy analysis.
# 'Out-GridView' provides a user-friendly table display in PowerShell.
$dataArray | Out-GridView
Important Notes About the Script
- Single Device Check: By default, the script runs the check for one device only. Don’t worry—I’ll provide an updated version of the code below to run it for multiple devices.
- JSON Variability: The JSON format in the response may differ depending on the app configuration profile you’re querying. Be prepared to tweak the script to match your specific needs and the structure of your configuration profiles.
- Test, Test, Test: I cannot stress this enough—ALWAYS test the script on a development device before running it in production. A little caution goes a long way in avoiding unexpected outcomes.
- POST, Not GET: Unlike many scripts that simply retrieve data with GET requests, this script performs POST requests to fetch the required information. Keep this in mind when analyzing or modifying the script.
The below is just an example of the data returned for each setting, the actual structure and keys may differ depending on the app configuration profile you’re querying. Dive into the JSON response, analyze the data structure, and modify it as per your needs to suit your use case. Whether you’re troubleshooting, reporting, or automating, tweaking the JSON format will ensure the script works efficiently for your specific requirements.
To check the app configuration settings for more that one devices you could run the below script:
# Connect to Microsoft Graph
Connect-MgGraph
# Path to the file containing Device IDs
$deviceIDFile = "C:\Temp\deviceIntuneIDs.txt"
# Define the Policy ID
$policyID = "079f6ffa-77ff-4e59-90c8-3758418972bc"
# Define request headers
$headers = @{
"Referer" = ""
"Accept-Language" = "en"
"X-Content-Type-Options" = "nosniff"
"Accept" = "*/*"
"x-ms-effective-locale" = "en.en-us"
}
# Read all Device IDs from the file into an array
$deviceIDs = Get-Content -Path $deviceIDFile
# Create an empty array to hold the final custom objects
$dataArray = @()
# Loop through each Device ID
foreach ($deviceID in $deviceIDs) {
Write-Host "Processing Device ID: $deviceID" -ForegroundColor Cyan
# Define the request body as a PowerShell object
$bodyObject = @{
select = @()
filter = "(PolicyId eq '$policyID') and (DeviceId eq '$deviceID') and (UserId eq '00000000-0000-0000-0000-000000000000')"
top = 50
orderBy = @("SettingName")
}
# Convert the PowerShell object to JSON
$bodyJson = $bodyObject | ConvertTo-Json -Depth 3 -Compress
# Define request method, content type, and URI
$method = "POST"
$contentType = "application/json"
$uri = "https://graph.microsoft.com/beta/deviceManagement/reports/getConfigurationSettingNonComplianceReport"
# Invoke the request using Microsoft Graph API
$response = Invoke-MgGraphRequest -Method $method -Uri $uri -Body $bodyJson -ContentType $contentType #-Headers $headers
# Loop through each item in the 'Values' property of the response
foreach ($item in $response.values) {
Write-Host $item -ForegroundColor Yellow
# Create a custom object with properties corresponding to the columns
$customObject = New-Object -TypeName PSObject -Property @{
SettingStatus = $item[8]
ErrorType = $item[9]
ErrorCode = $item[10]
SettingName = $item[12]
ErrorMessage = $item[11]
DeviceID = $deviceID
}
# Add the custom object to the array
$dataArray += $customObject
Write-Host "-------" -ForegroundColor Blue
}
}
# Export the array to a CSV file
$dataArray | Export-Csv -Path 'output.csv' -NoTypeInformation
# Optionally, display the data in a grid view
$dataArray | Out-GridView
Final Remarks
In this post, we took a deep dive into the process of retrieving app configuration settings in Intune. We started with the basics, exploring what app configuration policies are and where to find them in the Intune portal. Then, we examined how Intune works behind the scenes by performing POST requests to Microsoft Graph API to fetch this data. From there, we uncovered how to identify the exact API calls Intune makes and used PowerShell to replicate those calls programmatically.
This wasn’t a straightforward task. As you may have noticed, there isn’t much readily available information on this specific topic across the web. Furthermore, Microsoft’s official documentation doesn’t provide the detailed steps needed to achieve this—making this process both challenging and rewarding to figure out.
The script and approach shared here can be a powerful tool for automating app configuration queries, but always remember:
Adapt the script to fit the JSON format of your app configurations.
Test thoroughly on a development device before running it in production.
Use the knowledge gained here to scale and customize your automation workflows.
If you have any questions, feedback, or run into any issues, feel free to reach out to me! I’m always happy to help and collaborate. Let’s keep learning and solving challenges together.
Thank you for taking the time to read this post—I hope it empowers you to explore new ways to manage and automate your Intune environment using PowerShell!
References
Other Interesting Posts