Symptoms: Clients reinstall the ConfigMgr Client on a daily basis, and it doesn't appear that any automated push, automated deployment, or technician is reinstallng the client. In the %windir%\ccmsetup log, the reinstall is successful (exit code of 0) but yet the client reinstalls over and over again, seemingly automatically.

Cause: At some point in time in the client's past, a scheduled task called "Configuration Manager Client Retry Task", was created on purpose to retry a failed client install. However, once the client was successfully installed, that scheduled task was not (for some reason), and is not, being removed. No matter how many times the client reinstalls successfully.

Fix: Manually, go look at scheduled tasks, and delete that task. Automatically, you can import the attached Configuration Item --> Here <--, and deploy it (by adding it to a Baseline, and deploying that Baseline with the checkbox to allow remediation) to find and remove the scheduled task.

This Configuration Item may not be the best answer for your environment; it's up to you to determine if this Configuration Item is required, and to which collection of machines you want to target.  One suggestion could be to create a collection of "clients with the latest version in your environment (whatever that is)". The theory being that if those clients have the latest version, if they are a healthy enough client to find the policy for this baseline deployment, and they are already the latest client version--why retry reinstalling the CM Client? It's clearly installed and working... so... the SchTask clearly isn't actually needed, if it's there.  Of course, YOU will need to remember to change the collection's query whenever your client version increments; so that you are targeting the correct clients; for your environment.

Have you ever noticed, and been confused by, why sometimes, for some new client installations of the ConfigMgr 12 client, it seems like Hardware Inventory, the very first one, takes forever to trigger naturally?  That's by design.

There's something called "Inventory Max Random Delay", which is a setting you can modify--just not via the console.  My understanding of what it is for is to randomize when, for example, someone uses client push to say... their entire, newly discovered, every single system discovered in AD.  It's so that there isn't a flood of full inventory within 10 minutes in those cases.  Of course, if you're a mature installation--it's unlikely that you'll have that.  By default it is 240 minutes (4 hours)--at my company we've changed ours to 60.  To see what it is set to, here's the SQL you'd run in SQL Server Management Studio against your cm_sitecode database, just to see what yours it set at: (view only, it changes nothing.)  Each primary will have it set. (If you are unlucky to have a CAS, it will have it as well; but a CAS has no clients so it's not really relevant; but for consistency may want to change it)

SELECT SD.SiteCode, SCC.ClientComponentName, SCP.Name, SCP.Value1, SCP.Value2, SCP.Value3 FROM SC_ClientComponent SCC JOIN SC_SiteDefinition SD ON SD.SiteNumber = SCC.SiteNumber JOIN SC_ClientComponent_Property SCP ON SCP.ClientComponentID = SCC.ID WHERE SCP.Name like '%Inventory Max Random Delay%'

  To adjust the Max Random Delay, you run the below as a vbscript, after modifying the SiteCode to match the one you are changing

You run it as cscript whatever.vbs YourPrimaryServerName The3CharSiteCode  (after changing the desiredvalue and sitecode inside).  For example, if my primary site server name was "CMPRIMARY" and it's site code was PR1, I'd confirm that the sitecode in the script said "PR1" (it does, how convenient for me!), and I'd run  cscript.exe whatever.vbs cmprimary pr1

If you have multiple primaries, you need to run it on each one--it's per sitecode.

'***********vbscript below******************
'NOTE! Be careful if in displaying this on a blog, the ' or " are converted to "smart quotes" !

On Error Resume Next

'*** Define string variables for device, device Resource ID and user of interest

Class_Name = "SMS_SCI_ClientComp"
Class_ItemName = "Hardware Inventory Agent" ' "Software Inventory Agent" for SINV
Class_ItemType = "Client Component"
Property_Name = "Hardware Inventory Max Random Delay Minutes" ' "Software Inventory Max Random Delay Minutes" for SINV
Property_SiteCode = "PR1" ' Replace Site Code for Primary Site here
DesiredValue = 60 ' Desired Value in Minutes

'*** Check parameters - we need the provider server name and the site code

set args=wscript.arguments

If args.Count = 2 then
SMSProviderServer = UCASE(Wscript.Arguments(0))
SiteCode = UCASE(Wscript.Arguments(1))
wscript.Echo "Incorrect command line arguments." & vbCrLf & "Usage: cscript /nologo ModifySCFProperty.vbs <smsproviderserver> <sitecode>" & vbCrLf & "Example: cscript /nologo ModifySCFProperty.vbs SERVER1 S01" & vbCrLf
End If

'*** Connect to the provider - report the error and terminate on failure

SMSProviderServer = "\\" + SMSProviderServer + "\"
Set ObjSvc = GetObject("winmgmts:" & "{impersonationLevel=Impersonate,authenticationLevel=Pkt}!" & SMSProviderServer & "root\sms\site_" & SiteCode)

If Err.Number <> 0 Then
wscript.Echo "Failed to connect to provider server with code: " & Err.Number & ". Aborting!"
End If

'*** Get the desired instance of the class

Set objInst = ObjSvc.Get(Class_Name & ".ItemName='" & Class_ItemName & "',ItemType='" & Class_ItemType & "',SiteCode='" & Property_SiteCode &"'")

If Err.Number <> 0 Then
WScript.Echo "Failed to open desired object with error code " & Err.Number & " (" & Err.Description & "). Aborting!"
End If

'*** Loop through the Properties until we find a match or run out

bFoundProperty = False

For Each objProp in objInst.Props
If objProp.PropertyName = Property_Name Then
bFoundProperty = True
Exit For
End If

If bFoundProperty = False Then
WScript.Echo "Desired object was found but property was not found. Exiting without making any changes."
End If

'*** Property found so check to see if existing value matches desired, changing it as appropriate

If objProp.Value = DesiredValue Then
WScript.Echo "Property '" & Property_Name & "' found with desired value '" & DesiredValue & "'. Not making any changes."
OriginalValue = objProp.Value
objProp.Value = DesiredValue

If Err.Number <> 0 Then
wscript.Echo "Failed to save the desired change with code: " & Err.Number & ". Aborting!"
WScript.Echo "Property '" & Property_Name & "' successfully changed from '" & OriginalValue & "' to '" & DesiredValue & "'."
End If
End If

Issue:  After upgrading Configmgr 2012 R2 CU4 clients to ConfigMgr 2012 R2 SP1 clients, some, but not all, clients started having issues downloading content.  It seemed to only happen on clients which just so happened to be our Management Points, or our Software Update Points, so likely this particular error won't be seen much.  But in looking for the keywords of "error creating CTM job", where the error code was 0x80070003, there wasn't anything I could find via any popular search engine. 

Symptoms:  In those clients' local ContentTransferManager.log if you didn't have debuglogging enabled, it was simply this error, repeated every time a download request was attempted:

Error creating CTM job (0x80070003)

If one turned on debuglogging, you got a little bit more information, but not much:

In CContentTransferManager::DownloadContentEx7 Directory::Exists(szDestPath), HRESULT=80070003 (e:\nts_sccm_release\sms\framework\ccmctm\ctmanager.cpp,390) Error creating CTM job (0x80070003)

In those clients' local CAS.log, you'd see this error:

CcmContentTransferManager:DownloadContent failed with error 0x80070003

Diagnosis:  80070003, that error, is supposed to mean something like "the system cannot find the path specified".  We wondered if it was because many of these clients happened to be Management Points, so their installed location for the CM Client wasn't %windir%\ccm, but was <drive letter>:\SMS_CCM.  But that didn't make sense, only some of them were like that, others were in %windir%\ccm.  What it ended up being was a confused (or corrupt) ccmcache folder.

Fix:  Since this is about downloading into cache, and 8007003 is supposed to mean "can't find the path", we moved the location of ccmcache, temporarily (using the Control Panel applet).  What is "supposed" to happen is that when you do that, the former location should be automatically deleted.  That did NOT happen--so clearly something was messed up with it.  Deleted the old location manually, and then put the cache location RIGHT BACK to the normal cache location.  And then content can download.

Issue to be solved: Software Inventory (which is really FILE inventory) you've noticed takes FOREVER when you define a rule like "dropbox.exe on c:\users\", the clients take several minutes to run that query.  and the more rules you make, the longer it might take your clients to run software inventory.

Resolution:  whenever possible, forget creating software (file) inventory rules.  This blog post will show how to setup a rule looking for dropbox.exe on c:\users\, and you can get back File Version so you can run reports.

Take the attached --> here <-- and import it into your console, Configuration Items.  Create a Baseline and deploy that Baseline to a target collection.  What should happen is if the file dropbox.exe is in c:\users\ somewhere, those boxes will report non-compliant, and will report the Fileversion, and path location, where dropbox.exe is located.

Why I used dropbox.exe... dropbox.exe may not be listed in Installed Software, nor in Add/Remove Programs.  It might be listed in ccm_recentlyusedapps.  Using this as a sample, after you've deployed this, run this .sql query to see which computers, the version, and path.

  perclientDetails.InstancePath as 'Found In'
v_localizedciproperties ci
join vDCMDeploymentNonCompliantRuleDetailsPerClientMachine perclientDetails
 on perclientdetails.ci_id=ci.ci_id
join v_CIRules rooles on rooles.rule_id=perclientdetails.rule_id
join v_r_system s1 on s1.ResourceID=perclientDetails.ItemKey
  ci.displayname = 'File Inventory Dropbox.exe'
 ci.localeid = 1033
order by s1.Netbios_Name0

One interesting caveat: every time you change a ConfigItem (add something) the vDCMDeploymentNonCompliantRuleDetailsPerClientMachine will "reset", so if you don't want to "lose" history, you'll want to likely simply make more CIs.  Not edit existing ones.

This sample was to show you can get version of any dropbox.exe file, for reporting purposes.  If, for example, what you really need to be able to do is create a collection of "machines where widgets.exe located in c:\program files\widgets is less than version", then make a ConfigItem for widgets.exe, in that folder, and "compliant" means version is greater than or equal to  You can then easily right-click the CI and make a collection of Non-Compliant machines.

I encourage you to test it out for yourself; and see how quickly on a client a CI runs; vs. software file inventory for the same file.