Mystery Solved: Bitlocker is enabled, but Intune shows the computer as non-compliant for Require Bitlocker

For some time, I have struggled to understand why Intune reports some computers as non-compliant with the "Require Bitlocker" setting, even though Bitlocker is enabled and working on the computer.  In my searches for an explanation, I found the same question asked by many others, but never an answer.  Until today. I accidentally stumbled across this article from Microsoft's Rob Lane , which explains how the Require Bitlocker setting is evaluated and why it might seem to incorrectly report a non-compliant state.  I encourage you to check out that article for full details.  I'll just summarize here the part that suddenly made this bitlocker compliance issue make sense to me. The "Require Bitlocker" setting in Intune relies on the Device Health Attestation (DHA) service in Windows 10 to report the state of Bitlocker encryption on the computer.  If Bitlocker protection is disabled or suspended, DHA will report that the computer is non-compliant with this

Skype for Business Online adds support for Common Area Phones (At Last!)

The long awaited option for licensing common area phones for use with Skype for Business Online/Office 365 Phone System has arrived. Since the announcement of the Office 365 Phone System (Then called Cloud PBX) at Ignite 2015, IT Pros have struggled with how to configure and license common area phones for this offering.  While the on premises version of Lync/Skype for Business server has long supported these common area phones, the cloud version has not.  Until now, adding a phone which was not associated with a specific user required treating the phone's Office 365 account as an additional user, assigning it a combination of Office 365 licenses that made little sense for a stand alone phone in a break room or other other shared area.   This was cost prohibitive in many cases, and prevented some companies from making the move to Microsoft's otherwise attractive cloud based phone system. In January, Microsoft's Alejandro Araujo Rajzner revealed in a Microsoft Te

Automate cleanup of CB Defense sensor after a failed uninstall using SCCM

CarbonBlack recently released version 3.1 of the 'sensor' for their CB Defense product.  This sensor is the client side agent installed on each PC.  The CB Defense sensor does not self update, but installing the new version should be as simple as a few clicks in the CB Defense web console or downloading the install package and deploying it using your favorite method.  Unfortunately, it's not always so simple. In many cases, when the installer attempts to remove the old version of the sensor during the upgrade process, the uninstall does not completely remove the old sensor, and installation of the new sensor fails.  This leaves the computer with no working version of the CB Defense sensor installed.  The old version of the sensor no longer shows up under "Programs and Features", and all attempts to install the new version fail.  The CarbonBlack User Exchange (login required) site has a few articles describing this issue and potential workarounds.   An article