OSD / SCCM / MDT, Server 2012 R2

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

Leave a comment

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:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/d82dd905-e346-4a94-87e6-a78d59f4941c/keyboard-layout-wrong-on-logon-screen-but-fine-on-desktop?forum=windowsserver2008r2general
or
http://windowsitpro.com/systems-management/how-do-i-configure-default-keyboard-layout-during-login

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.

ConfigMgr 2012, OSD / SCCM / MDT, SCCM

New OSD Task Sequence Not Displaying

Leave a comment

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 / SCCM / MDT, Powershell, Programming and Scripting

OSD Scripting Hacks Part 4 – Renaming NICs

Leave a comment
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 / SCCM / MDT, Powershell, Programming and Scripting

OSD Scripting Hacks Part 3 – Disable NETBIOS in Powershell

1 Comment
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 / SCCM / MDT, Powershell

OSD Scripting Hacks Part 2 – Performance Settings

Leave a comment
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 / SCCM / MDT, Powershell

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

Leave a comment
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.

SCCM

Getting INVOKE-MBAM-PS1 SCRipt to run

Link Leave a comment

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

    Surface, Uncategorised

    Sign PDF Documents with the Surface Pen

    Leave a comment

    In my occasional series on Microsoft Surface-related posts, I thought I’d just do a quick one on signing a document. This seems like the type of thing you’d want to use the Surface pen for, right? Well it’s probably the single most useful thing I would want to use it for anyway. The trouble is, by default at least, when you open a PDF it opens up in Edge and you are unable to use the pen to sign with…

    You’ll also probably find it doesn’t seem to work in Adobe Reader and many other PDF readers. However not to worry – there is a built in reader app that can help with this very task! I feel a little stupid for only just realising this but try opening the app in Drawboard PDF and you can make adjustments with your pen to your heart’s content – and then save them. Great.

    You’re probably thinking I can’t believe he only just found that out and frankly, after owning my Surface for 10 months I’m kind of thinking the same. I can only assume that I’m not the only one to realise this late in the day and hopefully I can help others see the light.

    SCCM, SCCM 1511, SCCM 1602, Software Updates

    WSUS / SUP : System.Net.WebException: The request failed with HTTP status 401: unauthorized.

    Quote 1 Comment

    I noticed recently that after an extended period of being switched off, the Software Update Point in SCCM lab looked extremely poorly. I’m not sure why this was or if it had anything to do with being switched off for several days but in any case here is the scenario:

    WSUS lives on a separate server to my site server and SQL is on another separate box (I know, better to install it on the same box as site server but I find few customers these days that’ll let me do this so I keep it this way to replicate their environments as far as possible). Anyway I digress; the setup is as follows:

    Comms: HTTPS / SSL throughout  for SCCM and for WSUS.
    Version: Current Branch 1606
    OS: Server 2012 R2  (WSUS 6.2, commonly referred to as WSUS 4.0)

    After noticing some errors in my component status messages with regard to WSUS, I checked the WSUSCtrl.log and saw the following message appearing every minute or so:

    System.Net.WebException: The request failed with HTTP status 401: Unauthorized.~~ at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)~~ at Microsoft.UpdateServices.Administration.AdminProxy.GetUpdateServer()~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String ServerName, Boolean UseSSL, Int32 PortNumber)
Failures reported during periodic health check by the WSUS Server UT1.BC.LOCAL. Will retry check in 1 minutes

    Furthermore, if I ran WSUSUtil checkhealth on the SUP, my Application Log read as follows:

    The Reporting Web Service is not working.
 The API Remoting Web Service is not working.
 The Server Synchronization Web Service is not working.
 The Client Web Service is not working.
 The SimpleAuth Web Service is not working.
 The DSS Authentication Web Service is not working.
 On 13/10/2016 19:56:06, component SMS_WSUS_CONTROL_MANAGER on computer UT1.TEST.LOCAL reported: WSUS Control Manager failed to configure proxy settings on WSUS Server "UT1.TEST.LOCAL".

Possible cause: WSUS Server version 3.0 SP2 or above is not installed or cannot be contacted.
 Solution: Verify that the WSUS Server version 3.0 SP2 or greater is installed. Verify that the IIS ports configured in the site are same as those configured on the WSUS IIS website.You can receive failure because proxy is set but proxy name is not specified or proxy server port is invalid.

    Not good. Fortunately the fix was straightforward:

    I ran c:\Program Files\Update Services\Tools\wsusutil.exe configuressl ut1.test.local
    and then I saw URL: https://ut1.test.local:8531 appear on the screen.
    Then restarted the IIS services (IISAdmin, WWW) and all sprang to life. An IISReset would probably have done the same thing. After this the log should start to look like that below.

    wsuslog

    (Open image in a new tab to see more clearly)

    Assuming you are configured for SSL and for some reason you see something like URL: http://ut1.test.local:8530 instead, then most likely the SSL settings for WSUS are probably incorrect. Ensure you have the settings below in place in IIS:

    1. WSUS Administration. SSL Settings should be unchecked / ignore.
    2. ApiRemoting30. SSL settings should be checked / ignore.
    3. aspnet_client. SSL settings should be unchecked / ignore.
    4. ClientWebService. SSL settings should be checked /ignore
    5. Content. SSL settings should be unchecked / ignore.
    6. DSSAuthWebService. SSL settings should be checked/ ignore.
    7. Inventory. SSL settings should be unchecked / ignore.
    8. ReportingWebService. SSL settings should be unchecked / ignore.
    9. SelfUpdate. SSL settings should be unchecked / ignore.
    10. ServerSyncWebService. SSL settings should be checked / ignore.
    11. SimpleAuthWebService. SSL settings should be checked / ignore.

    Headaches of an SCCM Admin.