Easily controlling the Office update channel by using administrative templates

Let’s start this new year about a specific use case for the recently introduced feature to configure administrative template settings via Microsoft Intune. That specific use case is to easily control and configure the Office update channel by using the Administrative Templates profile type within Microsoft Intune. Before, this configuration would require ingesting a custom ADMX and creating custom OMA-URI settings, for configuring the Office channel, based on the information in the ingested custom ADMX. That’s not necessary anymore, as Microsoft Intune now provides a built-in list of available administrative template policy settings. In this post I’ll show the configuration steps, followed by the configuration results on a Windows 10 device.

Configuration

Before looking at the actual configuration steps, it might be good to first refresh memories by looking at the naming of the update channels in the different locations. The following table shows the naming of the different channels in Microsoft Intune (and the Office apps) and in the actual ADMX. Good news! This is actually the last time that it’s really required to look at this information. As this post will show, it wasn’t even necessary for the configuration in this post. It will be useful for verifying the results. Microsoft Intune will now provide an easy method for configuring many ADMX-backed settings, without going through the actual ADMX anymore.

Azure portal ADMX setting
Monthly Channel FirstReleaseCurrent
Monthly Channel (Targeted) Current
Semi-Annual Channel Deferred
Semi-Annual Channel (Targeted) FirstReleaseDeferred
Insider Fast InsiderFast

When this would be a configuration of an ADMX-backed settings, the information in the table above would be really relevant during the configuration. Since recently Microsoft Intune contains a new profile type, named Administrative Templates. These profiles take care of the heavy work. In case of Office settings, which will be used in this post, these profiles even take care of ingesting the correct ADMX-files. The following six steps walk through the creation of an Administrative Templates profile type that will be used to configure the Office update channel. After the creation of the policies it can be assigned to a user and/or device group.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, select Create profile to open the Create profile blade;
3

OfficeUpdates-CreateProfileOn the Create profile blade, provide the following information and click Create to open the <Name> blade;

  • Name: Provide a unique name for the device configuration profile;
  • Description: (Optional) Provide a description for the device configuration profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Administrative Templates (Preview);
4 On the <Name> blade, select Settings to open the <Name> – Settings blade;
5 On the <Name> – Settings blade, type Updates in the Search to filter items… field to filter the available settings to only update related settings and select Update Channel (as shown below) to open the Update Channel blade.
OfficeUpdates-Settings
6

OfficeUpdates-UpdateChannelOn the Update Channel blade, select Enabled to enable the setting, select the required update channel with Channel Name and click OK.

Note: Keep in mind that enabling a setting and clicking OK will directly save the change to the created device configuration profile. This is a similar experience to how changes are managed when working with normal group policies.

Note: In my device configuration profile I’ve also configured Enable Automatic Updates and Hide option to enable or disable updates to make sure that Office automatically checks for updates without an option for the user to disable Office updates.

Result

Now it’s really interesting to look at the result of the created configuration. For that, let’s first have a look at the registry. Below on the left is an overview of the registry key of the policy manager that contains the created Office configuration. It clearly shows the settings that should be configured, including the update branch. The update branch contains the ADMX-setting value of Current, which was shown in table above, and matches my configured value, in Microsoft Intune, of Monthly Channel. Below on the right is an overview of the registry key of the policy manager that contains the ingested Office ADMX.

OfficeUpdates-Registry01 OfficeUpdates-Registry02

Another interesting location is the standard location in the registry that contains policy settings. Below on the left is an overview of the configured update branch. The update branch also contains the ADMX-setting value of Current, which was shown in table above, and matches my configured value, in Microsoft Intune, of Monthly Channel. Below on the right is the actual configuration of an Office app shown. That clearly shows the Monthly Channel configuration.

OfficeUpdates-Registry03 OfficeUpdates-Outlook01

Conditional access and legacy authentication

This week is still all about conditional access. More specifically, the recently introduced feature to create conditions based on the use of legacy authentication (including older Office versions), which is currently still in preview. By now, I’ve done my fair share of posts regarding blocking legacy authentication (see for example here and here), but now it’s literally getting super easy. And no need for AD FS anymore. This helps with easily closing another backdoor, as previously legacy authentication simply bypassed any conditional access policy. In this post I’ll walk through the required configurations followed by the end-user experience.

Configuration

Before going through the configuration let’s start with a quick reminder about legacy authentication. Very simplistically said, legacy authentication is basic authentication that uses a single authentication factor in the form of a username and password and cannot force a second authentication factor (think about protocols like, POP3, IMAP, SMTP, MAPI and EWS and apps like, Office 2010). As I have no need for legacy authentication in my environment, I will block all legacy authentication to my apps. The following seven steps walk through the simple configuration to create a conditional access policy that blocks the access to all cloud apps for all users when using legacy clients.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups02On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps02On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5 AAD_CA_ClientApps02On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps (preview) to open the Client apps (preview) blade. On the Client apps (preview) blade, click Yes with Configure, select Mobile apps and desktop clients > Other clients and click Done and Done;
6

AAD_CA_Grant02On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select.

Note: Make sure that there are no apps within the environment that still need basic authentication, as this configuration will block all of it.

7 Open the New blade, select On with Enable policy and click Create;

Note: It can take up to 24 hours for the policy to take effect.

End-user experience

One of the best use cases is an old Office version. Office 2010 and the default configuration of Office 2013, both use basic authentication. Office 2016 and later use modern authentication by default. Due to the way basic authentication works the end-user experience is not pretty and will not be pretty. Below is an example of the end-user experience when using Outlook 2010 for connection to Exchange Online. As mentioned, it’s effective and not pretty.

BlockOutlook

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Client apps.

Conditional access and device state

This week back in conditional access again. More specifically, the recently introduced feature to exclude devices based on the device state, which is currently still in preview. This enables organizations to exclude managed devices (Hybrid Azure AD joined and/ or compliant) from a conditional access policy. That means that the conditional access policy will only be applicable to unmanaged devices. This enables new scenarios and makes existing scenarios easier. Think about using session controls to enable a limited experience within cloud apps, for unmanaged devices only. In this post I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

The configurations that make the most sense for using the device state are related to the access controls. At least, in my opinion. All other scenario’s can also be created by using the already available options. It just makes it a bit easier. By looking at the access controls, the session related controls are the most obvious configuration to start with. The Use app enforced restrictions session control enables organizations to enable a limited experience within a cloud app, for, in this case, unmanaged devices and the Use proxy enforced restrictions session control enables organizations to sent the user sign-in information to Microsoft Cloud App Security, also for, in this case, unmanaged devices. That enables additional actions based on the users sign-in activity. The following seven steps walk through the simple configuration to create a conditional access policy that uses the proxy enforced restriction session control.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups01On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps01On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5

AAD_CA_DeviceState01On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device state (preview) to open the Device state (preview) blade. On the Device state (preview) blade, click Yes with Configure, click Exclude, select Device Hybrid Azure AD joined and Device marked as compliant and click Done and Done;

Note: Think about the easier scenarios that can be created by using the option to exclude domain joined devices from the conditional access policy.

6

AAD_CA_Session01On the New blade, select the Session access control to open the Session blade. On the Session blade, select Use proxy enforced restrictions (preview) and click Select.

Note: Optionally configure additional a Cloud App Security Access policy or Cloud App Security Session policy to enable additional behavior based on the sign-in information of the user. For example, block the sign-in for a specific cloud app.

7 Open the New blade, select On with Enable policy and click Create;

Note: Basically the Azure AD conditional access policy and the Conditional Access App Control access or session policy will work together to perform real-time monitoring and control.

End-user experience

Let’s end this post with the end-user experience, followed with the administrator experience. As I only have connectors for Office 365 and Microsoft Azure in my Cloud App Security, I can only create access policies for the connected apps. These access policies can be used to simply monitor the activity or to actually block the session and display a custom block message. Besides that, the policy can also create alerts. In the dashboard, via email and via text message.

I created a policy that would block the session of the end-user with a custom message as shown below. Yes, I could have blocked the session already with conditional access itself, but this provides me with some more information about the sign-in.

CloudAppSecurity_Blocked01

When I’m now looking in the Cloud App Security dashboard, I can already see the alerts. When I navigate to either Investigate > Activity log or Alerts, I can look at the information as shown below. That provides me with the source, which, in this case. is Azure AD conditional access, the matched policy and information about the user and the device (as shown below). Pretty nice.

AppDashboard01

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Device state.

Conditional access and guest users

This week back in conditional access. More specifically, the recently introduced feature to assign a conditional access policy to All guest users, which is currently still in preview. At the same time also the ability to assign to Directory roles was introduced. The idea for both is the same. The first is to specifically assign to guest users and the second is to assign to specific roles in the directory. This post will focus on the first scenario. I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

Microsoft Teams is getting really hot for collaboration. This also creates a very low bar for inviting external parties (B2B) to collaborate with. Working together. Of course this should be facilitated to enable the productivity of the end-user. However, that doesn’t mean that there shouldn’t be additional security in-place. Even if it’s just to ensure the identity of the guest user. For example, enable multi-factor authentication for guest users. The following steps walk through the simple configuration to enable multi-factor authentication for guest users on Microsoft Teams.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroupOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select Select users and groups > All guest users (preview) and click Done;
4 AAD_CA_CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps > Microsoft Teams and click Done;
5

AAD_CA_GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access > Require multi-factor authentication and click Select.

6 Open the New blade, select On with Enable policy and click Create;

Note: Guest user matches any user account with the userType attribute set to guest.

End-user experience

Now let’s end this post by looking at the end-user experience. Once the (external) user is invited for using Microsoft Teams, it will first have to configure MFA (see screenshot on the left). After that the user will be able to access Microsoft Teams by using its favorite MFA option. In my example I picked the Microsoft Authenticator app, as it will clearly show that an external account was used (see screenshot on the right). It clearly shows #EXT and onmicrosoft.com.

Screenshot_MFA Screenshot_Authenticator

More information

For more information about conditional access and assignments, please refer to this article about Conditions in Azure Active Directory conditional access | Users and groups.

Join me at the Tech Summit in Amsterdam

Next week, March 28-29, the Microsoft Tech Summit will be in Amsterdam and I will be there. On Wednesday (March 28) I will be available at the Ask the Experts Reception and on Thursday (March 29) I will be speaking about Manage Windows AutoPilot via Microsoft Intune. I hope I will see you there!

pvanderwoude

About my session

In this session, I will pull you into the world of Windows AutoPilot. Learn what Windows AutoPilot is and also, learn what Windows AutoPilot is not. In this demo-rich session I will show you how to use Windows AutoPilot, together with Microsoft Intune, to simplify device provisioning.

Super easy Office 365 ProPlus deployment via Windows 10 MDM

This week a blog post about a very nice new app type in Microsoft Intune standalone. The Office 365 Pro Plus Suite (Windows 10) app type. This app type makes it very easy to assign Office 365 ProPlus apps to managed Windows 10 by utilizing the Office CSP. Additionally, it also allows the installation of the Microsoft Project Online desktop client, and Microsoft Visio Pro for Office 365. I know, I’m not the first to write about this app type, nor will I be the last, but this app type needs all the attention it can get. It’s that nice. I’ll start this post with some prerequisites and important information, followed by the configuration. I’ll end this post with the administrator experience.

Good to know

Before starting with the configuration of the new app type, it’s good to know the following current limitations and requirements.

  • Devices must be running Windows 10, version 1703 or later. That version introduced the Office CSP;
  • Microsoft Intune only supports adding Office apps from the Office 365 ProPlus 2016 suite;
  • If any Office apps are open when Microsoft Intune installs the app suite, end-users might lose data from unsaved files. At this moment the end-user experience is not that pretty;
  • When the Office apps are installed on a device that already has Office installed, make sure to be aware of the following:
    • It’s not possible to install the 32-bit and the 64-bit Office apps on the same device;
    • It’s not possible to install the same version of the Click-to-run, and MSI versions of Office on the same device;
    • When an earlier version of Office is installed, using Click-to-Run, remove any apps that must be replaced with the newer version;
    • When a device already has Office 365 installed, assigning the Office 365 ProPlus 2016 suite to the device might mean that the Office subscription level must be changed.

Configuration

After being familiar with the current limitations and requirements, let’s continue with the configuration. The 10 steps below walk through the configuration of the Office 365 Pro Plus Suite (Windows 10) app type. After creating the app type, assign the app like any other app. Keep in mind that at this moment the app can only be assigned as Required, Not applicable or Uninstall. Available is currently not an option.

1 Open the Azure portal and navigate to Intune > Mobile apps > Apps;
2 Select Add to open the Add app blade;
3 AA_AppTypeOn the Add app blade, select Office 365 Pro Plus Suite (Windows 10) as App type to add the Configure App Suite, the App Suite Information and the App Suite Settings sections;
4 On the Add app blade, select Configure App Suite to open the Configure App Suite blade;
5 AA_ConfigureAppSuiteOn the Configure App Suite blade, select the Office 365 apps that must be installed and click OK to return to the Add app blade;
6 Back on the Add app blade, select App Suite Information to open the App Suite Information blade;
7

AA_AppSuiteInformationOn the App Suite Information blade, provide the following information and click OK to return to the Add app blade;

  • Suite Name: Provide a unique name for the app suite;
  • Suite Description: Provide a description for the app suite;
  • Publisher: Provide the publisher of the app;
  • Category: (Optional) Select a category for the app suite;
  • Display this as a featured app in the Company Portal: Select Yes or No. At this moment the app suite can only be deployed as  required, which means that there are not many reasons to select yes;
  • Information URL: (Optional) Provide the URL that contains more information about the app;
  • Privacy URL: (Optional) Provide the URL that contains privacy information about the app;
  • Developer: (Optional) Provide the developer of the app;
  • Owner: (Optional) Provide the owner of the app;
  • Notes: (Optional) Provide additional notes about this app;
  • Logo: (Optional) Select an image.
8 Back on the Add app blade, select App Suite Settings to open the App Suite Settings blade;
9

AA_AppSuiteSettingsOn the Add Suite Settings blade, provide the following information and click OK to return to the Add app blade;

  • Office version: Select the version of Office that should be installed, 32-bit or 64-bit;
  • Update channel: Select how Office is updated on the devices, current, deferred, first release current or first release deferred;
  • Automatically accept the app end user license agreement: Select Yes or No;
  • Use shared computer activation: Select Yes or No;
  • Languages: Select additional languages that should be install with the app suite. By default Office automatically installs any supported languages that are installed with Windows on the end-user device.
10 Back on the Add app blade, click Add;

Note: After adding the app suite it cannot be edited anymore. To make adjustments, delete the app suite and create a new. That makes it important to think about the configuration before creating one.

Administrator experience

Usually I’ll end this type of posts with the end-user experience, but in this scenario there is not much to see. I can show something like the running installation process or the installed products, but that’s not that exciting as it’s simply there. Having said that, from an administrator perspective there are some interesting things to look at. Let’s start with the most interesting one, which is actually available on the end-user device, the Office CSP key in the registry. This key can be found at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OfficeCSP and is shown below.

Reg_OfficeCSP

Within this registry entry, it actually shows the content of the configuration XML in the default of the key. This enables me to have a look at the default values used during the installation of the Office apps. Besides the values configured in the app type. Below is the configuration XML that belongs to my installation. It basically shows 3 options that are not configurable, ForceUpgrade, Product ID and Display Level. Knowing these values should help with explaining the installation behavior.

<Configuration>
     <Add Channel=”FirstReleaseCurrent” ForceUpgrade=”TRUE” OfficeClientEdition=”32″>
         <Product ID=”O365ProPlusRetail”>
             <ExcludeApp ID=”Access” />
             <ExcludeApp ID=”Groove” />
             <ExcludeApp ID=”InfoPath” />
             <ExcludeApp ID=”Publisher” />
             <ExcludeApp ID=”SharePointDesigner” />
             <Language ID=”nl-nl” />
             <Language ID=”en-us” />
         </Product>
     </Add>
     <Display Level=”None” AcceptEULA=”TRUE” />
     <Property Name=”SharedComputerLicensing” Value=”0″ />
</Configuration>

Also interesting to look at, from an administrator perspective, is the installation status in the Azure portal. Simply navigating to Intune > Mobile apps > Apps install status and selecting the assigned app, will provide an overview as shown below.

InstallStatus

More information

For more information about the Office CSP and using Microsoft Intune to deploy Office 365 ProPlus, please refer to the following articles: