I finally completed upgrading our SCCM 2007 central site (and two secondary sites) to SP2.  Though it was successful, there were two issues that occurred as a result of the upgrade which may be useful for you to watch for. 

The first issue is that I was unable to update any distribution points for packages or adding new distribution points to a package.  This was being caused by a malfunctioning Distribution Manager in which the changes were being queued and not processed.

  • Issue can first be identified by noticing that updating package distribution points is “stuck” in a state of “Install Pending”
  • Check the distmgr.log – it may show that every the manager is attempting to validate every single package on every single distribution point…one at a time. 
  • If the distmgr.log will show a line that says “GetObject Failed error 0×8007003
  • If a file named “RESETISAPI.TRN” exists within  the DistMgr.box
  • Then the solution is founded in http://support.microsoft.com/default.aspx/kb/969163 for the second solution. 

The second issue that I experienced with the inability for unknown computers to know that there was a task sequence assigned to run.  Short of the long story is that I fixed the situation by deleting the existing advertisements and recreating them.

You can see the following post on my upgrade path to SP2 on SCCM 2007.  Below that is a short list of my post upgrade tasks, which will be done in the months following, but not the night of the upgrade…

http://t3chn1ck.wordpress.com/2009/11/05/my-sccm-2007-sp2-upgrade-path/

Post Upgrade Tasks

  1. Upgrade all consoles with SP2 files
  2. Deploy SCCM SP2 client
  3. Deploy Windows Update Agent 7.4.7600.226
  4. Deploy latest version of Nomad Branch

The upgrade path for my SCCM 2007 R2 to SP2 is as below.  I thought it may be helpful to someone out there…

  1. Disable any advertised OSD task sequences
  2. Make a backup copy of the default boot.wim files
  3. Ensure a recent sucesseful site backup by reviewing smsbkup.log
  4. Update server with any critical Windows and SQL updates
  5. Uninstall WAIK 1.1
  6. Reset all counts for status messages on the sites to make for easier troubleshooting post upgrade
  7. Upgrade WSUS to 3.0 SP2
  8. Install SCCM 2007 SP2
  9. Upgrade secondary sites from the console
  10. Upgrade Nomad Branch to the latest version (if you use it in your environment)
  11. Update the distribution points for any packaged SCCM clients
  12. Re-establish classifications for Software Updates – this is to correct a known issue where the classifications are reset during the SP2 upgrade
  13. Re-establish products for Software Updates
  14. Re-establish customizations within the default boot images.  For example, we have trace32 in our boot images, so I needed to put them back.
  15. Re-establish customizations to SMS_def.mof and Configuration.mof
  16. Re-enable the disabled OSD task sequences

See the following post on my post upgrade tasks, which will occur in the months following the upgrade

http://t3chn1ck.wordpress.com/2009/11/10/post-sccm-2007-sp2-upgrade-tasks/

I’m working on upgrading our sites to the recently released SP2 for SCCM 2007 so as to support Windows 7 and Server 2008 R2.  In using the prerequisite checker, I was a given an upgrade warning that “All distribution points in the site to be upgraded should have the latest version of software distribution packages before beginning the upgrade process”.  In looking more closesly at the warning (within log file C:\ConfigMgrPrereq.log) there was information on the query being executed to determine if any packages have potentially mismatching versions.

Using my Google-fu, I found a post from the ConfigMgr Support Team Blog which led me to a query to determine the impacted packages that I was able to run within SQL Server Management Studio (query below).  Unfortunately, almost all of our packages are impacted, so I am just going to disregard the warning for now….

select Name, PkgID, SourceVersion, StoredPkgVersion
from SMSPackages
where StoredPkgVersion <> SourceVersion

 

 

 

Sometimes when troubleshooting SCCM client software inventory, it is useful to retain the XML file which contains details on what the scan discovered.  To do this, simply create a file named “archive_reports.sms” within C:\WINDOWS\system32\CCM\Inventory\temp\.  If the scan is just reporting a delta, the file will be small.  But if it is a full SINV scan, then it could be large (the biggest I’ve seen is around 75 MB)

There are times when you may be unable to use “Right-click tools” to initiate a full software inventory scan on an SCCM client.  To schedule this to occur automatically upon the next normally schedule SINV cycle, do the following:

  1. Click on Start\Run and type wbemtest
  2. Connect to root\ccm\invagt
  3. Click on Enum Classes with recursive selected Look for a class named InventoryActionStatus
  4. Double click  InventoryActionStatus On the Object Explorer for InventoryActionStatus dialog box
  5. Click on Instances Select
  6. Delete the instance with value InventoryActionID = “{00000000-0000-0000-0000-000000000002}”

The Deployment Guys created of a handy utility (v2) that will automatically format your Task Sequences so that they are readable.  It uses a stylesheet to format the .xml with nifty columns and colors.  Check it out…No more looking through confusing XML code!

http://blogs.technet.com/deploymentguys/archive/2009/02/20/update-to-the-tasksequence-documentor.aspx

This is a little SQL web report I created that identifies systems which have not reported hardware or software inventories within the last 14 days.

SELECT DISTINCT
    SYS.Netbios_Name0,
    HWSCAN.LastHWScan,
    SWSCAN.LastScanDate
FROM v_R_System SYS

Full LessThan14Days SQL Code Here

Note: you’ll want to change the collection ID to be the one you need.  Or modify the code to prompt for a collection would probably be even better still!

I have been struggling with a problem all day that, when I was inches from giving up, I found the cause and the workaround.  Thought I’d share it too.

Sometimes it is necessary to not force a mandatory start time for an SMS/SCCM advertisement, but intead to allow the end-user to manually trigger the advertisement/program from the control panel applet “Run Advertised Programs”.  The situation was that, for all servers within the targeted collection (only 4 servers total), the Run Advertised Programs applet was blank.  And there was no “New Program Available” system tray icon.  I tried everything from different Program settings, different Advertisement settings, reviewed the Advertised Programs Client Agent, collection settings, etc etc etc.

After taking a short break to play company softball, I came back to the office to practiced my Google-foo skills.  I stumbled upon a forum posting about RDP interfering with the applet.  With my fingers crossed, I launched RDP in admin mode (e.g. mstsc /admin), logged into the server, launched the Run Advertised Program applet, and voila …there was my advertisement.

Hopefully one day I’ll find the solution and update this post…or maybe someone will read it who already knows the solution!

This VBScript is for disabling the Fingerprint device in BIOS.  It has only been tested on a few newer HP models.

‘============================================================
‘ AUTHOR: Nick Moseley ,
http://t3chn1ck.wordpress.com
‘ DATE  : 5/29/2009
‘ COMMENT: This script is for disabling the Fingerprint Device in BIOS
‘ It has been tested on HP models – 6515b, 6535b, 2510p – but may
‘ function for other models
‘============================================================
Option Explicit

Click Here for Full DisableFingerprintDevice.vbs Code

Queue of Upcoming Posts

  1. Scripting XP Power Settings
  2. "Homegrown" Client Health Solution
  3. SCCM Superflows
  4. Creative Solution for Using Different Network Settings in Task Sequences
  5. Scripting the backup of VMWare Server 2 VMDKs

Blog Stats

  • 13,733

World Map of Blog Hits

Most Recent Visitors!

 

December 2009
M T W T F S S
« Nov    
 123456
78910111213
14151617181920
21222324252627
28293031