Updating BgInfo when VMware View desktop changes locations

In my previous article “Using BgInfo with VMware View,” I discuss how to use Microsoft’s BgInfo utility within a VMware View desktop pool to write the following information to a user’s wallpaper:

  • Username
  • Physical and Virtual PC name
  • Physical and Virtual IP address
  • Physical and Virtual MAC address

Example of BgInfo wallpaper for my VMware View environment

BGinfo Desired Result


My BgInfo solution is great. It helps users know they are accessing their own virtual desktop (nurses and doctors frequently move from one PC to the next) and helps the Help Desk identify who is working where (by computer name, IP, or MAC address).

The primary problem is that my initial solution ran BgInfo only at logon. When nurses and doctors switch from one physical client to another (typically stationary thin or zero clients), BgInfo’s values are not updated and were now displaying stale IP/MAC values for the physical client.

The secondary problem was that monitor resolutions vary, sometimes forcing the BgInfo content out of view.


The solution was to leverage Group Policy Preferences, Scheduled Tasks, and Event Logs. I wanted to use these three tools to trigger BgInfo to run whenever a user moved their VMware View virtual desktop from one location to another. Here’s how I did it.

Open your Group Policy Management Editor, create a new Group Policy, and click Edit. Navigate to User Configuration > Preferences > Control Panel Settings > Scheduled Tasks. Right-click > New > Scheduled Task for Windows Vista or greater.

GPME Scheduled Tasks

General Tab

Give it a useful name and then stick with the defaults.

GPME General Tab

Trigger: At Logon

Create a new Trigger to run GpUpdate 30 seconds after logon. When using the PCoIP protocol, I’ve found that some zero and thin clients resize shortly after logging the user into their desktop. Having BgInfo run 30 seconds after login makes sure it appears in the right spot.

GPME Triggers Tab

GPME Trigger At Logon

Trigger: On an Event, after Group Policy update

This was my first solution. If I could get BgInfo to randomly run several times a day, I’d have more accurate information. Since Group Policy updates occur about every 90 minutes, I configured this Scheduled Task to run after EventID 5315 (Log: Microsoft-Windows-GroupPolicy/Operational; Source: Microsoft-Windows-GroupPolicy) appeared in the virtual machine’s Event Logs. Additionally, the Help Desk could ask a user to run “gpupdate” to refresh BgInfo at will.

GPME Trigger After Group Policy Update

Trigger: On an Event, after Terminal Services logon

This proved to be the better solution. When a user logs into their VMware View desktop from another location, EventID 25 (Log: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational; Source: Microsoft-Windows-TerminalServices-LocalSessionManager) appears in the virtual machine’s Event Logs. If I could get BgInfo to run every time this event occurred in the logs, then the BgInfo would remain accurate as the user moves from one location to another.

GPME Trigger After Terminal Services

Actions Tab

Create a new Action that silently runs BgInfo from a network share. I use a VB Script that silently launches a BAT file.

GPME Action Tab

GPME Action Tab run VB Script

VB Script

Set oShell = CreateObject ("Wscript.Shell") Dim strArgs strArgs = "cmd /c \%LOGONSERVER%\netlogon\Bginfo-nonpersistent.bat" oShell.Run strArgs, 0, false

BAT file

@echo off %logonserver%\netlogon\bginfo.exe %logonserver%\netlogon\Bginfo-nonpersistent.bgi /Timer:0 /NoLicPrompt /silent

Conditions, Settings, and Common tabs

I’m not using these tabs.


By using Group Policy Preferences to create a Scheduled Task that monitors specific Event Logs, we’re able to have BgInfo run and update a user’s VMware View desktop wallpaper each time they move from one location to another.

3 replies on “Updating BgInfo when VMware View desktop changes locations”

  1. Hi,

    Why not use the Vmware VIew ADM Template option of Run this command on Reconnect?? As per https://divyen.wordpress.com/2011/07/02/running-scripts-commands-on-vmware-view-desktop-connect-reconnect/ and other articles I have read. I just want to know if you’ve tried this and found it lacking so had to resort to another solution, or if you didn’t realise it was available. I am looking at running some processes on re-connect and want to find the best way around it.

    The other question would be are you using PCOIP clients? As they may not trigger the Terminal Services Connection event as they are not using Terminal Services.



  2. GilesB, Thank you for reminding me of the VMware View ADM Template “Run this command on Reconnect” option. This would have been a much similar solution that the one I crafted up.

    I am using PCoIP clients and my solution still works. Because I’m using Scheduled Tasks I can add a delay to some reconnect tasks. For example, I might want some things to happy right away after reconnect but others to happen 30 to 60 seconds after reconnect (like updating BGinfo, which is less important and should not take away resources that are being used to map printers).

  3. Jason,

    Just found this site a few days ago while looking for a solution to a bginfo issue I have with Linked clones. First of all, great site and a lot of great info!

    I was wondering if you have seen this happen, we have about 200 VMs Linked clones running Win 7 Enterprise, that we have a GPO to run a custom BGINFO at logon. But almost exactly 30 seconds after the desktop with the BGINFO loads, the information disappears. The script calls BGINFO from the local Domain Controller’s Netlogon folder. We can re-run the batch file to redisplay the info, and that might last for 3-5 minutes before it disappears. This is driving me nuts…..

Comments are closed.