The Case of Blurry Text Using BGInfo on Windows 10 / Server 2016

If you are deploying Windows 10 or Server 2016 (perhaps in an RDS role) across your organisation you may want to apply a appropriate wallpaper and some text using BGInfo.  You’ve probably been doing this for years with no issues but what you will notice in Windows 10 / Server 2016 is that the text applied to the wallpaper by BGInfo looks blurry:

Now is it the fault of BGInfo?  Turns out it is not.  BGInfo creates a .bmp file in this location when the wallpaper is applied:

C:\users\username\appdata\local\temp\BGInfo.BMP

Let’s have a look at that file:

No problem there, the text is smooth and the background quality remains high.

Windows stores the in-use wallpaper in this location:

C:\Users\username\AppData\Roaming\Microsoft\Windows\Themes\transcodedwallpaper.jpg

Open that up and you’ll see the image with poor quality as in the first image above.  So what’s going on?  Windows 10 (and possibly 8/8.1/2012/2012R2 I’ve not tested) always converts the bmp wallpaper to jpg format to display it.  The process of converting your high quality BGInfo bmp image to jpg is where the loss in quality is occurring.  We can overcome this by adding the following registry DWORD using whatever method you prefer (GPP, script, UEM etc.)

HKEY_CURRENT_USER\Control Panel\Desktop\JPEGImportQuality

Value : 100

By default Windows uses a value of 85, which means a JPG quality of 85%.  This is to make the transcoded jpg smaller and so use less resource to display it.  In modern workstations/servers the resource use isn’t an issue so upping to 100% won’t do much harm.  The setting will take effect at the next logon.

As you can see below once the quality has been upped to 100% we see an improvement in the quality of the text.

Top – 85%, Below – 100%

It still isn’t as good as the original BMP created by BGInfo.  JPG is not a good format for displaying text and even at 100% quality it still suffers but this is the best we can do until BGInfo can create the wallpaper in jpg or png format natively at a high quality.

If you are desperate to get the best possible quality one option would be to use BGInfo to create the BMP and set the wallpaper.  Then use your UEM tool to convert the bmp to png via a command line tool such as bmp2png, then use the UEM tool to set the wallpaper again using your new png file which can be rendered natively by Windows without the transcoding and loss of quality.  Overkill but it works.

 

Advertisement

The Path to Modernizing Windows Management – Part 2: How will you provision your devices?

When it comes to provisioning your Windows 10 MDM based clients you need to consider a number of things:

1. Do I trust the user to enrol the device?

   A device can be enrolled during OOBE or afterwards via Settings.  The question is if you just ship the device to the user will they actually bother to enrol it?  That might sound stupid as in most cases the device will need to be enrolled to access corporate resources but you may have awkward users who want to just use the device on their own terms.  If you are concerned about that you may have to issue the device via your Service Desk.  Having used Apple Device Enrolment Program for many years it is a bit of a shortcoming in Windows that you cannot force the enrolment during OOBE but I can understand the difficulty in this when you don’t control the hardware.

2. Does your corporate Wi-Fi network support connections from unmanaged devices?

   In order to join the device to AAD you are going to need internet connectivity.  In many organisations you’ll be using Wi-Fi networks that rely on either a device based certificate or AD credentials to connect.  Typically, with traditional management, you will use something like auto-enrolment to issue certificates to domain joined devices which will get you connected to Wi-Fi automatically.  During OOBE or with a non-domain joined W10 box you won’t have that luxury.  In order to make sure this is as easy as possible you may need a separate SSID which can be used in OOBE. This SSID may be configured to only allow access to connect to AAD and Intune.  After enrolment Intune can deliver a Wi-Fi profile for your corporate network and the user can switch to that network when on-site.

3. Who is going to  have permission to enrol?

   EMS is licensed per user.  You may not have purchased an EMS license for your entire workforce.  Also you may only want to allow CYOD devices to enrol in MDM and not BYOD.  With that in mind you will need to control who can join AAD and who gets enrolled into MDM to prevent anyone in your organisation joining any old device to your AAD and using up your EMS licences.  The simplest thing to do is create an AD group for your users who you will allow to AAD join and another group for those who you want enrolled in MDM.  MDM users will need to be in both groups.  Use the Azure portal to configure this:

    

   In the example above I’ve used the same group (AzureADJoin) for both but as you can see you can set it independently.

Pretty simple stuff but I’d make sure you’ve thought about all of the above before you go ploughing in to your MDM deployment so you don’t get caught out later.

 

 

Disabling SMB1 via ConfigMgr Desired State Configuration (DSC)

EDIT – Since I posted this MS have provided a method via GPO using some new admx:

https://blogs.technet.microsoft.com/secguide/2017/06/15/disabling-smbv1-through-group-policy/

I would now recommend using the admx approach to disable it, but then deploy the below baselines in monitor mode only so you have some reporting on if your GPO is working.

 

Put simply you should stop using SMB1 right away.  If you regularly scan your systems using something like Tenable Nessus you may have noticed that SMB1 being enabled is marked as a “Critical” and without disabling it you are likely to fail your compliance for systems which should meet standards such as PCI.

Ned Pyle at Microsoft posted an excellent article on why SMB1 is no longer safe or appropriate.  You can read it here.

Once you have read this your next step is going to be to disable it and remove it (Server 2012 R2+/8.1+) or disable it (Server 2012/2008/7).  If you are worried about what might break here are some things to check first:

• Are you using any MFDs with ancient firmware which use features such as scan to share or offer a share to upload content for print?  If so check for firmware updates or within the systems to see if you can enable at least SMB2
• If your shared storage is based on something like NetApp Data ONTAP make sure that your storage admins have enabled at least SMB2.  ONTAP 8.2 and later support SMB3 so if you can enable this too you should see some benefits for your Windows 10 clients
• If you still have any XP or Server 2003 clients get rid of them, they only support SMB1

Sadly there is no GPO option to disable SMB1 client or server, and the method to disable it differs across the versions.  In order to disable it and be able to report it on I am using DSC within ConfigMgr.

Configuration Items Required

We’re going to need four configuration items in our baseline:

1. Disable SMB1 on Windows 8 / Server 2012 and above
2. Remove SMB1 on Windows 8.1 / Server 2012 R2 and above
3. Disable SMB1 Client on Windows 7 / 2008 R2
4. Disable SMB1 Server on Windows 7 / 2008 R2

Disable SMB1 on Windows 8 / Server 2012 and above

Create the new configuration item and select only the Supported Platforms of:

In the Settings tab make a new setting of the type “Script” called “SMB1 Disabled”.

For your discovery script use:

$smbenabled = Get-SmbServerConfiguration | Select EnableSMB1Protocol
echo $smbenabled.EnableSMB1Protocol

 

For your remediation script use:

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

Move onto the “Compliance Rules” tab and create a new rule as follows:

Hit OK and close and that’s your first one done.

Remove SMB1 on Windows 8.1 / Server 2012 R2 and above

Create another configuration item as before, this time your supported platforms should be as follows:

Create the new setting with the following Discover and Remediation scripts:

Discovery

$smb1 = Get-WindowsOptionalFeature -Online -FeatureName smb1protocol
echo $smb1.State

Remediation

Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol -Norestart

Note that here I have added -norestart to prevent the systems from rebooting immediately.  At the next scheduled reboot SMB1 will be fully removed.

Create the compliance rule as follows:

Two down, two to go.

Disable SMB1 Client on Windows 7 / 2008 R2

No need to teach you how to suck eggs so this time create a configuration item with Supported Platforms of Windows 7 and Windows 2008 (this covers 2008 R2 also if you tick the box at the top level).

This one is slightly more tricky.  Whilst disabling the SMB client is the small matter of running a couple of sc.exe commands detecting the status is more difficult.  In order disable the SMB1 client we remove the dependency of “SMB 1.x MiniRedirector” from the Workstation service and then disable it.  Before starting, in the GUI it looks like this:

We need to discover if the “SMB 1.x MiniRedirector” has been removed from the dependencies and we want to do it with PowerShell.

$smb1 = Get-Service -name LanManWorkstation -RequiredServices | where { $_.Name -eq "MrxSmb10"}

echo $smb1

If the “SMB 1.x MiniRedirector” has not been removed from the Workstation service the command will return this:

If it has been removed then the command will return nothing.

By simply adding an if statement we can test for the null value and return a true/false result to ConfigMgr

$smb1 = Get-Service -name LanManWorkstation -RequiredServices | where { $_.Name -eq "MrxSmb10"}

if ($smb1 -eq $null)
{$Compliant = "True"}
else
{$Compliant = "False"}
echo $Compliant

This will be our discovery script.  The compliance settings will be that the value returned by the above script returns True:

Our remediation script will run the two sc.exe commands provided in the Microsoft guidance for removing SMB1:

sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled

This can be specified as a PowerShell script as calling sc from PowerShell is fine provided we use sc.exe.  sc is an alias for Set-Content in PowerShell.

This does need a reboot to take effect but once again we’ll assume that you are happy to wait until your next scheduled restart rather than forcing it.  If you need to force any of these just add a Restart-Computer command to the end of your remediation script.  You may also want to add a Write-Eventlog command to add something to the event log to show why the computer was restarted.

 

Disable SMB1 Server on Windows 7 / 2008 R2

Use the same supported platforms as in the previous item.

This time for your settings you want a registry rule as follows:

The required compliance rules are as follows:

Ensure that you have ticked the “remediate noncompliant rules when supported” box for your SMB Equals 0 rule.

Create and deploy our Baseline

With the four configuration items in place create a baseline and add the four conditions to it:

Deploy this to a collection and enable remediation and all your SMB1 problems will disappear!

 

 

 

 

 

Where should MDM only devices sit on your network?

In my last blog post around MDM you’ll see that Windows 10 AAD+Intune MDM devices are aimed at users who are primarily working outside of your organisations network.  Most likely users are connected to the internet at their own home, via 4G, at client/customer sites or on public Wi-Fi at Starbucks etc.  This isn’t a problem as that’s the whole point of it, taking away dependencies on your on-premise infrastructure for patching, management and access to systems is generally a good thing.

But what about when an MDM users comes on-site?  What sort of network connectivity do you give them?  How much do you trust the device?  Here’s a few thoughts:

The MDM device is likely to be Wi-Fi only, so how are you going to connect it to your Wi-Fi network?  Do you trust it enough to put it on the same VLAN as Wi-Fi devices which are fully managed via AD+ConfigMgr?  Bearing in mind that, by default, MDM users will have admin rights on their devices and no whitelisting they will be able to download and run whatever they like.  Do you want these devices to be able to reach your fully managed and AD bound devices/servers when you lack full control of them?

Personally I would put them onto a Wi-Fi network which sits outside your firewall, where they can only access resources which are based on the internet or published via your DMZ.  That is how you designed them to function when they are off-site, so why have them behave any differently when on-site?  Intune can be used to deliver a Wi-Fi profile for your organisational network to simplify connecting devices to the Wi-Fi.  Your domain joined, and fully trusted devices can continue to connect to a trusted VLAN over Wi-Fi using auto-enrolment to grant a certificate to connect.

I’d be interested to hear what others think on this topic so comment below…

 

The Path to Modernizing Windows Management – Part 1: What do you need to consider?

Microsoft published a nice blog almost a year ago around the movement towards MDM for mobile devices.  You can read it here but the crux of it is covered by this image:

 

The majority of enterprise customers I have seen tend to still be using traditional management with Domain join and ConfigMgr, perhaps throwing is DirectAccess or a Cloud Management Gateway to keep these devices under control.  The benefit of course with DirectAccess is that you can also access your on-premises resources when connected externally meaning that your off-premise experience should mirror your on-premise experience when using mobile devices.

Modern management for BYOD makes a lot of sense, for we do not want to be joining random consumer equipment to our domains but adding a Work Account gives you some SSO and Intune can provide a portal for LoB applications and some basic security configuration.

From a CYOD perspective it gets more complicated.  How I would see CYOD working in some organisations is that the equipment is purchased by the organisation but the user could choose what type of device they want and also how it is managed, rather than just always handing out the AD+ConfigMgr option but there is a much to consider.  I’ll cover each of these topics in a series of blog posts, the links will appear once the posts are published:

• Where should MDM only devices sit on your network?
• How will you provision MDM devices?
• How are we going to access corporate resources when using MDM?
• How does the security of an MDM device compare to that of a Domain Joined device?
• How can we apply security policy to MDM only devices?
• How are you going to manage deploying applications to MDM and Domain Joined devices without duplicating effort?

Creators Update – Allowing only Store Apps – Useful but not perfect…yet

Imagine this utopian scenario…

• You join your mobile/roaming devices to AzureAD ONLY
• You use EMS to enrol these devices automatically into InTune
• You are running Windows 10 Creators Edition (1703?)

By default, when a user joins a device to AzureAD they will be granted admin rights.  They can then download and install anything they like, which could be malware, ransomware or potentially unwanted applications (PUA).

Creators Edition has an option, which will presumably be configurable via MDM, to Allow apps from the Store only.  This will block the installation of Win32 apps if they do not originate from the Windows Store.

It is also possible via the MDM channel to block the public Windows Store and only allow your organisational Windows Store for Business (WSfB).

You can do this via a “Custom Configuration” policy for Windows 10.

Use whatever names you like but the important part is the OMA-URI:

./User/Vendor/MSFT/Policy/Config/ApplicationManagement/RequirePrivateStoreOnly

Set this to an integer value of 1

Deploy this policy to a USER group to enforce the setting.

At this point, if you enable Allow apps from the Store only you now have a machine which can only install apps via the WSfB.  Any app you require from the public store can be added to your private WSfB store for installation either by the user or pushed via Intune.

The device, despite being used with admin permissions, now at least is protected from externally introduced application installations.  Setting Allow apps from the Store only does not conflict with Intune delivery of traditional MSI based Win32 apps.  With Allow apps from the Store only set it is still possible to install an MSI via Company Portal or push it to the device.

All the above is good stuff, we don’t want users installing additional applications on their systems as we don’t know what they are and they could introduce vulnerabilities.

Here’s the important bit – the setting Allow apps from the Store only does not appear to stop all portable Win32 apps from running thus not stopping any kind of .exe which may be executed as part of a malware or ransomware attack.  I tried a few portable apps and got mixed results, putty.exe was blocked but bginfo was not.  It would be interesting to understand how the logic determines that the .exe is trying to install.

With that in mind you’ve got yourself a machine with some protection but not quite enough to meet some security scenarios.  It looks like for now at least you’ll still need AppLocker or another 3rd party tool to do your application whitelisting but it is a step in the right direction.

 

HP – Critical Update! ME Firmware and BIOS Updates Required to Avoid System Board Replacement

Background

Recently HP released an advisory for many of their enterprise desktop, laptop and workstation devices with an interesting title:

Advisory: HP Commercial and Workstation Skylake-based PC’s (6th Gen Intel Core Processors ) – Critical Update! ME Firmware and BIOS Updates Required to Avoid System Board Replacement

Wow, a firmware update to avoid system board replacement!  Symptoms of the issue include:

• No POST
• No video
• No fans run
• Only one LED lit on the system board

We have 1,000s of these devices so something needed to be done.  Incidentally another HP advisory  HP Elite Slice, EliteDesk 800 G2, EliteOne 800 G2, ProDesk 600 G2 DeskTop Mini, SFF and Non-Touch All-in-one PCs – System Fails to Get a DHCP IP Address After Resuming From Sleep (S3) Mode is also resolved by updating the ME firmware so this fix will resolve both issues.

Deploying the Firmware with ConfigMgr

HP have a useful SCUP catalogue for their enterprise updates.  Unfortunately it does not contain these ME firmware updates so the work needs to be done manually.

First we need a collection to deploy the update to.  Although this affects many models I am only concerned with EliteDesk 800 G2.  With that in mind I have a collection which contains all machines of this model using this query statement:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client from
SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on
SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId where
SMS_G_System_COMPUTER_SYSTEM.Model LIKE "HP EliteDesk 800 G2%" and
(SMS_G_System_COMPUTER_SYSTEM.Manufacturer = "Hewlett-Packard" or
SMS_G_System_COMPUTER_SYSTEM.Manufacturer = "HP")

Now we have a collection to target we’ll make the package:

Download the ME firmware package from HP (link is in the advisory).  Run it to expand the sp to a new folder.  Copy this folder to wherever you keep your ConfigMgr package source files.  If you want to conserve some space (every little helps) remove the pdf, html and bmp files as you won’t need them.

HP Provide a batch file with the syntax to run the update so we’ll just use that.  Within the SP78318\Update Utility\Local-Win\ folder you’ll find Update.bat and Update64.bat.  I am only concerned with Update64.bat as I’m running 64-bit OS.  Edit the batch file to remove the @pause from the end so that the script exits correctly.

Create the package and program as follows:

Deploy this program to your clients and all will be resolved.  The update doesn’t ask for a reboot (or at least hasn’t when I’ve deployed it) so safe to run at any time.  The FW level will not be reported as updated until after a reboot.

A BIOS update is also available, which contains the ME firmware.  These are available in SCUP but you won’t be able to deploy using SCUP if you have a BIOS password set.  You would need to follow a similar procedure to above to manually deploy the BIOS update using an encrypted password file.  For me at least with W10 1607 the latest HP BIOS update for an EliteDesk 800 G2 causes a BSOD if applied from Windows so I’m avoiding it for now…

 

 

 

 

 

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:

multimon:i:1

amend this to

multimon:i:0

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

 

Background

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.

Discovery

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).

Remediation

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

 

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

Baseline

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.