WSUS synchronization report

The other day I wondered how to get the equivalent of this WSUS synchronization summary and its details.
More precisely I wanted to get the summary of what you see in the mmc snap-in under the synchronizations node:
wsus-sync-01
and the details that you get when you right-click a synchronization and hit ‘Synchronization report’ but I got instead the following message telling me that the report viewer wasn’t installed
wsus-sync-02

After a few minutes, I found the following MSDN page about Reporting Newly Synchronized Updates
I first looked at the GetUpdates method that has many ways to call it.
wsus-sync-03
The msdn article proposes to use the 2nd one where you specify all the 5 arguments:

  • Microsoft.UpdateServices.Administration.ApprovedStates approvedStates,
  • datetime fromArrivalDate,
  • datetime toArrivalDate,
  • Microsoft.UpdateServices.Administration.UpdateCategoryCollection updateCategories,
  • Microsoft.UpdateServices.Administration.UpdateClassificationCollection updateClassifications

where both the updatecategories and updateclassifications are set to $null
I gave it a try but I couldn’t get reliable results 😦 even when the two collections (UpdateCategoryCollection and UpdateClassificationCollection) were properly defined and not set to null.
Forget that method, it’s too unpredictable.

I switched to the 3rd method where you just use a single updateScope object as argument instead of the above 5 arguments and finally got the expected reliability πŸ˜€

# Get the last sync info (start and end times)
$lastSync = (Get-WsusServer).GetSubscription().GetLastSynchronizationInfo()

# Create an updatescope object
$UpdateScope = New-Object -TypeName Microsoft.UpdateServices.Administration.UpdateScope

# Set the start time
$UpdateScope.FromArrivalDate = $lastSync.StartTime
# Set the end time
$UpdateScope.ToArrivalDate = $lastSync.EndTime

# Invoke the getupdates method using the update scope object
$SyncUpdates = (Get-WsusServer).GetUpdates($UpdateScope)

Now to get the summary, I just do

$SyncUpdates | 
Group-Object -Property publicationstate -NoElement

wsus-sync-04
To view the details of what was synchronized I do:

$SyncUpdates | Out-GridView
# or 
$SyncUpdates | 
Select Title,SecurityBulletins,UpdateClassificationTitle,PublicationState | 
Sort PublicationState | 
Format-Table -AutoSize

wsus-sync-05

Easy-peasy and as always PowerShell rocks 😎

Get-GPPrefRegistryValue or Get-GPRegistryValue

Someone at work recently asked me to provide the list of (web) sites assigned to an IE zone, so that he could tell me what sites are obsolete and can be removed. Yeah, we need that because IE11 intranet automatic detection mechanism doesn’t work with an httpstunnel interface and an NRPT table for those who are familiar with Direct Access scenario.

I jumped on a PowerShell console and couldn’t immediately get the answer because I got confused by the Get-GPPrefRegistryValue cmdlet. I couldn’t easily get the answer because I actually used the wrong cmdlet (my bad) 😦
I should have used the Get-GPRegistryValue cmdlet instead πŸ™‚ . Do you see the difference between the two cmdlets?

I could actually have had my answer in less than 2 seconds by doing:

Get-GPO -Name "myGPOName" | 
Get-GPRegistryValue -Key 'HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey' |
Select ValueName,Value

Instead, I went the hard way and did the following:

# 1. Export the GPO to an XML file
Get-GPO -Name "myGPOName" | 
Get-GPOReport -ReportType Xml -Path "C:\myGPOName.xml"

# 2. Read the XML file
(
 ([xml](Get-Content "C:\myGPOName.xml")).GPO.User.ExtensionData.Extension.Policy | 
 Where Name -eq 'Site to Zone Assignment List'
).ListBox.Value.Element

Even if you’re confused, PowerShell always provides many ways to skin the cat πŸ˜€

Add missing WinRMRemoteWMIUsers__ group in Active Directory

I’ve seen this morning a post in French about the WinRMRemoteWMIUsers__ group missing from Active Directory Domain Services. The post references the following kb3118385 page about Svchost.exe uses excessive CPU resources on a single-core Windows Server 2012 domain controller

The only missing part in the blog post is the properties of this group that I actually found on this technet page winrmremotewmiusers__

Of course, you can add the missing group like this

if (-not(Get-ADGroup -Filter { Name -eq 'WinRMRemoteWMIUsers__' })) {
 New-ADGroup -GroupScope DomainLocal -GroupCategory Security -Name 'WinRMRemoteWMIUsers__'
}

…but, it won’t have the well-known SID documented above.

And its Description is:

Members of this group can access WMI resources over management protocols (such as WS-Management via the Windows Remote Management service). This applies only to WMI namespaces that grant access to the user.

Stop telemetry

Some people noticed Windows 7 computers talking to some IP addresses on port TCP:80 since the November Quality Rollup while Woody Leonhard warned mid-October that there’ll be a new telemetry being pushed to downlevel OS like Windows 7 and 8.1 .

A few days before Christmas, abbodi86 provided a less aggressive way of stopping telemetry on a computer on the PM.org mailing list:
abbodii-telemetry-v2

Here’s how to do this on Windows 10 using PowerShell

At the end in the Perfmon snap-in you shouldn’t have any active event trace sessions (right-click refresh if necessary)
autologger-diagtrack-listener-tracesession
and the the Autologger session should be set to Disabled so that it doesn’t start at the next computer restart
autologger-diagtrack-listener-provider

On Windows 7, you cannot use PowerShell and here is the “legacy” way to achieve the same thing:

Fix DFSR 4012 event and MaxOfflineTimeInDays

What a nice way to start 2017, I’ve got group policies not applying to computers because the DFS replication of the Sysvol is stopped and the delay of 60 days to resume the replication is over.

sysvol-dfsr-4012

Happy new year πŸ™‚

NB1: don’t do what is recommended in the above message and when it says “To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group.”.
This does not apply to a SYSVOL share on a domain controller, right?

NB2: If you wait for error 4012 and ignore warnings, it’s too late. Why did the domain admin wait for more than 60 days to resume replication? Nobody is reading the alerts and saw the warnings (events Id 2213) and/or worse the remediation script is also broken and there isn’t an alert for that 😦

NB3: notice that the above message tells me how long it is disconneted.
This server has been disconnected from other partners for ? days: 71 in my case.

I did the following to get back the replication of the SYSVOL working:

$i = gwmi -namespace root\microsoftdfs -query 'Select * FROM DfsrMachineConfig'
# increase the MaxOfflineTimeInDays to more than just a day
# 71+4=75
$i.MaxOfflineTimeInDays =[uint32]75
$i.Put()
Restart-Service -Name DFSR -Verbose

How to export all URLs of Firefox tabs at once

I’ve seen the following script proposed on the technet script gallery that should show me “How to export all URLs of Firefox tabs at once”.

I said “should” because it actually doesn’t always work on my computer and there’s no error handling in any way in the proposed code 😦
firefox-tabs-01

First, to save you the hassle of trying that script, you can just open Tools/Options in Firefox and set the following. Even if you’ve 1000 tabs, the browser will open in a few minutes and restore the gazillion tabs without you to have to temporarily record the URL of each Firefox tabs that you want to open in the next session:firefox-tabs-02

Back to the proposed script. It actually threw the following error:
Error during serialization or deserialization using the JSON JavaScriptSerializer. The length of the string exceeds the value set on the maxJsonLength property.
Why? Because when you have a gazillion of tabs (whatever that means), your Mozilla .js file that stores the JSON data about your tabs can be quite big.
I found the following post in the Windows PowerShell forum that made me go this way:

Quick tip: change ConfigMgr updates maximum run time

With the new servicing model being applied to pre-Windows 10 operating systems, it’s a good idea to change the default “maximum run time” of the monthly cumulative updates.
For example, I’ve:
configmgr-max-run-time

Here’s a way to achieve this easily with PowerShell.
The -Name parameter of the Get-CMSoftwareUpdate accepts wildcards although its documentation says the opposite.
The -Fast is explained in the following warning message:

WARNING: ‘Get-CMSoftwareUpdate’ supports -Fast for retrieving objects without loading lazy properties. Loading lazy properties can cause significant performance penalties. If it is not necessary to utilize the lazy properties in the returned object(s), -Fast should be used. This warning can be disabled by setting $CMPSSuppressFastNotUsedCheck = $true.

# 1. View what updates will be targeted:
Get-CMSoftwareUpdate -Fast -Name "*Security Monthly Quality Rollup for Windows*" |
Select Max*,*DisplayName
#NB: MaxExecutionTime is in seconds in this case

# 2. Set the maximum run time to 120 minutes
Get-CMSoftwareUpdate -Fast -Name "*Security Monthly Quality Rollup for Windows*"  | 
Set-CMSoftwareUpdate -MaximumExecutionMins 120 -Verbose