Silent Installs of Adobe Acrobat Fail Successfully via the Creative Cloud Installer

Posted by James F. Prudente on August 23, 2023
Posted in: Deployment, Windows 11. Tagged: , . 1 Comment

We are rolling out Adobe Creative Cloud via Enterprise licenses. Adobe provides a fairly comprehensive package builder through the enterprise admin console, including templates for most of their applications. Each includes the Creative Cloud control center, plus the relevant applications.

Deploying Photoshop, Premiere Pro, and others through Group Policy went smoothly. Of all things however, Acrobat proved to be a huge issue. What we found was that the CC control center would install properly, but Acrobat itself would simply not install. Making matters worse, the parent installer (which calls the installers for Acrobat and the control center) returned a success exit code. Lovely.

I spent way too much time searching through MSI debug logs and the native Adobe installer logs without finding anything conclusive. Making matters worse was that installing interactively worked without issue; it was only the GPO installs that failed.

I eventually found this post on the Adobe community, where poster “Bodek” referenced essentially the same issue, although he was using InTune. At this point I at least knew it wasn’t something specific to us. The community post had several replies, some of which contradict each other. There was also a reference to the Adobe Acrobat deployment configuration tool. I went down that rabbit hole without any progress.

Eventually I gave up on trying to use the parent installer and decided to directly call the MSI for Acrobat itself. But even that wasn’t simple.

Assuming you use the Adobe package builder, the main MSI for Acrobat can be found at Setup\APRO23.0\Adobe Acrobat\AcroPro.msi. This installs Acrobat DC, which is an older version of the program. After running this MSI, you need to install the latest MSP file, which at the time of this writing is AcrobatDCx64Upd2300320269.msp, found in the same directory as the msi. This will upgrade Acrobat DC to the latest version of Acrobat, which will lose the “DC” from its name.

There is one more caveat. If you already have a current version of Acrobat Reader installed, the initial DC installer will fail because it detects Reader as a “more functional product.” Therefore, you will need to uninstall Reader prior to using this method to install Acrobat.

I would love to know what is fundamentally broken with Adobe’s CC wrapper for Acrobat. My guess is there is an error in the silent install sequence, but where its occurring was beyond my time and patience to figure out. If you have any insight, please comment below.

Nested Groups in Azure AD and Exchange 365

Posted by James F. Prudente on May 9, 2023
Posted in: Active Directory, Exchange, Office 365. Tagged: . 2 Comments

As in a lot of environments, we sync our on-prem AD to Azure AD, and as such, on-prem security groups are used to grant access to various cloud resources. For us, this includes shared calendars in Exchange 365.

We received a ticket that a few users were not getting the proper level of access to a shared calendar, and my initial investigation did not turn up anything that would explain the problem. Permissions were granted to a sync’d AD group, which itself contained two nested AD groups. Group nesting has always been a bit quirky in M365, so that was the obvious place to check, but users in the first nested group had the proper access. Only users in the second group were missing permissions.

I checked Azure AD and was able to confirm that all members of both groups were properly being placed in the parent group, so clearly the nesting itself was not the issue and there had to be something else going on. I started looking at the differences between the two nested groups and found that the working group was a mail-enabled security group, while the non-working group was not mail-enabled. Turns out that was the problem.

Evidently, Exchange 365 ignores group membership unless the relevant group is mail-enabled. It’s been a while since we had on-premise Exchange but I do not recall this being the case there. In any event, I added an e-mail address and proxy address to the problem group (in AD), and once things sync’d up to the cloud, the users had the proper permissions.

I was not able to find any documentation for this. Hopefully this post saves someone else the trouble of figuring it out on their own. If it does, or you have anything else to add, I’d love to hear from you.

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!