Deploying the well known Sysinternals tool BGInfo is popular since a very long time. Often people use it for more visibility of vital OS parameter to end users. It is used mostly to support in-house help desk personal. Today I’m using this approach, to provide a handy solution for your development or test environment to quickly identify your devices and logged on user including their permissions (local admin or standard user) in that session like this:
The undiscovered need for this was there all the time, e.g. during intensive testing in my development environments with a lot of virtual test devices and during class room training’s to make student life’s easier. I often test various features so Windows Version and Edition is important to know for me. As a nice addition I added the local permissions of the logged on user. Following an user logged on to an Autopilot device with standard user permission and a device without Autopilot and local administrator permissions:
Now you know my intention for this blog post. I was inspired by Nick Hogarth blog post (Intune – Win32 app Deploying BGInfo) about this and re-discovered my need 🙂 and took his solution and developed it a little further for my needs (thanks Nick!). I can recommend to read his blog as well as he has a nice walk through how to create and upload the Intunewin package for Intune and trace the installation itself. Like Nick I only focus on the x64 Edition of BGInfo64 as I’m not dealing with x86 devices for a long time now.
First I had to came up with a way to identify if the user is a local admin. BGInfo supports various ways to get OS information and one option is to use vbs scripts. So I wrote a short vbs script to verify local Administrators group membership. To handle this in a way to be language independent I’m resolving the local Administrators group SID S-1-5-32-544 (read about well known SIDs here) to the localized display name to finally enumerate account membership.
The vbs script is dynamically written by the install script as CheckAdmin.vbs to the BGInfo install folder (C:\Program Files\BGInfo) during install. This way I do not have to maintain several files, only my install script. I followed the same way and created an install.ps1 to install BGInfo64.exe with the custom background information file custom.bgi. In addition I modified the startup shortcut creation to create the shortcut with the ActiveX object WScript.Shell in the PowerShell install script. The startup shortcut is needed to always have actual information on the background. Following the complete install.ps1:
To also provide uninstall capabilities I created the small uninstall.ps1 as well:
The custom background information file custom.bgi was adjusted to present all information needed. Especially the CheckAdmin.vbs is referenced to get the user permission information:
For completeness I list the two registry keys I used for displaying the complete Version string e.g. 10.0.17763.194 (1809)
-> Windows Release e.g. 1809
-> Patchlevel e.g. 194
All files for the complete Intune Win32 app package can be found in my GitHub account here:
As always when dealing with Intune Win32 apps we need to package it as .intunewin and upload the package to Intune. Use the Packaging tool from here: https://github.com/Microsoft/Intune-Win32-App-Packaging-Tool. The complete conversion can be done in an one liner when the conversion tool is in the same folder structure level as the BGInfo folder with all needed files:
.\IntuneWinAppUtil -c .\BGInfo -s Bginfo64.exe -o .\ -q
For more details regarding packaging see my post: Part 3 Deep Dive Microsoft Intune Management Extension Win32 Apps. As soon as we have the BGInfo64.intunewin package we can upload it and specify the install and uninstall command lines with the install behavior System:
powershell -ex bypass -file install.ps1 powershell -ex bypass -file uninstall.ps1
As the detection rule we use a simple file exists for BGInfo64.exe in the install folder:
C:\Program Files\BGInfo Bginfo64.exe
Finally you can assign it to your devices or users. I assigned it to all my devices as I like to have it on all my test devices:
If successfully installed you should see the following files:
Because it is installed in System context we need to logon once to trigger the startup shortcut to finally execute BGInfo in user context and create the background information. If everything runs fine you should get nice information about the device you are currently using and in which context you are running (admin or user permission).
I hope it may help you as it helps me and gives you an idea how to dynamically get OS parameters for BGInfo and display them.
Happy tattooing you backgrounds!
Some strange thing is happening or i just plain dont understand 🙂
I create a folder BGInfo with all files in it, the setup and the ps1 script.
When i run IntuneWinAppUtil and enter the source folder, setup file and output the intunewin file get’s created OK.
When i open the intunewin file with 7zip and look into the Content folder i only see the bginfo setup file and the ps1 files are missing, is this expected behaviour ?
the content is archived two times within the content folder there is also a .intunwin file. This intunewin file is encrypted with the encryption key information from the detection.xml file from the folder metadata. So what you see is totally normal all files are archived and encrypted into a .intunewin, then the folder structure with content and metadata is created and all this in archived agein to a .intunewin. For a detailed analysis look at the post https://oliverkieselbach.com/2019/01/03/how-to-decode-intune-win32-app-packages/ there I described the process in detail in the beginning.
Oh my god and shame on me.
Due to truncation of the 7zip window i indeed did not see all the files 😦 and the intunewin file in the intunewin file 🙂 had the same name as the installer so missed the extension.
Should have stayed in bed today…
But the installer failed so i presumed files were missing.
I owe you a beer 😉
🙂 no problem. This is how it goes from time to time.
The cmdlet: Copy-Item -Path “$PSScriptRoot\Bginfo64.exe”
Is $psscriptroot a variable for the content/folder of the intunewin file/source folder?
It is basically the folder where the script itself is stored. In this case the .intunewin from the content folder gets transferred to the client decrypted and extracted to the cache folder of the SideCar. So basically in that cache folder the bginfo64.exe, custom.bgi, install.ps1 and uninstall.ps1 is then in that folder. $PSScriptRoot references then to this folder. 👍
Thanks for posting Oliver! saved me a load of time looking into it myself!
Alos noticed when you download the install and uninstall ps1 files from github you need to rename thm as install.ps1 is downloaded as ‘BGInfo64-install.ps1’ and uninstall is ‘BGInfo-uninstall.ps1’.
I’m glad it save you some time :-).
If you download the files via the RAW button on GitHub you should get only the install.ps1 etc. files.
Hi Oliver, I’m looking to deploy this via Intune but seem to be struggling. I can create the intunewin file and it deplys as expected however I am missing certain information and get a specific error when checking the custom.bgi config settings
Microsoft Windows 10 Pro
I seem to be missing the build number and the user type – The error I get when opening the custom.bgi file in C:\Program Files\BGInfo is
Error evaluating scripted filed ‘CheckAdmin’
Microsoft VBScript complitation error
Line1, position 0
Any ideas where to start?
Thanks in advance
I think something went wrong during install. The install.ps1 (https://github.com/okieselbach/Intune/blob/master/Win32/BGInfo64/install.ps1) will create a CheckAdmin.vbs file here: C:\Program Files\BGInfo\CheckAdmin.vbs. I guess this failed due to whatever reason. Can you check and make sure that the install.ps1 is successful in creating all the necessary files under C:\Program Files\BGInfo. Have a look for BGInfo.exe, custom.bgi and CheckAdmin.vbs
Thanks for the script, it’s really helpful.
I just wanted to let you know that I had the same issue as Nathan. I found that if I opened the VBS file that the powershell script creates in notepad, I can copy all of the text in to a new VBS file and then replace the old VBS file with the copy. This seems to resolve the issue. I wonder if the powershell script is adding some hidden character to the start of the VBS file it creates.
a month ago I slightly modified the Out-File command and this fixed the issue for me, so maybe try again with the latest version.
now my question is not 100 percent about your article, but maybe you can still help. I created a Win32 app to copy data to the clients using a PowerShell script. Similar to what you have done. The special thing is that the data should be copied into the user’s registered OneDrive folder. For this I use $env:OneDrive. If I run the script on my client, everything is wonderful. If I distribute the Win32 app via Intune, it creates the folder directly under C: \. Can intune not handle $env:OneDrive at this point? Many Thanks!
the $env:OneDrive environment variable is a user variable so you have to use the script in user context. In system context the variable is not set. Please make sure the PowerShell script runs in user context and not system context… that should solve your problem.
Anyway to troubleshoot this ? All Files show up in Program Files but bginfo never launches and shows up
Any security policies which might block vbs execution or did you check if there is a Autostart entry created…. did you check the content of the file in the Program Files folder, does the vbs script have valid script content…
Thanks for the Super BGinfo
I have same problem as boaBie.
If i create a new Checkadmin.vbs then it works
Thanks to help
Hey Oliver – I have a question and a couple of comments on this:
1) It looks like the install script at one point downloaded the actual bginfo program directly from live.sysinternals.com, rather than including it in the intunewin file. I’m curious, why did you change that? It seems like a great idea to always download the current version, rather than having to rebuild the intunewin file when an update is released.
2) In your comment dated May 11, 2020, you mentioned that you had made changes to the script and suggested trying the latest version. It looks like the github source used to display the code in this post is different from the one you updated though, and the links directly to the install script also point to that original version. You may want to consider updating that to point to the updated version instead. For anyone else reading this, the updated version of the file can be found by clicking the link later in the article that points to: https://github.com/okieselbach/Intune/tree/master/Win32/BGInfo64
3) I appreciate that you gave Nick Hogarth credit and linked back to his post. Unfortunately, it seems he let his site lapse and someone else has now taken it over and I’m not sure how trustworth that site is now. I would suggest that anyone wanting to view the original post that inspired you to access it using the wayback machine, via this address: https://web.archive.org/web/20201027003918/https://nhogarth.net/2018/12/14/intune-win32-app-deploying-bginfo/
I know that your article is a few years old at this point, but it’s still being referenced and helping others today. Thank you for sharing with the community!