Set up Intune

There are several steps required to set up Intune before you can manage devices. These steps are as follows:

1. Understand supported configurations These include the supported device operating system, network requirements, and commercial versus sovereign cloud.

2. Create a subscription Add Intune to your tenant, taking into consideration whether you have a Microsoft Online Services account, an Enterprise Agreement, or a volume licensing agreement.

3. Configure a custom domain name Configure a custom or vanity domain name to use with your tenant. It is recommended to do this before adding user accounts to simplify account management.

4. Add users and groups Add individual users and groups to Intune. Alternatively, connect to Active Directory with Intune for synchronization.

5. Assign licenses Associate purchased Intune or Enterprise Mobility + Security licenses with user accounts.

6. Set the MDM authority This applies only to tenants with a service release earlier than 1911. Tenants running 1911 or later are automatically configured to Intune.

7. Assign apps Apps can be assigned to groups for automatic or optional installation.

8. Configure devices Configure the profiles that manages device settings and features.

9. Customize the portals Add your company branding to the various portals.

10. Enable device enrollment Enable certain devices to be enrolled for management by Intune.

11. Configure app policies Configure specific app protection policies for apps protected by Intune.

Assign licenses

You can assign Intune licenses to users from both the Microsoft Endpoint Manager admin center and the Azure portal within Azure Active Directory. To assign a license from the admin center, follow these steps:

1. Log in to the Microsoft Endpoint Manager admin center at https://endpoint.microsoft.com.

2. Click Users.

3. Click All Users, then click the user for whom you want to change license assignments.

4. Click Licenses, and then click Assignments.

5. Select the Microsoft Intune check box and click Save. (The location of the check box varies depending on the type of license you purchased.)

Figure 1-2 shows the Microsoft Intune license enabled as part of the Enterprise Mobility + Security E5 license suite. Each licensed user can access and use the services defined in their profiles for up to 15 managed devices.

Understand the prerequisites for device compliance

Before you get started creating device-compliance policies, there are some technical prerequisites to plan for. Throughout this book you will see some trending prerequisites for each of the cloud technologies, particularly around the required subscriptions. Keep an eye out for these for the exam and take some extra time to understand which features are included with the various subscription models.

These are the prerequisites for device compliance:

• Subscriptions Device-compliance technology relies on Azure AD and Microsoft Intune. The device must be enrolled in Intune to receive a compliance policy, and the compliance flag is written to Azure AD for other features, such as conditional access. At a minimum you need a standalone Intune subscription and an Azure AD Premium P1 subscription. The higher-tiered subscriptions, such as Azure AD Premium P2, do not include additional capabilities focused on device compliance.

• Platform support Device-compliance policies support a wide range of platforms. (For clarification, the term platform refers to the operating system, not the physical hardware.) Platform support is an important prerequisite if you are planning to manage devices that are not supported. At the time of this writing, the following platforms are supported:

  • Android

  • Android Enterprise

  • iOS

  • macOS

  • Windows 8.1

  • Windows 10

• Enrollment Devices cannot report compliance until they are enrolled in Microsoft Intune.

Understand the process flow for device compliance

Device compliance and conditional access are both policy-based technologies. You configure the policy to address your needs, and then assign that policy to the desired resources in Microsoft Intune. Devices will evaluate the policy and report back whether they meet the requirements or not. The compliance state is then written to the device object in Azure AD as a custom attribute. The state of that attribute will determine whether the device is approved to access data and services. This is where conditional access enters the picture, which is covered in more detail later in this chapter.

Figure 1-5 illustrates the device-compliance flow. In this example, we are using the default configuration for device compliance. As an administrator, you have a few options to change this flow to meet your needs.

These next few items address controls that are available to administrators to alter the device-compliance flow.

• Intune enrollment Devices that are not enrolled in Intune cannot receive device-compliance policies. This also applies to devices that are Azure AD joined. This was covered earlier in the prerequisites section. In this context, it can also be used to prevent compliance policies from applying to unmanaged devices.

• Policy assignment In the compliance policy settings for Microsoft Intune, you have the option to mark devices as compliant if they do not have a policy assigned. By default, all devices without an assigned policy are marked as noncompliant. But you do have the option to change this behavior, making all devices compliant by default. This is represented by the dashed line between the policy assigned and the device marked compliant in the illustration, also marked as optional.

• Device exemption Device exemption is another control you can configure. This is accomplished in the policy settings by defining which device platforms the compliance policy is scoped for. If your compliance policy includes all platforms except iOS, then iOS devices will be exempt from running that policy.

Determine use cases for device compliance

In this section, you are going to look at some potential use cases for device compliance. First, understand that compliance policies contain a series of rules that you define. These rules determine whether a device is compliant. Compliance policies can help to remediate certain conditions, but in most cases the device will be quarantined, and remediation will be left up to the user. For example, suppose you have a device-compliance policy that has a security rule that requires a password before unlocking a device. If a device is noncompliant with this policy, the user will be prompted to set a password on their noncompliant device.

Users with devices that are marked as noncompliant will receive notifications about the conflicting rules. As an administrator, you can also create a conditional access policy to block these devices until they are remediated. See Table 1-1 for a series of compliance policies and corresponding sample use cases.

Design conditional access policies

In this skill section, you will review the design aspects of conditional access policies. As you prepare for these skills, plan to spend time working in the Azure portal and following along to review the interface and controls for conditional access.

This section began by covering what device compliance means from a cloud-management perspective. Now you will see how device compliance is used to establish access requirements for data and services in your organization.

Design for the protection of data and services using conditional access policies

There are a variety of policy settings available for conditional access, and a mixture of configurations that you can implement. Let’s first look at the Conditional Access Policies blade in the Azure portal. This will help set the stage for conditional access policies and introduce you to some key terms. Figure 1-6 shows the New Conditional Access Policy blade. Let’s drill down and take a closer look at each of the available options.

• Assignments These define the scope, criteria, and conditions of the policy you are deploying. The New Conditional Access Policy blade contains three assignment categories:

  • Users and Groups These define who will receive the policy. You can either include or exclude users and groups. Although the New Conditional Access Policy blade does not prevent you from proceeding, all conditional access policies require a user and group assignment before they can be applied. For includes, you can select all users or specific users and groups. For example, if you have a group that contains only your marketing team, you can select that as an option. For excludes, you can select all guest users (defined by the userType attribute), specific directory roles (such as application developer), or specific users or groups.

  • Cloud Apps or Actions These define the services that users will access for productivity. You have the choice to include or exclude services on a predefined list of supported cloud apps. For includes, you can select all cloud apps or specific apps, such as Microsoft Teams. For excludes, you can select specific apps.

  • Conditions These define when a policy is applied. See Table 1-2 for a breakdown of each condition, the available options, and some sample use cases.

Condition	Description	Options	Sample Use Case
Sign-in risk	Azure AD determines a user’s sign-in risk based on a configurable policy under Azure AD Identity Protection.	High, medium, low, or no risk	Enforce MFA policy for users who are flagged with a medium sign-in risk.
Device platforms	Azure AD retrieves the operating system of the joined device, but the information is not verified. This should be combined with a Microsoft Intune enrollment and device-compliance policy.	Android, iOS, Windows Phone, Windows, macOS	Enforce an app restriction policy on iOS and Android devices only.
Locations	Locations are used to define trusted network locations. Trusted network locations are configured in Azure AD under Named Locations.	Trusted locations	Block access to Exchange Online from the San Francisco office with an IP subnet of 10.20.11.0/22
Client apps (preview)	Set conditional restrictions based on specific client apps.	Browsers, mobile apps, and desktop clients	Restrict access to mobile apps unless the device is marked as compliant.
Device state (preview)	Exclude corporate or trusted devices from conditional access restrictions.	Hybrid Azure AD joined devices, devices marked as compliant	Enforce restrictions to Office 365 Exchange Online for noncompliant devices.

• Access Controls These define additional requirements for granting or denying access, along with session controls for limiting the experience within cloud apps. The following options are available from the Access Controls section:

  • Grant This enables you to block access based on the conditions that you defined under the Assignments section. Alternatively, you can choose to grant access and enforce additional requirements. For example, you can require MFA or only grant access to devices that are marked as compliant through device-compliance policies.

  • Session This enables you to limit the experience within certain cloud apps. At the time of this writing, Exchange Online and SharePoint Online are the only cloud apps that support app enforced restrictions. Enabling this feature adds real-time monitoring and control capabilities to these apps.

Now that you have spent some time exploring the interface, let’s look at how a conditional access policy is constructed. The policy is made up of two parts: the condition and the access control. You can also look at these in the following context: when this happens (condition), then do this (access control). For the exam you should be familiar with this formula and how it corresponds to conditional access restrictions. See Table 1-3 for a few examples on how conditional access policies are assembled.

When This Happens (Condition)	Then Do This (Access Control)
Windows and macOS device owners are accessing SharePoint Online from an untrusted network. Additional security requirements are needed.	Grant access to SharePoint Online for Windows and macOS devices. Require multi-factor authentication and a compliant device when accessed from an untrusted network.
The sales team is accessing Exchange Online from their iOS and Android devices. These devices must be compliant before access is granted.	Grant access to Exchange Online for the sales group. Require all sales team device owners to be enrolled in Intune and marked as compliant.
All users are accessing Microsoft Teams from trusted and untrusted networks. Users that are on an untrusted network need additional security requirements.	Grant access to Microsoft Teams for all users. Require multi-factor authentication when accessed from an untrusted network.
BYOD devices are accessing Exchange Online from their browser. Access needs to be restricted to approved apps.	Grant access to Exchange Online for all users. Restrict access to trusted client apps only.

The following list covers prerequisites that you must be familiar with. Some of these are firm requirements and others are strategic questions to help prepare you for designing policies.

• Subscriptions The basic capabilities of conditional access are available with an Azure AD premium subscription. There are additional capabilities, however, that will not be available until you upgrade your subscription. These include the following:

  • Azure AD Premium P1 The P1 subscription provides you with the basic capabilities of conditional access policies.

  • Azure AD Premium P2 The P2 subscription enables Identity Protection, which is required if you want to leverage sign-in risk. Sign-in risk is a capability that determines whether a user sign-in is malicious and measures the risk level. This can be leveraged as part of your policy conditions.

  • Microsoft Intune Intune can be purchased standalone or through an Enterprise Mobility + Security E3 or E5 subscription. Policy definitions that require a compliant device depend on the device being enrolled in Intune.

    Need More Review? Subscription Details

    For more information about Azure AD subscriptions, visit https://azure.microsoft.com/pricing/details/active-directory/. For more information about Microsoft Intune subscriptions, visit https://www.microsoft.com/cloud-platform/microsoft-intune-pricing.

• Permissions Before you can start creating and managing conditional access policies, you will need the appropriate permissions assigned to your account. Conditional access administrator is a predefined role that that enables the necessary privileges.

• Requirements to be delivered What requirements do you have for device compliance and conditional access? This is something you should start defining from the beginning. Determine whether your goal is something straightforward (such as enforcing multi-factor authentication for users) or something more advanced (such as restricting access to SharePoint Online from Windows devices when they are connected to an untrusted network).

• Device management What kind of device-management solution are you using today? The full capabilities of conditional access have dependencies on Microsoft Intune, but if you are using ConfigMgr, you can enable co-management and start leveraging conditional access policies sooner.

• Device platforms What types of devices and operating systems do you need to support? Conditional access policies support a variety of operating systems. At the time of this writing, the only current outliers are devices running Linux. Consider the devices in your environment and what types of restrictions you need to enforce.

• Email requirements What are your access requirements around email? Email is often used as one of the first services for enforcing conditional access restrictions. If your goal is to enable access restrictions for Exchange Online, then selecting the cloud app from the default list of assignments is straightforward, and is something you will look at later in this chapter. If your goal is to enable access restrictions for an on-premises Exchange server, you must plan for additional prerequisites, such as installing and configuring the on-premises Exchange connector.

Endpoint security profiles

To reduce the attack surface of a device, you can use endpoint security profiles in Intune. When creating a new profile, the supported operating system is Windows 10 or later. The available profile settings are as follows:

• App and Browser Isolation Isolating processes and applications on the device can prevent known and zero-day attacks. You can manage these settings with Windows Defender Application Guard with Defender for Endpoint by identifying the apps, websites, or networks that should be trusted.

• Device Control This setting enables you to configure security settings for removable media on the device.

• Attack Surface Reduction Rules This setting configures the available options in the Defender for Endpoint software on the device. This can include configuring rules and actions to take for downloaded executable files or suspicious scripts.

• Exploit Protection This helps protect against malware that has been identified to use known exploits for the selected platform or device to prevent the malware from spreading.

• Web Protection (Microsoft Edge Legacy) This setting enables you to protect against harmful websites that are phishing, using known exploits, distributing malware, and more.

• Application Control These settings enable you to block unsigned scripts or installation files and restrict applications that can access the system kernel.

Configure endpoint security profiles

To create a policy that uses one of these available profile settings, follow these steps.

1. Log in to the Microsoft Endpoint Manager admin center at https://endpoint.microsoft.com.

2. Click Endpoint Security.

3. Under Manage, click Attack Surface Reduction.

4. Click Create Policy.

5. Select the platform and desired profile type. For this example, select Device Control.

6. Click Create.

7. On the Basics tab, type a name for the policy — for example, DeviceControlPolicy — and click Next.

8. On the Configuration Settings tab, configure the desired policy. For example, set Block Removable Storage and Block Bluetooth Connections to Yes. (See Figure 1-7.) Then click Next. Figure 1-7 shows these settings being configured.

   

9. On the Scope Tags tab, select any desired scope tags. For this example, leave the default (blank) settings as is and click Next.

   Scope tags enable you to filter the policy to specific tags.

10. On the Assignments tab, configure the included or excluded groups that the policy should apply to. For this example, click Add All Devices and then click Next.

11. On the Review + Create tab, click Create.

Similar to the configuration profile you created in skill section 1.1, the endpoint security policy you create here will apply to the users or devices that you assigned it to in step 10.

After you create the policy, you can view its assignment status and properties by selecting it. Figure 1-8 displays the configured policy in the Microsoft Endpoint Manager admin center.

Navigate and configure device-compliance settings

When you access the Device Compliance blade for the first time, the first thing you might notice is the number of options available compared to the conditional access interface. The core functions are split into three groups: manage, monitor, and setup.

1. Log in to the Microsoft Endpoint Manager admin center at https://endpoint.azure.com/.

2. Click Devices, and then click Compliance Policies.

3. Click Create Policy.

4. Select the desired platform for the policy to apply to, and then click Create.

5. On the Basics tab, provide a name for the policy, such as CompliancePolicy, and then click Next.

6. On the Compliance Settings tab, select the settings required for the device to be considered compliant, and then click Next. For example, choose Require for the Require BitLocker setting. Figure 1-10 shows the compliance settings to configure for Windows 10 device health.

   

7. On the Actions for Noncompliance tab, select the action(s) to take if the device does not meet the settings defined on the previous tab, and then click Next.

   For example, you can choose to send an email notification to the end user and other recipients or retire the device after a set period of time.

8. On the Assignments tab, add the users or groups that you want the policy to apply to. For example, click Add All Users. Then click Next.

9. Review your settings and then click Create.

Device compliance includes several built-in reports for administrators to review and export as needed. This includes an overview dashboard, providing a high-level look at overall compliance and areas of interest. Later in this section you will look at monitoring in more detail.

When you first begin working with device compliance, there are some configurations that you should review. In the Compliance Policies blade, click Compliance Policy Settings. There are three controls on this blade that you should explore before you begin creating policies.

• Mark Devices with No Compliance Policy Assigned As [Compliant | Not Compliant] The default configuration for this setting is Not Compliant. In many cases, this will be the desired setting, because you will want to have some understanding of the device state before granting it access to services. For example, consider a scenario in which you assign a conditional access policy that requires devices to be compliant to access Exchange Online.

• Enhanced Jailbreak Detection [Enabled | Disabled] The default configuration for this setting is Disabled. Enabling this feature requires iOS devices to evaluate and report their jailbreak status more frequently in conjunction with leveraging location services. Note that enabling this setting will affect the device’s battery life.

• Compliance Status Validity Period (Days) [1–120] The default configuration for this setting is 30 days. This value determines the frequency with which devices must report back their device-compliance status to Intune. If a device does not report compliance within the required timeframe, it will be marked as noncompliant.

Each compliance policy you create is associated with a specific device platform, unlike conditional access policies, which enable you to select multiple platforms. Each platform has its own set of options. Some will be similar across platforms, but others will not. For example, macOS has a rule requiring system integrity protection, which is exclusive to this platform. Based on this, you should design your policies on a per-platform basis.

Plan for Microsoft Store for Business prerequisites

The MSfB is designed for organizations that want to take a modern approach to managing their application portfolio. Managing and delivering apps using this solution provides IT administrators with several capabilities. Table 1-4 contains a list of core features included with the MSfB.

As you begin planning for MSfB, there are a few prerequisites that you should be familiar with. First, you must understand the difference between the two available licensing models: online-licensed apps and offline-licensed apps. Which licensing model you choose can dictate which prerequisites you need to address.

• Online-licensed apps Apps purchased using the online licensing model require users to connect to the Microsoft Store service to acquire the app and corresponding license. Licenses are maintained using the user’s Azure AD identity. This is the default license model, and it will be the primary option if your users have Azure AD accounts and if access to the Microsoft Store is enabled.

• Offline-licensed apps Apps purchased using the offline licensing model do not require connectivity to the Microsoft Store. Instead, administrators can download their purchased apps and licenses for deployment within their internal network. Not all apps support offline licensing. It is up to the independent software vendor (ISV) to opt in for this option in the development center by selecting the Disconnected (Offline) Licensing setting during submission. Offline-licensed apps can be deployed at imaging time using a provisioning package or distributed to systems using a management solution such as ConfigMgr.

Next, let’s cover the baseline prerequisites for setting up MSfB. These are items you must plan for before you begin your implementation. Take note of the items that mention online and offline licensing requirements. These will differ slightly depending on which licensing model you choose.

• Microsoft Store for Business account A global administrator must visit https://businessstore.microsoft.com and sign in to activate the private store.

• Azure AD accounts for admins Administrators tasked with acquiring apps, distributing apps, and manage licensing need an Azure AD account. These requirements are the same for both online and offline licensing.

• Azure AD accounts for users An Azure AD account is required for users who access the MSfB to download and install online-licensed apps. Users do not require an Azure AD account for offline-licensed apps.

• Platform support Users accessing the MSfB must do so from a supported PC or mobile device. This includes Windows 10, version 1511, or later.

• Browser support Administrators managing the MSfB must do so from a supported browser. MSfB is compatible with Internet Explorer 10 or later and current versions of Microsoft Edge, Chrome, or Firefox.

Set up the private store

The private store is designed to help organizations deliver a unified experience to their employees when browsing and installing apps. This feature enables administrators to customize their own private Microsoft Store and manage app purchasing and distribution. From a user-experience perspective, this includes the ability to adjust app visibility in the store based on user or group membership, along with grouping and sorting apps to your liking. Figure 1-11 shows an example of the Contoso Electronics private store. In this section, we will walk through the process of setting up a private store for MSfB.

For the following example, suppose you are an admin for Contoso Electronics. You have been tasked with creating a private store for your organization. Follow these steps to set up the private store:

1. Navigate to the Microsoft Store For Business at https://businessstore.microsoft.com.

2. Sign in using an Azure AD global administrator account.

   Signing in without a global administrator account will only give you access to browse the standard Microsoft Store For Business.

3. In the menu bar at the top of the page, click the Private Store option. (See Figure 1-12.)

   

   If this option is not visible, maximize your browser window. Alternatively, locate the collapse menu button in the upper-left corner, click it, and select Private Store from the navigation menu.

   A Microsoft Store for Business consent form opens.

4. The first time you try to manage the private store, you will be prompted to activate it. Click the Activate Private Store link (see Figure 1-13) to continue with the initial setup.

   

The private store has now been created and is associated with your Azure AD tenant. Once this happens and the store becomes available, you can access the Manage menu, which contains several administrative options, which you will review in more detail in the next section.

At the time of this writing, if you click the Private Store option after accepting the consent form, you will see text that states: Check with your admin. They need to set up your private store before you can use it. This can be a bit confusing because the store has already been created. It turns out that before you can access the private store and see apps, you must accept a service agreement. You can do this by adding an app to your inventory.

Continuing with the Contoso Electronics scenario, register a free copy of the OneNote app to trigger and accept the pending service agreement.

1. In the menu bar at the top of the page, type OneNote in the search box and press Enter.

   If the search box is not visible, maximize your browser window. Alternatively, locate the collapse menu button in the upper-left corner, click it, and enter your search term in the navigation menu.

2. In the search results, locate and click the free Microsoft OneNote app.

3. On the OneNote shop page, click Get the App.

4. Review the Microsoft Store for Business and Education Services Agreement, select the check box to accept the agreement, and click Accept. (See Figure 1-14.) This agreement is required to start using the private store.

   

5. On the Thanks for Your Order page, click Close. This confirms that the app has been purchased and added to your app inventory.

At the conclusion of this scenario, the Private Store option on the menu bar will be replaced with the name of your organization (taken from your Azure tenant). When you click your organization name, you should see the OneNote app listed in your app inventory. At this stage, you can open the Microsoft Store on a compatible Windows 10 device, sign in with your Azure AD credentials, and access your organization’s private store.

Configure Microsoft Store for Business

The management portal for MSfB contains several pages for app administration, licensing, and account management. Among these pages are a few controls to customize the private store. This section will introduce you to the portal and walk through each of the available menu options.

Figure 1-15 shows the MSfB management portal. To access this portal, you click the Manage button along the top of the screen. In this figure you see a navigation menu in the left pane, and the Overview page open on the right. The navigation menu contains the administrative controls for managing your organization’s MSfB experience. Let’s take a closer look at the available options in the navigation menu.

• Home This directs you to a page that provides an overview dashboard with summary information for various items such as license availability and recent purchases. The overview also includes drill-down objects to other management options such as settings and permissions.

• Quotes Use this page to view and interact with quotes that have been assigned to your organization for apps and other solutions. This page will be blank unless you have a partner that has sent you a quote.

• Products & Services Use this page to view your app inventory, benefits information, and new LOB apps. App inventory will include all registered apps for your organization along with drill-down details and customization options for each app. Benefits information is tied to your Microsoft agreement. LOB apps are any newly registered LOB apps assigned to your organization.

• Benefits Use this page to view account profile information, status information for your Microsoft agreements, connected tenants that you established with the Microsoft Products and Services Agreement (MSPA), and review requests that require admin approval.

• Devices Use this page to manage your Windows AutoPilot deployments. AutoPilot is a technology that enables administrators to reduce traditional imaging needs by configuring automated system setup and configuration with Azure AD, Intune, Office 365, and MSfB.

• Billing & Payments Use this page to view invoices assigned to your organization and manage your account payment methods.

• Order History Use this page to view your order history and order details for software and subscriptions purchased by your organization.

• Partners Use this page to view the list of partners assigned to your organization. Partners are available to help organizations purchase and manage products and services. You can search for partner details by navigating to the Find a Solution Provider menu option.

• Permissions Use this page to view and manage the role-based access controls for your organization. This includes roles for admin, purchaser, basic purchaser, and device guard signer. Once your private store is active, it is important to review the default options and define the roles according to your business needs.

• Settings Use this page to view and manage the core settings for your organization’s store experience. This includes shopping controls based on role-based access, distribution settings, and connectivity to your preferred MDM solution, device guard policies, and notification controls for invoices.

• Support Use this page to access support information about MSfB and opening support requests.

Now that you have a better understanding of the management portal, let’s look at some customization controls for the private store. There are two primary locations that contain settings pertaining to the private store. The first is the private store itself, which is listed in the menu bar as the name of your organization. In this example, the private store is called Contoso Electronics. Click this link to access the store interface, shown in Figure 1-16.

This page enables administrators to customize the store interface for their employees. The changes you make here will be visible to employees when they access your organization’s private store. Available options include the ability to create new collections by clicking the +Add Collection button. You can also remove collections and assign apps to collections by clicking the more options icon (•••) next to the collection name.

In this example, the default collection, Contoso Electronics, which contains all available apps by default, is hidden. To replace this collection, we created two new collections: Contoso (shown in Figure 1-16) and File Sharing (not shown). These new collections contain a custom list of apps based on our preference.

To access the second location for customizing the private store, open the Manage page, click the Products & Services tile, and then click the Apps & Software tab. On this page, you will see a list of apps from your inventory, as shown in Figure 1-17.

Plan for app deployment prerequisites

There are a few different ways to deploy apps in the Microsoft cloud. The prerequisites for these methods depend on the requirements of the organization. For example, if your organization uses Office 365 but does not have an Intune subscription, you can still use the MSfB to help manage apps on Windows 10 devices. If your organization does have an Intune subscription, you can set up an MSfB account and integrate it with Intune to streamline the management and distribution of your apps across multiple platforms.

Based on the examples described previously, many prerequisites for app deployment are conditional. That said, you should be familiar with each of the available options and in what situations they apply:

• Microsoft Store for Business Standalone If you choose to leverage the benefits of MSfB, your organization must have an active MSfB account.

• Microsoft Store for Business + Intune If you plan to connect your MSfB account with Intune, you must activate Microsoft Intune. You can do this from the Intune portal; choose Manage, select Settings, select Distribute, and then choose Management Tools.

• Microsoft Intune If you choose to leverage Intune for app management and distribution, your organization must have an active Intune subscription. This includes setting the MDM authority to Intune in the Azure portal.

• Device Enrollment If you plan to require app installation on devices, those devices must be enrolled with Intune.

• Supported Platforms MSfB supports Windows 10 devices. If you need to support other platforms, such as Android or iOS, you must consider an Intune subscription.

• Supported App Types MSfB supports the conversion of multiple Windows app file formats into APPX bundles for distribution. This conversion process requires an install sequence and capture of the app. Intune has a conversion process that converts the installer to a compatible INTUNEWIN bundle. The Intune solution is in preview at the time of this writing. Both scenarios should be planned for if you have a requirement to deploy Win32 apps.

Plan for app deployment types

This section covers planning considerations for app deployment types. This refers to the various app deployment types that Microsoft Intune supports. In the management portal, administrators have access to a variety of app types that they can deploy to users and devices.

One of the first things to consider when planning your app-management model is file formats. An app’s file format can vary by publisher and platform. Variations by publisher exist only for Windows apps, where you have traditional file formats such as EXE and MSI, and newer formats such as APPX and MSIX. This segmentation adds a lot of effort for IT admins that support a variety of apps. Variations by platform includes Android, iOS, and Windows. Modern and mobile apps are all platform-specific and must be considered.

Next, you should know which app-deployment types are available in Intune, and what options they provide. For this, you will open the management portal and look at the client apps.

1. Log in to the Microsoft Endpoint Manager admin center at https://endpoint.microsoft.com/.

2. Click Apps.

3. On the Apps blade, click All Apps.

4. On the All Aps blade, click Add.

5. On the Add App blade, review the list of available app types. See Table 1-5 for a breakdown of each app type and its capabilities.

Create and deploy apps with Intune

This section walks through the app-creation process in Intune and covers how to deploy those apps to enrolled devices. Intune’s app-deployment capabilities continue to evolve, with recent additions including Win32 app support. These are some notable milestones for the product because Win32 app support breaks the barrier from traditional on-premises app management requirements with new cloud capabilities.

Manage Store Apps with Intune

Before you start working with apps in Intune, remember that you can synchronize Microsoft Store apps. Enabling this capability will simplify the management of Microsoft Store apps and provide you the ability to deploy them using Intune.

1. Navigate to the Microsoft Store for Business at https://www.microsoft.com/business-store.

2. Sign in using an Azure AD account with admin access.

3. On the menu bar at the top of the page, click Manage.

4. Click Settings in the navigation menu on the left.

5. On the Settings page, select the Distribute tab.

6. On the Distribute tab, under Management Tools, click Activate in the Action column for the Microsoft Intune and Microsoft Intune Enrollment settings, as shown in Figure 1-18.

Plan for app protection prerequisites

The capability to manage the data within an application has evolved over the years. Microsoft’s solution for this is called app protection policies. This is a feature available with Microsoft Intune.

In the past, application management required the management of the device running the app. With app protection policies, the policy is assigned to the user. This alleviates the need for devices to be enrolled in an MDM. Instead, the user signs in to the app with their Azure AD account and the necessary policies get applied.

The following list covers the basic prerequisites for deploying app protection policies in an organization:

• Azure AD subscription A basic Azure AD subscription is required to establish Azure AD accounts.

• Intune subscription App protection policies are a capability of Microsoft Intune. You need an Intune subscription to create and manage these policies. In addition, users to whom these policies are assigned require an Intune license.

• Office 365 subscription App protection policies assigned to Office 365 mobile apps require users to have an Office 365 license assigned to their Azure AD account.

• Azure AD account Users must have an Azure AD account.

• Supported platforms App protection policies are supported for iOS, Android, and Windows 10.

• Security groups App protection policies are assigned to Azure AD security groups that contain user objects. You must create the desired groups in Azure AD or synchronize your existing on-premises groups using Azure AD Connect.

• Supported apps App protection policies are not available for all apps. The app must support the Intune SDK features that enable app management.

Configure app protection policies

In this section you will create an app protection policy and assign it to a group of users. A common scenario that you may be presented with is app management for Office 365. These are often the core productivity apps for users, and company data is an important aspect to consider.

In the following example, you are going to create an app protection policy for the Contoso Electronics sales team. These users travel often and use a mixture of corporate and personal mobile devices to access company resources. The app protection policy will control data for each of the core Office 365 mobile apps.

1. Log in to the Microsoft Endpoint Manager admin center at https://endpoint.microsoft.com/.

2. Click Apps.

3. Under Policy, click App Protection Policies.

4. On the App Protection Policies blade, click Create Policy, and then click Android.

5. On the Basics tab, fill in the following information:

   • Name APP for Android

   • Description APP for Office 365 apps on Android

   • Platform Android

   • Target To All App Types Yes

6. On the Apps tab, select the following apps and click Next:

   • Excel

   • OneNote

   • Outlook

   • PowerPoint

   • Word

7. On the Data Protection tab (see Figure 1-21), select the following options and click Next.

   • Backup Org Data to Android Backup Services Block

   • Send Org Data to Other Apps Policy Managed Apps

   • Receive Data from Other Apps Policy Managed Apps

   • Save Copies of Org Data Block

   • Allow User to Save Copies to Selected Services OneDrive For Business

   • Restrict Cut, Copy, And Paste Between Other Apps Policy Managed Apps

   • Screen Capture and Google Assistant Disable

   • Encrypt Org Data Require

   • Encrypt Org Data on Enrolled Devices Require

   • Sync App with Native Contacts App Disable

   • Printing Org Data Disable

   • Share Web Content with Policy Managed Browsers Require

     

8. On the Access Requirements tab (see Figure 1-22), select the following options and click OK.

   • PIN for Access Require

   • PIN Type Numeric

   • Simple PIN Block

   • Select Minimum PIN Length 6

   • Fingerprint Instead Of PIN For Access (Android 6.0+) Allow

   • Override Fingerprint with PIN After Timeout Require

   • Timeout (Minutes of Inactivity) 30

   • App PIN When Device PIN Is Set Require

   • Work or School Account Credentials for Access Require

   • Recheck the Access Requirements After (Minutes of Inactivity) 30

     

9. On the Conditional Launch tab (see Figure 1-23), review the default options and click OK.

   

   Conditional launch enforces periodic checks to ensure that app protection policies are up to date and compliant. There are seven available settings:

   • Max PIN Attempts If a user enters their PIN incorrectly more than the defined number of times, the user can be forced to reset their PIN or the app data can be wiped.

   • Offline Grace Period If the managed app does not check in for a defined period, access to the app can be blocked or the app data can be wiped.

   • Jailbroken/Rooted Devices If the device has been jailbroken or rooted, access to the app can be blocked or the app data can be wiped.

   • Min OS Version If the device OS does not meet the minimum version, the user can be warned, access to the app can be blocked, or the app data can be wiped.

   • Min App Version If the app does not meet the minimum version, the user can be warned, access to the app can be blocked, or the app data can be wiped.

   • Min Patch Version If the device OS does not meet the minimum patch version, the user can be warned, access to the app can be blocked, or the app data can be wiped.

   • Device Manufacturer(s) If the device is not made by the specified manufacturer, access to the app can be blocked or the app data can be wiped.

10. On the Add a Policy blade, click Create.

11. On the Client Apps – App Protection Policies blade, select the APP for Android policy.

12. On the Intune App Protection blade, under Manage, click Assignments.

13. On the Intune App Protection – Assignments blade, on the Include tab, click Select Groups to Include.

14. Select the Contoso Electronics Sales group and click Select.

After completing these steps, you should have a new app protection policy created and deployed. You can review the check-in information for users that access this app by navigating to the APP For Android setting and selecting Overview. This tab provides insight into how many users are accessing the associated apps and the check-in count for each app in the policy.

Identify the core components for WaaS

The term as a service (aaS) reflects a transformation in the way digital services are provided to customers. Some common examples of this model include software as a service (SaaS) and infrastructure as a service (IaaS). Both examples are built on cloud-based technologies. Customers now have the option to purchase Microsoft Office as a subscription (SaaS), providing frequent updates and new capabilities every month. Landing servers in your local data center may not be realistic when you can move those servers to the cloud (IaaS) and reduce on-premises support and maintenance.

With Windows 10, Microsoft introduced Windows as a service (WaaS). The idea behind WaaS is that customers no longer buy a new version of Windows every three to five years. Instead, you purchase Windows 10 and receive frequent updates and features.

Moving Windows to a semi-annual release schedule enabled Microsoft to make some foundational changes in how the operating system would be serviced moving forward. As part of that transformation, the company introduced new components in Windows 10 to support the WaaS model. Each of the following is a key component of WaaS and relates to how you will manage Windows 10.

• Feature updates These updates deliver new functionality to the operating system. Feature updates are a core design change in Windows 10 and are a foundation of WaaS. Microsoft delivers these updates twice a year, once in the fall and one in the spring. From a deployment perspective, these updates are designed to be installed in place, over the existing version of Windows 10. Users can expect to retain all their data and applications during the upgrade process. Microsoft has also introduced several tools to help administrators deliver these updates. We will be reviewing each of these tools in this skill section.

• Quality updates These updates deliver security and reliability fixes to the operating system. Quality updates redefine the way administrators manage patching for Windows devices. Before Windows 10, Microsoft released a variety of individual updates on “patch Tuesday.” In managed environments, administrators could then choose which updates to install. For example, some organizations might only install critical security updates each month or completely miss an important update from a previous month. This resulted in fragmented patch levels and reliability issues. Quality updates help address these problems. They are cumulative, meaning the patch content from the previous month is automatically rolled into the next month’s update. They are also condensed, reducing the number of individual updates you need to deploy and manage. For example, instead of six individual security updates for August, you have a single quality update.

• Servicing channels Servicing channels are the management controls used to determine which release of Windows 10 is deployed and when. Feature updates can be delivered using management solutions such as ConfigMgr, but they can also be delivered through Windows Update. Administrators must consider how they want to manage these updates and how frequently they want them installed.

• Deployment rings Deployment rings are used to roll out Windows 10 feature updates in stages. A ring contains a collection of devices that you determine are ready for the upgrade. You might have a ring for pilot devices and a ring for production. These rings can also directly relate to different management solutions and deployment scenarios such as ConfigMgr with Windows 10 Servicing or Intune with Windows 10 Update Rings.

• Windows Insider The Windows Insider program was originally delivered in parallel with the first release of Windows 10. Customers were given the opportunity to join this program and test pre-release features. Participants had access to a feedback mechanism where they could share ideas and bugs. For enterprise customers, Windows Insider for Business was introduced to make enrollment easier.

Plan for servicing channels

We touched briefly on servicing channels in the last section. This section covers servicing channels in detail.

First, it is worth noting that the terminology for servicing channels has changed since their introduction. This was done to help align the update terminology between Windows 10 and Office 365. Earlier naming standards used branch identifiers — for example, Current Branch (CB), Current Branch for Business, and Long-Term Servicing Branch (LTSB). LTSB is still associated with some early editions of Windows Enterprise, but all other components are now referred to as servicing channels.

Servicing channels are broken down into three different types, each delivering a different service. As an administrator, it is your responsibility to identify and deploy the appropriate servicing channel based on the needs of your organization.

• Insider program With Windows 10, Microsoft has encouraged customers to start their testing early. Windows Insider delivers a servicing channel that enables customers to enroll their devices and begin testing new features and capabilities before they are released to the general public. This enables business customers to start compatibility testing earlier. Members of the Insider program also have a direct feedback link through the Feedback Hub application. The Insider program supports three deployment rings:

  • Fast ring Members of this ring are the first to receive new features and changes. These enhancements are validated on a small population of devices before they become available to the fast ring. Customers should expect possible issues and blockers when enrolled in this ring.

  • Slow ring Members of this ring receive Insider builds after members of the fast ring. These builds include updates and fixes for issues identified by fast ring members. There is still a risk that these builds could experience issues, but in general, they are more stable.

  • Release preview ring Members of this ring receive a release preview Insider build in advance of general availability. This enables organizations to start piloting the next release of Windows 10 with minimal risk while still having the ability to provide feedback.

• Semi-annual channel After a new feature update is released to the general public, it enters the semi-annual channel. At this point, administrators can begin managing how these updates are delivered to their production devices. There are two deployment rings for this servicing channel.

  • Semi-annual channel (targeted) Newly released updates will enter this deployment ring first. Customers who choose this ring will receive the latest feature update, with the option to defer up to 365 days.

  • Semi-annual channel After a period of time, usually about four months, feature updates are moved to the semi-annual channel deployment ring. This provides organizations with another option for postponing their rollout in addition to the 365-day deferral rules.

• Long-term servicing channel Customers with specialized systems running Windows 10, such as medical equipment or heavy machinery, can leverage the long-term servicing channel to prevent the deployment of feature updates and receive extended support. Unlike with the semi-annual channel, administrators must install the LTSB edition of Windows 10 Enterprise. There is no configuration option to quickly switch between the long-term servicing channel and semi-annual channel. Administrators must re-image devices if they need to make this change. Also, the long-term servicing channel is not designed for systems that are used for productivity or content creation. Devices running Office should not be using the long-term servicing channel.

Each servicing channel also has a different release cadence and support lifecycle. See Table 1-6 for these details.

Plan for Windows Insider for Business

Windows Insider delivers pre-release builds of Windows 10 to customers that enroll in the Insider program. Once enrolled, your device will start receiving Insider builds. As a participant, you get to try new features and capabilities before they are released. The Insider build also includes a dedicated channel for reporting issues or general feedback to the Windows development team. Through this program Microsoft can collect real-world data from a vast range of users and devices. This data helps address issues and improve Windows before an update is released to the general public.

After joining the Insider program, you enroll your existing Windows 10 device by navigating to the Windows Insider Program Settings page, shown in Figure 1-24. From there, click Get Started and enter your account credentials.

Windows Insider for Business is the same Insider program that we just reviewed, but with some extra controls to help organizations manage their enrolled users and devices. These controls include:

• Domain registration Customers that are synced with Azure Active Directory (Azure AD) can register their tenant with the Windows Insider program. This enables employees to sign in with their Azure AD credentials.

• Track feedback The feedback submitted through the Feedback Hub is tagged with the corresponding user’s Azure AD account. This feedback can then be tracked for internal analysis and data collection.

You can register your domain with the Windows Insider program by following these steps:

1. Navigate to the Windows Insider registration page at https://insider.windows.com/en-us/register.

2. Sign in with your Azure AD account and confirm you have access to complete the registration.

   Confirmation is shown at the top of the page under Register Your Domain with the Windows Insider Program.

   Your account must meet the following requirements. If these requirements are met, you will see a message prompting you to register your domain, as shown in Figure 1-25.

   

   • Assigned the global administrator role in Azure AD

   • Existing participant of the Windows Insider program

3. On the Manage Insider Preview Builds page, click the Register link.

4. On the Register page, review the program agreement, select the check box to accept the terms, and click Register.

5. Review the registration results to confirm your organization was successfully registered. (See Figure 1-26.)

   

Plan for deploying Windows 10 Enterprise

There are two main scenarios associated with Windows 10 deployment. The first scenario involves moving to Windows 10 from an earlier version of the operating system — for example, if your client devices have Windows 8.1 installed, and you are planning a migration to Windows 10. The second scenario involves keeping Windows 10 current with the latest feature updates — for example, your client devices have Windows 10, version 1803 installed, and you are planning to upgrade to Windows 10, version 1809. There are deployment methods for each of these scenarios.

In some cases, a deployment method can be used for both deployments and upgrades, such as the in-place upgrade. Other methods are more specific, such as Windows Update for Business. The first thing you must understand is what options are available and in what scenarios they apply.

• Traditional methods This category includes several of the deployment methods used with earlier versions of the Windows operating system. Microsoft has continued to support these methods, and has released compatibility updates for tools such as the Microsoft Deployment Toolkit (MDT) and the Windows Assessment and Deployment Kit (Windows ADK), both of which support traditional imaging and upgrades. Specific deployment methods in this category include the following:

  • Bare metal This deployment method is for scenarios where new hardware is procured or existing hardware is repurposed. In both situations, a Windows image is installed and configured according to the organization’s IT standards. Bare metal deployments occur at most organizations and are commonly leveraged in situations where you must roll out a new version of the operating system or another major application, such as Microsoft Office. It can help consolidate efforts.

  • Refresh This deployment method is for scenarios where an existing device needs to be wiped and reloaded. In this situation, the existing user state is backed up, the disk is wiped, the latest image is installed, and the user state is restored. Refresh deployments are often seen when a device becomes inoperable and needs to be wiped. This type of deployment can also be used in upgrade scenarios, such as moving from Windows 7 to Windows 10.

  • Replace This deployment method is similar to the refresh method but includes new hardware as part of the process. For example, suppose a user is running a three-year-old laptop with Windows 8.1 installed. You could back up the user state on this laptop and replace it by restoring the backup to a new laptop running Windows 10.

• In-place upgrade This deployment method is for scenarios where an earlier version of Windows (including an earlier version of Windows 10) is installed on a device and you upgrade the device to Windows 10 or to a newer release of Windows 10. This method pertains to upgrading to Windows 10 and staying current. For example, suppose you have a device running Windows 7 and you deploy an in-place upgrade for Windows 10, version 1809. Alternatively, suppose you have a device running Windows 10, version 1803 and you deploy an in-place upgrade for Windows 10, version 1809. Either way, you could use this deployment method. This method retains the applications, settings, and user data on the system. The old version of Windows is moved to a Windows.old folder for a configurable amount of time, which can then be referenced in the event you need to roll back the operating system.

• Modern servicing This deployment method is for scenarios where you need to keep current with new releases of Windows 10. Similar to the in-place upgrade, modern servicing can address situations where you are moving from one version of Windows 10 to the next. However, modern servicing technologies are specific to Windows 10, and cannot be used with earlier versions of the operating system. Windows Update for Business (WUfB), Windows Server Update Services (WSUS), and System Center Configuration Manager (ConfigMgr) are all tools that support modern servicing.

Now that you have covered the basic deployment methods for Windows 10, let’s take a look at the different deployment formats. Windows 10 is available in two formats:

• Electronic Software Delivery (ESD) Available through Windows Update or the Windows 10 Media Creation Tool

• Windows Imaging Format (WIM) Available through traditional installation media (ISO)

There are a number of solutions available for each deployment format, with pros and cons for each. See Table 1-7 for a breakdown of these formats.

The delivery solutions noted in Table 1-7 are described as follows:

• Windows Update for Business (WUfB) WUfB is a series of new policies available to Windows 10 clients. These policies enable administrators to manage the servicing channel and deferral settings for Windows 10 feature updates and quality updates. This service delivers updates to clients through the public Windows Update network using the ESD deployment format. WUfB policies can be configured using a group policy object (GPO) or Intune MDM policy.

• Windows Server Update Services (WSUS) WSUS is an on-premises solution for organizations that need to fully manage the updates that they deploy to their clients. Administrators can synchronize with the Microsoft Update catalog and deploy approved updates for all supported versions of the Windows operating system. This includes feature updates and quality updates for Windows 10.

• System Center Configuration Manager (ConfigMgr) ConfigMgr is an on-premises device-management solution for organizations that need to fully manage the updates that they deploy to their clients. With ConfigMgr, administrators are given the option to use task sequences or software updates (WSUS). With task sequences, you have additional control over the in-place upgrade scenario.

• Microsoft Deployment Toolkit (MDT) MDT is a free deployment tool that enables administrators to support Windows 10 images and in-place upgrades. Similar to ConfigMgr, MDT uses task sequences for image creation and upgrades.

As you prepare to deploy Windows 10 using the in-place upgrade method, there are a number of items to consider. Although there are several benefits to supporting this method, each of the following issues can affect the success of your implementation.

• Compatibility You must review all hardware, drivers, and applications for Windows 10 compatibility. Older hardware, including peripherals, may not support the latest release of Windows 10 or have supported drivers, in which case they would need to be replaced or updated. Applications that are incompatible can cause the upgrade to fail and must be assessed as well. Later in this skill section, you will review Upgrade Readiness, a service provided by Microsoft to help identify compatibility issues.

• Legacy BIOS to UEFI Windows 10 supports legacy BIOS and UEFI, both of which use different partition maps on the system drive. That said, there are security features, such as Secure Boot, that require UEFI. In this case, you can complete an in-place upgrade on a device running legacy BIOS and then use the MBR2GPT tool to convert the partition map from master boot record (MBR) to GUID partition table (GPT).

  Need More Review? Running MBR2GPT

  For more information about the MBR2GPT tool, including prerequisites and instructions, visit https://docs.microsoft.com/windows/deployment/mbr-to-gpt.

• Disk encryption The Windows 10 in-place upgrade supports BitLocker natively. If the system drive is encrypted with BitLocker, the upgrade will work without any additional administrative effort. If the drive is encrypted with a third-party solution, you must contact the vendor for instructions on how to address the encryption software during the upgrade.

• Language packs The Windows 10 in-place upgrade will retain the system default user interface (UI) language. Any additional language packs that have been installed previously must be re-installed following the upgrade.

• 32-bit to 64-bit The Windows 10 in-place upgrade does not support upgrading devices from 32-bit versions of Windows to 64-bit versions. If this is a scenario you need to plan for, consider using the refresh or replace deployment method instead.

• Windows to Go Windows to Go is a feature that enables customers to boot a Windows installation from a supported USB storage device. The Windows 10 in-place upgrade is not supported on Windows to Go devices running older versions of the operating system. Once a device is running Windows 10, however, future feature updates can be installed using this method.

• Existing images If you have an existing operating system image for Windows 7 or Windows 8.1, installing that image, upgrading it to Windows 10, and recapturing it is not supported. A new operating system must be re-created for Windows 10 deployments. Alternatively, you can start using offline servicing to avoid traditional reference image designs.

  Need More Review? Windows 10 Offline Servicing

  For more information about offline servicing for Windows 10, visit https://docs.microsoft.com/windows-hardware/manufacture/desktop/understanding-servicing-strategies.

• Dual-boot The Windows 10 in-place upgrade supports devices running a single version of Windows. Devices configured in a dual-boot or multi-boot configuration are not supported.

Design an in-place upgrade for Windows 10

In this section, you take a closer look at the in-place upgrade deployment method. This is a common starting point for organizations that are planning their migration to Windows 10. In the following example, you will work with a task sequence in ConfigMgr, version 1810. In this version of ConfigMgr, a task sequence template is provided to support in-place upgrade scenarios.

To begin, you must download a copy of the Windows 10 installation media. You can retrieve this by downloading the latest Windows 10 ISO from the Microsoft volume license service center (VLSC). To access the VLSC, visit https://www.microsoft.com/Licensing/servicecenter/default.aspx. After you have downloaded Windows 10, you must extract the files from that ISO in preparation for creating the operating system upgrade package required by ConfigMgr. See Figure 1-27 for an example of the extracted files needed.

ConfigMgr requires the Windows 10 installation media in order to complete the in-place upgrade. The installation media is referenced in the task sequence as an operating system upgrade package. When this step runs, ConfigMgr executes setup.exe with a series of command-line options that instruct the setup operation on how to complete the upgrade. Setup.exe can be executed independently of ConfigMgr; it is worth reviewing the variety of supported options.

Figure 1-28 shows an example of the in-place upgrade task sequence template provided with ConfigMgr, version 1810. Each group in this task sequence template is provided to assist you with creating a working upgrade deployment. You can add, remove, or modify any of these steps to meet your requirements. Each group contains a basic description to provide additional guidance.

The groups are as follows:

• Prepare for Upgrade This group is designed for steps that will run in the current operating system. These steps should be focused on pre-upgrade operations, such as checking for 20 GB of free disk space (a requirement for setup) or ensuring that the computer is connected to a wired connection (if you do not support upgrades over wireless).

• Upgrade the Operating System This group is designed for steps that trigger the in-place upgrade. The Upgrade Operating System and Restart Computer steps are included as part of the template. The Upgrade Operating System step includes a number of options. (See Figure 1-29.) In this figure, the Perform Windows Setup Compatibility Scan Without Starting Upgrade check box is selected. This setting runs setup using the /Comapt option. The Windows setup will scan the device for possible incompatibilities. If any are found, a return code is generated with a series of logs that require further analysis.

  

• Post-Processing This group is designed for steps that need to run after the upgrade has completed successfully. This group will run if the task sequence variable _SMSTSSetupRollback equals false. Possible steps might include installing applications, resuming disk encryption, and running custom configuration changes for your organization.

• Rollback This group is designed for steps that need to run after an upgrade has failed and triggered a rollback. This group will run if the task sequence variable _SMSTSSetupRollback equals true. Possible steps might include sending an email notification to the device owner that the upgrade was unsuccessful and automatically creating an incident in your service desk system.

• Run Actions on Failure Similar to the rollback group, this group is designed for steps that need to run after an upgrade has failed. This group will run if the task sequence variable _SMSTSOSUpgradeActionReturnCode does not equal 0. Possible steps might include running a log collector or diagnostic tool such as SetupDiag.

After you have configured this task sequence to meet your needs, you can use the deployment ring strategy discussed earlier in this chapter. In ConfigMgr, this can be done using a series of device collections (groups of devices) followed by a phase deployment (a multi-phase deployment based on success criteria). For the exam, you will want to be familiar with the in-place upgrade task sequence and what its capabilities are compared to other deployment methods.

Design a servicing plan for Windows 10

This section looks at the modern servicing deployment method. This method delivers new feature updates to existing devices that already have Windows 10 installed. With modern servicing, feature updates are installed in much the same way as they are with the more traditional Windows Update. In the following examples, you will review three techniques for enabling modern servicing.

Use Modern servicing with Microsoft Intune

The first solution you will look at involves the Windows 10 update rings in Microsoft Intune. This solution requires target devices to be enrolled in Intune. Once enrolled, devices that have this policy assigned will be configured to use Windows Update for Business. Follow these steps to create an update ring policy in Microsoft Intune.

1. Log in to the Microsoft Endpoint Manager admin center at https://endpoint.microsoft.com/.

2. Click Devices.

3. Click Windows 10 Update Rings.

4. On the Windows 10 Update Rings page, click Create Profile.

Figure 1-30 shows the Update Ring Settings tab, which shows the update ring settings available through this policy.

The update ring settings are split into two sections: Update Settings and User Experience Settings. In the Update Settings section are two controls that are used to manage the deployment of feature updates. These include the following:

• Servicing Channel This drop-down list includes each of the servicing channels you reviewed in Skill 4.1. Use this option to set up deployment rings for Windows Insider for Business or to configure deployments of public releases when they reach the semi-annual channel.

• Feature Update Deferral Period (Days) This feature enables you to defer an update for as long as 365 days. It is designed to give you an additional grace period to accommodate your deployment workflow.

After configuring and assigning this policy, you have the option to pause the assignment for as many as 35 days in case you need to halt all upgrades to troubleshoot an issue. You can set this option in the Software Updates – Windows 10 Update Rings blade, which you access by selecting the policy and clicking Pause on its Overview page. When you are ready to resume the assignment, you can do so from the same blade; otherwise, the assignment will automatically resume after 35 days.

Use Modern servicing with Group Policy

The next solution you will review involves configuring WUfB using the group policy. These group policy settings are identical to the ones in Intune, so this will be a brief example. The major difference with group policy is how the various settings are split into individual policies. For instance, the settings for user experience are broken down between multiple policies. In the following example, you will configure a new GPO for WUfB using the latest ADMX templates provided with Windows 10, version 1809.

1. Open the Group Policy Management Editor.

2. Create a new GPO and name it WUfB.

3. Right-click the new GPO and click Edit.

4. Under Computer Configuration, expand Policies.

5. Expand Administrative Templates.

6. Expand Windows Components.

7. Expand Windows Update.

8. Expand Windows Update for Business.

9. Locate and edit the Select When Preview Builds and Feature Updates Are Received policy.

10. Select the Enabled option and configure the following options (see Figure 1-31). Then click OK.

    • Select the Windows Readiness Level for the Updates You Want to Receive Semi-Annual Channel

    • After a Preview Build or Feature Update Is Released, Defer Receiving It for This Many Days 0

    • Pause Preview Builds or Feature Updates Starting Leave this value blank

Modern servicing with ConfigMgr

The last solution you will review is the Window 10 servicing feature in ConfigMgr. This deployment method is ideal for organizations that have chosen the ESD update format but still want to manage update deployments through ConfigMgr.

Windows 10 servicing uses ConfigMgr’s Software Update feature. This feature employs WSUS to synchronize updates from the Microsoft Update catalog. Those updates can then be managed and deployed by ConfigMgr. The Windows 10 Servicing feature leverages these capabilities.

The creation wizard will walk you through creating a servicing plan, setting up deployment rings, and creating the deployment. In this example, you will create a servicing plan in ConfigMgr, version 1810.

1. Click Start, search for Configuration Manager Console, and select it.

2. In the Configuration Manager Console, click the Software Library workspace.

3. In the Overview page, expand Windows 10 Servicing, and select Servicing Plans.

4. In the ribbon, click Create Servicing Plan.

   Figure 1-32 shows an example of a Windows 10 servicing plan created in ConfigMgr. The summary page outlines the configuration options for each of the various controls available on each page in the creation wizard. The pages are as follows:

   • General Assign a name and description for the servicing plan.

   • Servicing Plan Select the device collection that will receive the deployment generated by this servicing plan.

   • Deployment Ring Select a servicing channel and delay deployment up to 120 days. Note that your only options for servicing channels are Semi-Annual Channel (Targeted) and Semi-Annual Channel. You do not have options for Windows Insider builds.

   • Upgrades Define the criteria for the updates you are deploying with this servicing plan. For example, if you are creating a servicing plan for just 64-bit devices, you can configure the architecture attribute to only retrieve 64-bit updates.

   • Deployment Schedule Define when the update will become available and when it will be enforced.

   • User Experience Configure what notifications are displayed to the user and how reboot behavior will be handled. If you are using maintenance windows in ConfigMgr, you can configure whether they are acknowledged for this deployment.

   • Package Assign a deployment package or configure the servicing plan to use the Microsoft cloud, reducing the need to download and replicate content internally.

Analyze upgrade readiness for Windows 10

Earlier in this chapter, you explored some of the requirements that you must consider before deploying Windows 10. Most customers preparing to deploy a new operating system are going to perform extensive testing and validation of their hardware, drivers, and applications before they start large-scale deployments. This process can be time-consuming — even more so when that operating system is undergoing major changes every six months.

Upgrade readiness is a service provided by Microsoft to help customers identify compatibility concerns in support of WaaS. Customers that choose to enroll in this service can get metrics and visual indicators on which components need the most attention and which devices are ready to upgrade. This is made possible using Windows telemetry and the Microsoft cloud.

Plan for upgrade readiness

To prepare for upgrade readiness, you must be familiar with the requirements for Windows Analytics. To begin, let’s cover the fundamentals of upgrade readiness and items that you should be familiar with:

• Telemetry The upgrade readiness service requires that you set the Windows telemetry level to basic (minimum) for any devices that you enroll in the service.

• Operating system support Upgrade readiness supports devices running Windows 7 SP1, Windows 8.1, or Windows 10. For Windows 7 SP1, you must install KB2952664. For Windows 8.1, you must install KB2976978.

• Target operating system Upgrade readiness can provide you with compatibility information for one operating system version at a time. For example, in Figure 1-33, you can see the Target Version to be Evaluated drop-down menu. This option is configured as part of the solution settings in Azure. The operating system version you select will be used for data analysis. When a new Windows 10 feature update is released, you must update this field to the new build number. A change to the target version can take up to 24 hours to apply.

  

• Data availability After a device is configured to upload telemetry and associate it with a commercial ID, it can take up to 72 hours for that data to become visible in upgrade readiness. After that, you can expect to see updates every 24 hours. For example, if a device has an incompatible application and you update that application, the change will be reflected within 24 hours.

• Cost The upgrade readiness service is offered free of cost. This free offering provides seven days of historical data and up to 500 MB of storage. If your organization decides it needs to retain 90 days of historical data, you must procure Azure storage to accommodate this requirement.

Navigate upgrade readiness

After you have set up your devices to upload telemetry to Microsoft with your organization’s commercial ID, the results will be shown in the Log Analytics service in the Azure portal. From there, you can begin navigating through the different blades and assessing your organization’s upgrade readiness.

The following steps will introduce you to the upgrade readiness solution in the Azure portal. For this demonstration, we have already created a Log Analytics workspace for Contoso Electronics, named -Analytics. The devices in this organization are also configured for upgrade readiness. You will look at the Contoso Electronics environment to determine whether the organization is ready to adopt Windows 10. To access the upgrade readiness solution, follow these steps.

1. Log in to the Microsoft Azure portal at https://portal.azure.com/.

2. Click All Services.

3. Search for Log Analytics and select it.

4. On the Log Analytics blade, select the workspace containing your upgrade readiness solution — in this example, -Analytics.

5. On the -Analytics blade, under General, select Solutions.

6. On the -Analytics – Solutions blade, select the solution starting with CompatibilityAssessment — in this example, CompatibilityAssessment(-Analytics).

7. On the CompatibilityAssessment(-Analytics) blade, click the Upgrade Readiness tile.

   The Upgrade Readiness Workflow page opens. It consists of multiple blades with data related to Windows 10 compatibility.

The next blade you are presented with relative to upgrade readiness is STEP 1: Identify Important Apps. (See Figure 1-34.) This blade is designed to highlight applications in your environment that may need attention before deploying Windows 10. The first number on this blade, labeled Total Applications, indicates the total number of applications identified in your organization. The second number, labeled Applications in Need of Review, indicates the number of applications for which Microsoft does not have compatibility information and which it recommends that you review. You can click either of these values to drill down into the various data categories.

Applications are automatically grouped based on importance. For example, applications that are installed on less than 2% of devices are grouped together. You also have the option to assign or modify the importance level with a selection of built-in options. You accomplish this by clicking the Assign Importance link at the bottom of the blade. Defining the importance level will assist in organizing your application portfolio and defining which applications are upgrade ready. Importance levels include the following:

• Not reviewed This is the default importance level for applications that are installed on more than 2% of devices. To clearly understand which apps are important, you can modify this default value to something with additional meaning.

• Mission critical This is an optional importance level, signifying a mission-critical dependency on the application.

• Business critical This is an optional importance level, signifying a business-critical dependency on the application.

• Important This is an optional importance level, signifying the application is important to the organization.

• Best effort This is an optional importance level, signifying the application is not important and compatibility will be approached as a best effort.

• Ignore This is an optional importance level, signifying the application is not important and can be safely ignored from future compatibility reports. Selecting this option will mark the application as upgrade ready, removing it as a blocker.

• Review in progress This is an optional importance level, signifying the application is currently under review and the importance level has not yet been identified.

The next blade you are presented with is STEP 2: Resolve Issues. This step in the workflow includes a series of blades for addressing issues that are considered to be upgrade blockers. See the following list for more information about each of the blades in step 2.

• Review Applications with Known Issues This blade highlights applications with known issues. Applications that Microsoft has a fix for will be marked accordingly, reducing the number of applications that you must review. As you review these apps, you have the option to adjust the upgrade readiness value, approving or blocking applications from the upgrade. These values include:

  • Not Reviewed This is the default value for applications that are installed on more than 2% of devices and all drivers.

  • Review in Progress Assigning this value to an application or driver will prevent it from being approved until it can be marked as ready to upgrade. This should be used for any applications or drivers that you still need to validate.

  • Ready to Upgrade Assigning this value to an application or driver will mark it as upgrade ready.

  • Won’t Upgrade Assigning this value to an application or driver will mark all corresponding devices as not upgrade ready.

  • Review Known Driver Issues This blade highlights drivers with known issues. Drivers that Microsoft has information on will be marked accordingly. For example, if newer versions of various drivers are available through Windows Update, those drivers will be grouped together. Similar to the previous application blades, you can define the same upgrade readiness values to approve or deny drivers.

  • Review Low-Risk Apps and Drivers This blade highlights applications and drivers that need review but are determined to be low risk based on various conditions. For example, if Microsoft has identified an application as highly adopted (installed on more than 100,000 devices), that application will be marked as low risk.

  • Prioritize App and Driver Testing This blade highlights applications and drivers that are currently blocking the upgrade for your target operating system on more than 80% of devices. Reviewing and prioritizing these items can yield a high return for upgrade readiness.

The next blade you are presented with is STEP 3: Deploy (see Figure 1-35). This step in the workflow consolidates all information that has been collected and categorizes devices based on upgrade readiness. There are three upgrade options on this blade:

• Review in Progress Devices in this category have at least one application or driver installed that has been marked as review in progress. These markings are applied in step 1 and step 2 of the workflow.

• Won’t Upgrade Devices in this category have at least one application or driver installed that has been marked as won’t upgrade. Alternatively, these devices do not meet a system requirement to complete the upgrade, such as free disk space.

• Ready to Upgrade Devices in this category have all applications and drivers marked as ready to upgrade. When you are ready to deploy the upgrade to these devices, export the list of computers and target them with your preferred management solution.

The next blade you are presented with is STEP 4: Monitor. This step in the workflow includes a series of blades for monitoring the progress of your upgrade deployments. See the following list for more information about each of the blades in step 4.

• Update Progress (Last 30 Days) This blade highlights the deployment status for all your devices. There are five deployment categories that group devices.

  • Not Started Devices that have not started the upgrade. This includes devices that are upgrade ready and those that are not.

  • Upgrade completed Devices that have successfully completed the upgrade to your target operating system.

  • Failed Devices that attempted to upgrade to your target operating system but were unsuccessful.

  • In Progress Devices that have started the upgrade to your target operating system and have not yet reported back their results.

  • Progress stalled Devices that have started the upgrade and stalled.

• Driver issues Drivers that are reporting issues following a successful upgrade. This information includes the problem code reported in device manager for the affected device(s).

• User feedback User feedback submitted through the Feedback Hub app. Users that have submitted feedback using their Azure AD account will be consolidated and displayed here for review.

Create deployment profiles

Deployment profiles customize the provisioning experience and preconfigured settings to simplify enrollment for end-users. To configure a deployment profile, follow these steps.

1. Sign in to the Microsoft Endpoint Manager admin center at https://endpoint.microsoft.com.

2. Click Devices, and then click Enroll Devices.

3. Click Windows Enrollment, and then click Deployment Profiles.

4. Click Create Profile, and then click Windows PC.

5. On the Basics tab, enter a name for the profile — for example, AutopilotProfile1.

6. On the Out-of-Box Experience (OOBE) tab, enter the following settings (see Figure 1-37), and then click Next.

   • Deployment Mode User-Driven

   • Join to Azure AD As Azure AD Joined

   • Microsoft Software License Terms Hide

   • Privacy Settings Hide

   • Hide Change Account Options Hide

   • User Account Type Administrator

   • Allow White Globe OOBE Yes

   • Language (Region) Operating System Default

   • Automatically Configure Keyboard Yes

   • Apply Device Name Template Yes

   • Name %SERIAL%

     

7. On the Assignments tab, select the groups to add or exclude from being applied — for example, All Devices. Then click Next.

8. On the Review + Create tab, click Create.

Set device enrollment restrictions

This section covers the controls given to administrators to limit the number and type of devices a user can enroll. Limiting the number of devices assigned to a user can help with license constraints and organization. In addition, restricting devices that are running an older operating system is a requirement for many organizations due to security and compliance concerns. Finally, blocking personally owned devices may be a scenario you need to consider if your organization is not ready to support a bring your own device (BYOD) model. Table 1-9 explains the various enrollment restriction options.

Device Type Restrictions

The second enrollment restriction you will work with limits enrollment by the type of device:

1. Sign in to the Microsoft Endpoint Manager admin center at https://endpoint.microsoft.com.

2. Click Devices, and then click Enroll Devices.

3. Click Enrollment Restrictions

4. Click Create Restriction, and then click Device Type Restriction.

5. On the Basics tab, provide a name for the restriction — for example, Custom Type Restriction.

6. On the Platform Settings tab, select the desired combination of settings to allow or restrict devices by platform, version, whether they are personally owned, or device manufacturer. Figure 1-39 shows a configuration that blocks Android devices. Then click Next.

   

7. On the Scope Tags tab, specify a scope if required for the deployment, and click Next.

8. On the Assignments tab, specify the groups that the enrollment restriction should apply to, and click Next.

9. On the Review + Create tab, click Create.

With these steps complete, you should have a custom device type restriction available on the Enrollment Restrictions blade. In this example, you worked with platform restrictions. Platform restrictions provide a granular set of controls for approving specific device types and operating system versions. With an enrollment plan that supports BYOD, controlling the minimum and maximum operating system version can prevent known vulnerabilities or pre-release versions from entering your environment. Figure 1-40 shows the configured device type and limit restrictions.