Deploying Win32 app BGInfo with Intune

Deploying BGInfo to quickly find your test devices or provide easy VM access during trainings with more visibility of the available user permissions.

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. 

GitHub Listing – CheckAdmin.vbs

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:

GitHub Listing – install.ps1

To also provide uninstall capabilities I created the small uninstall.ps1 as well:

GitHub Listing – uninstall.ps1

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) 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ReleaseId

-> Windows Release e.g. 1809

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR

 -> 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: 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

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!

Configuring Windows Defender Credential Guard with Intune

The Windows Defender Credential Guard is a feature to protect NTLM, Kerberos and Sign-on credentials. Windows 10 Enterprise provides the capability to isolate certain Operating System (OS) pieces via so called virtualization-based security (VBS). NTLM and Kerberos credentials are normally stored in the Local Security Authority (LSA). Once VBS is enabled the LSASS process will be split into an isolated process (protected by virtualization based security)  called LSAiso and the LSASS process. The LSAiso process can not be accessed by other OS components than the LSASS. This approach protects credentials from malicious tools which gained system context access. A well known tool to accomplish extraction of credentials from LSASS in system context is Mimikatz. This will not work after enabling Windows Defender Credential Guard as the only process validated to gain access to LSAiso process is LSASS.

With that in mind Credential Guard can protect an attack vector used by a lot of bad guys trying to steal sensitive information. It’s really worth considering to turn this protection on for Windows 10 Enterprise x64 (no support for x86) devices.


Further information of Credential Guard:

How do we configure this via Modern Management in Intune?

Since Windows 10 Version 1709 Microsoft provides Policy CSP support to configure Credential Guard via custom OMA-URIs. We can create a custom device profile:


and then choose Profile type: custom


Here we add the following OMA-URIs to configure Credential Guard with default settings and additional DMA Protection:

Name: DeviceGuard/EnableVirtualizationBasedSecurity 
OMA-URI: ./Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity
Data type: integer
Value: 1 (enable virtualization based security)

Name: DeviceGuard/LsaCfgFlags
OMA-URI: ./Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags
Data type: integer
Value: 1 (Enabled with UEFI lock)

Name: DeviceGuard/RequirePlatformSecurityFeatures
OMA-URI: ./Vendor/MSFT/Policy/Config/DeviceGuard/RequirePlatformSecurityFeatures
Data type: integer
Value: 3 (Turns on VBS with Secure Boot and direct memory access (DMA). DMA requires hardware support.)

Further information regarding Policy CSP values:

As a last step we assign the new device configuration profile to our user group we want to provide the additional Credential Guard protection.

It is now possible to configure Credential Guard with the built in “Endpoint protection” configuration profile see screenshot below. The described way is still possible but a much easier way is to use the Endpoint protection configuration profile for Windows 10 now.

How to verify successful configuration?

First of all we verify if Intune applied the configuration successfully:


Then you can verify the applied registry settings on the target device of the user:


Further information regarding registry settings:

Make sure the device was restarted after successful configuration! This is needed as Credential Guard relies on Hyper-V technology for virtualization-based security and therefore it will enable the feature Hyper-V Hypervisor component.

We can have a look for the LsaIso.exe process in task manager:


Finally we open up msinfo32.exe and verify if virtualization-based security is running and Credential Guard is activated:


If everything went well your machine is now protected against stealing of password secrets (hashes) which can be used by attackers for Pass-The-Hash (PTH) attacks. Keep in mind that this will not protect against attacks like key loggers. The solution is an effective way to protect credential stealing from memory.

How to test this in a Hyper-V Virtual Machine?

When using Microsoft Hyper-V you can enable nested virtualization on the VM and enable the Trusted Platform Module. Now you can test Credential Guard in your Hyper-V VM.

Enabling nested virtualization on Hyper-V VM:

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

Further information on nested virtualization:

Enabling the TPM on Hyper-V VM:


Additional things to consider?

The target hardware must support Credential Guard

Compatibility problems

Limitation in protection


Virtualization based security (VBS) will be available for non-Enterprise SKUs and starting with RS4+ VBS will be automatically enabled for clean installs!

If you are using Windows 10 please try Credential Guard in your environment as it is a really big security enhancement of Windows 10 Enterprise.