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

V1.0
The original script was version 1.0

Syntax:

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

Output:



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

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

Syntax:

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

Output:



V1.2
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.


V1.3
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.

Syntax:

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

Output:



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.......



Monday, 12 February 2018

Migrate to Microsoft Intune from another MDM solution

Customers have asked me about this many times. How can we easily migrate to Intune from another MDM solution? Therefore I've decided to test drive a tool that I heard about recently. EBF have developed a tool called the EBF Onboarder and it supports the migration to Intune from pretty much all the well known MDM vendors. You can read about it here

It's really easy to use.



So let's start with the source MDM solution. You can see that I have a device waiting to be migrated.......



......and this is the EBF Onboarder. Click on New Migration to start.



Enter a name for the migration. Be creative.



Now we're asked to choose the source MDM system. The following solutions are supported sources:
  • Blackberry UEM
  • MobileIron Core (VSP)
  • MobileIron Core (EAS unmanaged)
  • MobileIron Cloud
  • AirWatch
  • XenMobile
  • Good for Enterprise
  • SAP Afaria
  • MaaS360
  • Sophos Mobile Control
  • Cisco Meraki
  • SOTI MobiControl
  • jamf PRO

Enter credentials for the source system. 



Microsoft Intune is the default target system. Enter your credentials. We only need to enter the tenant ID if the user has access to multiple tenants.



Click Find Devices.


EBF Onboarder connects to the source system and lists the device(s) that we need. Click Save Migration


Confirm that you want to Save the migration project.



You are presented with the content of the migration email that will be sent to users. This can be customized. Save the email.....




...and here is the migration. Check the box beside the users name and you can then select Send Invitations. This is so simple to use.

Now lets have a look at the behaviour on this Android device.


The user receives the invitation from EBF Onboarder for Intune.


The user opens the email and clicks on the Start Migration link.


The user is re-directed to the Onboarder service and asked to select Start Migration.



The first step is to retire the device from the source system. It's alarmingly quick (approximately 30 seconds).



Retirement is complete and now the user in invited to enrol with Intune. They are instructed to follow the Microsoft Intune link.



The user is re-directed to Google Play store and asked to download and install the Microsoft Intune Company Portal. We're familiar with the rest of the process at this stage.



User authenticates with Intune.........



.....and continues with the setup process.



The device is being added to Intune.



Enrollment is complete.


The device is available for management in the Intune portal.

The two-step retire/registration process on the device took less than five minutes and was very straightforward for the user to understand and follow. I was very impressed.

You can sign up for a trial on the EBF website The trial allows you to migrate 20 devices from multiple source systems and only expires when the 20 have been migrated.

I hope you found this blog post interesting. Until next time.........

Thursday, 8 February 2018

Failed to publish package to WSUS

I had a funny problem on a customer site today while deploying a Flexera CSI solution for third party patching. I integrated the solution with WSUS but had problems creating the agent package. The package failed to be published to WSUS.


The error was: Failed to publish package. Code: -2147467259. CreateDirectory failed.

Now I'm familiar with this error from my experience with System Center Updates Publisher. It's usually a permissions issue and that the logged on user does not have permissions to create a new folder in the UpdatesServicesPackages folder. Permissions was a good place to start troubleshooting.

I checked the NTFS permissions on the UpdatesServicesPackages folder but all looked normal
  • Full Control: Administrators, SYSTEM, WSUS Administrators
  • Read, Write: NETWORK SERVICE
  • List Folder Contents, Read, Read & Execute: Users/Everyone
I then thought I'd verify that my user account was in fact a member of the local administrators group on the server. That looked a bit weird. My user account AND SID were listed. That didn't look right to me so I figured that I needed to look into the health of the server.

I ran the PoSH cmdlet test-computersecurechannel and the result was worrying

Operation failed. Unknown interface.

Mmm, now I was getting a little concerned. Next step was to check the services and I found the little problem. The Workstation service was stopped (I have no idea how or why). Starting the service solved the problem and all was good again.


I could successfully create the package.

I hope this helps someone who encounters a similar problem. Until next time.....