Not sure if this is the exact same issue, but we had various Print to PDF and Type-4 driver installation issues. I posted what resolved it for me, here- https://learn.microsoft.com/en-us/answers/questions/214615/microsoft-print-to-pdf-not-working-after-windows-u.html
Here are my notes on what worked for us-
One thing I noticed was that the ntprint.inf file was referencing ntprint.inf_x86... for the active driver reference on the problematic machine, ntprint.inf_x64... on a working machine
I did the following and so far printing is back to normal for Type-4 drivers-
1- ran "pnputil /enum-drivers" from a command prompt
2- used psexec to elevate and run regedit as system
3- investigated the - HKEY_LOCAL_MACHINE\DRIVERS\DriverDatabase\DriverInfFiles\ntprint.inf
4- updated the (Default) value to include - ntprint.inf_x86_6fbb4b09e9354bf2 and ntprint.inf_amd64_6fbb4b09e9354bf2
5- updated the Active value to - ntprint.inf_amd64_6fbb4b09e9354bf2
Note- the exact values of ntprint.inf_x86 and _64 might be specific to build or updates installed, I'm not sure that they are universal to 2016. I used the values that existed in the DriverStore - C:\Windows\System32\DriverStore\FileRepository on my servers.
Not sure if this fix will do the trick long term, but so far after scrubbing out old printers, drivers, and pretty much cleaning out all registry / driver on the server its the only thing that has looked promising. Hopefully this will help point someone else in the right direction.
To recap the issue we had- On six Windows 2016 RDS session hosts last year, printing worked fine until April time frame and none of the Print to PDF or installing any printer with a type-4 driver would work. We would always get "Element not found" June 2020 we rebuilt new fully patched Windows Server 2016 RDS session hosts and the problem was resolved until 2 months ago when the exact thing happened again! Very frustrating. With limited testing at this point, editing the ntprint.inf entry in the registry seems to have resolved.