Month: November 2009

Issues of Post-SP2 Upgrade for SCCM 2007

Posted on

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 0x8007003
  • 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.

Advertisements

Post SCCM 2007 SP2 Upgrade Tasks

Posted on Updated on

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…

https://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

My SCCM 2007 SP2 Upgrade Path

Posted on Updated on

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.  This is done by going into Site Settings > Component Config > Software Update Point Component > Classifications tab.
  13. Re-establish products for Software Updates.  This is done by going in the same SUP Component, but on the Products tab.
  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

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

SCCM 2007 SP2 Upgrade – Prereq Checker

Posted on Updated on

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