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!
robklubsAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
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.
0
robklubsAuthor Commented:
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.)
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
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.
0
Cloud as a Security Delivery Platform for MSSPs

Every Managed Security Service Provider (MSSP) needs a platform to deliver effective and efficient security-as-a-service to their customers. Scale, elasticity and profitability are a few of the many features that a Cloud platform offers. View our on-demand webinar to learn more!

robklubsAuthor Commented:
The webpage works fine otherwise.

F12 on the domain looks correct:

Screenshot of F12 in IE on Domain PC
The non-domain looks similar if not the same.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Is PowerShell running elevated?
0
robklubsAuthor Commented:
Yes, I've tried elevated:

Elevated powershell with error
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).
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
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.
0
Rainer JeschorCommented:
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
0
robklubsAuthor Commented:
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.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Wait. You see the Google Login in IE, but have nothing in $ie.Document? That sounds like something is preventing Automation access.
0
robklubsAuthor Commented:
That is correct - but I don't know what that could possibly be (preventing Automation access).
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
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.
0
robklubsAuthor Commented:
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.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
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 ...
0
robklubsAuthor Commented:
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.
0
robklubsAuthor Commented:
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.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
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?
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Would be interesting to have the working machine joined for a change.
0
robklubsAuthor Commented:
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.
0
robklubsAuthor Commented:
Found this post: https://social.technet.microsoft.com/Forums/en-US/074bb76d-1900-4175-9be0-d462c1564c34/powershell-script-for-auto-gmail-logon-wont-work-on-2nd-system?forum=ITCG

Long story short, this person had the same issue on a machine without Office installed. Once they installed Office, the script ran with no issue.

Naturally, both my VM's don't have office on them. I just installed Office 2013 and the script now works. I wish I had taken a snapshot beforehand . . .

Does anyone know what this would be? Are there dll's or .NET components that are only present in systems with Office installed? Is there any way to tell?
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Got the same effect on W8 x64 VM (VMWare ESXi 5.0), with both 32bit and 64bit PS / IE, no Office.
0
robklubsAuthor Commented:
Thanks for confirming, Olemo.

Uninstalling Office causes the script to error out in the same fashion. I thought perhaps that Office had reinitialized a DLL or something but it's presence appears to be required to run a script that automates IE.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
BTW, each page has this behaviour. I tried with our home page, and there is nothing. So has to be something about registered COM types, though that sounds strange. I'm certain I'm using IE Automation in PowerShell on a XP machine without having Office installed :D.
I suppose Office replaces or patches a XML or HTTP DLL, or just creates a necessary registry entry ...
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
robklubsAuthor Commented:
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.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Powershell

From novice to tech pro — start learning today.