When does computer group change take effect?

As it turn out, if you never reboot the computer then it never will. That is uberLame.
This is a little tidbit that a TON of group policy documentation needs to spell out. Or at least link to a good document. If you filter machine policies by group membership then you really have to reboot all the time in order to make it work. That's fine for desktop computers, but it's not what we want for servers. There is a lot of wasted internet out there where various clueless people are trying to figure this out. Microsoft should just come out and say it and then link that document to every document they have about things that use group memberships.
Here is a not-so-elegant workaround.

Powershell: WSUS

I suppose you might just say "DUH!" but I have to say again to myself if nobody else, PowerShell is very powerful and useful.
Here are some useful fragments I've got from a little tinkering with dates.
Again it's no surprise that TechNet was very useful. Especially this Powershell Tip about dates.

List the computers from WSUS and all info about them.

$WSUSserver="WSUS02"
$WSUSList="c:\export\WSUS\DATA\WSUSLIST.TXT"
New-Item $WSUSList -Type file -Force >$nul
#Get WSUS list
function Get-WSUSComputers()
{
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($WSUSserver,$false)
$wsus.GetComputerTargets()
}
Get-WSUSComputers | Sort LastReportedStatusTime |`
Select * | `
Out-File -FilePath $WSUSList -Force

And, how about a list of machines for which last reported status was over a week ago.

$WSUSserver="WSUS02"
$today = Get-Date
$today = $today.touniversaltime()
$datecheck = $today.adddays(-7)
$WSUSList="c:\audit\DATA\NOTREPORTING.TXT"
New-Item $WSUSList -Type file -Force >$nul
#Get WSUS list
function Get-WSUSComputers()
{
    [void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
    $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($WSUSserver,$false)
    $wsus.GetComputerTargets()
}
Get-WSUSComputers | Sort LastReportedStatusTime |`
Select FullDomainName, LastReportedStatusTime | where {$_.LastReportedStatusTime -le $datecheck} | `
ft -auto | `
Out-File -FilePath $WSUSList -Force

WSUS: Microsoft Windows Server Update Service

The MMC for WSUS leaves much to be desired for reporting. It'd be nice to be able to print or at least export the view that lists the clients and their status. So it can be used to figure out which clients are missing or what servers might be configured there still that no longer exist.
The script below will help. It generates a list of server machine accounts from AD and then exports the list from WSUS and then generates lists for review.

#LIST-AUDIT.PS1
#Export list of server accounts from AD, export WSUS clients, compare
#
#Define variables
$WSUSserver = 'PRIWSUS02'
$serverlist = 'c:\audit\data\servers.txt'
$WSUSList = 'c:\audit\data\WSUS.txt'
$InWSUS = 'c:\audit\data\OK-Servers-on-WSUS-list.txt'
$NotInWSUS = 'c:\audit\report\REVIEW-Servers-not-on-WSUS-list.txt'
$allservers = 'c:\audit\data\allservers.txt'
$WSUSorphans = 'c:\audit\report\REVIEW-WSUS-item-not-on-Servers-list.txt'
#Initialize files
New-Item $serverlist -Type file -Force >$nul
New-Item $WSUSList -Type file -Force >$nul
New-Item $InWSUS -Type file -Force >$nul
New-Item $NotInWSUS -Type file -Force >$nul
New-Item $allservers -Type file -Force >$nul
New-Item $WSUSorphans -Type file -Force >$nul
#Get list of servers from AD
$strCategory = "computer" 
$strOS = "Windows*Server*"
$objDomain = New-Object System.DirectoryServices.DirectoryEntry 
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher 
$objSearcher.SearchRoot = $objDomain
$objSearcher.Filter = ("OperatingSystem=$strOS")
$colProplist = "dnshostname"
foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)}
$colResults = $objSearcher.FindAll()
foreach ($objResult in $colResults) 
{$objComputer = $objResult.Properties;  
$objComputer.dnshostname >> $serverlist}
#Get WSUS list
function Get-WSUSComputers()
{
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($WSUSserver,$false)
$wsus.GetComputerTargets()
}
Get-WSUSComputers | Sort FullDomainName |`
Select FullDomainName | `
Out-File -FilePath $WSUSList -Force
$Servers = get-content $ServerList
$WSUS = get-content $WSUSList
#compare lists
Foreach ($Server in $Servers)
{$Server = $Server.tolower()
$Server = $Server + (" " * (79 - $Server.Length))
Add-content $allservers $Server
If ($WSUS -contains $Server)
{ Add-content $InWSUS $Server }
Else
{ Add-content $NotInWSUS $Server }
}
$ADList = get-content $allservers
Foreach ($Server in $WSUS)
{
If ($ADList -contains $Server)
{ write-host "ok" >$nul }
Else
{ Add-content $WSUSorphans $Server }
}

FUD for troubleshooting

I have witnessed many companies and politicians making very good use of "FUD" in public relations. (see FUD)
In my line of work I see a correlary in action far too often in the area of troublehooting or worse, in root cause investigation. Since I love a good TLA (three letter acronym) I will manufacture one to describe it. SIR = Superstition, Ignorance, and Rumor.

SUPERSTITION

This problem is vaguely familiar (I can't be sure because I never put that much thought into problem definition. So, really, almost all of them are vaguely familiar.) So, I should immediately launch into "what fixed it last time."

Although I make enthusiastic use my good fortune on days when my superhero underpants are working in my favor, I can't really respect this as the basis of troubleshooting. When your job is to be the final point of escalation for major enterprise issues in an organization you really need to THINK BEFORE YOU ACT. Even greater a pox upon you if you are a support engineer for a worldwide company to whom enterprise customers pay $100K per year for support. In this case you must obey me when I tell you to ESCALATE ME NOW. (Or I will be forced to declare my help call a critical incident and waste everybody's resources because you are stupid.)

IGNORANCE

I am the subject matter expert and this is my answer. By definition I am right.

There is no shame in not knowing something. Indeed we all must accept that no single person can ever know everything that might be relevant to figuring out my problems and so I expect ignorance. However, I cannot abide someone without the common sense and humilty to admit that they are not the all-knowing god of [insert product/technology here.] When a solution is presented based on a 20-something's omniscience and I don't think it will help I will often ask questions which get a patronizing answer. When I get tired of being called "dude" and tell him to ESCALATE ME NOW. It never works. I have to call his boss. I am embarrassed for these people when even though the investigation goes another direction and it's pretty obvious they were on the wrong track, they will continue to interject excuses or reasoning why they thought the way they did long after it is relevant.
Even when it's not taken that far, IGNORANCE--leading to a lack of motivation to GATHER ALL THE FACTS--feeds a frenzy of SUPERSTITION and RUMOR in a dysfunctional troubleshooting environment.

RUMOR

They are having a network problem.

Lack of problem definition and detailed investigation will often lead IT Management (and, ugh, even sometimes USER Management) to pigeon hole problems/systems/people on a snap judgement of the cause of a problem based faulty or lack of investigation to define problems. This failure is manifested in management decisions for project direction, purchasing, and professional development are not based on fact. The root of this phenomina information gathered by the IT first contact person with the user who has the problem (Service Desk.)
RUMOR also feeds back into SUPERSTITION
When this phylosophy is deeply entrenched in the culture of the organization users don't even report their problems they tell the helpdesk that "the DNS server is having that problem again" and so the service desk opens a ticket to the same group that "fixed it last time." Too bad that the job of the service desk person is going to have to be done by an engineer who has to call the user back (and possibly play phone tag first) to get further details about a problem only to find out that (surprise!) the user was wrong about the diagnosis of their problem and it has to be requeued to the correct resources. The time wasted by this activity aggravates the user and often makes the real problem harder to diagnose. So when the lucky top tier engineer has to call the user for additional information about the problem the user is either to angry to be helpful or has forgotten any useful details.