pxedave

Hey, thanks for your suggestion. You're right. That would work and is slightly more transparent than simply deploying the uninstall to All Systems and letting the client fight it out. However, talking to a pal in another organisation who went down the same route, they moved away from it because deployment stats against every client showed 600+ permanent uninstalls alongside installs plus the extra unnecessary load on every client. Plus, that very real risk of an accidental site-wide uninstall. For now, we are going to include a custom Exe in every package with a standard naming convention (Manufacturer_Product_version_pkgversion.exe) and base our uninstall collections on these exes (whilst, as you suggest, excluding the install collection). This will also allow us to report on where our packages are installed more reliably than the SMS_G_System_AppClientState query, which, as you said, only returns where products were deployed, not where packages actually are...

We are deploying 600 applications to device collections, one per app. We want sccm to automatically uninstall applications if they're not being deployed to them regardless of how they got there... I remember reading that an install takes precedence over an uninstall so rather than have 600 uninstall collections/queries I should just permanently deploy an uninstall of everything to All Systems and the install deployments should overrule until a device is removed from a collection? I'm guessing the downside is that we'll briefly see hundreds of uninstalls in Software Centre / always see every uninstall deployed against every device in the console. PS. Another downside is that if EVER the install deployment is deleted but the uninstall deployment is accidentally left behind, you'll automatically uninstall software from everywhere = not good.

Hmmm. What I really want is for the software to be detected and automatically uninstalled if the device isn't in the install collection. I was thinking just deploying an uninstall to a collection that is based on the above query (and is set to exclude the install collection) would do it but this wouldn't cater for applications that are installed manually i.e. not deployed, correct? If so, would a logical solution be to deploy an uninstall of everything to everything knowing this will force the client to check for every application regularly (I'm assuming that's what would happen) and that the install will overrule the uninstall? Any thoughts? Right now I'm wondering if my original plan to make my uninstall queries based on hw/sw inventory (on an exe in the package etc) rather than using SMS_G_System_AppClientState is more efficient...

Interestingly, the above device is now in the list when I run the query... all I did was deploy the application to it "Available" and let it detect that the package is there. It's as though there's a risk that the device isn't being counted as having an application unless the software is actually specifically being deployed to it outside of a task sequence? But some of our applications that haven't been deployed outside of the TS show a correct count. Strange...

Further to this, I just deployed the example app to the device (Available) and the local AppDiscovery.log sees that the detection method is already present on the device... so what could be stopping the device from being included in the "Devices with Application" count/query? +++ Discovered MSI application [AppDT Id: ScopeId_E158B7D5-98D9-4669-A16D-FBF03B8FA92B/DeploymentType_7fff4bcb-a967-45d1-a63c-f91c0973741e, Revision: 2, MSI Product code: {743BBC0D-B119-4175-9EAC-555AD23BD582}, MSI Product version: ] AppDiscovery 17/05/2016 15:11:42 6460 (0x193C)

Folks, Today we noticed that the "devices with application" statistic against many of our packages looks far too low. The example application I'm currently looking at has been in our base OSD task sequence for some time and yet devices even recent devices are not showing up in this count. (I'm using an SMS_G_System_AppClientState.ComplianceState / SMS_G_System_AppClientState.AppName query to see a list of devices with this app). I'm expecting to see thousands of devices as having this application and yet only 1,300 are showing in the console / this query. The detection method of this app is just an MSI code and it's definitely present on devices not in the count. The MSI code is also present in Resource Explorer for these devices. Any ideas?

... Even if it was only a 2Mb pre-stage, across our 10,000 PC's... 2 x 10,000 = 20,000Mb = 20Gb...

Folks, My first experience with Automatic Client Upgrade (post R2 SP1) is not a good one... After enabling this in live, even with the maximum 31 day upgrade window, our Primary server jumped to 95% network utilisation - things returned to normal shortly after disabling it. Following a brief investigation this morning I think I know why... OK, we were expecting Scheduled Tasks to be created across all our clients on day one. What we didn't expect was that client source would be pre-staged to the PCs at the same time! To add insult to injury, as this deployment doesn't employ the usual caching methods the 1E Nomad software we use to reduce server load was bypassed too... For now we are going to use the old right-click-a-collection-and-reinstall-client method to deploy it gradually ourselves. What's the point in being able to increase the window to 31 days if the server is going to push client executables to every PC on day one? I still find it hard to believe it works like this but this is what I'm seeing. Note, only ccmsetup.exe is mentioned in the log but I saw an up-to-date 27Mb MSI in the same folder... Anyway, see the log snippet below. 'Configuration Manager Client Upgrade Task' is scheduled to run at 06/27/2015 12:10:38 PM (local) 06/27/2015 11:10:38 AM (UTC) time with arguments ' /AutoUpgrade /UpgradePackageVersion:14 /UpgradeWinTask'. ccmsetup 17/06/2015 14:29:38 5656 (0x1618) ITaskService::GetFolder failed with 0x80070003 ccmsetup 17/06/2015 14:29:38 5656 (0x1618) Params to send '5.0.8239.1000 Deployment Scheduled Time(UTC): 06/27/2015 11:10:38 AM' ccmsetup 17/06/2015 14:29:38 5656 (0x1618) Sending message with STATEID='102' via the existing client. ccmsetup 17/06/2015 14:29:38 5656 (0x1618) Adding client deployment state message. ccmsetup 17/06/2015 14:29:39 5656 (0x1618) <ClientDeploymentMessage ErrorCode="0"><Client Baseline="1" Platform="1"/><Packages><Package ID="{DC61B2DE-E38E-498E-95B3-4BEF3657482E}"/></Packages><Additional><UpgradeSchedule Value="06/27/2015 11:10:38 AM"/></Additional></ClientDeploymentMessage> ccmsetup 17/06/2015 14:29:39 5656 (0x1618) Successfully deleted existing ccmsetup.exe ccmsetup 17/06/2015 14:29:40 5656 (0x1618) Downloading file C:\WINDOWS\ccmcache\8j\ccmsetup.exe ccmsetup 17/06/2015 14:29:40 5656 (0x1618) Downloading C:\WINDOWS\ccmcache\8j\ccmsetup.exe to C:\WINDOWS\ccmsetup\ccmsetup.exe ccmsetup 17/06/2015 14:29:40 5656 (0x1618) File download 15% complete (262144 of 1738424 bytes). ccmsetup 17/06/2015 14:29:41 5656 (0x1618) File download 30% complete (524288 of 1738424 bytes). ccmsetup 17/06/2015 14:29:41 5656 (0x1618) File download 45% complete (786432 of 1738424 bytes). ccmsetup 17/06/2015 14:29:41 5656 (0x1618) File download 60% complete (1048576 of 1738424 bytes). ccmsetup 17/06/2015 14:29:41 5656 (0x1618) File download 75% complete (1310720 of 1738424 bytes). ccmsetup 17/06/2015 14:29:41 5656 (0x1618) File download 90% complete (1572864 of 1738424 bytes). ccmsetup 17/06/2015 14:29:41 5656 (0x1618) File download 100% complete (1738424 of 1738424 bytes). ccmsetup 17/06/2015 14:29:41 5656 (0x1618) Download complete. ccmsetup 17/06/2015 14:29:41 5656 (0x1618) CcmSetup is exiting with return code 0 ccmsetup 17/06/2015 14:29:41 5656 (0x1618)

Hi, sorry, yes I want to know what app-v apps are installed where rather than which machines have the client. You say I can use the default reports in the Virtual Application folder but the inventory reports appear to be for 4.6 only, or am I missing something? See https://technet.micr...px#BKMK_Monitor (under Virtual Application Reports)

Folks, Is it me? I can't find any built-in SCCM reports that shows me where App-V version 5 applications are installed. Under "Virtual Applications", the 3 reports that start "App-V" seem to relate to the "environment" (which I haven't setup yet because, as for as understand, I only need to do this when I need apps to talk to one another) and the other 4 reports seem to relate to 4.6 and not 5. I confirmed this here https://technet.micr...px#BKMK_Monitor (under Virtual Application Reports). I can confirm that App-V 5 apps are listed in Resource Explorer under "Hardware - AppV Client Package" where approporiate so clearly SCCM has the inventory data on these. I just can't see how to report on this...

Folks, Is it me? I can't find any built-in SCCM reports that shows me where App-V version 5 applications are installed. Under "Virtual Applications", the 3 reports that start "App-V" seem to relate to the "environment" (which I haven't setup yet because, as for as understand, I only need to do this when I need apps to talk to one another) and the other 4 reports seem to relate to 4.6 and not 5. I confirmed this here https://technet.microsoft.com/en-us/library/jj822982.aspx#BKMK_Monitor (under Virtual Application Reports). I can confirm that App-V 5 apps are listed in Resource Explorer under "Hardware - AppV Client Package" where approporiate so clearly SCCM has the inventory data on these. I just can't see how to report on this...

Hi and thanks, Glad the install would win. Chatting with the guy who is piloting the solution I outlined, workstations display all the uninstalls in Software Centre the first time they are built (obviously) but then things clear up quite quickly once the clients work out what's actually installed / not installed. Regarding restricting the uninstall collections down to only primary users whos machines have the software, I can see how that would help. Much easier for those targetting devices rather than users. I'm hoping someone might help us all out by posting up an example query, as that's beyond anything I've done thus far. Surely I'm not the first to be asking for something like this(?) Maybe UDA wasn't as widely embraced as I thought it would be?

Folks, Two years ago we started deploying all our software via permanent user collections (using UDA). This has done a good job of ensuring that all users have the software they need. However, of course, because removing a user from a collection doesn't automatically remove the software we now have machines with software the user no longer needs, and I'm sure we wont be the only ones with this problem. I've heard of one organisation getting around this by permamnently deploying uninstalls to collections that are a reverse of the deployment collections, but I have a couple of issues with this: 1. I can see this would work of device collections, but what about user collections / UDA ? I.e. What would happen if a device had both an uninstall and an install deployed to it because it had a primary user in both the install and uninstall collection? I'd hope the install would win? 2. I wonder how well this would scale? I can see this working on a small scale but we have 600 application deployments / 10,000 users. We wouldn't want to uninstall everything we deploy but I can see we could end up with at least 1000 deployments in total... Anyone any thoughts or experience on doing anything like this? I'm also waiting on Microsoft's input on this so we'll see what they say. Dave

Hi Peter, It's a strange one alright. Note, the GUI is built this way to allow for the definition of more complex products; short of reverting to a Script install it's the only way to define an Application made up of multiple MSI files, something we have dozens of: Adobe, Oracle, Vodafone etc...

Hi folks, Here's another one that got us today that's worth keeping in mind. If you have an Application which has, let's say, two Deployment Types, the first (priority 1) is configured to auto-install the second (as specified in the Dependancies tab). If you then make this application Available (i.e. not even Required) to a device, as expected it will appear as Available within Software Centre and do nothing until you hit Install... UNLESS the machine happens to meet the requirements of the Detection Method of the first Deployment Type in which case it will AUTOMATICALLY INSTALL THE SECOND DEPLOYMENT TYPE WITHOUT WARNING :angry: This will happend regardless of whether the application is deployed via Task Sequence or on its own. If you're in the habit of using Available deployments as we are, best make sure your Detection Methods in all Deployment Types are unique. I'd say this is similar to the issue that bit us earlier around supercedence causing Available applications to auto-uninstall superceded packages without warning ( http://www.windows-noob.com/forums/index.php?/topic/8952-possible-bug-in-sp1-cu1-client-applications-that-supersede-others-may-rollout-unexpectedly/?p=33797 ), both of which I'd call a bug rather than a feature.