Powershell System.__ComObject.document property no longer works under IE 9

Question

I've been writing up a script that runs some server functions using a web-browser interface. I coded up the script on Windows 7 with Internet explorer 8 and it works fine. As soon as I move it to the production server running Windows 2008 with Internet Explorer 9, it breaks. Finally traced it the point of failure, but I'm a bit stumped how to fix it. Here's the code that will cause an issue:

$ie = new-object -com "InternetExplorer.Application"
$ie.navigate("http://www.google.com")
$ie.visible = $True
$doc = $ie.document
$Object1 = $doc.getElementByID("pocs")

This pops up an IE windows, and it should be able to search elements by ID. Trouble is, now I get the error

"Cannot find an overload for "getElementById" and the argument count: "1"."

I can find very very little on this error. The actual issue is actually the variable $doc. If I do a "$doc | get-member" on IE 9 I get:

TypeName: System.__ComObject#{c59c6b12-f6c1-11cf-8835-00a0c911e8b2}

But under IE 8 I get:

  TypeName: mshtml.HTMLDocumentClass

So, basically, IE 9 / Windows 2008 is failing to load the web document contents when I call $ie.document. I've tried setting IE9 to compatibility mode, but no luck there.

The $ie.document | get-member does actually show the method of : "getElementById Method Variant getElementById () " so it's in there, but there's no document for it to parse.

Any ideas would be greatly appreciated.

Glassman

The type name here is as you expect on Windows 7 with IE 9. Your problem seems to lie elsewhere. – Underpainting

I can confirm Joey. Here no error is thrown.. – Isochronism

Hmm, interesting. So it does appear to be a windows 2008 issue. Though, interestingly enough, uninstalling IE9 and installing IE8 causes the script to work flawlessly. – Glassman

Try Setting the Compatibility mode for IE9 #6065859 – Solis

Hmm... for me (hitting a local intranet site) the compatibility mode for IE9 didn't make a difference (also, it was switched on by default). – Bihari

Just an update in case anyone else runs into this same issue. Powershell 2.0 only works with up to IE8 for scrapping the web-page and using it as an Object. Powershell 3.0 has been upgraded to work with IE9. So, the answer is upgrade :) – Glassman

Also, someone else answered my question here. Turning off protected mode or running the script as admin worked: https://mcmap.net/q/908884/-powershell-ie9-comobject-has-all-null-properties-after-navigating-to-webpage – Bihari

Answer 1

I am equally astonished this has not been fixed yet given the longevity of the issue on various technical forums. However I think I have found the solution, though it would be up to the Microsoft IE team to address at some point.

Like all the threads referenced that have looked into this I have suffered the same issue with the getElementById method, which with no other changes to a couple of test machines (one Windows 2008R2 Enterprise 64bit and one Windows 7 32bit), I can get the same script to work.

Workarounds that worked as temp solution that I didn't like:

1. Using the dev console in IE11, switch the Document Mode to 8 (9,10,11,Edge (default) don't work) - my automation script works instantly. No changes to IE trusted sites, zone security, protected mode, PowerShell session priveleges). So clearly just a component issue of the IE11 installation of some sort
2. Installing Office 2013, without ever running or licensing it, the same script works instantly without changing the Document Mode of IE11. Clearly Office does install/register something that fixes the problem (as Rhys Edwards says)

So I set about narrowing down what Office does to enable the COM object required for IE automation by:

1. Preparing a new Virtual Windows 2008R2 Server , no updates. Ran test script under IE8 - no issues.

2. Upgraded to IE11. Ran test script - failed as usual.

3. Took a VM snapshot

4. Used Regshot to do record the registry and file system

5. Ran the Office 2013 Pro_SP1 installation, no changes to default options When Office install completes, did not run office once (at all ever) Ran test script again - everything works, the IE automation with getElementById calls all back in operation

6. Took a 2nd VM snapshot

7. Ran 2nd scan with regshot and analysed the differences

8. Dumped the properties of my $ie object and also noticed there is far more there than before running Office install. References mshtml.dll and HTMLDocument classes throughout - looks as it should

9. I can see from the RegShot difference file that MSHTML.dll is ADDED and registered in the GAC (version 7.0.3300.0) by the office installation

What I did next may not be completely approved but:

1. I located the microsoft.mshtml.dll in the "c:\program files(x86)\Microsoft.net\primary interop assemblies" folder and saved it out of the VM to my local machine desktop

2. reverted to the pre-office 2013 snapshot

3. copied the microsoft.mshtml.dll into the VM and installed to the GAC (remember this is a 2008R2 server still on .net 2, I didn't update .net prior to or after IE11 install, only office). I installed to the GAC simply by dragging the file into the c:\windows\assembly view in explorer. In later versions of .Net you need to use gacutil /l

4. Tested the same script and BOOM, it all works fine. No need to change any IE settings or elevate script privileges or install Office

So to sum up. If you install IE11, to get PowerShell to automate the Document Model, I had to (re-)register the mshtml.dll in the GAC. Why the IE11 installation doesn't ensure this happens is beyond me but I think that the IE team need to look into this.

I also think for those where it 'just works' in IE10/11, you must have a product on the machine that has already registered the mshtml.dll in the GAC (perhaps Office, perhaps Visual Studio or some other MS app). Hence why you are not seeing the same problem that definitely exists.

Hope this helps someone - it was driving me crazy!

Andrew

Cabriolet

Answer 2

As detailed in the comments on the question, there seems to be three solutions to this problem.

1. Upgrade to PowerShell 3.0: Version 2.0 is only compatible with up to IE8 when it comes to web-scraping and using IE as an object. However, version 3.0 will work with IE9. You can get it here.
2. Turn off protected mode in IE: Turning of protected mode for the Internet zone under the Security tab in settings seemed to do the trick for me. There are security implications to this that should be carefully considered.
3. Run the script in admin mode: Simply run the script in an elevated PowerShell prompt.

The last two solutions come from a different SO answer.

Bihari

PowerShell v4 still doesn't work and I have protected mode off :( – Erotomania

Answer 3

I had similar kind of issue and it got resolved by following below steps:

1. Check for the Microsoft.mshtml.dll on your machine. It should be available at location C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies. If you don't find it at this location, It might be the case that you don't have this dll and this is the reason you are getting this issue.

2. Find the dll, and try to load the assembly at run time. You can place the dll at any location on you machine and do it. Below is the link to a method to load assembly at run time. https://onedrive.live.com/?cid=21ad54fd70600673&id=21AD54FD70600673%211922

Inept