Tag: device management

Categories
Intune

HoloLens multi-app kiosk

HoloLens got to be one of the cooler devices out there, but probably also one of the lesser-known devices how to manage.

What is a HoloLens really?

HoloLens is Microsoft’s device aimed for Mixed Reality, but at heart, it’s actually a Windows-based device but done in a more modern way. This means that the support for legacy protocols is limited, but also that the level of built-in security is maybe a bit higher than on your Windows-based PC. You can read more about the HoloLens as a platform here.

Given that it’s a Windows device, we can manage it using basically the same policies in Microsoft Endpoint Manager (MEM) as you would for the rest of your Windows devices. A lot of baseline profiles could be re-used (or duplicated) with ease which simplifies the configuration a bit.

There are a few things to keep in mind when it comes to Microsoft HoloLens 2, which has had an impact on the designs and implementations in my experience.

  • It doesn’t support EPP/EDR software of any kind
  • You can only run UWP based applications
  • You will need additional licenses to run e.g. Remote Assistance

HoloLens 2 as a kiosk

There are a lot of different applications and ways to implement and use a HoloLens 2. In this post, I’ll focus on how to set up the HoloLens 2 as a multi-app kiosk, but with user sign-in, using Microsoft Endpoint Manager.

Importing the device into Windows Autopilot

If your vendor or retailer didn’t import the HoloLens hardware ID for you, you can do this by following these four simple steps:

  1. While the HoloLens 2 device is powered on, press and release the Power and Volume down buttons together to trigger the hardware ID and diagnostic log collection process.
  2. Connect the HoloLens 2 device to a PC using a USB cable so that it shows up in File Explorer.
  3. Browse to Internal Storage > Documents  and extract AutopilotDiagnostics.zip. This file/folder will contain a CSV file with a a file name that begins “DeviceHash…”.
  4. Upload the CSV file to the Windows Autopilot service

In order to simplify our management a bit and be able to create a dynamic device group with only HoloLens devices, assign a GroupTag to the device such as “Hololens”.

Creating a device group for HoloLens

Like all things in device management, we are really dependent on groups. In this case, we will use a device group to target only our HoloLens devices.

You can create a new Azure AD group by selecting Groups in the left hand side menu in the MEM portal. Then select “New group“.

Give your group a good name and select “Dynamic Device” as Membership type.

Next, click “Add dynamic query” at the bottom and add the following rule syntax, but replace the word Hololens used here with the name of your GroupTag.

(device.devicePhysicalIds -any _ -eq "[OrderID]:Hololens")

Click Save followed by Create to finish the creating of the group.

Setting up enrollment

First off, we need to create a new Deployment Profile for the HoloLens platform.

You will find the Deployment Profiles by navigating to Devices > Windows > Windows Enrollment and selecting Deployment Profile.

When you have selected the Deployment Profiles card, select “+ Create Profile” and choose HoloLens as the platform.

Give your profile a name in the Basic tab and press next. On the “Out-of-box experience (OOBE)”, you can really only have to change the name template if you are looking to use custom names for your HoloLenses. In my example, I’ve left all values to default. Press next to move to the next tab.

On the Assignment tab, select your HoloLens device group and press next.

Review your settings and hit Create to finish the creating of the deployment profile.

Creating a Filter for HoloLens

To make sure that we only target settings deployed towards users to their HoloLens devices, we need to create a filter we will use later on.

Navigate to Tenant administration > Filter. Create a new filter by clicking “+ Create” in the top ribbon. Give your filter a name, such as HoloLens, and select Windows 10 and later as the platform.

Since filters are kind of like dynamic groups, we need to add a syntax. The easiest way I’ve found to include HoloLens devices is to use our Deployment profile name, the attribute is called EnrollmentProfileName on the device. Enter the name of your Deployment Profile in the Value field.

Click next, then review and create the filter.

Configuring kiosk mode

You could basically already enroll your devices now and be done, but it will be like an unconfigured PC, your end-user will miss vital settings and applications.

Since this is a Windows-based platform, you can reuse or duplicate profiles you already have for Wi-Fi, certificates, and such. Not all profiles make a whole lot of sense to use on the HoloLens (such as settings for the Office suite or Chrome browser to give some examples).

The profile we need to create to set up the Kiosk-mode on HoloLens is a profile based on the Kiosk template.

Go to Devices > Windows > Configuration profiles and create a new profile by pressing “+ Create profile” in the top ribbon. Select Windows 10 and later as platform and Templates as Profile type. Scroll down and find the Kiosk template and click create.

As always, give your profile a name based on your naming convention on the basic tab and press next.

Based on your scenario, select either “Single app, full screen” or “Multi app kiosk” as kiosk mode and select “No” on the question if device is running S mode.

In my scenario, I will configure that users will use the device using their Azure AD accounts. Since I have to specify a group with eligible users, I’ve in my setup used a group containing most of my users meaning that all my users are allowed to sign in to the HoloLens. You can easily assign this to either a group of users or even a specific user. You can also add additional groups and/or users. Depending on your scenario, you can make different choices here.

Next up is to select what applications we will run on the device. This can be done by either selecting built-in applications or applications distributed through MEM. Keep in mind that Win32 applications DO NOT WORK on the HoloLens when selecting applications.

If you want to add built-in or system applications, this is done by adding the AUMID of the application. You can find all the HoloLens 2 applications AUMID on this MSFT Docs site.

In this example, I will add one built-in application and one store app. You add apps by pressing the “Add…” button under the Browser and application section.

When adding a app by using AUMID, you give the application a name (preferably what it’s called in the reference document) and the AUMID for the application.

When adding a store app, MEM will list the apps you have available for distribution. Also, keep in mind that you will need to make sure to target the application distribution towards the HoloLens group.

Leave the rest of the settings to the default value and click Next.

In order for the Kiosk mode to function properly when requiring Azure AD users to sign in, the profile needs to be targeted toward users otherwise nothing will happen in my experience. If you are not doing personal logins, you can target this towards a device group.

In order to not assign the Kiosk-mode to all the user’s devices, we will need to use a filter to limit what devices the profile is assigned to.

On the Assignment tab, select your group of users who will be allowed to use the HoloLens and then press “Edit filter” next to the group.

Select “Include filtered devices in assignment” and choose your filter then press Select.

Press next and leave the Application Rules to blank and review and create your profile.

Enroll and sign in!

Now it’s time to enroll your device, simply start the device and follow the on-screen instructions.

What I’ve seen is that sometimes, the kiosk mode does not kick in on the first login after enrollment. If this happens, simply sign in and out of the device, this has done the trick for me!

Categories
Intune Tips & Tricks

Remove Quick Assist

Updated on the 29th of September 2022 due to changes in Quick Assist installation.

Like I mentioned in the blogpost about Remote Help, the build in Quick Assist tool in Windows 10 and Windows 11 is great for supporting friends and family. However, it’s not that great to support an organization since vital features are missing like handling UAC and logging. There is also a lot to wish for when it comes to how accounts are managed and the overall experience in a corporate setup using Quick Assist.

So, when we have deployed Remote Help to all our users, we want to remove Quick Assist to improve security (so unauthorized people cannot remotely connect) and to ease confusion about what remote support tool to use.

There are several ways of doing this, but I’m taking the approach that we don’t have a custom image since our devices has been enrolled through Windows Autopilot using vanilla images. So how can we remove the feature, and make sure that the end-user doesn’t get creative with enabling it again?

The answer to this is using proactive remediations.

What is proactive remediations?

Proactive remediations is a part of the Endpoint analytics section of Microsoft Endpoint Manager. You can find it by going to Reports > Endpoint Analytics > Proactive Remediations. By default you will have to script packages published by Microsoft.

Proactive Remediations is a script package where you can find and fix things on your clients, before this generates a ticket to your help desk.

However, since these are scripts running, you can do about anything to be honest. Each script package consists of a detection script and a remediation script. The scripts are then deployed to the devices through MEM and will report back. You can find reports on how many times a script has run, and how many times it has fixed an issue. Fixed and issue means that it has run the remediation script. You can read more about how they work and what you can do on e.g. Microsoft Docs.

One thing you could do is to detect if a Windows component is active, and if found active then disable it.

How do I remove new Quick Assist?

Due to an update, Quick Assist have now moved in to the Microsoft Store, meaning that we need a new way to remove the store app. Next chapter will cover the old application which was a Windows Capability.

There are several ways to remove pre-installed application from Windows, you could either get the application from the Business Store and assign it as “Uninstall” for all devices/users, or you could user PowerShell to remove applications.

For this, we will use Proactive Remediation to detect if the Quick Assist is installed, and if so we will remove it. This would remove the application even if the user installs it them self. There are other ways to do this as well, like only deploying the removal part and blocking the application with AppLocker.

I’ve put these scripts in my GitHub repository, for this part use the *_app files.

First we will do detection:

WinCap = Get-AppxPackage -name "MicrosoftCorporationII.QuickAssist"

try {
If ($WinCap.Name -like "*MicrosoftCorporationII.QuickAssist"){
Write-Warning "Quick Assist installed - running remediation script"
Exit 1
}
Else{
Write-Host "Quick Assist missing - exiting"
Exit 0
}
}
catch {
Write-Host "Quick Assist missing - exiting"
Exit 0
}

If our detection script finds the application, we will run a remediation script to uninstall it, just two lines of simple PowerShell code (thanks @LasseiLarod for the contribution to this).

$WinCap = Get-AppxPackage -name "MicrosoftCorporationII.QuickAssist"
Remove-AppxPackage -package $WinCap.PackageFullName

Now all that we need to do is to make sure that we run the script in User Context, since the application is installed in the user context.

How do I remove old Quick Assist?

One way to disable Quick Assist, even if the user enables it again, I have found is to use a proactive remediation which checks if Quick Assist is enabled on the device, and if it finds that it is Quick Assist is disabled.

Quick Assist isn’t an app installed from the store, it’s a Windows capability which means that we cannot uninstall the app.

To do this, we firstly need a script which will identify if Quick Assist is enabled. One way of setting that up is like this, a simple PowerShell script that my college helped me create (thank you Daniel).

I’ve put these scripts in my GitHub repository.

$WinCap = Get-WindowsCapability -online -name App.Support.QuickAssist*

If ($WinCap.State -match "NotPresent"){
    Write-Warning "Windows Capability - Quick Assist missing - exiting"
    Exit 0
}
else {
    Write-Host "Windows Capability - Quick Assist installed, Running Remediation script"
    Exit 1
}

This simple script will check if the Windows capability is enabled, if enabled it will run the remediation script which disables Quick Assist. It’s a one-liner:

Remove-WindowsCapability -online -name App.Support.QuickAssist~~~~0.0.1.0

What could be good to keep in mind is that if the version of Quick Assist changes, this disable-part will stop working. I’ve’ tried using a more generic string, but I couldn’t get it to work. However, my PowerShell skills are quite limited.

Categories
Windows 365

CloudLAPS on CloudPC?

So I’ve been playing around a bit with Windows 365 Enterprise and thinking about “okay, what cool things should we try?”.

First step is of course to set it up and I thought about writing a guide about that. Halfway through my guide I realised that the one written by Christiaan Brinkhoff was far superior to mine, so go check his guide out!

One thing came to mind however, could you get CloudLaps to work on a Cloud PC?

Of course, we needed to try this even though I’m not a 100% sure that you need it.

What CloudLaps does it that it provides your PCs with a unique, randomized password for the local admin account on the machines which is rotated on a given interval (default is every 3 days). By using this functionality, all your PCs will have unique passwords for their local admin accounts meaning that if this is handed out to an end-user or support personal, the password will stop working when the password is updated.

The Cloud PC configuration

If you have not yet implemented CloudLaps, have a look at the guide in the link above, but if you have it in place, you are ready to go.

Since CloudLaps is built on proactive remediations in Microsoft Intune, you will need to make sure that the Cloud PCs are included in the assignment by using (or adding) a group containing all your Cloud PCs. Windows 365 Enterprise gives you the benefit that Cloud PCs are being automatically enrolled into Microsoft Intune which gives you the possibility to manage them directly without any further actions!

In this example, all the Cloud PCs are included in the same group as all other PCs since we want all these PCs to have the same settings. This was done by adding an extra rule to our Dynamic Group.

device.deviceModel -contains "Cloud PC Enterprise"

No additional configuration needed!

The outcome

The outcome of this test was as expected, worked perfectly fine!

A local admin password is populated in the CloudLaps portal, and I can use it on the machine to elevate my rights on the Cloud PC.

Since you can use the exact same configuration for Cloud PCs as physical PCs, you will not need to separate how you manage the Cloud PCs. They are just another PC, but in the cloud!

Categories
Intune Modern Workplace

Why managed Android matters

Looking at the Swedish market, most of the companies I meet are managing their devices. These devices are usually iOS/iPadOS devices since, let’s face it, iOS has been superior in the Mobile Device Management segment throughout the years since they have had more settings exposed to MDM than Android. This has however changed over the years and the difference is not at all the same as of let’s say 3-5 years ago.

We can always discuss why platform A is better than platform B, but let’s not get into that. Everyone will have a separate opinion on this.

Looking at where we are today, many companies I meet manage their iPhones and iPads but haven’t really gotten around to Android yet. It’s still in some sense viewed as a secondary platform and not something that is wanted (it’s one more platform to provide end-user support on for one thing).

I fully respect this. However….

Looking back at my previous posts about what tools people to expect to use in the workplace, we are seeing a lot of growing demand for Android devices.

This could be out of personal preferences, the fact that the device is cheaper or the iPhone not being available in the market where the user lives. But this means that dodging the question of Android becomes harder and harder. And the later you get on top of Android, the harder the transition will be since Android is a lot different to manage compared to iOS/iPadOS.

For Android, you have to options depending on your wants and needs. You have Work Profile and Device Owner.

Management methods for Android

You should AT ALL COST avoid using Device Administrator since this is a legacy protocol which will be decommissioned by Google.

In this post I will not cover the dedicated devices method since this is meant for special adoptions and not regular end-users.

Work Profile

Work Profile is the most basic version of Android management and it has the least impact on already existing phones. Your users must download the Company Portal to enroll into Intune. This will create a separate “work sphere” where all corporate data will live.

This is the easiest form of Android management and you can deploy applications, configurations, and compliance policies. The work data will be separated from the personal data, but there are some limitations around management. This is the easiest way to start managing your Android devices without too much user impact.

Device Owner

Device owner or fully managed is the full feathered version of Android management where Intune takes total control of the device. This is more like how the iOS devices would be in a supervised mode. This management method also enabled Google Zero Touch enrollment (or Samsung Knox) for easier user onboarding. But you can of course have your users scan a QR code on first launch.

A huge benefit with this from a corporate perspective is that the user won’t need a Google account to enroll and download corporate applications. They can add a personal Google account, but it’s not needed to use it as a corporate device. Google accounts can otherwise be a hassle for less experienced user.

Company-owned work enabled

This version of Android management is when this blogpost is being written to officially launched, it’s still in preview.

This is however a combination of Work Profile and Device owner management where you as an organization gains full control over the device (giving you more management capabilities) but corporate data and personal data is separated.

This requires a device reset, just as device owner, but the user will get one corporate sphere and one personal sphere. The data is managed in the corporate sphere and left to the end users’ privacy in the personal sphere.

In my view, this will be the more attractive version of Android management overall since you can have a separation between personal and corporate data.

This method works extra smooth if you combine it with Google Zero Touch or Samsung Knox. If you don’t see a possibility to have this in place, you can of course have your users scan a QR code on first launch.

Where should you start?

Start small and start easy. If you have a lot of Android devices today, Work Profile is the best place to start. Having users reset their devices containing photos, apps etc. is not a popular thing to do. You could argue that it’s a corporate device and your users must comply, but this is not an effective way to build trust and getting the devices into management.

If you have just a few devices and looking to introduce Android into your environment, Device owner or the new Corporate-owned work enabled method is the way to go. You will have fresh devices going in and the need for a reset doesn’t exist. Combine this with Google Zero Touch or Samsung Knox and you will have a killer user on-boarding experience!

What are your thoughs on Android and where do you stand today? Comment below!