Category Archives: OSD / SCCM / MDT

C#, ConfigMgr 2012, ConfigMgr Current Branch, Front End, OSD / SCCM / MDT, PXE, SCCM, Windows 10

Simple Configurable Front End SCCM

Leave a comment

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.

CONFIG.INI

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.

[ORG_UNIT]
OU=Workstations,OU=Bondynet,DC=BONDYNET,DC=org
OU=Servers,OU=Bondynet,DC=BONDYNET,DC=org
OU=Secure Workstations,OU=Bondynet,DC=BONDYNET,DC=org

[DOMAIN]
BONDYNET.org
WORKGROUP

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

[MISC]
LOGO=logo-3.png
BACKGROUND=LightSteelBlue
FONTSIZE=8
FONTCOLOR=Black
SMSTSPREFERREDADVERTID=PR120019

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

DOWNLOAD HERE:

NewFrontEnd_v1.2

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.

OSD / SCCM / MDT, PXE, SCCM

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

Leave a comment

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.

Solution:

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 255.255.255.224 instead of the 255.255.255.0 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.

ConfigMgr 2012, DISKPART, OSD / SCCM / MDT, SCCM, SCCM 1511, SCCM 1602

0x8007000f Task Sequence Error

2 Comments

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

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.