Use a QR code to point users to the Intune Company Portal app for enrollment
Quick post here, ever wonder how you can create a QR code that points to the Intune Company Portal in the iOS app store (or any app store), and paste it in an email and send it to your end users? Well it’s super easy to do. Simply search online for a QR code generator. Example: https://www.bing.com/search?q=qr%20code%20generator
When I searched for a QR code generator, a result came up inline of my search results and I pasted the URL that points to the Intune Company Portal in the Apple app store and it generated the QR code below.
If you’re interested, here’s the raw data behind the QR code:
Even better, the Intune Company Portal has 4.5 stars, hey that’s awesome! Ok shameless plug, however it’s really cool to have such a high rating.
Anyway, theoretically you can do this for any app in an app store, whether they’re Microsoft Office apps, 3rd party apps, one of your published apps, etc.
To save you time, I generated QR codes that point to the Intune Company Portal (or enrollment URL in MacOS case) for all the platforms supported by Microsoft Intune:
Here’s an example email I manually created. Create your own by copying a QR code and generating your own custom emails using your corporate email application such as Outlook. Your users will love it! Plus it streamlines their enrollment process.
Here an example of using the built-in camera in iOS to scan the QR code. As you can see it took me directly to the Intune Company Portal app in the Apple app store.
Back in 2015 I wrote a blog about Mac management with Intune, however it’s been a few years and I feel it’s time we re-visit Mac management with Intune to learn more about what’s changed. You’ll soon learn there’s been a significant amount of progress and since my first post Intune now has a lot of native Mac management capabilities built in.
First let’s look at MacOS enrollment options with Intune.
MacOS enrollment options
There are two methods to enroll MacOS with Intune, user driven or using Device Enrollment Program.
If the user already had a device registered it will show on the screen, if the Mac is the first device being enrolled, they will see the following:
Once the user selects “Add this one by tapping here” they’ll be prompted to download the Intune Company Portal app.
After the Company Portal is downloaded and installed, open it up and you’ll be asked to sign-in using your corporate credentials. These are the same credentials used to sign into Office 365 (derived from Azure AD).
After sign-in is complete the device will begin the enrollment process.
The concept of the Apple DEP is to associate devices with an organization and to streamline the enrollment process, similar to enrolling Apple iOS devices. However, enrollment requires a different process by associating an Apple enrollment token with Intune. After the enrollment token is added and enrollment profile is created in Intune and associated with the enrollment token.
During the enrollment profile creation process you’ll be asked to select user affinity (i.e. userless or user associated). Once user affinity is selected, you’ll also select whether or not you’ll allow users to remove the enrollment profile via the “Locked enrollment” setting. Finally, you’ll customize the setup assistance which allows for hiding setup screen, e.g. Apple Pay, Siri, Registration, etc.
Note: as of this post only .pkg files are supported nor are conversions from .dmg to .pkg
Microsoft + Jamf partnership
Microsoft has also has a partnership with Jamf. Jamf also provides MacOS management and if your organization currently utilizes Jamf and would like to receive the benefits of integrating Jamf with Intune you can do this today with Jamf Pro. So, what does this mean?
MacOS devices managed by Jamf remain managed by Jamf when Intune comes into the picture (thus are only registered with Intune not enrolled) and integrating Jamf Pro with Intune provides a path for Jamf to send signals in the form of inventory to Intune. Intune will use compliance policies to evaluate the Jamf signals and in turn send signals over to Azure AD stating whether the device is compliant or not. The Azure AD conditional access policy will kick in and based on your configuration of the conditional access policy, will either block or further challenge the user to remediate before access company resources.
As I meet with organizations, I learn what their business goals are, what their end user goals are, and what their budgetary guidelines are. I also learn a lot about their endpoint management goals. What I’ve discovered is endpoint management has different meanings for each customer with a few common themes, user experience, simplification, and cost reduction.
The pace of change with technology is extremely rapid and organizations often struggle to keep up with all the updates across deployed technologies. When IT teams deploy technologies to help secure and simplify administration, they must provide evidence to the organization about the short- and long-term benefits of shifting to newer technologies, especially if they are duplicative of existing technologies. The evidence to rip and release a working solution is typically prioritized and is provided in the forms of cost reduction, end user benefits, and administrative simplification. Looking back in history, many would argue managing Windows in the enterprise has been a priority for most organizations. Many of these organizations today continue to manage Windows with a variety of technologies with one, (based on my interaction with hundreds of organizations) standing out the most, System Center Configuration Manager (ConfigMgr).
Configuration Manager has been around for a couple decades and for good reason, in my opinion it manages Windows best. For those familiar with ConfigMgr, you’re probably familiar with its history and the changes to the product over time. What I’ve seen is a blend of enhancing the client, infrastructure, and administrative experiences, including enhancements to reporting, management techniques, bandwidth controls, scale, performance, and more recently attaching Configuration Manager to the cloud. These advancements are critical to an ever-changing landscape of Windows computing and resource access.
Why write about this now?
There are a couple reasons:
Organizations are going through digital transformation and taking a hard look at existing endpoint management solutions.
Configuration Manager remains one of the most widely utilized endpoint management technologies across organizations today and I articulate the ongoing value of ConfigMgr in the content below.
Recently organizations have asked me the question if ConfigMgr is “dead” and my consistent answer is “no” is it not, ConfigMgr as of this post manages over 150 million endpoints, in fact there’s been continued investment in ConfigMgr year-over-year. Take a look at “What’s New in Configuration Manager” over the past several releases and you’ll see a growing list of exciting enhancements over each release.
You’ll also notice ConfigMgr has a release roughly every four months which provides a predicable release schedule for organizations needing to plan updates. Speaking of ConfigMgr updates, in console notifications of new releases provides an easy and informative method to update ConfigMgr to the next release by a click of a button. In addition, ConfigMgr technical previews allow organizations to test new features ahead of upgrading to the next service release of ConfigMgr. The servicing of ConfigMgr and technical previews are a win/win in my opinion.
I also receive questions such as “why stay with Configuration Manager, when I see Microsoft doubling down on efforts to enhance Intune toward feature parity?“. While partially true, there are clear advantages to continue utilizing ConfigMgr and leverage the cloud by cloud attaching ConfigMgr.
Preparing your infrastructure for cloud attach by extending ConfigMgr to Azure enables organizations to manage devices off the corporate network by utilizing Cloud Management Gateway . By attaching ConfigMgr to the cloud, it allows organizations to simplify management of Windows devices and administrators will have the advantage of leveraging current processes built around endpoint management with ConfigMgr.
Organizations needing high availability in ConfigMgr can take advantage of site server high availability and SQL Always On.
Cloud attach Windows 10 clients to Intune by enabling co-management in ConfigMgr allows organizations to utilize ConfigMgr and Intune to manage Windows devices. By enabling co-management, the organization benefits from the currently unparalleled strength of Configuration Manager as well as additional benefits cloud services such as Microsoft Intune and Azure Active Directory provide. For example, ConfigMgr client health will be reported directly to the device stats in Intune (shown below), remote actions may be initiated directly from the Intune admin console, as well as utilizing conditional access policies with Azure Active Directory to control access to company resources.
So why not move from ConfigMgr and manage all Windows devices with Intune?
Although managing devices may be viable for many modern management scenarios, there are scenarios where ConfigMgr remains as the preferred solution including:
Network controls for locations with low bandwidth
Down-level Windows 7/8 client management
Windows Server management
Devices that are network Air Gapped (isolated) and have no Internet access
OS deployment through network boot options
Complex application deployment scenarios
Third-party software updates
Co-management provides methods for organizations running ConfigMgr to decide where they manage certain workloads. Currently, there are a number of workloads that may be managed by Intune when devices are co-managed, including:
Resource access policies
Office Click-to-Run apps
Windows Update Policies
When utilizing co-management there are several advantages to utilizing Intune, for example in a co-managed scenario when moving “compliance policies” workload over to Intune, organizations can take advantage of Azure Active Directory Conditional Access. There are also immediate benefits of co-management such as executing remote actions directly from Intune including: Factory Reset, Selective Wipe, Device Restart, Fresh Start, etc. Intune compliance policies also play a significate role in controlling device health and access via Azure AD conditional access, for example Windows 10 compliance policies may require one or more of the following before accessing corporate resources:
Use a password to access devices
Encryption (e.g. BitLocker)
Windows Defender version and signature is up-to-date
Traditionally, setting up device health posture for an on-premises requires additional services and hardware such as a Network Access Control (NAC) solution. Whereas selecting workloads by enabling co-management for Intune to manage, organizations can take advantage of access controls delivered from Azure AD and Intune, including for on-premises web applications published through Azure AD Application Proxy. Not only is device health posture evaluated, additional access controls may be enabled including multi-factor authentication.
Below is an example of a device managed with ConfigMgr and Intune where compliance is reported back and shows in the ConfigMgr Software Center.
Intune Portal – shows compliant
Software Center – shows compliant (reported back from Intune)
Now let’s talk about Windows deployment options. Traditional deployment techniques for Windows typically involves an image that requires updating and then a system to publish those images so when a bare-metal boot takes place an image can be accessed, downloaded, and installed. OS image management can be a time-consuming process as it requires a human resource to manage and update the OS, drivers, apps, agents, etc. Some organizations offload OS image management to an OEM where the OEM preloads the image on the device, however the images still need to be maintained, and offloading to the OEM comes at a cost.
By leveraging Microsoft Intune and Azure Active Directory, organizations can take advantage of Windows Autopilot. Autopilot is very exciting as it eliminates the OS image management process which in turn can reduce IT costs. By pre-registering devices with Microsoft Intune when a user receives a device from the OEM, upon boot and connecting to the internet, the device will see that it’s registered with Microsoft Intune and go through the Autopilot process.
When organizations continue to utilize ConfigMgr, the CM agent can be pushed from Intune and the device now connects directly to ConfigMgr (when on corporate network) or through the Cloud Management Gateway giving your organization the confidence of maintaining current processes. Additionally, utilizing task sequences in ConfigMgr, Windows 7/8 devices may be upgraded to Windows 10 and automatically enabled for AutoPilot thereafter. The Windows 7/8 to 10 upgrade process may be pushed automatically or manually executed by end users (see screenshot below).
What about running scripts and installing software?
Both ConfigMgr and Intune support running PowerShell scripts and deploying Win32 applications, however for complex scripting scenarios such as running in task sequences and complex application deployments (i.e. deep app dependencies, etc.), ConfigMgr is unparalleled in this space.
My colleague Danny Guillory (who is also a PM on the Intune team) provided the following comments about Win32 applications and Intune:
“Win32 App Deployment in Intune is a great way to get those .exe applications deployed and installed on those Windows Devices. The Win32 Wrapping Tool wraps all the files within that folder (think of a zipped folder), then distributes and deploys those files to the endpoints. The addition of detection method and delivery optimization makes Win32 app deployment more robust, simplifies distribution of content, and makes Win32 apps a must to explore with Intune Application Deployment.”
Additionally, MSIX is a new app packaging format that can take existing Win32 applications such as APP-V, MSI, .exe, etc. and package them in the new MSIX format. Many partners already support MSIX as well and for more details on MSIX packaging please visit: https://docs.microsoft.com/en-us/windows/msix/
If you’re looking to simplify application deployment both ConfigMgr and Intune provide the tools needed to deploy applications.
Monitoring and Reporting
Finally let’s talk about monitoring and reporting. ConfigMgr comes with hundreds of built-in reports, in addition there are newer monitoring and reporting capabilities with co-managed devices and a new reporting feature called CMPivot that provides real-time state of devices (see screenshot below). If you’re looking to creating dashboards based on ConfigMgr data, look into the Power BI template for ConfigMgr.
There are many Ignite sessions covering the topics in this post as well, to watch videos and learn more about the services and features discussed in this post please visit: https://www.microsoft.com/en-us/ignite search for “configuration manager”, “MSIX”, “Intune”
In conclusion, as organizations plan for the future of modernizing Windows management processes, my message to those organizations is to continue to leverage your current investments in ConfigMgr and keep current with releases. In parallel, begin to look at the benefits of cloud attaching ConfigMgr and/or managing workloads with Intune.
I am pleased to have Chris Baldwin from Microsoft as a guest blogger this month. Chris is a Principal PM for Android on the Intune Engineering team. Chris has been working in Android space for the past couple years and leads delivery of Android Enterprise features.
NFC-based Android Enterprise device enrollment with Microsoft Intune – By Chris Baldwin, Principal PM, Microsoft Corporation
For corp-owned Android Enterprise devices (technically referred to as devices in “device owner” mode) there are a number of streamlined enrollment methods available. Depending on your Android version it’s possible to enroll devices with a QR code, by manually entering a short enrollment string, through Google’s Android zero-touch enrollment service (basically, Android’s answer to Apple’s Device Enrollment Program). It’s also possible to use NFC to perform enrollment, which makes provisioning devices as easy as tapping them on a specially formatted NFC tag. This blog will explain how you can use a couple inexpensive and readily available tools to program your own NFC tags to use for Intune device enrollment.
Android Enterprise for BYOD and corp-owned devices
There are two core ways to manage Android Enterprise devices depending on whether the device belongs personally to the end user of the device (BYOD) or if the device is corp-liable, an asset owned by your organization. Those modes are:
Work profile – in this mode of management the end user self-initiates enrollment with a device they own. The enrollment process creates a new, MDM-managed work profile on the device that sits alongside the user’s personal profile. The work profile is managed by the IT admin and the personal profile is not. This provides both privacy assurances to end users because their personal profile remains unmanaged, and data protection assurances to the IT admin because the work content is containerized and manageable.
Device owner – in this mode the device is fully managed (it is analogous to supervised mode on an iOS device). Device owner mode is unique in that there are two main deployment scenarios that can be configured when devices are in this mode: Dedicated devices, which are userless, heavily-locked down kiosk-style devices ideal for task worker usage, and Fully Managed devices which are associated with and user’s AAD account and are intended for core productivity usage (calling, messaging, Outlook, Office apps, and so on). Enrollment of device owner devices is also unique in that the device must be fully factory reset to be enrolled.
As of the writing of this blog, Intune supports work profile mode and the Dedicated (kiosk) device owner deployment scenario. Fully Managed support is currently being built and we expect it to be in public preview by the end of 2018, with general production support available in Q2 of 2019.
Why use NFC?
There are a couple reasons why using NFC-based enrollment might be useful for your scenario. First, it’s the only device owner enrollment mechanism that is supported on Android version 5.1. If you are using 6.0 and up there are additional options. Second, it’s very easy to use. You can program your NFC enrollment tag with Wi-Fi connection information, so you don’t need to perform any steps to enroll the device beyond tapping it. As a reminder, NFC enrollment is available on device owner devices only, and won’t work for work profiles.
What you’ll need
For NFC-based enrollment, you’ll need two items:
Blank NFC tags. I used NTAG216 NFC tags, however you may use any tags that you’d like. One thing to remember is NFC cards come with varying amounts of capacity in bytes. You’ll want to be sure that you buy ones with enough byte capacity to store all the NFC data necessary for enrollment. The amount of capacity you’ll need varies depending on how many options you put into your NFC data, but at minimum you’ll need 561 bytes. More will be required if you add Wi-Fi connection options. The NTAG216 tags I used have a usable capacity of 888 bytes.
Once you have the blank tags, you’ll need something to imprint/write the correct data onto the tags. You may use any NFC tool that you choose as long as it’s capable of writing NFC tags with an arbitrary mimetype. I demonstrate the process later in this post using the NFC Tools PRO app from the Play Store.
Steps to follow Guidelines
The NFC data that will be written to the NFC tags needs to be of a very specific format and will contain a lot of boilerplate data.
There is a portion of the tag data that you can copy and paste directly from this post because it will be identical for every Intune enrollment.
There is also part of the tag data that must be changed to match the enrollment token generated in your Intune tenant.
Finally, there are optional NFC data parts that you can choose to use if you want to use the tag to automatically turn on Wi-Fi during the NFC provisioning process.
Step 1: Format your NFC data Tag data that must be copy-pasted as-is
The following NFC data lines must be entered precisely as they appear here. These lines tell the device where to download the MDM agent from and ensure that it is installed properly:
Tag data you must change for your tenant
The line below must be copied precisely as it appears, except you must change the highlighted text to match the enrollment token you want to use for the device enrollment. This should match the token text that is displayed in the Intune admin console. This is what will associate your NFC enrollment with your Intune tenant.
Optional tags you can use for Wi-Fi connections
Optionally, you can use these lines to tell the device to automatically connect to a W-Fi network that it’ll use to perform enrollment. For example, these are the lines I used to connect to an open authentication network in my office called “MSFTGUEST”:
Note: I have observed that the PROVISIONING_WIFI_PASSWORD line must be included even if there is no password required for the network. It seems like a quirk that shouldn’t be necessary, however I have seen devices fail provisioning without it. The valid options for security type are NONE, WPA, and WEP.
Step 2: Configure the app with the tag data
As a reminder, I’m using the NFC Tools PRO app to demonstrate the enrollment process, however you may use your tool of choice for writing NFC data.
Under the Write tab, select Add a record
Scroll to the bottom and select Data: Add custom record
In the content-type field enter “application” in the first text box and then “com.android.managedprovisioning” in the second (without the quotes)
Take the all the tags above and put together to look like the following and past it into the data section of the app:
In the Data: field enter the big NFC data blob that you formatted in the step above. It should look close to this:
Step 3: Write your NFC data to the tags
Bump your device against your blank NFC tag
Step 4: Enroll devices!
Now that you have your properly formatted and programmed NFC tag from Step 3, the only thing left to do is to enroll devices. You can do this on any Android 5.1 or above device:
Factory reset the device (this is a necessary step for any device owner provisioning)
Once the device is reset and is on the initial welcome screen, bump the device against your NFC tag
From this point on, the device will enroll into Intune using the enrollment token your specified in your NFC data. You can use the same NFC tag again and again to quickly bulk provision a large number of devices. If needed, you may reprogram the tags with different enrollment tokens as well.
NFC is one of the lesser known enrollment techniques for Android Enterprise, however it can also be one of the most powerful because of how easy it is to kick off device enrollment once you get the tags properly programmed. I hope you found this useful!
Last month I wrote about the different Android enrollment scenarios Microsoft Intune supports. For this month’s post, I’m focusing on the Android enterprise enrollment process, specifically single purpose device enrollment (e.g. kiosk) using a factory reset device.
Note: the device must be factory reset to enroll using Android enterprise.
Let’s get started
Create an Azure AD Group
Create a group in Azure AD that will dynamically add Android enterprise devices to it. This group will be associated with the Android enterprise enrollment profile. To do this,
Navigate to portal.azure.com, locate and select Azure Active Directory
Select Groups > New group
Group type should = Security
Provide a name for the group such as “Android Enterprise Kiosk Profile”
Membership type = Dynamic device
Select Dynamic device members
Use a simple rule using the “enrollmentProfileName” attribute to create the dynamic rule as shown below:
Under settings select Kiosk > Kiosk mode: either select Multi-app or Single app kiosk. For this post I’ve selected Multi-app kiosk.
Select Add and add the apps previously added to Managed Google Play that were synced with Intune. Remember, do not add the Managed Home Screen app (otherwise it will show up as an app on the screen of the kiosk device which isn’t necessary).
For the remaining settings, feel free to configure the other settings to match your business requirements.
There are various methods for enrolling a device shown in the table below:
Below are the series of steps performed when my Pixel 2 device is enrolled with Intune with Android enterprise as a multi-app kiosk using a QR code, of course if you prefer, zero-touch is available on supported Android (8.0+) devices as well:
Tap on the screen six times
I tapped 5 times and it’s asking me for 1 more tap
Needs to download the QR reader app before QR code scan
Connect to Wi-Fi so we can download the QR reader
Once connected to Wi-Fi the device checks for updates
Downloading Google Play Store
Checking device info…
Installing QR Reader
Once the QR Reader is installed it will use the camera to scan the QR code under the Android enterprise enrollment profile created earlier
QR code is accepted and we’re prompted to continue setting up the device.
Updating the Google Play Store again which is connecting to the Managed Google Play store
Downloading Google Play services…
Uploading Google Play services…
Finish device updates
Registering the device with Intune
Intune device configuration policy we created earlier is now applied
The Managed Home Screen is applied and the apps we assigned earlier are shown on the locked down kiosk screen.
When I speak with organizations who are considering Android devices there’s usually the question of, “which management option should we choose?”. The answer to the question requires a clear understanding of the scenarios the organization would like to bring under management such as personal devices or corporate devices or even purpose-built devices (e.g. inventory scanners, digital signage, etc.).
There are many different versions of Android from many different OEMs and choosing and supporting each version can be challenging. However, as I’ll discuss later in this post, Android enterprise aims to address OEM fragmentation while providing a variety of management options. Fortunately, Microsoft Intune will address various Android management methods available today including those offered with Android enterprise, so let’s look at how Android management is accomplished with Intune.
The table below walks through each available Android device management scenario, how Microsoft Intune supports it, as well as items to evaluate when considering each option.
Device Management Type
Android Device Admin Considered legacy administration, the Android device administration API has provided APIs to manage the Android device since Android 2.2. The issue with device admin is there are only so many management APIs available, the user experience is challenging, and according to Google, device admin will be depreciated in 2019. With Android Q, device admin will not be available at all.Device Admin requires an Android device to be enrolled via an MDM and requires various administrator permissions during certain enrollment scenarios. As such, device admin offers insufficient privacy for BYOD, insufficient management capabilities for corporate owned devices, and a poor user experience all around. In addition, device admin is less secure than Android enterprise and device admin is not ideal for an environment requiring minimal or no touch enrollment.To learn more about device admin deprecation please visit: https://developers.google.com/android/work/device-admin-deprecation
Intune supports devices enrolled with device admin on Android 4.4+
For BYOD, Intune App Protection policies are a great choice as the policies protect the corporate data at the app layer without requiring the user to enroll their device.
Samsung KNOX Standard With Samsung devices, Samsung added their own management APIs which expands the management capabilities for devices enrolled with device admin. An example is managing the email profile for the native email app on a Samsung device.KNOX is only available with certain Samsung devices so utilizing other OEM devices would require device admin or Android enterprise.Note: Samsung has announced the unification of KNOX and Android enterprise. More details may be found here: https://www.samsungknox.com/en/blog/android-enterprise-and-samsung-knox-your-questions-answered-hereSamsung also offers KNOX Mobile Enrollment (KME) which allows for automatic enrollment of devices even after a reset. KME is supported starting with Android 2.4 and KME is beneficial for mass enrollment of devices without having to touch each one. Devices may be manually and/or added through a carrier to an MDM. After which, users will experience a streamlined enrollment process which removes the touch points required by device admin.KNOX Mobile Enrollment is only available with Samsung devices so if no touch enrollment is needed for other device OEMs, Android enterprise may be an option.To learn more about KNOX Mobile Enrollment please visit: https://www.samsung.com/us/business/solutions/samsung-knox/mobile-security-solutions/knox-mobile-enrollment/
Intune supports KNOX standard without additional licensing for KNOX. However, KNOX also requires Device Admin enrollment as well. Once a device is enrolled with an MDM the end user will also see prompts about KNOX after which both device admin and KNOX policies may be deployed to the device. KNOX Mobile Enrollment streamlines the enrollment process by enrolling the device automatically.
Up to this this point we’ve reviewed traditional management methods available on Android as well as enrolling and managing Android devices with Intune. However, if you’ve noticed, there seems to be a theme throughout and it’s around Android enterprise. It appears all paths are leading to Android enterprise so let’s learn about what Android enterprise is and how Intune will assist with managing devices enrolled using Android enterprise.
Android enterprise Android enterprise (AE) offers a variety of management scenarios for certified devices providing more robust management APIs over device admin. Although Android enterprise is supported on Android 5.0+, Google recommends 6.0 or later.Once a device is enrolled in an MDM such as Intune, Android enterprise has the concept of a work profile (formerly Android for Work) that separates or containerizes corporate applications and data on a personal device. The managed profile contains corporate data and allows only applications within the work profile to access the data within while leaving personal data separate. To learn more about work profiles please visit: https://support.google.com/work/android/answer/6191949?hl=enIn addition to work profiles, Android enterprise offers Device Owner mode where corporate owned devices are enrolled with an MDM and managed based on the purpose their intended for. To learn more about Android enterprise management for company-owned devices please visit: https://www.android.com/enterprise/management/To provision the device owner mode the device must be factory reset, unfortunately there are no migration paths to device owner mode from device admin. The provisioning process may be driven by NFC, QR code, or zero-touch. Previous versions of Android such as 5.0 and 5.1 can use an activation code to begin the enrollment process.For more details about device provisioning please visit: https://developers.google.com/android/work/prov-devicesTo learn more about AE management scenarios please visit: https://www.android.com/enterprise/management/Note: as stated previously, moving from device admin to Android enterprise requires a factory reset. Consider the ramifications of already deployed devices to end users and in the workplace before beginning a migration. A strategy of enrolling new devices with device owner while continuing to manage existing devices enrolled with device admin may be an option. Through attrition, devices will onboard using Android enterprise. As mentioned earlier, with Android Q, device admin will not be an option.
Intune supports Android enterprise purpose-built device management including single-use and work profiles which aligns with many organizational use cases.
Details on how to configure Intune to and manage devices supporting Android enterprise are below.
Applications, including LOB apps are published through managed Google play.
Selecting an enrollment option
Choosing an enrollment option really depends on the scenario and what your business requires. For example, if your devices require minimal or no touch enrollment you may consider KNOX Mobile Enrollment and/or Android enterprise. Since Android enterprise appears to be OEM agnostic, if the plan is to have various device OEMs deployed, devices supporting Android enterprise may be an option. However, if devices are used for kiosk, digital signage, ticket printing, inventory scanning, Android enterprise would be something to investigate as well. If devices are personal devices (BYOD), I recommend looking at Intune App Protection for unenrolled devices and/or Work Profiles. Lastly, before selection consider the short- and long-term ramifications of one option over another.
That’s it! We’ve reviewed the options available for Android enrollment and Intune, documentation on how to enroll Android devices, and the future of Android management through Android enterprise.
Windows Autopilot is a Windows 10 feature that enables organizations to pre-register devices either through an OEM or manually. When users receive a Windows 10 device that is registered with Autopilot and turn it on, they’ll walk through a streamlined and customized out of box experience (OOBE). In summary, Autopilot helps to reduce the costs (and in some cases, infrastructure) of deploying devices to users.
If Autopilot were to run into an error there are several methods to check what and why issues occurred. Michael Niehaus has several posts about troubleshooting Autopilot including a recent blog post outlining new methods of accessing information to investigate Autopilot. Refer to Michael’s posts for detailed information on how to troubleshoot Autopilot.
In this post I’m sharing a simple script I wrote (based on the info Michael Niehaus outlined in his post) to view aggregated information about Autopilot from the registry and event viewer. In addition to registry and event viewer info, deeper investigation steps may be pursued with ETW.
Let’s get started
Windows 10, 1709 or later
Feel free to modify the script to suite your needs such as remotely pull information from devices, etc.
The script is straight forward, first it looks for the Windows 10 version, i.e. 1709, and if it’s greater than or equal to “1709” it runs through both steps and pull registry and event logs. If the installed OS is greater than “1709” it will only pull event logs for 1709 as registry entries didn’t show up until 1803. Lastly, the script only pulls the latest 10 events, however that is easily modified.
#Get Windows Version
$WinVersion = (Get-ItemProperty -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion” -Name ReleaseId).ReleaseId
Write-Host WindowsVersion= $WinVersion