Solving UseBasicParsing Errors in PowerShell

-

 

Solving UseBasicParsing Errors in PowerShell

April 4, 2020

Today I was trying to write some PowerShell scripts against the Okta PowerShell Module and ran into an error that it doesn't look like I was the only one with. The error, abbreviated, was:

C:\> oktaGetUserByID -userName jesper -Verbose

...

[Microsoft.PowerShell.Commands.HttpResponseException].WARNING: Encountered error, returning limited or empty set

VERBOSE: This Page returned: 0, we've seen: 0 results so far VERBOSE: 0 results returned, i predict an empty page coming up, lets skip it 

VERBOSE: We see no or an invalid next link of: FalsePS 

Getting some more details:

C:\> $Error[0..($Error.count)]

Unable to find type [Microsoft.PowerShell.Commands.HttpResponseException]. At C:\<path>1:491 char:38+ ... .WebException], [Microsoft.PowerShell.Commands.HttpResponseException]+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    + CategoryInfo          : InvalidOperation: (Microsoft.Power...sponseException:TypeName) [], RuntimeEx    ception    + FullyQualifiedErrorId : TypeNotFound 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. At C:\<path> 1:473 char:29+ ... $request2 = Invoke-WebRequest -Uri $uri -Method $method -UserAgent $u ...+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    + CategoryInfo          : NotImplemented: (:) [Invoke-WebRequest], NotSupportedException    + FullyQualifiedErrorId : WebCmdletIEDomNotSupportedException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

What's going on here is interesting. The Invoke-WebRequest function requires you to have launched Internet Explorer and proceeded past the Internet Explorer first launch experience, because it apparently uses some Internet Explorer component for parsing. To avoid this, the error says that you can include the UseBasicParsing parameter. However, that parameter has been deprecated and no longer works. Furthermore, I'm running Windows 10, and there is no Internet Explorer to launch, so what I do? 


It turns out that you need to tell the OS not to bother with the Internet Explorer first launch experience. Save this to a .reg file and run it, or make this change directly in the registry:


[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Internet Explorer\Main]

"DisableFirstRunCustomize"=dword:00000001


Once you do that, IE, or whatever is left of it in Windows 10, knows that you don't want to go through the first launch experience, and now your PowerShell command will work.  


It took me some searching to figure this out so I thought if I post it here in context, with more complete error messages, maybe it will help someone else. 

Comments

Post a Comment

Popular posts from this blog

U2F, FIDO2, and Hardware Security Keys

-
  In our journey through possession proofs we have encountered hardware factors of various kinds. HOTP and TOTP is often implemented as hardware devices, and of course, so are Smart Cards. In this post we will look at authenticators that implement the FIDO standards -  U2F, WebAuthn, and CTAP2. WebAuthn and CTAP2 are collectively part of the FIDO Alliance ’s FIDO2 protocol suite. U2F and UAF are older FIDO protocols that are supported under FIDO2. They can all be thought of as being part of the FIDO2 suite of protocols.  To understand these protocols, and their advantages and disadvantages, we need to be familiar with the three fundamental actors: Relying party (RP) - Also known as the server. This is the service that a user wishes to log into. Client - This is the application that brokers the authentication from the relying party to the authenticator and eventually the user. Much of the time, this is a web browser, but it could be any application. Authenticator - This ...
Read more

Single Sign-On

-
There are two kinds of organizations. Those that manage their single sign-on (SSO) system, and those that let their users manage their SSO. The other day I was in a discussion with a number of security leaders about how important identity management is to your security strategy. Obviously, everyone agreed that identity is very important. After all, if you don’t have a strong identity strategy pretty much no other component of your strategy will be strong. There is a reason that the first function of the NIST CSF is Identity.  However, the discussion then turned to SSO and whether it didn’t constitute putting all your eggs in one basket, and whether doing so is a good idea. Yes. SSO does constitute putting all your eggs in one basket. But, that is a good  thing. Why? Because you, as a security leader control  that basket. You know where it is. You know how it is configured. You have already required strong multi-factor authentication (MFA) on it. (You have right? If not, s...
Read more

Warning: Regulations May Harm Your Security

-
Like many of you, I have spent decades trying to devise security controls that comply with various regulatory requirements. In some cases, they are actual regulations, like FINRA 17a-4, GDPR, HIPAA, NYDFS Part 500, and PCI DSS. In other cases, the regulation is an industry standard to demonstrate adequate controls to business partners and customers, such as NIST CSF and SOC 2 Type II; or a requirement for some customers, such as FedRAMP. While every one of these is well intended and they all have some requirements that are sensible, they also have the potential to cause harm, primarily in one of two ways.  Regulatory Compliant Does Not Mean Secure Regulatory compliance is often presented as a voucher or certification. Management often celebrates that we “passed our certification”. First, most of the regulations are not actually certifications. For instance, as a merchant, you are not “certified” under the Payment Card Industry (PCI) Data Security Standard (DSS). You are assessed,...
Read more