One of the challenges of managing an email system in the cloud is knowing what best practices should be applied. If a tenant has E5 licenses, then an additional set of features are available to configure, name the Advance Threat Protection suite. Microsoft field techs have created a PowerShell module to help with assessing your configuration and recommending appropriate actions. This module is know as ORCA or Office [atp] Recommended Configuration Analyzer. We are provided with two versions of this module. One I would consider the Stable/tested version and the other is a Preview version if you want to be on the bleeding edge of the testing. Let’s start by reviewing these modules.
Preview vs Stable
One keen thing to be aware of with ORCA is that there are two different versions of the PowerShell module. There is the stable version and then there is a Preview version for testing. Which one you use is up to the operator, you. From testing so far I have not seen any issues with either, but your mileage may vary.
- Production (Stable) – https://www.powershellgallery.com/packages/ORCA
- Preview (Test) – https://www.powershellgallery.com/packages/ORCAPreview
How to Install
Like any other modern PowerShell module / modern PowerShell version, we can use the Install-Module cmdlet to install this new module on our computer:
ORCA or ORCAPreview. Sample syntax:
Install-Module -Name ORCA Install-Module -Name ORCAPreview
Once the install has completed, we can load the module again and run the module.
How to Update
Periodically this version of ORCA and ORCAPreview will increment as additional features and bug fixes are added. These PowerShell modules can be updated like any other PowerShell module that has been installed from a PSRepository:
Update-Module -Name ORCA Update-Module -Name ORCAPreview
Once the update has been performed, we can load the module again and run the module.
How to check your version vs what is available
** Note ** The below example will work for either the Preview or the Stable version of the module. Simply replace ORCAPreview with ORCA and run the cmdlets.
Let’s take for example that you currently have the 1.6.3 version of the ORCAPreview PowerShell module installed. At the time we may not have checked to see if there was a newer version and we do not have the page bookmarked to look at on the web. Luckily we can easily check to see if there is a newer version with two options:
Using What if:
Get-InstalledModule OrcaPreview | Update-Module -WhatIf
Which shows us this:
So we see that there is indeed a newer version. Which we did not upgrade to.
Or, just updating without the WhatIf:
Get-InstalledModule OrcaPreview | Update-Module
Which just updates the module:
Looks like it installed with no feedback? Let’s check:
Now what if we already had 1.6.5 installed? Would we get any feedback from either cmdlet?
Nope. So if you need to automate this and need a check in your script, use the WhatIf as it will at least provide some sort of feedback if checking for a new version. OR. Just update it every time the script runs and then load the module to make sure the latest version is available to the script.
How to Use ORCA
Between the Stable version and the Preview version there is only one difference and that is the cmdlet to run to execute the test. Keep in mind that each module only has ONE cmdlet. There are no other cmdlets included.
Stable and Preview:
Get-ORCAReport
If you execute this cmdlet AND you are not logged into any tenant, you will be asked for credentials and then the script will run through all of it’s checks:
Once the script is complete, a new HTML file will open up in your chosen browser:
As we can see from the top of the report, we have a total of recommendations as well as a total of best practices that are being followed. Take this list with a grain of salt. These are Microsoft’s general and broad recommendations. You do not have to do anything if you do not want to. While some are common sense, some may not be what your users would expect or want. Also displayed is the version of the ORCA module in use, the Office 365 tenant name and other summary information.
If you are running and old version, this should be displayed at the top:
And if you run the preview version, an additional box will be shown as well:
Scrolling down on the report, we will see each recommendation or best practice followed. All items are color coded for easy reading:
Summary table of current recommendations:
Reading through the list we see there are a lot of good recommendations and settings for a tenant. There are also settinga that are being deprecated, where this tool provides notifications of that change. In the case of my report, the tenant is unconfigured and soley for testing. Your own report will look vastly different and may have items that are flagged for change when in fact they are what you need for your own tenant.
Parameters and Switches for Get-ORCAReport
Now, since this is a custom module and custom cmdlet by Microsoft, we need to see if there are any parameters that are available, or does it kick off some automated process. First we can review available parameters for the cmdlet with a Ctrl+Space as show below:
OK. So we have NoConnect, NoUpdate, NoVErsionCheck, AlternateDNS and Collection. Let’s review each option:
NoConnect: If we already have an open connection to Exchange Online, we can use this option to prevent the cmdlet from opening that connection again.
NoUpdate: Prevents the script from exiting if its not up to date
NoVersionCheck:
AlternateDNS: Can specify different DNS servers than what the current computer has configured.
Collection: For processing a pre-created object collection
** Note ** In the examples section of the Get-Help for the cmdlet, we see that there is also a -Report parameter for specifying a report name. However, this parameters is not noted in either the Parameters section of the help, the Syntax or even shows when we try to display all available parameters. Nor does the option work or does it error out when specified. Could be a relic of previous programming for the module.
Cleanup
What if you have a computer where you were using ORCA / ORCAPreview for quite some time and wanted to remove older versions to prevent any confusion for you or your scripts? First, we would need to see what versions are available on the computer:
get-module -ListAvailable |where {$_.Name -like 'ORCA*'}
One a sample machine, I would see this:
Notice I have ORCA versions 0.3.2 and 1.6.3 as well as ORCAPreview versions 1.6.3 and 1.6.5. Also see the one cmdlet on the right for all of the modules. Now, how do we remove a specific module? We would need to specify the versions somehow with the Uninstall-Module cmdlet. But how? Let’s see what is available to us:
So we have Maximum and Minimum Version options. Minimum would work, but if we specify a very low version number, would we be initiating an uninstall for all module with a version number greater than that? So for ORCA if we specify 0.3.2, would it uninstall 0.3.2 AND 1.6.3? Better not take a chance. Our other option is MaximumVersion. We could then cap off where the uninstall process stops. So in our case we would need these two cmdlets:
Uninstall-Module ORCAPreview -MaximumVersion 1.6.3 Uninstall-Module ORCA -MaximumVersion 0.3.2
As always, be aware of your session and if you are running it as an Administrator as you may need elevated rights for some operations:
And once the cmdlets run properly, we see that there are only two versions left:
** Note ** For your operation, you may need one or more versions of a module installed. The above is just an exercise in cleaning up older versions if that is something that you would need to do.
Further Reading on ORCA
https://github.com/cammurray/orca
https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/recommended-settings-for-eop-and-office365-atp
