Sometime back while I was creating a bunch of Azure Automation PowerShell Runbooks for certain Azure Operations automation work, I started getting a strange error from a couple of Runbooks regarding Invoke-WebRequest cmdlet. On further investigation, I found out the cause and remedy of the same. Let me explain to you in detail about the problem and the solution.
If you try to execute any Azure Automation Powershell Runbook, which contains a PowerShell Invoke-WebRequest cmdlet like below:
$WebResponse = Invoke-WebRequest -Uri $url -TimeoutSec 1000 –ErrorAction Stop –Method Post -Headers $headers
Invoke-WebRequest: The response content cannot be parsed because the Internet Explorer engine is not available, or Internet Explorer’s first-launch configuration is not complete. Specify the UseBasicParsing parameter and try again
However, the underlying host on which the Azure Automation Runbook Jobs are executed in the background, do not have IE configured for use by default through the Windows Identity being utilized to execute the Runbooks. We cannot do anything about it since Microsoft does not give end-users any access to the underlying hosts used for executing Azure Automation Jobs.
You may have seen similar behavior when you spawn a new VM/Machine (with a fresh Windows Server or Client OS Install), and try to run Internet Explorer for the first time. You get a first-launch configuration dialog before you can use Internet Explorer as shown below. Unless you make a choice in this dialog to either select the appropriate option or defer it for later, Internet explorer assemblies are not loaded. This is exactly what also prevents Invoke-WebRequest cmdlet from using those Internet explorer assemblies.
The right way to make a call to the Invoke-WebRequest cmdlet from within an Azure Automation Runbook would be with the –UseBasicParsing switch as follows:
Hope you found this blog post useful. If you have any queries/feedback, please feel free to mention it in the comments section below.
