Aaron Parker's stealthpuppy

Subscribe to Aaron Parker's stealthpuppy feed Aaron Parker's stealthpuppy
on applications, desktop and Terminal Server deployment, virtualisation and anything else that takes my fancy
Updated: 3 hours 4 min ago

Default Start Menu Customisation via Intune

Tue, 12/18/2018 - 11:47

The promise of a modern management approach to deployment and management of Windows 10 is that you no longer create and manage a custom SOE image. User experience is still important though and a large part of that experience in an enterprise environment, is the default Start menu.

The default Start menu, especially on Windows 10 Pro, is far from enterprise ready right? Take a look at this mess:

Windows 10 Pro 1809 default Start menu

Over-the-air provisioning of PCs via Windows AutoPilot & Microsoft Intune (or insert your MDM solution here), limits the possibilities of customising the target PC before the user logs on. Users then have to live with the default Start menu or one that is defined by the administrator – neither is ideal.

UWP / Microsoft Store apps can be targeted for removal, but those apps won’t be removed until well after login. Compounding the issue of default apps pinned to the Start menu is that some of them aren’t actually installed, so removal won’t occur until the Store downloads and installs updates. That can sometimes be hours after the user has provisioned the PC.

Customise with PowerShell?

PowerShell scripts can be used to remove user and system provisioned Store apps (I have a couple of scripts in my Intune GitHub repository); however, PowerShell scripts in Intune can only be targeted to users and don’t fire until after the first logon. Additionally, I’ve had a crack at using PowerShell to pin and unpin tiles from the Start menu, but found that I can’t interact with the shell (or at least the pin / unpin has no effect) when the script is delivered via Intune.

Looking for Alternatives

With the availability of the Windows Autopilot Enrolment Status page in Windows 10 1803 and above, plus the recent addition of the feature to ‘Block device use until these required apps are installed‘, we might have an opportunity to deploy a customised default Start menu.

The Enrolment Status page tracks security policies and line-of-business (MSI) applications, so a custom default Start menu will have to be packaged into an MSI. Fingers and toes crossed then that this approach works.

Packaging a Start menu Customisation

To package a customised Start menu, we need to create the desired layout and export it with theExport-StartLayout command. Nothing new there – you’ve likely done that before. The next step is to create a custom Windows Installer package to deliver the layout file.

I’m using Advanced Installer to create my deployment package. For this particular project, the Freeware version of Advanced Installer provides all of the features you’ll need to deploy the custom layout file.

Create a Windows Installer Package

Advanced Installer makes short work of creating the package – create a new Simple Installer package and configure the product name, version and publisher. Note that if you want to update the package, save your project and update the version number each time you produce an updated installer.

Add the Start menu layout file to the project under Files and Folders. The project must define the correct target path and file name because it will be deployed into the default profile. Use this path:

Windows Volume\Users\Default\AppData\Local\Microsoft\Windows\Shell

And add the LayoutModification.xml file that you’ve exported with Export-StartLayout into this path. If your target path and file name aren’t correct, this won’t work so ensure your package looks the same as the screenshots here.

For this package, I’ve configured the following install parameters:

  • Package type – 64-bit package
  • Installation type – Per-machine only
  • Reboot behaviour – Suppress all reboots and Reboot prompts

Configure the default build to produce a Single MSI file and define the name. In the example below, I’ve used DefaultStartMenuLayout.msi.

Build your package and add the MSI into Microsoft Intune as a line-of-business application. Assign the new application as Required for All Devices, so that the Enrolment Status Page can track the installation before the user logs on.

Configure the Enrolment Status Page

To ensure that the package is delivered to the target PCs before the user logs on, we’ll leverage the Enrolment Status Page (ESP). The ESP is supported on Windows 10 1803 and above, so if you’ve gotten this far into the article and haven’t yet updated to 1803 or higher, you should stop reading and update those machines.

Configure the ESP and enable the ‘Block device use until these required apps are installed if they are assigned to the user/device’ feature. Here select at least the applications whose shortcuts you have configured in your Start layout customisation. This list must include the MSI package containing the customisation itself.

Here’s the applications that I’ve configured in my test environment:

Today the ESP tracks specific application deployments – Microsoft Store apps and single MSI files, while Office 365 ProPlus applications are tracked on Windows 10 1809 and above.

User Experience

Most of my testing is on Windows 10 1809 – with a PC enrolled into Azure AD and Microsoft Intune during the out of box experience, the Enrolment Status Page tracks the installation of policies and applications, including our Start menu customisation. 

After the enrollment and deployment is complete, the user sees a customised Start menu after first logon. There’s a few tiles that didn’t remain pinned from the default customisation, but this is much cleaner and enterprise ready than what we end up with out of the box.

Wrapping Up

Provisioning PCs via Windows AutoPilot and Microsoft Intune is a rapidly changing landscape. So what may not be possible today, is likely to be addressed quickly. In the meantime, there’s usually a custom approach to achieving the end-user experience that you need and this is a great example. 

This article by Aaron Parker, Default Start Menu Customisation via Intune appeared first on Aaron Parker.

Categories: Community, Virtualisation

Download, Install, Import Visual C++ Redistributables with VcRedist

Wed, 11/28/2018 - 23:48

Note: for a more up to date version of the content in this article, VcRedist now has documentation available here: https://docs.stealthpuppy.com/vcredist

Last year I wrote a PowerShell script that can download, install or import the Visual C++ Redistributables into MDT or ConfigMgr. Long-term maintenance of the full feature set in a single script is a little unwieldy so I’ve re-written the script and created a PowerShell module – VcRedist.

Refactoring the script into a module has been a great little project for creating my first PowerShell function and publishing it to the PowerShell Gallery.

Why VcRedist?

At this point, I’m sure you’re saying to yourself – “Aaron, haven’t you just created Chocolatey?”. In a way yes, this module does exactly what you can do with Chocolatey – install the Visual C++ Redistributables directly to the local machine. Although you can download and install all of the supported (and unsupported) Redistributables, the primary aim of the module is to provide a fast way to download and import the Redistributables into the Microsoft Deployment Toolkit or System Center Configuration Manager for operating system deployments.

Module

The VcRedist module is published to the PowerShell Gallery, which means that it’s simple to install the module and starting importing with a few lines of PowerShell. For example, here’s how you could install the module, download all of the supported Redistributables and import them into an MDT deployment share:

Install-Module -Name VcRedist Import-Module VcRedist $VcList = Get-VcList | Get-VcRedist -Path "C:\Temp\VcRedist" Import-VcMdtApp -VcList $VcList -Path "C:\Temp\VcRedist" -MdtPath "\\server\share\Reference"

This results in each of the Visual C++ Redistributables imported as a separate application with all necessary properties including Version, silent command line, Uninstall Key and 32-bit or 64-bot operating system support.

Visual C++ Redistributables imported into an MDT share with VcRedist

The same approach can be used to import the Redistributables into a ConfigMgr site:

Install-Module VcRedist Import-Module VcRedist $VcList = Get-VcList | Get-VcRedist -Path "C:\Temp\VcRedist" Import-VcCmApp -VcList $VcList -Path "C:\Temp\VcRedist" -CMPath "\\server\share\VcRedist" -SMSSiteCode LAB

Just like MDT, each Redistributable is imported into ConfigMgr; however, Import-VcCmApp copies the Redistributables to a share for distribution and creates and application with a single deployment for each one.

Visual C++ Redistributables imported into ConfigMgr with VcRedist

Of course, the module can download and install the Redistributables to the local machine:

Install-Module VcRedist Import-Module VcRedist $VcList = Get-VcList | Get-VcRedist -Path "C:\Temp\VcRedist" $VcList | Install-VcRedist -Path C:\Temp\VcRedist

By default, this installs all of the supported Redistributables:

Visual C++ Redistributables installed locally with VcRedist

Note that the 2015 and 2017 Redistributables are the same version, so the end result will include only the 2017 versions.

Functions

This module includes the following functions:

Get-VcList

This function reads the Visual C++ Redistributables listed in an internal manifest or an external XML file into an array that can be passed to other VcRedist functions. Running Get-VcList will return the supported list of Visual C++ Redistributables. The function can read an external XML file that defines a custom list of Visual C++ Redistributables.

Export-VcXml

Run Export-VcXml to export the internal Visual C++ Redistributables manifest to an external XML file. Use -Path to define the path to the external XML file that the manifest will be saved to. By default Export-VcXml will export only the supported Visual C++ Redistributables.

Get-VcRedist

To download the Visual C++ Redistributables to a local folder, use Get-VcRedist. This will read the array of Visual C++ Redistributables returned from Get-VcList and download each one to a local folder specified in -Path. Visual C++ Redistributables can be filtered for release and processor architecture.

Install-VcRedist

To install the Visual C++ Redistributables on the local machine, use Install-VcRedist. This function again accepts the array of Visual C++ Redistributables passed from Get-VcList and installs the Visual C++ Redistributables downloaded to a local path with Get-VcRedist. Visual C++ Redistributables can be filtered for release and processor architecture.

Import-VcMdtApp

To install the Visual C++ Redistributables as a part of a reference image or for use with a deployment solution based on the Microsoft Deployment Toolkit, Import-VcMdtApp will import each of the Visual C++ Redistributables as a separate application that includes silent command lines, platform support and the UninstallKey for detecting whether the Visual C++ Redistributable is already installed. Visual C++ Redistributables can be filtered for release and processor architecture.

Each Redistributables will be imported into the deployment share with application properties for a successful deployment.

Import-VcCMApp

To install the Visual C++ Redistributables with System Center Configuration Manager, Import-VcCmApp will import each of the Visual C++ Redistributables as a separate application that includes the application and a single deployment type. Visual C++ Redistributables can be filtered for release and processor architecture.

Tested On

Tested on Windows 10 and Windows Server 2016 with PowerShell 5.1. Install-VcRedist and Import-VcMdtApp require Windows and the MDT Workbench. Get-VcList, Export-VcXml and Get-VcRedist do work on PowerShell Core; however, most testing is completed on Windows PowerShell.

To Do

Right now, I have a few tasks for updating the module, including:

  • Additional testing / Pester tests
  • Add -Bundle to Import-VcMdtApp to create an Application Bundle and simplify installing the Redistributables
  • Documentation updates

For full details and further updates, keep an eye on the repository and test out the module via the PowerShell Gallery.

Image credit:

Alexey Ruban

This article by Aaron Parker, Download, Install, Import Visual C++ Redistributables with VcRedist appeared first on Aaron Parker.

Categories: Community, Virtualisation

Dynamic Software Update Rings in Microsoft Intune

Wed, 10/10/2018 - 02:27

Microsoft Intune provides management of Window 10 Update Rings to enable Windows as a Service, via the Software Updates feature. This enrols a Windows PC into Windows Update for Business to manage feature and quality updates the device receives and how quickly it updates to a new release. As you scale the number of devices managed by Microsoft Intune, the need to manage the software update or deployment rings is key to adopting Windows 10 successfully. Being able to do so dynamically and empowering end-users by involving them in the process sounds like an idea that’s just crazy enough to work. This article details an approach to achieve dynamic software update rings.

Dynamic Groups 

Azure AD Premium includes Dynamic Device and User groups whose membership can change, well dynamically. This feature enables us to apply software update rings to dynamic groups where the membership can be based on just about any user or device property that suits our needs.

In most cases, applying Windows 10 Update Rings to devices, rather than users, is the best approach to ensure that updates can be better tracked across specific hardware and software combinations. I don’t necessarily want a user moving between PCs and have devices move back and forth between update rings. Basing update rings on dynamic device groups is then likely the better approach.

Software Update Rings

For the purposes of illustration, I’ve created a basic approach to update rings with the 3 rings show here:

  • Semi-Annual Channel – we need a catch-all ring applied to All Devices. If our dynamic groups that are based on a device property don’t catch a device, it won’t get the correct update ring applied. This approach ensures that by default, a device is treated as generally production ready be being enrolled in the Semi-Annual Channel to receive well tested updates. This ring is assigned to All Devices, while excluding Azure AD dynamic groups assigned to all other rings
  • Semi-Annual Channel (Targeted) – here devices are enrolled for a pilot ring so that the latest Windows 10 release can be tested before rolling out the majority of PCs. This ring applies to a specific Azure AD dynamic group
  • Windows Insider – to preview upcoming Windows 10 releases it’s important to be enrolled in the Windows Insider program. This ring applies to a specific Azure AD dynamic group

My update rings in this example are quite simple, but the approach can be customised for specific environments and needs.

Update Rings configured within Intune Software Updates

Assigning Devices

To assign a device to an update ring, we need to leverage a device property that can be dynamically set. Here, Device Category fits this bill in a number of ways – here, the administrator can view the device category and therefore the device’s update ring, by viewing the device properties in the Intune console. If device category is not set (it will be set to Unassigned), our catch-all update ring will ensure the device is set to a production ready state.

Device properties in Intune

The device category can also be viewed in the Intune Company Portal, thus making it easy to view this property from multiple locations. This visibility makes device category a good choice for managing our update rings.

Device properties in the Intune Company Portal

The Intune Administrator creates device categories in the console. As you can see in the image below, I’ve chosen Production, Pilot and Preview as the device categories that provide, hopefully, clear indication as to what each category is for.

Intune Device categories

Here’s where the choice of using Device Category for assigning update rings is possibly a bit out there – the end-user chooses the device category! When enrolling their device or launching the Intune Company Portal for the first time they see the device category choices:

Setting a device category in the Intune Company Portal

There’s no replacement for end-user education, so it would behoove an organisation to include instructions on which category to choose, but in my mind it’s obvious that most users should choose Production. Having device category descriptions displayed as well would help, but they don’t at this time. Device categories are only shown once and the user cannot change the category after enrolment. Bulk changes to or reporting on categories can be achieved using the new Intune PowerShell SDK.

Dynamic Software Update Rings

Now that we have Update rings in place and an approach assigning them via Dynamic Device groups in Azure AD, we can create those groups based on membership rules that query Device Category. I’ve created two groups – Devices-Pilot and Devices-Preview that use a query where deviceCategory equals Pilot or Preview respectively. A Devices-Production group can also be created, but isn’t required because the production update ring applies to All Devices. A production devices group would assist with reporting.

Dynamic group membership rules

For these devices groups, the membership rules are:

  • Devices-Production: (device.deviceCategory -eq "Production") -or (device.deviceCategory -eq "Unknown") 
  • Devices-Pilot: (device.deviceCategory -eq "Pilot") 
  • Devices-Preview: (device.deviceCategory -eq "Preview") 

We can take this a step further and account for corporate vs. personal devices. Where users can enrol personal devices and you would prefer not to deploy Software update policies to them, membership can be filtered further. Using an advanced membership rule, update the group membership with:

  • Devices-Production: ((device.deviceCategory -eq "Production") -or (device.deviceCategory -eq "Unknown")) -and (device.deviceOwnership -eq "Company") 
  • Devices-Pilot: (device.deviceCategory -eq "Pilot") -and (device.deviceOwnership -eq "Company") 
  • Devices-Preview: (device.deviceCategory -eq "Preview") -and (device.deviceOwnership -eq "Company") 

With these groups created, assignments for my Software update rings are:

  • Semi-Annual Channel – assign to All Devices and exclude Devices-Pilot and Devices-Preview. 
  • Semi-Annual Channel (Targeted) – assign to Devices-Pilot
  • Windows Insider – assign to Devices-Preview

When a category is assigned to a device, the dynamic group will update at some point and the policy will apply on a subsequent device policy refresh.

Dynamic Software Updates

The same approach can be used for deploying applications that provide preview channels similar to Windows. Microsoft Office 365 ProPlus is an obvious choice – we can create Office application deployments using Update Channels with assignments using our Dynamic Device groups.

Office 365 ProPlus apps in Intune to manage update channels

The update rings I’ve implemented in my test environment include:

  • Office 365 ProPlus Semi-Annual Channel or Semi-Annual Channel (Targeted) that is assigned to All Devices and excludes Devices-Pilot and Devices-Preview, we have a catch all Office deployment package that will go out to the majority of devices
  • Office 365 ProPlus Semi-Annual Channel (Targeted) or Monthly Channel assigned to the Devices-Pilot group to receive the latest updates
  • Office 365 ProPlus Monthly Channel (Targeted) assigned to the Devices-Preview group to test Office Insider updates for testing upcoming features

Office 365 ProPlus then updates itself on the end-device based on the assigned channel. This actually works quite well for this application as you can pretty seamlessly move between channels as required.

Wrapping Up

In this article, I’ve shown you how to enable dynamic Software Update rings for Windows Office in Intune using Azure AD Device Dynamic groups. This uses what may be a controversial approach – devices category chosen by the end-user. Modern device management forces us to rethink our engagement with end-users and involving them more directly in the testing process can help make IT more personal.

For more controlled environments, the choice of category can be overwritten by the administrator, especially for users who may need to roll back to a more stable release.

Photo by Mathew Schwartz on Unsplash

This article by Aaron Parker, Dynamic Software Update Rings in Microsoft Intune appeared first on Aaron Parker.

Categories: Community, Virtualisation