I am attempting to maintain an automated html printing service and we are migrating to Server 2016. During this migrating, the automated printer service has stopped functioning.
The original version used the 'old standard' of creating an InternetExplorer interface, and then controlling it remotely using the OLECMD method. I've tried including the code, but every time I do I get an Azure firewall error when trying to save the question. It's easy enough to find though, comes up whenever you search "Print html from windows service."
While executing on Server 2003 or Windows 10, this works just fine. But the moment I put it on Server 2016, it reaches the 'Print' OLECMD and never comes back. No error is thrown, it simply goes to sleep waiting for the teardown to happen, and that never does.
Things I have already tried and have not worked...
- Giving the Windows Service permission to interact with the desktop
- Changing the user the Service runs under to both system and administrative accounts--none worked
- Going into Component Services and giving blanket access/control/launch/activation permissions to everything (planned to narrow it once I knew what it needed) related to Internet Explorer
- Taking ownership of everything related to IE in the Windows Registry
- Replacing the OLECMD logic with a Windows Forms Browser control and trying to remote control that. It works while in a console app, but fails once put into a Windows Service
- Doing the same as above, but spawning the Browser Control off in an STA apartment stated thread
- Attempting all three of my printing options (OLECMD, Forms, and Threaded Forms) in a Scheduled Task
- Making use of Foxxit PDF Reader's ability to run headless (this was axed by leadership/legal before I got the chance to try it)
I have seen advice around the net advising that the "recommended" way of having a hands-off printing service is to run it as a tray application, but that is an unacceptable solution in our environment. Unless I'm missing something big, you can't activate a tray application unless someone has logged in--and given the sheer volume of printing that we handle, we need a dedicated server handling this. Which means that nobody works on that server, and so nobody is reliably logged into it. Likewise, just using Windows 10 is unacceptable in the environment we're working with.
Ultimately, the problem seems to stem from Microsoft's increasing levels of Session 0 Isolation...and it appears that, unless I'm missing something that I can't find documented anywhere on the net, that the old OLECMD system has been locked out of being able to command a Print operation while in session 0.
So, is there something I am missing that I couldn't find anywhere else on the internet that makes this work? Or is there some other recommended way of having something that prints rendered HTML in an entirely hands-off fashion?