none
Launching an EXE not working through SCCM > "Run Script" on another PC RRS feed

  • Question

  • When running an imported script, on a remote PC, via the SCCM console, everything goes well, except one thing. I can't launch an application. I love this new functionality in the System Center console. We are running the latest, 1810, w/ all patches, etc. With my imported scripts, I can delete files, query WMI, etc., on end users' PCs. All works great. Why won't any of the methods below work when it runs on the client's PC (Win7 SP1 or Win10 1709) when I try to launch an application? When I look at c:\windows\ccm\logs\Scripts.log on the client PCs, it always returns code 0. No errors. 

        

    & "C:\Program Files\internet explorer\iexplore.exe" <----doesn't work

    Start-Process -FilePath "C:\Program Files\internet explorer\iexplore.exe" <----doesn't work

    Start-Process -FilePath iexplore.exe -WorkingDirectory "C:\Program Files\internet explorer" -verb open <----doesn't work

    --

    $iepath='C:\Program Files\internet explorer\iexplore.exe'
    Start-Process $iepath

    ^ doesn't work

    --

    Yes, IE works from that path.

    Please help. Thank you






    • Edited by ScriptWork Friday, March 1, 2019 8:59 PM
    Friday, March 1, 2019 7:49 PM

Answers

  • What you are trying to do will not work. Windows will not allow you to inject code into a user session and remotely the execution will leave the process running with no visible window.

    The issue has nothing to do with scripting or SCCM. It is just how basic Windows works. In fact it is how all modern operating systems work. It is called "process isolation" The user session is an isolated process (Explorer) that creates and isolated session.

    You can use a logon script or a scheduled task to do this.


    \_(ツ)_/

    Friday, March 1, 2019 9:45 PM

All replies

  • The syntax you have is correct, so I suspect you're running into 32-bit/64-bit file system redirection.

    On 64-bit Windows, 32-bit programs run in an emulation layer

    Other than this, you don't have a scripting question and you have some other kind of question. (SCCM?)


    -- Bill Stewart [Bill_Stewart]

    Friday, March 1, 2019 9:00 PM
    Moderator
  • So the process iexplore IS starting; I can see it in Task Manager. There's just no window for the logged on user to see. It hit me I need to launch this in the user's environment. Right? Now I need to figure out how to do that.
    Friday, March 1, 2019 9:27 PM
  • You cannot remotely start IE.  It will not display a window.

    All methods posted work correctly when run from a local session on both 64 and 32 bit Windows.


    \_(ツ)_/

    Friday, March 1, 2019 9:37 PM
  • I'm sorry, but I guess I don't know how to answer that. Iexplore.exe does "start," but it's only a process shown in Task Manager. I don't see the Internet Explorer window open. My script stops IE, deletes caches, then re-launches IE. I'm stuck getting IE to launch in a window w/ which the user can interact. Is that a scripting problem? Or is SCCM to blame here? 
    • Edited by ScriptWork Friday, March 1, 2019 9:40 PM
    Friday, March 1, 2019 9:39 PM
  • What you are trying to do will not work. Windows will not allow you to inject code into a user session and remotely the execution will leave the process running with no visible window.

    The issue has nothing to do with scripting or SCCM. It is just how basic Windows works. In fact it is how all modern operating systems work. It is called "process isolation" The user session is an isolated process (Explorer) that creates and isolated session.

    You can use a logon script or a scheduled task to do this.


    \_(ツ)_/

    Friday, March 1, 2019 9:45 PM
  • What you are trying to do will not work. Windows will not allow you to inject code into a user session and remotely the execution will leave the process running with no visible window.

    The issue has nothing to do with scripting or SCCM. It is just how basic Windows works. In fact it is how all modern operating systems work. It is called "process isolation" The user session is an isolated process (Explorer) that creates and isolated session.

    You can use a logon script or a scheduled task to do this.


    \_(ツ)_/


    I thought the scripts I send SCCM clients run from the local system as the local system? I can see them on the user's c:\windows\ccm\ScriptStore directory. So, for all intents and purposes, this is the same as remotely executing a script? 
    Friday, March 1, 2019 9:58 PM
  • It is the same as remoting.  YOU are remotely running the script under the agent which runs as the LocalSystem account. 

    I recommend learning the basic structure of Windows.  There are many good books on "Windows Internals" that will give you a context for understanding how Windows works.  Your questions show that you do not understand what a process is and how it is created.  YOur understanding of networking is also not complete.  Remoting implies network access.  Learning these basics will clarify most issues and will give you a base from which to ask better questions and to better understand how all things work in automation.

    You can also gain some of this with an in-depth study of SCCM.  Most basic training only addresses the GUI SCCCM management tools and assumes you already know the technical details of Windows.  This usually means that most SCCM techs do not learn SCCM at a deep technical level. Also most SCCM techs have no formal training as they have learned on-the-job and are not certified in the product.

    I would start by learning Windows Internals then take the MS courses in SCCM.  You don't have to get certified but you should take the courses or get the course books and study them CAREFULLY.


    \_(ツ)_/

    Friday, March 1, 2019 10:11 PM
  • jrv is correct.

    Windows does not allow you to start an executable that appears on the logged on user's session for the user to interact with. This is for security reasons.

    If you want an executable to appear interactively for a user, you must start it from the user's context. You can't do that remotely.


    -- Bill Stewart [Bill_Stewart]

    Monday, March 4, 2019 4:28 PM
    Moderator