asked on

PowerShell Script to Control IE

I have a script that we need to use on our domain to control a login for IE. However, I have it running just fine on a standalone Windows 8.1 machine but cannot get it to run on a domain Windows 8.1 machine.

I've scaled back to the script to an example just for testing purposes:

$URL = "https://accounts.google.com/ServiceLogin?service=mail&continue=https://mail.google.com/mail/"
$ie = New-Object -com InternetExplorer.Application
$ie.visible=$true
$ie.navigate($URL)
while($ie.ReadyState -ne 4) {start-sleep -m 100}
$ie.Document.getElementById("Email").value = "asdf"

All this should do is open IE and enter "asdf"as the username.

On the domain computer, this is the error that PowerShell gives us:

Method invocation failed because [System.__ComObject] does not contain a method named 'getElementById'.
At line:7 char:1
+ $ie.Document.getElementById("Email").value = "asdf"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : MethodNotFound

I've tried to run the script as an admin (elevated), disabled protected mode, and various combinations of the two but cannot figure out what is holding this up.

Any suggestions would be quite welcome!

Qlemo

Maybe a web proxy sends a different type of page as reply? Check what you get back as object in $ie.Document on your domain PC. You can issue a $Ie.Document | gm and/or dump $je,Document and/or $ie.Document.MimeType and compare.

robklubs

ASKER

Thanks for the speedy reply.

I followed your suggestion and got radically different results. On the domain PC, running just the $ie.Document got me this:

System.__ComObject

Running it on the non-domain computer I got quite a listing of objects (207 in all) which I would imagine is what I should be getting. (I won't post them unless you need.)

Trying to run the $ie.Document.MimeType results got nothing on the domain, but the non-domain results in "Chrome HTML Document". (My default browser is Chrome despite this script using IE.)

Qlemo

That is worse than expected. Obviously you get an empty COM object. The non-domain result is how it should be (no need to post it).
What happens if you display the web page (in IE) manually? You can use the dev tools too (F12) to analyze the resulting HTML code.

robklubs

ASKER

The webpage works fine otherwise.

F12 on the domain looks correct:

The non-domain looks similar if not the same.

Qlemo

Is PowerShell running elevated?

robklubs

ASKER

Yes, I've tried elevated:

I've also tried disabling protected mode for the Internet zone in IE. It's just odd that IE loads (via the script) but it does not allow input like it doesn't even see something to input to.

This domain PC is a VM, brand new with updates, and no virus protection. I removed the protection to troubleshoot (one less thing to deal with).

Qlemo

There was a recent, similar question posted here on EE, where the HTML Document has not been retrieved either, but only if running as scheduled task without interactive logon settings. I could not explain why, and still have no clue, why interactive or non-interactive makes a difference. Might be something similar here. The OP told that he saw the HTML Document be sent back to the IE client machine, but nothing was delivered to the script.

Rainer Jeschor

Hi,
question: when you remove the last line in the Powershell script, you should have a visible open IE window. Does this show the Google logon page?
Thanks.
Rainer

robklubs

ASKER

Qlemo - thanks for the help. I'm sort of glad it wasn't something simple.

Rainer - yes, removing the last line leaves me the the IE window with the Google login page. The script can call IE seemingly without issue, but cannot enter or even see any of the controls on the page. I've tried checking the "stay signed in" box as well with the same result.

Qlemo

Wait. You see the Google Login in IE, but have nothing in $ie.Document? That sounds like something is preventing Automation access.

robklubs

ASKER

That is correct - but I don't know what that could possibly be (preventing Automation access).

Qlemo

Do you use PS 3 or 4? Then try what

$html = Invoke-WebRequest "https://accounts.google.com/ServiceLogin?service=mail&continue=https://mail.google.com/mail/"
$html.InputFields | select Name

Open in new window

returns. Maybe that one allows access.

robklubs

ASKER

It appeared to . . . got this on both domain and non-domain:

PS C:\Windows\system32> $html = Invoke-WebRequest "https://accounts.google.com/ServiceLogin?service=mail&continue=https://mail.google.com/mail/"
$html.InputFields | select Name

name
----
GALX
continue
service
_utf8
bgresponse
Email
Passwd
signIn
PersistentCookie
rmShown

Using PS version 4 on both machines.

Qlemo

Of course you are using PS 4. It is W8.1, so stupid question I have asked ;-).
Have to think about what that could mean, and/or whether we can trick IE into working ...

robklubs

ASKER

No stupid questions here, I've been second guessing myself on this like crazy. I'm looking into if there is something outright preventing this from working. Gotta be something, just not sure what. Took a shot and checked the event viewer and there's nothing there either.

robklubs

ASKER

Still have not found the issue, but I removed the computer from the domain and it continues not to work. At this stage it is a brand new Windows 8.1 VM that cannot run this (simple) script.

Qlemo

Tested today on a domain-joined W8.1 (32bit), no issues with IE :/(. I have access to the HTMLDocument, so still cannot replicate your issue.
Did you try on a different W8.1 machine?
Any chance you have a 32bit on 64bit OS issue?

Qlemo

Would be interesting to have the working machine joined for a change.

robklubs

ASKER

I've now expanded this test.

Script is working fine on other physical Windows 8.1 boxes. Domain and non-domain joined. Also working fine on a Win7x86 non-domain.

It's not working on two test machines. Both are VM (VMware on ESXi 5.5). One is Win8.1 the other is Win7x64. I've had them both domain joined and non-domain joined. The script is failing with same errors as above.

Now, I understand what I just found and wrote but am having a hard time understanding why. I guess my next step would be to recreate one of those VM's, but I just don't see how two machines with different OS's are not working in the same fashion with the only similarity being virtual/ESXi.

SOLUTION

robklubs

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

SOLUTION

Qlemo

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

SOLUTION

robklubs

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER CERTIFIED SOLUTION

Qlemo

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

robklubs

ASKER

This issue really does not have a solution, but I figured out that Office was the differentiating factor that causes the IE automation to work or fail. The expert was great and was able to do additional testing to confirm.

I hope someone that really knows Office sees this post and can shed some light on what Office does/adds to enable the script.