AzureAD and Automatic Bitlocker


One of the great features of AzureAD is that when a device is joined it can be automatically encrypted with Bitlocker and the recovery key can be stored against the device within AzureAD.  However this is only true for devices which support ‘InstantGo’ which is low power state found in a very small number of devices, such as Surface Pro 3 and 4.

What you don’t want to happen is find that other mobile devices are connected to your AzureAD but not encrypted.  Fortunately Jan Van Meirvenne reverse engineered the process and has posted a PowerShell script which will enable the TPM, invoke Bitlocker and store the key to AzureAD.

You can find his blogpost and the script here.

However, how are you going to automate the running of this script?  If you are enrolling Windows 10 devices into AzureAD and then into Intune using the MDM channel you will find that you cannot deploy scripts via Intune.  Not only that, you cannot even deploy an .exe file (you could easily convert the .ps1 to .exe) so that method is out the picture.  At present all you can deploy is .msi files and MDM based policy.

Fortunately in my organisation we use DesktopNow from Ivanti (formerly AppSense).  Environment Manager is able to execute scripts of any kind at any trigger point and can use logic to determine if the script needs to be run.

First we can create a custom condition to check if Bitlocker is not yet enabled.  Environment Manager expects a return code of zero for success (condition evaluates true) so we’ll test for protection in a state of “Off”.


If this condition determines that Bitlocker is not enabled we simply run the script provided by Jan Van Meirvenne  to enable it by using a custom action which runs in the System context:

In this configuration I’ve added the test and the action to the Desktop Created node but you can of course use any available trigger.  By running it regularly either at logon/startup or on a schedule you can ensure that if the user disables Bitlocker (AzureAD only users will have admin rights by default) it will become re-enabled next time the condition runs.


The Environment Manager agent and Environment Manager configuration can both be deployed via MSI so these will work nicely with MDM only Windows 10 Intune devices.  By utilizing the Environment Manager engine you pretty much get back a level of control which you had with classic domain join devices such as applying ADMX policies, setting registry keys etc.

In the future I will cover how the Application Manager agent can be used on AzureAD devices to restrict local administrators from doing things they shouldn’t.





Disabling Multi Monitors within full RDP session delivered via RDWeb


By default RDWeb in Windows Server 2012 R2 only displays published RemoteApp programs.  One can also display a full RDP desktop session by changing the registry value ShowInPortal to a value of 1:


The full remote desktop session will now be published to the session collection.  However, even if you have set relevant GPO on your session hosts to not allow multi-monitor  you will find that it still spans two displays, which is particularly annoying if you need to view content on both your local machine and the remote machine.

To disable this edit the RDPFileContents key which can be found in the same node as the ShowInPortal key which you already edited.  The REG_SZ key is very long but a little way in you will find the following:


amend this to


and then you will no longer get sessions spanning multiple screens.  Note that much like the ShowInPortal key if you make amendments to your session collection via the GUI these keys can get reset back to their default.  You may wish to use DSC or a GPP to ensure they remain set how you like them.

Disabling NetBIOS via ConfigMgr DSC




If you’ve ever studied IT security you’ll know that one task you need to complete on your network is to disable NetBIOS.  The NetBIOS API dates back to 1983 and is often left enabled for fear of breaking legacy applications and systems.  From a security perspective NetBIOS can mostly be considered a reconnaissance risk and so should be disabled.  For more information check out:

NetBIOS Over TCP/IP (Microsoft)

Securing Windows Workstations: Developing a Secure Baseline

With NetBIOS enabled one can remotely query devices, without authentication, to reveal information about the host.

The simplest way to disable NetBIOS on your Windows clients is via DHCP option 001.  You will find information on how to do this elsewhere.  But what if you have no control over the DHCP server or you want to ensure that it stays disabled if the device is connected to other networks?

A ConfigMgr configuration item can be created to discover the state of NetBIOS and the remediate if required.


The code below will discover any network adapters, which are IP enabled and return the NetBIOS options.  This can return one of three values:

  • EnableNetbiosViaDhcp (0)
  • EnableNetbios (1)
  • DisableNetbios (2)



$adapters= $null
$adapters=(gwmi win32_networkadapterconfiguration -Filter 'ipenabled = "true"')
Foreach ($nic in $adapters) {
write-host $nic.TcpIPNetBiosOptions



For compliance, we are looking for a return code of 2 (DisableNetbios).



If we discover any adapters which do not return a value of 2 we will run the following to remediate and disable NetBIOS.


$nics = (gwmi Win32_NetworkAdapterConfiguration -Filter 'ipenabled = "true"')
foreach ($nic in $nics) {
If ($nic.TcpipNetbiosOptions -ne 2) {


Simply create a configuration item with the above scripts.  Then make a baseline which includes the configuration item and deploy.  Sit back and watch your devices disable NetBIOS the next time they evaluate their compliance data.