Copilot appearance for SMB will require patience

man waiting patiently and not rushin

Microsoft has announced that Copilot will be available on November the 1st 2023. Unfortunately, Microsoft is only targeting the initial release at enterprises as revealed in a document titled:

Microsoft 365 Copilot General Availability FAQ for partners. In essence it says:

Availability will be worldwide, in the public clouds, and customers will be able to transact via the EA/EAS/MCA-E channels.

the document also addresses the question:

Why are we not making the SKU available in Direct and CSP channels?

Microsoft 365 Copilot is an amazing new technology, but we are all learning together. To ensure
a smooth integration process, we’ve decided to start by introducing it to our Enterprise and
SMC-Corporate customers via EA/EAS/MCA-E.

there will also be minimum purchase requirements, also highlighted in the document:

Is there a minimum number of seats customers should buy?

Yes, customers must buy at least 300 seats of Microsoft 365 Copilot.

It is disappointing to see many claim, even some well respected identities in the SMB space, that Microsoft is not delivering Copilot to SMB. The reality is that the SMB space has always had to wait for technologies to trickle down and Copilot will be no different.

As I understand it, Copilot and AI in general, places a lot more load on the back end servers and much of this cannot be cached like normal searching can. Also, Microsoft doesn’t have a true indication of the load users will place on cloud infrastructure when it starts to be used in production. They therefore want to bring this load on in a controlled manner to avoid failure, which would not be good or profitable for a new service like Copilot.

Thus, there are many technical and business reasons for limiting the roll out of Copilot to the customers. There is significant demand in all areas for the technology but it needs to both prove itself and pay its way before it is widely adopted. That means that those in SMB are going to wait a little longer before it becomes available as a direct purchase. It does not mean that Microsoft won’t be delivering to all audiences, it just means people will need to be patient.

I would point you back to the features that have been added to Microsoft Business premium over time. At release of this product it didn’t include technologies like Entra ID P1 or Defender for Business. However, they did come to the product. Perhaps they didn’t arrive as soon as people would have liked but they did arrive and we are reaping the benefits today.

There is no doubt that the demand for Copilot is significant. There is no doubt that will will benefit the SMB market. However, it is incorrect to say Copilot will not be available for the SMB market. It will just require a little patience for it to become available, which to be honest is probably a good thing to let others work the kinks out.

Using Sentinel to determine application usage

examinatyion using a magnifying glass

In recent article:

Block applications on Windows devices using Intune

I outlined how to prevent an application from running on a Windows device. It would be nice to know how many people are running this application prior to it being blocked (and even before). You can achieve this using Sentinel.

Many don’t appreciate

The extra value that Microsoft Defender provides

apart from security. In a nutshell, Defender for Endpoint sends signals from devices into the Microsoft cloud that something like Sentinel can take advantage of. This is something that can be taken advantage of to see application usage.

DeviceNetworkEvents
| where InitiatingProcessFileName contains “msedge.exe”
| project TimeGenerated, RemoteUrl, RemoteIP, DeviceName, InitiatingProcessAccountName
| summarize count() by bin(TimeGenerated,1day),DeviceName
| render columnchart

an example of this is the above KQL query, which when run provides an output like:

The result is basically a bar graph, over whatever time you specify, of how many times an application has been used. This is a great indicative way to get a feel for how often a device is running a particular application (here msedge.exe). The different bar colours show each particular device and each bar height represents the total usage of that application for one day.

The great thing is that you can further customize and enhance this query to suit your needs to product the output your require. You can then take that query and embed it into a Sentinel workbook so that it is available as part of a dashboard.

There is just so much that you can do and all it takes is becoming familiar with the tools Microsoft provides in your environment.

Block applications on Windows devices using Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

6. Setting an Edge Security Baseline with Intune

7. Setting an individual Attack Surface Reduction (ASR) rule in Intune

8. Setting Edge as the default browser using Intune

Now that we have Microsoft Edge all set up and have done as much as we can to encourage people to shift away from using other browsers, it’s now time block any other browsing options. We can again use Intune to achieve this and, typically, it can be done using a number of different methods. Here, we’ll use what I consider the easiest method.

Once again, create a Configuration profile for Windows 10 and later using the Settings catalog as shown above.

Give the policy a suitable name and continue.

In the search field type ‘specified windows application’ and select Search. The only category that appears should be Administrative Templates\System, which you should select. Then in the lower pane select Don’t run specified Windows applications (User) as shown above.

Enable the Don’t run specified Windows applications (User) and then enter the name of the applications you do not wish to run. Here, we’ll block chrome.exe and brave.exe as shown above.

These settings are covered in the RestrictApps documentation in which you will note:

1. The setting applies to users not devices:

and

2. This policy setting only prevents users from running programs that are started by the File Explorer process. It doesn’t prevent users from running programs such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting doesn’t prevent them from starting programs in the command window even though they would be prevented from doing so using File Explorer.

3. Blocking occurs by filename only. If users can rename the file then it will execute.

As mentioned previously, this is but the simplest method to block existing applications from running. Other options are available if you wish a more comprehensive blocking approach.

Finish configuring the policy remembering to assign it to a user NOT device group.

Once the policy has been deployed to your fleet and these machines have been rebooted, when a user tried to run an application that you have specified as block in the policy they will receive message like that shown above.

The good thing about this policy is that you can easily extend it to include any other applications you don’t users to run on their Windows devices.

Setting Edge as the default browser using Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

6. Setting an Edge Security Baseline with Intune

7. Setting an individual Attack Surface Reduction (ASR) rule in Intune

Now that Microsoft Edge has been secured in the environment, the next task will be to set Microsoft Edge as the default browser. There are number of ways of achieving this, but I’ll use the more modern Intune Settings catalog approach.

The first step in the process is to take a machine that already has Microsoft Edge configured as the default browser app and run the command:

dism /online /export-defaultappassociations:edgedefault.xml

This will produce an XML with all the application defaults for that device.

If you just want to configure Microsoft Edge as the default browser you’ll need to edit the XML file until it looks something like this:

<?xml version=”1.0″ encoding=”UTF-8″?>
<DefaultAssociations>
     <Association Identifier=”.htm” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.html” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.mht” ProgId=”MSEdgeMHT” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.mhtml” ProgId=”MSEdgeMHT” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.pdf” ProgId=”MSEdgePDF” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.svg” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.xht” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.xhtml” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”ftp” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”http” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”https” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”microsoft-edge” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”microsoft-edge-holographic” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”ms-xbl-3d8b930f” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”read” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
</DefaultAssociations>

Next, you’ll need to convert that XML file to a base64 file for us an Intune policy. You can do that using the following site:

https://www.base64encode.org/

The output from this conversion should look like this:

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxEZWZhdWx0QXNzb2NpYXRpb25zPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIuaHRtIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLmh0bWwiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIubWh0IiBQcm9nSWQ9Ik1TRWRnZU1IVCIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLm1odG1sIiBQcm9nSWQ9Ik1TRWRnZU1IVCIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLnBkZiIgUHJvZ0lkPSJNU0VkZ2VQREYiIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Ii5zdmciIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIueGh0IiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLnhodG1sIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iZnRwIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iaHR0cCIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Imh0dHBzIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0ibWljcm9zb2Z0LWVkZ2UiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSJtaWNyb3NvZnQtZWRnZS1ob2xvZ3JhcGhpYyIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Im1zLXhibC0zZDhiOTMwZiIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9InJlYWQiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KPC9EZWZhdWx0QXNzb2NpYXRpb25zPg==

In the Intune console, create a new Device Configuration profile using the Settings Catalog:

Give the new policy a meaningful name and continue.

In the Settings picker search for applications and then select Application defaults and then Default Associations Configuration in the results as shown above.

Into the option Default Associations Configuration paste a copy of the base64 file you created from the original XML.

Complete the policy by assigning it to a group of devices NOT users. This is because the Policy CSP – ApplicationDefaults is only scoped to devices per:

This may mean you need to create a different Edge configuration policy from the one created in previous steps, if that policy was assigned to users.

When the policy has been deployed from Intune, and the device rebooted, Microsoft Edge will be the default browser for the device.

Of course, the user can still change the default back but they will need to do that after every reboot. In the future, you’d create a policy to prevent that, but for now, if the user is that desperate for their old browser they can swap. However, the next policy I’ll cover will show you how to stop other browsers (or any other application) from running on Windows devices.

Setting an individual Attack Surface Reduction (ASR) rule in Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

6. Setting an Edge Security Baseline with Intune

The next recommended setting to implement is Attack Surface Reduction (ASR) rules. I’ve detailed how you can set this on individual devices using PowerShell here:

Show ASR settings for device with PowerShell

I’ve also detailed how to do this with Intune previously:

Attack surface reduction for Windows 10

In a nutshell, ASR is going to prevent child processes from launching, which is typically how a malware infection starts.

To create a stand alone ASR rule navigate to Endpoint security, Attack surface reduction in the Intune portal and select Create policy, as shown above.

Select the platform as Windows 10, Windows 11 and Windows Server and the profile as Attack Surface Reduction Rules.

Then Create the policy

As always, give the policy a meaningful name.

You should then see a list of the 16 standard ASR rule types as well as a rule called Block Webshell creation for Severs.

The best practice is to set all of these to Block. However, you will also see options for Audit and Warn if you want to take a more cautious approach.

The good thing about an individual ASR policy like this is that you get a lot more options that can be configured, unlike other policies in Intune that also include ASR. An example if the above, where you can provide enter a directory or file which will prevent ASR rules from matching. As an example, a path might be defined as: C:\Windows to exclude all files in this directory. A fully qualified resource name might be defined as: C:\Windows\App.exe.

Best practice is not to have any exclusions.

A little further down you’ll see a setting for Enable Controlled Folder Access as shown above. The controlled folder access feature removes modify and delete permissions from untrusted applications to certain folders such as My Documents.

Best Practice is to set this to Enabled.

Under this you can set Controlled Folder Access Protected Folders and Controlled Folder Access Allowed Applications. Controlled Folder Access Protected Folder allows adding user-specified folder locations to the controlled folder access feature. These folders will complement the system defined folders such as My Documents and My Pictures. The Controlled Folder Access Allowed Applications allows user-specified applications to the controlled folder access feature. Adding an allowed application means the controlled folder access feature will allow the application to modify or delete content in certain folders such as My Documents. In most cases it will not be necessary to add entries. Windows Defender Antivirus will automatically detect and dynamically add applications that are friendly.

Best practice is to not have any settings here and to have these both set to Not configured.

When you configure an individual rule you’ll also see the ability to set exceptions for just this rule. As an example, a path might be defined as: c:\Windows to exclude all files in this directory. A fully qualified resource name might be defined as: C:\Windows\App.exe.

Once you have determined your settings you then apply the policy to an audience in your environment. You can use multiple policies if needed for different audiences.

If you want to monitor ASR actions in your environment you can use the following KQL query:

DeviceEvents
| where ActionType startswith ‘Asr’

This going to help you identify which devices and processes ASR is impacting, making troubleshooting much easier.

If you want to read more about ASR then visit:

Understand and use attack surface reduction capabilities

I believe ASR is something that should be enabled fully on all Windows devices, withou any exceptions or exclusions. It is an ability included with Windows for free and just needs to be enabled, either by policy or PowerShell. I would recommend setting an individual ASR policy as I have shown above as it provides the greatest flexibility when configuring as well as the greatest number of exclusions if required. Many other Intune policies include the ability to configure ASR but if you have a stand alone policy you should not configure it elsewhere or you may end up with configuration clashes and errors.

The next recommended policy will be for Defender for Endpoint.

Setting an Edge Security Baseline with Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

The next step in the process is to assign a security baseline to the Microsoft Edge environment. Security baseline policies differ from all other policies in Intune because they already have best practice settings enabled. This compares to other Intune policies where you need to go into each policy item and set them to the desired setting. Another benefit of using Security baselines is that they are easily upgradable when updated policies become available. These two factors save a lot of time and effort securing your environment.

In the Intune console, navigate to Endpoint security | Security baselines and select Security Baseline for Microsoft Edge as shown.

Select the option to Create profile and then give the profile a meaningful name.

You’ll then see a list of the individual settings with values already selected.

You can adjust any of the individual settings if you need to customise the policy. Generally, I find there is no need to make any changes here as I have found no conflicts.

Here we also find an example of one of the challenging things with implementing any policy, duplicate settings. If you remember back to the previous article on

Managing browser extensions in Edge with Intune

you’ll note that extension restrictions was configured there, but now it is also in this Security baseline policy. A best practice recommendation is to only have one place in your policies where a setting is made. This will avoid conflicts and aid troubleshooting. If you do choose to retain the same settings in multiple policies, ensure they are set identically or otherwise you will get conflicts. In this case I’ll leave the setting in place for both policies as they are the same and it is bit challenging to disable just this option in the original ‘Edge configuration’ policy created in the previous post.

With any changes made, continue with the Security baseline policy configuration and assign it to your environment.

When complete you should see the policy you just created, as shown above. Remember, you can create as many policies as you need to accommodate your environment targeted to different audiences, however the aim should be to get to a single Security baseline policy for Edge to keep things simple.

You’ll see that the policy created has a version number. You’ll also note a Change version button on the menu at the top (currently greyed out) as shown above. This is the beauty of a Security baseline policy, when an update is available you’ll be able to use this option to update the policy. You can read more about this here:

Update a profile to the latest version

We are now at a point in our roll out where we have policies to provide a secure Microsoft Edge configuration in our environment. Those already using Microsoft Edge will benefit immediately, users on other browsers still need to ‘encouraged’ to make the shift as soon as possible, but are still not being forced to use Microsoft Edge just yet (they will be eventually, so keep encouraging them to make the shift with your communications because they day when they have no other option but to switch is coming!).

for more information about the:

Microsoft Edge security baseline settings reference for Microsoft Intune

visit the above link and remember the benefit of Security baselines is that they have best practice settings already enabled, so typically all that is needed to apply the policy with these default settings .

It is now time to look at securing the Windows devices against ransomware. Stay tuned.

Managing browser extensions in Edge with Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

The goal we are trying to achieve is to move all users from third party browsers to using Microsoft Edge. The next step in this process will be deploying and managing a constrained set of extensions in Microsoft Edge.

The first step is to visit the Microsoft Edge store for extensions and grab the unique ID for the extensions you want to use. You find this in the URL for the extension as shown above. Here are three common extensions I will use for this example:

Lastpass – bbcinlkgjjkejfdpemiealijmmooekmp

DuckDuckGo Privacy – caoacbimdbbljakfhgikoodekdnlcgpk

Save to Pocket – jicacccodjjgmghnmekophahpmddeemd

Once we have these we need to login to the Intune management portal.

In the last article I created a generic device configuration profile called ‘Edge configuration’ policy that I’ll be extending here. Select the policy name to view its settings.

Scroll down the policy until you locate the heading Configuration settings as shown above, and then select the Edit hyperlink to the right of this.

Select the + Add Settings link as shown above.

Expand the Microsoft Edge option in the top part of the blade that appears and then select Extensions as shown above. In the options that appear in the lower part of the screen select:

– Allow specific extensions to be installed

– Control which extensions are installed silently

– Control which extensions cannot be installed

Close the blade.

You should now see the ability to customise these options in the policy as shown above.

Add the ID’s of the extensions you want silently installed and ensure that each is ticked as shown.

Add ‘*’ (i.e. all) as the option for IDs to be prevented from being installed and ensure it is ticked as shown. Basically all other extensions will not be permitted to be installed.

Add the ID’s of the extensions you want to allow in the exempt from block area and ensure each is ticked as shown.

Save the policy changes and allow it to be propagated to all groups included in the policy.

Once the policy has rolled out, you should find the extensions you entered in the policy have been added to Microsoft Edge as shown above.

You should also find that users cannot add additional extensions to their Microsoft Edge browser as shown above.

The aim of this exercise was to automatically configure a number of ‘standard’ extensions for Microsoft Edge and block everything else. We have been able to achieve this by extending the original ‘Edge configuration’ policy that was created earlier.

The next step in the process will be to lock down the Microsoft Edge browser using a baseline policy. Stay tuned.