Terms and conditions

This week I’m back in ConfigMgr and I’m back with custom Terms and Conditions. A few months ago I did my latest post about custom Terms and Conditions. That post was completely focused on Microsoft Intune standalone. Starting with ConfigMgr 1511 it’s now also possible to deploy custom Terms and Conditions through Microsoft Intune hybrid.

Custom Terms and Conditions can be deployed to end-users to explain how device enrollment, access to work resources, and using the Company Portal affects them and their devices. End-users must accept the custom Terms and Conditions before they can use the Company Portal to enroll and access their company data.

In this post I’ll show how to create, deploy, update and monitor custom Terms and Conditions in Microsoft Intune hybrid. I’ll also briefly show the end-users experience. Keep in mind that custom Terms and Conditions are deployed to users and that users only need to accept the Terms and Conditions once, unless specifically configured in an updated version of the custom Terms and Conditions.

Configuration

Now let’s start with the configuration of custom Terms and Conditions. I’ll first go through the configuration steps to create custom Terms and Conditions, followed by the configuration steps to deploy custom Terms and Conditions and I’ll finish with the configuration steps to update the custom Terms and Conditions.

Create Terms and Conditions

The first configuration activity is creating the custom Terms and Conditions. This configuration activity can be performed by simply going through the following six steps.

Select the new custom Terms and Conditions and in the Home tab click Deploy to open the Deploy Terms and Conditions dialog box;

3

In the Deploy Terms and Conditions dialog box, specify the following information and click OK;

Name: [Grayed out]

Collection: [Select to the collection containing the required users]

Update Terms and Conditions

The last configuration activity is updating the custom Terms and Conditions. This is an optional activity that is only required when an update to an existing custom Terms and Conditions is required. This configuration activity can be performed by simply going through the following three steps.

Select the new custom Terms and Conditions and in the Home tab click Properties to open the Terms and Conditions Properties dialog box;

3

In the General tab and Terms tab, make the required updates, choose between the following options on the Terms tab and click OK;

Increase the version number, and require all users to accept the updated terms the next time they open the Company Portal: [Select this option when significant changes are made to the custom Terms and Conditions];

Keep the current version number, and require only new users to accept the updated terms: [Select this option when typos, or formats are fixed in the custom Terms and Conditions].

End-user experience

Before I’ll go to the reporting capabilities, for the custom Terms and Conditions, I think it’s important to first show the end-user experience. Depending on the number of targeted custom Terms and Conditions, the end-users can experience the behavior as shown below.

Single custom Terms and Conditions

Multiple custom Terms and Conditions

Reporting

Let’s finish this post with the reporting abilities of custom Terms and Conditions. Out-of-the-box there is one report available, named Terms and Conditions acceptance, that shows which user accepted which version of which custom Terms and Conditions. That report is available in the category Compliance and Settings Management and only shows the information about end-users that accepted the custom Terms and Conditions.

Filters

Report

This report can use the following filters:

Terms and Conditions: [Select a specific Terms and Conditions to display];

And we’re back in the Company Portal app. Not just because I think that the Company Portal app is awesome, but also because there’s a new Company Portal app related capability added, during the August 2015 update, to Microsoft Intune. That new capability is that it’s now possible to deploy multiple custom Terms and Conditions for enrollment and company access. A while ago I did a blog post about Custom terms and conditions for using the Company Portal of Microsoft Intune and this post will be an updated version of that post. However, this post will not go into as much detail about the use of different versions, of a single custom Terms and Conditions, as that part is still applicable in the same manner.

In this blog post I’ll show that the capability to create custom Terms and Conditions has been relocated to the Policy node in the Microsoft Intune administration console and that it now also can be configured like a policy. That means it’s possible to create multiple Terms and Conditions and that’s possible to deploy multiple Terms and Conditions. This can be very useful when it’s required to make the Terms and Conditions available in different languages, or when different custom Terms and Conditions are required for different parts of the company.

One important thing that’s still the same, is the fact that Terms and Conditions are deployed to users and that users only needs to accept the Terms and Conditions once.

Configuration

Now let’s start with looking at the new way to configure custom Terms and Conditions. First I’ll go through the steps to create and deploy custom Terms and Conditions and than I’ll continue with showing the end-user experience of that configuration and deployment.

Create a new policy

To create a new policy, perform the three steps mentioned below. For every additional custom Terms and Conditions the same three steps apply.

On the Create Terms and Conditions page, provide the following information and click Save:

Name: <Provide a name for the policy>;

Description: <Provide a description for the policy>;

Title: <Provide a title for the custom terms and conditions>;

Text for terms: <Provide a text for the custom terms and conditions>;

Text to explain what it means if the user accepts: <Provide a text describing what it means when the user accepts the custom terms and conditions>.

A good thing to keep in mind is that with editing the created policy an additional option of Decide whether to require users to re-accept updated terms will show. This option can be used to increase the version number, or to keep the current version number. Increasing the version number will require all users to accept the updated terms and keeping the version number will required only new users to accept the updated terms.

Deploy the new policy

To deploy the new policy, perform the four steps mentioned below. For every additional custom Terms and Conditions the same three steps apply.

A good thing to keep in mind with deploying multiple custom Terms and Conditions is their behavior when multiple custom Terms and Conditions are deployed to the same user. I’ll show that behavior during the end-user experience, but it’s good to note that it will simply merge the multiple custom Terms and Conditions in to one.

End-user experience

To test the end-user experience, I’ve created two custom Terms and Conditions. I’ve deployed these to two different groups and that actually gave me expected behavior. The first custom Terms and Conditions is created in English and deployed to a group with my English end-users. That makes that all my English end-users experiencing the behavior as shown in the Windows Phone 8.1 device below.

Configuration

Windows Phone 8.1 Example

The second custom Terms and Conditions is basically the same. The only difference is that it’s created in Dutch and deployed to a group with my Dutch end-users. That makes that all my Dutch end-user are experiencing the behavior as shown in the Windows Phone 8.1 device below.

Configuration

Windows Phone 8.1 Example

Now that I’ve created multiple custom Terms and Conditions it’s time to see the end-user experience when the end-user is either in both groups, or when both configurations are targeted to the same group. These end-users will experience the behavior as shown in the Windows Phone 8.1 device below.

Configuration

Windows Phone 8.1 Example

In this scenario I’ve tested the English and Dutch configurations by deploying them to the same group and by adding the end-user to both groups. In both cases the end-user experience was as shown here on the side. This is not something I would want when I’m deploying multiple custom Terms and Conditions because of the language of the end-users. However, this might be ideal behavior in a case with multiple parts of the company having different custom Terms and Conditions.

Report

Now that I’ve shown the creation and deployment of custom Terms and Conditions it’s time to look at the reporting capabilities of this feature. Basically this is still the same, that means that it’s still possible to see the difference in accepted version of the accepted Terms and Conditions. What’s new is that it now allows me to run a report either based on the end-user(s), or based on the company terms. That allows me to use configurations of the report as shown below.

A bit more than a month ago Microsoft released the Microsoft Intune Company Portal app specifically for Windows Phone 8.1 in the Download Center. This version of the Microsoft Intune Company Portal app is created specifically for Windows Phone 8.1 and later, as it’s created in the APPX format, which is not supported by Windows Phone 8. It can be used by administrators to deploy to end-users who do not have access to the Windows Phone Store. The main feature of this version of the Microsoft Intune Company Portal app is the ability to show the configured Terms and Conditions in Microsoft Intune standalone.

In this blog post I’ll describe how this version of the Microsoft Intune Company Portal app can be signed and how it can be used in either Microsoft Intune hybrid, or Microsoft Intune standalone.

Sign the Microsoft Intune Company Portal app

Let’s start with the part that got me puzzled for a while, signing the Microsoft Intune Company Portal app. I was smart enough to use the Signtool.exe, but that alone will not do the trick. This will provide an error message indicating that the publisher of the app does not match the used code-signing certificate. For signing the Microsoft Intune Company Portal app a little bit more is required, but luckily there is a PowerShell script, which is part of the Windows Phone 8.1 SDK, which is part of Visual Studio Community 2013 CU4, that takes care of everything. To sign the Microsoft Intune Company Portal app, perform the following steps.

Tip: Use the same certificate that’s used to sign other LOB applications, or that’s already been used to sign the Microsoft Intune Company Portal app for Windows Phone 8 (xap).

The PowerShell script BuildMDILAPPX.ps1 does all the required work to successfully sign the Microsoft Intune Company Portal app. The path specified in the command, of the script, is the default path after the installation of Visual Studio Community 2013 CU4. The parameters used as input to this script require the following information.

appxfilename – This parameter specifies the path and name of the APPX file;

pfxfilename – This parameter specifies the path and name of the certificate file;

password – This parameter specifies the password of the specified certificate.

Configure the Microsoft Intune Company Portal app

Now that the Microsoft Intune Company Portal app is signed, let’s have a look at how it can be used. I’ll go through both scenarios, Microsoft Intune hybrid and Microsoft Intune standalone, as they both have their own configuration requirements.

Microsoft Intune hybrid

Since the release of the latest service pack for ConfigMgr 2012 R2, the configuration for enabling just Windows Phone 8.1 is a lot easier. Simply navigate to the Microsoft Intune Subscription Properties and select Windows Phone 8.1 and later in the configuration of the Windows Phone platform.

To make sure that the Microsoft Intune Company Portal app can be installed, the code-signing certificate, used for signing the app, must also be configured. This can be done by simply selecting pfx file and browsing to the code-signing certificate, that’s used to sign the Microsoft Intune Company Portal app, or by selecting Application enrollment token and browsing to the location of the AET file.

For Windows Phone 8.1 and later the Microsoft Intune Company Portal app must be deployed, with a Purpose of Required, to either an user or a device collection. I would suggest to target an user collection, as that collection membership is already available during the enrollment of the mobile device. This will make sure that the Microsoft Intune Company Portal app installation happens sooner, as it doesn’t have to wait on the collection membership of the mobile device. Even better would be to use the user collection configured in the Microsoft Intune Subscription Properties, as this user collection gets top priority.

Tip: Use the Microsoft Intune Company Portal app for Windows Phone 8 (xap), when the company also supports Windows Phone 8 devices, or when the company is still running ConfigMgr 2012 R2 (without service pack). This will save a lot of administrative overhead, for only minor application changes, especially from a Microsoft Intune hybrid perspective.

Microsoft Intune standalone

Funny enough, the configuration for the Microsoft Intune Company Portal app is more complicated in Microsoft Intune standalone. There is no configuration required to allow the enrollment of Windows Phone 8.1 devices, but the fun starts with uploading the code-signing certificate.

To make sure that the Microsoft Intune Company Portal app can be installed, the code-signing certificate, used for signing the app, must be uploaded to Microsoft Intune and that can only be achieved by uploading a signed Microsoft Intune Company Portal app for Windows Phone 8 (xap). After that’s successfully done, the code-signing certificate is available within Microsoft Intune for usage with other applications.

Now to prevent the installation of the Microsoft Intune Company Portal app for Windows Phone 8 (xap), configure the Approval configuration, of the deployment, to Uninstall.The next thing is to make sure that the Microsoft Intune Company Portal app for Windows Phone 8.1 (appx) is deployed with the Approval configuration of Required Install,to either an user or a device group. Again, I would suggest to target an user group, as that group membership is already available during the enrollment of the mobile device. This will make sure that the Microsoft Intune Company Portal app installation happens sooner, as it doesn’t have to wait on the group membership of the mobile device.

Tip: Use the Microsoft Intune Company Portal app for Windows Phone 8 (xap), unless the company uses custom Terms and Conditions. This will save a lot of administrative overhead, for only minor application changes.

Conclusion

Personally I prefer everything that’s newer, which in this case would be the Microsoft Intune Company Portal app for Windows Phone 8.1 (appx), but as mentioned a couple of times it’s not always the best option from an administrative perspective. To prevent any confusions make sure to know the different scenarios of the Microsoft Intune Company Portal app, before just simply deploying. For example, in Microsoft Intune standalone the use of custom Terms and Conditions can be a reason to (also) use the Microsoft Intune Company Portal app for Windows Phone 8.1 (appx).

More information

For more information about the different subjects of this blog post please refer to the following links:

And we’re back in the cloud, back in Microsoft Intune. One of the things customers like to do is customize, as the standards are often to generic. The nice thing with the Company Portal is that it’s already possible to customize things like the text, logo and colors via both Microsoft Intune standalone and Microsoft Intune hybrid (integrated with ConfigMgr). To add-on to that, it’s now also possible to create custom Terms and Conditions, via Microsoft Intune standalone, and in this blog post I’ll show how easy this can be done.

The nice thing is that I can publish custom Terms and Conditions that the users will see when they first use the Company Portal. It doesn’t matter from which device and it doesn’t matter if that device is already enrolled or not. The users will have to accept the custom Terms and Conditions before they can access the Company Portal. What makes it even better is that when I update the custom Terms and Conditions, I can choose if I want the users to accept the new Terms and Conditions again. In that case the user would have to go through the same process again when logging on to the Company Portal.

The last positive note, for now, about custom Terms and Conditions, that I would like to point out, is that they apply to users and not to devices. That means that the users only has to accept each version once.

Configuration

Now let’s go on with the configuration, which, to be quite hones, is not very difficult, but good to know. I’ll go through the different settings and I’ll also try to show the behavior of the different settings. First let’s go through the different available settings, by going through the following three steps.

Select Require users to accept company terms and conditions before using the Company Portal, provide the following information and click Save:

Title: <Provide a title for the custom terms and conditions>;

Text for terms: <Provide a text for the custom terms and conditions>;

Text to explain what it means if the user accepts: <Provide a text describing what it means when the user accepts the custom terms and conditions>;

With Decide whether to require users to re-accept updated terms select one of the following options:

Increase the version number, and require all users to accept the updated terms the next time they open the Company Portal;

Keep the current version number, and require only new users to accept the updated terms;

In my opinion the most important setting is the last setting of the third step. With that specific setting I can decide what happens when I update the custom Terms and Conditions. Let me show that setting in a bit more detail by showing an example. When I create initial custom Terms and Conditions, it will look like the following screenshots that include an example of what it looks like on Windows Phone 8.1.

Configuration

Windows Phone 8.1 Example

Now let’s have a look at what will happen when I update the custom Terms and Conditions. When I update the custom Terms and Conditions and select Increase the version number, and require all users to accept the updated terms the next time they open the Company Portal the version number will increase and it will directly impact the users as shown in the following screenshots.

Configuration

Windows Phone 8.1 Example

When I update the custom Terms and Conditions and select Keep the current version number, and require only new users to accept the updated terms nothing will change for the end user. Simple conclusion is that a major change should always require an increase of the version number.

Besides accepting the custom Terms and Conditions the user can, off course, also decline them. In that case the user will be given an additional question of Are you sure you want to decline the terms and conditions?, including an explanation of what it would mean for the user.

Report

Now the last thing I would like to know is which users accepted the custom Terms and Conditions. The good thing is that Microsoft Intune standalone has a canned report that shows which users accepted the custom Terms and Conditions. This includes the information about the most recent version number that the user accepted and the date and time it was accepted. For example, below are two examples about a user that accepted the initial custom Terms and Conditions and later also accepted the renewed custom Terms and Conditions.

Award

Subscribe to updates

About

I’m Peter van der Woude, born in 1983 and I’m living together with my wife and two sons in the Netherlands.

Currently I work for KPN Consulting. At this moment my main focus is Enterprise Client Management via Microsoft Intune and/ or System Center Configuration Manager (ConfigMgr 2007/ 2012/ CB) and I love it!