Jump to content


pxedave

Established Members
  • Posts

    63
  • Joined

  • Last visited

Posts posted by pxedave

  1. You're right in saying that could go horribly wrong if the install was deleted and the uninstall wasnt.

     

    Why not do something like this:

     

    Collection A - Install (add all the machines you need software deployed to here and deploy the install)

     

    Collection B - Uninstall (this collection will contain all system but EXCLUDE Collection A - deploy the uninstall here)

     

     

    Example:

     

    You have a sccm site consisting of 20 machines

     

    Adobe Flash - Install (10 members)

    Adobe Flash - Uninstall (add the "Adobe Flash - Install" as a exclude rule and then just include the "all systems" collection (or whatever you feel is best)). Then deploy the uninstaller here.

     

    Any members of "Adobe Flash - Install" will get the software installed.

    Any members of "Adobe Flash - Uninstall" will get the software uninstalled

    One day you decide to remove 5 machines from "Adobe Flash - Install", this will mean they then end up in "Adobe Flash - Uninstall" as they are no longer members of the collection that was excluded

     

    Mind you, im sure there are better ways of doing this. I have setup a auto-uninstall mechanism however that's for licensed software and we are using metering. Anyone who hasn't used software "X" in 90 days will get it auto uninstalled.

     

    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...

  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 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.

  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 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...

  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 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?

  7. 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)

     

     

  8. are you trying to identify the computers that have app-V version 5 installed ? or identity what app-v apps installed on computers ? you tend to combine both here ?

    to know computers that have app-v version 5 installed,you can check other report called computers with specific program installed .if you want to know what app-v apps installed ,then you can refer the default reports at virtual application folder.

    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)

  9. 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...

  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.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...

  11. 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? :(

  12. 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

  13. Well, we also ran into the supersedence bug some time ago.

    According to your actual problem i would say that you are absuing the application model and found a bug that should be not even possible. The app model was never designed for a deployment type to be able having another deplyoment type of the same application as dependancy. A Computer should be only able to install a singel deplyoment type of an application at all. So it's a logic error in the console wizard allowing you to chain two deplyoment types.

     

    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...

  14. 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.

     

     

  15. OK, Premier Support can reproduce this problem, confirm that there is no fix for this in R2 and also agree that this is not the best design. See their response below. In the meantime we are changing our procedures to make less use of superseed in the console, especially for anything included in our Task Sequences. Just to clarify, using superseed is fine when deploying Required deployments; the problem only appears when deploying software (individually or using a Task Sequence) using Available (and only to device collections, we believe)....

     

    "I just wanted to keep you informed that this Issue is by Design as we are not able to change “Automatically upgrade any superseded version of this application” in UI when an App is targeted to Computer, As we are Deploying Application Via Task Sequence so at the background we have this option selected because of which Superseded versions of Applications are getting upgraded Automatically though Deployment setting Action is set to Available

    http://technet.microsoft.com/en-us/library/gg682082.aspx

    “Automatically upgrade any superseded version of this application – If this option is selected, any superseded versions of the application will be upgraded with the superseding application

    I agree this is not a Good Design and already a Design Change Request(DCR) was filed for this Issue which is postponed for now and may be consider for future products, We had a very similar Bug but not the same Bug where Applications were getting Installed Automatically which is fixed in CM12R2 however as per my testing and discussion with Product group and Escalation Team this Issue is by Design.

    I have marked this case against an Existing Bug and there will be no charges to your account for this case"

  16. Folks,

     

    You'll like this.

     

    We were wondering why two packages recently uninstalled themselves from all our PCs without any warning. Eeak! It took a bit of digging but we discovered that currently (SP1 CU1), when you “supersede” an application with another, if the superseding (i.e. newer) application is then added to a Task Sequence and this Task Sequence is then made “Available” to a PC that has the superseded application installed, the client will automatically try and perform the upgrade shortly afterwards! Because our application happened to require a reboot before the newer version would installed, the first sign we got that something was wrong was when our users started reporting that the application had disapeard. Oh what fun!

     

    Here’s what we did to replicate the problem:

     

    a) Created application A and installed this on a PC.
    B) Created application B and specified that this supersede application A (ticking the Uninstall option in the Supersede tab).
    c) Created a new Task Sequence that includes only application B and made this Available to the PC.

    d) The client will uninstall application A and install package B shortly afterwards.

     

    The CCM client log AppIntentEval.log finally gave us the tip-off as it not only goes to the trouble of listing all applications within an available Task Sequence with each policy refresh, but it also reports the supersede uninstall/install.

     

    I can’t find any documentation that warns that making an application Available via a Task Sequence (or even via a direct deployment but I haven’t tested that far) might trigger the automatic upgrade of any superseded applications, but I can't see how this should be default behaviour. I've raised an incident with MS so let's see what they say...

     

    Dave

  17. Folks,

     

    Long story short, I have 600 applications and 600 matching AD groups which I will use to target my apps to specific users. I had planned to create 600 matching User Collections, each collection querying it's specific matching AD group, deploy each app to the matching user collection and away we go. However, when discussing this with someone in Microsoft who knows much more about this product than me, he suggested I simply target all my applications to all systems and then create a Requirement within the Deployment Type in each Application limiting the installation of that app to the specific AD group.

     

    What I think I like about this:

    - Requirement rules and global conditions are processed by the client, therefore you don't have to wait for layers of collections to update according to their schedules before an app can be delivered.

     

    What I think I don't like about this:

    - You're deploying to all systems every time. You get a warning every time you setup every deployment that you are distributing to everything (?) which is not only unnerving but you also can't easily see what you've targeted.

    - Even after reducing the risk by running a Deployment Simulation before a big rollout, you'd have to be really careful when modifying your requirement rules in the future as you could very easily deploy your app to every device by mistake.

    - I see that a client reevaluates requirement rules only once every 7 days by default (see client setting) but surely I want to add a user to a group and have that arrive within a few hours rather than a week (?).

     

    Has anyone else got this far / decided which approach they will use and why / seen any other blogs relating to this?...

  18. OK since replacing my SCCM 2012 RC1 server with RC2 I happened to try this again (a remote client push to a machine which has SMS 2003 client installed) expecting it to fail... but it worked. The log file (c:\windows\ccmsetup\ccmsetup.log) shows that the old client was detected but now it says it is going to continue with the upgrade (although it does state this is unsupported, probably because SMS is so old). I'm going to get a cup of tea to celebrate and try this again just to make sure :)

  19. We're trying to use Software Update Point-based installation and it appears that the uninstallation of SMS 2003 works... Doing some more tests to validate this.

     

    Anybody else tried this?

     

     

    <![LOG[Current client version '2.50.4253.3000' doesn't meet the minimum in-place upgradable version '5.00.7685.0000'.]LOG]!><time="00:24:48.996+480" date="02-27-2012" component="ccmsetup" context="" type="1" thread="2860" file="msiutil.cpp:638">

    <![LOG[upgrade code '{252DA259-82CA-4177-B8D0-49C78937BA3E}': product = '{4A39A27F-005B-407E-8CF5-F4D8065658E4}', installed = 1, version = 2.50.4253.3000]LOG]!><time="00:24:52.386+480" date="02-27-2012" component="ccmsetup" context="" type="0" thread="2860" file="msiutil.cpp:1242">

    <![LOG[A SCCM client with version '2.50.4253.3000' is detected. It's smaller than the minimum upgradable version '5.00.7685.0000' so current client will be uninstalled.]LOG]!><time="00:24:52.386+480" date="02-27-2012" component="ccmsetup" context="" type="1" thread="2860" file="util.cpp:451">

    <![LOG[source location is not under software distrubtion cache folder. No need to back up source.]LOG]!><time="00:24:52.401+480" date="02-27-2012" component="ccmsetup" context="" type="0" thread="2860" file="preuninstallcopysource.cpp:51">

    <![LOG[No current reboot settings to backup.]LOG]!><time="00:24:52.401+480" date="02-27-2012" component="ccmsetup" context="" type="0" thread="2860" file="uninstallpreservereboot.cpp:66">

    <![LOG[A newer version client is being installed over an old client and uninstalling old client is necessary. Uninstalling the old client.]LOG]!><time="00:24:52.401+480" date="02-27-2012" component="ccmsetup" context="" type="1" thread="2860" file="ccmsetup.cpp:7248">

    <![LOG[uninstalling product '{4A39A27F-005B-407E-8CF5-F4D8065658E4}'.]LOG]!><time="00:24:52.401+480" date="02-27-2012" component="ccmsetup" context="" type="1" thread="2860" file="msiutil.cpp:1141">

    <![LOG[Running installation package

    Product: {4A39A27F-005B-407E-8CF5-F4D8065658E4}

    Log: C:\WINDOWS\ccmsetup\client.msi_uninstall.log

    Properties: ]LOG]!><time="00:24:52.401+480" date="02-27-2012" component="ccmsetup" context="" type="1" thread="2860" file="msiutil.cpp:1053">

     

     

    Interesting. I'm guessing you're using a seperate WSUS setup to do this other than the SUP I've just configured in my SCCM 2012 console (as per the guides) as surely you'd need the SCCM client on the PC first for it to receive SUP updates via SCCM (?) Sorry, I'm new to SUP / WSUS...

  20. Also when downloading the various SQL service packs and cummulative updates ensure you download the right architecture version (x86 / x64). The default download will differ deppending on the machine you are downloading from. For example, we were using an x86 PC to download updates so it only listed the x86 version. Annoyingly the x86 version of the patch runs on an x64 installation but it only upgrades the Shared Features of SQL and not the full bhuna so the SCCM installation (RC2) still fails. Obvious when you know.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.