Jump to content
graybags

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

Recommended Posts

Posted (edited)

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

Share this post


Link to post
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

 

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
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?


It's my job to comfort the disturbed and to disturb the comfortable.
My Projects: Profiler, MakeSFX, UserInfo, Simple Robocopy Progressbar

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
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?

Share this post


Link to post
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."

Share this post


Link to post
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.

Share this post


Link to post
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."

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.
  :)

Share this post


Link to post
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 :)

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...