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

[graybags]

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 July 28, 2020 by graybags

[Sidley]

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

 

[Exit]

 

@graybags

Have you tried #requireAdmin ?

[graybags]

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.

[graybags]

55 minutes ago, Exit said:

 

@graybags

Have you tried #requireAdmin ?

Yep, it's normally always my first line of code in scripts I have to run at work.

[Marc]

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?

[graybags]

I reckon it must be something like that, shame I can't see what's going on inside.  I could use Total Commander I guess, but that wouldn't allow me to fix it, just find out a bit more how it won't work

[Marc]

or rename your autoit-exe to "explorer.exe" 😆

[graybags]

that's interesting...  I wonder if that would work?  bit confusing though!

[Jos]

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

Jos

[graybags]

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?

[Jos]

Second param of RunWait()

Jos

[Musashi]

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

[graybags]

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.

[Musashi]

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"

[graybags]

Ooh...  That actually seems to work.  So I can just call that from the Autoit script maybe?

[Jos]

So what about this version of RunWait ? :

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

Jos

[graybags]

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

 

[graybags]

Excellent!  That worked!  I cannot thank you all enough for the help.  Seems so easy now I look at it.  Thanks again.