Is this a bug in Windows Server 2008's SetJob function?
This shows an apparent error in the implementation of SetJob on Windows Server 2008.
This is the source code for a simple NT RPC Service that can change the owner of its print jobs, from any account, on all Windows NT Operating Systems, EXCEPT Windows Server 2008.
On Windows Server 2008 the SetJob call only changes the Owner of the Print Job, if the service is run from the SYSTEM account. SetJob does NOT return an error indicating that it was unable to change the Owner of the Print Job, it just doesn't change the Owner.
There doesn't appear to be a published work around to enable changing the Owner of the Service's Print Jobs, on Windows Server 2008, for Services that are NOT running under the SYSTEM account.
It appears that a Hot Fix was released for the same (or related) problem for Terminal Services and changing the Owner of a Print Job from Services on Windows 2008 (KB 958741). This Hot Fix did not correct this SetJob Owner problem.
This is a link to my home HTTP Server...
Simple Print For Service and Client Source Code and Instructions Zip File
I've been asking about this, on the MSDN and TechNet forums for over a month. And in every case the replies have always been, ask in this other forum... When I respond that I have already asked in the other forum, I never receive another response...
In the big scheme, we aren't a big company, we have been selling this product since 1995. We have several thousand installations, a few of them have tens of thousands of users. Most all of our larger sites are holding off on upgrading to Windows Server 2008, until we find a solution to this problem, that doesn't involve having to retrain their users. Needless to say, we are getting more than a little heat about this...
Windows Server 2008 R2 SP1 (Beta) contains the fix for changing the ownership of a print job from a service that isn't running from the System account. I don't see it listed in the Excel Spreadsheet that lists the individual issues addressed.
This does not do anything to help 32 bit Windows Server 2008 users. But it does get rid of the problem for 64 bit Windows Server 2008 R2 users.
And only 17 months after I initially reported it...