Jump to content

Script doesn't work in background


 Share

Recommended Posts

So I've created the below 'script' to install software that has no silent options in their software within our Intune environment (installs run under system and are not visible to users)

 

$log = Fileopen("location to a log file here", 10)
FileWrite($log, 'Starting AutoIt3 script to click through installation...' & @CRLF)
AutoItSetOption("TrayIconDebug", 0)
FileWrite($log, 'Line 3: AutoItSetOption("TrayIconDebug", 0)' & @CRLF)

AutoItSetOption("Trayautopause", 0)
FileWrite($log, 'Line 6: AutoItSetOption("Trayautopause", 0)' & @CRLF)

AutoItSetOption("TrayIconHide", 1)
FileWrite($log, 'Line 9: AutoItSetOption("TrayIconHide", 1)' & @CRLF)

Opt("WinTitleMatchMode", 2)
FileWrite($log, 'Line 12: Opt("WinTitleMatchMode", 2)' & @CRLF)

BlockInput(1)
FileWrite($log, 'Line 15: BlockInput(1)' & @CRLF)

Run("pathto\setup.exe")
FileWrite($log, 'Line 18: Run("pathto\setup.exe")' & @CRLF)

WinWait("Main installation")
FileWrite($log, 'Line 21: WinWait("Main installation")")' & @CRLF)

ControlClick("Main installation","&Next >","[Class:Button; INSTANCE:1]")
FileWrite($log, 'Line 26: ControlClick("Main installation","&Next >","[Class:Button; INSTANCE:1]")' & @CRLF)

FileWrite($log, 'Line 27: Starting WinWait licence now...' & @CRLF)
WinWait("[CLASS:#32770]","Please enter the software licence number here. This number is located on the CD packaging.")
FileWrite($log, 'Line 28: WinWait("[CLASS:#32770]","Please enter the software licence number here. This number is located on the CD packaging.")' & @CRLF)

ControlSend("licence", "", "", "XXXX")

sleep(200)
ControlSend("licence", "", "", "XXXX")

sleep(200)
ControlSend("licence", "", "", "XXXX")

sleep(200)
ControlSend("licence", "", "", "XXXX")
FileWrite($log, 'Line 31-40: Written the license key in 4 parts of 4 numbers with small delays.' & @CRLF)

sleep(200)
ControlClick("Enter licence number","&Continue >","Button1")
FileWrite($log, 'Line 44: ControlClick("Enter licence number","&Continue >","Button1")' & @CRLF)

WinWait("Comfort Software","B&rowse...")
FileWrite($log, 'Line 47: WinWait("Comfort Software","B&rowse...")' & @CRLF)

ControlClick("Comfort Software","B&rowse...","Button1")
FileWrite($log, 'Line 50: ControlClick("Comfort Software","B&rowse...","Button1")' & @CRLF)

WinWait("Comfort Software","B&rowse...")
FileWrite($log, 'Line 53: WinWait("Comfort Software","B&rowse...")' & @CRLF)

ControlClick("Comfort Software","B&rowse...","Button1")
FileWrite($log, 'Line 56: ControlClick("Comfort Software","B&rowse...","Button1")' & @CRLF)

WinWait("Comfort Software","E&xisting Folders:")
FileWrite($log, 'Line 59: WinWait("Comfort Software","E&xisting Folders:")' & @CRLF)

ControlClick("Comfort Software","E&xisting Folders:","Button2")
FileWrite($log, 'Line 62: ControlClick("Comfort Software","E&xisting Folders:","Button2")' & @CRLF)

WinWait("Comfort Software","< &Back",60)
FileWrite($log, 'Line 65: WinWait("Comfort Software","< &Back",60)' & @CRLF)

sleep(5000)
BlockInput(0)
FileWrite($log, 'Line 69: BlockInput(0)' & @CRLF)

FileWrite($log, 'Line 72: Installer completed... Ending log file!' & @CRLF)

My issue is, when I run it by hand it goes through the whole installation perfectly. When deployed from Intune within system context it always gets stuck at the winwait between line 27-29. It for some reason can't pick that up. Any ideas? I've tried it with CLASS:#32770 as shown in the code snippet, I've tried it with window title name. All give the same effect of working when ran manually, but not when deployed under system context.

Any help would be greatly appreciated!

NOTE: I've redacted the license digits and certain paths to executables for obvious reasons.

Link to comment
Share on other sites

Ok, now you will have to find what is going on.  First do a WinList() of all the windows before the winwait so we can know if this particular window exists or not, if there is multiple windows having the same class, etc.  Save the result of the winlist in your log file. There is something fishy and you will need to search for it...

Link to comment
Share on other sites

25 minutes ago, Nine said:

Ok, now you will have to find what is going on.  First do a WinList() of all the windows before the winwait so we can know if this particular window exists or not, if there is multiple windows having the same class, etc.  Save the result of the winlist in your log file. There is something fishy and you will need to search for it...

As u asked I ran a WinList of all windows right before the WinWait in the script, below the results:

Main installation - InstallShield Wizard:  exists enabled
Main installation - InstallShield Wizard:  exists enabled
AutoIt v3:  exists enabled
Administrator: Windows PowerShell:  exists enabled
FC_FORTIWF_HIDDEN_WINDOW:  exists enabled
CWNPTransportImpl:  exists enabled
CWNPTransportImpl:  exists enabled
Windows Push Notifications Platform:  exists enabled
Wmi Provider Host:  exists enabled minimised
FC_SCH_HIDDEN_WINDOW:  exists enabled
ChangeNotify:  exists enabled
ChangeNotify:  exists enabled
ChangeNotify:  exists enabled
ChangeNotify:  exists enabled
CAutoInstallAPO:  exists enabled
FC_ESNAC_HIDDEN_WINDOW:  exists enabled
CWavesSysSvcService:  exists enabled
OfficePowerManagerWindow:  exists
HID Input Service:  exists enabled

The top 2 would be the installation. So I am guessing it is looking at the wrong Window for this. Any way to work around this?

Link to comment
Share on other sites

WinWait (and many other win* function) returns the Window Handle which is unique at the time.  Once you have found the right window, use thereafter the handle of the window instead of its title.

Link to comment
Share on other sites

1 hour ago, Nine said:

WinWait (and many other win* function) returns the Window Handle which is unique at the time.  Once you have found the right window, use thereafter the handle of the window instead of its title.

So I've used a few functions to get all windows based on title, and return their handles and window text to some text files. Suprisingly when I run it under a normal/admin user, it comes back nicely with handles and the text that all windows display.

Under the system user however, All I get is a handle and nothing else. Meaning that none of the open Windows will actually work?

Link to comment
Share on other sites

4 minutes ago, Davy2022 said:

All I get is a handle and nothing else

That is quite strange, never seen something like this.  It is not an AutoIt issue that's for sure.

Out of curiosity, how do you start the script with system user (task scheduler ?), is it a compiled .exe ?  Has your AV logged an event ?  The problem comes from your environment IMHO.

Link to comment
Share on other sites

6 minutes ago, Nine said:

That is quite strange, never seen something like this.  It is not an AutoIt issue that's for sure.

Out of curiosity, how do you start the script with system user (task scheduler ?), is it a compiled .exe ?  Has your AV logged an event ?  The problem comes from your environment IMHO.

AutoIt gets called from a powershell script that runs as a system user (powershell script is started via Microsoft Intune deployment with system context)

 

Just tried 

run("executable here")

(sleep x amount of time)

Local $hWnd = WinGetHandle("[active]")
Local $txt2 = WinGetText($hWnd)

then write handle to file with the text.

Unfortunately it just returns a file with the 0x00000000 meaning nothing is active. 

Link to comment
Share on other sites

If it's an installshield product you may be able to use the Setup.exe /r /f1"C:\Temp\Setup.iss" this should record your responses i.e. product key, when deploying you can copy the setup.iss into the same directory as Setup.exe and then use the command "Setup.exe /s" or use the /f1 option again.  Alternatively you could try using interactive mode for system account otherwise Windows won't appear for the user, however it's not generally recommended to use interactive mode with system account as an advanced user could elevate other processes .

Link to comment
Share on other sites

I'm guessing it's a privilege level issue.   Attempt to elevate the process to all access via open process,  if that doesn't work Attempt to get a dup handle to the process or open up a security debug token. Handles are weird like that.  Also try #Require admin.  <====first.  Scatter brained sry.

Link to comment
Share on other sites

Dav.

The top 2 would be the installation. So I am guessing it is looking at the wrong Window for this. Any way to work around this?

this how you get handle of same window

Local $value
   _GetHandleSameWindow("Untitled - Notepad",$value)
MsgBox(0,0,$value)
Func _GetHandleSameWindow($title,ByRef $tmp)
  Local $aList = WinList()
  Local $arr
    For $i = 1 To $aList[0][0]
           if WinGetTitle($aList[$i][0]) = "Untitled - Notepad" Then
        $arr &=   WinGetHandle($aList[$i][1])&@CRLF
        $tmp = $arr
           EndIf
             Next
          EndFunc

 

Edited by ad777

iam ِAutoit programmer.

best thing in life is to use your Brain to

Achieve

everything you want.

Link to comment
Share on other sites

In system context, without "interactive mode", graphical windows are not working this has been like this for ages. 

In Intune, from the top of my head, knowing Microsoft's products, there must be something like "run even when no users a logged in" (which means system context, you mustn't use this option), you must use a standard administrator context. 

 

It is a bad practice to use GUI for largr scale installations, and as mentionned earlier you can and must use command line in your situation. 

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