Category Archives: Powershell

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.

GOAL:

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:

    1. DISABLE ALL BITLOCKER PRE-PROVISION STEPS
    2. DISABLE ROOT CERTIFICATE UPDATE
    3. STOP THE MBAM SERVICE
    4. ADD ENCRYPTIONMETHOD
    5.  ADD OSENCRYPTIONTYPE
    6. ADD  ENCRYPTIONMETHODWITHXTSOS
    7. ADD  ENACTONFIRSTLOGINREQUIRED
    8. REMOVE STARTUP DELAY
    9. START MBAM SERVICE
    10. FORCE USER TO SELECT A NEW PIN ON FIRST LOGIN
    11. RUN INVOKE-MBAMCLIENTDEPLOYMENT.PS1 SCRIPT
    12. RE-ENABLE ROOT CERTIFICATE UPDATE

1. DISABLE ALL BITLOCKER PRE-PROVISION STEPS

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.

2. DISABLE ROOT CERTIFICATE UPDATE

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

3. STOP THE MBAM SERVICE
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

4.  ENCRYPTIONMETHOD

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

5.  ADD OSENCRYPTIONTYPE
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

6. ADD ENCRYPTIONMETHODWITHXTSOS

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


7. ADD  ENACTONFIRSTLOGINREQUIRED

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

8. REMOVE STARTUP DELAY
Force MBAM client to wake up within a minute.

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

9. RE-START MBAM SERVICE

Net start mbamagent


10. FORCE USER TO SELECT A NEW PIN ON FIRST LOGIN
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"

11. RUN INVOKE-MBAMCLIENTDEPLOYMENT.PS1 SCRIPT
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


12. RE-ENABLE ROOT CERTIFICATE UPDATE
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!

Simon

 

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
$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
 }

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!

OSD Scripting Hacks Part 2 – Performance Settings

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.

In part 2, I will show you how to change the performance settings via a script which can be run from a task sequence step. Like the file extensions in Part 1, this was another area that (at the time of writing) seems frustratingly missing from group policy. I was creating an MDT task sequence recently to build some servers and one of the requirements was that the Visual Effects setting was specifically set for ‘Best Performance’ as opposed to Let Windows choose…

Anyway, the script:

# VisualFX - Best Performance
$RegKey ="HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects"
Set-ItemProperty -Path $RegKey -Name VisualFXSetting -Type DWORD -Value 2

For MDT, you may wish to run this as a commandline as follows:

powershell.exe -ExecutionPolicy Bypass -command "set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects' -Name VisualFXSetting -Type DWORD -Value 2"

In the above I set the value to 2 for best performance. Other values can be:
0 – Let Windows choose what’s best for my computer settings.
1 – for Adjust for best appearance settings.
2 – for Adjust for best Performance settings.
3 – for Custom settings.

OSD Scripting Hack Part 1 – Enable file extensions for all users

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.

First in the series is a build fix for file extensions. By default, these aren’t enabled and at the time of writing there isn’t a GPO that can be applied that applies them for users when they log on so they have to be enabled manually. Personally I find it frustrating that I can’t see what kind of file something is and it is usually the first thing I change when  I log into a new computer. Anyway, among others, this became a requirement for a recent project I was on and after a bit of playing around and further research I came up with the following Powershell script:

reg load HKLM\DefaultUser C:\Users\Default\NTUSER.DAT
 $path = "HKLM:\Defaultuser\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced"
 New-ItemProperty -Path $path -Name HideFileExt -Value "0" -Type DWord
 reg unload HKLM\DefaultUser

This should be run as a task sequence step but depending on your deployment tool of choice, Powershell commands can occasionally be a little fussy. If you are using MDT, you might find the following works better if set up as a commandline:

Powershell.exe -ExecutionPolicy Bypass -command "reg load HKLM\DefaultUser C:\Users\Default\NTUSER.DAT; New-ItemProperty -Path 'HKLM:\Defaultuser\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced' -Name HideFileExt -Value 0 -Type DWord; reg unload HKLM\DefaultUser"

The above should also work fine for SCCM although SCCM isn’t as picky as stand-alone MDT so either might work there.

Next time, Performance settings.

Can’t run PowershellInstance.invoke() from C# (but code is fine)

I recently wrote a GUI to duplicate MDT database roles based on the excellent Powershell commandlets written by Michael Niehaus:
http://blogs.technet.com/b/mniehaus/archive/2009/05/15/manipulating-the-microsoft-deployment-toolkit-database-using-powershell.aspx.
Although the Powershell code worked fine when executed directly in a Powershell window, I was seeing mixed results when executing the same code in C# through PowershellInstance.invoke(). Specifically, when I compiled the executable I was able to run the powershell code through the utility without issue, whereas it failed for my colleagues for some reason.

THE FIX

It seems that what I needed to do was ensure that the code was compiled specifically for the platform I was running it on as opposed to ‘any CPU’. In my case this was for x64. You can set this under the project properties in Visual Studio:

Platformx64

However, after making this change, I found I was getting compilation errors along the lines of:
An attempt was made to load an assembly with an incorrect format: [path to exe]

To fix this, I needed to change Generate serialization assemply to Off and everything compiled as expected. More on this here.

New-CMBoundary IPSubnet Doesn’t work

CM2012 introduces to us the ability to easily script many labour-intensive tasks. I was recently adding numerous boundaries to a ConfigMgr implementation for a client so decided the best approach was to automate this procedure.  I fired up the Powershell session from within ConfigMgr and checked the syntax for New-CMBoundary. Now, I had a spreadsheet with a bunch of IP subnets in CIDR notation so it made sense to use this for my script. Running Get-Help New-CMBoundary I got the following:

Example 1: Create a new IP Subnet site boundary
PS C:\>New-CMBoundary -DisplayName "IPSubNetBoundary01" -BoundaryType IPSubNet -Value "172.16.50.0/24"
BoundaryFlags: 0
BoundaryID: 6338009
BoundaryType: 0
CreatedBy: Contoso\PFuller
CreatedOn 6/10/2012 1:17:42 PM
DefaultSiteCode:
DisplayName: IPSubNetBoundary01
GroupCount: 0
ModifiedBy:
ModifiedOn:
SiteSystems:
Value: 172.16.50.0/24

Looks straightforward enough but no. This simply doesn’t work as stated. The problem seems to be that it doesn’t understand the ‘/24’ part (in this example). Instead, what you first need to do is to find the subnet ID which is associated with your address. If you’re unsure what this is then I’d recommend you use something like http://www.subnet-calculator.com/cidr.php:

cidrcalc

 

 

In the example above we have a CIDR range of 10.13.160.0/23. You can see from the calculator that this produces a network ID of 10.13.160.0. Therefore the correct syntax for New-CMBoundary is as follows:
New-CMBoundary -DisplayName “IPSubNetBoundary01” -BoundaryType IPSubNet -Value “10.13.160.0”
All that said, I’d personally avoid IPSubnet boundaries completely. Instead, just go for a range, far simpler to understand. The CIDR calculator is again helpful for this and displays the range at the bottom.
Thankfully, the IPRange syntax is correct so you shouldn’t have any issues.