Hi,
I have been tasked with checking non compliance of "critical" applications in our very large (100k+) estate.
Our compliance rates are superb, 98.5%+ - but the higher ups still want decent effort upping that (1.5% of 100k is still 1500 so, reasonable amount of non compliant devices)
One pattern/clue for around 250 devices is that they all erroneously show
ActionType - Install will use Content Id: Content_*ID* + Content Version: 1 for AppDT "*sccmApp*" [ScopeId_*ID*/DeploymentType_*ID*], Revision - 6
ActionType - Install will use Content Id: Content_*ID* + Content Version: 1 for AppDT "*sccmApp*" [ScopeId_*ID*/DeploymentType_*ID*], Revision - 6
ActionType - Install will use Content Id: Content_*ID* + Content Version: 1 for AppDT "*sccmApp*" [ScopeId_*ID*/DeploymentType_*ID*], Revision - 6
Spammed - its one specific app/policy that seems to have corrupted a few clients.
I've now got rid of this from SCCM and when checking device WMI, the policy is gone.
However... when re-running all policy cycles/Actions on clients, I get the...somewhat evidence lacking...impression it is not then proceeding to process application deployment policies as if they are new.
For example I do not see the application ID appear in PolicyAgent.log
I do not see it appear in Appdiscovery.log (which..another issue is... is horrendously spammed with gosh dern USER BASED Virtual environment lines, some of the desktops have 25 users and 25 policies per user...slow going)
I *DO* see it in AppIntentEval.log as
ScopeId_*ID*/DeploymentType_*ID* :- Current State = NotInstalled, Applicability = Applicable, ResolvedState = Installed, ConfigureState = NotNeeded, Title = *appname*
But then I *DO NOT* see it proceed to be raised in AppDiscovery.log (I'd expect something like....)
ActionType - Install will use Content Id: Content_*ID* + Content Version: 1 for AppDT "*Appname*" [ScopeId_*ID*/DeploymentType_*ID*], Revision - 5 AppDiscovery 14-08-2015 06:05:06 2912 (0x0B60)
I know re-installing the client will fix this, i've piloted it on 10 devices - but I've sledge hammered this stuff far too often and want to get a better understanding of it/a sleeker way to force a device to restart application deployment policy process over regardless where it *thinks* it is up to.
If I delete the desired application policy from the client WMI with this
Get-WmiObject -ComputerName 'Device' -Class "CCM_Policy" -Namespace "ROOT\ccm\Policy\Machine\ActualConfig" | where {$_.AssignmentName -eq *APP*} | remove-wmiObject
and re-run CM actions, will that force it to come through "as new" again? is that the right approach?
I just feel like the "broken" client is treating incomplete deployments as .... if they are moving through as usual (but they aren't - they are stuck/not following the usual steps through the logs) and the client see's no reason to start it over - even after me removing the toxic app deployment policy (by deleting the app/running cycles on the target collection) that seemed to be affecting 250+ devices.
Happy to be educated on the matter explicitly (i.e. whats going on above) or in whatever approach is best (new way to handle it), even happier if someone can educate me on the best way to ask a device to re-run a deployment without having to create a new deployment/re-install client.
Thank you
I have been tasked with checking non compliance of "critical" applications in our very large (100k+) estate.
Our compliance rates are superb, 98.5%+ - but the higher ups still want decent effort upping that (1.5% of 100k is still 1500 so, reasonable amount of non compliant devices)
One pattern/clue for around 250 devices is that they all erroneously show
ActionType - Install will use Content Id: Content_*ID* + Content Version: 1 for AppDT "*sccmApp*" [ScopeId_*ID*/DeploymentType_*ID*], Revision - 6
ActionType - Install will use Content Id: Content_*ID* + Content Version: 1 for AppDT "*sccmApp*" [ScopeId_*ID*/DeploymentType_*ID*], Revision - 6
ActionType - Install will use Content Id: Content_*ID* + Content Version: 1 for AppDT "*sccmApp*" [ScopeId_*ID*/DeploymentType_*ID*], Revision - 6
Spammed - its one specific app/policy that seems to have corrupted a few clients.
I've now got rid of this from SCCM and when checking device WMI, the policy is gone.
However... when re-running all policy cycles/Actions on clients, I get the...somewhat evidence lacking...impression it is not then proceeding to process application deployment policies as if they are new.
For example I do not see the application ID appear in PolicyAgent.log
I do not see it appear in Appdiscovery.log (which..another issue is... is horrendously spammed with gosh dern USER BASED Virtual environment lines, some of the desktops have 25 users and 25 policies per user...slow going)
I *DO* see it in AppIntentEval.log as
ScopeId_*ID*/DeploymentType_*ID* :- Current State = NotInstalled, Applicability = Applicable, ResolvedState = Installed, ConfigureState = NotNeeded, Title = *appname*
But then I *DO NOT* see it proceed to be raised in AppDiscovery.log (I'd expect something like....)
ActionType - Install will use Content Id: Content_*ID* + Content Version: 1 for AppDT "*Appname*" [ScopeId_*ID*/DeploymentType_*ID*], Revision - 5 AppDiscovery 14-08-2015 06:05:06 2912 (0x0B60)
I know re-installing the client will fix this, i've piloted it on 10 devices - but I've sledge hammered this stuff far too often and want to get a better understanding of it/a sleeker way to force a device to restart application deployment policy process over regardless where it *thinks* it is up to.
If I delete the desired application policy from the client WMI with this
Get-WmiObject -ComputerName 'Device' -Class "CCM_Policy" -Namespace "ROOT\ccm\Policy\Machine\ActualConfig" | where {$_.AssignmentName -eq *APP*} | remove-wmiObject
and re-run CM actions, will that force it to come through "as new" again? is that the right approach?
I just feel like the "broken" client is treating incomplete deployments as .... if they are moving through as usual (but they aren't - they are stuck/not following the usual steps through the logs) and the client see's no reason to start it over - even after me removing the toxic app deployment policy (by deleting the app/running cycles on the target collection) that seemed to be affecting 250+ devices.
Happy to be educated on the matter explicitly (i.e. whats going on above) or in whatever approach is best (new way to handle it), even happier if someone can educate me on the best way to ask a device to re-run a deployment without having to create a new deployment/re-install client.
Thank you
