Archives

All posts for the month December, 2015

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!

By Default, the Windows 10 “Default” Printer Isn’t Really a Default

Posted by James F. Prudente on December 1, 2015
Posted in: Windows 10. Tagged: , , . 1 Comment

A default printer by definition is the printer used unless an alternate device is explicitly selected. At least that’s the way it should work, and has worked in every version of Windows until Win 10. Now though the “default” settings for the “default” printer is to let Windows manage it, which means Windows will automatically change your default printer to the last used printer. I can’t imagine the tortured logic that led to this setting, nor can I imagine the number of print jobs that will be misdirected in corporate America as a result.

Thankfully, unlike so many Win 10 settings that are held in obscure databases, this one is a simple registry setting:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\LegacyDefaultPrinterMode

Set to 1 and you’ll have the old behavior back, where your default printer really is a proper default – and stays that way.