Replacement for Invoke-WebRequest before IE retirement in June 2022? - powershell

I've inherited a lot of scripts that rely on Invoke-WebRequest and am aware that this commandlet requires IE to run.
Is there a way to configure Invoke-WebRequest so that it uses Edge instead?
Considering that Internet Explorer 11 desktop application will be retired and go out of support on June 15, 2022; I'd imagine that MS would have some drop-in replacement for the Invoke-WebRequest command that would allow PowerShell scripts using it to continue to function after IE11's retirement.

PowerShell 5.1 -UseBasicParsing
Indicates that the cmdlet uses the response object for HTML content without Document Object Model (DOM) parsing. This parameter is required when Internet Explorer is not installed on the computers, such as on a Server Core installation of a Windows Server operating system.
PowerShell 7.2 -UseBasicParsing
This parameter has been deprecated. Beginning with PowerShell 6.0.0, all Web requests use basic parsing only. This parameter is included for backwards compatibility only and any use of it has no effect on the operation of the cmdlet.

Related

Invoke-webrequest -get request through a custom Chrome profile

I've been looking to ways to read HTML on a opened custom chrome profile, but with no luck.
& "C:\Program Files\Google\Chrome\Application\chrome.exe" --profile-directory="Profile 1" $url;
I tried using invoke-webrequest but couldn't figure out how to get it to work through a custom profile.
The point is to read if an item was bought on $url, where "Profile 1" is logged into.
Alternatively I thought about logging into $url with POST method and then returning the HTML as a variable, but I couldn't figure out a way to do that either.
This won't work. This can't work.
You can :
Launch Chrome on a specific profile
Use Invoke-RestMethod and / or Invoke-WebRequest
The two are not correlated though.
The Powershell cmdlets do not depend on Chrome for their operations.
If you want to do stuff through Chrome, you need to do browser automation.
That's a different thing that require specialized tools, such as Selenium.
You can use the .Net interface of selenium directly or use the Selenium powershell module that will help you interface with selenium (and your browser of choice / browser profile) more easily.
To install :
Install-Module -Name Selenium -AllowPrerelease
Note that this tool is a lot more complex to learn and use than just Invoke-WebRequest
References
Github - Selenium-Powershell
Powershell Gallery - Selenium

Is there any New-WebServiceProxy alternative?

I'm trying to consume a SOAP web service at PowerShell 6. I used to do this task with the New-WebServiceProxy command on early versions but no longer exists on PowerShell 6. Is there any similar command?
I'm using currently PowerShell 7 and the lack of New-WebServiceProxy affect me in several Scripts that was running with this CmdLet as expected in PS 5.1.
As 'danno' answered before, Invoke-WebRequest is the natural option in Core editions.
Googling I found two sites with examples to implement a workaround for SOAP Web Services:
https://www.itprotoday.com/powershell/getting-started-soap-based-web-services-and-powershell
... and ...
https://www.powershellbros.com/send-soap-message-powershell/
Maybe someone says it that this is go back, but really works!
A combination of ConvertTo-XML with Invoke-WebRequest should be able to get you where you need to be, both of which are supported in PowerShell 6.

Powershell Handling cookie popup without using invoke-webrequest

I am attempting to get a script working that does not use invoke-webrequest. The problem I am having is that when I run the script a popup prompt occurs, the popup consists of the following message;
"Windows Security Warning
To allow this website to provide information personalized for you, will you allow it to put a small file (called a cookie) on your computer?"
with yes no response from user
The code I am executing is the following:
$ParsedHTML = New-Object -com "HTMLFILE"
$webresponse = New-Object System.Net.WebClient
$webresponse.Headers.Add("Cookie", $CookieContainer.GetCookieHeader($url))
$result = $webresponse.DownloadString($url)
$ParsedHTML.IHTMLDocument2_write($webresponse)
$ParsedHTML.body.innerText
The main problem with this code is that the $url I am using part of the weblink checks to see if cookies are enabled and this code causes a returned value of disabled.
My question, is there a way to handle the cookie request without changing the output response from the test url site.
Note: This script will be automating a process over hundreds of remote computers and thus having an unhandled popup will just prevent the script from running.
I found the answer in another SO question Using Invoke-Webrequest in PowerShell 3.0 spawns a Windows Security Warning
add the parameter -UseBasicParsing
Technet https://technet.microsoft.com/en-us/library/hh849901.aspx notes that the parameter stops the DOM processing. and has the caveat "This parameter is required when Internet Explorer is not installed on the computers, such as on a Server Core installation of a Windows Server operating system."
So, you mileage may vary.

The term 'Invoke-WebRequest' is not recognized as the name of a cmdlet

I've got problem with executing Invoke-WebRequest cmdlet. I read that ~100% case of that scenario is PS version lower than 3, but it's not my case:
Name Value
---- -----
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
CLRVersion 4.0.30319.34011
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.10208.0
PSVersion 5.0.10208.0
SerializationVersion 1.1.0.1
I can add that I'm using Windows 10 IoT Core version of OS. In fact my main purpose is execution of simple web request, but I am interested why this cmdlet is not working, especially if more of them won't be ;/ I suppose it can be some windows feature like switch to turn on, but its just my guess.
Update
As far as I compared available cmdlets for certain modules, and preloaded assemblies between my regular system and an IoT version, it looks like the latter version is cut somehow, but I still didn't see any docs for that.
I had this issue on a Windows Server 2008 R2 server, because it was running PowerShell v2. Upgrading to v4 fixed the issue.
Windows Management Framework 4.0 (includes PowerShell 4.0)
As of v5, Invoke-WebRequest is still documented.
Check your version with:
$PSVersionTable.PSVersion
Trying to create the request in the same way I would do it for PS version 2 (using .net library instead of cmdlet) doesn't work either...
$request = [System.Net.WebRequest]::Create("https://google.com")
$request.Method = "GET"
[System.Net.WebResponse]$response = $request.GetResponse()
This appears to be removed in PowerShell Core.
I am searching for why this doesn't work on Docker for Windows running on Nano Server for Windows 2016 and your findings match mine.
Though the PowerShell version and everything else was good at my end, I was unable to download the code from the desired repo. So, I've executed the following command first to satisfy the TLS version, and then I have executed my desired command to download the latest version of the githubActions runner.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -Uri
https://github.com/actions/runner/releases/download/v2.165.2/actions-runner
-win-x64-2.165.2.zip -OutFile actions-runner-win-x64-2.165.2.zip
Invoke-WebRequest has been stripped from PowerShell 5.
Here's an implementation of a function called Invoke-FastWebRequest that works just like the old Invoke-WebRequest in PowerShell 5: https://github.com/cloudbase/unattended-setup-scripts/blob/master/FastWebRequest.psm1
Using -UseBasicParsing option in the command works. The following is part of the command's documentation
-UseBasicParsing
Indicates that the cmdlet uses the response object for HTML content without Document Object Model (DOM) parsing.
This parameter is required when Internet Explorer is not installed on the computers, such as on a Server Core installation of a Windows Server operating system.

Deploying WSP remotely from PowerShell 3.0

I have this large application that I am using Windows RM 3.0 to deploy Databases, SSIS packages, and other things to multiple different servers and it is working just fine. It was requested that branding changes to a Business Intelligence SharePoint site be added to this process as well. So I create a custom build script to do so, and set Win RM to run this command from PowerShell on Sharepoint server
Install-SPSolution –Identity Payload\SharepointDeploy.wsp –WebApplication http://localhost/ -GACDeployment
when I run that, I get the following error
Install-SPSolution : Microsoft SharePoint is not supported with version 4.0.30319.18444 of the Microsoft .Net Runtime.
Reading around, it seems its a PowerShell 3.0 issue and when running in 2.0 it works fine. However, my existing process requires PowerShell 3.0 to work properly. Is there anyway to get this working with 3.0? Or can I spin up a 2.0 instance using an Invoke-Command or something? I can provide more details if needed.
You can build a custom endpoint which will run the required version of PowerShell. That way you won't have to mess with the default endpoint which you probably want to keep with its defaults
This would require you to connect to the new endpoint with something like
new-pssession -computername "SharePoint01" -configurationName "psv2".
You build and endpoint with the following cmdlet:
New-PSSessionConfigurationFile -Path "psv2session.pssc"
And then register an endpoint using that config with this cmdlet:
Register-PSSessionConfiguration -Name psv2 -Path psv2session.pssc –ShowSecurityDescriptorUI
It's fairly easy to do, and this link provides a good introduction to the setup:
http://blogs.technet.com/b/heyscriptingguy/archive/2014/04/02/build-constrained-powershell-endpoint-using-configuration-file.aspx (although the blog deals with constrained endpoints, the teqnique is essentially the same for what you need to do)
I was facing the same issue with console application, I decreased the framework version from 4.5 to 3.5 from the project properties page and I works perfect!