• Manual removal of the SCCM client

    As much as I love it, it may occasionally be necessary to remove the System Center Configuration Manager client.  I recently had a customer who could not get a machine to upgrade from 2007 to 2012 and after attempting many things we did a manual clean down of the client then the 2012 client installed just fine.  If you need to remove the client you can do so fairly easily by running ccmsetup.exe /uninstall.  Ccmsetup should exist on all clients, usually under the windows folder.  In the event that the command line doesn’t work here is a list of things I usually check and remove to manually clean-up all the traces of the client so I can try a fresh install.

     

    1. SMS Agent Host Service

    2. CCMSetup service (if present)

    3. \windows\ccm directory

    4. \windows\ccmsetup directory

    5. \windows\ccmcache directory

    6. \windows\smscfg.ini

    7. \windows\sms*.mif (if present)

    8. HKLM\software\Microsoft\ccm registry keys

    9. HKLM\software\Microsoft\CCMSETUP registry keys

    10. HKLM\software\Microsoft\SMS registry keys

    11. root\cimv2\sms WMI namespace

    12 root\ccm WMI namespace

    * Updated 9/30 to add WMI info

  • KB2775511 deployment for the SCCM Admin

    This week Microsoft rolled out a BIG hotfix (90 hotfixes) rollup for Windows 7 SP1 and Windows Server 2008 R2 SP1.  To better understand all the goodness it gives you check out the AskPFEPlat blog or go to the source of one of the guys who helped put it together, my fellow PFE Jeff Stokes.  It is being distributed as an enterprise hotfix and so I think it likely that a lot of you folks running SCCM to manage your enterprise might want to roll out this hotfix.  One big advantage that comes to mind is including it in your OSD image capture to cut down on patch install time for future deployments.   The trick is that “out of the box” you can’t deploy this.  It does not sync to WSUS and your SCCM software update point (SUP) automatically.  There are some simple steps you can take to get it there, however.

    1. On your central site/CAS SUP open up the Windows Server Update Services admin console
      1. It is worth noteing that we see SCCM folks do more harm than good in the WSUS admin console, but this is one of those exception times you need to go in there.  Do so carefully.
    2. Go to updates and select Import Updates to launch a webpage to the Microsoft Update Catalog.
      1. image
    3. Search on 2775511 and then add all that you are interested in getting for your environment
      1. image
    4. Make sure the checkbox to import directly is selected then hit the import button.
      1. Another box will come up tracking the download and show success when completed
        1. image
    5. Verify that your SCCM site is set to sync "Updates" classification, becase that is what this is (as compared to "service packs" or "security updates").
    6. Once that download is complete you can sync SCCM and then you should see the updates in SCCM to deploy as you would any other update
      1. image
      2. image

     

    3-14-13 update - Added links to AskPFEPlat and Jeff Stokes' blogs along with warning about using WSUS admin console

    3-14-13 update #2 - added clarity about fix classification

  • Prompted Query to find machines based on MAC address

    One of my customers asked me to build this example query and I figured I would share with everyone, not just one company.  it can be handy when you are doing OS Deployment testing and you need to look up a machine based on its MAC address to delete it so it becomes an “unknown computer” again.  Keep in mind that in the ConfigMgr database, the MAC address is in the form of ZZ:ZZ:ZZ:ZZ:ZZ:ZZ.

     

    select distinct SMS_R_System.Name, SMS_R_System.MACAddresses from  SMS_R_System where SMS_R_System.MACAddresses = ##PRM:SMS_R_System.MACAddresses## order by SMS_R_System.MACAddresses

     

    “This software (or sample code) is not supported under any Microsoft standard support program or service. The software is provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the software and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the software be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the software or documentation, even if Microsoft has been advised of the possibility of such damages.”

  • Basic content deployment troubleshooting in SCCM 2012

    I was recently asked to pull together a general starting point guideline on how to troubleshoot content deployment issues with SCCM 2012.  There is a lot that could go wrong, and the specifics for each scenario are different, but here is what I pulled together as a general starting point.

     

    · Check Status in the UI

    · Head to the logs

        • If you missed the time or no problems are obvious look "downstream" at pkgxfermgr.log
        • If you should have info but do not, look "upstream" at the parent site communication components (sender, scheduler)
      • Watch for lines with “STATMSG” in them where you see Sev=W or Sev=E
      • This are the error and warning status messages and help focus on problem points
      • Look just above them to see the real issue
    • Use CMTRace.exe and look for lines colored red

    Additional info:

  • System discovery of an untrusted forest fails with 0x8007052E

    I got a question from one of my customers the other day that was an easy, but not obvious, answer.  They had SCCM 2012 setup in Forest A but wanted to discover machines in forest B.  They supplied alternative credentials with the correct username and password for this other domain\forest but kept getting back a 0x8007052E error, which translates to “Logon failure: unknown user name or bad password.”

     

    That error is, unfortunately, a misleading error.  There is nothing wrong with the username or the password.  The real problem was in the formulation of their LDAP query.  They needed to add a named DC to the query for it to run correctly, which was not an obvious thing to do.  The solution syntax was to formulate the LDAP query that looked similar to this:

    LDAP://RemoteDC.remotedomain.com/DC=remotedomain,DC=com