0

I had a similar issue compared to the following SO threads:

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

PowerShell IE9 ComObject has all null properties after navigating to webpage

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

My error was something to the effect of:

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

So I looked at each of these threads to help determine the why and the solutions to this problem.

I'm running PowerShell 4.0 on Windows Server 2012 R2. The script runs with Execution Policy Bypass and I am also running PowerShell as an Administrator (i..e. Administrator: Windows PowerShell ISE) AND my user account is part of the Administrator group. The URL the script is accessing is on the Intranet (one would think Internet Explorer isolates it to the proper zone, namely the Intranet Zone).

The script worked fine on my local machine but not on this server.

Here are the list of things I tried--one at at time, never in combination--that failed to yield a successful outcome:

  • Disabled Protected Mode in the Internet Zone.
  • Added URL to Trusted Zone Sites. Note that Protected Mode was already disabled. Only change I made here was adding the URL to the Trusted Sites list.
  • Disabled IE Enhanced Security Configuration completely. Administrators was already set to Off, but Users was set to On. I set Users to Off, which had no effect.
  • Ensured PowerShell ISE was running in Administrator mode (elevated privileges). It didn't seem to matter what mode PowerShell ISE was running in, likely because Execution Policy is set to Bypass.
  • Added URL to Intranet Zone Site List. Note that Protected Mode was set to disabled, prior to. Only change I made in this zone was adding the URL to its Site List. Initially worked but then I tried again and same problem. May have been a fluke that it worked.

Here are the list of things that I tried--again, one at a time--that solved the problem:

  • Added URL to Compatibility View with Display intranet sites in Compatibility View unchecked.
  • Added URL to Compatibility View with Display intranet sites in Compatibility View checked.

So the question is why does employing Compatibility View resolve the problem? What's different about this that the other things I tried didn't work?

One would think Trusted Zone Site List should do the trick. Security Level for Trusted Zone is set to Medium. For Intranet Zone, it's Medium-low. And for Internet Zone, it's set to Custom.

Is it related to one or more of the individual properties that you can set in a Security Level? Is it something under the covers with Registry, COM, IE?

Good thing is I found 2 solutions which worked. Bad thing is I don't quite understand why. Obviously, it works because of some relaxed security permissions. Maybe it's also tied to Group Policy settings. I'm not sure.

Anyone have any ideas here? Thank you.

Community
  • 1
  • 1
user3621633
  • 1,681
  • 3
  • 32
  • 46
  • 1
    The security restrictions on server versions of IE are higher than those of a desktop IE on windows. Localhost maps to the Internet zone by default. Use the File>Properties menu in IE to confirm that localhost is mapped to the zone you expect. You can find out which IE Emulation mode is being used and how it was established (eg. x-ua header, Enterprise site mode lists) from the Emulation tab of the dev tool (F12). To debug blocked content from tracking protection and security restrictions, go Internet Options>Advanced tab, check "Always record developer console messages" – Rob Parsons May 13 '17 at 10:12
  • Thank you for your help. I did as you said. Zone is Internet Zone with Protected Mode off. I moved the site to Local Intranet Zone (w/ Protected Mode off). Internet Zone is locked down to High and I cannot change it. Local Intranet Zone Security is set to Low. I checked local group policy settings on the server and seems most settings are not configured. It seems like no matter what I do, on the server, it needs comp. view settings enabled, in order for PowerShell to access the field. Doesn't make a difference what Zone the site is in. Page is minimal HTML. No client-side warnings or errors. – user3621633 May 15 '17 at 18:44
  • Since local group policy appears to be minimally configured, then I imagine these security restrictions on the browser are embedded in the registry or maybe some Windows system COM or DLL files, since IE is integrated with Windows. It'd be good to know why this works. I don't see a security setting in IE which could trigger this. Maybe if I run Windows Sysinternals Process Monitor (aka ProcMon), I'll get a better idea of what's going on. – user3621633 May 15 '17 at 18:48
  • 1
    From your description it sounds like you are using IE11 on an actual server version of windows (on your desktop?).. Use a windows client to develop and test... that's the bottom line.... do not tweak your server version of windows to accommodate web development on it... Its locked down for good reason. – Rob Parsons May 15 '17 at 21:41
  • Yes, IE11 on a windows server. The code was developed and tested on client. The goal in mind was to run it on the server (as a temporary stopgap solution). I don't disagree with you, of course. Definitely not looking to tweak windows server settings. Just fascinated why comp. view settings on a windows server permitted Powershell to reference an HTML element in its code. – user3621633 May 16 '17 at 14:36
  • Even administrators are corked on server versions of IE. – Rob Parsons May 17 '17 at 00:13

0 Answers0