Powershell Invoke-WebRequest to https://docs.microsoft.com

Question

Hi guys,
we tried to invoke a webrequest with powershell to https://learn.microsoft.com (https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date) to get the versionnumber table for exchange via ps1 script. It worked fine since today.
Now all invoke-webrequest to learn.microsoft.com without basic parsing seems to be blocked with powershell running into an endless loop without error. Anyone else got problems like this?
Thanks!

Answer 1

Hi @Fischer, Matthias ,

here i tried the Invoke-WebRequest and got a response:

Invoke-WebRequest -URI https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date  

----------

(If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)

Regards
Andreas Baumgarten

Answer 2

I get the same result . . . it just hangs. Doesn't respond to Ctrl+C or any other attempt to kill it.

Adding "-Verbose" to the cmdlet showed this:

PS C:\Users\richm> Invoke-WebRequest -URI https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date -verbose
VERBOSE: GET https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date with 0-byte payload
VERBOSE: received -1-byte response of content type text/html

Answer 3

Interesting. Assigning the result of that Invoke-WebRequest to a variable works. You can access the RawContent, RawContentLength , Content, Headers, etc. However, the parsing of the data fails by entering a loop. E.g., $x.Links or $x.ParsedHTML never complete.

The BaseResponse property is this -- note the ContentLength value!

IsMutuallyAuthenticated : False  
Cookies                 : {}  
Headers                 : {Request-Context, X-Datacenter, X-Frame-Options, x-content-type-options...}  
SupportsHeaders         : True  
ContentLength           : -1  
ContentEncoding         :  
ContentType             : text/html  
CharacterSet            : ISO-8859-1  
Server                  :  
LastModified            : 3/24/2021 10:52:46 AM  
StatusCode              : OK  
StatusDescription       : OK  
ProtocolVersion         : 1.1  
ResponseUri             : https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date  
Method                  : GET  
IsFromCache             : False  

Answer 4

I am glad we're not alone in seeing this behavior. I will monitor and update this if I hear anything.

Answer 5

Guys, I can't take the credit (although we did punt it to MS as a question if you want to give me kudos!) but it appears that MS have fixed this issue.

Good news indeed.