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

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:

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

	# Disable the DiagTrack service
	Get-Service DiagTrack |
	Stop-Service -Verbose -PassThru |
	Set-Service -StartupType Disabled -Verbose
	# Disable compattelrunner.exe launched by scheduled tasks
	'Microsoft Compatibility Appraiser',
	'ProgramDataUpdater' | ForEach-Object {
	Get-ScheduledTask -TaskName $_ -TaskPath '\Microsoft\Windows\Application Experience\' |
	Disable-ScheduledTask
	}
	# Stop and remove Diagtrack ETL trace session under
	# C:\ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger\
	Get-EtwTraceSession |
	Where Name -match '(AutoLogger-)?Diagtrack-Listener'|
	Remove-EtwTraceSession
	del C:\ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger\AutoLogger-Diagtrack-Listener.etl -ErrorAction SilentlyContinue
	# Disable the Autologger session at the next computer restart
	Set-AutologgerConfig -Name 'AutoLogger-Diagtrack-Listener' -Start 0
	# Other idea: block the diagtrack service at firewall level
	New-NetFirewallRule -Name "Block DiagTrack" -Profile Any -Direction Outbound -Action Block -Service DiagTrack -DisplayName "Block DiagTrack"

view raw Stop-WxTelemetry.ps1 hosted with ❤ by GitHub

At the end in the Perfmon snap-in you shouldn’t have any active event trace sessions (right-click refresh if necessary)

and the the Autologger session should be set to Disabled so that it doesn’t start at the next computer restart

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

	@echo off
	:: W7 version
	REM stop the current trace used by the diagtrack service
	logman.exe stop "Diagtrack-Listener" -ets
	REM stop and disable the diagtrack service
	net.exe stop diagtrack && sc.exe config diagtrack start= disabled
	REM Stop the Autologger trace session
	logman.exe stop "AutoLogger-Diagtrack-Listener" -ets
	REM Disable the Autologger session at the next computer restart
	reg.exe add "HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\AutoLogger-Diagtrack-Listener" /v Start /t REG_DWORD /d 0x0 /f
	REM Delete the etl file
	del /F/Q "C:\ProgramData\Microsoft\Diagnosis\ETLLogs\AutoLogger\AutoLogger-Diagtrack-Listener.etl"
	REM Other idea: block the diagtrack service at firewall level
	netsh.exe advfirewall firewall add rule name="Block DiagTrack" dir=out action=block service=diagtrack profile=any

view raw Stop-W7Telemetry.bat hosted with ❤ by GitHub

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.

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