Wednesday, 1 August 2018

ConfigMgr - PXE without WDS

ConfigMgr Current Branch 1806 will shortly be released. One of the most eagerly awaited features (my favourite) is that we can now enable PXE on our DPs without Windows Deployment Services (WDS). This is an enormous step forward as it will save customers money. I have customers with many PXE-enabled DPs throughout the world. That's a lot of server licensing. Previously a server OS was required simply for WDS. Now we can use a desktop operating system for the DP and enable it to use a lightweight PXE responder. That will save customers a lot of money. Let's have a look at that.

This is the traditional server DP with WDS.

Remember the RemoteInstall folder.

Now we have a new checkbox when creating a DP - Enable a PXE responder without WDS

We're told that selecting this option will disable WDS on existing DPs. Also we can see that the new service does not support multicast. I can live with that.

Understandably Multicast options are now greyed out in the wizard.

This is what the folder structure looks like on a PXE-enabled Windows 7 DP, no RemoteInstall folder. Wow.

This is the new lightweight ConfigMgr PXE Responder Service. Who needs WDS?

We can see the path to the executable file sccmpxe.exe.

This is where the SCCM PXE files are located.

I can PXE boot as normal. See the way we're told that SCCM PXE now provides this service (not WDS).

This is a really cool feature and will save many customers a lot of money on server licensing. It's a good enough reason alone to upgrade to ConfigMgr Current Branch 1806. 

I hope this was useful. Until next time....

Friday, 20 July 2018

Intune - Block app access based on unapproved device vendors and models

This is one the most recent new features to be published by the Intune team. We can now specify a list of Android manufacturers and iOS models and choose an action to be performed on the devices specified in the list. At the moment we have a choice of two actions:
  1. Block devices that are not specified from accessing an app
  2. Perform a selective wipe of corporate data on devices that are not specified
This sounded really cool to me so I tested to see if this was easy to configure. It is. It's as easy as typing a list of Android manufacturers and iOS models separated by a semicolon.

In Microsoft Intune, select Mobile apps > App protection policies and select Add a policy.

Enter a name and choose a platform (Android in this case). Select your required apps and configure your required settings as normal.

Now, in the Settings page, scroll to the bottom to the Access Actions settings.

You'll find an existing list of settings, values and actions.

Click on the drop down arrow to reveal some additional choices. Select Device manufacturer(s).

A new line is added. We now must configure the values and action.

Enter your required values. As soon as you type a semicolon you are prompted for another value. The Microsoft documentation has a warning about this. 

"On end-user devices, the Intune client will take action based on a simple matching of the strings specified in the Intune blade for Application Protection Policies. This depends entirely on the value that the device reports. As such, the IT administrator is encouraged to ensure that the intended behavior is accurate. This can be accomplished by testing this setting based on a variety of device manufacturers and models targeted to a small user group".

In other words Intune will not check that what you've typed is accurate. It will only recognize it as a series of strings.

Next, choose your required action. I want to block access to my app for all Android devices except Samsung and HTC devices. Click OK to create the policy as normal.

It's very similar for iOS devices except that you choose Device models.

There are a couple of additional considerations:
  1. On iOS devices, this feature requires the participation of applications (such as WXP, Outlook, Managed Browser, Yammer) to integrate the Intune APP SDK for this feature to be enforced with the targeted applications.
  2. On Android, this feature requires the latest Company Portal.
I think this is a very useful feature and I hope it helps you. Until next time......

Tuesday, 19 June 2018

New super-slick kiosk mode with Windows 10 and Intune

It's been a while since I implemented Windows 10 kiosk mode and I remember that it previously wasn't a trivial task. There were quite a few steps involving AssignedAccess CSP and OMA-DM policy. I have to implement some single app browser-based kiosks (extranet only) for a customer next week so I figured that I'd have a look at how the solution has improved and I'm very impressed. It's so easy and now fully automated. This has been made possible by the introduction of the new Kiosk Browser app. This is so simple to configure and it took me about 10 minutes to configure the solution.

So what is this new browser that was published recently? The Kiosk Browser app (supported on W10 v1803 and later) can be found in the Microsoft Store for Business and has the following description:

"Kiosk Browser is a tool for IT departments, intended to be used with assigned access to create a kiosk browsing experience. Kiosk Browser is great for presenting interactive web apps and digital signage content. It is built on Microsoft Edge and allows IT to tailor the experience and apply restrictions such as allowed list of URLs and disabling navigation buttons. Kiosk Browser can be configured using runtime provisioning packages created from Windows Configuration Designer (also available in the store) or by using a modern management tool such as Intune. Search for “Guidelines for choosing an app for assigned access” to refer to our documentation for more details".

Getting the Kiosk Browser app

Launch the Microsoft Store for Business and search for the app

Select Get the app

Now Sync the MSfB apps with Intune.

Remember you must have added (and activated) Intune as a management tool first.

The app is now available in the Intune console.

Assign the app to a group containing the kiosk devices.

The app is installed on a device and can be seen in the start menu (you won't find it in Programs and Features).

The app can be manually launched

We can see that some configuration is required. We will do this using an Intune kiosk profile.

Intune Kiosk profile.

The What's new in Microsoft Intune for week on June 4 2018 tells us about a new kiosk profile. 

In the Intune console, navigate to Device Configuration > Profiles > Create profile

Name the profile, select Windows 10 and later as the platform and choose Kiosk (Preview) as the Profile type.

Click to Add a Kiosk configuration.

Name the configuration and choose a kiosk mode (in my case I want a "Single full-screen app kiosk")

More information is required. Select the Kiosk Browser app as the managed app. Choose Autologon as the user account type.

Add the row and create the kiosk configuration.

Next the kiosk web browser is to be configured.

I've configured the default home page URL and the website exceptions (only these websites can be accessed using the browser).

Finish creating the profile and assign to the group containing the kiosk computer.

Compare to previous Kiosk profile
This is a little different than before. Previously we would configure the Kiosk profile from the Device Restrictions blade. Incidentally that profile is still there and we're told that it is now obsolete.

The What's new doc tells us that this old profile type should now be renamed Kiosk (Obsolete) but it hasn't been yet. This is a little confusing so I'll report it to the product group.

It was a little more difficult to configure the old profile type. You had to specify a local kiosk user and the application user ID of the managed app.

Behaviour on the kiosk device

When the policy is applied the device restarts and is logged on automatically.

The Kiosk browser (with extranet) is available full screen as is the only available app. 

The device is restricted to the extranet only. Looks good and this was really easy to configure.

Until next time....

Tuesday, 22 May 2018

My favourite new Intune features

Hi all,

I've been quiet on my blog recently as I've been a bit busy with other things. However I have been keeping up with new Intune features as they've been released. There have been so many recently. These are a few of my favourites (in no particular order).

  • Enrollment status page - this is a big one that we've been waiting for. We can now can block end users from accessing Windows 10 v1803 until Intune has finished deploying policies, apps, certificates and network profiles (and any other deployments) during the provisioning of AutoPilot devices. 
  • MacOS - we can now upload MSIs and deploy to MacOS.
  • Advanced Threat Protection - ATP and Intune are now fully integrated so we can create conditional access policies to control access to corporate resources based on ATP "health".
  • Deleting devices - we can now delete a device from Intune without first having to remove company data or factory reset the device.

  • Play sounds on iOS when in Lost mode - we can force supervised iOS devices in Lost mode to play a sound, which continues to play until the device is removed from Lost mode, or a user disables sound on the device. Pretty cool.

Normal blogging service will resume shortly. Until next time.......

Monday, 19 February 2018

What's new with Windows AutoPilot?

There have been a few recent developments with Windows AutoPilot so I wanted to take a closer look. You can read my original experience with AutoPilot here

New version of PoSH script

Version 1.3 of the Get-WindowsAutoPilotInfo script has been published

I decided to have a look through the versions to see the history of changes

The original script was version 1.0


.\Get-WindowsAutoPilotInfo.ps1 -ComputerName <ComputerName> -OutputFile .\ComputerName.csv


Details captured:
  • Device Serial Number
  • Windows Product ID
  • Hardware Hash

The Append switch was added in version 1.1
Additional computer details are appended to the output file instead of overwriting the file.


.\Get-WindowsAutoPilotInfo.ps1 -ComputerName <ComputerName> -OutputFile .\ComputerName.csv -append


The Credential switch was added in version 1.2
This allowed us to add the credentials necessary to connect to remote computers. This switch is not supported when gathering details from the local computer.

The Partner switch was added in version 1.3
This allows us to specify that additional details required by the Partner Center are gathered (for use by CSPs). Presumably this will also be required when the OEM Vendors start to upload the computer details on our behalf.


.\Get-WindowsAutoPilotInfo.ps1 -ComputerName <ComputerName> -OutputFile .\ComputerName.csv -Partner


Details captured:
  • Device Serial Number
  • Windows Product ID
  • Hardware Hash
  • Manufacturer Name
  • Device model

SCCM Report

The second development involves ConfigMgr. A new report has been introduced in 1802 TP. The "Windows AutoPilot Device Information" report lists all the information that we would normally gather using the PoSH script.

I hope this information is useful. Until next time.......