Group Policy Analytics role in moving User authentication to Azure AD


When I meet with customers one of the conversations I typically have is that organisations would like to start joining new devices (either Autopilot or ConfigMgr deployed) to Azure AD joined and shift their user authentication process into the cloud. This has many benefits, not least the mitigation of having to rely on a VPN back to their on-prem domain controllers to perform the authentication. As the conversation progresses we talk through using Azure AD Connect to synchronise identities, and how that will work with NTFS file shares, then we hit a snag. Group Policies.

Its worth prefixing this post with the fact that typically I work with medium to large organisations with 500+ devices that have many years of GPOs, possibly created and deployed by admins no longer with the company and no clear understanding of what every GPOs purpose is let alone the specific settings in the GPO.

Up until now I have had to explain that these GPOs will no longer apply as the devices will not be joined (or Hybrid Joined) to the existing on-prem Active Directory, and Azure AD does not provide support for GPOs. The migration path would necessitate converting their GPOs to Intune Configuration profiles, enrolling their device to Intune and then deploying the profiles. So far so good… then the killer line “there is no way to convert GPOs to Configuration profiles and this would be a manual process”. At this point they start to estimate the effort involved in analysing these existing GPOs and deciding which ones to migrate and which are stale or no longer required, and they start to favor Hybrid joining the devices just to hang on to what they know as they see it as less effort. This means they miss out on the benefits of Azure AD joining the devices and keep the reliance on their VPN and line-of-sight connectivity to a Domain Controller.

Now we have a new tool to assist with this conversation, Group Policy Analytics in the Endpoint Manager admin center.

Group Policy Analytics allows us to export our existing GPOs to a .xml file and then upload this file to the Endpoint Manger admin center for automatic analysis of all the configuration contained with the GPO. This will then tell us which of the settings can be migrated to Configuration profiles, which are not supported and which are depreciated.

Lets see the workflow in action


Firstly, we need to connect to open Group Policy Management Console on a domain joined device and locate a GPO we would like to test for conversion. We then right-click on the policy and choose ‘Save Report’. Save the .xml file to a temporary location which is easily accessible.

Open Group Policy management and save a GPO as an XML file report.

Then in the Endpoint Manage admin center navigate to Devices > Group Policy Analytics (Preview), select Import and choose the .xml file we previously exported. For my demonstration I am choosing to import the Microsoft provided Windows 10 2004 security baseline GPOs as I know these contain multiple settings and are a good example of complex GPOs.

The admin center then processes the .xml and provides us with a report showing the migration possibility for every individual setting as well as a summary for what percentage of every policy can be migrated to Configuration profiles. We also get a summary showing the total number of settings and migration counts across all GPOs.

Clicking on the percentage column shows us the individual settings included in the GPO and which can be migrated to Configuration profiles.


This is a big step forward for simplifying the analysis of the workload required in the migration from GPOs to Configuration profiles, and with it helping companies to move to the cloud for user authentication. There would still be additional work to be performed to work through the ‘Not Supported’ and ‘Depreciated’ settings to determine what the impact would be and if any mitigations need to be put in place, but this is a much simpler process than anything that has come before.

However, there are some things still to consider:

Organizational Units to security groups – GPOs by design are deployed to OUs and a computer can only exist in a single OU. Configuration profiles are deployed to security groups. There is currently no way to map OU membership to security groups without writing custom PowerShell scripts and executing these on a regular basis.

Automatic creation of Configuration profile – After the GPO has been analysed by Endpoint Manager it is currently necessary to manually create the Configuration profile. Hopefully Microsoft will introduce a method for automatically creating the required profile with settings ready for deployment.

Intune enrollment – For the propose of this blog I have assumed the the devices in question will be enrolled in Intune and therefore will support Configuration profiles.

Removing Symantec Outlook Add-in using SCCM

Hi guys,

This week I have been looking into an issue a customer of mine has been experiencing with the Symantec Outlook Add-in crashing repeatedly and causing Outlook to crash too which is a poor user experience.

In order to resolve this issue we decided that the best solution was to simply remove the Add-in from the Symantec Endpoint Protection installation. However, this was complicated by the fact that the Symantec Add-in was already installed on all of the workstations and the Add-in is an optional component of the installation and not a seperate application listed in programs and features.

Looking in Program and Features then choosing to modify the Symantec Endpoint Protection installation shows me that currently the feature is installed…

And I want it to change to having the feature removed…

New Installations

As always I took a two stage approach to resolving this issue, firstly to modify the installation process for Symantec Endpoint Protection so that any workstations that need to install Symantec (primarily during OSD) were not deployed with the issue. Then I will target a remediation process to the existing workstations, this saves freshly deployed workstations having to run the fix post-deployment and also should result in the number of unmediated systems only ever decreasing as new systems will not be introduced to the environment.

The resolution for the new installations was a simple process of adding the following additional lines to the end of the SetAid.ini file which is included in the Symantec Endpoint Protection source files. This simply instructs the MSI installer which components to install, and setting the OutlookSnapin to 0 means that the component we want to exclude is skipped.

After updating the INI file I had to redistribute the content to the Distribution Points. I then tested this on a workstation and confirmed that the changes were successful.

Now I know I will not have any additional systems with the Outlook Add-in enabled I can start to resolve the issue on all of my existing workstations.

Existing installations

As we are using SCCM to deploy Symantec Endpoint Protection we already had an application which would perform the installations and I have already modified this application so that new installations will not have the Outlook Add-in enabled. As the application is an MSI type, simply re-running the application on the workstations will modify the existing installation to the desired state.

In order to correctly identify if the workstations needed to re-run the installation I needed to modify the Detection Method for the application to identify if the Outlook Add-in was NOT installed as well as Symantec Endpoint Protection was installed. The existing application only detected if Symantec Endpoint Protection was installed, so I need to modify this.

Unfortunately SCCM does not currently have the capability to identify if a file/folder/reg entry does NOT exist as part of a detection method. It is only capable of identifying if these components exist. However, it is possible to run scripts to perform the installation which means that as long as I can write a script to perform the detection I need then I should be able to successfully identify these systems.

SCCM can run PowerShell, VBS and Jscript for the Detection Method and as I am more proficient in PowerShell I chose this option. The question now though was what criteria should I be querying?

To identify this I simply ran Process Explorer on a workstation whilst I manually performed the installation of the Outlook Add-in on a test workstation. Analysing the actions of the MSIEXEC process showed me that new files were created in the C:\Program Files (x86)\Symantec\Symantec Endpoint Protection\14.2.770.0000.105\Bin\ during the installation, specifically a file called OutlookSessionPlugin.dll.

I also know that in order to identify applications that are installed on a Windows workstation I can check the registry for an entry under the hive HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ and looking on a test workstation I can see that the MSI code is {713C5DAE-75BA-4DCA-B328-F96B129DCFD5}

Now that I know what the criteria for a ‘correct’ installation is I can write a PowerShell script which will detect the criteria and return the correct results to SCCM. This code is:

$FilePath = "C:\Program Files (x86)\Symantec\Symantec Endpoint Protection\14.2.770.0000.105\Bin\OutlookSessionPlugin.dll" 
$RegPath = "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{713C5DAE-75BA-4DCA-B328-F96B129DCFD5}" 
If ((!(Test-Path $FilePath)) -and (Test-Path $regPath)) {Write-Host "Installed"} 

I then ran this manually on a test workstation both WITH and WITHOUT the Outlook Add-in and confirmed that the script results the correct results. I was then able to paste this script into the Detection Method for my application in SCCM.

Now I simply need to test my updated application to ensure that I get the desired results. To do this I deployed the application as ‘available’ to a collection containing my two test workstations, one with and one without and Outlook Add-in.

Monitoring the AppDiscovery.log I can then see that on my workstation without the Add-in the application is successfully detected, but on my workstation with the Add-in installed the application is not detected.

Clicking ‘Install’ forced the SCCM client to commence the installation of Symantec Endpoint Protection. Once complete the application is successfully detected.

Now I have tested the updated SCCM application I am now confident to deploy the application as Required to all of my workstations and complete the task.

Connecting SCCM to Upgrade Analytics

In my last post I detailed the process for deploying Upgrade Analytics and how to use SCCM to configure workstations to upload their telemetry data for processing in Upgrade Analytics.

Now we have this data available to us in Upgrade Analytics I am going to walk through the process of connecting SCCM to import the available Upgrade Analytics data back into the SCCM console. Doing so enables administrators to create SCCM collections based on the Upgrade Analytics data, and then in turn create deployments to remediate issues that have been identified with apps/drivers etc. that are currently blocking in-place upgrades of Windows 10 to the desired build.

Obviously a pre-requisite to following this guide is to have fully deployed Upgrade Analytics according to my previous blog post.

Create Azure AD Web Application

The first stage of connecting SCCM to our existing Upgrade Analytics instance is to create an Azure AD Web Application which will then, in turn, be used to grant SCCM read permissions to the instance.

Firstly, navigate to and logon with your Azure AD credentials. Then navigate to the exiting Azure Active Directory instance and select ‘App registrations’.

Now click ‘New Application Registration’ and complete the details as below:

  • Name – Free text but call this something easily identifiable
  • Application Type – Select Web app / API
  • Sign-on URL – Does not need to be a valid URL (as we won’t be redirecting users to this address), but must be in a valid URL format with http:// or https:// as a prefix

And click ‘Create’

The Application will then be created and the details presented in the console

Now click ‘Settings’ then ‘Keys’ to be prompted to create a new Key. Complete the name of a new key (maximum 16 characters) and select the length of duration for the key.

Click ‘Save’

Important – At this stage you will now be presented with the key in the form of a 43 character text string. I have deliberately not screenshotted my key, but this is the only time you will be able to read the key so ensure you copy this key now and store in a secure manner. Also, note the Expiry date (although this can be retrieved later).

Also collect the Application ID and App ID URL from the key properties screen.

Grant the New Application permissions to Upgrade Analytics

Now we have successfully created our Azure AD application we need to grant to the required permissions so it can access the data stored in Upgrade Analytics.

To perform this, within the Azure Portal browse to Resource Groups and select the Resource Group that contains the Upgrade Analytics solution

Under ‘Add a role assignment’ select ‘Add’ and complete the presented screen as below, then click ‘Save’.

Note: It is required to assign the permissions at the Resource Group level as later in the process SCCM will need to create a

Configuring SCCM to connect to Upgrade Analytics

Now we have created our new Azure AD app and granted it the correct permissions we are ready to connect SCCM to Upgrade Analytics.

In the SCCM Console browse to Administration-Cloud Services-Azure Services.

Then right-click on ‘Azure Services’ and select ‘Configure Azure Services’. Complete the presented wizard as shown below.

Then ensure ‘AzurePublicCloud’ is selected and click ‘Import’

You will then need to complete the presented screen with all of the details listed below and click ‘Verify’

  • Azure AD Tenant Name – Free text field but name it something easily identifiable
  • Azure AD Tennant ID – This is the directory ID of your Azure AD instance. This can be found by browsing the properties screen of Azure AD
  • Application Name – Free text field but name it something easily identifiable
  • Client ID – This is the App ID previously obtained
  • Secret Key – This is the Key previously obtained
  • Secret Key Expiry – Ensure the same date is selected as the key expires
  • APP ID URL – This is the previously collected value

Provided everything verifies successfully click ‘OK’ and then ‘Next’ in the wizard

Ensure that the correct Subscription, Resource Group and Windows Analytics workspace are selected and click ‘Next’

Review the settings and click ‘Next’

Once the wizard completes click ‘Close’. We can now see that the Upgrade Analytics Connecter is listed in Azure Services

Now if we switch to the Monitoring – Upgrade Readiness node in the SCCM console we can see the data is displayed

This completes the configuration of connecting SCCM to Upgrade Analytics

Deploying Microsoft Upgrade Analytics

Hi All, In todays post I am going to walk through the process of deploying Microsoft’s Azure/OMS solution named Upgrade Analytics. The purpose of Upgrade Analytics is to assist organisations with their planning process for in-place upgrades of Windows 10 builds through the review and remediation of all applications and drivers that are deployed within the existing fleet of workstations, either Windows 7, Windows 8/8.1 or an existing Windows 10 system.

Throughout this post I will be focusing on how to deploy Upgrade Readiness to existing workstations, the analysis of the information that is collected, processed and presented through Upgrade Analytics I will cover in a separate dedicated post at a later date.

Upgrade Analytics is a ‘solution’ that is provided by Microsoft that runs within a Operations Management Suite workspace which in turn runs on Azure. Therefore, for the purpose of the post it is assumed that there is an existing Azure tenant available, as well as a valid subscription (Upgrade Analytics is a free solution, but as with all Azure resources the OMS workspace we will create needs to reside within a subscription).

As Upgrade Analytics allows administrators to analyse large numbers of workstations I am going to assume that SCCM has also been deployed in the environment and is available for use.

OK, lets proceed with the deployment…

Phase 1 – Creating the Upgrade Analytics solution

Firstly, logon to your existing Azure Portal, and select the ‘Create a Resource’ option in the top left and search for ‘Upgrade Analytics’.

Here we can see the full description of Upgrade Analytics, review and select ‘Create’

We are now prompted for a log analytics workspace in which to create the Upgrade Analytics solution. Select ‘select a workspace’

As we can see there are no existing workspaces so I will select the option to ‘Create New Workspace’

We need to name the new Log Analytics workspace, select a suitable Subscription and Resource Group and click ‘OK’

After the workspace has completed deployment we can now click ‘Create’ to start the deployment of the Upgrade Analytics solution

Once the deployment has completed we can now verify that the solution existing by searching for ‘Solutions’ in the Microsoft Azure portal

Within the solutions blade we can see that the new Upgrade Analytics solution is now present and we can select it

Currently we can see that there are currently 0 systems currently uploading data to the new solution so we will now proceed with configuring workstations to upload data for analysis

Using SCCM to configure workstations to upload data

Now we have created the new solution we need to obtain our Commercial Id Key from the solution and then use SCCM Client Settings to configure this on existing workstations.

Within the new solution we need to select ‘Upgrade Readiness Settings’ and copy the Commercial Id Key that is displayed

Note: Also on this page I can change the version of Windows 10 we are assessing our workstations for upgrade to. This will need to be modified each time we are ready to start analysis for the next Windows 10 build

Now we need to switch to our SCCM console and browse to ‘Client Settings’

I do not want to deploy this configuration to my existing servers as I will not be assessing these for upgrade but I do want to deploy this to all existing workstations. To allow for this configuration I will create a new Client Settings Policy and give it the name of ‘All Windows Workstations – Upgrade Readiness’

It is now possible to configure the Windows Analytics component of the new client settings policy by enabling the management of telemetry settings, pasting our previously obtained Commercial Id Key, and I have selected to Enabled telemetry data from Windows 8.1 and earlier systems as I want to assess their readiness for upgrade to Windows 10. I have also allowed all Internet Explorer data uploaded as I want to analyse this data.

Click ‘OK’, and we now have out new policy ready for deployment

To deploy the new client settings policy simply right-click the new policy and chose ‘Deploy’. Then select the collection we want to deploy to, in this example I am going to be deploying to the ‘All Windows Workstations’ collection

Click ‘OK’ and we can now see that the client settings are deployed

This completes the required configuration within SCCM. We now need to wait for the following processes to complete:

  • SCCM clients to perform a policy refresh – Normally within 1 hour
  • Workstations to upload data to OMS – Normally within 1 day
  • Upgrade Analytics to process the data – Overnight each day

Verifying the deployment

2 days after configuring my workstations I again logged on to the Azure Portal and navigated to the Upgrade Analytics portal. Here I can now see that my test workstations have successfully uploaded data.

I am now in a position to start using Upgrade Analytics to plan for my upgrades to Windows 10 build 1809!!!

Deploying Office 365 client using Microsoft

Hi all,

In this post I am going to explain a solution I have designed to overcome a customer’s requirement to deploy Office 365 click-to-run client to its existing workstation fleet. The customer in question is a small organization with approximately- 160 workstations (a mixture of Windows 7 and Windows 10 and currently does not have application deployment tools in place, but is going to migrating to Office 365 and also have EM+S licensing.

Included in EM+S is Microsoft Intune, so the decision was made to deploy the InTune agent to all workstation in the domain which can then be used to deploy the Office 365 client.

This gives us the high level steps of :

  1. Deploy InTune client
  2. Create Office 365 package
  3. Deploy Office 365 using Intune


Deploy InTune client

To deploy the InTune client to all workstations we will be using a Group Policy Object as all the workstations are currently joined to an Active Directory domain. To achieve this the following steps will be undertaken :

  1. Logon to the Intune portal (
  2. Navigate to Admin -> Client Software DownloadIntune2.PNG
  3. Click on the option to ‘Download Client Software’ – this will download a 13Mb zip file
  4. Extract the client files to a local directory – c:\InTuneIntune3
  5. Extract the Microsoft_InTune_Setup.exe file using the command ‘c:\Intune\Microsoft_Intune_Setup.exe /extract c:\Intune’Intune4
  6. Copy Files to a suitable network share – exclude the original Microsoft_Intune_Setup.exe file, there is no need to retain this now we have extracted the contentsIntune5
  7. Open GPMC                                 Intune7.PNG
  8. Create a new GPO and link to Domain root levelIntune8
  9. Modify GPO to deploy InTune agent as a software installationIntune9.PNG
  10. Verify GPO is applied to clientIntune10.PNG
  11. Reboot client to initiate installation
  12. Track client installation logs in c:\program files\MicrosoftIntune19.PNG
  13. Verify workstation is registered in the Intune consoleIntune20


Create an Office 365 installation package

Now we have the Intune client deployed we have the ability to deploy .exe and .msi files to our workstations. I personally like to use the GitHub Office 365 ProPlus | Install Toolkit to create an installer for Office 365 as I find the interface simple and intuitive.

Here are the options I have chosen

  1. Create a new installerOffice 365.png
  2. Select the product options for deploymentOffice 365-2.png
  3. Choose the desired LanguagesOffice 365-3.png
  4. Choose the following optional settingsOffice 365-4.png
  5. Choose which products to exclude – Exclude products not licensed as it will prevent the software from being installedOffice 365-5.png
  6. Select which version of Office 365 you wish to installOffice 365-6.png
  7. Select which update channel to subscribe to for future updatesOffice 365-7.png
  8. Select the options you wish to deploy using – Note: Display level is not relevant when deploying through Intune as Intune only performs hidden deploymentsOffice 365-8
  9. Choose the wrapper options you wish to use – Note I am creating a .MSI fileOffice 365-9.png
  10. Clicking the generate button then produces a 2Mb file named OfficeProPlus.msi – Note: the size of this file is small as we chose not to include the source files. This was due to this customer having a fast internet connection and wishing to always install the latest Deferred Channel version. Also, deploying through Intune means that the source files would have to be transferred across the internet anyway resulting in the same file transfer requirements

I could now run this .msi installer on a workstation to verify the installation performs as required.


Deploy Office 365 using Intune

Now we have clients enrolled in our Intune tenant and a valid Office 365 installer we need to bring the two together to complete our solution. For this we will import our new .msi file as an application in Intune and then deploy to a test group to confirm functionality

  1. In the Intune portal navigate to Apps – Apps – Add App, the Microsoft Intune Software Publisher will then launch in a pop-out window. Unfortunately you will need to sign in again to this applicationIntune11.PNG
  2. Click next to begin the wizardIntune12.PNG
  3. Specify the location of your custom .msi fileIntune13.PNG
  4. Specify the details you would like to appear for end-users. Personally I like to use the Office 365 image to give a more professional lookIntune14
  5. Choose the requirements as desired, in this example I am not going to specify anyIntune15.PNG
  6. No need to provide any command line argumentsIntune16.PNG
  7. Review the details entered and click UploadIntune17
  8. Once the upload of the application has completed we need to deploy the application to our test system. As this is a lab I am simply going to deploy the app to all Staff but in a production environment you may want to limit this to a subset of users.
  9. Navigate to Apps – Apps and select ‘Office ProPlus Installer application’ we have just createdIntune21
  10. Select Manage Deployment to launch the deployment wizardIntune22
  11. Select the all staff collectionIntune23.PNG
  12. Click the Add button in the centre of the wizard and click nextIntune24.PNG
  13. Configure the deployment to be Required and As Soon As Possible and click finishIntune25.PNG
  14. Back on our test client I can either wait for the new policy to be downloaded or force a restart to expedite the process
  15. We can see the new policy downloaded in the *** log file
  16. The installation will then initiate, Office 365 logs its install tasks under c:\windows\temp so we can follow the installation
  17. Eventually we will then see that the office icons appear in the Start Menu on the system