Tumulus

Script Fails to Open

11 posts in this topic

I have a code that will open an application we use for remote connections here at work and then change the password for it. We were audited recently and told our security was a bit lax, so we are overhauling our password convention and changing our current passwords.

This script was working until just this morning and then started to give an error right at the cusp of QA testing. It says "Line 0 ("M:\Scripts\AutoIT\TVPasswordChange.au3"): Error: Error opening the file"

I haven't seen this before, and I don't think we made any significant changes to our code (I added the two control sends to delete the contents of the password field) that could have caused it. Any ideas why it might be failing to open?

#RequireAdmin

Global $SingleClick = 1

If ProcessExists(13696) Then
    MsgBox(0, "", "TeamViewer process already exists. Closing process.")
    ProcessClose(13696)
    ProcessWaitClose(13696)
EndIf

Run("cmd")
WinWaitActive("Administrator")

   Send("cd C:\Program Files (x86)\TeamViewer\Version8\")
   Send("{Enter}")

   Send("TeamViewer.exe")
   Send("{ENTER}")

WinWaitActive("TeamViewer")
    Sleep (1000)

    $pos = WinGetPos("[ACTIVE]")
    $x = 115
    $y = 40

    MouseClick("left", $pos[0] + $x, $pos[1] + $y) ;clicks "Extras"
         Sleep (500)
    MouseClick("left", $pos[0] + $x + 15, $pos[1] + $y + 25) ;clicks "Options"
         Sleep (500)

WinWaitActive("TeamViewer options")

    ControlClick("TeamViewer options", "TvOptionList", 20586, "left", $SingleClick, 32, 48) ;clicks "Security"
         Sleep (500)

    ControlSend("TeamViewer options", "", 20065, "^a{BS}");deletes the password field
         Sleep (500)
    ControlSend("TeamViewer options", "", 20065, "password");types in "Password" field
         Sleep (500)

   ControlSend("TeamViewer options", "", 20066, "^a{BS}");deletes the confirm password field
         Sleep (500)
    ControlSend("TeamViewer options", "", 20066, "password");types in "Confirm Password" field
         Sleep (500)

    ControlClick("TeamViewer options", "O&K", 1, "left", $SingleClick, 40, 10);clicks "OK"


MsgBox(0, "SUCCESS", "The Teamviewer password has been succesfully changed")

WinClose("TeamViewer")
WinClose("Administrator")

Share this post


Link to post
Share on other sites



That is actually a good point. Also, scary article. Glad I don't use Teamviewer for personal stuff. I'll be sure to forward that around. Appears that our passwords really could use an update.

What could I use in place of the pid? Could I put "TeamViewer" in place of it?

Also, I ran into an issue using Run and couldn't quite figure it out, so did this as a work around. I'll give run another look.

 

Share this post


Link to post
Share on other sites

Possibly the AV. I can check SCEP, though I don't think we have updated since yesterday when the script was working. I'll poke around and let you know.

 

Share this post


Link to post
Share on other sites

Turn SCEP off altogether and then retry.


√-1 2^3 ∑ π, and it was delicious!

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

I turned off SCEP and firewall but the error still persisted. However, I took the file from off of my personal network drive and copied it to the desktop. It runs just fine from there. Would there be an issue with permissions when accessing the script from my drive or something? I've never had issues before, although I am using a different machine today than the one I usually use.

Edited by Tumulus

Share this post


Link to post
Share on other sites

By elevating the script using #RequireAdmin, and then running the script from a network share, you could be running into a permissions issue. What is your eventual goal for deploying this to your machines (manual copy and paste, GPO, SCCM, etc.)?


√-1 2^3 ∑ π, and it was delicious!

Share this post


Link to post
Share on other sites

That makes sense. I could possibly take the #require admin off...

SCCM is the goal, though if we have compliance issues (our SCCM isn't as reliable as we would like) then GPO is an option. 

Share this post


Link to post
Share on other sites

So remove the #requireadmin, and use psexec to run it as system, as I am guessing that is how you'll do your deployment in the end.


√-1 2^3 ∑ π, and it was delicious!

Share this post


Link to post
Share on other sites

Yeah. Great idea there. Thanks!

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