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.

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.

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.

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

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 https://gallery.technet.microsoft.com/ConfigMgr-2012-R2-e52919cd. 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:
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.

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

Headaches of an SCCM Admin.