Change Print Job Owner in Print Queue

[DeanJansen]

Good Day Everyone,

Im busy making this small application for work to test a few things

I have the following code runs when a button is pressed

// Create the printer server and print queue objectsLocalPrintServer localPrintServer = new LocalPrintServer();
PrintQueue defaultPrintQueue = LocalPrintServer.GetDefaultPrintQueue();

// Call AddJob
PrintSystemJobInfo myPrintJob = defaultPrintQueue.AddJob("My Test Job");

// Write a Byte buffer to the JobStream and close the stream
Stream myStream = myPrintJob.JobStream;
Byte[] myByteBuffer = UnicodeEncoding.Unicode.GetBytes("Test Print Job");
myStream.Write(myByteBuffer, 0, myByteBuffer.Length);
myStream.Close();

It works as planned.



All i want to do now is to be able change the Owner from "Dean" to any user i need.
Or if there is any better way to send print jobs to a print server from any username.

Thank You

Ref : Change Print Job Owner in Print Queue

 

[nkat]

Hi
Would you please reply if you found a solution to this?
I'm interested in a somewhat similar thing

 

[JohnH]

I see Win32_PrintJob.Owner property is readonly. You probably have to impersonate the user that creates the print job.

 

[nkat]

Thank you! Would you please elaborate on how to do just that? (impersonate a user)

 

[JohnH]

WindowsIdentity.RunImpersonated Method (System.Security.Principal)

Runs the specified action as the impersonated Windows identity. Instead of using an impersonated method call and running your function in WindowsImpersonationContext, you can use RunImpersonated(SafeAccessTokenHandle, Action) and provide your function directly as a parameter.

learn.microsoft.com

 

[nkat]

Thank you! Unfortunately, that would still require a user to enter the password of the impersonated account
Is there a way to Change Print Job Owner in Print Queue without the need to know the password?

 

[Skydiver]

Unfortunately, Windows was designed at a time before there was widespread accepted implementations of the OAuth style access to resources. So the architecture was made such that the current user logon session is assumed to be the owner of the job that was submitted.

The sample code in that documentation above just happens to show the most expedient way to get a logon session token. If you can somehow get the logon session token of the other user(s), then you can impersonate them and submit the job on their behalf without having to call LogonUser().