Author Posts

July 7, 2015 at 3:07 am

Searching for better HotFix description i failed to retrieve the Title (or Description) for these Microsoft websites, using this PowerShell(v4) code:
$hotfixID="KB2899189"
$myHotfix=Get-HotFix|Where-Object -Property HotFixID -like "${hotfixID}*"
$hotFixUrl=$myHotfix.Caption
$hotFixHtml=(Invoke-WebRequest -uri $hotFixUrl).ParsedHTML
$hotfixHtml.title

When inspecting te HTML elements Chrome shows the contents but IE does not. Probably these values are dynamically fetched by the Browser Engines.

Is there any solution other than to retrieve the info using WSU or RSS, like in:
http://www.pythian.com/blog/a-big-trick-listing-windows-updates-using-powershell/

Thanks for any help,
Frits

July 7, 2015 at 5:12 am

Web browsers may indeed be using Javascript or something else to dynamically fetch values; there's no way to make PowerShell do that.

That URL you posted seems to have a working solution – is that not what you're after?

I don't personally know of any RSS feeds that can be used to query information about a single hotfix. If you know of such a feed, then yes, PowerShell could read it and parse it. It's just XML.

July 7, 2015 at 5:20 am

well this is annoying. a few months ago I had to look up descriptions for a bunch of kb id's and did it with powershell.

today I'm just getting 'This type of document does not have a security certificate'

July 7, 2015 at 5:32 am

Without knowing the exact URL you're using, it's possible that the server is now insisting on an HTTPS connection, and attempting to redirect from an HTTP URL, or that your local Internet security settings are jacked up a bit high. Keep in mind that the underlying .NET code behaves a little like IE in that it uses the Control Panel's security settings for Internet access.

July 7, 2015 at 5:41 am

This works.

$hotFixHtml=(Invoke-WebRequest -uri 'https://www.google.com/').ParsedHTML
$hotfixhtml.title

This works.

$hotFixHtml=(Invoke-WebRequest -uri 'https://www.microsoft.com/en-us/').ParsedHTML
$hotfixhtml.title

This does not.

$hotFixHtml=(Invoke-WebRequest -uri 'https://support.microsoft.com/en-us/kb/2520155').ParsedHTML
$hotfixhtml.title

July 7, 2015 at 6:19 am

Don,
Thank you for clearing this up.
The RSS method will do but being a beginner i though i might have missed the obvious.

Frits

September 29, 2015 at 8:38 am

I too am vexed by this. I administer an Exchange 2010 environment in an organization that siloes responsibilities, and patching is handled by a different group. To adhere to best practice I need all of my production machines to be patched identically. In the past, I have found discrepancies between what is reported as being installed with our patch management software, and what is actually installed on the machines. Therefore, quarterly, I perform a self-audit of the patches that are installed on the nodes under my visage in order to reconcile my results against the report generated by the patch management team. I spent significant time writing PowerShell scripts that automate this process, consolidate the results, and generate a macro-enabled pivot table detailing which patches are installed on each of my machines. Of the solution I authored, my favorite feature is the ability to simply scroll over the patch in the spreadsheet, which generates a call-out displaying the title of the patch without having to click anywhere. This greatly improves the speed with which I can perform the audit, as I can quickly determine a patches purpose. For instance I can determine that a cluster related patch is correclty installed on all of my clustered nodes, but not on my unified messaging hosts.

A screenshot of a report that I generated last quarter illustrating successful output can be seen by following the link below:

http://screencast.com/t/Fz7wtU1RGlmH

My frustration is with not with powershell per-se, rather with the webteam that decided to alter the method that they use. Now, they dynamically inject the title of the kb article's page via the browser using jquery which means that I can no longer scrape the title via the following method:

 $site = Invoke-WebRequest -uri $IRL;$Site.ParsedHtml.nameProp 

I suppose that now I shall have to re-write my scripts to load the interop for the browser, fully render the page, parse the html using a regex and blah, blah, blah... What? re-write my code again next quarter again whey they decide to change the way they deliver the content?

September 30, 2015 at 10:54 am

I figured out a convoluted, alternate way to get the title for the KB articles. Instead of using Invoke-Web request, it uses the InternetExplorer.Application object model, but it is slow & you will need to run your PowerShell session as Administrator...
Here is the function

Function Get-Title($Web)
    {
        if ($Web -ne "https://go.microsoft.com/fwlink/?LinkId=133041")
            {
				$ie = new-object -com internetexplorer.application
				$ie.navigate($Web)
				while ($ie.busy -eq $true) { Start-Sleep -Milliseconds 600 }
				$BaseResponse = $ie.LocationURL
		
				if ($BaseResponse -ne $Web) { $Title = "Site may no longer be available. Site redirection occurred - new target $BaseResponse." }
				else
				{
					while (($ie.LocationName -eq "Microsoft Support") -or ($ie.LocationName -eq $Web)) 
                        { 
                            $ie.refresh();
                            while ($ie.busy -eq $true) { Start-Sleep -Milliseconds 600 }
                        }
					$Title = $ie.LocationName.tostring()
                    $ie.Quit()					
				}
			}
	Else
	{
		$Title = "Invalid URL - Original KB was for IE 9.0..."
	}
	start-sleep -Seconds 1
        return $Title.ToString()
    }#end function Get-Title

$IRL = "https://support.microsoft.com/en-us/kb/2488113"
Get-Title $IRL