Executing Commands From Windows Service

Discussion in 'Python' started by T, Feb 7, 2010.

  1. T

    T Guest

    I have a script, which runs as a Windows service under the LocalSystem
    account, that I wish to have execute some commands. Specifically, the
    program will call plink.exe to create a reverse SSH tunnel. Right now
    I'm using subprocess.Popen to do so. When I run it interactively via
    an admin account, all is well. However, when I'm running it via
    service, no luck. I'm assuming this is to do with the fact that it's
    trying to run under the LocalSystem account, which is failing. What
    would be the best way around this? Thanks!
     
    T, Feb 7, 2010
    #1
    1. Advertising

  2. T

    Sean DiZazzo Guest

    On Feb 7, 11:02 am, T <> wrote:
    > I have a script, which runs as a Windows service under the LocalSystem
    > account, that I wish to have execute some commands.  Specifically, the
    > program will call plink.exe to create a reverse SSH tunnel.  Right now
    > I'm using subprocess.Popen to do so.  When I run it interactively via
    > an admin account, all is well.  However, when I'm running it via
    > service, no luck.  I'm assuming this is to do with the fact that it's
    > trying to run under the LocalSystem account, which is failing.  What
    > would be the best way around this?  Thanks!


    Try running/debugging your service from the commandline as
    "<servicename> debug" That should lead you to the error.

    Otherwise, we need to see a traceback and some code to be better able
    to help.

    ~Sean
     
    Sean DiZazzo, Feb 7, 2010
    #2
    1. Advertising

  3. T

    T Guest

    On Feb 7, 4:43 pm, Sean DiZazzo <> wrote:
    > On Feb 7, 11:02 am, T <> wrote:
    >
    > > I have a script, which runs as a Windows service under the LocalSystem
    > > account, that I wish to have execute some commands.  Specifically, the
    > > program will call plink.exe to create a reverse SSH tunnel.  Right now
    > > I'm using subprocess.Popen to do so.  When I run it interactively via
    > > an admin account, all is well.  However, when I'm running it via
    > > service, no luck.  I'm assuming this is to do with the fact that it's
    > > trying to run under the LocalSystem account, which is failing.  What
    > > would be the best way around this?  Thanks!

    >
    > Try running/debugging your service from the commandline as
    > "<servicename> debug"  That should lead you to the error.
    >
    > Otherwise, we need to see a traceback and some code to be better able
    > to help.
    >
    > ~Sean


    It's working fine when I run it via "<servicename> debug" - that's how
    I was testing before. It's when I start the service that it fails -
    and you can see that, when you run it with debug, plink.exe runs under
    my username. When I run it as a service, it runs under System...
     
    T, Feb 7, 2010
    #3
  4. T

    Sean DiZazzo Guest


    >
    > It's working fine when I run it via "<servicename> debug" - that's how
    > I was testing before.  It's when I start the service that it fails -
    > and you can see that, when you run it with debug, plink.exe runs under
    > my username.  When I run it as a service, it runs under System...


    You can have the service run as any user under the service
    properties. Perhaps set the service to run under your username?

    There may be some environment variables set in your session that
    aren't in the one its running as. So maybe check there as well.

    Off to drink beer. Good luck.
     
    Sean DiZazzo, Feb 7, 2010
    #4
  5. * T:
    > On Feb 7, 4:43 pm, Sean DiZazzo <> wrote:
    >> On Feb 7, 11:02 am, T <> wrote:
    >>
    >>> I have a script, which runs as a Windows service under the LocalSystem
    >>> account, that I wish to have execute some commands. Specifically, the
    >>> program will call plink.exe to create a reverse SSH tunnel. Right now
    >>> I'm using subprocess.Popen to do so. When I run it interactively via
    >>> an admin account, all is well. However, when I'm running it via
    >>> service, no luck. I'm assuming this is to do with the fact that it's
    >>> trying to run under the LocalSystem account, which is failing. What
    >>> would be the best way around this? Thanks!

    >> Try running/debugging your service from the commandline as
    >> "<servicename> debug" That should lead you to the error.
    >>
    >> Otherwise, we need to see a traceback and some code to be better able
    >> to help.
    >>
    >> ~Sean

    >
    > It's working fine when I run it via "<servicename> debug" - that's how
    > I was testing before. It's when I start the service that it fails -
    > and you can see that, when you run it with debug, plink.exe runs under
    > my username. When I run it as a service, it runs under System...


    This sounds like a Windows programming problem, not anything related to Python
    per se.

    Windows services are generally limited in what they can do, such as interaction
    with the user, and I guess that spills over to network access.

    Also, services need to interact with the service control manager, the "scum" as
    it's known. Well, all right, that's just what my coworkers and I called it once.
    But essentially, it's an even-driven execution model, which means that it might
    not work to use just any program, such as [python.exe], directly as a service.

    The Windows Resource Kit used to have a facility for running ordinary programs
    as services. I'm not sure what it did at the technical level, but it worked. Or
    it appeared to work.

    You might also find it useful to look up the documentation on services that
    interact with the user. In the old times that was mostly a matter of configuring
    which account the service ran under. But I think it all got more complicated
    with Microsoft's introduction of Terminal services (generally, most of the
    complication in modern Windows is due to the shift in focus about 1995, ditching
    the personal computer user market in favor of the enterprise and MIS market).

    Cross-posted to [comp.os.ms-windows.programmer.win32], follow-ups set to that
    group -- that means, unless overridden you won't see follow-ups in [c.l.p].

    I think that group may give more informative and helpful responses.


    Cheers & hth.,

    - Alf
     
    Alf P. Steinbach, Feb 7, 2010
    #5
  6. T

    T Guest

    Thanks for the suggestions - I think my next step is to try running
    it under an admin user account, as you guys both mentioned. Alf -
    you're absolutely right, Microsoft has srvany.exe, which allows you to
    run any EXE as a Windows service. I've done this in the past, but
    it's more of a "hack"..so this go around (since I will be distributing
    this program), I wanted to go the more professional route..which,
    unfortunately, involves learning the "scum". :) I posted this to
    comp.os.ms-windows.programmer.win32, so we'll see if what the Win32
    programmers have to say as well. Thanks again!
     
    T, Feb 8, 2010
    #6
  7. T

    Sean DiZazzo Guest

    On Feb 7, 4:57 pm, T <> wrote:
    > Thanks for the suggestions -  I think my next step is to try running
    > it under an admin user account, as you guys both mentioned.  Alf -
    > you're absolutely right, Microsoft has srvany.exe, which allows you to
    > run any EXE as a Windows service.  I've done this in the past, but
    > it's more of a "hack"..so this go around (since I will be distributing
    > this program), I wanted to go the more professional route..which,
    > unfortunately, involves learning the "scum". :)  I  posted this to
    > comp.os.ms-windows.programmer.win32, so we'll see if what the Win32
    > programmers have to say as well.  Thanks again!


    I use windows services and they are very reliable. I would say though
    that relying on plink.exe is much less reliable than either python or
    the service that it is running under.

    Why not take a look at paramiko as the ssh client library? I think it
    runs under windows. Also perhaps Twisted has something. Either way
    would be light years ahead of using subprocess with plink.

    Just my thoughts.

    ~Sean
     
    Sean DiZazzo, Feb 8, 2010
    #7
  8. T

    T Guest

    On Feb 8, 1:28 am, Sean DiZazzo <> wrote:
    > On Feb 7, 4:57 pm, T <> wrote:
    >
    > > Thanks for the suggestions -  I think my next step is to try running
    > > it under an admin user account, as you guys both mentioned.  Alf -
    > > you're absolutely right, Microsoft has srvany.exe, which allows you to
    > > run any EXE as a Windows service.  I've done this in the past, but
    > > it's more of a "hack"..so this go around (since I will be distributing
    > > this program), I wanted to go the more professional route..which,
    > > unfortunately, involves learning the "scum". :)  I  posted this to
    > > comp.os.ms-windows.programmer.win32, so we'll see if what the Win32
    > > programmers have to say as well.  Thanks again!

    >
    > I use windows services and they are very reliable.  I would say though
    > that relying on plink.exe is much less reliable than either python or
    > the service that it is running under.
    >
    > Why not take a look at paramiko as the ssh client library?  I think it
    > runs under windows.  Also perhaps Twisted has something.  Either way
    > would be light years ahead of using subprocess with plink.
    >
    > Just my thoughts.
    >
    > ~Sean


    I totally agree that it would be much more reliable to use a Python
    library for SSH - however, the program will need to execute other
    external binaries as well. So my goal at this point is to track down
    _why_ it's failing when running as a service. The actual command is
    as follows:

    C:\plink.exe -R 9999:127.0.0.1:2020 -batch -i C:\keyfile.ppk
    user@10.10.10.1

    I tried having subprocess.Popen run plink.exe by itself and piping
    output to file, and this worked - so I know it's at least executing
    plink.exe. Sorry, I realize this isn't truly just a Python-related
    question, but any help would be greatly appreciated! So far no help
    at comp.os.ms-windows.programmer.win32..
     
    T, Feb 8, 2010
    #8
  9. T

    David Bolen Guest

    T <> writes:

    > I have a script, which runs as a Windows service under the LocalSystem
    > account, that I wish to have execute some commands. Specifically, the
    > program will call plink.exe to create a reverse SSH tunnel. Right now
    > I'm using subprocess.Popen to do so. When I run it interactively via
    > an admin account, all is well. However, when I'm running it via
    > service, no luck. I'm assuming this is to do with the fact that it's
    > trying to run under the LocalSystem account, which is failing. What
    > would be the best way around this? Thanks!


    The LocalSystem account is not, if I recall correctly, permitted to
    access the network.

    You'll have to install the service to run under some other account that
    has appropriate access to the network.

    -- David
     
    David Bolen, Feb 8, 2010
    #9
  10. T

    T Guest

    On Feb 8, 2:25 pm, David Bolen <> wrote:
    > T <> writes:
    > > I have a script, which runs as a Windows service under the LocalSystem
    > > account, that I wish to have execute some commands.  Specifically, the
    > > program will call plink.exe to create a reverse SSH tunnel.  Right now
    > > I'm using subprocess.Popen to do so.  When I run it interactively via
    > > an admin account, all is well.  However, when I'm running it via
    > > service, no luck.  I'm assuming this is to do with the fact that it's
    > > trying to run under the LocalSystem account, which is failing.  What
    > > would be the best way around this?  Thanks!

    >
    > The LocalSystem account is not, if I recall correctly, permitted to
    > access the network.
    >
    > You'll have to install the service to run under some other account that
    > has appropriate access to the network.
    >
    > -- David


    The more testing I do, I think you may be right..I was able to get it
    to work under a local admin account, and it worked under debug mode
    (which would also have been running as this user). I'm a bit
    surprised though - I was under the assumption that LocalSystem had
    rights to access the network?
     
    T, Feb 9, 2010
    #10
  11. T

    Sean DiZazzo Guest

    On Feb 9, 6:52 am, T <> wrote:
    > On Feb 8, 2:25 pm, David Bolen <> wrote:
    >
    >
    >
    > > T <> writes:
    > > > I have a script, which runs as a Windows service under the LocalSystem
    > > > account, that I wish to have execute some commands.  Specifically, the
    > > > program will call plink.exe to create a reverse SSH tunnel.  Right now
    > > > I'm using subprocess.Popen to do so.  When I run it interactively via
    > > > an admin account, all is well.  However, when I'm running it via
    > > > service, no luck.  I'm assuming this is to do with the fact that it's
    > > > trying to run under the LocalSystem account, which is failing.  What
    > > > would be the best way around this?  Thanks!

    >
    > > The LocalSystem account is not, if I recall correctly, permitted to
    > > access the network.

    >
    > > You'll have to install the service to run under some other account that
    > > has appropriate access to the network.

    >
    > > -- David

    >
    > The more testing I do, I think you may be right..I was able to get it
    > to work under a local admin account, and it worked under debug mode
    > (which would also have been running as this user).  I'm a bit
    > surprised though - I was under the assumption that LocalSystem had
    > rights to access the network?


    You really need a way to see the error you are getting. If you can't
    get it to show you the error in the shell, set up some logging to a
    file, and find the error that way. I think the user can access the
    network just fine, but that maybe plink.exe is not in his path or some
    such thing.

    Find the error!
     
    Sean DiZazzo, Feb 9, 2010
    #11
  12. T

    David Bolen Guest

    T <> writes:

    > The more testing I do, I think you may be right..I was able to get it
    > to work under a local admin account, and it worked under debug mode
    > (which would also have been running as this user). I'm a bit
    > surprised though - I was under the assumption that LocalSystem had
    > rights to access the network?


    Not from my past experience - the system account (LocalSystem for
    services) can be surprising, in that it's pretty much unlimited access
    to all local resources, but severely limited in a handful of cases,
    one of which is any attempt to access the network. I can't recall for
    sure if it's an absolute block, or if in some cases you can configure
    around it (e.g., it might use a null session for remote shares which
    can be enabled through the registry on the target machine). I've
    basically stuck "LocalSystem = no network" in my head from past
    experience.

    So you can either install your service to run under your existing
    account, or create an account specifically for running your service,
    granting that account just the rights it needs.

    -- David
     
    David Bolen, Feb 9, 2010
    #12
  13. T

    David Bolen Guest

    David Bolen <> writes:

    > Not from my past experience - the system account (LocalSystem for
    > services) can be surprising, in that it's pretty much unlimited access
    > to all local resources, but severely limited in a handful of cases,
    > one of which is any attempt to access the network. I can't recall for
    > sure if it's an absolute block, or if in some cases you can configure
    > around it (e.g., it might use a null session for remote shares which
    > can be enabled through the registry on the target machine). I've
    > basically stuck "LocalSystem = no network" in my head from past
    > experience.


    Given it's been a few years, I decided to try some tests, and the
    above is too simplistic.

    The LocalSystem account runs without any local Windows credentials
    (e.g., not like a logged in user), which has several consequences.
    One is that you can't access any network resources that require such
    credentials (like shares). However, there's no sort of firewall
    filtering or anything, so plain old TCP/IP connections are fine.
    Unless, of course, the client being used also has other needs for
    local Windows credentials, independent or as a pre-requisite to the
    network operations.

    So backing up a bit, the TCP/IP connection that plink is making is not
    inherently disabled by running under LocalSystem, but it's certainly
    possible that plink is trying to identify the user under which it is
    operating to perhaps identify ssh keys or other local resources it
    needs to operate. You might be able to cover this with command line
    options (e.g., plink supports "-i" to specify a key file to use), but
    you'll also need to ensure that the file you are referencing is
    readable by the LocalSystem account.

    One of the other responders had a very good point about locating plink
    in the first place too. Services run beneath an environment that is
    inherited from the service control manager process, and won't include
    various settings that are applied to your user when logged in,
    especially things like local path changes, and working directories.
    Should you change the system path (via the environment settings),
    you'll need to reboot for the service control manager to notice - I
    don't think you can restart it without a reboot.

    So it's generally safer to be very clear, and absolute when possible,
    in a service for paths to external resources.

    The prior advice of running the service as an identified user (e.g.,
    with local credentials) is still good as it does remove most of these
    issues since if you can run the script manually under that user you
    know it'll work under service. But it's not a hard requirement.

    If your script is dying such that a top level exception is being
    raised you should be able to find it in the application event log. So
    that might give further information on what about the different
    environment is problematic.

    You can also use the win32traceutil module to help with grabbing debug
    output on the fly. Import the module in your service, which will
    implicitly redirect stdout/stderr to a trace buffer. Run the same
    win32traceutil module from the command line in another window. Then
    start the service. Any stdout/stderr will be reflected in the other
    window. Can't catch everything (suppressed exceptions, or I/O that
    doesn't flow through the script's stdout/stderr), but again might help
    point in the right direction.

    -- David
     
    David Bolen, Feb 9, 2010
    #13
  14. T

    T Guest

    On Feb 9, 4:25 pm, David Bolen <> wrote:
    > David Bolen <> writes:
    > > Not from my past experience - the system account (LocalSystem for
    > > services) can be surprising, in that it's pretty much unlimited access
    > > to all local resources, but severely limited in a handful of cases,
    > > one of which is any attempt to access the network.  I can't recall for
    > > sure if it's an absolute block, or if in some cases you can configure
    > > around it (e.g., it might use a null session for remote shares which
    > > can be enabled through the registry on the target machine).  I've
    > > basically stuck "LocalSystem = no network" in my head from past
    > > experience.

    >
    > Given it's been a few years, I decided to try some tests, and the
    > above is too simplistic.
    >
    > The LocalSystem account runs without any local Windows credentials
    > (e.g., not like a logged in user), which has several consequences.
    > One is that you can't access any network resources that require such
    > credentials (like shares).  However, there's no sort of firewall
    > filtering or anything, so plain old TCP/IP connections are fine.
    > Unless, of course, the client being used also has other needs for
    > local Windows credentials, independent or as a pre-requisite to the
    > network operations.
    >
    > So backing up a bit, the TCP/IP connection that plink is making is not
    > inherently disabled by running under LocalSystem, but it's certainly
    > possible that plink is trying to identify the user under which it is
    > operating to perhaps identify ssh keys or other local resources it
    > needs to operate.  You might be able to cover this with command line
    > options (e.g., plink supports "-i" to specify a key file to use), but
    > you'll also need to ensure that the file you are referencing is
    > readable by the LocalSystem account.
    >
    > One of the other responders had a very good point about locating plink
    > in the first place too.  Services run beneath an environment that is
    > inherited from the service control manager process, and won't include
    > various settings that are applied to your user when logged in,
    > especially things like local path changes, and working directories.
    > Should you change the system path (via the environment settings),
    > you'll need to reboot for the service control manager to notice - I
    > don't think you can restart it without a reboot.
    >
    > So it's generally safer to be very clear, and absolute when possible,
    > in a service for paths to external resources.
    >
    > The prior advice of running the service as an identified user (e.g.,
    > with local credentials) is still good as it does remove most of these
    > issues since if you can run the script manually under that user you
    > know it'll work under service.  But it's not a hard requirement.
    >
    > If your script is dying such that a top level exception is being
    > raised you should be able to find it in the application event log.  So
    > that might give further information on what about the different
    > environment is problematic.
    >
    > You can also use the win32traceutil module to help with grabbing debug
    > output on the fly.  Import the module in your service, which will
    > implicitly redirect stdout/stderr to a trace buffer.  Run the same
    > win32traceutil module from the command line in another window.  Then
    > start the service.  Any stdout/stderr will be reflected in the other
    > window.  Can't catch everything (suppressed exceptions, or I/O that
    > doesn't flow through the script's stdout/stderr), but again might help
    > point in the right direction.
    >
    > -- David


    Great suggestions once again - I did verify that it was at least
    running the plink.exe binary when under LocalSystem by having the
    service run "plink.exe > C:\plinkoutput.txt" - this worked fine. And,
    as I mentioned, it's now working just fine when running under a
    regular admin account. So, I think that's going to be my solution to
    avoid any further issues. My best guess at this point (as you
    mentioned), is that plink.exe is doing _something_ network-related
    that LocalSystem doesn't have the privileges to do - what exactly it
    is, I have no idea. I may play around with it some more later, but
    running the service under an admin account should be a perfectly
    acceptable solution.

    Also, I will be writing other Python apps that the service will be
    executing - so it goes without saying that I'll be including a log to
    file option :) Thanks again for all your guys' help!
     
    T, Feb 10, 2010
    #14
  15. T

    Tim Golden Guest

    On 10/02/2010 22:55, T wrote:
    > Great suggestions once again - I did verify that it was at least
    > running the plink.exe binary when under LocalSystem by having the
    > service run "plink.exe> C:\plinkoutput.txt" - this worked fine. And,
    > as I mentioned, it's now working just fine when running under a
    > regular admin account. So, I think that's going to be my solution to
    > avoid any further issues. My best guess at this point (as you
    > mentioned), is that plink.exe is doing _something_ network-related
    > that LocalSystem doesn't have the privileges to do - what exactly it
    > is, I have no idea. I may play around with it some more later, but
    > running the service under an admin account should be a perfectly
    > acceptable solution.
    >
    > Also, I will be writing other Python apps that the service will be
    > executing - so it goes without saying that I'll be including a log to
    > file option :) Thanks again for all your guys' help!


    I'm not sure if this has been said already, but a reasonably common
    approach to services is to create a user specifically for the
    service and grant it exactly the privs / perms it needs (once you
    work out what they are). You then assign it a generated password,
    eg a GUID which you don't even try to remember: simply cut-and-paste
    it in. Then create the service to run under that user.

    That way you don't have the service running under
    some local Administrator account with the associated risk
    of its being subverted and gaining more control than you
    want. Nor do you have it running as a real user whose
    password might change for any reason, leaving you with
    a service which won't start up.

    I don't remember at this moment whether such a user's profile
    is automatically loaded in the process when the service starts
    or whether you have to do the LoadUserProfile thing.

    TJG
     
    Tim Golden, Feb 11, 2010
    #15
  16. On 02/07/10 19:02, T wrote:
    > I have a script, which runs as a Windows service under the LocalSystem
    > account, that I wish to have execute some commands. Specifically, the
    > program will call plink.exe to create a reverse SSH tunnel. Right now
    > I'm using subprocess.Popen to do so. When I run it interactively via
    > an admin account, all is well. However, when I'm running it via
    > service, no luck. I'm assuming this is to do with the fact that it's
    > trying to run under the LocalSystem account, which is failing. What
    > would be the best way around this? Thanks!


    All being said about LS account not having the appropriate rights to
    access the necessary devices/files.

    Could it be so simple that the network is plain simply not available at
    all? For wireless connections I believe the connection/authentication by
    default is made in user space. I would save the output of an ipconfig
    run as the LS account to a file and see what is happening.
    Perhaps followed by a ping.

    --
    mph
     
    Martin P. Hellwig, Feb 11, 2010
    #16
  17. T

    T Guest

    On Feb 11, 4:10 am, Tim Golden <> wrote:
    > On 10/02/2010 22:55, T wrote:
    >
    > > Great suggestions once again - I did verify that it was at least
    > > running the plink.exe binary when under LocalSystem by having the
    > > service run "plink.exe>  C:\plinkoutput.txt" - this worked fine.  And,
    > > as I mentioned, it's now working just fine when running under a
    > > regular admin account.  So, I think that's going to be my solution to
    > > avoid any further issues.  My best guess at this point (as you
    > > mentioned), is that plink.exe is doing _something_ network-related
    > > that LocalSystem doesn't have the privileges to do - what exactly it
    > > is, I have no idea.  I may play around with it some more later, but
    > > running the service under an admin account should be a perfectly
    > > acceptable solution.

    >
    > > Also, I will be writing other Python apps that the service will be
    > > executing - so it goes without saying that I'll be including a log to
    > > file option :)  Thanks again for all your guys' help!

    >
    > I'm not sure if this has been said already, but a reasonably common
    > approach to services is to create a user specifically for the
    > service and grant it exactly the privs / perms it needs (once you
    > work out what they are). You then assign it a generated password,
    > eg a GUID which you don't even try to remember: simply cut-and-paste
    > it in. Then create the service to run under that user.
    >
    > That way you don't have the service running under
    > some local Administrator account with the associated risk
    > of its being subverted and gaining more control than you
    > want. Nor do you have it running as a real user whose
    > password might change for any reason, leaving you with
    > a service which won't start up.
    >
    > I don't remember at this moment whether such a user's profile
    > is automatically loaded in the process when the service starts
    > or whether you have to do the LoadUserProfile thing.
    >
    > TJG


    Tim - thanks, that's the route I'm going to go. I've created separate
    accounts for services before, and there's no question that's what I
    have to do in this case. I'm still having some issues running some
    commands (such as one that takes a screenshot), even as an admin user,
    but I think this is more due to the fact that it's trying to interact
    with the Desktop..so there may be no good solution.

    Btw great site..can't tell you how many times I've gone back to it.
    Keep up the great work!
     
    T, Feb 13, 2010
    #17
  18. T

    T Guest

    On Feb 11, 8:21 am, "Martin P. Hellwig" <>
    wrote:
    > On 02/07/10 19:02, T wrote:
    >
    > > I have a script, which runs as a Windows service under the LocalSystem
    > > account, that I wish to have execute some commands.  Specifically, the
    > > program will call plink.exe to create a reverse SSH tunnel.  Right now
    > > I'm using subprocess.Popen to do so.  When I run it interactively via
    > > an admin account, all is well.  However, when I'm running it via
    > > service, no luck.  I'm assuming this is to do with the fact that it's
    > > trying to run under the LocalSystem account, which is failing.  What
    > > would be the best way around this?  Thanks!

    >
    > All being said about LS account not having the appropriate rights to
    > access the necessary devices/files.
    >
    > Could it be so simple that the network is plain simply not available at
    > all? For wireless connections I believe the connection/authentication by
    > default is made in user space. I would save the output of an ipconfig
    > run as the LS account to a file and see what is happening.
    > Perhaps followed by a ping.
    >
    > --
    > mph


    Martin - another part of the program sends an email back to a
    specified user, and that works, so LocalSystem must at least have some
    network access. From the testing I've done so far, seems like there's
    just some grey area (which I haven't completely figured out yet) of
    network-related tasks that LS just can't do. I'd love to know what
    this is, but so far the solution I have is just to create another user
    and have the service use that..
     
    T, Feb 13, 2010
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mitchley
    Replies:
    0
    Views:
    625
    Mitchley
    Jun 10, 2004
  2. Ben Pfaff

    Re: man pages for C commands (GCC commands)

    Ben Pfaff, Jun 24, 2003, in forum: C Programming
    Replies:
    4
    Views:
    4,007
    Thomas Stegen
    Jun 28, 2003
  3. Tim Stanka
    Replies:
    1
    Views:
    834
    Jeff Epler
    Aug 2, 2004
  4. Dariusz Tomoñ

    executing Windows commands via ASP

    Dariusz Tomoñ, Dec 19, 2003, in forum: ASP General
    Replies:
    1
    Views:
    232
    Aaron Bertrand [MVP]
    Dec 19, 2003
  5. Murugesh
    Replies:
    5
    Views:
    199
Loading...

Share This Page