Plain Text Prose

i encountered this error when i was running an installation of visio 2007.  after doing a search, i found this blog entry that described the same problem.  i concur with scott hanselm.  this is a really lousy error. the blog entry itself doesn’t describe how to track down the problem.  however, in a comment, michael grier indicates exactly where to look. in summary, you want to do the following: navigate to %windor%\logs\cbs inside this directory, find the “cbs.log” file and open it from the bottom up, search for the “(F)” in my case, this is what i found. 2009-04-24 09:30:21, Error CSI 000000b3 (F) A previous transaction requested a reboot, so you cannot commit any transactions until you reboot. oh, so that’s all it is?  i just needed to reboot and clear out the pending changes first.

i was looking for flowcharts for configmgr and couldn’t find any.  as it turned out, there really aren’t any.  remember in the lovely 2.0 days?  at least they had some great flowcharts back then.  eventually when enough superflows release, this conversation will be so far in the past. until then … grab a copy of steve rachui’s flowcharts .  he did a pretty bang up job.  granted this is configmgr 2007 rtm, there’s still tons of information with screenshots and dialog.  great, great material.

this is a great article on lastLogonTimeStamp.  particularly interesting to me are the kinds of triggers that will cause an update to this attribute.  here’s a snippet: Logon types and that will trigger an update to the lastLogontimeStamp attribute. The lastLogontimeStamp attribute is not updated with all logon types or at every logon. The good news is that the logon types that admins usually care about will update the attribute and often enough to accomplish its task of identifying inactive accounts. Interactive and Network logons will update the lastLogontimeStamp . So if a user logs on interactively, browses a network share, access the email server, runs an LDAP query etc… the lastLogontimeStamp attribute will updated if the right condition is met. (The conditions are discussed below in the section Update and Replication of lastLogontimeStamp . As of Windows 2003 SP1 these logon types will NOT update lastLogontimeStamp Certificate mapping through Micros

if you get this alert from opsmgr, it’s more than likely a problem with the management group(s) your agent is assigned.  i didn’t catch on to this initially because of the myriad distractions, but the clue is in the alert description. “The health service on myServer is attempting to communicate with a management group that does not exist on this server.  The management group Id the agent is requesting is <guid>.  Please verify that the management group specified on the agent and server is correct.” so that is in fact, exactly what i did.  in the registry, i found the entries to the old management group still plugged in there under this path: hklm\software\microsoft\microsoft operations manager\3.0\agent management groups. after that, the agent streamed down all the assigned management packs.  looks like i might to get look forward to some clean up scenarios when deploying to production.  if so, i’ll be scripting it.  :)   update: unfortunately the management

i got this notification from the online marketing manager of bridgeways.  i figured i’d let you guys know about it since i’m planning to check it out myself.  considering the *nix extensibility r2 brings to the table, i’m interested in seeing what it will bring to the table. if you’re going to join in too, let me know!  here’s the link -- How to extend Microsoft System Center Operations Manager