User based uninstall collections - Dynamic

Question

Hi Guys,
I have been looking for sometime at how User based uninstalls are done and I see that mostly people do an Exclude on the collection and deploy an uninstall to basically everyone who DOESNT have the application deployed to them. The issue with this is
if you have a high number of apps (500 lets say) you deploy 400 either uninstall or install deployments to everyone which dramatically slows down deployment of apps on new machines etc.
With APP-V the queries are fairly straight forward and we have dynamically changing uninstall collections that only show users that have the app for them in a compliant state on a workstation in the estate, when they are fully unpublished they drop
out of the collection based on compliance state.
I am trying to achieve the same method for uninstall collections where physical installs are used. Unfortunately there isn't a class like the APP-V AppClientState for Physical apps, or from what I can see at least and just wanted to see if anyone had
achieved uninstall collection for physical apps in a more dynamic way than doing Include/Exclude on the collections which I see as very static and uneconomical.
Many thanks,
Adam

Answer 1

Hi Hican, Torsten,
Thanks both for your replies. below is the query i have used. I'll just be clear that this may not suit a lot of environments because of users moving around etc.
select SMS_R_USER.ResourceID,SMS_R_USER.ResourceType,SMS_R_USER.Name,SMS_R_USER.UniqueUserName,SMS_R_USER.WindowsNTDomain from SMS_R_User where uniqueusername in (select distinct SMS_G_System_SYSTEM_CONSOLE_USAGE.TopConsoleUser from SMS_G_System_ADD_REMOVE_PROGRAMS INNER JOIN SMS_G_System_SYSTEM_CONSOLE_USAGE ON SMS_G_System_SYSTEM_CONSOLE_USAGE.ResourceID=SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID WHERE SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = '<ARP DISPLAYNAME>' and TopConsoleUser not in (Select SMSID From SMS_CM_RES_COLL_XXXXXXX))
This query basically finds all workstations with a specific Display name in ARP, it then looks at the topconsoleuser in the SystemConsoleUsage class for that workstation. The User resource is then pulled back based on that username and the uninstall is deployed
to the user alongside the install.
When the machine tied to that user no longer has that software installed the user drops out of the collection. I have these collections scheduled to do an update overnight at random intervals.
You will note at the end i use a "NOT IN" clause so i can exlude specific accounts from being included in the uninstall collections. The reason for this is we have a couple of service accounts that gets used heavily in various places
and end up getting registered as the top consoleuser in some instances. This is put in as a safeguard.
the only bits in the query that change is the <DisplayName> section which is what gets added in ARP.
SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = '<ARP DISPLAYNAME>'
Again you need to be careful here as a program may have the same displayname as another if it hasnt been versioned correctly. in this case it may be better to use another attribute such and Product GUID.
Lastly if you choose to have an exclude collection like myself the collection Class will also need amending:
and TopConsoleUser not in (Select SMSID From SMS_CM_RES_COLL_XXXXXXX)
Somone may say there is an issue with doing it this way. obviously if users roam a lot you could end up stripping software off peoples machines which is why i say it may not suit some environments but this goes quite well where we are.
Some users may also not show if they are not yet registered as the TopConsoleUser of their workstation yet as this is a 3 month calculation (if i remember rightly). If this is being put in with a new not yet deployed app it looks clean from a returned list
of users standpoint, if however you have an estate where applications have never been unstalled and workstations have changed hands, initially you will see a lot of users in the uninstall collections which werent in the install. These applications will uninstall
for them and they will drop out of the collections.
Hican, like i said adding the software metering part in to the above query could prove even more economical as the uninstall deployment wouldn't actually be deployed if the software was active. If i get a chance i will look at this.
Hopefully the above makes sense, obviously this is just my take on how to do some uninstall collections and if somone decides to try it they are doing so at their own risk. retrofitting uninstalls is painful and risky.
Thanks,
Adam