BgInfo deployment via Group Policy

BgInfo Introduction

BgInfo is a Windows Sysinternals tool that displays relevant information about the Windows computers on its desktop. This article will outline deploying this tool via Group Policy. Our goal will be to deploy one policy with more information for administrators for our server environment, and a second Group Policy that simply shows the hostname and IP address for end user workstations.

BgInfo can be downloaded at:

Once downloaded, extract the files. The extracted directory will have (3) files: Bginfo.exe, Bginfox64.exe, and Eula.txt.

When opening up the Bginfo.exe, it will pull up the default configuration.

One issue is with the IP address field. This will show IP addresses for unassigned adapters, which can create confusion. Per a post by Zlatin Kostov, he shows how we can use a WMI query with the IPEnabled flag to remove these unassigned adapters:

Zlatin also shows how we can query a registry value to identify the virtual host. We will use this value for our server policy.

BgInfo Setup

Following his example, we will create a new custom fiegInfold named “IPAddress” (must differ in name from current IP Address field), using a WMI Query.

Choose from the WMI Class:


Choose from the Class Property:

IPAddress WMI Query

When the WMI Query populates, append it with the entry WHERE IPEnabled=TRUE, so the complete query will reflect:

SELECT IPAddress FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled=True

Choose the “Evaluate” button to test your query.

For the Virtual Host, create a ne.w custom field named “VM Host”

Choose “Registry Value” and “64-bit registry view”

For path insert:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters\PhysicalHostName

Click “OK”  if you receive the message “The specified registry value does not exist” click “OK” to proceed.

wmi query

Once done with the custom entries, go ahead and configure BgInfo for your servers. Once done with fonts, position, and your entries, choose “Save As” and save with a name for this deployment, i.e. “Server_BgInfo”.

Repeat to create your settings you want for your desktop deployment. Save your configuration, i.e. “Desktop_BgInfo”.

Next we will copy bginfo.exe, and our two (2) new “.bgi” files to the active directory netlogon directory, creating a folder for these items named “BgInfo”:


netlogon path

We will now create our Group Policies. Open “Group Policy Management” and create or modify a policy.

This is where I deviate from Zlatin’s post – he used Group Policy Preferences to copy the files to each host, then create a shortcut to launch them – instead I propose we use Group Policy Preferences to skip to the shortcut part, but launch from the netlogon share…

I propose we use Group Policy Preferences to create a shortcut that launches for all users that points to the netlogon folder; within Group Policy Management, go to:

Computer Configuration -> Preferences -> Windows Settings -> Shortcuts -> “New Shortcut”

Name: Server_BgInfo

Target Type: File System Object

Location: All Users Startup

Target Path:



\\domainname\netlogon\BgInfo\Server_BgInfo.bgi /SILENT /TIMER:0 /NOLICPROMPT

Click “OK”

Finally – we may see trust issues in launching this application.

First, browse to the netlogon directory \\domainname\netlogon\BgInfo\ and right click on BgInfo.exe. Check the “Unblock” button on the general tab:

bginfo properties

Secondly, we need to force trust to our netlogon directory. Within your Group Policy Management console, most likely modifying your Default Domain Policy, and browse to:

Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page

Choose “Site to Zone Assignment List”, ENABLE the policy, then “SHOW”

For Value, add your domain name, and set a value of “1” (for Intranet).

Site to zone assignment

Assign your policy to the correct Organizational Unit. Test by using “gpupdate /force” via the command line.

Setup a second policy for desktops, making sure that it is assigned to the correct Organizational Unit.



Local Administrator Password Solution (LAPS)

LAPS (Local Administrator Password Solution) is the recommended security solution to mitigate PtH (Pass the Hash) attacks of a local administrator account on your network.

Local administrator accounts are a bane to network administrators. Physical access can compromise the local account, and it is typically standardized across the domain as a secondary tool for the help desk and administrators when computers lose trust with their respective domain controllers. A compromised local administrator account has the potential to create havoc across your network.

LAPS can provide your environment with a local administrator password that is unique for each workstation, and provide basic password management, with manageable length, complexity, and age requirements based on your group policy. You can also determine what security groups are able to retrieve these passwords through a component (the Fat Client UI). This is discussed in more detail in the Microsoft Security Advisory 3062591:

The installation of LAPS comprises of the following steps:

  1. Download and install components on the management server
  2. Update the active directory Schema
  3. Set the permissions for viewing the local administrator password
  4. Push the client install component to the managed computers
  5. Set the group policies for LAPS
  6. Retrieving the password


Download and install components on the management server

The LAPS components can be downloaded from Microsoft at the following site:

There is both a 32 bit and a 64 bit msi that may be downloaded for your environment. We will create a GPO to deploy both based on the architecture later in the article.

In this article, the installation of the LAPS management components will be installed on a Windows Server 2012R2 Domain Controller.

Install LAPS
Install LAPS









Select all of the components, and complete the installation on your management server.


Update the Active Directory Schema

The management tools installed the PowerShell module on your management server. Run PowerShell as an administrator with an account that is a member of the built-in Schema Admins group.

Import the module within the PowerShell prompt:

Import-Module AdmPwd.PS

Then update your schema with the following commandlet:












Set the permissions for viewing the local administrator password

We will use ADSIEdit to manage the permissions on who is able to view the new attribute created.

Open ADSIEdit, the right click ADSI Edit and “connect to”










Then choose the “Default naming context”:






You will now need to drill down through your OU’s to the correct container the computers to be managed. Right-click on the OU, and select “Properties”. Choose the “Security” tab and click on the “Advanced” button.











You now need to audit the accounts within the advanced security settings, ensuring that non-administrative accounts do not have the “All extended rights” permission. This is to be UNCHECKED.









Set the permissions for viewing the local administrator password

Next we need to allow the computers in are specific OU(s) the ability to update their password attributes, via the AdmPwdComputerSelfPermission PowerShell commandlet, specifying the correct distinguished name for each OU:

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=SBSComputers, DC=infosoda, DC=local"

Hint: Right click on the OU, select “Properties”, choose the “Attribute Editor” tab, then “View” the distinguishedName to copy the correct distinguished name for your OU.

We then set the permissions per OU to the security groups that are allowed to retrieve the password set by LAPS using the AdmPwdReadPasswordPermission PowerShell commandlet, specifying the correct distinguished name for the OU and the correct security group:

Set-AdmPwdReadPasswordPermission -Orgunit "OU=SBSComputers, DC=infosoda, DC=local" -AllowedPrincipals "Help Desk Support"

In the above example, members of the security group “Help Desk Support” can retrieve passwords for all computers within the SBSComputers OU. Repeat this step as necessary to ensure that the correct groups have access to the correct OUs.


Push the client install component to the managed computers

We can now create a policy to push either the x64 or the x86 client out to the machines, based on their architecture. Create a folder in your netlogon directory, and drop both the LAPSx64 and the LAPSx86 msi’s that we downloaded earlier into the new folder:






Now open up Group Policy Management, create a new group policy object named appropriately, end edit the new policy.

Computer Configuration -> Policies -> Software Settings -> Software Installation -> New -> Package

When creating the x86 installer, uncheck the “Make this 32-bit X86 application available to Win64 Machines






Assign the policy to the correct OU’s to allow policy to push out the MSI to the computers. Once installed, “Local Administrator Password Solution” will appear as an installed application under “Programs and Features”.


Set the group policies for LAPS

Utilizing either the same Group Policy, or a separate policy, you now need to implement your settings for LAPS. These settings are located at:

Computer Configuration -> Policies -> Administrative Templates: Policy Definitions -> LAPS

There will typically be (3) settings to enable:

  • Password Settings
  • Do not allow password expiration time longer than required by policy
  • Enable local admin password management







Password Settings (ENABLED): Choose password complexity, password length, and password age, recommended settings:

  • Password complexity: Large letters + small letters +numbers + specials
  • Password length: 20 characters
  • Password age (days): 30 days

Do not allow password expiration time longer than required by policy (ENABLED)

Enable local admin password management (ENABLED)

Link the policy to the correct OU’s if it is a separate policy, and allow the policy to deploy to the environment.


Retrieving the password:

The easiest way to retrieve a password configured by LAPS is to fire up the LAPS UI application installed on your management server. Launch the LAPS UI application, type in the computer name, and the application will retrieve the password and the current expiration date. By enabling “Advanced Features” within Active Directory Users & Computers (View -> Advanced Features), you can also view the Attribute Editor tab, and the specific attribute “ms-Mcs-AdmPwd” to retrieve the password:








Deploying LAPS is a great way to add an additional layer of security to your environment. It also allows administrators the ability to easily manage and create local administrator policies for your environment.

Deploying printers via Group Policy Preferences

Deploying large numbers of printers to the correct individuals in a large environment is always a challenge. I personally am a fan of utilizing Group Policy Preferences, and the multiple filters available for the individual preferences.

There are several obstacles that need to be addressed to guarantee the success of your deployment, and I will outline the common issues I have seen.

Within your group policies, you need to disable “Point and Print Restrictions”, which are labeled as:

Package Point and Print – Approved Servers (DISABLED) – this could also be enabled and specify the print server(s) that will be storing your drivers

Only Use Package Point and Print (DISABLED)

Point and Print Restrictions (DISABLED)

Disable Point and Print

These settings can be found at:

Computer Configuration -> Policies -> Administrative Templates -> Printers

With the point and print policy changes being tied to a computer configuration, I personally prefer separating computer configurations from user configurations where they make sense. For example, if the firewalls are to be disabled for computers on the domain, I would usually integrate these settings with the firewall policy, since both are machine based. This also allows for more obvious filtering on the user side, such as not applying a printer deployment GPO to admins (assuming our printer deployment preferences are based on user logins and thus are user based).

I do still see remnant XP machines in environments that are somehow holding out against modernization. These machine also require KB93729 – Group Policy Preference Client Side Extensions for XP to be deployed to the XP machines in order for them to recognize the preferences.

After you have prepped your Active Directory, you will now move on to your print servers…

There are several rules that must be followed in order to deploy printers:

  1. If you are in a mixed architecture environment, do you have the same version of the x86 and x64 driver installed? The driver must have the same driver name and driver version in order to deploy.
  2. Have you set up your print drivers to use the winprint print processor? HP printers are notorious for deviating from this, and must be set to winprint. WINPRINT Please!
  3. I would also verify the use of TCP/IP ports, again HP printers can create a deviation from this. (Did you notice we are utilizing DNS names?)  Printer ports
  4. Printers must be both shared and listed; typically admins will share them but forget to list them. You can modify this setting in the share tab of each printer, or select all of the printers, right click, and “List in Directory”.

Listing in directory

Other recommendations are going to be dependent upon your environment. If you are dealing with large numbers of printers, it will also be a good time to explore using PowerShell to modify settings en masse.

Once we have made our adjustments on the print server, we can create a GPO and edit it to create our preferences. The user preferences for printers may be found at User Configuration -> Preferences -> Control Panel Settings -> Printers

Selecting GPP in User Settings

I typically deploy “Shared Printers”, but in the case where you just want to push local printer connections, you would choose “TCP/IP Printer”. This would be useful for a remote office with  out a local server, that needs to print directly to their printer to avoid “hairpinning” all of their print jobs.

To Share or Not to Share

Create the appropriate printer connection type by right clicking on the “Printer” preference and choosing “New” and your printer connection type.

Group Policy Preference Actions… you will have the choice of Update, Create, Replace, and Delete. This may be up to debate, but I have always been under the impression that the default of “Update” is typically best for most deployments. This setting will check the preference, and deploy or modify as needed. “Replace” is an absolute, and will always deploy the printer, and overwrite it if it already exists. “Create” is also very common, and will create or ignore if the printer has been deployed. The last setting is fairly obvious and requires no explanation.

Now if you listed your printers correctly, you will be able to see them when you choose your printer “Share Path”. Simply select your printer here.

You do have the option to alienate end users and “Set this printer as the default printer…”

Now select the “Common” tab – this is where the possibilities start to multiply, specifically under “Item-level targeting”. Item-level targeting is a filtering mechanism available for every Group Policy Preferences setting available. Do you want to filter the deployment of this printer by IP address? You can filter by OU, by user, by security group. You can even filter by terminal session, so if you are using a terminal server, you can filter by session or the the client’s IP address. We also can create statements, such as “The user is a member of the security group “Human Resources” and the IP address of the workstation is “” which allows this user to see the HR printer in our Richmond office.

As a foot note to the item-level targeting, I typically like to exclude Domain Admins for example from having printers deployed to them as they bounce between machines. Typically, I will highlight the GPO, choose the “Delegation” tab in the GPO pane, and choose “Advanced”. This will open a security settings window. Add or select the appropriate security group, and “Deny” the “Apply Group Policy” security setting.

Denying Domain Admins