Anyone try BGInfo in a layer?

I'm not familiar with bgInfo but from your description is seams like it's related to layer visibility and priority and this is a common problem with programs that have ini/config files you edit.

By default something in a layer will check to see if that file exists in the layer.

If it doesn't find that file it will check in other layers next.

Lastly it checks the base (non-virtualized files).

What's most likely happening is you are editing the config file via something like notepad, which is in the base not a layer, the changes you're making are not getting saved into the layer but onto the base and when the exe launches it's finding the config file in the layer so it never looks for the config file in the base that has the changes.

There are currently two ways to fix this using 2.x (we've got more ways of resolving this issue in 6.1) and that's to delete the config file out of the layer or run notepad.exe from the layer (via svscmd) and make the changes.

Thanks Jordan - I think your explanation is on the right track but it happens even without the use of the ini file.

A layer consisting of only bginfo.exe will not work properly because when it is launched it needs to change the 'wallpaper' value in the 'HKEY_LOCAL_MACHINE\SOFTWARE\fslrdr\3B\HU\S-1-5-21-9122744-284426325-638672422-33136\Software\Winternals\BGInfo' key but does not.

The corresponding key value does get changed in the base when bginfo.exe is in the base.

So either there is something about SVS and User SIDs that I don't understand or possibly that value is trying to be changed by a base process as opposed to a layer process?

So let me see if I understand.

When the layer is active the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\fslrdr\3B\HU\S-1-5-21-9122744-284426325-638672422-33136\Software\Winternals\BGInfo does NOT get changed but if the exe is in the base it does?

If that's the case open up the advanced layer editor for the layer (double click on it when it's inactive) and navigate to the registry tab and then under Read/Write see if you can find that key and let me know.

When the layer is active the 'wallpaper' value in the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\fslrdr\3B\HU\S-1-5-21-9122744-284426325-638672422-33136\Software\Winternals\BGInfo does NOT get changed.  If I deactivate the layer and use the editor, I see the exact same thing.  The value is there but it does not get changed.

If the exe is in the base then the the 'wallpaper' value in the 'HKEY_USERS\S-1-5-21-9122744-284426325-638672422-33136\Software\Winternals\BGInfo' DOES get changed.

Thanks,

Gary

Can I get a link to where that app is downloaded from?

Sure.

It's one of the Sysinternal utilities - now owned by Microsoft.

http://technet.microsoft.com/en-us/sysinternals/bb897557.aspx

BGinfo works by taking a copy of the wallpaper and editing the graphic with an overlay of the data required from your settings in the INI file. The updated wallpaper file then replaces the default wallpaper file specified for your system.

I'm guessing that the updated wallpaper file is in your layer, not in the base, so priority may well play a part here.

In addition, if you are not running as an admin user, you may not have sufficient permissions to create the modified wallpaper file, as the files are usually in the windows folder tree, where standard users only have read permissions. So you may also need to play around with the location of the default wallpaper file, so that permissions can be set as required without having to open up the windows folder.

As correctly explained by EdT , the main problem is the location of the wallpaper changed  by the BGI Info tool.

Default setting for the BGI info wallpaper position is the "Windows directory", so better setting could be located somewhere else the wallpaper changed by BGI info.

In the Bitmap and Location menu , there are some settings where configure the wallpaper location.

Replace settings  %WinDir%\BGInfo.bmp, with the  User's temporary files directory : %TEMP%\BGInfo.bmp or better on Other directory : %userprofile%\BGInfo.bmp.

Not being admin would cause this issue, though I'd be surprised if that was the cause, and being in the windows directory shouldn't be a problem.  Priority might be playing a role here, with windows not seeing the updated info in the layer before it sees the stuff on the base but by default that shouldn't happen.

I am running as admin so that is not the issue.

Windows is seeing the info in the layer first - but the problem is that the layer info is not getting updated when the layer is active and the exe is run.  From what I can tell it is the layer registry key/value that I mentioned above that is not getting updated properly when the layer is active. 

 Could it be that you would need to restart the explorer.exe process for the background to be updated correctly?

If you set the layer to autostart would it show the correct updated background during next start of windows?

Normal (bginfo.exe in the base)

• Current wallpaper is found here: HKU - SID - Control Panel -Desktop / Wallpaper
• BgInfo exe launched
• BgInfo looks at above key and does two things:

1. records the existing wallpaper here: hku - SID - software - winternals - bginfo / wallpaper
2. creates a 'stamped' copy of this wallpaper, names it bginfo.bmp, and forces a copy to HKU - SID - Control Panel - Desktop / Wallpaper (which becomes the new wallpaper).

BgInfo in a layer doesn't work because of a problem at the 3rd bullet point above:when bginfo looks at the hku-sid-control panel-dekstop/wallpaper value it looks at the layer registry value and sees the old bginfo.bmp file and not the new current wallpaper. 

Is this a situation that would require a registry exclude? Haven't run into any of those yet so not sure under what circumstances those would be used (once they are available).

Hi--

As I understand it, this is the same situation that would require a registry exclude.

This is great, I was having the same issue.  Thanks for explaination.

Nichant

 Gary, did you get it working yet? I'm curious since we use BgInfo too :)

George - Nope, not yet.  Too many higher priority projects going on.
Not sure if there is a way to have the exe in a layer without some kind of registry exclude.

Have you tried to use SWV (Symantec Workspace Virtualization) instead?
It has some new features as isolation that may well suite your needs for bginfo.

The problem is not SVS but how Windows behaves.  I did some testing and let me tell you what's going on.

Scenario 1:

I create a layer and place BGinfo into the layer, Activate it and then launch BGinfo. and my wallpaper changes.  The new wallpaper gets saved in the layer under windows.

Now I deactivate the layer and the background doesn't change, refreshing doesn't change it, the only way to get the wallpaper to change is by changing the resolution or by changing the wallpaper.  This is expected because the wallpaper is loaded into memory so just deactivating the layer isn't going to switch back to the old one (you could set up an OnEvent Notification for this though) because you need to tell windows to reload the wallpaper found at HKUSERS\SID\Control Panel\Desktop.

Scenario 2:

After deactivating I change my wallpaper to something different then the original and activate the layer and run BGinfo.  I delete a few items from the list and click apply.  The old wallpaper appears with the new info.

This is expected because of what's stored in the layer.  Under HKUSERS\SID\Software\Winternals\BGinfo you see that the wallpaper key is set to the original wallpaper (in my case Bliss, the default XP wallpaper) and that doesn't get updated just by running BGinfo.  You can to use the Desktop butting to get this setting to change for some reason, I think because BGinfo switches what's in HKUSERS\SID\Control Panel\Desktop with whats in the key mentioned above so the current desktop never gets checked (this would be the only key we'd have to apply a registry exclude to) because it's checking the layer first and finding the keys it needs.

Thanks Jordan...I think you confirmed what I posted in the 'this is the problem' post.
I didn't realize though that the 'stamped' data was updating properly...thanks for pointing that out.  The way it's working would be okay if we had a locked down wallpaper scheme but we don't. 
The important thing is that you confirmed that this is a situation that would require a registry exclude (in order for end user to be able to change their wallpaper and have it 'stamped' at startup).   Hadn't run into a registry exclude situation before this.
Are there any other 'virtualizations' that you know of where a registry exclude is needed in order to get app to work as desired?
Thanks,
Gary

I could get this working without an exclude using onPreActivate.  Just have some vbscript that checks the current desktop and make the change to the registry in the layer before it's activated.  You could use WMI to get the location of the layer's virtualized registry, the user SID and probably the current desktop.

As for registry excludes, I'm sure someone has a list around here but I can't think of any off the top of my head.

You can also just use it as a swd task.  Schedule it to run at login.  It is also possible to pass data from inventory to that machine, but that could be a different post.