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.

Advertisements

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