This is more of an information post than a request for help. However, if anybody knows anything about this I would be very grateful for any advice!
In our product we have written a COM server that, when the web user requests a report, spawns a process that calls the driver to create the PDF. Each report request spawns its own process, and once the PDF has been created the process ends. Typically the COM is set up to run as a restricted user. Now according to Microsoft, a COM+ application does not load the configured user's hive into HKEY_CURRENT_USER (see http://support.microsoft.com/kb/202785/). This seems to cause a problem in some cases: the PDF is readable and has password security as expected, but no permissions at all are allowed! For example, printing is not permitted, copying is not permitted, nothing.
If the COM (and therefore all sub-processes) is run as the interactive user then all is well, but obviously this is not something that would be allowed in a production environment. Furthermore, if a dummy Windows service is run as the restricted user on the same box as the COM, then the PDF is also created correctly. What happens is that the service loads the restricted user's hive into the registry, and it is then available when the driver comes along and creates a new PDF. As soon as that service is stopped all subsequent PDFs are once again locked too tight, and when the service is restarted the PDFs are once again okay. That is, they are password encrypted, but they do allow printing, copying, etc. as I coded.
I am currently working on calling the Userenv.dll's LoadUserProfile() function to force the restricted user's hive to be loaded. Hopefully this will remove the need to have that silly dummy service.
It would be handy to know just what the PDF driver is expecting to find in the registry. The 2.x and 3.x versions do not exhibit this behavior, only the 4.x version. Perhaps the driver code is requesting registry keys from HKEY_CURRENT_USER where in previous versions it looked in HKEY_LOCAL_MACHINE?