I’m not saying that there isn’t historical issues with the black screen of death (aka KSOD) that Mark Crall probably lost a few dents in his head to a few months back, but tonight as the Techmeme articles are parroting the “Latest Microsoft Patches cause black screen of death”, I’m asking …okay are all of the folks supposedly impacted by this not calling in, not posting in a newsgroup, not posting in a forum and only silently suffering? 

I will be the first to eat crow (rather than leftover turkey) if something comes out of this, but right now I’m doubting Thomas for sure.

Microsoft investigates Windows ‘black screen of death’ triggered by recent security updates | Security – InfoWorld:

“Searches of Microsoft’s support forums today, for example, turned up only one “black screen” thread with posts after the Nov. 10 security updates had been released. Four different users on that Windows 7-specific thread said that they faced a blank screen.”

Microsoft investigating ‘black screen of death’ | Beyond Binary – CNET News:

“So this is a problem that ostensibly would have happened 20 days ago? Does it happen right away, or under certain circumstances.

Cause if its supposed to happen right away, I’m sure we would have heard about it before a press release from a software vendor. People love to jump on any problems that MS has, I’m surprised it would have stayed quiet for 3 weeks.”

“I loved this line from the link “If you Google Black Screen then you will find a whopping 80Million plus results” except all but the computer world article and Cnet article are between 1 and 5 years old.”

So if some of your workstations are not showing up properly in the SBS 2008 Computers console, here’s what I did to fix all of my truant ones.

Event ID 10016 Source DCOM:

In my case I went into Dcomcnfg.exe

Then I went under component services, computers, my computer, dcom config, then found the 49BD2028-1523-11D1-AD79-00C04FD8FDFF CSLID and changed the settings to “use default”


Then I followed this and

Repairing and re-registering the WMI:

Did the following commands at a c:\

rundll32 wbemupgd, UpgradeRepository

Then did this:

  • cd /d %windir%\system32\wbem
  • for %i in (*.dll) do RegSvr32 -s %i
  • for %i in (*.exe) do %i /RegServer
  • This big square box will load up just hit cancel.

    Close the command window.

    Why did I do all of that?  to get the WMI kicked back into gear so I could fix the lack of security status being reported in the SBS 2008 console.

    If your machines are not checking in, it’s either a firewall blocking the communication, or your WMI messed up.

    Vista and Win7’s were connecting just fine but I had three XPs not reporting the proper security status.   Remember that servers will not report a status as they have no security status center.



    And now I’m not …..

    Now protecting the RWW access (especially for the administrator account)…

    And the cool thing is that I can now use iPhones and Windows mobile phones to be portable softtokens

    I’ve also added the protection to the RDP access to the server so that it’s not open.  Mind you I already limited the RDP access to certain IP addresses, but this tightens up security that much more.

    And you can extend the password policy and let people change them LESS often to then ensure that they choose better passwords.

    Windows Small Business Server 2008 from SBS 2003 R2 | Loz’s ALITs Blog:

    For the migration scenario from Windows Small Business Server 2003 R2 to Windows Small Business Server 2008, a manual migration will be required. More information will be provided in the future.

    “Exactly who’s future is that then? Do we have to wait for an R2 release of 2008 to be able to do a slick automation of the upgrade process? All very foggy – but we shouldn’t really be surprised!”

    Two comments to this post. 

    We will never have a slick automation of the upgrade process.  There is too much in active directory.  Not to mention going from SBS 2003 to SBS 2008 it’s a 32 to 64 bit transition.

    And If there ever was the ability to have a slick upgrade process, that kinda means IT pros are no longer needed?  🙂

    Seriously, that page needs a little bit of updating as the migration docs have been published.


    And if you are looking for other alternatives… www.sbsmigration.com provides support along the way.

    But automatic?  Not possible with the kind of networks we have.

    EVENT # 15343
    EVENT LOG System
    EVENT TYPE Error
    OPCODE Info
    SOURCE Microsoft-Windows-DistributedCOM
    EVENT ID 10009
    DATE / TIME   11/28/2009 8:36:23 PM
    MESSAGE DCOM was unable to communicate with the computer ANOTHERSERVER.DOMAIN.lan using any of the configured protocol

    So when you put another server on the network and just set it up for a specific purpose it may not open up all of the needed protocols in the firewall that it needs to correspond to the SBS 2008 box.

    So here’s how to adjust the firewall to get the Dcom messages out of your event logs:

    Event ID 10009 Source DCOM:


    Check the firewall settings and enable the firewall exception rule

    To check the firewall settings and enable the firewall exception rule:

    1. Click Start, and then click Run.
    2. Type wf.msc, and then click OK. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
    3. In the console tree, click Inbound rules.
    4. In the list of firewall exception rules, look for COM+ Network Access (DCOM In).
    5. If the firewall exception rule is not enabled, in the details pane click Enable rule, and then scroll horizontally to confirm that the protocol is TCP and the LocalPort is 135. Close Windows Firewall with Advanced Security

    Right mouse click and enable the rule


    Then to get the server to be able to query the name/model of the remote server enable the WMI in the inbound firewall rules as well.



    Once you do that your server will report into the console and provide the hardware information on the Network/Computers tab.

    When you set up ANY computer, be it a workstation, server, whatever, you want to flip from Windows Update to Microsoft Update.

    In Windows 2008/Vista/Windows 7 there’s a tiny little section you need to click on to get it to flip.


    Which then brings up the web page to opt into Microsoft update.

    Even though the server is patched by WSUS, this way you can run manual scans to MU as you like.

    When you add a member server to your SBS 2008 you will notice that it adds itself as a workstation.

    You have to go into active directory users and computers, find the MyBusiness OU, then go to the SBSComputers OU and move the Server that’s listed in the SBS computer section over to the SBSServers section.

    Right click on the name of the server, and click on move.


    Then MOVE the server to the right OU so that it’s listed up in the right section in the networking console.

    And the fact that the security status is “Not available” is normal.  There is no security status center on a server.

    So “normal” for servers is green/grey/green/green.

    One of the key “this will nail you EVERY migration you attempt” is the Journal Wrap.  And I’ve seen a lot of folks in the SBS world with a journal wrap error.

    Fortunately it’s an easy fix.  You literally read the KB article that it points to and voila, it fixes the journal wrap error.

    This was an old one I had years ago on my old SBS 2k3 server.  I got in this condition because I didn’t have a good UPS on the home server and Dad and PG&E shut down the circuit breaker on the house during Thanksgiving weekend in 2007.  I didn’t fix the error until Christmas because on a single domain box, you won’t notice it having issues.

    Event Type: Error
    Event Source: NtFrs
    Event Category: None
    Event ID: 13568
    Date:  12/25/2007
    Time:  2:43:19 PM
    User:  N/A
    The File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR.
     Replica set name is    : “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)”
     Replica root path is   : “c:\windows\sysvol\domain”
     Replica root volume is : “\\.\C:”
     A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found.  This can occur because of one of the following reasons.
     [1] Volume “\\.\C:” has been formatted.
     [2] The NTFS USN journal on volume “\\.\C:” has been deleted.
     [3] The NTFS USN journal on volume “\\.\C:” has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
     [4] File Replication Service was not running on this computer for a long time.
     [5] File Replication Service could not keep up with the rate of Disk IO activity on “\\.\C:”.
     Setting the “Enable Journal Wrap Automatic Restore” registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.
     [1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run “net stop ntfrs” followed by “net start ntfrs” to restart the File Replication Service.
     [2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.
    WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.
    To change this registry parameter, run regedit.
    Click on Start, Run and type regedit.
    Click down the key path:
    Double click on the value name
       “Enable Journal Wrap Automatic Restore”
    and update the value.   [to 1]
    If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Keep in mind that even if you have fixed it, it may still show up in the BPA report as it sees that old journal wrap event left over in your File replication log files.  The key thing is to review the File replication log and ensure that post registry you get indicators that the system has been fixed up.

    Event Type: Warning
    Event Source: NtFrs
    Event Category: None
    Event ID: 13560
    Date:  12/26/2007
    Time:  12:34:03 AM
    User:  N/A
    The File Replication Service is deleting this computer from the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” as an attempt to recover from the error state,
     Error status = FrsErrorSuccess
     At the next poll, which will occur in 5 minutes, this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Event Type: Warning
    Event Source: NtFrs
    Event Category: None
    Event ID: 13520
    Date:  12/26/2007
    Time:  12:39:39 AM
    User:  N/A
    The File Replication Service moved the preexisting files in c:\windows\sysvol\domain to c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog.
    The File Replication Service may delete the files in c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog at any time. Files can be saved from deletion by copying them out of c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog. Copying the files into c:\windows\sysvol\domain may lead to name conflicts if the files already exist on some other replicating partner.
    In some cases, the File Replication Service may copy a file from c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog into c:\windows\sysvol\domain instead of replicating the file from some other replicating partner.
    Space can be recovered at any time by deleting the files in c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Event Type: Information
    Event Source: NtFrs
    Event Category: None
    Event ID: 13553
    Date:  12/26/2007
    Time:  12:39:40 AM
    User:  N/A
    The File Replication Service successfully added this computer to the following replica set:
    Information related to this event is shown below:
    Computer DNS name is “kikibitzfinal.Kikibitzrtm.local”
    Replica set member name is “KIKIBITZFINAL”
    Replica set root path is “c:\windows\sysvol\domain”
    Replica staging directory path is “c:\windows\sysvol\staging\domain”
    Replica working directory path is “c:\windows\ntfrs\jet”

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Using the BurFlags registry key to reinitialize File Replication Service replica sets:

    Complications from an SBS 2008 Migration :: Third Tier:

    And don’t blow off what it says….

    One of the group policy tweakages I’ve done is to have it so that when someone connects via RWW that the desktop background they have on their office machines get’s blanked out.  With Vista and Win7 and the nice (heavy graphical) wallpapers people have chosen slows down the remote web workplace screen.

    So just go into Group policy

    and enable the “Enforce Removal of Remote Desktop Wallpaper”