surfincow

As I test, I removed my computer from the collection that this task sequence is deployed to. Updated machine policy and ran Application Deployment Eval Cycle and the rogue application no longer shows up. So it is something with this application being in this TS which is deployed to this collection that is definatly causing the problem. How and why an application within a TS is able to be detected and ran when the TS itself is not is a mystery..

Hello, I don't think it has anything to do with dependencies. All the dependencies for this application are contained within this single application. Its not a situation where I have MS Word deployed and mistakenly made the BIOS version a dependency. If it is a bug, then definatly I think it needs to be addressed. I've always considered TS as their own little box of magic and things can only happen that are in a TS when the TS is run and run in order meeting the criteria established in the TS. Even if there are dependencies or superceedance, if you do not have the application deployed it should not be able to be installed. The only exception is if you have enabled the package to be installed when not deployed if it is a part of a task sequence. In that scenario, I would be under the impression that it can only be installed IF the TS is ran and IF all the criteria of the TS are met. I don't know what collection the PXE TS was deployed too but in a link on that thread it went to another post where the person is deploying his TS to a similar large collection (all systems) that included an application that superceeded another application. The newer application was not deployed to any collection but once the TS was deployed for OSD that contained that newer appication, all the machines started to upgrade. I am using the R2 version of ConfigMgr. I do like the new app model but there is still some things I use packages for instead of Applications. For my use case for the BIOS upgrade, the application model works well since I can chain dependencies for things like the BIOS.

Now that I've re-read the posted link I think the issue is different. I think his issue did relate to superceedence... I'm not using superceedence in my envionment (as of yet) but it sounds like when he set that up is when the program starting uninstalling the old and installing the new. While it sounds like he only had the newer version in the TS, the fact that he created the superceedence to the original program is what triggered the unplanned upgrades.

Hi Rocket, Thanks for the info. It sorta does seem similiar to the issue I'm having. The difference is though I don't have any supercedence configured in this application. There is an order that some BIOS's are applied (if you need to gradually bump up the versions to get to the current version) but those are handled through dependencies. Example: v16 is dependent on v11 which is dependent on v9 which is depended on v2. Which ever one of those versions it needs to hit and advance forward from to upgrade to the current is processed in that order. If he does have his TS deployed to the same collection that the "mystery" machines are receiving the upgraded application, then it sounds similar, but to me sounds like a bug or at least does not make sence that a TS can have parts of it picked out and ran individually outside the intended purpose. I typically think of TS's for OSD but I know you can use them for deploying applications (and other things) to live machines. The problem though is that it should be a sequence. Meaning things should happen in order, and here, they are not. If the TS isnt deployed to the collection where the machines are getting the mystery upgrade, then thats even more confusing. Hopefully he will update the thread with where this TS is being deployed to.

Hello, It does appear to be only running on machines in this collection (which contains windows workstation class (7/8/8.1) machines. If I look at any of the servers (which are not a part of this collection) I do not have an AppEnforce.log file (most likely because we are not deploying applications to servers). This has ocurred on machines imaged with CM2007 months/years ago and migrated to CM2012 as well as a machine that was imaged with CM2012 2 months ago. The task is failing (which is sort of a good thing) due to the password needed to install the BIOS being wrong. (Since the smsts.log would capture the password used to apply the BIOS update "biosupgrade.exe /p=password" I set a temporary BIOS password during the OSD. The password is later changed with a dell cctk .exe which has the old/new BIOS password in the exe). The command that is run to upgrade the BIOS uses that temp. password and thus fails because the step to set the temp password did not run (since the TS is not running). Since this application is a part of an OSD task sequence (and not advertised/deployed anywhere else), how is it possible that it is allowed to run? As I said before, if machines suddenly started to go through this task sequence from start to end (which would be format, apply os, drivers, apps, updates, etc, etc, etc) I would understand.. it would not be a good thing... but at least it would make sence. If this is a sequence of tasks that are to be performed in order and stop if something fails (such as it should as the 4th step is Apply Operating System (and is not set to "Continue on Error"), how can something 14 steps later still be executed?

Hello, The only dependencies for this application are contained within this application. Most of the BIOS are able to be installed regardless of the current version installed. However, for some models you need to go from Ver1 to Ver5 to current version. For those situations there are dependencies built in to handle that. Again, those are all deployment types contained within the same Application.

Hello, Have something odd going on and I'm having trouble understanding why/how this could ocurr. As part of the OSD Task Sequence I have an install application step to evaluate the BIOS version for each notebook model we have and if there is a newer version in SCCM to upgrade the BIOS during the imaging process. The application (not package) is not deployed, but has "Allow this application to be installed from the Install Applications task sequence action without being deployed" which allows this to be installed using a task sequence. The only task sequence this application is a part of is for OSD, so the only time this application should be ran is when that step in the OSD process ocurrs, correct? What I have noticed is, this is running outside the OSD Task Sequence. During the migration from the 2007 client to the 2012 client one of the pilot users reported that their BIOS was updated after they restarted their computer. I checked the AppEnforce.log and sure enough, SCCM had installed the BIOS update. Luckily, everything worked fine after the BIOS update. I didn't hear any other reports of this behavior. During another issue I am working on today, I checked the AppEnforce.log on my notebook to troubleshoot a problem with a normal application deployment but noticed that SCCM has been trying to update the BIOS on my workstation as well. This notebook was imaged in February, yet the logs show the last time this was enforced was yesterday. I had a co-worker send me the logs from his machine (imaged with 2007 probably a year ago, but then upgraded client to 2012 within the last 2 months) and same thing. SCCM is trying to install the BIOS upgrade application that is not deployed to any collection, but is part of a Task Sequence. We do advertise/deploy the Task Sequence to a collection that contains all workstations rather than adding/removing machines to a specific "OSD" collection. This allows the service desk to image/re-image machines without having to import them to a special collection. I do understand the risks of doing this; however, this is how we've had the 2007 SCCM setup for years without issue. To help prevent something bad from happening, we do not make the TS deployments "assigned/mandatory" but "available", allow it to only run on an OS that we do not have in production (AIX 5.3), and the deployment is only made available to media and PXE. I COULD understand if all the workstations started going through the OSD process (thank God they have not though), but what I don't understand is how this one application in that task sequence is trying to be applied outside the TS that is not running. Any idea? Thanks

Hello, I'm testing out the reboot policy and I'm having some issues with the reboot (forced by the configmgr client in the application deployment) timeframe configured in the Client Policy not being enforced. I have a test collection set with a reboot window of 30 minutes, with the reminder displaying with 10 minutes left, and that client policy is deployed to that collection. If I create a package and set it to have the configmgr force the reboot after install, all works as expected. If I create an application and set it to have the configmgr force the reboot after install, it does not work as expected. I get the reboot notification, no count down. Only option to reboot or snooze (which it allows me to snooze 4 hours, which is way past the reboot setting) I'm sure I'm missing something simple but not sure what it is. Am I correct in asuming the Client Settings "Computer Restart" affects reboots triggered by Package/Application/Software Update installation that calls for a reboot? The resultant Client Settings shows the 30/10 values. There are no maint. windows configured, nor business hours. What am I missing? Thanks

Hello, There are quite a few new features with SCCM 2012 that I'd like to take advantage of. I really like the application vs package model but I'm seeing a lot of things left out of the Application model that will probably require me to stay with the package deployment instead. One of those features is user popup notifications. In our environment we push application upgrades out as soon as possible. We can't wait until the user logs on or off (as they may only do this once a month). Maintenance windows don't work either as again its waiting for pre-set date/time and dealing with the issues of people being out of the office, computer off (don't want to deal with WOL), etc, etc, etc. Because of this, in our current SCCM 2007 environment we do popup notifications before an installation that requires the closing of a program (typically Firefox) ocurrs. Since we don't want users to have these programs close unexpectantly the install does not happen until they've clicked OK on the popup notificatioin (simple .vbs script). I know there are 3rd party apps and workarounds (scripts) that can do this but I'm wondering if there is any tricks that can be done with 2012 that don't require outside apps or separate scripts using the Application deployment method. One thought was the Global Conditions. I think this is outside the scope of the intent of Global Conditions, but this is outside my scope of what is possible so I'm looking for your thoughts. Is it possible to create a global condition that says "If applicationx.exe is running, create this popup window to the user and wait for their input. Once you've received their input, close applicationx.exe and continue the installation"? Essentially the same type of script that you would use with a package, but built into the condition rule set for each deployment? I know a condition could be made to check for the running of that application and continue or fail depending on if its running or not, but I'm looking to go a step further and have the sccm client notifiy the user of the installation, what will be closed and wait for their input before continuing. I'm fairly sure this is not possible but I'm disapointed that some sort of built in user notification is not a feature of SCCM. It seems that most users would like to be notified before an application is closed and waiting for the user to be logged off as to not interfere isnt always possible. Thanks, Mark

Hello, I'm looking for a method to block an individual patch from being installed on one or few servers. I am currently using ADR's that as part of the search criteria, removes any updates that have a custom severity level. If I find a patch that I want to skip, I change the severity level on the individual patch and its prevented from being distributed according to my ADR. This works well if you want to prevent the patch from being deployed to all machines in the targeted collection, but what if you find a single patch causes problems on a single server? I believe with WSUS, you could block an individual patch from being installed on a single machine where with SCCM (2012R2) it does not appear so. Any thoughts on how to do this without creating separate server collections for every possible role/configuration we have? Also, is there a way to configure the client to not reinstall a patch that has been removed? It looks like the "Client Settings: Software Updates: Schedule Deployments re-evaluation" will check to make sure all the updates are installed and re-install them if something is missing. I don't see an option to turn off the re-evaluation so is this done someplace else? Thanks