Jump to content

The executable doesn't work if I run it from a script... why???


Recommended Posts

Hi,

I work in IT for a very large company, and to build our PC's we have to boot from a USB key which installs Windows over the network, which is all controlled by Central IT.  That's all well and good, but for the environment I work in we have to install various other apps, do lots of tweaks etc. etc.  We have to do this for almost 1000 people, so we try and automate as much of the set up as we can, as we sometimes have to build a large number of PC's in one block.  Anyway, part of what I have to have due to the way Microsoft have apparently changed licensing with Office, is to uninstall Office 365 and install Office 2016. 

I can get the Office 365 uninstall to work from the script, but I can't do the Office 2016 install.  Both the install and uninstall apps we have to use were written by Central IT, so I can't see what they do internally.  We have to map a network share and then run a file, it's as simple as that, nothing technical.  Quite often we copy things locally from the share, then run it locally, as not everything will run in Autoit from the share.  Anyway, that's alot of waffle.

Here's what I do to uninstall Office 365 and it runs fine:

Func UninstallOffice365()
    DirCopy ( "\\server\share\folder\folder", "C:\temp_file\office365",1 )
    RunWait ( "c:\temp_file\office365\remO365.exe" )
    DirRemove ( "c:\temp_file\office365", 1 )
 EndFunc

But when I try to install Office 2016, it jumps right past the install bit and brings up a "finalizing installation window".  If I run the executable directly, it works, just not if I call it from Autoit.

Func InstallOffice2016()
    DirCopy ( "\\server\share\folder\folder", "C:\temp_file\office2016", 1)
    RunWait ( "C:\temp_file\office2016\setupapp.exe" )
    DirRemove ( "c:\temp_file\office2016", 1 )
 EndFunc

Am I missing something?  Or does it look like it should work?  I've been pulling my hair out over this, it just doesn't sound logical to me.  How can it work if I manually double click a file, but not if I call if from a script?

Cheers,

Graybags

Edited by graybags
Link to comment
Share on other sites

You could try some basic debugging, both DirCopy and RunWait return values (So does DirRemove for that matter), these might give you some indication as to where it's failing:

Func InstallOffice2016()
    Local $copyResult = False
    Local $runResult = False
    $copyResult = DirCopy ( "\\server\share\folder\folder", "C:\temp_file\office2016", 1)
    If Not $copyResult Then
        ConsoleWrite("Error copying file")
    EndIf
    $runResult = RunWait ( "C:\temp_file\office2016\setupapp.exe" )
    ConsoleWrite("The result of running installer: " & $runResult)
    DirRemove ( "c:\temp_file\office2016", 1 )
 EndFunc

 

Link to comment
Share on other sites

1 hour ago, Sidley said:

You could try some basic debugging, both DirCopy and RunWait return values (So does DirRemove for that matter), these might give you some indication as to where it's failing:

Func InstallOffice2016()
    Local $copyResult = False
    Local $runResult = False
    $copyResult = DirCopy ( "\\server\share\folder\folder", "C:\temp_file\office2016", 1)
    If Not $copyResult Then
        ConsoleWrite("Error copying file")
    EndIf
    $runResult = RunWait ( "C:\temp_file\office2016\setupapp.exe" )
    ConsoleWrite("The result of running installer: " & $runResult)
    DirRemove ( "c:\temp_file\office2016", 1 )
 EndFunc

 

I have... The directory does actually get copied, so that's not the problem.  And the Runwait returns a 0 error code.

Link to comment
Share on other sites

Just a wild guess, but according to your description, I could imagine that the office2016 installer-exe checks which process has started it.

If the parent process is explorer.exe (which is the case if you simply make a double-click in windows explorer) it installs. If the calling exe has another name it acts different.

For fun and giggles, could you run the installer from another file manager, let's say "total commander" and see what happens?

Any of my own codes posted on the forum are free for use by others without any restriction of any kind. (WTFPL)

Link to comment
Share on other sites

  • Developers

Have you tried adding the Workdir to the RunWait() Statement pointing that to "C:\temp_file\office2016"?

Jos

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

31 minutes ago, Jos said:

Have you tried adding the Workdir to the RunWait() Statement pointing that to "C:\temp_file\office2016"?

Jos

I'm not sure...  I *think* I did, but then I didn't really understand what "working directory" meant anyway.  Could and would that make a difference?

Link to comment
Share on other sites

53 minutes ago, Jos said:

Second param of RunWait() :)

This would work as follows:

$runResult = RunWait ("C:\temp_file\office2016\setupapp.exe", "C:\temp_file\office2016\")

 

4 hours ago, Marc said:

Just a wild guess, but according to your description, I could imagine that the office2016 installer-exe checks which process has started it. If the parent process is explorer.exe (which is the case if you simply make a double-click in windows explorer) it installs. If the calling exe has another name it acts different.

It is possible to start an application via the explorer.exe ,

$runResult = RunWait(@WindowsDir & "\explorer.exe C:\temp_file\office2016\setupapp.exe", "C:\temp_file\office2016\")

but then you might face the problem, that despite #RequireAdmin, these rights will not be forwarded by the Explorer.

Here is an older link (not sure, if the content is still valid) : running-explorer-under-admin-credentials

Musashi-C64.png

"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."

Link to comment
Share on other sites

14 hours ago, Musashi said:

This would work as follows:

$runResult = RunWait ("C:\temp_file\office2016\setupapp.exe", "C:\temp_file\office2016\")

 

It is possible to start an application via the explorer.exe ,

$runResult = RunWait(@WindowsDir & "\explorer.exe C:\temp_file\office2016\setupapp.exe", "C:\temp_file\office2016\")

but then you might face the problem, that despite #RequireAdmin, these rights will not be forwarded by the Explorer.

Here is an older link (not sure, if the content is still valid) : running-explorer-under-admin-credentials

Tried that, and although I was excited...  It never worked.  The folder copies across ok but it still doesn't seem to want to run the install.  Damn!

The admin credentials I don't think is an issue, as I am logged onto the PC as an admin.

Oh well, thanks everyone for the suggestions.

Link to comment
Share on other sites

Just out of curiosity. What happens if you create and execute the following .cmd file in the C:\temp_file\office2016\ directory? Use e.g. the file name SetupOffice2016.cmd

@echo off
cls
cd %~dp0
Start "Office 2016 Install" /wait "setupapp.exe"

Musashi-C64.png

"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."

Link to comment
Share on other sites

  • Developers

So what about this version of RunWait ? :

$runResult = RunWait (@comspec ' /c "C:\temp_file\office2016\setupapp.exe"', 'C:\temp_file\office2016')

Jos

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

I had about 4 test PC's I was running these scripts on.  I just went to a meeting and came back to find that someone is putting them out on the shopfloor!

I'm going to have to restage another PC from scratch and try that script, but it looks good and I'm excited, thanks :)

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...