• MS11-100 – KB2656352, KB2657424
• MS11-078 – KB2572073
• MS11-044 – KB2518864

So far this has affected some population of Windows XP and Windows 2003 x86 servers.

The issue is that SCCM would offer these hotfixes to the client machines and upon installation it will report “failed”. However, if you install the hotfixes manually, it will say installation was successful. Evenlogs status also reports successful. This obviously is causing issues especially if you are using SCCM to track security patch compliance status. Even though the hotfixes were installed on those machines, SCCM will report them as non-compliance. Furthermore, the client machines are being offered the same hotfixes again and again.

Investigation reported by the support team found that it appears that the detection logic from WSUS for those patches is flawed or incorrect. The detection logic looks for the following registry keys to determine applicability along with some file versions.

HKLM\Software\Microsoft\Updates\Microsoft .NET Framework 2.0 Service Pack 2

But some client machines have the following key instead:

HKLM\Software\Microsoft\Updates\Microsoft .NET Framework 2.0 SP2

Changing this to “Microsoft .NET Framework 2.0 Service Pack 2” then retrying the update installation would complete successfully reporting the update to be installed.

In another server, KB2657424 became applicable and installs after I’d amended a reg key for .Net 3.5 SP1 from ..\Microsoft .NET Framework 3.5 SP1 to “..\\Microsoft .NET Framework 3.5 Service Pack 1”

So the workaround is the rename the registry keys, but we are not sure what this may impact. Personally, I feel that this is sufficient and should not have too much impact. Nevertheless, this issue is being raised to Microsoft for their comments and further investigation.

• SVR1 – my script server in Singapore
• SVR2 – the remote server I want to run the scheduled job in London.

I issued the following command at SVR1:

schtasks /CREATE /s SVR2 /ru me /rp pw /sc ONSTART _
/tn Job1 /tr "c:\runme.cmd"

Task got created on SVR2, I reboot the server but Job1 never kicked off after reboot! Why?

It turns out that if you issue a command from a remote server for ONSTART, the scheduled task property (Under Edit Trigger) called Activate will have a date time stamp of SVR1. This tells SVR2 that the job is only active after that time, which is 8 hours away (SGP is +8 hrs different from LDN)

There is no parameters in the schtasks that can modify this behaviour. (pull hair and curse at M$).

There are 2 workarounds that I can think of however:

A) Using XML

• Precreate the tasks and export as an XML file.
• Remove the tag “StartBoundary” under Trigger -> BootTrigger
• Use this XML file to create the schedule task

This method will not work on w2k if you have more than one type of OS versions.

B) Run a schedule command to schedule the onstart task locally.

schtasks /create /s SVR2 /ru me /rp pw /once /sd 09/09/2011 _
/st 01:00 /tn Job2 /tr "schtasks /create /ru me /rp pm _
/sc onstart /tn Job1 /tr "c:\runme.cmd" /z

Then issue command

schtasks /run /s SVR2 /tn Job2

This will create a job2 that will create Job1 from the server SVR2 local. The /Z option will cause the task to be deleted after its been run, so that your password is not exposed!

Also you will notice that I used a really old date/time. This is on purpose. I use this method to create one time schedule job so that I can trigger them manually. If I create it with a future date, it may trigger without me wanting it to.

Also you notice I set 09/09/2011, sometimes I use 01/01 for month-day. The reason is that schtasks /SD command is dependent on the regional date/time settings. So if you have a generic script with /SD 11/24/2011, it may not work on a server with format DD/MM/YYYY. Having values 01/01 to 12/12 will ensure this will work regardless of MM/DD or DD/MM.

Luckily some nice person on PreCentral found the solution and am reposting it here for easier web search.

http://forums.precentral.net/webos-discussion/189477-modifying-replacing-fonts-3.html#post3094128

The trick is simply; you can enter the ASCII value from your keyboard using “ALT + keypad numbers”. So for “\”, the ASCII value is 92. If you hold “ALT” and enter “92″ from the number keypad, “\” will appear. You can use this technique for any ASCII character. Its good to remember your ASCII table.

Here we were required to retire old folders. Its simple enough if there is only 10, but being a clean up job, we found hundreds and needed to rename them to _RETIRED_yyy-mm-dd_filename. Addition checks for folder access and if the change was done sucessfully was added. Input is a CSV file as below:

path,folder
c:\temp,test11
c:\temp,test22

Results is output to a log file called retire-fldr.log

param([string]$file)

$outlog = ".\retire-fldr.log"
$d = Get-Date $ds = "$($d.year)-$($d.month)-$($d.day)"
$f = import-csv $file
foreach ($fldr in $f)
{
 $new = "_RETIRED_$($ds)_$($fldr.folder)"
 Write-Output "Working on... $($fldr.path)`\$($fldr.folder)"
 if (test-path "$($fldr.path)`\$($fldr.folder)")
 {
  Rename-Item -path "$($fldr.path)`\$($fldr.folder)" -NewName $new
  if (test-path "$($fldr.path)`\$new")
    {"$($fldr.path)`\$new `t DONE" |out-file $outlog -append}
  else
    {"$($fldr.path)`\$new `t ERROR" |out-file $outlog -append}
 }

else {"$($fldr.path)`\$($fldr.folder) `t NO ACCESS" |out-file $outlog -append}
}

http://blogs.msdn.com/b/powershell/archive/2006/07/15/variable-expansion-in-strings-and-herestrings.aspx

http://blogs.msdn.com/b/rds/archive/2007/06/15/introducing-terminal-services-server-drain-mode.aspx

In summary:

• the pwdLastSet property of the CNO and VCO in AD should be refreshed every 30 days by default (just like workstation passwords). If the last password set is much longer than 30 days, it should indicate stale cluster objects.
• By default, when a cluster Network Name resource is deleted or if a cluster is destroyed, the CNO and VCO’s are placed in a disabled state.  Any cluster computer object which is in a Disabled state is no longer being used by the cluster.
• When destroy a cluster, use –CleanupAD switch to the Remove-Cluster in powershell to remove the CNO and VCO instead of putting them in a disabled state as above.
• CNO and VCO contains SPN “MSClusterVirtualServer”, so you can identity which computer object is cluster by quering its SPN service.

Function SplitSec(pNumSec)
  Dim d, h, m, s
  Dim h1, m1

  d = int(pNumSec/86400)
  h1 = pNumSec - (d * 86400)
  h = int(h1/3600)
  m1 = h1 - (h * 3600)
  m = int(m1/60)
  s = m1 - (m * 60)

  SplitSec = cStr(d) & "," & cStr(h) & "," & cStr(m) & "," & cStr(s)
End Function

This is where the logic starts to break down.  The code wanted to write to b7b4d6ec, which is a valid address.  The bugcheck code and cr2 say we failed writing to address c73fdb0b.  This does not make sense.

The analogy I often use for scenarios such as this one is: If I ask my intern to get me a Mountain Dew from the break room, and he comes back to say we are out of coffee, am I at fault or is my intern broken?  Applying the same logic to this crash, if ObReferenceObjectByHandle asks the hardware to write to address b7b4d6ec and the hardware came back saying it cannot write to address c73fdb0b, is the software at fault or is the hardware broken?  Clearly the hardware is broken if it does not do what the software asks of it.

http://blogs.msdn.com/b/ntdebugging/archive/2011/06/29/a-classic-case-of-whodunit.aspx