Windows 10

Windows Update Logging on Windows 10

Posted by James F. Prudente on September 27, 2016
Posted in: Web Filtering, Windows 10. Leave a comment

For many years and through multiple Windows versions, Windows Update logged to c:\windows\windowsupdate.log – simple and functional. But Microsoft’s vision with Windows 10 seems to be fixing things that aren’t broken, and this is no exception.

Opening c:\windows\windowsupdate.log on Win 10 gives you this:

Windows Update logs are now generated using ETW (Event Tracing for Windows).

Please run the Get-WindowsUpdateLog PowerShell command to convert ETW traces into a readable WindowsUpdate.log.

For more information, please visit http://go.microsoft.com/fwlink/?LinkId=518345

Basically, in order to have a human-readable update log, you need to open PowerShell and run Get-WindowsUpdateLog, which as noted above will convert ETW logs to an old-style WindowsUpdate.log which it places on the desktop. It’s an extra step but not too bad. When it works.

Unfortunately, in some (many?) cases you will end up with a log file filled with lines like these:

1601.01.01 01:00:00.0000000 692 5220 Unknown( 31): GUID=c232d8d6-c0ba-3f2d-4ee0-3c6f4b234595 (No Format Information found).

So what’s the problem? Believe it or not, in order for Windows 10 to convert the ETW files to a human-readable log, the system needs Internet access in order to reach Microsoft’s symbol servers. This is yet another functional change that seems to ignore the reality that many larger environments and virtually every school has content filtering in place, which blocks this very access.

In order to fix this, you will need to whitelist all traffic to http://msdl.microsoft.com/download/symbols. If that still does not fix things, you will need to delete the contents of %temp%\WindowsUpdateLog and re-run the PowerShell command.

After doing that, you should once again have a usable log file. Easy, right?

BGInfo for Windows 10

Posted by James F. Prudente on September 16, 2016
Posted in: PowerShell, Scripting, Windows 10. 12 Comments

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.

EDIT: These are tested and working on both 1709 and 1803.

IE11 on Windows 10 not Displaying Certain Graphics

Posted by James F. Prudente on February 2, 2016
Posted in: Group Policy, Windows 10. Tagged: , , , . 5 Comments

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

Posted by James F. Prudente on December 10, 2015
Posted in: Permissions, Windows 10, Windows 8.1. Tagged: , , . 2 Comments

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

Posted by James F. Prudente on December 9, 2015
Posted in: Group Policy, Windows 10. Tagged: , , . 16 Comments

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 3rd 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!