Windows - Enterprise Branding - Configure Custom Company & Support Information

What the Windows Security Center branding Worklet does

This Automox Worklet™ publishes your organization's company name, support email, phone number, and help desk URL into the Windows Security Center on every managed endpoint. Windows reads those values from the Enterprise Customization registry policy and renders them inside the Security Center app and in Microsoft Defender toast notifications on Windows 10, Windows 11, and Windows Server 2016 or later.

The Worklet writes six values to HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Enterprise Customization: EnableInApp (master switch for in-app branding), EnableForToasts (mirrors the same details into Defender toasts), CompanyName, Email, Phone, and Url. You set the four contact strings and the two boolean toggles at the top of evaluation.ps1 and remediation.ps1, and the script applies the matching set across the fleet on the next policy run.

Evaluation is idempotent, so the Worklet is safe on a recurring schedule. Endpoints already inline with the desired values exit clean. Any endpoint where the key is missing, a property is absent, or a value drifts from the configured string is flagged for remediation. Reverting is a single parameter flip: set $EnableEnterpriseCustomization to $false in the remediation script and the next run rewrites EnableInApp to 0, which stops Security Center from rendering the custom block.

Why enforce a Security Center branding baseline

By default, Windows Security Center shows generic Microsoft contact prompts. When a Defender notification fires, the employee in front of the laptop has no in-app path to a verified internal help desk. The common next step is a web search for a support phone number, which is the exact pattern that tech support scams and impersonation pages are built to intercept. Publishing your help desk number, email, and portal URL into the Security Center surface puts the verified contact in the same window the user is already looking at.

A re-imaged laptop loses the policy, a developer rebuilds a VM from a stale gold image, and a new acquisition's hosts land in the tenant with someone else's company name still baked into Security Center. Running this Worklet against the Windows workstation and server policy keeps Enterprise Customization synchronized from one configuration, so users see the right support contact on every recurring pass instead of a stale number that no longer routes anywhere.

How Security Center branding enforcement works

1. Evaluation phase: The Worklet runs Test-Path against HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Enterprise Customization. A missing key exits 1 with a remediation message. If the key exists, the script iterates the six properties (EnableInApp, EnableForToasts, CompanyName, Email, Phone, Url), reads each one with Get-ItemProperty, and compares the value against the desired configuration. Any mismatch flags the endpoint for remediation; an exact match across all six properties exits 0.

2. Remediation phase: The remediation script creates the registry path with New-Item if it does not exist, then walks the same six-property list and writes each value with New-ItemProperty -Force. When a desired value is null, Remove-ItemProperty strips that property. An optional $rebootDevice = $true flag triggers Restart-Computer -Force after the writes complete; the default $false defers the visual update to the next Defender event so the user is not interrupted.

Security Center branding requirements

• Windows 10 (1709 or later), Windows 11, or Windows Server 2016 / 2019 / 2022 with the Windows Security Center app installed

• Local administrator context for the Automox agent (the default service context already meets this)

• PowerShell 5.1 or later

• Set $CompanyName, $SupportEmail, $SupportPhone, and $SupportURL in both evaluation.ps1 and remediation.ps1 so the two scripts agree on the desired state

• Set $EnableEnterpriseCustomization to $true to apply branding or $false to revert to default Windows contact strings

• Set $EnableCustomNotifications to $true to extend the branding into Defender toast notifications, or $false to limit it to the Security Center app surface

• Set $rebootDevice in remediation.ps1 only if the policy can tolerate a forced restart; the default $false defers the visual update to the next Defender event

Expected Security Center state after enforcement

After a successful run, HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Enterprise Customization holds six values: EnableInApp = 1, EnableForToasts = 1, and CompanyName, Email, Phone, and Url populated with the strings you set in the policy. Open the Windows Security app and the home card shows your organization name, support email, support phone, and help desk URL as clickable contact actions. When Defender writes a threat or update notification to the action center, the same details surface in the toast footer.

Reg query is the fastest spot check: reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Enterprise Customization" /s returns all six values in one call. The PowerShell equivalent is Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Enterprise Customization'. Subsequent Automox policy runs report compliant without re-running remediation because the evaluation phase reads the same property set and finds it inline. The branding survives Windows feature updates and cumulative patches, and reverts only when an administrator deletes the key, a re-image wipes the registry, or the Worklet runs again with $EnableEnterpriseCustomization set to $false.