All posts by bondy

Disable WiFi Group Policy

I recently had a request by a customer to disable WiFi on their laptops. I know, crazy, right? They had their reasons though and it was a temporary solution to a problem.  The issue with disabling Wifi is that there isn’t actually a group policy which directly allows ‘disable wifi’ but the workaround is pretty easy. Essentially we need to disable the WlanSvc service.

What we need is to harness group policy preferences, so without further ado here goes:

  1. Create a new GPO. Browse to Preferences | Control Panel Settings | Services. Right click in the right-hand pane and select New | Service. Call it WlanSvc.
  2. In the properties, change Startup to Disabled
  3. Ensure the service name is WlanSvc. Note, you’ll probably not be able to find this service if you browse via the ellipses unless the machine you’re using for administering group policy is a laptop. This is why it’s important you name the service correctly.
  4. Under Service Action change to Stop Service.


5. Apply the group policy. Note, you will probably need to reboot the machine for everything to take effect properly. You may notice a short pause before full (wired) network connectivity kicks in, maybe about 20 seconds. After this you should see that wireless is disabled.

Error Code 1 – Using Invoke-MbamClientDeployment.ps1 in SCCM OSD

I know I’m not alone in the misery of getting this less-than-perfect script to work during OSD and after a good couple of weeks of on-off testing I can finally say I got my desired result and it most certainly deserved a post. Please note, you may need to click on the pictures to see them fully.


Encrypt used space only with XTSAES256 encryption and escrow keys in MBAM database during SCCM OSD task sequence. I also need a PIN to be requested automatically at first logon.

I’m not going to detail the ins and outs of what I tried because this post will be far longer than necessary so I’ll concentrate on the steps that finally got it working for me. Don’t get me wrong, this is a buggy script that should really have been updated by Microsoft by now.  Error code 1 is an extremely common problem and can result for any number of reasons.

I would suggest you create an MBAM section in the task sequence, filtering on laptops or whatever criteria you require and add the steps below to this section.

High Level:



Contrary to what I have read elsewhere, the pre-provision step in the task sequence isn’t necessary. In fact, it’ inclusion will cause the error code 1. These steps should be disabled.


This is a strange one but I have had trouble getting the Invoke-MbamClientDeployment.ps1 to run properly without first disabling the certificate update mechanism in Windows. Trust me, just do it, reboot, run the rest of the steps and make sure you remember to re-enable afterwards.

REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot /v DisableRootAutoUpdate /t REG_DWORD /d 1 /f

The assumption is that you have installed the MBAM 2.5 SP1 client with the August 2017 hotfix by this stage so there will be an MBAM Agent service running on the machine.

Net stop mbamagent


Now I am recreating what worked for me here and despite my requirement for XTSAES256 the below setting seems to work fine for this in my task sequence. However evidence elsewhere suggests the DWORD value should be 7. Feel free to test in your own environment though and let me know how you get on.

REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE /v EncryptionMethod /t REG_DWORD /d 2 /f

We want used space only as this is quickest. See here for other values. Be careful though – if you want the PIN prompt to appear at first logon the disk has to be ‘fully encrypted’, ie with used space only OR full disk. If the disk is still encrypting when the user logs on, they won’t be prompted for the PIN.

REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE /v OSEncryptionType /t REG_DWORD /d 2 /f


This is where * I believe * stage 3 gets overwritten (tbc). Essentially this will set the OS encryption to XTSAES256.

REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE /v EncryptionMethodWithXtsOs /t REG_DWORD /d 7 /f


Call the MBAMClientUI on first login. Technically this shouldn't be needed as I have a step further down which will call this anyway but no harm in adding.
REG ADD HKLM\Software\Microsoft\MBAM /v EnactOnFirstLoginRequired /t REG_DWORD /d 1 /f

Force MBAM client to wake up within a minute.

REG ADD HKLM\Software\Microsoft\MBAM /v NoStartupDelay /t REG_DWORD /d 1 /f


Net start mbamagent

This adds a setting to the default user so that every NEW user that logs onto the machine gets prompted for a new MBAM PIN for startup. Note, this will only fire if the disk is fully encrypted to type, ie used space only or full disk. Since we’re aiming for used space only here, disk encryption is pretty quick but it still needs to complete before the prompt will appear. If you log on before encryption is complete then the automatic prompt won’t appear and you will instead need to rely on GPO.

powershell.exe -ExecutionPolicy Bypass -command "reg load HKLM\DefaultUser C:\Users\Default\NTUSER.DAT; New-ItemProperty -Path 'HKLM:\Defaultuser\Software\Microsoft\Windows\CurrentVersion\RunOnce' -Name PromptForPIN -Value '""C:\Program Files\Microsoft\MDOP MBAM\MBAMClientUI.exe"""' -Type String; reg unload HKLM\DefaultUser"

The script itself. Note the encryption method, Unspecified. Because we have specified the encryption method earlier, the XTSAES256 encryption is automatically derived from that. Strangely, I couldn’t get this script to work unless I used this parameter and manually set the reg entry. Also note, I am running the script from the local installation of the MBAM client. This ensures that I am running the script that is aligned to that version of the client, ie it should contain any updates provided by any client upgrades you’ve applied, eg August 2017 update.

powershell.exe -ExecutionPolicy Bypass -File "C:\Program Files\Microsoft\MDOP MBAM\Invoke-MbamClientDeployment.ps1" https://MBAMSERVER.local/MBAMRecoveryAndHardwareService/CoreService.svc -EncryptionMethod UNSPECIFIED

Don’t forget to re-enable this otherwise you’ll end up with all sorts of certificate errors when trying to reach HTTPS sites.


That’s it. One would assume much of this legwork should automatically be taken care of by the script itself but unfortunately that doesn’t appear to be the case. Don’t forget, you will also need to make sure that no MBAM policies are in place when the script runs. This isn’t a problem with SCCM as GPOs will be suppressed but if you’re using native MDT this can be an issue.

Hopefully this will save some of you a few hours (more likely days) of frustration!



0x8007000f Task Sequence Error

Really quick post on issue experienced recently.

We were trying to build some Lenovo T470Ps and one was exhibiting this error just before the task sequence was to start and failed as a result before we even got off the ground. The error translates to The system cannot find the drive specified. However I knew for a fact that the drivers were OK as other T470Ps were building fine.

Transpires that somewhere along the way, something had indeed got mixed up on the disk and it was having problems with the config. I initially tried a DISKPART then CLEAN but this wasn’t enough and it was continuing to fail.

In the end we resorted to doing the task sequence’s job manually and recreating the partitions as follows:

Open CMD prompt (F8):

1. Diskpart
2. Select disk 0 (0 being the disk to setup)
3. Clean
4. Convert gpt
5. Create partition efi size=300
6. Format quick fs=FAT32
7. Create partition msr size=128
8. Create partition primary
9. Assign letter=c
10.Format quick fs=NTFS

Exit DISKPART and try again – this time the task sequence continued as expected.

Adding a Software Update Point to a Secondary Site (for those who already know how to add it to the primary site!)

This is something I’ve meant to get round to writing about for months as the first time I did this I couldn’t find any direct answers in the multitude of blogs I read about it.

On the face of things, installing WSUS/SUP on a secondary site sounds pretty straightforward if you’re used to adding them to a primary site but when you start it soon becomes clear there are a few unanswered questions which start to materialise. It’s important to first consider whether a SUP is even required for the secondary site: remember, the update packages will be present anyway. The secondary site SUP is really only there for scanning purposes and to relieve associated traffic which is really quite minimal. Assuming you are over this and need it anyway then here are a few other things to consider, some of which have changed since CM2007.

  1.  Since CM2012, there is now a DB on the secondary site so should we be installing to that?
  2.  WSUS Content?
  3. How does it interact with the Primary SUP?

This blog is only intended to answer one or two questions you might have as regards specifics of installing on a secondary site and there are plenty of answers out there for general installation. In short, the SUP on the secondary site is a secondary SUP and when you install it ConfigMgr will actually take care of marrying it up to the Primary SUP.

So the high level tasks are as follows:

  1. Install the pre-req’s for a Software Update Point. I thoroughly recommend Nickalaj A’s PreRequisite Tool  for this job, see I must confess this has made me lazy and I barely remember what the pre-reqs are these days but to be honest I don’t need to with this.
  2. Install the database on the secondary site SQL instance. Best practice is to have separate instances but I’ll leave that to you. Personally I don’t find there is any real performance issues using the same instance. Also, as an aside, if you have full SQL on the primary, (and you will) then I don’t really see why you wouldn’t use it on the secondary. Why use SQL Express when the licence is free for the full version? Just my opinion though.
  3. WSUS Content should always be local. It’s a requirement to specify this during installation but it’s not really used when part of a SUP in ConfigMgr.
  4. Finally, after WSUS installation, add the SUP role to the site. ConfigMgr will take care of the rest. Click on the secondary site under  the Sites node, and click the SUP under the site component properties to check the sync status. It should be greyed out because SCCM has recognised it as a child of the primary SUP.
  5. A good, detailed explanation of the whole process can be found here

Happy Deployments…

Change login screen language in MDT / SCCM (Server Core)

I came across an interesting (if very frustrating) issue recently when a client provided me with an updated version of Windows Server 2012 R2. Prior to being handed the new media, I was using my own copy of Server 2012 R2 which is Build 6.3.9600.16384. I set up my MDT build which had a task sequence for each version of Server 2012 R2, Standard, Standard Core, Datacenter and Datacenter Core.  Everything was fine and the UI language was configured correctly throughout.

I received the new media which was Build 6.3.9600.17415 and replaced my original copy of Server with this new version. All appeared to be fine until I tried to log in to the two Server Core versions where my password wasn’t being accepted. It transpires that these have some kind of bug / difference whereby the Input Locale doesn’t change to the configured language. In my case, I had an American (en-us) keyboard and I wanted to use an English (en-gb) keyboard. Weirdly, this was only the case for the core versions; the GUI versions were fine.

I spent a good deal of time scouring the internet for a fix to this and it appears quite a few people had the same issue, eg:

This one was also interesting but the application of the fix wasn’t explained clearly and I gave up on it.

Mostly, the ‘fix’ was to change the HKEY_CURRENT_USER\Keyboard Layout\Preload setting to the proper value and this does seem to work if you log on and change this manually in the registry. However I could not get this setting to stick when I applied it through any scripting mechanism.

I eventually found a solution though through group policy which I applied during the build. The steps below are for MDT but the same can easily be applied for SCCM.

Create a new GPO and browse to Computer Configuration\Policies\Admin Templates\System\Locale Services
Change Disallow copying of user input methods to the system account for sign in to Enabled.
Create a backup of the policy and copy it to your deployment share. Rename it from {GUID} to LogonKB. I created a custom directory to store this in called Custom2012R2. Under this I had a directory called GPOBackup which contain any GPOs I need to apply.
Download a copy of lgpo.exe and stick it in your tools\%architecture% directory (in practice you want the x64 version)
Create a TS step just before the Tattoo step called Copy GPOs Locally as below
Command line: xcopy “%DEPLOYROOT%\Custom_2012R2\GPOBackup” C:\Windows\Temp /e /i

6. Next, create another step to apply the GPO, directly after the copy step and call this Apply GPO logon keyboard.
Command line:

“%DEPLOYROOT%\Tools\%ARCHITECTURE%\lgpo.exe” /g “C:\Windows\Temp\LogonKB”

It is important these two steps are early in the task sequence as the ‘damage’ is already done if you apply them too late. What is actually happening is that the GPO you have applied is preventing the Input Locale from being copied over to the login screen keyboard locale. You can see this before and after by running up the systeminfo command from a command prompt. On a machine without the application of the GPO the Input Locale will show up as:

Input Locale: en-us;English (united States)

and this will get copied over to the login screen language during build time. The GPO prevents this from happening and keeps the setting at en-gb.

I hope this will save others many hours of frustration.

New OSD Task Sequence Not Displaying

Recently been testing an upgrade scenario from ConfigMgr 2012 SP2 to Current Branch 1702 and during the course of putting together the legacy environment I came across a strange issue I’d not seen before. Essentially it goes like this:

A new OSD task sequence is created (doesn’t matter whether it is MDT-infused or not) and is deployed to All Unknown Computers. In my case I was using boot media to reach the WinPE environment on my test VM but there were no task sequences displayed. Checking the smsts.log file in the WinPE environment, it suggests that no policies are found.

The first time this happened the task sequence eventually appeared after about an hour or so. The next day I created a new one and exactly the same thing happened, with just the old TS showing up. I then saw this thread and changed my new task sequence availability time back 1 day. Et voila, the task sequence appeared.

Hope this helps anyone else scratching their head…

OSD Scripting Hacks Part 4 – Renaming NICs

In a new series of short posts I’m going to show how to get around some frustrations I have had with the lack of GPO support for some common requirements plus a few other issues I have come across which have crept up recently.

More for a bit of fun really but this was another serious request I have had where a machine contained several adaptors, they should all be sequentially named to specification, in this case NIC1, NIC2, NIC3 ,etc.

Here’s the script. It renames the adaptor numerically and outputs to a logfile:

# Rename NICs
ForEach($nic in (Get-NetAdapter -Name *)) {
$number += 1
Get-NetAdapter -Name $nic.Name | Rename-NetAdapter -NewName NIC$number - PassThru | Out-File %WinDir%\Temp\NicName.log -Append

For MDT users I recommend using a commandline action as follows:

powershell.exe -ExecutionPolicy Bypass -command "$number=0; ForEach($nic in (Get-NetAdapter -Name *)) { $number+=1; Get-NetAdapter -Name $nic.Name | Rename-NetAdapter -NewName NIC$number -PassThru | Out-File %WinDir%\Temp\NicName.log -Append }"

That concludes this series for now until such time as another request comes my way…


OSD Scripting Hacks Part 3 – Disable NETBIOS in Powershell

In a new series of short posts I’m going to show how to get around some frustrations I have had with the lack of GPO support for some common requirements plus a few other issues I have come across which have crept up recently.

Another requirement that came up in my recent project was to disable the NETBIOS over TCP/IP setting function under the network adaptor settings | IPv4 properties | Advanced. The issue here is that there are multiple GUIDs present in the registry that must be changed and these can’t be easily predicted. Fortunately Powershell is kind to us and allows the use of a wildcard (*) to just hit them all. This is achieved with the following script:

 # Disables NETBIOS over TCP/IP
set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces\tcpip* -Name NetbiosOptions -Value 2

For MDT users, I recommend using a commandline action as follows:

powershell.exe -ExecutionPolicy Bypass -command "set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces\tcpip*' -Name NetbiosOptions -Value 2"

Next, renaming NICs!