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.

Deploying Domain Controller using PowerShell on Windows Server Core

Hi All,

In this post I am going to walk you though a process I perform regularly when creating new domains for the purpose of testing, and occasionally in production environments. This procedure is going to be performed on Windows Server 2016 Core edition.

I normally choose Core edition for Domain Controllers as it reduces the overall footprint of the server by not having to run a GUI. This is perfect for Domain Controllers as not only do I want to reduce the possible security vulnerabilities on the server, but also after the DC has been deployed I will “never” need to log on to the server itself as all Active Directory management will be performed using Remote Server Admin Tools on remote server/workstations. On top of this its always nice to reduce the amount of CPU/RAM the server needs to run.

Note: For the purpose of this post we will assume that the server Operating System has already been deployed and network adaptors configured. I am using Windows Server 2016 Datacenter, but the process should be identical for all other versions and editions. Also, in this demo there is no existing Active Directory Domain deployed in the environment so we will be creating a new AD Forest, Domain and DNS whilst deploying this Domain Controller.


Installing the Active Directory features

When deploying Windows Server 2016 it does not include the necessary features to function as a Domain Controller. Therefore the first action we need to perform is to install the required feature. As this is process is being performed on Server Core we will need to do this from the command line/PowerShell.

Firstly, connect to the freshly built server using the local credentials supplied during deployment. This will open a Command Prompt window as shown below:


We then need to launch PowerShell by typing the command ‘PowerShell’:


Before installing the Active Directory feature on our server we first need to know the exact name of the feature. To get this we can simply run the cmdlet ‘Get-WindowsFeature’ which will list all of the available features, already installed and available for installation


Scrolling up we can find the Active Directory feature we are looking for ‘Active Directory Domain Services’. We can see by the lack of the X to the left that the feature is not currently installed, and can see in the ‘Name’ column the name of the feature is ‘AD-Domain-Services’.


We can now go ahead and install this feature by running the command ‘Install-WindowsFeature AD-Domain-Services’


Which then returns the following if successfulScreenshot-6

This completes the installation of the Active Directory Domain Controller feature on our server. We now need to configure the new Domain Controller…


Configuring Active Directory Domain Controller

Firstly, we need to ensure that the AD management module is imported to PowerShell so we can start our deployment. I will first check if the module is already imported by running the command ‘Get-Module’


We can see that the module is not currently imported so we will go ahead and import the module by running the command ‘Import-Module ADDSDeployment’


And run ‘Get-Module’ again to confirm that our import has completed successfully


We can see that the ADDSDeployment module is now listed

Now we are ready to actually execute our command to install and configure our new forest and domain. I will be configuring my new domain with the following attributes:

  • DNS Delegation – False
  • Database Path – C:\Windows\NTDS (Default)
  • Domain Mode – Server 2016
  • Domain Name –
  • NetBIOS Domain name – StingraySystems
  • Forest Mode – Server 2016
  • Install DNS – True
  • Log Path – C:\Windows\NTDS (Default)
  • Reboot on Completion – True
  • Sysvol Path – C:\Windows\SYSVOL

In order to apply all of these attributes during the creation of the Forest and Domain I therefore need o execute the following command – Install-ADDSForest -CreateDnsDelegation:$False -DatabasePath “C:\Windows\NTDS” -DomainMode “7” -DomainName “” -DomainNetbiosName “StingraySystems” -ForestMode “7” -InstallDns:$True -LogPath “C:\Windows\NTDS” -NoRebootOnCompletion:$False -SysvolPath “C:\Windows\SYSVOL” -Force:$True

Note: Obviously if you intend to run this command on your own server then please adjust the relevant attributes to match your own environment

I will then be prompted to enter (and confirm) the Safe Mode Administrator password for the domain. Enter these and press enter to start the installation of the forest and domain


After a few mins the server will then restart as we had told it this was OK to proceed in the command


Once the server completes its restart it is possible to logon to the server again but this time we must use domain credentials as all local accounts will be removed during the promotion to a Domain Controller.

Note: The account used to execute the Domain Controller installation on the first Domain Controller in the domain is automatically converted to a domain account and made a member of the Domain Admins security group so this account can be used for logging on to the server.

And that completes the installation of the Domain Controller on Windows Server Core. We are now ready to start using the domain.

If you have any questions or feedback on this guide please feel free to leave a comment below…