The underestimated compliance policy in Microsoft Intune

Way back when I started to work with Microsoft Intune, I remember that I had a very hard time understanding the use case for the compliance policy.

They don’t do anything, and I can’t even get them for all of my configuration settings?

Part of that is still true today, but not in a bad way. This post will explain what you need to know about them, how to design them and why it’s a vital part of most Microsoft courses I deliver.

Compliance policy 101

Compliance policies are used to verify that a device have configured the security settings that are required by an organization. This does not mean that you need to use Intune to configure a specific setting.

Compliance policies are as applicable to a BYO-device as for a company owned. However, the responsibility to configure the required settings could be either the user, and IT-department or both. Regardless, we want to ensure that the settings have applied before we allow access to company resources.

Evaluation of compliance policies

Compliance policies are evaluated, and the result sent to Intune, on the same schedule as policies – which is around every 8th hour. We should therefore not rely on compliance policies to, as an example, prevent malicious behavior or IT-attacks. If you force a device sync that will also trigger a compliance sync.

That allows us to manually or automated evaluate compliance more often. Other integrations, that do not rely on the compliance state being pushed from the device, such as JAMF and Microsoft Defender ATP, will give you an even faster and more frequent evaluation.

Compliance policies are there to ensure that those risk can be prevented from the start. We will have a lag between something changing on a device that makes it non-compliant until that information reaches the Intune service – make sure you are aware of that.

Compliance policies can be integrated with Configuration Manager to allow you to track compliance for just about anything. The settings that are available to you in the Intune-portal is in comparison limited, but in most cases, it should be enough from a security point of view.

A part of something bigger

Compliance policies have, on their own, a limited use case, even if we can use them to lock or retire devices that are non-compliant. We will get back to that later in this post. The real benefit is of course to integrate compliance as a part of your conditional access strategy.

CA policy that requires Compliant device










Integrating with conditional access have two benefits, first the obvious one that we can ensure that devices that are connecting to cloud- and/or internal resources are following security requirements.

The other aspect is that you can guide users into the management scenario you prefer, managed devices or managed apps. If you configure your conditional access for a specific app to require a compliant device, that will require the device to be enrolled. If not, the user of the device can connect – if they fulfill the other controls in the CA policy.

Designing compliance policies – more than just the settings

When I visit new customers, I usually find the compliance policies in the same state. They have one compliance policy per platform, with all or most settings configured according to their requirements. This configuration does work, but it has several downsides.

Some also have the default tenant wide settings configured. In rare cases I also find that many of the compliance policies are not assigned or not widely deployed.

Compliance policy settings – default or not?

There are settings that are available and configured in Intune to allow for a smooth onboarding and migration to a zero-trust security model. They aren’t really, in my opinion, supposed to stay in that state. One of them, which I may cover in a later blog post, is Hybrid Azure AD join as a requirement in Conditional Access.

The other one, is the setting for how to treat devices (or users really) that aren’t targeted by a compliance policy. The default settings is to mark these as compliant, to ensure access to corporate resources. You can find this, and the other settings mentioned in the paragraph, in the Endpoint Manager portal, Devices, Compliance Policies, Compliance policy settings.

This setting is something that, when you have implemented your Conditional Access policies and users are able to register their devices, I recommend that you change. To allow any device, from which a user is trying to access a service as compliant, based on that the users isn’t targeted by policies, is a bad idea.

Going on vacation or what?

Second is the time before a device that have not communicated with Intune is marked as non-compliant, or Compliance status validity period. 

Compliance Settings




In this case you should look at your organization and try to figure out how many days it is likely that a user could be offline under normal circumstances. The number of days should be the limit for when a device is marked as non-compliant. The default is 30 days, which depending on your organization could be a long time. Especially today where its very uncommon to go without a connection for an extended time period.

We configure this setting to ensure that an attacker would not be able to block access to the Intune service, but allow access to other online services while configuring the phone to a non-compliant state.

Also, the last setting here is Enhanced jailbreak detection. It requires location services to be turned on to work properly, but I advise you to try it out. If you find that it actually has a significant impact on battery or that your users turn location services off, you can consider to turn it off. If not, keep it on.

Do not make the group policy mistake – break down your policies

Do not put a variety of different settings into the same compliance policy. Divide them into logical policies based on the platform.

As an example: Have one policy for password settings and one policy for disk encryption.

This also allows you to more easily apply granular policies over time, if needed. For an organization that runs Windows, MacOS, Android and iOS you´ll probably see around 20-25 policies in total, instead of 4.

This will give you a much easier overview of which devices that aren’t compliant for a specific setting. It will also allow you to make notifications and compliance timings much more granular, relevant and user friendly.

A list of Compliance policies

A list of Compliance policies

Notify, notify, notify and take action

The main benefit of having multiple policies is that its much easier to inform the user of a non-compliant device about the reason for non-compliance. This allows the user to either seek help or remediate the non-compliance state on their own. If you are using a single policy, we can’t target a specific notification to a specific reason for non-compliance, making it harder to self-remediate.

In general, I see a much lower usage of notifications and actions for non-compliance than what would be useful and valuable both for the users but perhaps especially for administrators. The most common setting I see is just leaving the configuration at default. The default setting is to change the compliance state to non-compliant instantly when a configuration is changed to a non-compliant value.

In some cases, this is a suitable configuration, such as jailbreak detection or password configurations. These are either settings that could be potentially dangerous or which could be remediated easily and swiftly. For other settings, it could be more suitable to change the actions to more customized options.

Actions not action!

That brings us to another aspect of the actions. You are not limited to a certain number of actions for a policy. You could have multiple actions and notifications for each policy. Below you can find an example for a policy that evaluates the version of an iOS device.

Notification and actions for non-compliance








As you can see, I send customized notifications at a number of intervals and I also combine e-mail notifications as well as the newly released feature of push notifications. Lastly, I do take additional actions as well as change the compliance state of the device.

The available actions for iOS are the once below, but varies based on the platform:

iOS actions






This kind of process for non-compliance is what I would advise for most of your compliance policies. Also note that the e-mail notifications can send additional notifications to other addresses than the user that is targeted by the compliance policy. A very useful feature for administrators or security managers to get notified if a user tries to bypass the security configuration.

We also have actions that will retire a device (which is again very useful for BYOD scenarios especially) and lock devices (which may be mostly applicable to shared devices or kiosk). For personal devices, we in general would apply CA policies and therefore limit the usage of the device.

It is all about timing – give the user a chance

For notifications and actions to work efficiently we need to configure the timings for each action accordingly. Just as in the example above it could be a reasonable configuration to wait to put the device into a non-compliance state. This is especially applicable to version checks. It will, most likely, take the user a while to remediate the compliance state.

You can also use timings to send additional notifications with intervals to the user. Reminding the user to remediate if they have not done that after the first notification have been received.

Finding the correct timing

The timings always count from the time when the compliance state reached the Intune service, so there may be a time difference between the configuration change, the compliance state and therefore also the notifications. The difference could be up to 8 hours, which is also why we cant be more exact than a day. Keep this in mind when configuring your notifications as well.

The timings should be based on the ability to self-remediate as well as your organizations policies of course. Its therefore hard to give any general recommendations. Do have in mind that, again depending on the configuration, some compliance states could be harder to remediate during a weekend as an example. Like in the example above where I allow three days after non-compliance before the device is locked/retired.

Compliance policy integrations

Some aspects of the compliance policies are dependent on integrations with other tools and solutions. Based on your needs, your platform and your environment it could be advisable to integrate with these. Most importantly is however to be aware that these settings is not evaluated correctly, and it may lead to unexpected results.

ME Configuration Manager

If you are using Microsoft Endpoint Configuration Manager, you should be co-managing the devices that aren’t exclusively managed by Microsoft Intune. One of the oldest, and most valuable aspects of Co-management, is compliance evaluation.

With an option added in Configuration Manager 1910 we can combine the advanced options available in Configuration Managers configuration items with the compliance evaluation of Intune. In practice, we can evaluate close to anything on a co-managed device and send that compliance state to Intune. This could include settings in LOB-apps, more granular options for BitLocker-encryption or a third party anti-malware.

Microsoft Defender Advanced Threat Protection

For Windows and Android devices, we can base compliance state on the device risk delivered from Microsoft Defender ATP. Apart from providing a very detail and fast security evaluation of a device, MD ATP also communicates directly with the Intune. This allows for a more frequent update to the compliance state. Note that MDATP does not necessarily evaluate the activated features or applied configurations of the device. You should therefore ensure that that is covered by other compliance policies.

3d party threat protection

For iOS and Android, we can get a similar experience and state reporting from 3rd party threat protection tools. The protection here is mostly based around malicious apps, or apps that may required higher privileges than needed for a functioning app. Just as MDATP the 3rd party app, based on your configurations, sets a device risk score that you can evaluate as part of your compliance policy.


If you are using JAMF Pro to configure the MacOS devices in your environment, the tool is easy to integrate with Microsoft Intune. JAMF will continuously send inventory data from the devices to Intune, which Intune uses to evaluate the compliance state of the device. That allows you to manage Macs with JAMF, while getting the benefits from compliance and conditional access with Intune.


Even though we will not cover this integration in detail in this post, it is possible to use the compliance state of a device to allow or prevent access to internal networks and/or VPNs. The most common hardware vendors that support that from a networking perspective is Cisco and Checkpoint. The integration would enable a scenario where a firewall or wireless network controller would ask the Intune service for a compliance state. Based on that state, network access could be allowed, prevented or limited.

What you can learn from working with compliance policies

Other than being very useful, what can you learn from working with compliance policies?

First, you can learn a lot about integrations with other 1st and 3rd party products. That´s also why I usually save compliance policies together with Conditional Access to the end of every MS Intune course I deliver. It summarizes everything that the people who take my class have learned in a very hands on way.

Second, you learn about user interactivity. Since compliance policies drives Conditional Access, it will have an impact on the users experience. Imagine the situation yourself:

You are watching TV, when suddenly the program you are watching is interrupted. On the screen a message is visible:

You have broken one of our rules, we have therefore paused your subscription until you make up for what you have done.

Rather frustrating right? Not knowing, and also negatively impacting the experience, will for sure make your users angry.

Therefore, make it easy for users to remain compliant. Give them the proper information to get back to a compliant state. That will help your organization to stay compliant.

What Compliance policies are built for

Lastly, you also learn when to use the proper tool. If you are looking for something that instantly will block access if a malicious app is installed, compliance policies alone are not the tool.

If you are looking for something to report back on policy applicability on a granular level, compliance policies is not the tool

If you want to configure settings that will apply and reconfigure devices, compliance policies isn’t what you are looking for.

On the other hand: If you want to ensure that your users are keeping their devices up to date in a promptly fashion – it’s the tool to use.

If you want to allow your users to enroll their own devices, but don’t want to enforce policies in an intrusive way, it’s a great tool.

When you want to ensure that your users can’t access data on an unprotected devices, it’s a very good combination together with Conditional Access.

Summary (or TL: DR)

Compliance policies is one of the vital tools in your device management toolbox. Ensure to understand the usage of them and how to configure them in an efficient way. There are also a number of aspects that I haven’t been able to cover in this post. Therefore it is  likely that another one will follow with more details on individual settings.

  • Spilt the settings into logical policies, to make it easy to communicate the reason for non-compliance.
  • Configure the tenant wide settings to suit your needs, ensure that all users have a policy applied to them.
  • Use actions and notifications to minimize the amount of interaction needed with your service desk. When a user needs to remediate, they should know why and how.

Furthermore, evaluate what you want to use compliance policies for, and if MS Intune is enough to fulfill those needs. You may need to integrate additional services, to further protect your data and applications.

In the end, that´s what compliance policies are all about. Helping us protecting what´s valuable. Its one of the gatekeepers and implemented correctly it will be essential in your Stay Current strategy.

Links to official documentation as well as useful community blogs:



The case of the missing Apple Business Manager – or how to choose your vendor

I´m back blogging again, but Ill start with a short post straight from the trenches!

I am working on a MDM project where we are leveraging Microsoft Intune as well as JAMF for Macs. The implementation of Intune (and JAMF) will divide users into three different categories. The reason is due to very different security requirements, and will be covered in upcoming posts.

When we tested the enrollment process using ABM, we configured the enrollment profile in Intune as shown in the screenshot below:

The Intune Create profile page with "Locked enrollment" highlighted









While there are many parts of this screen that I find interesting this post will focus on the “Locked enrollment” part. This setting is applied to prevent the user from removing the device from management and if done, require a full wipe.

The challenge

We assigned a number of devices to the policy and started with the initial tests. The tests included attempts to remove management from the device, with some surprising results.

We realized that we are not only able to remove the device from management (which as expected required the device to be reset) but also from Apple Business Manager!

In the normal case, a removal of management on a ABM-enrolled device really wouldn’t be a problem. The device is reset and at next startup forced into management again. That makes it a rather boring device to steal. This ensures that sensitive data the device stores is remove when management is removed.

In this case we lost the connection to ABM. The device could be started again and it wouldn’t be forced into Intune management, which was not the goal.

The management profile page of an iOS device

Why was this happening? I´ve done plenty of projects where this had been working flawlessly, but this time the result was both a security risk as well as a surprise.

With some help from my Apple contacts we were able to figure it out. The solution were both an eye-opener for the customer as well as a good learning for myself.

The cause and the solution

The customer had ensured that when you procured iOS devices, their vendor promised to add them to ABM automatically – which is something I highly recommend that you do. When I took a look at the vendor I quickly realized that they were lacking the required certifications from Apple to provide this service. After a discussion between the customer and the vendor we got the following information:

The vendors purchases iOS devices from a number of different distributors, some of them are able to do the ABM upload on behalf of the vendor. This upload is the recommended approach. So far so good. When the vendor needs to deliver a larger numbers of devices, they sometimes were falling back to Apple Configurator for ABM upload. Which is a manual process and something you should avoid if possible.

This also takes us to the core challenge:

According to the official documentation:

The user of a ABM enrolled device, that were added using Apple Configurator, are able to remove it from: “enrolment, supervision and MDM” – for a period of 30 days.

The default behavior of Apple Business Manager is also a challenge. When adding a new MDM server to ABM it allows the MDM to release devices from ABM on its own. This combined behavior caused the issues. In the end the customer wrote a new agreement with the vendor. The agreement requires the vendor to upload devices using their distributors, not Apple Configurator.

Server settings page in Apple Business Manager

Learnings and recommendations

So, what have we learned and what do I advise you as readers to do:

  • Choose your vendor. A verified Apple reseller with an official partner status is my strongest recommendation. Don´t try to go down the cheapest route, since it may cost you in the end.
    • This also more and more apply to vendors and resellers of both Windows and Android (especially Samsung) devices.
  • Avoid adding devices to ABM using Apple Configuration. It works great for testing, and small scale, but its not for production use.
  • Decide if the MDM should be able to release devices from ABM.
    • If not, de-select the option in Apple Business Manager.
  • Test the entire lifecycle of a mobile device when implementing or making changes to an MDM.

More blogs will follow on Microsoft Intune, management of Apple devices and Mobile devices security – stay (in)tuned!


Have you experienced the same with your iOS devices? Then you can always put them back in ABM using, guess what, Apple Configurator! There are plenty of instruction out there, but this video explains in rather well in my opinion.

Adding iOS Devices to DEP with Apple Configurator 2.5

New adventures – with TrueSec

Today is the first day of my new adventure. As of today, I´ve joined TrueSec Infrastructure and will be taking on the role as Principal Technical Architect. I will be focusing on Microsoft 365 and other technologies related to it.

Its really a dream come true, I still do remember my first user group that I attended many years ago. Johan Arwidmark was one of the speakers, and he and many of my new colleagues at TrueSec have in different ways been idols and people you always have been able to turn to.

That´s of course one of my goals as well, to become a trusted advisor for both customers and the community. I do see TrueSec as a great company that will enable me to achieve that. They will also be able to provide me with opportunities to work with some of the worlds most interesting and, in a good way, challenging companies and organizations.

From today, Ill be working globally and ill of course still be doing as many community activities as possible. In the coming months I´m speaking at Techdays Sweden, Microsoft Ignite, Experts Live Europe. Looking into the future I´m one of the featured speakers at Igel Disrupt EMEA in February.

Me, Alexander and Toni will continue the adventure we have set out on with Knee-Deep in Tech, that wont change. We will still aim to publish weekly podcasts, blogpost and be active on social media.

On top of that, I know that TrueSec have a few things planned for me – so stay tuned and reach out if there´s anything I can help you out with. You can reach me at Twitter, LinkedIn and of course via e-mail.

Deploying and Managing Power BI using Microsoft Intune

This post is written on request by parts of the Power BI community. I’ve really enjoyed writing it, not because it’s a deep dive, because it isn’t. I’ve enjoyed writing it because this post will show what you can do with Intune and Windows 10, which will help another strong community to grow and make use of Microsoft 365.

So, this is the request:

How do we distribute Power BI to our users, how do we keep the clients up to date and should we choose the Store version of Power BI Desktop or the installed version?

There are a few requisites to what I’ll be showing below:

I do assume that the management and enrollment of these devices (Windows 10, iOS and Android) have been set up and are working. As well as the devices have already been enrolled (if needed).

I do expect the Power BI and Intune licenses have been assigned to the users.

The Windows devices need to be either Azure AD Joined or Hybrid Azure AD Joined.

Windows version needs to be Enterprise, Education, Business, Pro and 1607 or later.

Let’s get started!

Which version should you use – the app or the installed application?

Well, it depends on how you would like to manage it. First, the feature set in these apps are the same. You can do everything you expect to be able to do in both the app and the installed version of Power BI Desktop.

From a Windows, and a security, point of view the app (from the Microsoft Store) would be your primary choice. The reasons being that the app has been built in such a way that it will handle updates and upgrades of Windows just fine. It’s a highly secure architecture and it integrates very well with most of Microsoft’s (and others) management and security solutions.

To deploy the app, which ill show you how to do in a little while, you publish it from the Microsoft Store. That means that you don’t have to repackage it, and that it will keep itself up to date after you’ve installed it. You’ll also ensure that you always are deploying the latest release of Power BI.

The downsides on the other hand are mainly two:

  1. The bad thing about an app that updates itself, is that you don’t have control over the updates. You can’t control when a specific update is being released and installed on your machines.
  2. When you are using the app, it will automatically adapt its language to the language of the Windows 10 operating system its installed on. So, say at you have a Swedish Windows 10 Enterprise, then the app will be in Swedish as well. Which in some cases isn’t at all what we want.

On the other hand, with the installed app, which we from the start get in as an .MSI file you have to take care of your upgrades by yourself. You must repackage it, which is a simple process, but still something you need to do. This is also a fairly old, and not always streamlined way of installing applications. It’s a larger, even though small, security concern than the app and it demands more work from you as an administrator.

The flipside on the other hand is control. You control when the Power BI update gets installed on machines. Its much easier to pilot a new version to a select group of users and you can release in the pace you’d like.

You are also in control of which language Power BI will be installed in, and it doesn’t need to match the language of the operating system.

So, you are in most cases choosing between simplicity or control. Next, ill show you how to set up the distribution of both of these using Microsoft Intune and Microsoft Store for Business.

Distributing and installing Power BI using Microsoft Store for Business & Microsoft Intune

We’ll start in the Intune console, which you can find in the Azure portal ( Search for Intune and when you’ve found it, navigate into the “Apps” section.

To the left you’ll see an option for Microsoft Store for Business and if this is the first time your organization is using it, we’ll have to set it up. To do this you’ll need Global Admin rights, so usually you would be required to ask on of your colleagues, but if you are “fortunate” enough to have these rights, go ahead.

Open the Business Store using the link and accept the EULA. Thereafter navigate to Manage\Settings\Distribute and activate Intune.

Next, it’s time to choose apps. In black ribbon at the top of the page, click “Shop for my organization” and search for Power BI. Once you’ve found it open it up and click “Get the app”. You’ll need to accept yet another EULA.

Now, I recommend that you add the app to your private store as well as distribute it with Intune. Therefore, next to the “Install” button you have a settings toggle (three dots) in here you can make the app available to everyone in the private part of Microsoft Store for Business.

For now, we are done in Microsoft Store for Business. Go back to the Intune portal and Save your settings for Microsoft Store for business. Refresh the page and you should now see a green checkmark and a text telling you that the connecting between Microsoft Store for Business and Intune has been configure.

In the apps list (you’ll find the link to it to the left in the portal) you should now see Power BI. Click on the line and then choose assignments. You have the possibilities to distribute it to both apps and users, in most cases you would like to distribute it to users.

When you choose to assign it, you’ll be asked to provide a group or a user. I would highly recommend using an Azure AD group for assignment.

In terms of how it will be installed, you can choose available or required. Required means that the app will be installed automatically on devices that the users you have assigned it to logs on to without any user interaction.

Available on the other hand publishes the app in the Company Portal, and the user can then self-service themselves to the app from the app.

Its up to you what service you would like to provide your users, and you can mix these two for different groups of users.

If you choose required, it will install as soon as the device have synchronized with Intune.

To deploy the Power BI app to Android or iOS you follow almost the same procedure. But you don’t, necessarily, need to configure the platforms specific stores.

You add an app using the “Add” button at the top of the Apps section. Choose your platform and search for Power BI. You’ll then assign it in the exact same way as you did with the Windows 10 apps.

Distributing and installing Power BI using Microsoft Intune and Win32-app deployment

To install the app, a few more steps are required from your side. You’ll first need to create a package that Intune can distribute for you.

To do this, download the Power BI desktop installation file and save it in a folder called “PowerBI”. Before continuing, create an empty folder named “PowerBIApp”. You can find the download here:

Interestingly enough if you choose the “Download” option you’ll actually be sent to the Store version, which points to which version Microsoft thinks that we should choose. So, to find the MSI file we need to choose the “Advanced Download Options”.

Download the Intune App Packaging tool from GitHub and extract the .ZIP file.

Open a PowerShell prompt as administrator on your machine and run the Intune packaging tool.

You’ll be asked for three things by the packaging tool:

  1. The full path to the “PowerBI” folder where you saved the installation file, aka “Source Folder”. C:\Users\<Username>\Downloads\PowerBI as an example.
  2. The full path to the installation file, aka “Setup File”. C:\Users\<Username>\Downloads\PowerBI\PowerBI.msi as an example.
  3. The full path to the output folder where the package will be created, aka “Output Folder”. C:\Users\<Username>\Downloads\PowerBIApp as an example.

When you have entered this information, the tool will compress the package and the output will be in the form of a .intunewin file.

Now, its time to head back to Intune and add a new app. In the Client Apps section, select add and choose to add a “Windows app (Win32)”.

Select your newly created app package and upload it to Intune.

Next, you are required to enter a suitable name, description and Publisher. Ensure that you make it clear if this deployment is intended for 32-bit or 64-bit (if you are thinking about the 32-bit one, we need to have a discussion) and which language you are installing.

In this case, and usually when we base our package on an MSI-file the installation and uninstallation commands will populate by themselves. However, due to how the Power BI Desktop MSI file is designed we need to change the original command line to the following:

msiexec /I PBIDesktop_x64.msi ACCEPT_EULA=1

Intune will then add ” /qn ALLUSERS=1” to the command line to complete it.

In the next step you must configure which requirements that needs to be fulfilled for the installation to take place. We will only configure x64 and a later version of Windows 10, but you are also able to add requirements on disk space, RAM, number of CPUs and CPU speed if you’d like.

To ensure that the installation is successful, Intune requires you to specify a detection rule. The detection rule could be a file, a registry setting or anything else that will tell Intune that everything is as it should be. The good thing about using an MSI in this case is that the MSI will tattoo a unique value for that file to the MSI, a GUID, which we can use to verify the installation. You can use this by selecting to manually configure a detection rule and add an MSI rule. This will auto-populate for you.

We could, if we would like to add custom return codes as well as tags (often used for Role Based Access Control RBAC), but for this time we can leave them.

When you then press add the package will start the upload to Intune, encrypting it on the way. Once the upload is done, we will then open the app and assign it to our users.

We do this in the exact same way as we did with the app-version of Power BI. Select a group and choose how it should be installed. The user experience is however a bit different form the app.

After the assignment, it can take a while for the devices to retrieve the instructions to install the app, but after a while it will start to download and install without requiring the user to interact with in (in the case of a required deployment).


Managing Power BI with Microsoft Intune

So, you have deployed your new apps to your machines and the next update gets out. What do you do?

For the app from Microsoft Store for Business, you don’t need to do anything. This will handle the upgrades itself as soon as the new version is available.

For the Win32 app, you need to do some more hands on work. You’ll need to create a new package for the new version and create new a new app in Intune. Before deploying the new version, you need to remove the assignment of the previous version, because when the update is installed the GUID will change and therefore trigger a new installation of the old one and so on…

So, the steps in short:

  1. Create a new package for the new version and upload it as a new app to Intune.
  2. Remove the assignment of the old version. You could create a “Pilot” group and exclude that from the assignment as well, but that’s another story.
  3. Create a new assignment for the new version and let the MSI take care of the update itself.
  4. Done!

You could automate a lot of this with PowerShell, but that’s for another time

Wrap Up

As a wrap up, your first and most important choice is to choose how to install Power BI. What do you value most? Less work or more control? There is nothing that says that you couldn’t even combine these two, its just a matter of controlling the Azure AD groups. The users will be very confused to see two different Power BI apps on their machines.

Next, is this something you as the Power BI administrator should do, or do you have a client management team that could help you out? It depends of course, but this guide will help you to get started if you need (or want) to do it yourself.

If you have any questions regarding this, let me know and ill do my best to help you out!

Don’t forget to follow me on Twitter @Bindertech as well as the #KneeDeepinTech hashtag for more great Microsoft 365 content!

Want to listen to perhaps the most bizarre Microsoft focused podcast out there? Ensure to subscribe to Knee Deep in Tech on Spotify or where you usually find podcasts!