Azure Policy: Your Enterprise Azure Resource Guardrails!

Introduction:

There are numerous conversations surrounding Azure Policy. This post will provide information to accompany those conversations. This post will be a living and constantly modified document throughout the product development.

Post Purpose:

The purpose of this document is to explain the following:

  1. What is Azure Policy

Intended Audience:

The intended audience will be Azure Cloud Engineers and Azure Cloud Security Engineers as well as any other related parties who need information and overview of Azure Policies as part of the overall security governance process of your organization.

What is Azure Policy

Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements. Azure Policy meets this need by evaluating your resources for non-compliance with assigned policies. For example, you can have a policy to allow only a certain inbound and outbound rule within a Network Security Group (NSG). Once this policy is implemented, new and existing resources are evaluated for compliance. With the right type of policy, existing resources can be brought into compliance. Later in this documentation, we'll go over more details on how to create and implement policies with Azure Policy as well as different Effect Types.

  • Effect Types - Azure Policy

This section will contain information on the different Effect Types that are associated with Azure Policy. Effect Types are exactly what is sounds like, a determined effect that will occur on a resource based on conditions of the Azure Policy. For example, you could have an Effect Type of ‘Deny’ that will disallow resources from being created based on conditions present in your Policy Definition (e.g. Resources are deployed in the improper Azure Region).

The subsections below will dive into a bit more detail, with practical use cases for each Effect Type.

  • Deny

Whenever a Policy has an Effect Type of ‘Deny’ any new resource that gets created that goes against the conditions defined within the Policy Definition, that deployment of such resources will be denied from creation.

Deny evaluation

When creating or updating a matched resource, deny prevents the request before being sent to the Resource Provider. The request is returned as a 403 (Forbidden). In the portal, the Forbidden can be viewed as a status on the deployment that was prevented by the policy assignment.

During evaluation of existing resources, resources that match a deny policy definition are marked as non-compliant.

Example: If a AZURE Cloud Engineer spins up a new Virtual Network, and attaches an NSG that have default Internet outbound rules, the Engineer will be denied resource creation due to Policy disallowing such actions.

  • Append

Append is used to add additional fields to the requested resource during creation or update.

Append evaluation

Append evaluates before the request gets processed by a Resource Provider during the creation or updating of a resource. Append adds fields to the resource when the if condition of the policy rule is met. If the append effect would override a value in the original request with a different value, then it acts as a deny effect and rejects the request. To append a new value to an existing array, use the [*] version of the alias.

When a policy definition using the append effect is run as part of an evaluation cycle, it doesn't make changes to resources that already exist. Instead, it marks any resource that meets the if condition as non-compliant.

Example: If an AZURE Cloud Engineer forgets to add a required Tag to a resource, upon creation and evaluation, that Tag will be added to the resource automatically.

  • Audit

Audit is used to create a warning event in the activity log when evaluating a non-compliant resource, but it doesn't stop the request.

Audit evaluation

Audit is the last effect checked by Azure Policy during the creation or update of a resource. Azure Policy then sends the resource to the Resource Provider. Audit works the same for a resource request and an evaluation cycle. Azure Policy adds a Microsoft.Authorization/policies/audit/action operation to the activity log and marks the resource as non-compliant.

Example:

If AZURE Cloud Engineer wanted to see how many resources are non-compliant against a condition within a Policy Definition, the engineer can use ‘Audit’ to get a gauge of compliance, evaluate, review, and plan for compliance remediation.

  • AuditIfNotExist

AuditIfNotExist enables auditing on resources that match the if condition, but doesn't have the components specified in the details of the then condition.

AuditIfNotExist evaluation

AuditIfNotExist runs after a Resource Provider has handled a create or update resource request and has returned a success status code. The audit occurs if there are no related resources or if the resources defined by ExistenceCondition don't evaluate to true. Azure Policy adds a Microsoft.Authorization/policies/audit/action operation to the activity log the same way as the audit effect. When triggered, the resource that satisfied the if condition is the resource that is marked as non-compliant.

AuditIfNotExists properties

The details property of the AuditIfNotExists effects has all the subproperties that define the related resources to match.

  • Type [required]
    • Specifies the type of the related resource to match.
    • If details.type is a resource type underneath the if condition resource, the policy queries for resources of this type within the scope of the evaluated resource. Otherwise, policy queries within the same resource group as the evaluated resource.
  • Name (optional)
    • Specifies the exact name of the resource to match and causes the policy to fetch one specific resource instead of all resources of the specified type.
    • When the condition values for if.field.type and then.details.type match, then Name becomes required and must be [field('name')]. However, an audit effect should be considered instead.
  • ResourceGroupName (optional)
    • Allows the matching of the related resource to come from a different resource group.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • Default is the if condition resource's resource group.
  • ExistenceScope (optional)
    • Allowed values are Subscription and ResourceGroup.
    • Sets the scope of where to fetch the related resource to match from.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • For ResourceGroup, would limit to the if condition resource's resource group or the resource group specified in ResourceGroupName.
    • For Subscription, queries the entire subscription for the related resource.
    • Default is ResourceGroup.
  • ExistenceCondition (optional)
    • If not specified, any related resource of type satisfies the effect and doesn't trigger the audit.
    • Uses the same language as the policy rule for the if condition, but is evaluated against each related resource individually.
    • If any matching related resource evaluates to true, the effect is satisfied and doesn't trigger the audit.
    • Can use [field()] to check equivalence with values in the if condition.
    • For example, could be used to validate that the parent resource (in the if condition) is in the same resource location as the matching related resource.

AuditIfNotExists Example:

Azure Policy evaluates Customer’s Azure Virtual Machines to determine if the Antimalware extension exists then audits when missing.

  • DeployIfNotExist

Similar to AuditIfNotExists, DeployIfNotExists executes a template deployment when the condition is met. This will trigger essentially ‘remediation’ upon the Azure resource to bring it into compliance based upon the Policy conditions.

DeployIfNotExists evaluation

DeployIfNotExists runs after a Resource Provider has handled a create or update resource request and has returned a success status code. A template deployment occurs if there are no related resources or if the resources defined by ExistenceCondition don't evaluate to true.

During an evaluation cycle, policy definitions with a DeployIfNotExists effect that match resources are marked as non-compliant, but no action is taken on that resource.

DeployIfNotExists properties

The details property of the DeployIfNotExists effects has all the subproperties that define the related resources to match and the template deployment to execute.

  • Type [required]
    • Specifies the type of the related resource to match.
    • Starts by trying to fetch a resource underneath the if condition resource, then queries within the same resource group as the if condition resource.
  • Name (optional)
    • Specifies the exact name of the resource to match and causes the policy to fetch one specific resource instead of all resources of the specified type.
    • When the condition values for if.field.type and then.details.type match, then Name becomes required and must be [field('name')].
  • ResourceGroupName (optional)
    • Allows the matching of the related resource to come from a different resource group.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • Default is the if condition resource's resource group.
    • If a template deployment is executed, it's deployed in the resource group of this value.
  • ExistenceScope (optional)
    • Allowed values are Subscription and ResourceGroup.
    • Sets the scope of where to fetch the related resource to match from.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • For ResourceGroup, would limit to the if condition resource's resource group or the resource group specified in ResourceGroupName.
    • For Subscription, queries the entire subscription for the related resource.
    • Default is ResourceGroup.
  • ExistenceCondition (optional)
    • If not specified, any related resource of type satisfies the effect and doesn't trigger the deployment.
    • Uses the same language as the policy rule for the if condition, but is evaluated against each related resource individually.
    • If any matching related resource evaluates to true, the effect is satisfied and doesn't trigger the deployment.
    • Can use [field()] to check equivalence with values in the if condition.
    • For example, could be used to validate that the parent resource (in the if condition) is in the same resource location as the matching related resource.
  • roleDefinitionIds [required]
    • This property must include an array of strings that match role-based access control role ID accessible by the subscription. You can consider this part of the ‘remediation’ part of Azure Policy.
  • DeploymentScope (optional)
    • Allowed values are Subscription and ResourceGroup.
    • Sets the type of deployment to be triggered. Subscriptionindicates a deployment at the subscription level, ResourceGroupindicates a deployment to a resource group.
    • location property must be specified in the Deploymentwhen using subscription level deployments.
    • Default is ResourceGroup.
  • Deployment [required]
    • This property should include the full template deployment as it would be passed to the Microsoft.Resources/deploymentsPUT API.

DeployIfNotExists example

Azure Policy evaluates SQL Server databases within Customer’s Azure subscriptions to determine if transparentDataEncryption (TDE) is enabled. If not, then a deployment to enable is executed.

  • Order of Evaluation

Requests to create or update a resource through Azure Resource Manager are evaluated by Azure Policy first. Azure Policy creates a list of all assignments that apply to the resource and then evaluates the resource against each definition. Azure Policy processes several of the effects before handing the request to the appropriate Resource Provider. Doing so prevents unnecessary processing by a Resource Provider when a resource doesn't meet the designed governance controls of Azure Policy.

 

Disabled is checked first to determine if the policy rule should be evaluated.

Append is then evaluated. Since append could alter the request, a change made by append may prevent an audit or deny effect from triggering.

Deny is then evaluated. By evaluating deny before audit, double logging of an undesired resource is prevented.

Audit is then evaluated before the request going to the Resource Provider.

After the Resource Provider returns a success code, AuditIfNotExists and DeployIfNotExists evaluate to determine if additional compliance logging or action is required.

 

  • Mode Types – Azure Policy

Mode Types are available for Azure Policy. There are two modes, ‘All’ and ‘Indexed’. We recommend you set the mode to ‘All’ in most cases. You should use ‘Indexed’ when creating Policies that enforce Tags or Resource Location.

  • Indexed

Indexed Mode only evaluates resource types that support Tags and Location. Indexed should be used when creating policies that enforce tags or locations. While not required, it prevents resources that don't support tags and locations from showing up as non-compliant in the compliance results. The exception is resource groups. Policies that enforce location or tags on a resource group should set mode to all.

  • All

All Mode evaluates resource groups and all resource types. All policy definitions created through the portal use the all mode. If you use PowerShell or Azure CLI, you can specify the mode parameter manually. If the policy definition doesn't include a mode value, it defaults to all in Azure PowerShell and to null in Azure CLI.

Managing Windows 10 with Intune – AutoPilot Reset

Managing Windows 10 with Intune – AutoPilot Reset

Playing with the AutoPilot Reset and essentially refreshing my home laptops over and over, I thought why not just document and share it. I’m coming at this from a “Devices already managed” approach, so I did not pre-register my hardware ID’s for the full white glove experience.

Starting out, I created some device compliance policies that look for how BitLocker and Windows Defender are configured.

Then created my Device Configuration Profiles for BitLocker and the MDATP on-boarding package.

A screenshot of a cell phone screen with text

Description automatically generated

I also decided to test out one of the newer features in Intune, Security Baselines. Windows 10 Security Baselines have made managing device security much easier. They’re bundled configuration settings recommended by Microsoft based on its own security engineers as well as the community. Docs link below.

https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-security-baselines

A screenshot of a cell phone screen with text

Description automatically generated

Here I have some apps that I’d like installed by default.

For this test I’m using a Self-Deploying autopilot profile for my Deployment Mode.

Once I have all my policies and profiles created, I can trigger the AutoPilot reset, notifying the end user that they’ll be logged off.

A screenshot of a cell phone screen with text

Description automatically generated

And away we go with some high definition pictures:

A screen shot of a computer

Description automatically generated

A screen shot of a computer

Description automatically generated

A close up of a computer screen

Description automatically generated

A screen shot of a monitor

Description automatically generated

A screen shot of a computer

Description automatically generated

Once all that is complete, I login and get presented a nice clean device with my basic apps already loaded.

Here I can see the clean slate of apps I’m starting with.

And that’s it, a nice easy way to refresh your machines.

A screenshot of a computer screen

Description automatically generated

Azure Security Center : Playbooks!

Azure Security Center Playbooks

First off, what is a Playbook in Azure Security Center (ASC)? A Security Playbook is a pre-established and scripted set of actions that can be taken in the event of a specific alert within your Azure tenant (think of System Center Orchestrator Runbooks, but for Azure, aimed towards increased Security for your subscription). Security Playbooks are intended to provide additional security for your cloud resources.

Security Playbooks are built on Azure Logic Apps (https://azure.microsoft.com/en-us/services/logic-apps/). There is a multitude of options within Logic Apps, including built-in templates, and ones you can create blank for security personalization. Keep in mind that due to the fact these are based on another set of technologies within Azure, that means a cost will be associated with each Logic App and triggers (https://azure.microsoft.com/en-us/pricing/details/logic-apps/).

So, this all sounds great, right? You might be wondering what would a real-life example look like for your organization? Here’s a thought: Let’s say Security Center recognizes that on a handful of Azure IaaS resources, have suspicious SVCHOST processes being executed, this is triggered due to the intelligence built into ASC with knowledge that a lot of times Malware tends to use SVCHOST to mask it’s malicious activity. What happens? Alert is triggered, and a Playbook is automatically executed to act on conditions or actions configured by your organization security administrators (e.g. Post a message in Teams, send an Email, run a script, etc.) I bet you want to know how to do this. Here we go:

Creating your first Security Playbook

To create your first Security Playbook, you need to log into the Azure portal and navigate to the Security Center as shown below.

In the Security Center Playbooks are at the bottom of the menu on the left under “Automation & Orchestration.” (this might change upon GA release)

Creating a Playbook is quite simple. All you need to do is click “Add Playbook” button at the top of the interface.

This will take you through a quick wizard, that most of you are now already accustomed to within the Azure Portal. You’ll be asked to name your Playbook, and to put it into a Resource Group (an existing RG or allowing you to create a new RG for this Playbook). Notice you’ll also have the option to turn on Log Analytics, this requires an appropriate workspace to already be previously created for the data to flow into. (optional).

One thing to note, for future automation is that for most resources in Azure (Playbooks included), you’ll have “Automation Options”. This will take you to a JSON editor that shows you the ‘under the hood’ code that you can then pipe into an Azure Resource Manager (ARM) template. Keep this in mind as you expand your Azure footprint.

Configuring a Security Playbook

Once you’ve gone through the wizard to create your Playbook, you’ll see them listed in a manner like below. Keep a close eye on the “Trigger Kind”, we will dig deeper into this later.

Essentially right now you have a blank slate, so let’s dive deeper here. You can start by clicking the name of your Playbook, and it’ll take you into the details of that Playbook (see below).

You will have a plethora of options to choose from when designing your Playbook, I will go into further detail on “Blank Logic App” creation in another document as there are over 290 unique settings, triggers and actions that can be leveraged in your organization if required. One thing to remember, The Logic App Designer is built on a “if this happens, then do that” type of flow (just like Orchestrator from System Center).

When you first launch the Logic App Designer on a new Playbook you are shown the below wizard.

For this example and document, I am going to choose one of the preconfigured templates: “Post message to Teams channel and send email notification”.

The first step before moving on is signing into the services below (in this case Office 365 and Teams). Once you successfully sign in and allow permissions for this Playbook, you’ll be able to continue.

 In this basic example, the Playbook template will send a recipient a notification when Security Center Alerts are generated. It’ll (based on your configuration) send an email for low priority alerts, and for high priority alerts notify the Teams site. All of the settings mentioned are configurable to your organization testing standards as needed.

In case you’re curious on how many potential actions are available in Playbooks, I scrolled down and selected “Add a step” and choose an “Add an action”. This gave me a chooser with 290 separate actions I can add to this Playbook.

As a next step, begin testing and working with Playbooks. Sometimes it’ll take a bit to firmly grasp the amazing opportunities and automation this presents your organization, but I implore you to dig deep! If you’d like some templates / starter kits, I’ve provided some links below!

Helpful Starting Points (Playbook Starter Kits):

Virus attack playbookhttps://aka.ms/ASCPlaybooksVAttack – deploys 2 virtual machines, OMS and associated network resources. One of the VM is deployed without endpoint protection

SQL Injection playbookhttps://aka.ms/ASCPlaybooksSQLi – deploys 2 application gateway, a web app and SQL server and database and OMS

XSS (cross site scripting) attackhttps://aka.ms/ASCPlaybooksXSS – deploys 2 application gateway, a web app and SQL server and database and OMS

DDoS protectionhttps://aka.ms/ASCPlaybooksDDos – deploys a virtual machine an associated network resources (including public IP address) and OMS

Additional Links:

  1. Hunting Threats: https://gallery.technet.microsoft.com/Azure-Security-Center-549aa7a4
  2. Microsoft Docs: https://docs.microsoft.com/en-us/azure/security-center/security-center-playbooks

Deploy SQL CU w/ rollback package

Had to write something up for a customer, so I thought I’d share that. Nothing mind blowing here, just the simple process of deploying a CU for SQL 2016 SP1 with an uninstall package to showcase the roll back of said CU. The customers DBA team was looking to see how they could leverage SCCM for this. Yes, there are numerous ways to do this, everyone has their method, this was mine. Quick and easy.

The starting point in the demo, was SQL 2016 SP1 CU7. The end goal, SQL 2016 SP1 CU13.

First things first, make sure you’re syncing SQL updates for your specific platform, in this case I needed 2016 so I checked that box on my SUP to pull them down.

From Software Library, Overview > Software Updates > All Software Updates, search out the CU you’re looking to deploy. Select it and “Create Software Update Group” (SUG).

Once you create the SUG go ahead and deploy it out.

From one of the machines you deployed it to, go ahead and open up Software Center and kick off the install.

Once that installs and comes back from a reboot, we’ll check the version again for good measure. As we can see below, we’re now at CU13.

Let’s say for some reason this breaks the application (as if that would ever happen) and we need to roll the CU back. If we peek at the article listed below, we’ll see that there is a specific command line to run for this. https://docs.microsoft.com/installing-SQLupdates-from-the-command-prompt

In this case we want to create a slightly custom command line, using the /AllInstances switch on the /Action=RemovePatch

Just replace the <package_name>.exe with the CU package name your deploying.

.\SQLServer2016-KB4475775-x64.exe /qs /Action=RemovePatch /AllInstances

I went ahead and created a Standard Program, specified my source files which included the same CU .exe and script that runs the command line from above.

Specified my command line with “powershell.exe -File uninstall.ps1” as such:

Deployed it. Checked Software Center on the same test machine, and kicked it off.

That’ll take just a minute or two, and voilà, all done. Back to CU7.

Like LeeLo from The Fifth Element said, Bada Boom!

ConfigMgr Cloud Management Gateway!

Good day everyone! Recently I spoke at Microsoft Tech Talk - Dallas on this topic, and I wanted to put together a quick informative post on some of the prerequisite steps along with implementation steps necessary to deploy the SCCM Cloud Management Gateway! This is an amazing feature that is truly a new way to manage your internet clients in your enterprise.

Certificate verification

Create:

  1. SCCM IIS Certificate
  2. SCCM Client Certificate
  3. SCCM CMG Certificate (same as IIS cert, but private key is exportable)
  4. SCCM OSD Certificate (same as client auth, but exportable)

Request:

  1. On Primary Site Request Client, IIS, OSD, and CMG certificates.
    1. SCCM IIS Cert Request (common name in request) short and FQDN
    2. SCCM OSD Cert Request (common name in request) short and FQDN
    3. SCCM CMG Cert request Unique (common name) must be specified when requesting SCCM CMG Certificate (example: cloudapp.net)
  2. GPO for autoenrollment for client certificates

Export:

  1. Root Cert to file
  2. Intermediate Cert to file (if present)
  3. SCCM CMG Certificate with password
  4. SCCM OSD Certificate with password

Azure Subscription & Permissions

  1. Login to portal.azure.com – identify subscription, verify permissions. We prefer this is done via a service account, however that service account needs to have temporary subscription ownership for us to continue.

PKI SCCM Changes and log verification process

  1. MP – IIS and console (mpsetup.log, mpcontrol.log)
  2. SUP – IIS and console (wcm.log) please refer to SSL in WSUS and SUP
  3. DP (workstation cert (SCCM OSD Certificate) in console)
  4. Site and Hierarchy Settings (HTTP or HTTPS, deselect CRL, use PKI when available)

Azure services wizard in console

Detailed steps:

As with most configurations for SCCM, we are going to start in the ConfigMan console.

  • In the ConfigMgr Console, go to Administration > Cloud Services > Azure Services.
  • Click Configure Azure Services on the ribbon menu.
  • Select Cloud Management in the Wizard.
  • Provide a Name and click Next to proceed.
  • Click on Browse to either Import an existing App or click Create to start with a fresh App.
  • You need to Sign in with a Subscription Admin/Owner.

Follow the steps for both Web and Client App to proceed with the wizard.

Click Next, Enable Azure AD User discovery is not required for CMG and is optional if you'd like to check it and finish the wizard.

Azure app registration modifications

Within the Azure Portal, we need to navigate to App Registrations:

We will hopefully find both our Server and Client API Apps that we created in the previous SCCM Console Wizards like below:

Click each of the app registrations, and navigate to the settings option like below:

We need to then modify permissions so that we can continue on with the actual creation of the Cloud Management Gateway with no issues. Please modify like below (we will need to do this on both Client app and the Server app):

Cloud management gateway creation

  • On the ConfigMgr Console, go to Administration > Cloud Services > Cloud Management Gateway
  • Click Create Cloud Management Gateway on the ribbon menu and Sign In with Azure Subscription Admin account
  • The subscription info and the Web App created in Section 3 will auto populate. Click Next to proceed.

 

  • Click Browse to specify the SCCM CMG Certificate (same as IIS but with the exportable private key and password) This will auto populate the Service name.
  • Choose your Azure Region
  • Choose Create new under Resource Group.
  • Add the Client Trusted Root Certificate from section 1.1
    • If you have an intermediate CA, please complete the chain of trust, by “Add” again.
  • Verify Client Certificate Revocation checkbox [Clear this only if you haven't published the CRL on internet.]
  • Click Next to finish the Wizard.

The deployment in Azure begins -

CloudMgr.log will show the details of the CMG deployment. Below are a few key points of the process that we are looking for log-wise.

Resource Manager - Creating resource group cmgarm with location South Central US        SMS_CLOUD_SERVICES_MANAGER        3/27/2018 6:02:27 PM        3140 (0x0C44)

 

Resource Manager - Resource group cmgarm created        SMS_CLOUD_SERVICES_MANAGER        3/27/2018 6:02:28 PM        3140 (0x0C44)

 

Resource Manager - Creating cloud service cmgarm with deployment CreateCloudServiceba0f51cf-SMS_CLOUD_SERVICES_MANAGER        3/27/2018 6:02:28 PM        3140 (0x0C44)

 

Resource Manager - Creating storage service cmgarm with deployment CreateStorageService7cabb6ec-SMS_CLOUD_SERVICES_MANAGER        3/27/2018 6:02:45 PM        3140 (0x0C44)

 

Uploading file C:\Program Files\Microsoft Configuration Manager\inboxes\cloudmgr.box\CloudProxyService.cspkg to container deploymentcontainer with blob name cmgarm.cspkg in storage account cmgarm        SMS_CLOUD_SERVICES_MANAGER        3/27/2018 6:08:44 PM        3140 (0x0C44)

Log in to the Azure Console to view the resources

Validate the status Ready from ConfigMgr console.

Cloud management gateway connector point creation

We must now go ahead and configure the Cloud Management Gateway Connector Point. You can think of this as a secure tunnel that’s connecting authenticated requests through your CMG, down to your on-premise hierarchy, specifically your management point and software update point(s)..

Steps:

  • Add new site system role and choose Cloud Management Gateway connection point
  • Validate the Gateway name we just created and the Region to finish the wizard.

The Connection Point server will show as associated in the console. For troubleshooting this component, you can check SMS_Cloud_ProxyConnector.log.

SUP and MP changes to accept CMG traffic

Within the console we must modify properties of the designated MP’s and SUP’s that your business organization has chosen to accept Cloud Management Gateway Traffic for your internet clients.

  • On the Management Point Properties, check the box Allow Configuration Manager cloud management gateway traffic
  • Follow the same steps for Software Update Point.

Ensure and enable content hosting on CMG (this is new to 1806+)

Starting with 1806, the product group modified the behavior and administration of cloud content. Historically you had to provision a Cloud Distribution Point for content, now all of that can be hosted on your CMG (go to properties of CMG):

Test functionality

We must modify our Default Client Settings, or the Client Settings deployed to our test collection of machines to ensure that we have CMG options enabled. Upon confirmation, we can either initiate a machine policy download, or simply restart the SMS Agent Host for quicker results.

The client machines will receive CMG connection info which can be verified by the following registry key – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Internet Facing

 

On a test client outside corporate network, check CCMMessaging.log to validate a successful communication with CMG

Additional testing methods

You can force the client to always use the CMG regardless of whether it’s on the intranet or internet. This configuration is useful for testing purposes, or for clients at remote offices that you want to force to use the CMG. Set the following registry key on the client:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Security, ClientAlwaysOnInternet = 1

Verify that the client is on Internet through the Configuration Manager applet in the control panel:

And run following PowerShell line to verify that the CMG is available as Internet management point:

PowerShell:

Get-WmiObject -Namespace Root\Ccm\LocationServices -Class SMS_ActiveMPCandidate | Where-Object {$_.Type -eq "Internet"}

SCCM Managed Office 365 Clients, Versioning

A topic I’ve been asked about often the last few weeks has been around Office 365 Client versioning, more specifically when being managed with SCCM. Ensuring Office 365 Clients are properly set to be managed via SCCM is important for consistent versioning results.

A few cross checks first, make sure your site is set to pull Office 365 Client updates down:

cid:image005.jpg@01D42A62.0E158540

Make sure you have the highlighted field below set to “Yes”, that will ensure Configuration manager is able to update the clients as defined (hopefully) in their configuration when deployed\installed. This is assuming those clients are set to use SCCM as their point of contact for updates which we’ll cover in this blog.

cid:image006.jpg@01D42A62.0E158540

cid:image008.jpg@01D42A62.0E158540

When you’re creating the configuration.xml for your Office 365 deployment, make sure it contains the below highlighted segment, this will ensure the client knows who to talk to for updates.

Another note, if you want your users to see that there are updates pending, add the <Updates Enabled=”True” /> portion. As you can imagine, when set to False, clients still receive updates from SCCM, but end users will not see any pending update notifications.

See https://docs.microsoft.com/end-user-update-notifications-for-office-365-proplus for more information on update notifications.

Requirements for SCCM to manage Office 365 Client Updates:

  • System Center Configuration Manager, update 1602 or later
  • An Office 365 client – Office 365 ProPlus, Visio Pro for Office 365, Project Online Desktop Client, or Office 365 Business
  • Supported channel version for Office 365 client. For more details, see Release information for updates to Office 365 ProPlus
  • Windows Server Update Services (WSUS) 4.0 You can’t use WSUS by itself to deploy these updates. You need to use WSUS in conjunction with Configuration Manager
  • The hierarchy’s top level WSUS server and the top-level Configuration Manager site server must have internet access.
  • On the computers that have the Office 365 client installed, the Office COM object is enabled.

Let’s get some perspective on client versioning in an environment now. Check under ”Software Library > Office 365 Client Management” to see where your versioning stands.

A lot of what’s expected here should be dependent on what testing you may have in place. Do you have a test group on monthly? Who might be on Semi-annual? Don’t be caught off-guard to see something like what’s depicted further below.

cid:image013.jpg@01D42A62.0E158540 cid:image018.jpg@01D42A62.0E158540

If the expectation would be for all clients to be on “Semi-annual Chanel”, and all version numbers to be some variant of 1803 which would be build 9126, or 16.0.9126.XXXX, then we have some things to dig into. (Office Pro Plus Versions by Date)

Here is the expected behavior when devices are correctly set to be managed by SCCM:

“When Microsoft publishes a new Office 365 client update to the Office Content Delivery Network (CDN), Microsoft simultaneously publishes an update package to Windows Server Update Services (WSUS). Then, Configuration Manager synchronizes the Office 365 client update from the WSUS catalog to the site server. Configuration Manager can then download the update and distribute it to distribution points selected by the administrator. The Configuration Manager desktop client then tells the Office client where to get the update and when to start the update installation process.”

I stress the above bolded area as it is vital to ensure the clients are set to use SCCM properly.

If you feel that most of what has been covered so far remains true for you, the most likely culprit is probably still some mixture of inconsistent settings. Good news though, there are a few easy ways we can make sure we have the client settings set correctly where needed.

The Microsoft preferred method for computers that have already had Office Pro Plus deployed, would be the Group Policy option.

GPO Option – https://docs.microsoft.com/en-us/deployoffice/configure-update-settings-for-office-365-proplus#use-group-policy-to-configure-update-settings-for-office-365-proplus

The other option, and frankly the “Cooler” one, is the PowerShell option. See the following for the PowerShell Option – https://blogs.technet.microsoft.com/odsupport/2017/05/10/how-to-switch-channels-for-office-2016-proplus/

That should be a great start and hopefully answers a lot of the basic questions around getting Office 365 Client versioning in order. Please comment with any comments, questions, or anything I may have missed! After all, that is the purpose of being a community : )

 

Hyper-V Baseline Change – AutomaticStopAction

Was recently asked by a customer to make a global Hyper-V change on VM’s having the wrong AutomaticStopAction setting, across many HV Hosts. My tool of choice, SCCM Baseline! (Yes, SCVMM is a better option here, but that’s not an option in their environment…)

To familiarize everyone, this is what we are changing:

Let’s hop over to PowerShell and get familiar with the cmdlets needed for this. Let’s check the value first:

$(Get-VM -Name HYD-CLIENT1).AutomaticStopAction

For what’s it worth, running just $(Get-VM).AutomaticStopAction will return the state for all VM’s on the host.

Good source for Hyper-V cmdlets : https://docs.microsoft.com/powershell/module/hyper-v

Create and name the baseline, we’ll come back to it later:

Go ahead and create a new configuration item, name it, platforms you want to limit it to, etc. We’ll focus primarily on the “Settings” and “Compliance Rules”:

For “Setting type” and “Data type”, we’ll choose Script and String as shown below:

Since we know what value we want and how to grab that, we’ll use that for our “Discovery Script”:

And as you may have guessed, we’ll use the Set version of that cmdlet to ensure the desired value is set:

Get-VM | Stop-VM;Get-VM | Set-VM -AutomaticStopAction ShutDown;Get-VM | Start-VM

Now choose the “Compliance Rules” tab, this can also be accessed from the main properties window shown below this. Double click or highlight and:

Here we are defining the conditions for a machine to report as compliant when measured against this baseline, make sure you check the box to “Run the specified remediation script when this setting is noncompliant”:

That’s it for the configuration item!

Last step, head back to the Configuration Baseline and add the configuration item we just created, by adding it to the “Evaluation Conditions” as shown below:

Filter the list to find the newly created item, select it and click “Add”:

Choose “OK” and you’re done!

Please comment with any questions about this procedure or any general baseline questions, we’re here to help!

 

July 2018 Windows Patches – Stop 0xd1 Errors

Patch Scenarios

Microsoft has released a solution for the Stop 0xd1 errors that some customers encountered after the July 10th update release. The offering of Windows updates released on July 10th will resume.

Suggested actions for customers:

  • Customers who have previously deployed Windows updates released on July 10 and did not encounter any Stop 0x1d errors have no new action to take.
  • Customers who did not install Windows updates released on July 10 are encouraged to apply the original updates released on July 10, and monitors for Stop 0x1d errors.
  • Only customers who encounter a Stop 0xd1 error after installing Windows updates released on July 10 are encouraged to install one of the following update packages to resolve the Stop 0x1d symptom:
    • Windows 10 v1803: KB4345421
    • Windows 10 v1709: KB4345420
    • Windows 10 v1703: KB4345419
    • Windows 8.1 and Windows Server 2012 R2 (Standalone rollup): KB4345424
    • Windows Server 2012 (Standalone rollup) KB4345425
    • Windows 7 and Windows Server 2008 R2 (Standalone rollup) KB4345459
Patching Steps

If you have already performed the below steps of rolling back the July Cumulative Updates (CU), you will need to resinstall the CU before installing the new patch.

Starting from having to install the July CU again, we’ll do the following:

From the Configuration manger app, run:

Choose “Install All”:

Since I deployed this patch as available, you can see the client had to download the patch, rather then it being downloaded already, waiting for a MW. The reason I made it available is because not ever server needed the fix, and it was easier to just have it offered to the admins if they needed it.

Post installation reboot required:

Once both patches are installed, well see the folllowing:

If you still have the CU installed and are experiencing the issues decribed in this article, install just the additional patch:

Rinse and repeat for your specific OS version.

*Please note this patch will require a reboot in most cases.*

 

Custom Reports 101 – An Example from the Real World – Report on Software Updates in a Software Update Group

Custom Reports 101 – An Example from the Real World – Report on Software Updates in a Software Update Group.

Good day everyone, my name is Trevor Stuart. I am one of the authors and operational leads of moderncloudmanagement.com. Today I wanted to share a post on a real-world client request that came my way. To shed a little background, I am a typical Tech Guy– specializing in SCCM (12+ years), Windows 10 (RTM +), Azure (5+ years), and Cyber Security (learning and loving it). I work alongside Joe Anich (the original author and operational lead of moderncloudmanagement.com) daily for this customer.

Scenario:

Whilst I was on my way out for the evening, the manager I report to for this particular customer asked if I was able to create a custom report that quickly showed all software updates that were in a particular software update group – group it, and highlight the ones that have been modified/added since the last time the software update group had been deployed. Sounds simple right? Let’s dive right in to see if that’s true or not!

Technical Deep Dive:

First thing that must be accomplished is to identify where in the SCCM DB the data for this request is stored. Now I am not going to sit here and assume everyone reading this understands the SCCM DB Schema to an expert level, so I want to share a common trick I teach customers during training on custom report creation. There is a component in all hierarchies called SMS Provider, the provider essentially takes what you do in the SCCM admin console, which is normally executed in WQL, translates that to SQL and executes it against the DB. So, how does this help? Big time!

Go to: Software Library – Software Updates – Software Update Groups – Double click your SUG to show the members of it.

This is the content you’re looking to identify, now quickly go to your log directory on you site server <installation directory>\Program Files\Microsoft Configuration Manager\Logs – within that directory you will see SMSProv.log – open it.

You can see from the highlighted line the precise SQL command that SMS Provider is executing against your DB to bring you what you visually see in the console. Here we are seeing all the columns it’s selecting and most importantly where it’s selecting this information from within the DB. Keep this log up on that line – we will need it later.

Moving on, you will need to open up SQL Server Management Studio and make a connection to your Site DB. Once connected go ahead and open up a new query window. I normally start off by doing a few “Select *” statements from the views I see within the SMSProv.log execution like below:

Text:

select * from vSMS_SoftwareUpdatesPackage_List

select * from vSMS_CIRelation

select * from v_AuthListInfo

select * from v_CIToContent

Returned Results:

As you can see here most of our information comes from these four views. Now what we must do is start pruning out what we do not need vs what we are trying to obtain in order to start forming this custom query to then build a report from. What you can learn from these select statements is your Name, CI_ID, etc. all of which will be crucial to the success of this report. I was quickly able to identify the CI_ID that I wanted to target along with sorting by date released to meet the other requirement from the customer.

Text:

select distinct

upd.articleid,

upd.bulletinid,

upd.DisplayName,

upd.severity,

upd.DateCreated,

upd.IsSuperseded,

upd.IsExpired,

upd.DateLastModified,

al.Title,

al.ci_id

from vSMS_CIRelation as cr

inner join fn_listupdatecis(1033) upd on upd.ci_id = cr.tociid and cr.relationtype =1

inner join v_CIToContent cc on cc.CI_ID=upd.CI_ID

inner join v_AuthListInfo al on al.ci_id=cr.FromCIID

where al.CI_ID = 1473

order by upd.DateCreated desc

Results (461 Rows Returned which match what we visually saw in the SCCM Console):

The above results provided me with everything I needed from a requirement perspective. So, at this point I know that I’m clear to move onto Report Builder, merely copying the query and taking it with me.

Next up we will open Report Builder (don’t worry, Report Builder isn’t all that difficult after all you’ll shortly see!), and follow the Wizard below:

1. Within “New Report” – Click “Table or Matrix Wizard”, that will bring up the following window:

2. Allow “Create a dataset” to remain selected and click Next. This will bring the following window:

3. It should automatically identify the data source that’s mapped to your report server, at this point click “Next” and that will bring you to the following window:

4. Now we are getting somewhere! At this point you will select “Edit as Text” which will bring you to the following window:

5. Remember that query we created in SQL? Let’s go ahead and copy and paste that into this window like the following:

6. After successfully pasting, please click “Next” and you’ll be presented with the following window:

7. You will see numerous available fields in which you will be able to drag and drop into Columns, Rows, or Values. For basic configurations I normally just drag the appropriate fields into the “Values” box like below:

8. Once the desired fields are in “Values”, click Next and you’ll see the following screen:

This will provide you a high-level look at what you’re table will look like once completed – go ahead and click “Next”, then “Finish” on the following screen.

9. You’ll now be brought into the Report Designer window where you will see the beginnings of your report!

10. From this point on you can customize the look and feel of the report as you deem fit. I normally expand the size so that all of the information is presented in a readable manner, I change the fonts, alignment, and add custom branding per each customer. At the end – the results look like the following (Customer Scrubbed Out):

11. Finally, go ahead and save the report where you’d like within your report server and you’re officially complete!

I was able to provide the URL where this report can be run to the manager of this customer, with all requirements met, and accepted! I have various other custom SQL queries that I will be posting at a later date, but feel free to request custom SCCM reports here: Custom SCCM Report Requests & Discussion – and we will do our best to provide the SQL statements for the data you’re trying to obtain.

Thanks for your time! Like, and share! See you all soon.

  • Trevor

 

PART 2 – Firmware Deployment for Spectre-Meltdown Protection

This is part 2 to the original article titled Addressing the Spectre Meltdown Vulnerability where we covered the process of deploying the Spectre-Meltdown protection with Baseline. In this article we will discuss the firmware aspect of the process.

Contents

Step 1 – Deploy updated firmware

Step 2 – Understanding levels of protection

Step 1 – Deploy updated firmware

First things first, let’s go grab the firmware. HPE ProLiant DL380 Gen9:

https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_b229638a12b34c61b1f441aa51

Apologies if some of you are beyond some of this, but I like to make documentation for my 20-year-old self, so I’m going to include a few basics. When I download exe’s, I like to run them in a command prompt with a /? to see what switches it allows, as shown below:

The switches will come into play a bit later when we package it up in SCCM, for now, just run the exe by itself in a test environment if you can. Always nice to see how it installs, time it takes, reboot time, etc.

Once testing is complete, we can now package the firmware. Head over to the console, Software Library > Application Management > Applications. Create the corresponding folder as you wish and choose “Create Application”.

We’ll manually choose the application information as it’s an exe:

Enter General Information:

Enter Application Catalog information, choose icon, and specify documentiaton if you want to:

Add the deployment type:

Choose “Script Installer”:

Enter General Information:

Here we are going to use the switches we determined earlier, in this case, the /s for silent install. Of course, we’ll specify the content location as well.

Now, we’re going to enter our detection method. This will be what we target to see if the installation was successful.

In testing, we noticed the following registry key was something we could specify as the detection:

User experience settings, specify this to “Install for system”, and Logon requirement to “Whether or not a user is logged on”, then next:

After the User Experience, you can click next through to the summary as that’s all we’re focused on for now.

In testing, we noticed that it was reporting that the applicaton failed, which didn’t quite make sense because it was such a basic install. So we dug a little bit and found the HP log that get’s created in the root of C:\, named <installer>.log (example: cp034881.log). This log told us otherwise:

The nice about creating applications is that we can add Return Codes to the application. In Software Library, choose the Deployment Types tab on the bottom from the firware application you created. Open the properties for the installer.

Here we can see the built-in codes don’t align with what the HP installer returns.

Click add at the bottom:

The default options aren’t that great, so set it to what you feel works best. In this, I used the following:

We reached out to the HPE rep and he provided us an old document that gave us the Windows smart component return codes.

Source:

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c02511658#page=73&zoom=auto,-79,574

Step 2 – Understanding levels of protection

To break this down line by line, I will add the explanation and corelating fix:

Hardware support for branch target injection mitigation is present: True (Firmware related)

  • Maps to BTIHardwarePresent. This line tells you if hardware features are present to support the branch target injection mitigation. The device OEM is responsible for providing the updated BIOS/firmware that contains the microcode provided by CPU manufacturers. If this line is True, the required hardware features are present. If the line is False (update firmware), the required hardware features are not present, and therefore the branch target injection mitigation cannot be enabled.

Windows OS support for branch target injection mitigation is present: True (Current CU Related)

  • Maps to BTIWindowsSupportPresent. This line tells you if Windows operating system support is present for the branch target injection mitigation. If it is True, the operating system supports enabling the branch target injection mitigation (and therefore has installed the January 2018 update). If it is False, the January 2018 update has not been installed on the system, and the branch target injection mitigation cannot be enabled.

Windows OS support for branch target injection mitigation is enabled: True (OS Registry related)

  • Maps to BTIWindowsSupportEnabled. This line tells you if Windows operating system support is enabled for the branch target injection mitigation. If it is True, hardware support and OS support for the branch target injection mitigation is enabled for the device, thus protecting against CVE-2017-5715. If it is False, one of the following conditions is the true:
    • Hardware support is not present.
    • OS support is not present.
    • The mitigation has been disabled by system policy.

Hardware requires kernel VA shadowing: True

  • Maps to KVAShadowRequired. This line tells you if the hardware is vulnerable to CVE-2017-5754. If it is True, the hardware is believed to be vulnerable to CVE-2017-5754. If it is False, the hardware is known to not be vulnerable to CVE-2017-5754.

Windows OS support for kernel VA shadow is present: True (Current CU related)

  • Maps to KVAShadowWindowsSupportPresent. This line tells you if Windows operating system support for the kernel VA shadow feature is present. If it is True, the January 2018 update is installed on the device, and kernel VA shadow is supported. If it is False, the January 2018 update is not installed, and kernel VA shadow support does not exist.

Windows OS support for kernel VA shadow is enabled: True (OS Registry related)

  • Maps to KVAShadowWindowsSupportEnabled. This line tells you if the kernel VA shadow feature has been enabled. If it is True, the hardware is believed to be vulnerable to CVE-2017-5754, Windows operating system support is present, and the feature has been enabled. The Kernel VA shadow feature is currently enabled by default on client versions of Windows and is disabled by default on versions of Windows Server. If it is False, either Windows operating system support is not present, or the feature has not been enabled.

Windows OS support for PCID performance optimization is enabled: True [not required for security]

  • Maps to KVAShadowPcidEnabled. This line tells you if an additional performance optimization has been enabled for kernel VA shadow. If it is True, kernel VA shadow is enabled, hardware support for PCID is present, and PCID optimization for kernel VA shadow has been enabled. If it is False, either the hardware or the OS may not support PCID. It is not a security weakness for the PCID optimization to not be enabled.

BTIHardwarePresent: True -> apply OEM BIOS/firmware update
BTIWindowsSupportPresent: True -> install January 2018 update
BTIWindowsSupportEnabled: True -> on client, no action required. On server, follow guidance.
BTIDisabledBySystemPolicy: False -> ensure not disabled by policy.
BTIDisabledByNoHardwareSupport: False -> ensure OEM BIOS/firmware update is applied.
KVAShadowRequired: True or False -> no action, it’s a function of the CPU the machine uses

If KVAShadowRequired is TRUE
KVAShadowWindowsSupportPresent: True -> install January 2018 update
KVAShadowWindowsSupportEnabled: True -> on client, no action required. On server, follow guidance.
KVAShadowPcidEnabled: True or False -> no action, it’s a function of the CPU the machine uses

 

PART 1 – Deploy the Spectre-Meltdown Fix via SCCM

This article will cover the process of addressing the Spectre and Meltdown vulnerability using Configuration Manager for Task Sequence deployment coupled with a Configuration Baseline for compliance reporting.

Contents

Step 1 – Import & Deploy Configuration Baseline
Step 2 – Package and Deploy the registry keys and Meltdown-Spectre patches via Task Sequence
Step 3 – Deploy firmware update (Add to Task Sequence – Optional)
Step 4 – Understanding levels of protection
Firmware vendor list
Article Sources

Step 1 – Import & Deploy Configuration Baseline

The official baseline release can be found here.

Starting in the SCCM console, Assets and Compliance > Compliance Settings > Configuration Baselines

Choose Import Configuration Data:

Click “Add” and choose the “Speculative Execution Side-channel Vulnerabilitiesv106.cab” downloaded from the link provided in the article above. You’ll notice the following error, assuming that’s ok with you, choose “Yes” and continue.


Once added, choose “Next” and you’ll see the following, click “Next” and continue:

Once complete, you’ll see the following:

Close the Import Configuration Data Wizard once it finishes. You’ll now see the following under Configuration Baselines in the folder where you Imported it.

Since we are testing this first, I went ahead and created a test collection where I will deploy the Configuration Baseline. *Please test before you deploy to production*

Now that we have the Configuration Baseline added, our test collection created, we can deploy the Baseline. Head back to Assets and Compliance > Compliance Settings > Configuration Baselines, right click on the newly created Baseline and choose “Deploy”. Or choose from the ribbon.

From deployment wizard, we have the option to check “Remediate noncompliant rules when supported” which will automatically remediate the registry entries, however, we will opt to deploy the registry changes via a task sequence and use this baseline for reporting only. Choosing this would automate the remediation within your maintenance windows, otherwise checking “Allow remediation outside the maintenance window” would allow for remediation sooner.

We should see the following on the deployments tab once the Baseline is deployed:

Step 2 – Package and Deploy the registry keys and Meltdown-Spectre patches via Task Sequence

The first part of the Task Sequence will be a “Check Readiness” to ensure the disk has at least 2GB free space and that there is an eligible OS installed.

Package the following registry keys and add to the task sequence under the second step, “Execute” (a simple .BAT or .CMD will do just fine):

reg add “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management” /v FeatureSettingsOverride /t REG_DWORD /d 0 /f

reg add “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management” /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

reg add “HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualization” /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d “1.0” /f

Download and package the following updates and include in the task sequence after “Apply Reg Keys” in the “Execute” portion as shown below:
After you’ve deployed everything, head over reporting and look at “Compliance and Settings Management”. Depending on how you want to view compliance, there is an assortment of built in reports that should show you what you want to see.

Step 3 – Deploy firmware update (Add to Task Sequence – Optional)

Visit the Firmware vendor list and find the vendor for which you need the firmware for. Once you’ve tested the firmware in your environment, package it up and add that to the task sequence as the last step.

Step 5 – Understanding levels of protection

To break this down line by line, I will add the explanation and corelating fix:

Hardware support for branch target injection mitigation is present: True (Firmware related)

  • Maps to BTIHardwarePresent. This line tells you if hardware features are present to support the branch target injection mitigation. The device OEM is responsible for providing the updated BIOS/firmware that contains the microcode provided by CPU manufacturers. If this line is True, the required hardware features are present. If the line is False (update firmware), the required hardware features are not present, and therefore the branch target injection mitigation cannot be enabled.

Windows OS support for branch target injection mitigation is present: True (January patch related)

  • Maps to BTIWindowsSupportPresent. This line tells you if Windows operating system support is present for the branch target injection mitigation. If it is True, the operating system supports enabling the branch target injection mitigation (and therefore has installed the January 2018 update). If it is False, the January 2018 update has not been installed on the system, and the branch target injection mitigation cannot be enabled.

Windows OS support for branch target injection mitigation is enabled: True (OS Registry related)

  • Maps to BTIWindowsSupportEnabled. This line tells you if Windows operating system support is enabled for the branch target injection mitigation. If it is True, hardware support and OS support for the branch target injection mitigation is enabled for the device, thus protecting against CVE-2017-5715. If it is False, one of the following conditions is the true:
    • Hardware support is not present.
    • OS support is not present.
    • The mitigation has been disabled by system policy.

Hardware requires kernel VA shadowing: True

  • Maps to KVAShadowRequired. This line tells you if the hardware is vulnerable to CVE-2017-5754. If it is True, the hardware is believed to be vulnerable to CVE-2017-5754. If it is False, the hardware is known to not be vulnerable to CVE-2017-5754.

Windows OS support for kernel VA shadow is present: True (January patch related)

  • Maps to KVAShadowWindowsSupportPresent. This line tells you if Windows operating system support for the kernel VA shadow feature is present. If it is True, the January 2018 update is installed on the device, and kernel VA shadow is supported. If it is False, the January 2018 update is not installed, and kernel VA shadow support does not exist.

Windows OS support for kernel VA shadow is enabled: True (OS Registry related)

  • Maps to KVAShadowWindowsSupportEnabled. This line tells you if the kernel VA shadow feature has been enabled. If it is True, the hardware is believed to be vulnerable to CVE-2017-5754, Windows operating system support is present, and the feature has been enabled. The Kernel VA shadow feature is currently enabled by default on client versions of Windows and is disabled by default on versions of Windows Server. If it is False, either Windows operating system support is not present, or the feature has not been enabled.

Windows OS support for PCID performance optimization is enabled: True [not required for security]

  • Maps to KVAShadowPcidEnabled. This line tells you if an additional performance optimization has been enabled for kernel VA shadow. If it is True, kernel VA shadow is enabled, hardware support for PCID is present, and PCID optimization for kernel VA shadow has been enabled. If it is False, either the hardware or the OS may not support PCID. It is not a security weakness for the PCID optimization to not be enabled.

BTIHardwarePresent: True -> apply OEM BIOS/firmware update
BTIWindowsSupportPresent: True -> install January 2018 update
BTIWindowsSupportEnabled: True -> on client, no action required. On server, follow guidance.
BTIDisabledBySystemPolicy: False -> ensure not disabled by policy.
BTIDisabledByNoHardwareSupport: False -> ensure OEM BIOS/firmware update is applied.
KVAShadowRequired: True or False -> no action, it’s a function of the CPU the machine uses
If KVAShadowRequired is TRUE
KVAShadowWindowsSupportPresent: True -> install January 2018 update
KVAShadowWindowsSupportEnabled: True -> on client, no action required. On server, follow guidance.
KVAShadowPcidEnabled: True or False -> no action, it’s a function of the CPU the machine uses

Firmware vendor list:
https://www.intel.com/content/www/us/en/support/articles/000025619/software.html

Article Sources:

Guidance to mitigate speculative execution side-channel vulnerabilities – https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002

Additional guidance to mitigate speculative execution side-channel vulnerabilities – https://blogs.technet.microsoft.com/configurationmgr/2018/01/08/additional-guidance-to-mitigate-speculative-execution-side-channel-vulnerabilities/

Windows Server guidance to protect against speculative execution side-channel vulnerabilities – https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

The ConfigMgr Speculation Control Baseline – https://gallery.technet.microsoft.com/Speculation-Execution-Side-1483f621

Official Baseline – https://gallery.technet.microsoft.com/Speculation-Execution-Side-1483f621

Deploying Configuration Baselines – https://docs.microsoft.com/en-us/sccm/compliance/deploy-use/deploy-configuration-baselines

Understanding Get-SpeculationControlSettings – https://support.microsoft.com/en-ie/help/4074629/understanding-the-output-of-get-speculationcontrolsettings-powershell