All posts by bondy

Something went wrong, OOBE

Just a really short post on an issue I saw a little while back which I’ve been meaning to get round to documenting.

Whilst working on VM optimization project, I booted up one of my VMs for testing and received the above message during the OOBE stage. Turns out, the reason for this is because I disabled one of the scheduled tasks which I thought looked fairly innocuous, CloudExperienceHost. Turns out this is important to leave enabled, even if you don’t want your VMs connecting to the cloud as the Out of Box Experience uses it. Specifically, the task can be found under:


Resolution : Enable task

I appreciate there are probably other reasons for this error message but this was what the issue was for me.

Add SSL Certificates For SCCM

Arguably there are newer and more fancy ways to do this in recent iterations of SCCM. If you wish to set up a standard internet facing SCCM environment or just an SSL secured environment this is the old skool way.


  1. Open CA | Right-Click Cert Templates > Manage
  2. Right-Click Web Server template > Duplicate template
  3. Open new duplicate template :
    a Request Handling tab: Check ‘Allow private key to be exported’
    b General tab : Change name to “ConfigMgr IIS Cert”, validity 5 years
    c Subject name : default (‘supply in the request’ should be checked)
    d Security tab : remove the ‘Enroll’ permission from Domain Admins and Enterprise Admins, add your SCCM_Site_Servers group and add Enroll and read permission to this group | Click OK
  4. Open CA | Right-Click Cert Templates > Manage
  5. Right-Click Workstation Authentication template > Duplicate template
  6. Open new duplicate template :
    a Compatibility tab: keep defaults (ensure Windows Server 2003)
    b General tab : Change name to “ConfigMgr DP Cert”, validity 5 years
    c Security tab : Add your SCCM_Site_Servers group and add Enroll and read permission to this group | Click OK
  7. Right-Click Workstation Authentication template > Duplicate template
  8. Open new duplicate template :
    a Compatibility tab: keep defaults (ensure Windows Server 2003)
    b General tab : Change name to “ConfigMgr Client Cert”, validity 5 years
    c Security tab : Click ‘Domain Computers’ group and add AutoEnroll and read permission to this group (don’t uncheck ‘enroll’) | Click OK
  9. Open CA | Right-Click Cert Templates > New > Certificate Template to issue
  10. Select the three new certs from the ‘Enable Certificate Templates’ box. | Click OK
  11. Open the GPMC, open default domain policy (or wherever you have your PKI policy)
    a Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
    b Open up ‘Certificate Services Client – Auto-Enrollment’. Change ‘Configuration Model’ to ‘Enabled’
    c Check ‘Renew expired certs…’ and ‘Update certificates that use cert templates’


  1. On the DP open the certificate MMC > Computer > Personal > Certificates | Right-click folder > All Tasks > Request New Certificate
  2. Next > Next | On ‘Request Certificates’ page check ‘ConfigMgr DP Cert’ and click ENROLL > Finish
  3. While still in the certs MMC, Right-click the DP cert you have just imported > All Tasks > Export > Next. Select Yes, export private key
  4. Keep defaults on Personal Information Exchange – PKCS #12 (.PFX) and click next.
  5. Enter a password > Next > Save the file as C:\Temp\SCCM_DP_Cert. Click finish
  6. On the MP open the certificate MMC > Computer > Personal > Certificates | Right-click folder > All Tasks > Request New Certificate
  7. Next > Next | On ‘Request Certificates’ page check ‘ConfigMgr IIS Cert’ and click ‘moe information is needed…’ link
  8. Under Subject Name, select ‘Common Name’ and add the name of the server, eg SCCMMP01 > Add
    9.Under Alternative Name, select DNS and add the FQDN of the server > Add
  9. Under the GENERAL tab, add the name of the server as the friendly name
  10. Under the Cert Authority tab, select your CA if it’s not already selected. Select Enroll > Finish.
  11. On the MP (internet facing if there is one) open IIS > Default Web Site > Bindings… | Edit HTTPS
  12. Select the new SSL certificate. If you don’t see HTTPS, click add and create it.
  13. Repeat the above on any other MPs
  14. From the SCCM console go to Admin\Overview\Site Configuration\Sites | Properties > Client Computer Communication. Add the Root CA Certificate you created earlier.
  15. FINALLY!!!! Go to Admin\Overview\Distribution Points | Properties and add the certificate and password you created on the DP in point #5. Rinse and repeat for all your DPs.
    Just select YES if you get a message about it being a copy of one used on another DP.
  16. To add certs for the SUP/WSUS see

Build a Certificate Authority, Step By Step

I have just had to do this so I thought I’d make the most of the ordeal by documenting. I make no apologies here – I am giving you the bare minimum click-by-click. I’m not attempting to tell you what you’re doing along the way as this post will just be too long. As long as you do everything as indicated and don’t take any shortcuts, you should be fine. If you previously had a CA in place, I recommend you fully uninstall them before starting.

You will need two VMs, one domain joined (IssuingCA) and the other just in a workgroup (RootCA). In my example below, my rootCA is and my Issuing CA is These names make up some of the cert names in the instructions below so please ensure you substitute as appropriate for your environment. One final caveat : this was put together on Windows 2012 R2 so there maybe one or two minor changes to the interface in places but honestly not much has changed in years…


  1. Workgroup computer, Install cert services
  2. Go thru config wizard, Select:
    a Cert Authority
    b Standalone CA
    c Root CA
    d New private key
    e All default crypto options
    f Default names
    g Default Validity (5 years)
    h Default db locations
    i Click CONFIGURE
  3. Open Cert Authority > Properties > Extensions > Add CDP
    b Check Include in CRLs…
    c Check Include in CDP extension…
    d Select AIA from cbobox > Add AIA
    f Check ‘Include in the AIA extension…’
    g Restart services when prompted.
  4. Publish CRL by going to Revoked certificates node | right click > all tasks > Publish
  5. crl and crt published at C:\Windows\system32\CertSrv\CertEnroll. Copy this path to clipboard.
  6. ROOTCA properties > General > View Certificate #0 > Details > Copy to file > Next DER Encoded > Next > save as C:\Windows\system32\CertSrv\CertEnroll\RootCACert.cer
  7. Browse to \IssuingCA\C$\Temp\Certs and drop the three certs in the folder


  1. Open the GPMC, open default domain policy (or some other if preferred)
    a Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
    b Right-click > Import > Next > browse to \IssuingCA\C$\Temp\Certs\RootCACert.cer > Next > Finish
  2. Run GPUpdate /force and you should see your new certificate appear under ‘Trusted Root Cert Authorities’ in Certificate manager MMC.


  1. Install Certificate Authority with all Role Services
  2. Once complete, in SVRMGR click the yellow triangle for post config.
  3. Specify creds or leave default | Next
  4. Select Cert Auth, Cert Auth Web Enrollment | Next
  5. Select Enterprise | Next
  6. Subordinate CA | Next
  7. Create a new private key | Next
  8. All default crypto options | Next
  9. All default names | Next
  10. Default req filename and location (C:\SVR-CA-02.BONDYNET.org_BONDYNET-SVR-CA-02-CA-2.req) | Next
  11. Default db location | Next | Configure | OK. Don’t configure additional roles when prompted for out purposes here.


  1. On the root CA, browse ro \IssuingCA\C$ and copy C:\SVR-CA-02.BONDYNET.org_BONDYNET-SVR-CA-02-CA-2.req locally.
  2. In CA MMC console > | Right click > All Tasks > Submit New Request > Select SVR-CA-02.BONDYNET.org_BONDYNET-SVR-CA-02-CA-2.req > OK
  3. Go to Pending Node top see the new certificate. Right-click > All Tasks > Issue
  4. Under ‘Issued Certificates’ node, right-click > Open > Details tab > Copy to file > Next
  5. Select Cryptographic Message Syntax Std (.P7b) and select ‘Include all certs in path’. | Next
  6. Open Browse and you should be in the CertEnroll directory. Call the cert ‘IssuingCACert’ | Next | Finish | OK | OK
  7. Copy the new .p7b certificate to the \IssuingCA\C$\Temp\Certs\ location.


  1. Create a new folder at C:\inetpub\wwwroot\CertData
  2. Copy the .crt file and the .crl file from C:\Temp\Certs to C:\inetpub\wwwroot\CertData
  3. Open the CA console on the Issuing CA. Right-click servername > All Tasks > Install CA Certificate. Select The new p7b certificate.
  4. Start the CA service from the MMC console. If you get an error (CRYPT_E_REVOCATION_OFFLINE) see
  5. Switch off the root CA!


  1. Create two service accounts domain users only, CESvcCert and NDESvcCert and add these to the local IIS_IUSRS group
  2. Click the yellow triangle in svrmgr and check all the unchecked roles | Next
  3. Under Service account for NDES, enter the NDES svc Account | Next
  4. Use defaults for RA Information | Next
  5. Use defaults for Crypto | Next
  6. Under CA for CES, keep defaults | Next
  7. For Auth type, select User name and password | Next
  8. Under Service Account for CES, enter the CESvcCert Account | Next
  9. For Auth type, select User name and password | Next
  10. For Key-bases renewal for CEP check Enable key-based renewal | Next | Configure

You’re all done for the CA. Now for the certs…see next post!

Simple Configurable Front End SCCM

The business of adding a front end for a PXE-driven SCCM OS build is generally a pretty important consideration if you want to specify some basic information prior to deployment. It’s also something that I’ve felt has never been properly addressed by the SCCM development team. To be fair you could argue it’s not their job to do this but with more functionality being adding to every single aspect of SCCM in every new release, it does feel like something that probably should be looked at in the future.

For now, there are plenty of examples of great front ends on the internet – look up ‘Pretty Good FrontEnd’ by Johan Arwidmark or ‘Pretty Good Front End Clone’ by Maik Koster. These two have been around donkey’s years. One of my favourites is Nicolaj Andersen’s very neat ConfigMgr Front End which offers a whole world of features. Additional infrastructure is necessary to accommodate this however, in the form of web services.

So why create another? Well I’m certainly not pretending to  set the world alight with some kind of ingenious new approach but I always felt there was just a little too much fiddling about with most of the solutions I saw elsewhere. What I wanted was something I could ideally just drop straight into my WinPE image which would just work.  There are certainly features I could add (and may indeed do so if enough people ask) such as ability to remove certain sections, eg, domain, OS, etc. However in an effort to keep things simple I have left this for now.

The Front End

This is a typical illustration of what it looks like in my lab. Most aspects are configurable via a small ini file (yes I know it’s a bit 90’s but let’s face it, it’s a damn sight easier to use than an xml file for this kind of thing). The ini file below is configurable for the OUs in your environment, the domain (or domains) and even colour and font size. One area I went a little off the beaten track is the ability to select different images you want to use in your task sequence. This is great in my lab as I often want to test stuff out on different OS’s and will routinely add a new image when necessary to my tried and trusted task sequence.  As such I’ll detail this a little more.

If you want to use the same task sequence but have different images available in that sequence, you can enter them in the ini file. Just be sure to enter the appropriate option/filter in appropriate task sequence step. For example, in the image above we have  a number of different OS’s which relate to separate images. Under the INSTALL section of your task sequence you might have one or more separate steps to Install Windows 10, Install Server 2016, etc. On each of these steps, click Options and add a Task Sequence Variable condition, eg:

TS VARIABLE: OSDImage Equals <Windows 10 1803>

It is important that the text in the OS box above equals the OSDImage value of your condition. 

Of course, you can just add a description in the Config.ini file instead and have one image step in your task sequence with no condition set and all will be well. I suspect this is what most people will want. The option to do it this way is just there if you want it.


Typical Config.ini settings below. This file must always exist in the exact same folder as the NewFrontEnd.exe executable.

:: [ORG_UNIT] - Enter all OUs you want displayed in format OU=Dept, OU=Org, DC=domain, DC=suffix one after the other.
:: [DOMAIN] - In most cases, this is more for show but can be used to build a workgroup machine too if WORKGROUP is specified underneath the primary domain.
:: [OS] - If your task sequence can build more than one image, add it here, eg Windows 10 1607 LTSB. Then add a task sequence variable condition called OSDIMAGE and equal it to the image name in your TS.

:: [MISC]
:: LOGO, recommended max size is approx W:120, H:120 for a font size of 8-10
:: BACKGROUND, Enter standard OS colour names, eg Red, DarkRed, Marroon, MidnightBlue, etc
:: FONTSIZE, recommend, 8-10 but it will go bigger. Seems to jump in 2s, eg, 8,10,12, etc. This has a bearing on the size of the form.
:: FONTCOLOR (American spelling, sorry) see BACKGROUND, above.
:: SMSTSPREFERREDADVERTID, If specified, enter the Deployment ID of the task sequence you want to run. This will override any other advertised task sequence either 'available' or 'required' and the wizard won't show.

:: HIRESDISPLAY, If HIRESDISPLAY=True the size of the form is increased so it doesn't get 'scrunched up' on the display. This has been tested against a Surface Pro 4.

:: NOTE - [ORG_UNIT], [DOMAIN] and [OS] should all have at least one value (ideally) so the interface has something to show. Settings under [MISC] can be removed or ignored by adding a semicolon before the setting.

OU=Secure Workstations,OU=Bondynet,DC=BONDYNET,DC=org


Windows 10 1803
Windows 10 1607
Windows Server 2016
Windows 2012 R2
Windows 10 1607 LTSB
Windows 7
Windows 8.1
Windows Server 2008


WinPE Setup

So how do you get this working in WinPE?

  1. Create a share somewhere and drop NewFrontEnd.exe, Config.ini and your company logo png into it (and/or possibly RunFEUI.vbs – see end of post)
  2. In SCCM go to your chosen boot image, right-click | properties | Optional Components. Select Microsoft .NET (WinPE-NetFx). This is a C# application so it needs this option available in your boot image binaries.
  3. Select the Customisation tab. Under Prestart Command Settings enter “X:\sms\PKG\SMS10000\NewFrontEnd.exe”
  4. Select Include files for the prestart command
  5. Select the share you created above with the files in for the source directory.

If you want to, add a background, click OK  and you’re done. After the update distribution points wizard has completed, double check the Last Update information in the bottom section of the SCCM console to ensure the time matches the time you ran the wizard and everything has updated as it should. This is important as it hasn’t usually finished updating just because the wizard progress bar has completed.


For The Adventurous.

One of the neat things about using the above method is that there is no ugly command prompt in the background as it brings up the front end interface. However the downside of this is that all the files are inside your WinPE image so if you want to update them you have to go through the above process once again which is both time consuming and laborious. One solution though is to simply point to a script that will map a drive to a share that exists elsewhere on your network and execute the files from there instead. This facilitates updating the files on the fly.

In the zip file included below, there is a file called RunFEUI.vbs. Simply open it and edit it to fit your environment (ie edit line 4 with the appropriate drive mapping and account).



Please ask any questions or suggestions for improvements in the comments below.

[*** UPDATE ***]

I have added a new variable, HIRESDISPLAY=True. If you have a Surface or another slate type device, it is common to see forms get squashed up. Set this if you need a larger form to display.

Office 365 Client Updates Not Showing Up in SCCM Summary as ‘Required’

Had a tag-team of problems with Office 365 Client updates and this one reared its ugly head just a I managed to successfully get the O365 updates syncing successfully.

The Problem

Under Software Library|Office 365 Client Management|Office 365 Updates none of the client updates were checking in as ‘required’. Given that the O365 client on 5000-odd machines was at version 16.0.8201.2207 (v1705) this seemed odd to say the least. Everything was set correctly in SCCM for O365 Client Deployment so the summary screen should theoretically be showing that the whole estate needed at least every version beyond this.

The Solution

After some considerable digging I discovered that for updates to work in SCCM, the CDNBaseUrl and the UpdateChannel settings in the registry MUST BE IDENTICAL. In my case, whoever had packaged the application had a bogus entry in the UpdateChannel setting that made no sense. I copied the CDNBaseURL setting (something along the lines of into the UpdateChannel setting, restarted the Microsoft Office Click-To-Run service and ran an update scan and update deployment policy refresh from the SCCM control panel applet. Immediately O365 client updates showed up as required. This can be checked under the following ConfigMgr report:

Compliance 8 – Computers in a specific compliance state for an update (secondary)

I then set up a GPO to push this URL out to the estate and watched the count increase.

OneDrive For Business out of space – plenty of room left!

I have recently been doing some work for a customer who has introduced OneDrive to their estate. For reasons known only to them, they have insisted that their users have their OneDrive storage restricted to only 1GB. Not much in today’s  money.

The issue that I have been seeing (on more than one occasion) is that OneDrive would run out of space (denoted by a red cross over the blue cloud icon) yet if you were to look at what the folder contained, clearly there should be space left. On one occasion there should have been as much as 700MB left so I was left scratching my head as to why it was complaining it was full.


This is what has worked for me when I have come across the above scenario, and mainly involves removing the versioning feature, which by default will store 500 major versions.

  1. Completely clear out the local OneDrive folder. Cut and paste the data into a local temp folder somewhere, eg C:\Temp\OneDrive
  2. Right-click OneDrive icon and select View Online.
  3. Select Recycle Bin from the menu on the left. Click Empty Recycle Bin. This can take a little while sometimes, be patient and ensure it’s properly emptied.
  4. Once empty you should see a line at the bottom of the screen: Can’t find what you’re looking for? Check the Second-stage recycle bin. Click the Second stage recycle bin link.
  5. Delete everything in the second-stage recycle bin.
  6. Click the cog/gear icon in the top right of OneDrive. A setting menu should open. Select Site Settings.
  7. Under Site Settings | Site Administration click Site libraries and lists.
  8. Click Customise “Documents”
  9. Click Versioning Settings.
  10. Under Create a version each time you edit a file in this document library? select No versioning.
  11. Select OK at the bottom of the screen.
  12. Recommended: Remove OneDrive from the computer. Also ask user to save any profile related settings (favourites, desktop icons, etc) and remove user’s profile in System|Advanced Settings|User Profiles|Settings
  13. Get the user to log back on and restore the user’s desktop and favourites.
  14. Reinstall OneDrive. Once configured, copy user data back to the user’s local OneDrive directory and wait to sync.

The above steps were successful in releasing the ‘used’ space. Bare in mind, no version history will be kept in this scenario so please ensure that this is acceptable first. Without step 12, I did see the problem come back in one instance so if possible, I’d strongly recommend this step. You must bare in mind that when this procedure is carried out, it is like the user logging on for the first time and any customisations to their local profile WILL BE LOST.

Good luck.

Failed to download file- “” from internet. Using proxyserver – 0. Error = 12029

This one caught me out recently. Scenario:

All is whitelisted and available, definitely no issue there.

  • All other updates seem to come down fine.
  • There are no ADR rules at all in place.
  • Running a full sync produces the error below:

My client downloads updates through a proxy server and naturally the correct details for the proxy were in place on the Site System Settings under Site System Roles. Also the checkbox for Use a proxy server when synchronizing software updates was checked under the Proxy And Account Settings tab under the Software Update Point Properties role.


Despite the fact that ADRs were NOT created or used in any way, it transpired that the checkbox Use a proxy server when downloading content by using automatic deployment rules also had to be checked. Once this was selected, O365 updates started syncing.


PXE only works for X number of clients; DHCP works fine

Difficult to pick a snappy title for this so suggestions welcome!

Anyway, I had an issue recently where we needed to load test 100+ machines, all booted from PXE. All machines were fresh out the box and all ethernet adaptors were fully registered in SCCM in the ignore list. In short, there was no reason for any machine not to PXE boot as expected. All went well until the 29th machine and then every machine thereafter refused to PXE boot. However, they did still receive an IP address. Additionally, the message Server response timeout E-18 flashed up very quickly before booting from the SSD.

Digging a little further, the machines that were able to PXE boot fine had to receive an IP address between .2 and .31 to work. Any IP after just refused to work.  Having accepted that all was well from a firewall perspective, I was forced to concede that the problem was somehow local.


To cut a long and boring story short, the problem turned out to be a mis-configured subnet mask on the PXE server, in this case instead of the that it was supposed to be. The PXE server itself was allocated an IP within the range of PXE bootable clients and anything outside the range didn’t work. So easy when you know but one expects the basics to be correct so it took a while to track down. Hopefully this will provide some more ideas for anyone else who finds themselves with a similar issues.

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!