How to get history of application deployment status??

Question

_{Friday, January 13, 2017 2:03 PM}

Hi Guys,

I need to know how to get the history of application deployment in SCCM?

Likewise in package deployment, we get the entire history of package deployment status on the targeted machines irrespective machines in collection or moved out (dynamic query).

However, in application deployment we do not have any such options. As the machines move out of targeted collection, the machine is moved out of the reporting as well. We get the status of machines only till the machines is available in collection (dynamic query).

Suppose, if someone need the application deployment status (machines)of an application after 2-3 weeks later and meanwhile we do not have the any machines in the collection (dynamic query), what we get is an entire empty report. In such case, how do we say how many machines it was targeted and success on it?

System Security analyst at CapG

All replies (13)

_{Friday, January 13, 2017 2:16 PM}

Not an answer really, but why are you moving the systems out of the collection (dynamic or static)? The whole point of the application model is to represent the state of an application and thus deployments enforce your intent that an application should (or should not) be installed on systems within the collection. Thus, moving them out serves no purpose as it removes your intent and thus in turn removes you ability to track your intent. 

Jason | http://blog.configmgrftw.com | @jasonsandys

_{Friday, January 13, 2017 2:41 PM}

Hi Jason,

We have dynamic query checks whether applications installed on the machine and part of a security group. The local team adds just machines to these groups, this is to avoid direct access to sccm console for the local team.

Question is when we can have the same thing working for packages, then why not for applications? To get the history of any deployments. 

Any alternatives to get this is also appreciated.

System Security analyst at CapG

_{Friday, January 13, 2017 2:44 PM}

Because packages and applications are different and deploying them ultimately is different. As noted, deploying an application defines intent. ConfigMgr tracks the enforcement of that intent but if you remove that intent, it no longer tracks it.

Same question though, why are the systems being removed from the group?

Jason | http://blog.configmgrftw.com | @jasonsandys

_{Saturday, January 14, 2017 5:57 AM}

You could create another dynamic collection where only the clients with the same application installed become members, so basically as the clients exit the first collection upon successful installation, they become members of your second collection where you can also deploy the same application for monitoring purposes only. This work around should do the trick but caution should be observed if the target clients are in thousands to avoid unnecessary policy replication.

_{Sunday, January 15, 2017 2:52 PM}

Hi Jason,

No, we do not remove them machines from the group.

1 application- 2 collections - Install/ Uninstall dynamic queries. Add machine to the groups, app installs. Remove from the group, app uninstalls. This is to avoid direct access to the console for the L1 guys. 

System Security analyst at CapG

_{Sunday, January 15, 2017 3:08 PM}

Hi Qamar,

Can't take this as an alternative.

We have environment with ~4500 packages/ apps, each with  install/ uninstall collections. Adding more collections will add to overhead of the evaluation

System Security analyst at CapG

_{Sunday, January 15, 2017 3:33 PM}

All you need is one dynamic collection, where you can modify the collection query for every application that you'd like to track the deployment status, deploy the app, and you get your reports for the specific deployment of your choice for one collection.

_{Sunday, January 15, 2017 3:46 PM}

This is a current discussion I'm having with people on my team as well. There is really no way to do this within SCCM as it's not designed to track historical data in relation to applications or software updates. 

Essentially what you are running into is something Configuration Manger does to preserve space, as well as a feature change that occurred between SCCM 2007 and SCCM 2012/Current Branch. 

Within the packaging model, SCCM tracked the status of if a program had run as that was how it would determine IF it needed to run the program again. However, within the application model they shifted towards using the detection method to track if an application was present on the machine or not. 

What your're saying in this post is 100% contradictory: 

"Suppose, if someone need the application deployment status (machines)of an application after 2-3 weeks later and meanwhile we do not have the any machines in the collection (dynamic query), what we get is an entire empty report. In such case, how do we say how many machines it was targeted and success on it?"

Here you imply you have a collection that if the software is installed it falls out of the collection, meaning the software was deployed and it no longer needs to be in there leveraging a dynamic query of some sort that is dependent on data in SQL. 

Second:

"No, we do not remove them machines from the group.

1 application- 2 collections - Install/ Uninstall dynamic queries. Add machine to the groups, app installs. Remove from the group, app uninstalls. This is to avoid direct access to the console for the L1 guys. "

You state right here we don't remove machines from the group, but then say you're adding them to and removing them from a group? When you say group I'm assuming you mean AD group, but then it sounds like you're talking about a collection above. 

So, let's get back to your original question:

Is there a way to track to what machines an application has been deployed, if they are no longer a member of the collection that is targeted by a deployment, or the deployment has been deleted?

To my knowledge no, once the machine leaves the collection it is no longer included as part of deployment summarization data and is deleted.

How do we work around this? Simple by requiring management to give us a better definition of the end goal. Does this software need to be present on 20 machines? Good put those 20 machines in an A.D. Group, deploy it and when it reaches 100% compliance generate a report that shows this submit it to management and clean up the collection and content. 

Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question, please click "Mark As Answer"

_{Sunday, January 15, 2017 4:22 PM}

hi Jordan,

Thanks for the post. 

First, yes, by groups i mean the AD groups (used in the dynamic query) and not the collections. 

Pretty difficult to set a goal. I assume, historical data always helps to sort/ understand things. We have 70K workstations. If i need produce a history of deployments for 100's applications how do i show it to the management?

This was very much possible in packages, where i would show 'N' packages deployed on 'M' number of machines successfully, same expectation is from apps as well which am afraid is not possible :-(.

Even if i get the summation of how many targeted, success, failed etc.. should be the least expectation.

System Security analyst at CapG

_{Sunday, January 15, 2017 4:34 PM}

I understand completely. I'm coming from an organization of about 150K endpoints, 138K workstations and about 12 - 15K servers and reporting is something we are CONSTANTLY fighting with management. 

"Even if i get the summation of how many targeted, success, failed etc.. should be the least expectation."

You can get that information provided the original "scope" of the deployment is present and has not changed. Unfortunately if stuff falls out of the collection changes etc, you're going to lose some of that data it's just the way of the application model. 

Fortunately/Unfortunately the application model is a very different animal, but lets take a look at why that information isn't stored. Let's imagine for a brief moment, that we save ALL of that information, every deployment to every machine and the status that was reported, can you imagine how much data that would be for an environment of 150K machines? How about 400K? That's a  LOT of data, you would practically need a data warehouse like SCOM for it. 

What's the business drive for this report on historical data? Are they just looking to see what's installed where? Are they trying to figure out who did what? Is management just looking for a baseline of the environment? These are all questions I ask when I get what appear to be frankly asinine reports on the environment from pretty much anyone at any org I work at/consult for. 

Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question, please click "Mark As Answer"

_{Sunday, January 15, 2017 5:15 PM}

So then what exactly are you not getting? Are you really after a report that shows the application being installed, then uninstalled, and installed again, etc.?

Jason | http://blog.configmgrftw.com | @jasonsandys

_{Sunday, January 15, 2017 5:15 PM}

Then how was the package details history, details stored?

Does it mean, 2012 apps deployment one intention was to get rid of history data, in order to save the space??

Anyways, with all this i understand that apps history is not possible unless until machines in collections.

Lets see if i can get the MS to convince the management on the same. 

But it disappointing on unable to report details of what we have deployed, anytime.

System Security analyst at CapG

_{Sunday, January 15, 2017 5:20 PM}

As has been mentioned multiple times, they are different things so using what you can do for one as the basis of an expectation for the other is invalid.

You absolutely can report on what you have deployed.

What exactly is your business goal here?

Why aren't you using Asset Intelligence?

Jason | http://blog.configmgrftw.com | @jasonsandys