Jump to content


pxedave

Established Members
  • Content Count

    63
  • Joined

  • Last visited

Community Reputation

0 Neutral

About pxedave

  • Rank
    Advanced Member
  1. 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
  2. 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 u
  3. 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 t
  4. 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...
  5. 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)
  6. 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
  7. ... Even if it was only a 2Mb pre-stage, across our 10,000 PC's... 2 x 10,000 = 20,000Mb = 20Gb...
  8. 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 us
  9. 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)
  10. 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 Packag
  11. 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
  12. 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 t
  13. 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 wit
  14. 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...
  15. 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 SE
×
×
  • Create New...