powershell
36 TopicsHow can I get the Operating System Build Number for an Android device in Intune
Hello all, I am trying to pull information about an Android devices Operating System Build Number from Intune using PowerShell, however - the closest information I can find is the Operating System Version. I've been successful in connecting to Microsoft Graph via PowerShell, and I'm certain I have permissions to access all the device information. However, I cannot find information about how to pull the data I'm looking for. Google suggested that I need to include 'hardwareInformation' as an ExtendProperty of Get-MgManagedDeviceManagedDevices but I receive an error stating: "Parsing OData Select and Expand failed: Could not find a property named 'hardwareInformation' on type 'microsoft.graph.managedDevice'" Can someone please help me find how to select the Operating System Build Number from Intune or MgGraph? I've included an image of the exact data I'm looking for as it shows up in Intune47Views0likes0CommentsDeploying Script as Win32 App
Hi all, I created a script that is supposed to check if a certain app was installed from a managed installer, then create a file in the C:\Temp folder if it was installed from a managed installer. I would deploy this as a Win32 app so that I could use the detection rules in the Win32 App deployment to check which device was installed via a managed installer. However, it doesn't seem to work. I created a transcript log as well to check if I would get an output from the variables, but it seems to only run the else block in the If Statement. We use a Business Premium license, so I don't access to Enterprise license capabilities like proactive remediation scripts. It is run using the System credentials, I've tested the script locally which works. Thank you, I've included some images of the script and transcript log. Script: Transcript Log Output:48Views1like1CommentIntune Proactive Remediation Script Not Working for Normal Users on AVD Multi-Session
Scenario: We are using Azure Virtual Desktop (AVD) multi-session machines that are Azure AD joined and enrolled in Intune. These machines are part of an Application Group where normal Azure AD users are assigned. Users can successfully log in to the AVD session host. What We Are Doing: We are deploying a Proactive Remediation script (now called Remediations) via Intune. The script is designed to show a confirmation popup to the user. In the script package settings, we have selected: > Run this script using the logged-on credentials (i.e., run in user context) What Works: When a Global Administrator logs in to the AVD machine, the popup appears as expected. Logs and script output are generated correctly. What Doesn’t Work: When a normal user logs in (non-admin Azure AD user), the script: Does not show the popup Does not generate logs Appears to not run at all What We Suspect: The issue may be related to lack of local administrator rights for normal users. Since we are using AVD, we are not logging in with local machine administrators. We understand that system context would allow the script to run regardless of user login, but we specifically need user context to show the popup. Questions: Is this expected behavior for Proactive Remediation scripts in user context on AVD multi-session machines? Do normal users need to be local administrators for the script to run properly in user context? Is there a supported way to show popups or UI prompts to normal users via Intune scripts on AVD? Are there any official Microsoft documents or best practices that explain this behavior or provide a workaround? Additional Info: We are using Windows 10/11 Enterprise multi-session Devices are Azure AD joined Scripts are encoded in UTF-8, and logging is implemented Licensing is compliant with Intune and AVD requirements If anyone has encountered this issue or has documentation or a workaround, your help would be greatly appreciated!63Views0likes1CommentPowershell - Lock screen & Desktop background issue
I am currently starting to configure for a smaller organisation, using Intune for MDM, I've managed to successfully change my Azure AD login to be a standard user (I don't want every user having full administration rights) - that works well and I've assigned an Azure AD group to have admin privileges. So my next step is to set a corporate lock screen and desktop background image, using this script. But I now have an issue, either way I want to handle the script in Intune. Running script as: Run this script using the logged on credentials: No The script runs, but the user doesn't download the image files (having tested with administrative privileges in Powershell - the user doesn't have an internet connection, as the laptop is on wifi). So the lock screen and desktop background don't get set. Run this script using the logged on credentials: Yes The script runs, downloads the files successfully but then can't set the registry keys (as my standard user doesn't have permission to alter registry keys). So the lock screen and desktop background don't get set. Do Powershell scripts run in order - and sequentially? That way I could set two scripts, one to download and one to set the registry keys. Or is there any other way of achieving this? Please bear in mind I'm using Windows 10 Pro - so the usual Intune background settings don't work with. Many thanks.Solved23KViews0likes8CommentsPowerShell install updated Sysmon
Attempting to install an updated Sysmon to a computer. Sysmon has been uninstalled prior to updating; however, when running PowerShell in Intune to install it, it appears that Sysmon64.exe is copied to C:\Windows\, but no service is created for Sysmon64. This is running in System context, with WORKGROUP\SYSTEM for a user. Running the following command in a PowerShell script only copies the file, but doesn't create the service: Start-Process -Wait "sysmon64.exe" -ArgumentList "-i -accepteula" Running the above line in PowerShell ISE, as myself outside of the Intune deployment, the service is created without issue. What am I missing? Thanks!84Views0likes0CommentsWindows 11 Autopilot and language packages
Hi everyone, I work for a Company with about 10.000 employees. We have a working SCCM envoirenment and an Autopilot PoC which should go live in the near future. The whole project was in cooperation with DELL. The problem here is that DELL scammed us a little bit, because they always ensured us, that we will get the DELL ready image for the region where Notebook is deployed (DELL ready Image contains the LPs for all countries in the Region e.g. central Europe, Asia pecific etc.). At the End Dell told us, that it us technically not possible to provide us this image and the only thing they can do is to provide us the basic US image That's where our problem started... We need some languages for our subsidaries in some countries. Thus we tried to create a package for the Language install. 1. First idea was to use the Powershell cmdlet install-language (Install-Language (LanguagePackManagement) | Microsoft Learn). The problem here is that this package runs pretty unstable. During Autopilot the command needs about 30 Minutes to finish. Sometimes the command throws an error: "Language Pack or feature could only be partially installed. Error Code: -2147023436“ (I guess it is a timeout but I didn't find anything on Google). The strange thing here is that this cmdlet runs pretty good and stable in private envoirenment. I tested it on my PC at home with Windows 10 22H2 and on a company device with the Microsoft en-US base Image (Win 11 23H2). With Autopilot it worked 70-80% of the time and the rest failed. It was very strange that in the logs the cmdlet faild with error Code: -2147023436, but after Autopilot finished, the Language was available if I called get-language. I also monitored it in the OOBE with the powershell. Result: cmdlet sometimes failed, Language was av Does anyone know how install-language works in the Background? Which URLs are called or what this error code means? Thank you for every kind of help Best regards Sven3.5KViews0likes7Commentshelp with remediation
Hi, i'm trying to create detection and remediation scripts for intune to detect the presence of a template in the users word startup folder **My detection is as follows** $path = "C:\Users\$env:USERNAME\AppData\Roaming\Microsoft\Word\Startup\ACS Template 2010 2013 2016 (2) (1).dotm" if (Test-Path $path) { Write-Output "File exists: $path" exit 1 # Success, file exists } else { Write-Output "File not found: $path" exit 0 # Failure, file does not exist **My remediation** $path = "C:\Users\$env:USERNAME\AppData\Roaming\Microsoft\Word\Startup\ACS Template 2010 2013 2016 (2) (1).dotm" if (Test-Path $path) { Remove-Item -Path $path -Force It seems like the detection works as the detection status is "without issues" but the remediation doesn't run. Any advice on how to correct this very much welcomed77Views0likes2CommentsError on Connect-MSGraph
Hello, I would like to use Powershell to sync Intune devices but when I launch the Connect-MSGraph command and enter the user credentials it responds with the following error message: AADSTS700016: Application with identifier d1ddf0e4-d672-4dae-b554-9d5bdfd93547 was not found in the directory 'Contoso'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant. Is there a problem with Azure Graph app? How can I fix it? Thank you very much.328Views3likes0CommentsManipulating the registry via Intune push
Our goal is simple: Manipulate the registry as part of application deployment or PowerShell script. Use case: When we install our VPN client, there are a raft of registry updates that need to be made to configure it for use in our environment. The easiest way of doing this is simply by importing a .reg file we've created. The problem that I just can't seem to overcome is how to import a .reg file using PowerShell as part of an Intune deployment. For testing purposes, I've created a simple test registry file and I'd ideally like to use a PS script that simply has the command "reg.exe import .\1Test.reg" in it. The command runs perfectly from CLI but when I try pushing it as part of a Win32 app, it fails. When I build in other diagnostic steps, everything in the script runs perfectly except for the actual import. I've tried using the script to create a temporary directory, copy the files to it, set it as the working directory, and importing from there in case there were path issues. Everything works perfectly all the way up to the actual import, which never works. I've tried using "regedit.exe /silent" as well as "reg.exe" and I've spun it off as a separate process; nothing seems to work. I think it needs to run in the user instead of system context so I've tried both of those. I'm currently at a 100% failure in my ability to figure this out and I'm hoping that someone out there in the community has dealt with this and knows the incredibly simple secret and can demystify it for me. Thanks in advance for your help!156KViews0likes11Comments