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?

Office 365 Folder Naming Conflict

Posted by James F. Prudente on July 14, 2021
Posted in: Office 365. Leave a comment

I ran into what is either a nasty bug or an undocumented “feature” in OneDrive for Business recently.

Let’s say you create a OneNote Notebook named “MyStuff” and then create a folder in the same location as the notebook, also named “MyStuff”; OneDrive will allow you to do this and on the surface there is no reason it shouldn’t. I managed to do this inadvertently, and the first sign something was wrong was that the folder itself was completely invisible in the OneDrive UI, or in the modern file dialogs within the Office suite. It was however perfectly visible from the old-style Explorer file dialogs, and I could access files without a problem so long as I used the older dialogs.

The real problem started when I tried to rename the folder and lost the ability to access any of the files contained within. After some investigation, what I found is that because of the file and folder sharing a name, when it seemed to me that I was saving to the folder, I was actually saving within the OneNote notebook, as if it was a folder. Except that the files were not there if I opened the notebook itself.

I’m not even sure what I did to get the files back, as rather than documenting the recovery process I was busy questioning why I hadn’t just saved to my NAS.

It seems as if somehow OneDrive created something like a symlink between the folder and file, and renaming the folder broke that link. I can’t imagine that this is deliberate behavior but these days one never knows.

So long story short…don’t do this!

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.

Making Sense of Office 365 Pro Plus and Office 2019

Posted by James F. Prudente on November 5, 2018
Posted in: Office 365. 1 Comment

Office 2019 recently released and accordingly, you may be looking into the upgrade process and any challenges it may bring. We recently found ourselves in this situation and the upgrade is, unfortunately, anything but simple. My usual disclaimer applies: some of the information below is a result solely of my own experiences in trying to upgrade our organization. If there are any errors, please comment and let me know.

MSI vs. Click-To-Run

Prior versions of the Office Suite used the well-known MSI format. MSI allows the use of Group Policy for network installs, and most large organizations have plenty of experience with the format. So of course Microsoft had to fix something that wasn’t broken.

Office Pro Plus 365 and Office 2019 (I’ll cover the differences in a moment) use Click-To-Run technology (CTR) which Microsoft touts as a “modern” deployment method.

Here’s a quick comparison of the two methods:

MSI

  • Deployed via Group Policy
  • Installs from local media
  • Patches directly from Windows Update or through WSUS

CTR

  • Deployed via the Office Deployment Tool
  • Installs from local media or directly from the Internet
  • Patches directly from the Internet or from a network share (not through WSUS)

There are plusses and minuses to both methods, but CTR is seemingly the future so we have no choice but to deal with it.

Product Channels

For all practical purposes, there are five variants of the current Office Suite, each of which is considered a “channel.”

  • Office 365 Pro Plus Semi-Annual
  • Office 365 Pro Plus Semi-Annual (Targeted)
  • Office 365 Pro Plus Monthly
  • Office 365 Pro Plus Monthly (Targeted)
  • Office 2019

The 365 SKUs are retail, and their license is tied to an appropriate Office 365 subscription that includes the Office Suite. You can choose to get either monthly or semi-annual feature updates, while security patches are applied regularly regardless. The “targeted” channels are essentially “sneak-peeks” of upcoming changes.

Where it gets confusing is that Office 2019 is essentially nothing more than a point-in-time snapshot of Office 365 Pro Plus, that will not get any feature updates; it will receive security updates only. This version is also the only one that can be volume-licensed using KMS.

As of November 1st, the most recent O365 Pro Plus Semi-Annual channel is version 1803, Office 2019 is considered version 1808, while the O365 Pro Plus Monthly channel is 1809, and the monthly targeted channel is 1810. Each has different feature sets. See Microsoft’s update history for O365 Pro Plus for more info.

Licensing

As mentioned, any of the Pro Plus channels imply retail licensing, and they must be activated against an Office 365 account that is entitled to the appropriate applications. This is fairly straightforward in an office setting where people don’t switch computers too often, but it poses a challenge in a school or other shared computer setting. In this case, you want to use shared computer licensing, and ideally license token roaming as well.

Office 2019 implies volume licensing, either using MAK or KMS. In this sense it’s identical to prior volume-licensed versions of the Office Suite. Note your KMS server will need an update to activate Office 2019.

Installation

Whether you want to install Pro Plus or 2019, and regardless of the desired channel, you will need to use the Office Deployment Tool (ODT). Essentially you will need to create an XML file that defines various options, including the desired channel, the installation source, and the update method. Microsoft’s documentation is actually pretty thorough, so you shouldn’t run into too many problems. There are a few caveats though:

  • The setup.exe that you run to install the suite is actually just a stub installer. In some cases (and I haven’t yet figured out the specifics), setup.exe will terminate successfully before the apps are installed. There is a further installer that will continue to run in the background.
  • The XML file gives you an option to remove any MSI-installed versions found. In my testing, this setting is ignored and the installer will always remove any older versions of Office. Even better, it will remove applications like Visio or Project that aren’t part of the suite and are thus not going to get reinstalled.
  • Normally, the suite is going to be configured to take updates directly from Microsoft. You can no longer use WSUS to patch Office. You can technically control patches by disabling updates from the Internet and then manually downloading them to a network share, but that’s likely impractical. Realistically administrators have no choice but to accept giving up control of Office patches if they want to stay reasonably current. As an example of how little control we now have over the patch process, I left Word open with this document being edited on Friday, running version 1809. I came in Monday morning to the document still open, with Word running version 1810.

Co-Existence With Visio or Project

While neither Visio nor Project are included in the O365 Pro Plus suite, or in Office 2019, they are considered part of Office and the ODT is used to install them as well. This has implications for installing either application alongside the Office Suite. Microsoft has a KB article about that here, but it’s missing one critical bit of info.

According to Microsoft, it is possible to install Office 365 Pro Plus with a retail (subscription-based) license alongside Project 2019 or Visio 2019 using a volume license. However in the “additional information” section of the linked article, Microsoft adds a major restriction: all installed Office applications must be using the same update channel.

The reality is that restriction precludes using O365 Pro Plus along with volume-licensed copies of Project or Visio, because the retail versions use one set of update channels, and the volume license versions use a different one. Perhaps I’m missing something here but I could not get retail O365 Pro Plus to work properly alongside volume licensed (either MAK or KMS) versions of Project or Visio.

If a volume-licensed edition of Project 2019 or Visio 2019 is already installed, the O365 Pro Plus install may succeed (it did for me), however none of the applications will activate. The volume-license apps generate an error that the license has changed, and the retail apps simply refuse to license with a generic error.

If O365 Pro Plus is installed first, the volume license versions will refuse to install due to the unavoidable channel mismatch.

If you install the retail versions of Project or Visio alongside O365 Pro Plus, you cannot activate them using KMS or MAK because only the volume license version supports volume activation.

So the long and short of it is that if you need either Project or Visio, you either have to use Office 2019 and the volume license edition of Project or Visio, or you need an O365 subscription that includes rights to all applicable products.

In Conclusion

Anytime a long-standing technology changes, there are growing pains. We’re still too new to using CTR to see any clear advantages, but the move itself isn’t all that painful. However, the changes to how applications are updated, licensing, and the restrictions on product coexistence all have significant implications to cost, both in dollars and labor.

Most corporations will probably be content to stay with the volume-license editions of Office, but in education, Microsoft continues to add – and quickly publicize – new features that are only available in the monthly retail channel. So while we have the option of staying volume-licensed, the reality is we would be doing our students a disservice by not offering the latest features. And that means dealing with all the accompanying quirks.