8

I have a Powershell script that is supposed to run an Invoke-WebRequest against a site. I want to use this script with PRTG Network Monitor to ensure that a web server is up and running properly.

Currently, the script works running from my local machine as well as running with my domain credentials on the probe server. However, it doesn't run when logged in with the local admin credentials which is what PRTG uses.

I've narrowed it down to a single line,

Invoke-WebRequest $uri -Method POST -Body $body -TimeoutSec 10

It appears that for whatever reason, when using this account, Invoke-WebRequest will not work. When running that line, it doesn't produce anything, no error, warning, or output. Both $uri and $body variables are already defined as well.

Even if I'm logged into the probe server with the local admin PRTG account and run Powershell as another user (using my own credentials) it still fails to produce anything.

Why would a local admin account not be able to run Invoke-WebRequest? This is happening on a Windows Server 2012R2 with PSVersion 4.0.

Moerwald
  • 10,448
  • 9
  • 43
  • 83
Shawn L.
  • 83
  • 1
  • 1
  • 4

2 Answers2

16

[Turning my comment into an answer]

In Windows PowerShell, Invoke-WebRequest uses the Internet Explorer engine for parsing websites, unless you tell it not to. IE has a lot of restrictions - coming from its security model of Trusted Sites/security zones, IE Enhanced Security, overrides by Group Policy, maybe more, and it looks like you'd tried everything else sensible, and it was worth trying to test that directly.

This switch: 

Invoke-WebRequest -UseBasicParsing ....

avoids the IE engine and makes a HTTP request and processes the response all within C#/.Net.

The trade-off is that you get plain text results to work with and can't access the page through the HTML DOM, no getElementByTagName() or anything that needs a live browser engine to work.

TessellatingHeckler
  • 27,511
  • 4
  • 48
  • 87
  • 1
    Thanks for this. Finally figured out why some background job did not work while a client running the same script did work. Saved my weekend (y) – PNS Jun 05 '20 at 17:46
  • still fails, I get `Invoke-WebRequest : Die Verbindung mit dem Remoteserver kann nicht hergestellt werden` – Timo Mar 25 '21 at 18:19
  • I run a webserver on port 3000 and put: `Invoke-WebRequest -Uri http://localhost:3000 -UseBasicParsing`. I got the error from above. Howerver, `Invoke-WebRequest -Uri http://test.de` works. – Timo Mar 25 '21 at 18:43
  • @Timo you're doing a different thing, and getting a different error, and this question was 2 years ago. Probably not the right place to troubleshoot it. I can run `NetCat` from the nmap project in one window using `ncat -l -p 3000` to listen on port 3000 like a webserver, and `invoke-webrequest -uri http://localhost:3000 -UseBasicParsing` in another window to connect, and the connection works, and the netcat window gets the HTTP request headers. I'm guessing you have a local firewall, or the webserver isn't configured to allow the connection. – TessellatingHeckler Mar 29 '21 at 17:12
  • [this](https://stackoverflow.com/a/46367395/1705829) helped, maybe the `ie` was not introduced, seems a firewall issue. Btw do you have `ncat` for powershell? I cannot find it. Question is 3 years old, time flys – Timo Mar 29 '21 at 17:50
  • 1
    @Timo oh, good find! I do not have an ncat specifically for PowerShell, it's just the standard Windows downlad of nmap. You can open a socket and listen in PowerShell/.Net [but it's not trivial to type at a command line](https://riptutorial.com/powershell/example/18117/tcp-listener) – TessellatingHeckler Apr 05 '21 at 00:26
  • `-UseBasicParsing` solves an alarming number of problems with Invoke-WebRequest. Poor design IMO? – Jeremy Morren Jan 11 '22 at 15:19
  • @JeremyMorren the PowerShell team made the cmdlet more useful and convenient by leaning on Windows' built-in browser engine. Then Microsoft abandoned IE and left it to rot for years while the web moved on. I like the "batteries included" approach more than the "install a module from the gallery for everything" approach. Having to find, install, learn and use Selenium just so you can `.Document.Links` is a real shame when Windows has IE, Edge/Edgium, often Outlook and more HTML parsers inside it somewhere. – TessellatingHeckler Jan 12 '22 at 19:24
0

In our case, it turned out there was a proxy setting in internet explorer (which Powershell uses by default), but we couldn't clear it because it was a company laptop and so we had to first disable the group policy and then clear it in Internet Explorer. Open gpedit.msc and then go here Computer Configuration -> Administrative Template -> Windows Components -> Internet Explorer -> Prevent Changing proxy settings and then disable it.

enter image description here

Varun Sharma
  • 2,591
  • 8
  • 45
  • 63