SCCM: Administrator Console Locked up, Frozen, Hosed, or Hung solution

Today I received an email from a tech who complained that the Configuration Manager administrator console we have installed on a Windows 2003 terminal server was hosed up. I’ve seen this happen in a few instances. I’m not entirely sure why the console just sits hung, but the solution that I’ve seen work most often is to delete the MMC related files in the user’s profile that get created after the console has been used. You want to delete the sms and/or adminconsole files (I think the sms file comes from the old SMS 2003 console).

You can find the files at the following path:

Windows 2003: C:\Documents and settings\userid\Application Data\Microsoft\MMC

Windows 2008: C:\users\userid\appData\Roaming\Microsoft\MMC

Once the files have been deleted, logoff and log back on and run the console. This should fix the issue.

System Center Configuration Manager v.next Beta 1 has been released!

It’s been a long time coming, and I’m very excited for the release of Configuration Manager v.Next. Listed below are just some of the bullet points in this release. You can see the full announcement here.

Today we are very excited to announce the release of Beta 1 for System Center Configuration Manager v.Next.

System Center Configuration Manager v.Next is uniquely positioned to provide for powerful and flexible user-centric client management, allowing users to be able to seamlessly access their data from virtually anywhere, across multiple device types while providing IT with unified management tools and centralized control.

This next release of Configuration Manager is focused on 3 main pillars:

User centric application management  – Empowering Administrators to define intent, and end users flexible access to the right application at the right time

  • Allow the administrator to think users first
  • Application management model to capture admin intent
  • End user self-service software portal

Infrastructure simplification – Simplify management infrastructure, processes and administrative overhead

  • Unified management across PCs and devices
  • New role based administration and end-user experiences
  • Automated content distribution and troubleshooting
  • Redesigned core infrastructure and improved scalability

Simplify Client Management – Daily tasks, model based configuration management and improvements over existing capabilities

  • Automated compliance remediation
  • Client health and auto remediation
  • Remote control enhancements
  • Offline servicing of OS images
  • SCCM: Software Distribution Fails with Error Code 1603 in Execmgr.log

    Error code 1603 by definition is just a generic windows installer (MSIexec) fatal error code. Yesterday I was seeing this for a software package deployment. The interesting part of this was this was an application that was packaged for us by a third party vendor (a vendor that will remain nameless, but has created some poor packages for us in the past that allows me to write up blog posts like this explaining the solution to their packaging issues), and the application was actually installing on some machines but not all. In total, about 50% had successfully installed the application and the other 50% had failed. So it was a very peculiar push that piqued my interest.

    After looking at the advertisement report, I noticed that most of the successful installs were from Windows 7 machines. The failures were coming from Windows XP. So that pointed me to setup a test XP machine and test the push on that platform.

    Next I looked at the package and how it was created in SCCM (I personally didn’t set this up or work with the vendor on packaging it, so this was all new to me). I noticed that the install program was using a transform that the vendor had created as well as a requiring ISScript8 be run first before installing.

    After doing some research, I came across a forum post that made reference to DCOM InstallShield InstallDriver Identity properties being set incorrectly. In my case, we were running this application with administrative rights and silently via SCCM. When a local administrator was logged on during runtime, the application would install fine. It would also install fine if no one was logged on. However if a user was logged on without admin rights, we’d get the 1603 error.

    So I took a look at the InstallShield InstallDriver Properties from DCOMCNFG. To do this, follow the following steps:

    From a command line (or start – run) type in dcomcnfg
    Select Component Services
    Expand Computers
    Expand My Computer
    Expand DCOM Config
    Right click on InstallShield InstallDriver (in my case I had two of these)
    Select Properties
    Select the Identity tab

    What SHOULD be selected here is The launching User. What I had selected was The interactive user. So by changing both InstallShield InstallDriver identities to The Launching User I was able to run the application successfully as the user which was a low rights account.

    How to change the Installshield Installdriver Identity via VBScript

    So I had the problem solved, but I needed a way to do this programatically. I basically needed to run ISScript first, then run a VBScript to change the Identity value, then run the application. The good news is that these options are all stored in the registry! The problem though is that they’re stored in GUID/AppID format, and with different versions of ISScript out there, there isn’t a consistent method to fix this. What this means for you is that you need to get the GUID/AppID yourself, luckily for you, you can get the GUID/AppID from within DCOMCNFG.

    How to find the GUID/AppID from DCOMCNFG

    To find the Application ID, repeat the steps I listed above to get to the Installshield InstallDriver Properties pane.

    From a command line (or start – run) type in dcomcnfg
    Select Component Services
    Expand Computers
    Expand My Computer
    Expand DCOM Config
    Right click on InstallShield InstallDriver (in my case I had two of these)
    Select Properties
    Under the General tab select the Application ID

    Once you have the application ID, you can use the following VBScript to change the Identity of the Installshield InstallDriver. Note that if you only have one InstallDriver, you can remove the second path and the second deletevalue command.

    const HKEY_CLASSES_ROOT = &H80000000
    strComputer = “.”

    Set oReg=GetObject(“winmgmts:{impersonationLevel=impersonate}!\\” &_
    strComputer & “\root\default:StdRegProv”)

    strKeyPath1 = “Appid\{INSERT APPLICATION ID HERE IN BETWEEN THE BRACKETS}”
    strKeyPath2 = “Appid\{INSERT APPLICATION ID HERE IN BETWEEN THE BRACKETS}”
    strStringValueName = “RunAs”

    oReg.DeleteValue HKEY_CLASSES_ROOT,strKeyPath1,strStringValueName
    oReg.DeleteValue HKEY_CLASSES_ROOT,strKeyPath2,strStringValueName

    Once you’ve made the file, put it in the packagesource folder and make a new SCCM program using cscript nameofscript.vbs.

    SCCM: How to Restore the All Systems Collection in SCCM/SMS

    When I got into the office this morning an email came in from one of our technicians. The issue was that he couldn’t see the All Systems collection anymore and wanted me to put it back. Since I know I didn’t do this, I took a look at Status Message Queries to see what happened. I specifically looked at “Collections Created, Modified, or Deleted” to see who the culprit was and when the deletion happened. Once I figured out that yes, All Systems was in fact deleted, I ran the following VBScript (copy this text to a text file and save it as all_systems.vbs and run it on your site server):

    strSMSServer = “.”
    strParentCollID = “COLLROOT”
    ‘This example creates the collection in the collection root.
    ‘Replace COLLROOT with the CollectionID of an existing collection to make the new collection a child.

    strCollectionName = “All Systems”
    strCollectionComment = “This is the All Systems Collection.”
    Set objLoc = CreateObject(“WbemScripting.SWbemLocator”)
    Set objSMS = objloc.ConnectServer(strSMSServer, “root\sms”)
    Set Results = objSMS.ExecQuery (“SELECT * From SMS_ProviderLocation WHERE ProviderForLocalSite = true”)

    For each Loc in Results
    If Loc.ProviderForLocalSite = True Then
    Set objSMS = objLoc.ConnectServer(Loc.Machine, “root\sms\site_” & Loc.SiteCode)
    End if
    Next

    Set newCollection = objSMS.Get(“SMS_Collection”).SpawnInstance_()

    ‘Create new “All Systems” collection
    newCollection.Name = “All Systems”
    newCollection.OwnedByThisSite = True
    newCollection.Comment = strCollectionComment
    newCollection.CollectionID = “SMS00001”
    path = newCollection.Put_

    ‘Set the Relationship
    Set newCollectionRelation = objSMS.Get(“SMS_CollectToSubCollect”).SpawnInstance_()
    newCollectionRelation.parentCollectionID = strParentCollID
    newCollectionRelation.subCollectionID = (“SMS00001”)
    newCollectionRelation.Put_

    ‘Add the Query Rule
    Query = “SELECT * FROM SMS_R_SYSTEM”
    Set objQueryRule = objSMS.Get(“SMS_CollectionRuleQuery”).SpawnInstance_
    objQueryRule.QueryExpression = Query
    objQueryRule.RuleName = “AllSystems”
    newCollection.AddMembershipRule objQueryRule

    The collection was remade and all the objects are there like they should be. Now I need to lock all collections down so our techs don’t delete them anymore.

    SCCM: Collection Query to get all machines who haven’t rebooted in X amount of Days

    Here’s a query that I use to see all machines who haven’t rebooted in 7 days. You can change the 7 to however many days you want.

    select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where DATEDIFF(DD, SMS_G_System_OPERATING_SYSTEM.LastBootUpTime, GETDATE()) > 7

    SCCM: How to Determine Content Download to Cache Issues

    Over the past couple of days I’ve been fighting with an application that a 3rd party vendor packaged for us. The package in question is an MSI that calls numerous other files. In total, the package has over 3000 files and is about 180 MB in size.

    Issue

    The issue that was reported to me was that the content was not downloading. My datatransferservice.log, my CAS.log, and ContentTransferManager.log all looked good. The client found a local DP to download the content from. However when I looked at my cache folder, I saw that only a couple of MB of data was downloaded and it never increased in size.

    So I figured BITS was the culprit here. Unfortunately there’s no good logging for BITS without doing some nasty logmon stuff. The good news is that BITSAdmin is a great utility (at least for now, according to BITSAdmin on a Windows 7 box they reference new BITS Related powershell cmdlets which I didn’t find all that particularly useful).

    In order to see what jobs are currently downloading, type in:

    bitsadmin /list /allusers

    This will give you output similar to the following:

    BITSADMIN version 3.0 [ 7.5.7600 ]
    BITS administration utility.
    (C) Copyright 2000-2006 Microsoft Corp.

    BITSAdmin is deprecated and is not guaranteed to be available in future versions of Windows.
    Administrative tools for the BITS service are now provided by BITS PowerShell cmdlets.

    {19A1D938-E1E9-437F-882E-1BFAABB707CB} ‘CCMDTS Job’ ERROR 146 / 3805 4752558 / UNKNOWN
    Listed 1 job(s).

    Notice how in this picture I have the following line:

    {19A1D938-E1E9-437F-882E-1BFAABB707CB} ‘CCMDTS Job’ ERROR 146 / 3805 4752558 / UNKNOWN

    This is no good. This basically means there’s an error somewhere in the transfer job.

    Before we get into the next step of the solution, you must first understand what an SCCM distribution point is. An SCCM DP is simply a glorified web server. If you look at the Datatransferservice.log file on any of your SCCM clients, you’ll see a lot of URLs that look like the following:

    http://DOMAIN:80/SMS_DP_SMSPKGF$/CEN00119/System32/Redist/MS/System/msvcrt.dll

    What your client is basically doing is grabbing the files from these URLs and storing them into your local cache directory underneath the package ID.

    So back to BITS. Since we saw an error in our bitsadmin /list /allusers, we need to find out exactly what that error is. The following command will show just that:

    bitsadmin /info {19A1D938-E1E9-437F-882E-1BFAABB707CB} /verbose > c:\bits2.txt

    So what this command is doing is giving us the information about the failed BITS job that we saw before. The verbose command gives us the status of each file in the job. We then pipe this out to a file. Inside of that file, we see the following:

    BITSADMIN version 3.0 [ 7.5.7600 ]
    BITS administration utility.
    (C) Copyright 2000-2006 Microsoft Corp.

    BITSAdmin is deprecated and is not guaranteed to be available in future versions of Windows.
    Administrative tools for the BITS service are now provided by BITS PowerShell cmdlets.

    GUID: {19A1D938-E1E9-437F-882E-1BFAABB707CB} DISPLAY: ‘CCMDTS Job’
    TYPE: DOWNLOAD STATE: ERROR OWNER: NT AUTHORITY\SYSTEM
    PRIORITY: LOW FILES: 146 / 3805 BYTES: 4752558 / UNKNOWN
    CREATION TIME: 5/12/2010 11:31:04 AM MODIFICATION TIME: 5/12/2010 11:33:18 AM
    COMPLETION TIME: UNKNOWN ACL FLAGS:
    NOTIFY INTERFACE: REGISTERED NOTIFICATION FLAGS: 11
    RETRY DELAY: 60 NO PROGRESS TIMEOUT: 2419200 ERROR COUNT: 147
    PROXY USAGE: NO_PROXY PROXY LIST: NULL PROXY BYPASS LIST: NULL
    ERROR FILE:    http://DOMAIN:80/SMS_DP_SMSPKGF$/CEN00119/Program Files/Hummingbird/Connectivity/9.00/HostExplorer/SDK/Samples/OHIO/Visual C++ Samples/HEOhioSample/MyTabCtrl.cpp -> C:\Windows\system32\CCM\Cache\CEN00119.1.System\Program Files/Hummingbird/Connectivity/9.00/HostExplorer/SDK/Samples/OHIO/Visual C++ Samples/HEOhioSample/MyTabCtrl.cpp
    ERROR CODE:    0x80190194 – HTTP status 404: The requested URL does not exist on the server.

    ERROR CONTEXT: 0x00000005 – The error occurred while the remote file was being processed.

    DESCRIPTION:
    JOB FILES:

    The above shows exactly what the issue is. a HTTP status error of 404 indicates that the file cannot be found on the server. In my case, the package that I am troubleshooting has two + signs for the Visual C++ Samples folder. In this case, if I try to visit that URL (which you can do in normal situations) you get a 404, which confirms the error BITS is reporting.

    To fix this issue, you need to change the path so that this folder doesn’t have any special characters. In ansi, a + sign is the equivilent to a 0x2B (i.e. %2B for a URL string), however the way SCCM handles this poor. I’m not sure if this is a bug, or just by design. The vendor was the one responsible for this pathing, but I can see where some apps will have folders for their SDK that would include C++ example code.

    In any event, it took 2 days to figure this one out, but thankfully I did. Luckily, the users don’t need the SDK files :)

    Related External Links

    Related External Links

    SCCM: Program failed (download failed – content mismatch) for advertisement failures

    Today I was noticing on a few of our advertisements that all of our machines in the collection had received the “Program failed (download failed – content mismatch)” failure message. Upon receiving this error message, I came across a blog post by Matthew Boyd that referred to the following:

    Binary Differential Replication – If this is enabled in the package configuration, some packages seem to fail. I’m assuming that they can’t handle this kind of replication and several of the files become corrupt, creating a hash mismatch. This can be turned off by opening up the package properties, going to the Data Source tab, and unchecking Enable binary differential replication. This wasn’t my problem because I hadn’t enabled binary differential replication.

    Hidden Files – Apparently, if the package source contains hidden files, SCCM may not calculate the correct hash for the package and clients could encounter an error. I found a quick way to check this using the command line:

    1. Open up a command window in the root director that contains your package source files.
    2. Type Dir /S /A:H and hit enter. Depending on the package, you may be presented with several directories with multiple hidden files.
    3. Trying to remove the hidden attribute on all the files with the GUI would be tedious, so just use this command instead: attrib -H /S
    4. Update Distribution Points

    For my environment, BDR has never been an issue with content mismatches. So for the specific package I was working on I looked at my package source and sure enough there were some hidden files in the source.

    So my next step was to look at my entire package source folder and I noticed that there were a lot of packages that had some hidden files. I went through their advertisement reports and sure enough, these packages also had content mismatch failures.

    Thanks to Matthew for posting the tip.

    Related External Links