Re-enabling Defender on Windows 2016 servers via command line

I've carried out a number of Microsoft Defender for Endpoint deployments recently. I find that workstations are easy enough to deal with but it can be a pain working with low level servers. Windows Defender shipped natively with Windows 2016 Servers and organizations came up with some pretty creative ways to stop Defender from running. In fairness, at the time, Defender caused some pretty serious CPU spikes when co-existing with a third party antivirus solution.

I've come across three scenarios in particular. They are easy enough to deal with in the UI but I just wanted to show how you can also deal with these using commands. This was essential for me when working at scale and using management tools to automate the solution.

Scenario 1: the Defender feature had been uninstalled.

The Defender features can be added back using the "Add Roles and Features wizard". Don't forget to add the sub-features as well.

Scenario 1 command line:

Dism /Online /Enable-Feature /FeatureName:Windows-Defender-Features

Dism /Online /Enable-Feature /FeatureName:Windows-Defender

Dism /Online /Enable-Feature /FeatureName:Windows-Defender-Gui

Don't forget to add a reboot step afterwards.

Scenario 2: Defender service had been disabled.

You'll be notified that the Defender service is stopped and you won't be able to start it. I found this scenario when Microsoft Defender Antivirus was disabled through Group Policy.

First make sure that you reverse this policy. Just set it to Not Configured, do not choose Disable.

Scenario 2 command line:

Then re-enable Defender using this command:

MpCmdRun.exe -wdenable

It must be executed from "C:\Program Files\Windows Defender" and you must add a step to reboot the system afterwards.

Scenario 3: Defender is turned off.

Essentially this means that Real-time protection is turned off.

It can be turned on in Settings > Windows Defender.

Scenario 3 command line:

You can turn on Real-time protection programatically using PowerShell

Set-MpPreference -DisableRealtimeMonitoring 0

You don't need a reboot for this one.

I hope this information is helpful to automate your Defender deployment. 

Until next time.....

Windows 10 devices not enrolling in Intune

This is just a quick post to describe a customer issue I encountered this week. Customer had previously configured Azure AD Connect and all devices were hybrid joined. They had just implemented a GPO to enrol the devices into Intune

Administrative Templates > Windows Components > MDM > Enable automatic MDM enrollment using default Azure AD credentials

However no devices were enrolled.

I looked a the event viewer on one of the devices and this told me where the problem was. In the DeviceManagement-Enterprise-Diagnostics-Provider log I saw this error

Auto MDM Enroll: Device Credential (0x0), Failed (Unknown Win32 Error code: 0x8018002b)

I figured that this was nothing to do with credentials but was caused by the user not being assigned a license. I was half right. The user had been assigned a license but it was a standalone Intune license. This is not enough for automatic Intune enrollment, that also requires an Azure AD Premium P1 license. I explained that it was still possible to enrol each device manually, but advised that wasn't a sustainable approach. 

Customer cancelled the Intune licenses and EM+S E3 licenses were provisioned. Problem solved and devices are now being automatically enrolled.

Moral of the story: Standalone Intune licenses are not recommended. You "may" get away with them if you are just managing mobile devices (Android & iOS), but not when you are managing Windows. EM+S or M365 is recommended.

Until next time....

Disabling screen rotation on Windows tablets with Intune

I had a recent requirement to disable screen rotation for Windows tablets. 

This is easy to do within Windows. There is a Display setting to turn on the Rotation lock. However, I had to automate this using Intune. There doesn't seem to be a Windows CSP for this so it's not possible to use a custom OMA-URI policy. 

However, this is something you can do by configuring the registry. If you navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AutoRotation you'll see that the Enable key is set to 1. This needs to be changed to 0 to disable screen rotation. This is easy to configure with a PowerShell script:

New-ItemProperty -Path Registry::HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AutoRotation -Name Enable -Value 0 -Force -PropertyType DWord

Once you have the script, upload it to Intune. Select Devices > Scripts > Add (Windows 10 and later). Choose the script location and configure the following:

• Run this script using the logged on credentials - NO
• Enforce script signature check - NO
• Run script in 64 bit PowerShell Host - YES

Assign the script to a group of Windows tablets and screen rotation will be disabled.

I hope this helps. Until next time......

Suppressing key mapping on Zebra tablet using Intune

I've been doing a lot of work with Zebra devices recently. In this blog post, I showed how to use Zebra StageNow to create an XML file which could be deployed by Intune. I used the same technique to solve this latest problem.

I've developed an Android Enterprise dedicated device solution to turn Zebra ET40 rugged tablets into kiosk devices running Chrome only. Everything was working correctly except for one minor detail. I could press the top left button on the device which displayed the settings menu for the device. That's not what you want on a kiosk.

The button is labelled number 3 in the graphic above. The Zebra documentation tells me that this is a programmable button (or a key that supports key mapping) called P1. I carried out a lot of testing and I discovered that pressing P1 on the ET40 defaults to the settings app. I needed to suppress this key mapping on P1.

I was able to do that by creating a StageNow Xpertmode profile.

I added the KeyMappingMgr CSP.

I selected the following settings and saved the profile:

• “Remap Key” button
• "The key to modify" :  Select “P1 button” from drop down
• "Key behaviour": Suppress Key

 Then I exported the settings to xml.

<wap-provisioningdoc>

  <characteristic version="9.2" type="KeyMappingMgr">

    <parm name="Action" value="1" />

    <characteristic type="KeyMapping">

      <parm name="KeyIdentifier" value="P1" />

      <characteristic type="BaseTable">

        <parm name="BaseBehavior" value="5" />

      </characteristic>

    </characteristic>

  </characteristic>

</wap-provisioningdoc>

This XML file was then use to create an Intune configuration profile based on the Zebra OEMConfig app. 

Select Configure > select the three dots next to Transaction Steps > and then select Add setting.

 

From the list of settings select, Device Administration Configuration.

Under Device Administration Configuration only two settings are required.

• Action = Submit XML
• Submit XML = the .xml data we copied above. Paste it into this field.

Complete the wizard to create the device configuration profile and assign it to a group of your devices. Now pressing the P1 button now has no effect and the kiosk is secure.

Until next time......

Android Enterprise devices losing Wi-Fi network when using proxy

This was a little awkward to solve, especially as the devices were single app kiosks and the device settings were not available. This was my scenario:

• Devices: Zebra TC52X handheld scanner
• Management platform: Microsoft Endpoint Manager (Intune)
• Android Enterprise: Corporate-owned dedicated devices
• Kiosk: single app (Chrome)
• Proxy: Zscaler (devices could not connect to corporate apps without going through proxy)

This would periodically show up on the devices (No internet connection). It would also present after every restart.

On restart, kiosk operators were told that the device had limited Wi-Fi connectivity. It was a straightforward temporary workaround. The operator had to double-click the message.

The operator had to check the box Don't ask again for this network and click Yes.

This would solve the problem for a while, but would inconvenience the operators. I wanted to solve this programatically. Before I could do that I had to understand what was happening.

This issue is caused by captive portal detection. A captive portal is what we call a network that requires your action before it allows you to connect to the Internet. This action could be to log in using a username and password, or just to accept the network's terms and conditions.

The way most networks do this is by redirecting you to such a page. Chrome will make automatic connections to detect these redirects. When those happen, you may see a notification indicating that you may need to log into the network. Normally, after you do this, the tab will be closed automatically. Occasionally, it will be kept around to display a message from the network's owners. These actions can happen seamlessly using open Wi-Fi systems. However, this becomes problematic in conjunction with a corporate proxy. The solution is to disable captive portal detection.

Luckily Zebra (and other vendors) provide a solution for that. I can create a Zebra StageNow profile which can be exported to and deployed by Intune. See the Zebra documentation for details on installing and using StageNow.

Launch StageNow and create new profile.

Choose your MX version (10.1 in my case) and select Xpert Mode. Click Create.

Give your profile a name and click Next.

Select Wi-Fi and click the Plus icon to move it over Config column. Click Add.

Scroll down and check the "Specify Advanced options" box to expose more options.

Search for Captive Portal detection and choose Disable.

Complete the wizard.

Complete the profile and generate the StageNow configuration barcode. You can also export to XML after creating your StageNow profile by clicking Export for MDM.

<wap-provisioningdoc>

  <characteristic version="10.1" type="Wi-Fi">

    <parm name="UseRegulatory" value="0" />

    <parm name="UseDiagnosticOptions" value="0" />

    <parm name="UseAdvancedOptions" value="1" />

    <characteristic type="AdvancedOptions">

      <parm name="CaptivePortalDetection" value="0" />

    </characteristic>

    <parm name="UseHotspotOptions" value="0" />

  </characteristic>

</wap-provisioningdoc>

This is the XML generated. Once we have the XML we can import into Intune and assign to a group.

In the MEM admin console, create a Device Configuration profile of type OEMConfig.

Enter a name and select the OEMConfig app, in this case it's for Zebra. Each vendor will have their own OEMConfig app, which must be added in advance to Intune.

Select Configure > select the three dots next to Transaction Steps > and then select Add setting.

You will see a list of settings.

From the list of settings select, Device Administration Configuration.

Under Device Administration Configuration only two settings are required.

• Action = SubmitXML
• Submit XML = the .xml data we copied above. Paste it into this field.

Complete the wizard to create the device configuration profile and assign it to a group of your devices. You won't see the No internet connection warning again or be prompted that you have limited connectivity.

Until next time......

Defender for Endpoint - Onboarding status column missing

I came across this on a customer site last week. The Onboarding status column was missing in the Microsoft 365 Defender portal for all administrators, although they had been granted the Security Administrator role.

Navigate to Assets > Devices and you can see that the column is missing. It should be between Sensor health state and Last device update (by default).

I found that the reason for this was that Device discovery was disabled (Settings > Endpoints > Advanced features).

Turning on Device discovery solved the problem.

The Onboarding status column was restored.

You can see the importance of this column.

We can see if devices have been onboarded. If not we can see if they are unsupported by Defender for Endpoint or just not onboarded (Can be onboarded). This will require some action.

The fix makes sense. We are sort of told about this limitation when we disable Device discovery.

I hope this helps of you find yourself in the same situation. Until next time....

We can't activate Windows on this device

I encountered this problem recently while carrying out Windows 10 Autopilot testing on a customer site. My test device would step up from Windows 10 Professional to Enterprise but would not activate.

I could see the error: We can't activate Windows on this device as we can't connect to your organization's activation server. Error code 0x8007232B.

Running slmgr /dli on the device showed me that the currently installed operating system was expecting to be activated using volume licensing (MAK key). This isn't expected when provisioning devices directly from the vendor through Autopilot. However this was a test device so I figured it was re-imaged in the past.

Running wmic path SoftwareLicensingService get OA3xOriginalProductKey from a command prompt gave me what I needed. This displays the Windows product key embedded in the computer’s firmware. This is the original Windows key that shipped with the device.

I selected Change Product Key at the Activation window.

I entered the original product key and clicked Next.

I clicked Activate.

Windows was activated with a digital license. We wouldn't normally expect to see this problem with devices shipped directly from a vendor. However it could come in handy during customer testing in order to validate the process.

Until next time....

BitLocker waiting for activation

This is a quick blog post describing an annoying issue I encountered while developing a Windows 10 Autopilot process for a customer. My BitLocker policy (MEM > Endpoint Security > Disk encryption) reported as Succeeded and the recovery key was escrowed to Azure Active Directory. 

However, all was not well in the BitLocker Drive Encryption applet in Control Panel. I had the yellow exclamation warning icon with the message "Windows (C:) BitLocker waiting for activation".

The event log gave me an idea where to look. "Failed to enable Silent Encryption. Group Policy settings require the creation of a recovery key". This was Azure AD only so the Group Policy reference didn't make much sense. However it made me look for anything related to creating a recovery key in my BitLocker policy.

I found it here. I had set Recovery key file creation to Required.

What does this do? According to the tooltip "Setting this to Allow will allow an admin user to create a 256-bit recovery key file manually. Setting this to Require will require an admin user to create a 256-bit recovery key file manually. Setting this to Deny will disallow any admin user from creating a 256-bit recovery key file manually. BitLocker silent enablement requires this setting configured as Deny or Allow". I didn't want this to be required.

Changing this setting to Allowed did the trick and the device was encrypted successfully.

I hope this helps.

Until next time.......