Powershell invoke-webrequest not working

13,023

[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.

Share:
13,023
Admin
Author by

Admin

Updated on June 15, 2022

Comments

  • Admin
    Admin almost 2 years

    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.

  • PNS
    PNS almost 4 years
    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)
  • Timo
    Timo about 3 years
    still fails, I get Invoke-WebRequest : Die Verbindung mit dem Remoteserver kann nicht hergestellt werden
  • Timo
    Timo about 3 years
    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.
  • TessellatingHeckler
    TessellatingHeckler about 3 years
    @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.
  • Timo
    Timo about 3 years
    this 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
  • TessellatingHeckler
    TessellatingHeckler about 3 years
    @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
  • Jeremy Morren
    Jeremy Morren over 2 years
    -UseBasicParsing solves an alarming number of problems with Invoke-WebRequest. Poor design IMO?
  • TessellatingHeckler
    TessellatingHeckler over 2 years
    @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.