Windows Server

MDT/ADK Issues – Path Not Found

Posted by James F. Prudente on October 12, 2022
Posted in: Deployment, Windows 10, Windows 11, Windows Server. Tagged: , , . Leave a comment

Brief but important warning here about Windows 11 ADK/MDT.

We recently ran into a corruption issue with our imaging server that led us to reinstall some of Microsoft’s imaging components including the Assessment and Deployment Kit and the additional WinPE extension. Naturally we went for the latest version, which as of this writing corresponds to Win 11 22H2 build 22621.

After the reinstall, we ran into an issue where we could not run scripts from within WinPE. I added the missing scripting packages to the deployment share, but every attempt to rebuild the WinPE media resulted in errors.

Deployment Image Servicing and Management tool
Version: 10.0.22621.1
Image Version: 10.0.22621.1
Processing 1 of 1 - Adding package WinPE-Scripting-Package~31bf3856ad364e35~amd64~~10.0.22621.1
[======                     11.0%                          ]
[===========                20.0%                          ]
[==============             25.0%                          ]
[=================          30.0%                          ]
[====================       35.0%                          ]
[=======================    40.0%                          ]
[========================== 45.0%                          ]
[==========================100.0%==========================]
An error occurred - WinPE-Scripting-Package Error: 0x80070003
Error: 3
The system cannot find the path specified.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
Exit code = 3

I spent way too long trying to figure out why DISM was erroring trying to find a package file that was clearly available. Interestingly, Sysinternals Process Monitor did not show any file not found errors that seemed relevant.

Even more interesting was that the x86 WinPE image would build successfully with the scripting components. It was only x64 WinPE that failed while adding the additional packages.

I started looking at any obvious differences between the WinPE logs for x86 and x64, and one thing stood out: the version number for DISM and the WinPE image. The latest ADK shows x64 build 10.0.22621 but x86 build 10.0.22000.

Some quick research turned up this page which, in true Microsoft fashion, doesn’t quite tell the whole story. Per Microsoft, “The 32-bit versions of Windows PE are no longer included in the Windows PE add-ons starting with the ADK for Windows 11, version 22H2.” That doesn’t seem to be the case; although I didn’t install on a clean server to confirm, it looks like the 22H2 ADK still includes x86 WinPE components, just an older version.

Microsoft goes on to say that “The last supported version of 32-bit Windows PE is available in the Windows PE add-on for Windows 10, version 2004.” But that doesn’t seem to be accurate either. Win 10 version 2004 corresponds to build 19041, yet the x86 DISM included with the latest 22H2 ADK is 22000, which corresponds to Win 11 build 21H2.

At this point I had a path not found error that made no sense, and a version discrepancy that I also couldn’t explain. I wanted to try the 21H2 version of the ADK and see what happened, but Microsoft doesn’t list it for download on the page I linked above. Fortunately. I found a post by Prajwal Desai that included a link to the 21H2 ADK. Note that the download is direct from Microsoft.

I removed the 22H2 ADK and installed the 21H2 ADK. This gave me version 22000 for both x86 and x64 architectures. And perhaps not surprisingly at this point, the 22000 x64 build installs the scripting packages without issue.

So long story short, the 22H2 ADK is apparently bugged. Use the 21H2 ADK instead.

The Real-World Implications of PrintNightmare

Posted by James F. Prudente on August 23, 2021
Posted in: Group Policy, Permissions, Scripting, Windows 10, Windows Server. 1 Comment

PrintNightmare refers to a series of recent vulnerabilities in the Windows print spooler service. There are plenty of articles detailing the issues and Microsoft’s ongoing attempts to (partially) fix them. I’m not going to rehash any of those. What I do want to touch on is the real-world implication of Microsoft’s fixes.

Cutting straight to the point: The updates Microsoft released to fix PrintNightmare, which will of course be included in subsequent rollups, completely prevent non-admin users from receiving printer mappings through group policy and/or using the “internet printing” webpage to add printers.

Microsoft’s documentation does state that “non-administrator users will no longer be able to” “[i]nstall new printers using drivers on a remote computer or server” or “[u]pdate existing printer drivers using drivers from remote computer or server.” Unfortunately, because of the way the first statement is phrased, it isn’t as clear as it should be that standard users can no longer connect to a printer on a corporate print-server, unless they have the necessary driver pre-loaded.

I understand that Microsoft may not have many options for resolving the spooler vulnerability, but what they have pushed out is a fix that will make it quite difficult for IT staff to install printers on end-user PCs. For the many organizations out there using group policy, logon scripts, or other long-standing methods to connect printers to PCs, these updates broke significant functionality.

Unless you can quickly move to a new method of installing printers (System Center, Endpoint Configuration Manager, or a 3rd party platform), operational realities mean most of us are going to have to disable the security fix and make due with whatever other mitigations we can enable, such as limiting the servers from which a driver can be installed. It isn’t clear why Microsoft says that isn’t a full mitigation since end-user devices should be secure, as long as the print server itself is secure.

Aren’t you glad we’ve moved to a paperless office?

DHCP Registration of DNS Entries to an Alternate DNS Server

Posted by James F. Prudente on December 19, 2019
Posted in: Active Directory, Windows 10, Windows Server. 9 Comments

We are in the midst of a BYOD rollout, and one of the challenges we’ve faced is how to best provide DHCP services and DNS resolution to BYOD clients. On the surface these are not difficult items, but with BYOD you are inherently dealing with a variety of devices that are outside of your control, plus you obviously want them isolated from your production (secure) network. This implies a few things:

  • If you want BYOD devices registered in DNS, your DHCP server(s) will need to handle the registration and maintenance of DNS records.
  • A BYOD device that is behind your firewall yet physically isolated from production resources may need different DNS resolution than a domain-joined device. An example of this is a federation (ADFS) server; domain-joined devices connect to an “internal” ADFS server that does SSO, while non-domain devices need to connect to an ADFS proxy that accepts a manual login.

There are many posts about DHCP and/or DNS configuration, including how to handle DHCP registering DNS records. Rather than repeat anything, I’ll link to a few that I found helpful:

TechNet: Windows Server: Integration between DNS and DHCP

Ace Fekay: Dynamic DNS Updates…

Where things get a bit trickier (or perhaps less obvious) is when you want DHCP to register a client on a DNS server that is different from the DNS server assigned to that client. In our case, we want our BYOD devices registered on our Windows DNS servers, but the BYOD devices themselves need to query a DNS proxy rather than our Windows DNS servers.

We already had DHCP configured to register clients in DNS, but which DNS server? I could not find any reference for this, but based on packet captures and empirical evidence, this is what happens:

  1. DHCP queries the DNS server that is being assigned to the client for the address(es) associated with the DNS domain name in DHCP option 015
  2. DHCP then attempts to register the client on the address(es) returned by the prior query

Put another way…when DHCP offers a DNS server to a client via option 006, DHCP will query that same option 006 DNS server for the DNS Domain Name in option 015, in order to determine what DNS server the client should be registered on.

Long story short: the option 006 DNS server must have an entry that matches the option 015 DNS Domain Name, and resolves to the IP address of the DNS server where you actually want the clients registered.

802.1x Certificate Based Authentication against NPS on Windows Server 2016

Posted by James F. Prudente on September 20, 2018
Posted in: PKI, Windows Server. Tagged: , , . Leave a comment

When we were preparing to upgrade our domain controllers from 2008 R2 to 2016, we of course began inventorying all functions that were going to be migrated. One of these was Network Policy Server (NPS). NPS is one of the easiest services to migrate to a new system, since it’s basically a simple backup and restore, and we weren’t expecting any difficulties. Of course had things gone smoothly, this post wouldn’t exist.

A little background:

We use NPS for multiple functions, including Cisco AAA and wireless device authentication. Our Meraki wireless infrastructure has multiple SSIDs, some of which are for domain-joined devices, and others for non-domain devices. The domain-joined devices use 802.1x certificate-based authentication and the non-domain joined devices use various other methods.

NPS was migrated from 2008 R2 to 2016 and everything other than the 802.1x certificate authentication worked. The 2016 servers were correctly setup as RAS servers and had certificates that were valid for client & server authentication, as needed. I spent quite a long time troubleshooting this with no success, and eventually had to back-burner it. The 2008 R2 servers were due to be retired, so as a temporary measure I migrated NPS to a couple 2012 R2 servers, all of which worked flawlessly after about two minutes worth of effort.

This was pretty early in 2016’s lifecycle, so since it worked in 2008 R2 and 2012 R2, we chalked it up to a bug in the OS and intended to pursue it with Microsoft at a later date.

Before I had a chance to call Microsoft, another project had us looking at our PKI configuration. We were having issues using LDAPS with this particular system (despite using it elsewhere), and after extensive troubleshooting the vendor told us they thought the hash algorithm used by our PKI was unsupported.

Our PKI was originally setup on a 2003 server back when that was the current server OS. It had been migrated to a newer server since then but the hash algorithm had never been changed; it was still using md5RSA. Now upgrading the hash algorithm isn’t something to be taken lightly, as it can break a lot of things, but in our case since our PKI is pretty simple I decided (after backing everything up) that the upgrade risk was minimal. I changed the hash algorithm to SHA256, reissued RAS certificates to the NPS servers and just like that things started working.

I can’t find any changelog indicating why NPS would not work with an older certificate hash on 2016 but empirical evidence shows the hash was the problem.

There are plenty of resources about upgrading your root CA’s hash algorithm, but this is a good start from Jason Bender at Microsoft.

Monitoring Microsoft NLB with PowerShell

Posted by James F. Prudente on June 21, 2018
Posted in: Active Directory, ADFS, PowerShell, Windows Server. Tagged: , , , . Leave a comment

Recently the need arose to monitor the status of a Microsoft NLB cluster. There are a number of ways of approaching this, but PowerShell seemed like the cleanest.

I found this script on TechNet but found that it did not work in our (2008 R2) environment. During troubleshooting, what I found was that instead of returning a single status result, the WMI query was returning an array of results for each server. It appears that the statuscode is only relevant for the specific hostpriority applicable to each server.

For instance, this is the server with hostpriority 1 as shown in the NLB Manager:

And this is the one with hostpriority 2:

As you can see, a proper statuscode is only returned for the current hostpriority for each server.

With that in mind I made a change to the script to enumerate through the array of results for each server and check the status accordingly. This has only been tested on ADFS 2.0 on 2008 R2 servers, and it would need to be revised if you have more than two servers in a NLB cluster.


#Define Nodes
$node1 = "SERVER01"
$node2 = "SERVER02"

#get NLB status on NLB Nodes
$Node1status = Get-WmiObject -Class MicrosoftNLB_Node -computername $node1 -namespace root\MicrosoftNLB | Select-Object __Server, statuscode, status, hostpriority
$Node2status = Get-WmiObject -Class MicrosoftNLB_Node -computername $node2 -namespace root\MicrosoftNLB | Select-Object __Server, statuscode, status, hostpriority

$node1converged = $false

Foreach ($status in $Node1status)
{
if(($status.hostpriority -eq "1" -and $status.statuscode -eq "1008") -or ($status.hostpriority -eq "2" -and $status.statuscode -eq "1007"))
{
$node1converged = $true
write-host "NLB Status of $node1 is: Converged"
}
}

Foreach ($status in $Node2status)
{
if(($status.hostpriority -eq "1" -and $status.statuscode -eq "1008") -or ($status.hostpriority -eq "2" -and $status.statuscode -eq "1007"))
{
$node2converged = $true
write-host "NLB Status of $node2 is: Converged"
}
}

Sorry about the indents; they show up in the WordPress editor but not on the actual page.

Let me know if you find this useful, or if you are able to use it on a platform other than 2008 R2.