Home All Groups Group Topic Archive Search About
Author
18 May 2009 3:25 PM
Eric
..Net 3.5 added ability for a client machine to run .Net programs on a
server, but if we run a VB.Net program on a server and use the printer
object to create a printout, it adds a printout to the queue with the name
administrator.  If we run it from the client, we get the logged in username.
Is there a method to run it on the server and still see documents in the
queue with the user names?

Author
20 May 2009 5:19 PM
Eric
Nobody knows, or this is not possible?

Show quoteHide quote
"Eric" <someone@idontwantspam.com> wrote in message
news:%23%23rvyz81JHA.5772@TK2MSFTNGP02.phx.gbl...
> .Net 3.5 added ability for a client machine to run .Net programs on a
> server, but if we run a VB.Net program on a server and use the printer
> object to create a printout, it adds a printout to the queue with the name
> administrator.  If we run it from the client, we get the logged in
> username. Is there a method to run it on the server and still see
> documents in the queue with the user names?
>
Author
20 May 2009 9:47 PM
Mike
Eric wrote:
> Nobody knows, or this is not possible?
>
> "Eric" <someone@idontwantspam.com> wrote in message
> news:%23%23rvyz81JHA.5772@TK2MSFTNGP02.phx.gbl...
>> .Net 3.5 added ability for a client machine to run .Net programs on a
>> server, but if we run a VB.Net program on a server and use the printer
>> object to create a printout, it adds a printout to the queue with the name
>> administrator.  If we run it from the client, we get the logged in
>> username. Is there a method to run it on the server and still see
>> documents in the queue with the user names?

Well, to me its sort of a odd question.

You always had the ability for a process to run another process on the
server side.  .NET does not have a copyright on  that idea.

But I can imagine .NET 3.5 possibly added easier logic to establish
the child process credentials, which by default if not specified, the
spawned process will inherit the parent process credentials.

When initiating it from a client, the client is the user so the code
is running under the context of the user.

When doing it from the server, well, typically this is done under the
account established for .NET applications, it may be the local account
or administrator or whatever secured ANONYMOUS credentials used for
..NET applications.

You can probably use this context to browse all the queues and get the
one you want or their might be a lookup by user name.

But if you want to get the information for a user context, I believe
you need to either login as that user or impersonate that user.

Once you know the basic requirements for both client/server
credentials, then look up the commands  in .NET to do it.

--
Author
20 May 2009 10:00 PM
Mike
Mike wrote:
Show quoteHide quote
> Eric wrote:
>> Nobody knows, or this is not possible?
>>
>> "Eric" <someone@idontwantspam.com> wrote in message
>> news:%23%23rvyz81JHA.5772@TK2MSFTNGP02.phx.gbl...
>>> .Net 3.5 added ability for a client machine to run .Net programs on a
>>> server, but if we run a VB.Net program on a server and use the
>>> printer object to create a printout, it adds a printout to the queue
>>> with the name administrator.  If we run it from the client, we get
>>> the logged in username. Is there a method to run it on the server and
>>> still see documents in the queue with the user names?
>
> Well, to me its sort of a odd question.
>
> You always had the ability for a process to run another process on the
> server side.  .NET does not have a copyright on  that idea.

For example, RSH (Remote Shell) is a long time common practice. You
have a RSH command in Windows.

   c:> rsh /?
   rsh: remote terminal session not supported

   Runs commands on remote hosts running the RSH service.

   RSH host [-l username] [-n] command

   host           Specifies the remote host on which to run command.
   -l username    Specifies the user name to use on the remote host.
                  If omitted, the logged on user name is used.
   -n             Redirects the input of RSH to NULL.
   command        Specifies the command to run.

What you probably talking about in  .NET is this was added or some
form of it was added with an new assembly.

In any case, notice the -l username option?

That establishes the user context the remote server will spawn the
process under.

If not specified, there is a default user context.  You are probably
running it as a non-user context, the .NET default credentials.

See if the new .NET 3.5 commands you are talking about has a user
credentials option or has a very deep remark on the subject of
security as this would be a major threat entry point. I would be very
surprise if it does not.

--