BGInfo for Windows 10

Years ago, Mark Russinovich of Sysinternals fame (since bought by Microsoft) released the BGInfo utility, which served two purposes: to put various system information such as the computer name and free hard drive space on the desktop, and likewise to put the same info on the lock screen. In a large environment, that latter feature was extremely useful as it enables users and technicians to quickly see the name of a PC without having to log on and find the info.

Unfortunately, Microsoft changed the way the lock screen was handled in Windows Vista and 7, which broke BGInfo’s lock screen functionality. Windows 10 changed things yet again and while BGInfo has been updated to support Win 10, we could not get it working for the lock screen. I don’t want to say it’s not possible, because there may be some combination of using the program along with group policy to display the info on the lock screen, but in our environment it did not work.

Anyway…we really wanted this functionality so I began to look into ways of hacking something together…and boy is this a hack.

Before I go any further, I want to clarify the terms I’m using:

The lock screen is the screen (wallpaper) displayed before a user has logged on, or when the logged-on user locks the computer. {WIN}+{L} for example. In Win 10 RTM and 1511, this disappears before the user is prompted for credentials.

The login screen is the screen where a user actually enters their credentials. On Win 10 RTM and 1511, this background will either be a solid color or the neon-blue Windows wallpaper. On 1607, the lock screen image will remain even once the login fields are shown.

As is seemingly always the case with Windows 10, half the battle is figuring out how aspects of the OS actually work; only then can you determine how to best control things. The below represents my best efforts at understanding what’s going on behind the scenes; if you know otherwise or can add to the discussion, please leave a comment. Also, while some of the settings below can be controlled through group policy (and one must be), I elected to deal with the registry directly as doing so kept all the changes in one place.

Additionally, the way the lock screen works is different in build 1511 (Threshold 2), 1607 (Anniversary) and 1607 with the September cumulative update. These scripts will work with either 1511 or a fully-patched 1607, at least as of this writing. They may however work differently between the two builds, as well as on an existing user profile versus a new one.

There are two sets of lock screen settings: the system-wide machine setting, and a user setting which is (predictably) specific to each user.

For the system-wide settings, we have:

HKLM\Software\Policies\Microsoft\Windows\Personalization\NoChangingLockScreen – Set to 0 to allow the user to change the lock screen, 1 to prevent changes.

HKLM\Software\Policies\Microsoft\Windows\Personalization\LockScreenImage – This is the full path to the lock screen file.

The in-box lock screens are located at c:\windows\web\screen and there does not appear to be a way to select anything other than these default images through the UI.

For the user-specific settings, we have:

HKCU\Software\Microsoft\Windows\CurrentVersin\ContentDeliveryManager\RotatingLockScreen – Set to 0 for a fixed image, or 1 for Windows Spotlight.

Windows Spotlight is a feature by which Win 10 downloads new lock screen images on its own, rotating them from time to time. If Spotlight is enabled, the below registry keys are relevant:

HKCU\Software\Microsoft\Windows\CurrentVersion\Lock Screen\Creative\HotspotImageFolderPath – Path to the user’s downloaded images

HKCU\Software\Microsoft\Windows\CurrentVersion\Lock Screen\Creative\PortraitAssetPath –> Full path to the lock screen file for portrait (vertical) layout

HKCU\Software\Microsoft\Windows\CurrentVersion\Lock Screen\Creative\LandscapeAssetPath –> Full path to the lock screen file for landscape (horizontal) layout

Now in theory, if a computer (HKLM) policy is set to prevent the user from changing the lock screen image, the user should receive the same lock screen, but what we found instead was in some cases on build 1511 the user’s setting would override the computer’s setting. In other words, we would have a fixed lock screen for the computer when nobody was logged in, but once a user logged in, their lock screen settings (which default to having Spotlight enabled) would take precedence. This meant we’d have one lock screen for the computer, and one lock screen for each user. 1607 seems to work properly in that setting a lock screen at the HKLM level prevents any user changes from being made.

On 1511, I recommend enabling the group policy Computer Config à Policies à Administrative Templates à Control Panel à Personalization à Prevent changing lock screen and login image. If you do not do this, the user retains the ability to change their lock screen even though they technically should not.

There are a lot of moving pieces here. The download includes both a startup and login script; on 1511 you need both. On 1607 you can get away with just the startup script however you will lose some functionality in doing so. Here’s what each piece does:

Startup Script

• Check if we’re running on Win 10; if not, exit.
• Choose a random picture from c:\windows\web\screen, and save it out to c:\programdata\bginfoscreens
• Determine the size of the display; this unfortunately running this at startup or shutdown is problematic, so we’re doing a few different things:
  • Attempt to determine the size; the default return value is 1024×768. If we get that back, assume we have bad info.
  • If we have bad info, attempt to read c:\program files\bginfo\resolution.out, which is a text file created by the login script, containing the correct resolution.
  • If we have resolution.out, use the resolution there; otherwise stick to the (likely incorrect) data we collected earlier.
• Resize the picture chosen earlier to our screen resolution.
• Write out our desired info to the resized picture. We attempt to adjust the text positioning to fit the image.
• There’s some code here for debugging purposes, where you can choose to display additional info on the screen if the system name matches a certain pattern.
• Save the image.
• Set the new lock screen by making changes to the registry.

Login Script

• Check if we’re running on Win 10; if not, exit.
• If you set $enablenetworkcollection to $true and provide a valid, user-writable path as $networksspath, the login script will copy the user’s Windows Spotlight backgrounds to a network share. This is useful if you want to have a larger pool of pictures for the computer lock screen. If you choose to do this, you will eventually want to disable $enablenetworkcollection and use whatever method you like to copy this collection of pictures to c:\windows\web\screen
• If you collect these images, you will need to rename them to .jpg and also filter out any that are not the proper resolution. I’ve included a quick and dirty script, “CheckResolution.ps1” which will do this.
• Determine the screen resolution; unlike the startup script, this should always be correct. We save it to a file so the startup script can access it on subsequent reboots.
• Read the registry to determine where the user’s lock screens are located; if we don’t find the keys the rest of the script is meaningless, so we exit.
• Find a random image to work with, checking if it’s 1920px wide.
• Code to save images to a network location if $enablenetworkcollection is true.
• Resize the picture chosen earlier to our screen resolution.
• Write out our desired info to the resized picture. We attempt to adjust the text positioning to fit the image.
• Save the image.
• Set the new lock screen by making changes to the registry.

The combination of these two scripts provides a lock screen that rotates on startup and on login (1511) only, as well as displays the info you choose to show. It’s a hack as I said earlier, but it works for us at least, and if nothing else it should provide a starting point for your own environment.

Download the scripts here: http://media.islipufsd.org/Scripts/BGInfoScripts.zip

Note the scripts themselves credits certain other sites and posts I’ve taken code from.

Orphaned VMs on ESXi

Recently we added another host to our VMWare cluster. During testing we discovered a few virtual machines would not vMotion between any of our hosts. It’s not clear if this had anything to do with adding the host or if it was something we only noticed because we were moving guests between hosts, which as a general rule does not happen that often.

To set the stage from the hardware side of things:

• One VMWare cluster, with (5) Dell hosts: (2) 2950s, (2) R720s, and (1) R730
• Shared storage on a FalconStor NSS SAN, connected via a Brocade 6505 FC switch.
• Originally we had a mix of ESXi 5.1 and 6.0, but we’ve since upgraded to all 6.0; the problem didn’t change between versions.

Fairly standard stuff.

When a vMotion would fail, we would get one of a few different errors, most of which were along the lines of:

After that, the VM would show either “(orphaned)” or “(inaccessible)” in vCenter:

Often, the same VM would reappear at the same time as a “discovered virtual machine,” which showed normally in vCenter but still could not be moved between hosts. It also showed the wrong disk space usage, often showing 4GB or less on servers with 60GB or larger drives. Note the guest OS was still running without issue, and the VM could be shut down and started back up without any errors.

We quickly established that this was not limited to a specific data store or specific host since there was no commonality between the guest VMs that had a problem. We also ruled out a storage issue as we have quite a lot of other VMs on that SAN as well as a Windows cluster, all of which was running fine.

Our first troubleshooting step was to remove the guest from vCenter inventory and attempt to re-add by browsing the datastore for the .vmx file. This resulted in two VMs being imported, as shown:

The first VM – i.e. the one without the (1) – would not show any data.

The second copy of the VM would show mostly accurate data:

Note the provisioned and used storage numbers, which are clearly incorrect.

After a while, the registration of the first copy of the VM would fail with an error and no longer show in vCenter.

The second copy of the VM would remain in vCenter but any attempt to vMotion to another host would result in an error (shown below), and the VM would then show (orphaned) in vCenter.

We were back where we started and contacted support.

Support was not terribly useful. I’m not looking to turn this into a rant about VMWare support, so I’ll skip a lot of the details but the short version is that while they did fix this for two of our VMs, they did so in an extremely inefficient manner that involved duplicating the entire VMDK file. So when the same problem appeared on two more VMs I wanted to investigate this further in-house.

Below is the fix we came up with, which is a little tedious but effective and not too time consuming.

• SSH to one of your hosts.
• Navigate to /vmfs/volumes/datastorename/vmfoldername
• Run ls –l for a directory listing

  It’s a good time to review a few things about VMWare file names:

  name.vmx is the virtual machine definition file, which is plain text, and contains info about the VM itself

  name.vmdk is the hard drive definition file, which is plain text as well, and points to the hard drive data file

  name-flat.vmdk is the actual hard drive data

In some cases, either of the definition files could be missing (which would cause a problem), but they were both there for us.

• Keep the SSH session open, and use WinSCP to connect to the same host then navigate to the same folder.
• Use WinSCP to take backup copies of the base vmdk file and the vmx file.
• Open the base vmdk file and take note of the “ddb.adapterType” shown, as you will need this later. Also check to see if “ddb.thinProvisioned” is present, and its value if so.
• Rename the base vmdk file and the vmx files; we’re going to replace both: (This is shown via SSH)

  mv –i name.vmdk name.vmdk.old

  mv –i name.vmx name.vmx.old
  

• Follow this link to recreate the vmdk file. (VMWare KB article 1002511) Note that in step 8, when you need to edit the vmdk file, it’s easiest just to do this directly from WinSCP which is why I suggest using both it and SSH simultaneously.
• Now we need to deal with the vmx file. See this link. Here’s where things get even stranger. Following the post linked to, you select the existing vmdk file with the datastore browser, so the file is clearly there. Yet when you finish the wizard and vCenter goes to create the VM, we ended up with an error that the vmdk file wasn’t found.

  

  Well that makes no sense; the file is clearly there. It’s in the datastore browser and it’s visible through the CLI and WinSCP. It was at this point I noticed something strange. I realize it’s hard to tell with the obfuscation, but there’s a slash “/” missing between the folder name and the filename. Huh.

  I went through the wizard again and paid more attention to what’s shown for the disk file path, after selecting it in the datastore browser:

To be clear, the brackets [] are just part of our naming convention. Notice the total lack though of slashes. I took a shot in the dark and added a slash between the folder and file name, then finished creating the VM and crossed my fingers.

    

• The good news is manually adding the slash fixed the “file not found” error. But why should things get normal now? vCenter again showed two copies of the VM as discovered. Again, the second copy appears operational and the first shows no info. vCenter meanwhile hung trying to create (presumably) the first copy of the VM. Eventually it will timeout.

  Note the second (working) copy of the VM did show a MAC address conflict which appears to be a harmless side-effect of the inexplicable duplication of VMs. I was able to boot the second copy of the VM. You may need to reconfigure the NICs from within the guest OS since in some cases new NICs may be ‘added’ to the system.

• Once this was all done, we had a fully-functional guest VM that could be migrated from host to host without any issues.

Hopefully this problem doesn’t reoccur, but at least we have a viable fix for it if it does. I’d be curious to hear if anyone else knows what may cause this in the first place.

Cisco 2960S and 2960X Mixed Stack

Haven’t had a chance to post in a while but wanted to put this up here quickly…

We recently purchased some 2960X switches, which are capable of stacking with the older model 2960S units. The additional switch(s) can be hot-added, but there are some requirements in order for things to work properly.

• Both (all) switches must run the same version of IOS. As of this writing, Cisco recommended 15.2.2E4(MD).
• The 2960X supports a faster stack port speed than the 2960S. That’s documented. However, what I did not see in the documentation is that the 2960X must be manually set to the slower speed with the command “switch stack port-speed 10“.
• You may need to change the switch template on one or both switches. You can check the current template with “show sdm prefer” and change it with “switch sdm prefer default“.

Hope that helps!

Turn off Windows 10 Notification Sounds

One of the annoying quirks we found with Windows 10 was that system notifications now include an audio alert. That’s not such a big deal at home, but try pushing out 50 applications to a lab of computers, each of which beeps for each application installed, and it gets overbearing. On build 1511 there does not seem to be a direct way to turn off notification sounds, so the best you can do is clear out the audio file within the sound theme.

This is easy enough through control panel – the “Notification” sound is what you need to unset – but of course we need a way of doing this in bulk. Thankfully this is just a registry setting: HKCU\AppEvents\Schemes\Apps\.Default\Notification.Default\.Current

Clear out the (default) entry, and you will remove the notification sound. For once, something nice an easy.

 

 

IE11 on Windows 10 not Displaying Certain Graphics

Windows 10 introduces Edge as its default web browser, but Microsoft made a big deal out of keeping IE11 around for compatibility purposes. And by all accounts IE11 on Win 10 should be functionality identical to IE11 on Windows 7 or 8/8.1. We were surprised then to run into a problem on Win 10 that we did not see previously.

What we saw on a few websites, including an internal site and the Office 365 portal, was some graphics not displaying. The bottom (green) image here is correct, and as you can see the top one is missing the bell and other graphics. Also you can see how the Office 365 portal was missing the icons for various apps.

Again, we were only experiencing this using IE11 on Windows 10. All of our IE policies were applied to all our operating systems, so there should not have been any policy differences in IE11 due to the underlying OS. Turns out though a policy that seemingly has nothing to do with IE was the culprit.

Both of these websites, and no doubt others, actually use icon fonts to display the graphics in question. And on Windows 10 there’s a new policy – Computer Configuration à Policies à Admin Templates à System à Mitigation Options à Untrusted Font Blocking – which, if enabled, will block IE from downloading new fonts. Edge is unaffected.

Once we turned the policy off things went back to normal.

When an Application Really Doesn’t Need Admin Rights

When Windows Vista launched, we made the decision to disable User Account Control – UAC – because it seemed to be an unnecessary complication. We were already tightly locking down our PCs with Group Policy and none of our users have admin rights, so our exposure to threats was comparatively limited. We kept UAC disabled through Windows 7 and our limited use of Windows 8.1, but as we prepped for Windows 10, we needed to completely revisit UAC.

In Windows 10, Metro apps – which includes the Edge browser – require UAC to be enabled to work properly. With UAC disabled we had inconsistent behavior, where sometimes Metro apps would launch, and other times they would fail with the below error:

So it was time to turn UAC back on.

We immediately ran into problems with a couple of end-user applications that were requesting elevation. Since our users do not have admin rights and therefore cannot elevate, these applications would not run. What made no sense though is these were programs that had worked fine with UAC off, and with standard user rights, so it stood to reason they didn’t actually need elevation to function.

Thus began my exploration into why these applications were requesting elevation. They weren’t installers, and they weren’t trying to write to protected directories. Turns out they were just poorly coded.

UAC-compliant applications are supposed to explicitly request the level of permissions they require through an application manifest.

You can use mt.exe found in the Windows SDK to extract and change application manifests.

To extract:     mt.exe –inputresource:myexecutable.exe;#1 –out:extracted.xml

The manifest itself is just XML, so open with whatever plain-text editor you like and look for the section like this:

<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
   <requestedExecutionLevel level="requireAdministrator" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>

Notice the “level” parameter, set here to “requireAdministrator” – this, not surprisingly, tells Windows that the application requires administrator rights and thus must request elevation.

Change “requireAdministrator” to “asInvoker” – this will allow the app to run in the security context of the user launching it. Now we need to import the edited manifest back into the application.

To import:    mt.exe –nologo –manifest “editedmanifest.xml” –outputresource:”myexecutable.exe;#1″

Once that was done, our problem application stopped asking for elevation. Problem solved.

Understand though that this only works because the application didn’t need admin permissions – it just wanted them. An app that actually requires admin rights will not work properly without them.

There was one lingering question I had though: Why did this app actually work with UAC turned off? Turns out the answer is simple. With UAC disabled, when a standard user runs an application that’s set to “requireAdministrator,” the elevation fails silently, allowing the app to launch. Since this particular app didn’t need elevation, it ran fine, and we had no idea of the underlying problem.

Now if we could just get the developer to do things properly…

Customizing the Windows 10 Start Menu for Enterprises

By far the biggest complaint with Windows 8 was the removal of the start menu, and accordingly, it being added back is the most noticeable change with Windows 10. As it turns out though, the start menu in Windows 10 marks a very drastic design change behind the scenes, one that frankly is more significant from an administrator’s standpoint than the mostly aesthetic changes introduced with Windows 8.

There are a lot of “Customize the Win 10 Start Menu” articles out there, but almost all talk about how to make changes using the user interface. Obviously as an admin we need systematic ways of do that through group policies, scrips, etc.

As a school, we try to create a consistent user experience across all our devices. After all, staff and students typically log on to multiple computers over the course of a day. One of the ways we have done that since Windows 2000 was to redirect the start menu to a network share. This has the benefit of supplying the same menu of programs regardless of the computer being used. The user also cannot make any changes to the start menu. Even on Windows 8/8.1 this worked pretty well. I touched on that here.

Windows 10 is completely different, and if you currently redirect the start menu on any prior version of Windows, you are going to have to make significant changes to how you approach doing so.

The first thing to understand is that the “All apps” feature on the start menu is actually a database of applications and shortcuts installed on the system. Keep it in mind; this will come into play later.

Both Windows 10 Enterprise and Windows 10 Education support customizing the start menu via group policy. In theory you create a reference start menu, export it via PowerShell, then assign it via group policy as desired. In reality, that doesn’t work so well. When we tested it we found many of the pinned items were simply missing from the start menu. And thus began – as one of my colleagues likes to call it – the “trip down the rabbit hole” to find out what was happening.

A quick note…most of the below are things I can’t verify through a 3^rd party; there simply is no information out there. Nearly everything here is a result of my own testing and some best-guess conclusions, and I’ll concede that some of it defies logic – yet it’s what I found. Take that as you will and please comment if you have anything to add.

Anyway…let’s start by looking at some sample XML generated by the export-startlayout PowerShell command:

<LayoutModificationTemplate Version=”1″ xmlns=”http://schemas.microsoft.com/Start/2014/LayoutModification”&gt;

<DefaultLayoutOverride>

<StartLayoutCollection>

<defaultlayout:StartLayout GroupCellWidth=”6″ xmlns:defaultlayout=”http://schemas.microsoft.com/Start/2014/FullDefaultLayout”&gt;

<start:Group Name=”” xmlns:start=”http://schemas.microsoft.com/Start/2014/StartLayout”&gt;

<start:Tile Size=”2×2″ Column=”2″ Row=”0″ AppUserModelID=”Microsoft.WindowsCalculator_8wekyb3d8bbwe!App” />

<start:DesktopApplicationTile Size=”2×2″ Column=”0″ Row=”2″ DesktopApplicationID=”C:\Apps” />

<start:Tile Size=”2×2″ Column=”4″ Row=”2″ AppUserModelID=”Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge” />

<start:DesktopApplicationTile Size=”2×2″ Column=”0″ Row=”4″ DesktopApplicationID=”{7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\Microsoft Office\Office16\EXCEL.EXE” />

<start:DesktopApplicationTile Size=”2×2″ Column=”4″ Row=”4″ DesktopApplicationID=”{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\mspaint.exe” />

</start:Group>

<start:Group Name=”” xmlns:start=”http://schemas.microsoft.com/Start/2014/StartLayout”&gt;

<start:DesktopApplicationTile Size=”2×2″ Column=”2″ Row=”2″ DesktopApplicationID=”{6D809377-6AF0-444B-8957-A3773F02200E}\Windows Media Player\wmplayer.exe” />

<start:DesktopApplicationTile Size=”2×2″ Column=”4″ Row=”2″ DesktopApplicationID=”Microsoft.InternetExplorer.Default” />

</start:Group>

</defaultlayout:StartLayout>

</StartLayoutCollection>

</DefaultLayoutOverride>

</LayoutModificationTemplate>

The official Microsoft documentation for working with this XML is here and you’ll definitely want to review it, but to touch on a few important items:

AppUserModelID – This is for Metro (App Store) apps. The pins for these seem to work all the time.

DesktopApplicationID – In theory this type of link works for file paths, shortcuts, or executables. In reality it only seems to work reliably for shortcut (.lnk) files.

Anyway, some basic testing revealed at least one problem pretty quickly. If the target of an item pinned to the start menu is not present on the system when the start menu loads, the pin will disappear. So consider a situation where a user logs on to a fresh machine that hasn’t finished installing Microsoft Office. Their pin for Excel (as shown in the XML above) will be missing. What’s worse, it will never come back, even when Office gets installed. The only way to get the pin to appear is to delete the user’s profile and allow a new profile to be created. This seriously complicates things as it means you’ve got one single chance to have a user’s start menu display properly.

The problem seems to be the start layout import/export is designed more for a situation where you are creating a reference image, preloaded with software. In our case we do all of our software installations via group policy as needed, so the software installed on a given machine can vary and there’s likewise no guarantee that a piece of software will be installed the second the machine is finished being imaged.

Early testing showed a few other important things:

• If there are any errors in the XML, Windows will ignore it entirely and revert to the user’s prior start menu, whether that was a previously valid custom one, or the default out-of-box start menu.
• Adding comments to the XML likewise results in the start layout being ignored. (This in fairness is mentioned in the MS documentation.)

After a lot of further testing, trial, and error, we’ve determined the following:

• You can only pin items that are present in “all apps.”
• The “all apps” database is generated only
  at boot-up, and is generated from the items found in the user’s profile plus the “all users” profile, in these two location:
  • %APPDATA%\Microsoft\Windows\Start Menu\Programs\
  • %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\

  There is clearly some logic that causes the database to be rebuilt when a new program is installed, but that does not seem to be exposed at all to the end user, so for all practical purposes if you want to add an item to “all apps” programmatically, it requires a reboot after adding the item to one of the above paths.

• As mentioned earlier, if an item that is not found in the “all apps” database is pinned to a custom start menu layout, the pin will disappear, never to be seen again without deleting the user’s profile.
• Directly linking to EXEs is not reliable. It’s not clear why this is, but it’s better to pin a shortcut to the EXE. To clarify, if you want to pin an EXE, you should instead create a shortcut to that EXE, get the shortcut in “all apps” and then pin that shortcut to the start menu.
• Attempting to pin a path does not appear to work across users. It’s not clear why this is. I resorted to a very convoluted method: writing a short C# app that opened the desired path, then linking to a shortcut to that EXE. It’s a crazy method but the only way I could get to consistently work.
• The link to “Microsoft.InternetExplorer.Default” works inconsistently as well. I found it better to create a shortcut to IE and pin that to the start menu.
• Here’s a very strange one…If you redirect the start menu (i.e. the pre-Win 10 way), items pinned to the Win 10 start menu are unreliable. Win 10 sometimes seems to take the shortcut from the local “all apps” and other times from the redirected start menu. You must turn off redirection for Win 10 devices to reliably use the customized start menu layouts.
• You must also disable the group policy “Remove common program groups from Start Menu,” otherwise the “all users” profile items will not be loaded into the user’s all apps database, resulting in missing pins.

There are a lot of moving pieces here, but by following the above we’ve been able to create a custom start menu layout that works the way we need it to. Hope this helps!