Announcement

Collapse
No announcement yet.

Running an MSI remotely

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Running an MSI remotely

    I've been chasing this for a week now, and I'm stumped. I have a need to install an MSI, but it can't be pushed thru Group Policy because the prior version was installed during OS deploy, must be manually removed first, and the machine restarted before new install. I've got a script assembled which:
    *-Reads all PCs from AD
    *-Checks each to verify on-line status
    *-Checks the version of install for this app
    *-Removes it and restarts if old version
    *-Installs new if no version installed
    *-Records complete if new version installed

    The plan is to WOL all domain client PCs, then run the script to force the removal. Then run the script again to force the install, both during the night hours when users aren't in. Anything that misses out can be done manually, once the log files are examined.

    Tried using a per-machine script as a Scheduled (startup) Task, failed. Task was denied access every time GP refreshed (haven't begun to research that!) All the scripts options work except the install itself. The script copies a network share to the local PC, then issues 'Invoke-Command <pc name> {cmd /c 'msiexec /i C:\<localpath>.msi /qn /log <logfile>'}. Running it that way executes MSIEXEC enough to open the msi file, then start recording events. The log file has a collection of 'action start' and 'action ended' statements at the beginning of the file. They end with 3 lines that I think highlight the problem, that either MSIEXEC or the msi itself thinks "...the profile for the user is a temporary profile." Since this is running remotely from a management server under a domain admin account, with the ISE running under elevated privs, authority shouldn't be an issue. I've tried running under the domain 'god' account with the same results. I've also tried calling a PSSession under the same creds and running the install inside that session, same failure.

    I can call just the network shared MSI file from a Run box when logged in as an interactive admin user to any destination PC, and the install works flawlessly. The msi itself forces a restart when complete.

    Anyone got any ideas? The vendor of the MSI say it's not their software mandating an interactive login, and I'm out of answers.
    *RicklesP*
    MSCA (2003/XP), Security+, CCNA

    ** Remember: credit where credit is due, and reputation points as appropriate **

  • #2
    Re: Running an MSI remotely

    Bueler....Bueler....?? No suggestions at all?
    *RicklesP*
    MSCA (2003/XP), Security+, CCNA

    ** Remember: credit where credit is due, and reputation points as appropriate **

    Comment


    • #3
      Re: Running an MSI remotely

      Have you tried using PSexec to run the installer on the remote pc?

      It can copy over on the connection the files necessary, and can be called to run as System if necessary.
      The most important thing in life is to be yourself.

      Unless you can be Batman.
      Always be Batman.

      Comment


      • #4
        Re: Running an MSI remotely

        We used PSExec on our previous LAN system (Servr2K3/XP), but are trying to 'make the move' to doing as much with PShell as possible.

        If we're logged into our Management Server (2012), running PShell as admin, we can open a session to any of our Win7 Pro clients. But even with the domain 'God' account creds being used for the remote session, the path that shows up in the PShell command window is always: "C:\Users\TEMP\Desktop". And that's what we think is wrong.

        We suspect now that our GP is the faulty component. User roaming profiles are enforced at the workstations by a computer policy, rather than a setting per user account. We've turned that off on our Dev system and set the user profile paths for our DFS shares where profiles and redirects are stored. Got some scheduled restarts on servers and clients over the weekend, so we'll see on Monday how the Dev environment holds up. Maybe this is the smoking gun?
        *RicklesP*
        MSCA (2003/XP), Security+, CCNA

        ** Remember: credit where credit is due, and reputation points as appropriate **

        Comment


        • #5
          Re: Running an MSI remotely

          I'd be interested to hear the results.

          But while PowerShell will do a lot of the tasks, some are still best served by some older tech.

          What do you get with
          whoami
          on the remote session? The file path may not suit, but you should be able to get to the right location easily.
          The most important thing in life is to be yourself.

          Unless you can be Batman.
          Always be Batman.

          Comment


          • #6
            Re: Running an MSI remotely

            My first question would be if the original install was per machine or per user. You mentioned trying to setup a scheduled task through a start up script, which leads me to believe permissions might be an issue. I didn't pick up if the uninstall logs give you any indication of why it is failing.

            To do anything in a remote session, the uninstall command must be local and not on a share. You can't make a second hop in a PowerShell remoting session. I thought I saw a mention that you could connect to the network share with the MSI. That will work fine interactively, but not in a remote session.

            I would try putting the commands in a PowerShell script and see if they work in an interactive session. If so, create a GPO with a PowerShell startup script or logon script if that seems appropriate and try that. The script runs locally so it should be able to access remote shares, although remember the startup script runs under system.

            Comment


            • #7
              Re: Running an MSI remotely

              wobble-wobble: I haven't tried the 'whoami', will have a look next time I'm at work.

              Jeff Hicks: The original install was done as part of the OS deployment using MDT to push the image and run the various customizations to deliver a user-ready box. The vendor for this endpoint security app has released an upgrade for several issues, one of which we found in our environment (random BSODs at restarts in the wee hours). The old version has to be removed and the box restarted, then the new version installed and the box restarted again before it's all finished.

              I've already tried running the exact same commands from inside PS while interactively on the client specimen box, and it works without a hitch. And that's what I've been beating my head against the wall for a week over. I've been experimenting on my Dev system to get it all worked out before pushing it to Live, but I'm fast running out of boxes that need the new version. As part of my efforts, I've also tried using 'Start-Process' but that failed early on, before I managed to get the msiexec logging working.

              My script now copies the install files to the local client, then calls msiexec, then cleans up the copied files after the install is theoretically done. The script doesn't check for error status at that point, the copy and deletes are done without fail. The install cmd calls the local files, but blows up because of the temp profile. Since the logging which complains about the temp profile is the msiexec logging, I don't think it's PS failing me at this point, but I didn't know that when I started the thread.

              It's worse than annoying because we haven't run into this behavior with anything else we've done, to date (but we've only been at it with our current infrastructure for about 10 months). And, the first thing I tried was putting my script as a PS Startup script, pushed via GP. And the GP error'd each time it attempted to create the task, due to access denied errors. And we haven't begun to chase that one. This is the first time we've tried to create a startup script of any kind using PS, so that's a task for another decade.
              *RicklesP*
              MSCA (2003/XP), Security+, CCNA

              ** Remember: credit where credit is due, and reputation points as appropriate **

              Comment


              • #8
                Re: Running an MSI remotely

                When you run the commands interactively, is everything you are calling on the local hard drive? If you put all the commands in a script and run the script locally, does it work? If so, can you post the script? Feel free to change app names to things like foo.exe for foo.msi.

                What version of PowerShell?
                What is the client OS?

                I'm assuming the uninstall process requires admin privileges and an elevated session.

                Comment


                • #9
                  Re: Running an MSI remotely

                  The only command which isn't working is the one for the install. If I log in interactively and run the install command, calling the msi from either the network share or a local folder, both installs work without incident. When run from a remote PS ISE window, the network share call gives me an error that the msi is corrupted or otherwise invalid. When run from the same PS ISE window (either with or without opening a PSSession), calling the msi from a folder local to the client, the PS window shows a return to an inactive prompt in just a few seconds. The log for that msiexec run shows the temp profile I mentioned before. So best I can get is the msiexec command to run, but the msi file itself either can't be read or won't run on the remote client due to the environment of PS. The vendor claims that their msi has no requirement for a local logon to run.

                  Can't post the script today as I'm not at work. I'll have to do some data masking when I'm at work tomorrow. We're down in manpower as well, so I don't know when I'll be able to post it.
                  *RicklesP*
                  MSCA (2003/XP), Security+, CCNA

                  ** Remember: credit where credit is due, and reputation points as appropriate **

                  Comment


                  • #10
                    Re: Running an MSI remotely

                    Ok. From a a remote PowerShell session, calling the MSI from a network share will never work unless you enable CredSSP.

                    When you run it in a remoting session and the MSI is local, there is no user profile loaded as you might expect in Windows so that will probably fail.

                    But, if the MSI is local and the the MSI commands are in a script that you run interactively ON the machine, does it work or give you an error? If it works interactively it should work in a script. Don't use Invoke-Command. Your script should be the same MSIExec command that you run manually. If you run into problems parsing the command, you can use Invoke-Expression.

                    If *that* script works, you should be able to run it as a user logon script or maybe even start up script.

                    Packaging apps is a real art that not everyone has mastered. And sometimes PowerShell isn't the right answer. If you can get the process to work with an old-fashioned batch file, run with it.

                    Comment


                    • #11
                      Re: Running an MSI remotely

                      At work now, can't post the whole thing, but here's where I am: whether I call

                      Invoke-command <PC name> {msiexec.exe /i <local_client_path>.msi /log C:\<log_path>.txt}, or

                      Invoke-command <PC name> {cmd /c 'msiexec.exe /i <local_client_path>.msi /log C:\<log_path>.txt'},

                      The log file left by msiexec shows the action entries I described earlier. Because it's only been the install process which has given me grief, I've looked for alternate means of commanding the install, and the best I've managed is getting log entries which describe the profile problem.

                      We aren't running the entire script locally per box, it's being run from a management server. And we do that because our attempts to assign a Startup scheduled task with this same script to that task using Group Policy have failed miserably (access denied issues, go figure!) We are the final admins on this system, but learning PS under fire like this is slow going. The easy really has been easy, but this is kicking my backside. We figured it'd be less time to run it all from this server, because we've never seen this kind of problem with scripts in the past.

                      Because of the network access and parsing issues, I've taken all the spaces out in path names and finally resorted to copying the files to the client. And now it's only the profile issue that's the problem, whether I use a Remote session under our God account, or no Session called at all.

                      I'll have a look at 'Invoke-Expression'. At this point, what else can go wrong?
                      *RicklesP*
                      MSCA (2003/XP), Security+, CCNA

                      ** Remember: credit where credit is due, and reputation points as appropriate **

                      Comment


                      • #12
                        Re: Running an MSI remotely

                        Looks like 'Invoke-expression' is a local-only run thing, which goes against what we're trying to do. Based on the other things you described, do I understand you correctly that, ultimately, we can't use 'Invoke-Command' or 'Start-Process' to get MSIEXEC on any client to run an install of an MSI that's also local to that client, when calling from a server? That is truly disappointing, if so.
                        *RicklesP*
                        MSCA (2003/XP), Security+, CCNA

                        ** Remember: credit where credit is due, and reputation points as appropriate **

                        Comment


                        • #13
                          Re: Running an MSI remotely

                          When you use PowerShell remoting, such as using Invoke-Command, PowerShell spins up a temporary environment called a runspace. Think of it as a non-interactive PowerShell console. The MSI you want to use has something in it that is incompatible. It's not that PowerShell doesn't work. It will happily kick off the MSI, but there is something in the package that can't understand where it is running. Or if there is anything in the MSI that is trying to reference a network resource, that too will fail. That is the famed 2nd hop problem.

                          I don't think PowerShell is going to be an answer here, at least not with trying to repackage the MSI or coming up with an equivalent set of manual steps that you can run remotely.

                          Comment


                          • #14
                            Re: Running an MSI remotely

                            Back to the drawing board full-stop, I guess. Having ignored the issue of trying to put a PS1 file as a startup script thru Group Policy-Scheduled Tasks and spent 10 days doing it the way we know how, now I get to go back to Start and begin again.

                            Please let me win the lottery!!
                            *RicklesP*
                            MSCA (2003/XP), Security+, CCNA

                            ** Remember: credit where credit is due, and reputation points as appropriate **

                            Comment


                            • #15
                              Re: Running an MSI remotely

                              But think about how much you've learned!

                              If it was me, I'd look at using a old-fashioned batch file as a computer startup or user logon script pushed by a GPO.

                              Comment

                              Working...
                              X