Deploy Win32 applications with Intune



The ability to “package” applications for deployment in Microsoft Intune is something that has been highly requested by many organisations making the move to management of devices through Intune. Although there is a fundamental difference in deploying applications through Configuration Manager and Intune, Microsoft is developing tools to provide similar functionality across the management stack. Up until now it it has been possible to deploy applications through Intune, this relied on a single MSI installation file with no external dependencies. In some cases this meant that repackaging of applications was the only method of deploying those business applications, thus being a time consuming process.

Today it is now possible to deploy applications through Intune without those restrictions, this process creates a packaged container of the setup files along with command line installation and uninstall commands.


This is a significant feature towards bringing Intune from the realms of “good for mobile device management only” to “also good for desktop management”.

SCCM currently does (and probably will for quite a while) have additional functionality which larger enterprises require – however, this is a good step in allowing smaller organisations more flexibility in their deployment options.


Note: as of 25/9, this feature is available with an Intune tenant running a preview of the GA release.

Speed up offline servicing

Currently i am creating some server builds for a place which will be deploying large numbers of servers over the coming months.

One of things that is/was taking up a great deal of time was offline servicing for the base OS, primarily because the SCCM server is currently sitting on a virtual environment with disk that is struggling. With 2016, this isn’t so bad, as due to cumulative updates, there are only a few updates to be installed. With 2012 R2 however, there is a large number of updates – and the process continually fails due to the poor performance of the server.

One of things you can do to speed this process up is to remove unused images from your wim.

Both Server 2012 R2 and 2016 come with 4 images (with an index of 1 to 4) within the install.wim. These generally correlate with:

  • Index1 – Server 2012R2/2016 standard core
  • Index2 – Server 2012R2/2016 standard desktop experience
  • Index3 – Server 2012R2/2016 datacentre core
  • Index4 – Server 2012R2/2016 datacentre desktop experience

If you view Logs\OfflineServicingMgr.log during an offline servicing operation, you will notice lines that state things such as:

Applying update with ID xxxxxx on image at index 1

Then the same update will apply to image 2,3 and 4. In this enviornment, we are not deploying server core, so we only need indexes 2 and 4 (standard and datacentre with desktop).

We can view the indexes available within the wim by typing:

dism /get-imageinfo /imagefile:E:\<path to wim>\Install.wim

Then, if you dont need indexes 1 and 3 (as we dont in this scenario)

dism /delete-image /imagefile:E:\<path to wim>\Install.wim /index:1
dism /delete-image /imagefile:E:\<path to wim>\Install.wim /index:3

Now when you use offline servicing, each update will only be compared against 2 images, instead of 4, significantly reducing the processing time/disk usage, especially for 2012 R2 (where there are a large number of updates to apply)

This can also be used for client OS’s, such as Windows 10.

One important note – this will not reduce the size of the WIM. It will simply remove the index and save you time for offline servicing.

If your image is already in SCCM, then you must

  1. Go to Software Library | Operating systems | Operating system images
  2. Right click on the appropriate image | properties | Images tab
  3. Click on “reload”, then notice the dropdown has been reduce from 4 index’s, then hit “ok” to exit.
  4. Go into your task sequence
  5. Update the image index as required.

Windows 10 1709 and installing Hyper-V

It’s not often that I actually install Hyper-V on a client OS, so it was only by chance that I came across a bit of a weird issue when installing it on Windows 10 1709. Obviously I performed the usual process: Virtualization was enabled in the BIOS, enabled Hyper-V in Windows Features, rebooted and it all appeared to install/enable successfully.

Launched the Hyper-V console, and the local PC wasn’t automatically selected. Odd. Added ‘Localhost’ to the view, and received an error that indicated the services may not be running. Sure enough, Hyper-V Virtual Machine Manager was running, but Hyper-V Host Compute Service (vmcompute.exe) wasn’t. When trying to launch it, I received “The service did not respond to the start or control request in a timely fashion”. Event viewer detailed the exact same error – nothing more. Awesome!

Tried it on another machine in the same environment and experienced the exact same issue. Apparently, another Adexian (Hayes) also installed Hyper-V on one of his 1709 PCs recently – and his worked fine – so what the trigger is, I’ve yet to determine. On a related note, Hayes’s machine won’t shut down since the Hyper-V install – it reboots instead (and he’s yet to find a fix for this).

Obviously it’s time for Google – and it seems to be quite a common issue with 1709. Apparently Microsoft added some additional security policies that prevents Hyper-V running in certain scenarios (usually when there’s some non-Microsoft dll’s loaded in vmcompute.exe). There’s even a Microsoft support article detailing a similar issue where the vmcompute.exe process is crashing (rather than in my case where it wasn’t even launching in the first place).

In the end, the recommended solutions I could find were pretty varied:

  • Roll back to 1703 (no thanks – plus it wasn’t an upgrade)
  • Uninstall Sophos (wasn’t installed)
  • Uninstall any other Antivirus (McAfee installed in this instance, though anecdotal evidence suggests uninstalling it doesn’t work – didn’t try)
  • Configure ‘Control Flow Guard’ in the Exploit settings of Defender to be ‘On’ (which it was)

Going with the easiest option first (configure Control Flow Guard), I figured I’d set that to ‘On’. You can find this setting under:

Windows Defender Security Center > App and Browser Control > Exploit Protection Settings > Control flow guard

For me, it was already set to ‘Use Default (On)’. Damn. Ok, so what happens if we turn it off (and reboot). Unsurprisingly, it didn’t fix the issue. What it did do though, was cause vmcompute.exe to start launching and generating a crash error (as detailed in the microsoft support article).

Given the setting is meant to be ‘On’, I decided to turn it back on and see what happens. And it works. Why? No idea!

Either way, the solution for me (on two computers) was to disable CGF, reboot, re-enable CFG and reboot again.

Meltdown and Spectre patches available

Hi all,

For many of you that switched off over the xmas break (like me), you may have missed that there are now patches (released Jan 3rd 2018) for the creatviely (almost bond movie like) named vulnerabilities of “meltdown” and “spectre”.

You can find more detail on these Vulnerabilities  here –

Advice for Microsoft client OS’s is here – . The page still indicates to “contact your vendor” for microcode updates – which isnt going to overly helpful for standard end-users.

Advice for Microsoft server OS’s is here – There is additional work required over and above the patch for Remote Desktop and Hyper-V servers. Additionally, Windows server 2008 and 2012 are not yet patched, only Server 2008 R2/2012 R2/2016/1709 – read into that what you will.

The register has a good article (as they do most of time) cutting through the intel PR bullshit. Importantly, there has been various reports of performance impacts after installing these patches – but it is still too early to tell exactly how large/important those perfomrance impacts are.

There are links to many vendor advisories (which in turn have links to updates) @ – which is quite useful.

The patches and additional mitigations are fairly easy to implement if you have patching/management infrastructure in place – but if your company needs any assistance, we’re happy to help too.

Windows 7 unsupported CPU’s starting to hit the market

As has been well documented

The newest Intel and AMD processors are not supported when using Windows 7, 8.1, Server 2008R2 and Server 2012 R2… While this has been known for a while, however its always variable how much time the new hardware takes to hit the market.

A client recently had ordered a number of Dell 3040’s….. but Dell apparently decided to send 3050’s instead due to stock issues…. leading to this clients build’s not working.

While I, like many others, hate being “forced” to move versions (of anything), Win 10 is actually a pretty good OS and with Windows 7 extended support ending in 2020, its simply time to start planning to migration.

UEV now included in Windows 10 1607 (and above)

User Experience Virtualization (UEV) use to be part of the MDOP packs…. however MDOP’s last update was in 2015…. leaving some of us wondering what was happening to awesome tools contained within.

Given Microsoft’s strong movement towards cloud platforms, it seemed likely that these tools were dead.

Fortunately for UEV, its now included in Windows 10 Enterprise as a default service, for versions 1607 and 1703 (and we may be able to assume future releases as well). Some details on the release are here –

Unfortunately, the documentation is somewhat unhelpful.

The UEV documentation is located here –

However, there are a couple of quite important things that anyone deploying this should be aware of

  • Even though it isn’t stated anywhere in the doco, and seems quite counter-intuitive based on what’s presented in the GPO settings, the default Microsoft included templates do not automatically register on clients. These can be copied to your custom templates path, or you can register them with powershell on each machine as per
  • The UEV template generator is part of the ADK (1607 or 1703) – however, it does not show up if you try and run the ADK installer on Windows 8.1 or server 2012 R2. I haven’t tried on Windows 10 versions below 1607 or 1703 – but it will show/be installable on those versions.

Windows 10 Fast Startup Mode – Maybe not so good for enterprise!

Windows 10 includes a feature called “Fast Startup”, which is enabled by default. The whole idea behind this feature is to make it so computers don’t take as long to boot up after being shut down (rather than going into hibernation or sleep). It achieves this by essentially using a cut-down implementation of Windows Hibernation. Instead of saving all user and application state to a file like traditional hibernation, it only saves the kernel and system session to the hibernation file (no user session data) – that way when it “turns on”, it loads the previous system session into RAM and off you go. Its worth noting that this process doesn’t apply to reboots – only shutdowns. Reboots follow the traditional process of completely unloading the kernel and starting from scratch on boot-up.

Obviously, it’s a great idea for consumers – quicker boot-up and login times = happy consumers.

When you start using it in a corporate environment though, you can start running into some issues – primarily:

  • It can cause the network adaptor to not be ready prior to the user logging in. If you’re using folder redirection (without offline files – for computers that are always network-connected), then this isn’t such a good thing. It’s also not such a great thing for application of user-based group policies that only apply during login.
  • Some Windows Updates require the computer to be shut down/rebooted for them to install correctly. In the case of Fast Startup, the system isn’t really shutting down – it’s hibernating. Since users in corporate environments quite often just “shut down” at the end of the day (hibernate with Fast Startup), these updates don’t get installed. Of course there’s ways around this (have SCCM prompt the user to reboot, for example), but they’re not always an acceptable solution for every customer.

Obviously if the computer doesn’t support hibernation, there’s no issues.

If you’d like to disable Fast Startup, there doesn’t seem to be a specific GPO setting – you’ll have to use Group Policy Preferences instead. The relevant registry setting is here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled    (1 = enable, 0 = disable)

Windows 10 Photos App – Invalid Value for Registry / Repairing Windows 10 Universal Apps

One of our clients had a user with a weird issue today – whenever they tried to open a photo, they’d get the following error:


When looking at the PC, they had all image formats set to use the built-in Windows 10 Photos application. If you try to open the application separately, you get the exact same error – so obviously the application was broken somehow.

After a little research, I discovered other users with the same issue – and of course, many of the suggested solutions were ridiculous (sfc /scannow – seriously?!).

As it turns out, there’s actually quite a simple fix – and it’s built into Windows.

  1. Navigate to Start – Settings – System – Apps & Features
  2. Scroll down to ‘Photos’ and click on it
  3. Click ‘Advanced Options’
  4. Click ‘Reset’

Give it a minute or so, then try it again – it should now work!

As an aside, you can do this with any of the Windows 10 Universal Applications!