OSD Task Sequence Application being enforced/installed OUTSIDE OSD environment

[surfincow]

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

[Iroqouiz]

Is it somehow marked as a dependency with automatic installation for another application?

[surfincow]

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.

[Rocket Man]

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?

 

 

This should be the normal behaviour.

 

Is this happening on all systems that is contained within the collection you have advertised the TS to?

OR

Is it only happening on systems that have been recently OSD'd or OSD'd at any stage using this TS?

 

If it is the latter then maybe the application is stuck and is continually trying to run.... check the task manager on the systems to see if there is any sign of the app running... reboot them and check task manager again to see if it comes back in..... if so the application is not working as it should during the OSD and maybe does not know it has finished properly.

[surfincow]

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?

[Rocket Man]

Maybe this can shed some light on the issue...... link

[surfincow]

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.

[surfincow]

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.

[Rocket Man]

It states

 

 

Is this really as intended? The TS itself is only available to PXE, but yet will applications in the TS still be evaluated by the OS, and cause Lync (and other application if not present on the client) to be uninstalled/installed (when software inventory is run).

 

He has obviously deployed it out to some sort of collection as he has specified to only media and PXE option, so you won't get this until you actually deploy the TS.

It sounds very similar to your problem but as you say you have dependicies and not supercedence, but it actually is doing the overall same job, upgrading versions, so maybe this applies to dependicies also?

 

Is this a bug that needs to be addressed, if not a bug then it still needs to be addressed as I am sure a lot of SCCM users deploy TS with application tasks attached with similar scenarios(supercedence/dependicies).

 

What version of SCCM are you running?

Maybe this has been sorted in R2... I am running this version but do not use apps in OSD I just use the standard reliable package model. I just use the app model for the self service application portal...had way too many unsuccessful deployments when trying the app model with OSD when I was running CM2012 non service pack...haven't tried it with R2 since so can't be sure if there has been any improvement.

[surfincow]

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.