I've been searching for a solution to this for a while and I'm stunned and embarrassed I haven't found more helpful pages with information how to solve this problem for myself.

I have a few different scripts that spawn an instance of IE, navigate to the page, then update and click elements.  They work fine with IE 8, but nothing newer.  

$ie = New-Object -comobject InternetExplorer.Application
$ie.Visible = $true
$ie.Navigate($URL)

This works fine.  I can type $ie.document | gm at the console and see getElementById, getElementsByClassName, etc in the list of methods and properties, but if I try to access them I get an error:

Cannot find an overload for "getElementsByClassName" and the argument count: "1".
At line:1 char:36
+ $ie.document.getElementsByClassName <<<< ("input")
    + CategoryInfo          : NotSpecified: (:) [], MethodException
    + FullyQualifiedErrorId : MethodCountCouldNotFindBest

I found this link:

http://stackoverflow.com/questions/17924770/how-can-i-translate-or-run-a-vbscript-function-inside-a-ps1-file

That gets me a little bit further:

$EmailField = [System.__ComObject].InvokeMember("getElementsByClassName",[System.Reflection.BindingFlags]::InvokeMethod, $null, $ie.document,"email")

If I output $EmailField I get a long list of properties that includes:

type                         : email
value                        :
name                         : email

But when I try to edit $EmailField, I get another error:

PS C:\Users\user> $EmailField.value
PS C:\Users\user> $EmailField.type
PS C:\Users\user> $EmailField.name
PS C:\Users\user> $EmailField.value = "email@email.com"
Property 'value' cannot be found on this object; make sure it exists and is settable.
At line:1 char:13
+ $EmailField. <<<< value = "email@email.com"
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : PropertyAssignmentException

Also from the previous site I tried using the similar method as above:

[System.__ComObject].InvokeMember("value",[System.Reflection.BindingFlags]::SetProperty,$null,$EmailField,"email@email.com")

But that caused another error:

Exception calling "InvokeMember" with "5" argument(s): "Unknown name. (Exception from HRESULT: 0x80020006 (DISP_E_UNKNO
WNNAME))"
At line:1 char:34
+ [System.__ComObject].InvokeMember <<<< ("value",[System.Reflection.BindingFlags]::SetProperty,$null,$EmailField,"emai
l@email.com")
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

I found another link that mentioned a missing microsoft.mshtml.dll and related it to this problem with IE without Office installed, which I can't find now, but copying that file and loading it didn't make any difference in the behavior.

I can't believe I'm the only one having this problem...anyone have an idea how I can access the IE Com object on newer versions? 

Here's the other link, the missing file solution is detailed under Workarounds:

http://connect.microsoft.com/PowerShell/feedback/details/764756/powershell-v3-internetexplorer-application-issue

Hi Rhys,

I have tested with these IE version for your reference:

IE 10 on WIN7 with powershell 3.0:

I tested with no method "getElementsByClassName" available on the object:$ie.document

IE 11 on WIN8.1:

I tested with the script below, and the method "getElementsByClassName" can only be found on the object "$ie.Document.body":

$url="http://www.bing.com/?setmkt=en-US&setlang=en&uid=B4402711&FORM=NFTOUS"
$ie.Navigate($URL)
$ie.Visible = $true
#the same div id is "hp_sw_hdr", classname is "hp_hor_hdr"
$ie.Document.getElementById("hp_sw_hdr")
$ie.Document.body.getElementsByClassName("hp_hor_hdr")

If I have any misunderstanding, please feel free to let me know.

If you have any feedback on our support, please click here.

Best Regards,

Anna Wang

TechNet Community Support

Thanks Anna.  If I $ie.document | gm it does show getElementsByTagName and getElementsByClassName methods, among others.  But here's what happens if I try $ie.document.body.getElementsByClassName:

and I didn't have to include .body on IE8:

Hi Rhys,

I would like to confirm more detailed information from you to make more tests:

1.  What's the version of Operating System you used and ran into the issue, I want to check if I can reproduce the same error.

2.  In addition, please also make sure the input Element Id and Element ClassName are right, to get these items from website, please go through this thread:

[Forum FAQ] How To Automatic Sign In Websites with Windows PowerShell

3.  I also tested the script, and got the Null valued expression error as you, and found this script is better:

$ie = New-Object -comobject InternetExplorer.Application
$ie.visible=$true
$url="http://www.bing.com/?setmkt=en-US&setlang=en&uid=B4402711&FORM=NFTOUS"
$ie.Navigate($URL)
while($ie.ReadyState -ne 4) {start-sleep -m 100}
#the same div id is "hp_sw_hdr", classname is "hp_hor_hdr"
$a=$ie.Document.getElementById("hp_sw_hdr")
$b=$ie.Document.body.getElementsByClassName("hp_hor_hdr")
$A

$B

$ie.quit()

And this is the screenshot I tested on Win 8.1:

If you have any feedback on our support, please click here.

Best Regards,

Anna Wang

TechNet Community Support

Same issue, Win7 SP1 x64, IE 11, PS 2.0

Its curious why it's a different error message with and without the .body, since if I get-member on document all the methods I'm trying to use are listed just like they are for .body:

PS C:\> $ie.Document | gm | ?{$_.name -match "get"}

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

Name                   MemberType Definition
----                   ---------- ----------
getElementById         Method     Variant getElementById ()
getElementsByClassName Method     Variant getElementsByClassName ()
getElementsByName      Method     Variant getElementsByName ()
getElementsByTagName   Method     Variant getElementsByTagName ()
getElementsByTagNameNS Method     Variant getElementsByTagNameNS ()
getSelection           Method     Variant getSelection ()

On IE 11 (windows 7), I was able to do the following successfully:

$ie = New-Object -comobject InternetExplorer.Application
$ie.Visible = $true
$ie.Navigate($URL)
$ie.Navigate("www.facebook.com")
$ie.document.getElementById("pass")
$ie.document.getElementById("pass").value = "Hi"

This correctly set the password field. Interestingly, the only 'get' methods I have are:

getElementById
getElementsByName
getElementsByTagName

On a brand spankin' clean install of Windows 7 SP1 with IE 8 that works.  After installing IE 11 and nothing else, I get the same result:

PS C:\> $ie.document.getElementById("pass")
Cannot find an overload for "getElementById" and the argument count: "1".
At line:1 char:28
+ $ie.document.getElementById <<<< ("pass")
    + CategoryInfo          : NotSpecified: (:) [], MethodException
    + FullyQualifiedErrorId : MethodCountCouldNotFindBest

PS C:\> $ie.document.body.getElementById("pass")
You cannot call a method on a null-valued expression.
At line:1 char:33
+ $ie.document.body.getElementById <<<< ("pass")
    + CategoryInfo          : InvalidOperation: (getElementById:String) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull

And I just tried it on Windows Server 2012 R2, same result.

Has this been resolved? We're having the same issue on Server 2012 R2 as well.

No, but thanks for bumping this up.

Actually, I found a setting in IE that I thought might be involved but mysteriously this is no longer a problem on my Win7/IE11 laptop.  It is still a problem on my Win10 vm, haven't tried any other OS/IE combination yet.

Well, I have an answer for myself, although I don't really call it a solution.  I created a VM, applied all updates except IE 9 through 11 and tested, various get and set methods worked.  Then I installed IE 11 and tested, the methods didn't work. Last I installed Office 2013 and now all IE com methods seem to be working as expected and a few Get-Methods show much different capabilities.  I shouldn't have to pay for an Office license to be able to use their 'free' built-in browser as a scripted gui.

Hi,

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 didnt 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
6. When Office install completes, did not run office once (at all ever)
7. Ran test script again - everything works, the IE automation with getElementById calls all back in operation
8. Took a 2nd VM snapshot
9. Ran 2nd scan with regshot and analysed the differences
10. 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
11. 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 didnt 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, you need to (re-)register the mshtml.dll in the GAC. Why the IE11 installation doesnt ensure this happens is beyond me but i think that the IE team need to look into this.

I also think Anna, you must have a product on the machine you are testing Rhys's script on 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 definately exists. It shouldnt take the IE team long to isolate this, given that it just took me a couple of hours doing the above. Could you please refer this to them for a fix in a future release/update?

Hope this helps someone - it was driving me crazy!

Andrew

• Edited by Andrew Johnson (IT) 21 hours 5 minutes ago typos

Hi,

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 didnt 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
6. When Office install completes, did not run office once (at all ever)
7. Ran test script again - everything works, the IE automation with getElementById calls all back in operation
8. Took a 2nd VM snapshot
9. Ran 2nd scan with regshot and analysed the differences
10. 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
11. 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 didnt 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, you need to (re-)register the mshtml.dll in the GAC. Why the IE11 installation doesnt ensure this happens is beyond me but i think that the IE team need to look into this.

I also think Anna, you must have a product on the machine you are testing Rhys's script on 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 definately exists. It shouldnt take the IE team long to isolate this, given that it just took me a couple of hours doing the above. Could you please refer this to them for a fix in a future release/update?

Hope this helps someone - it was driving me crazy!

Andrew

• Edited by Andrew Johnson (IT) Sunday, May 31, 2015 10:03 AM typos

Hi,

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 didnt 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
6. When Office install completes, did not run office once (at all ever)
7. Ran test script again - everything works, the IE automation with getElementById calls all back in operation
8. Took a 2nd VM snapshot
9. Ran 2nd scan with regshot and analysed the differences
10. 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
11. 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 didnt 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, you need to (re-)register the mshtml.dll in the GAC. Why the IE11 installation doesnt ensure this happens is beyond me but i think that the IE team need to look into this.

I also think Anna, you must have a product on the machine you are testing Rhys's script on 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 definately exists. It shouldnt take the IE team long to isolate this, given that it just took me a couple of hours doing the above. Could you please refer this to them for a fix in a future release/update?

Hope this helps someone - it was driving me crazy!

Andrew

• Edited by Andrew Johnson (IT) Sunday, May 31, 2015 10:03 AM typos

Security!

Not sure what you mean by Security - a bit more elaboration would be helpful. However given that the installation of Office or the microsoft.mshtml.dll into the GAC as the only change restores this functionality, i would suggest it isnt security in this particular case. Unless you are suggesting installing Office relaxes the IE security model (which i am sure it doesn't and would be alarmed if it did)

Thanks

Andrew

Hey! found another solution.

Just enable the Internet Explorer Enterprise Mode.

In Internet Explorer, Press "ALT" key, go to Tools -> Enterprise Mode.

If Enterprise Mode is not available:

• Launch GPEDIT.MSC
• Go to User Configuration > Administrative Templates > Windows Components > Internet Explorer > Let users turn on and use Enterprise Mode from the Tools menu
• enabled

and it work !

That works, but it isn't a suitable solution.  It doesn't enable by default, you have to enable it every time you launch IE.  And that's changing the behavior of IE to make it more compatible, I'm not convinced that's really fixing the problem.  But thanks for the tip, that could work in a pinch.