This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
I am experimenting with task-sequence deployment types, using Configuration Manager version 2002, and I've run into a problem. I can't actually tell for certain whether it's related to the use of task sequences in this context, but it's happened with every single one I've tried so far, and doesn't seem to happen with other deployment types.
The short version is: an application with a "Task Sequence" deployment type, pointing to a very simple task sequence (just "Download Package Content" and "Run Command Line"), and deployed as Available to a device collection, does not appear in Software Center and cannot be selected for an "Install Application" action in another task sequence. This actually happens with every task sequence I've tried to create a deployment type from, that's just the simplest and thus most minimal reproducing case I've found so far.
The referenced task sequence appears in Software Center just fine when deployed as Available directly to the same device collection, and runs without issue both from that deployment and when referenced by a "Run Task Sequence" action in another task sequence.
I haven't yet found anything online discussing this behavior. I have in fact found at least one step-by-step guide (https://sysmansquad.com/2020/09/27/use-the-task-sequence-deployment-type-to-deploy-an-application-with-sensitive-information/) whose steps seem to assume that it does not happen.
Any ideas for what might be wrong here, and how I can get an application based on a task-sequence deployment type to appear and be available in Software Center?
(If this is somehow intended behavior, then I'd appreciate pointers to examples of how task-sequence deployment types are expected to be useful without the ability to have the resulting application available in Software Center.)
I'd be happy to provide additional information to help track this down and get it working, once I know what information to provide; I don't want to just blat a bunch of stuff here and have it turn out later to be useless and just taking up space.
Hi,
Maybe stating the obvious, but did you check if you have the primary user session id on the machine?
No, I haven't; I'm not actually sure offhand of how to do that. That said, A: since this is a device-associated deployment that shouldn't matter (although I do recall reading things which indicate that it may do so anyway), and B: for the last several test passes, I've been checking Software Center while logged in either as the local Administrator account or as the only domain account to have logged in to the computer since it was reimaged (by the same "other task sequence" which contains a Run Task Sequence referencing the task sequence involved in this application).
I can't entirely guarantee that there isn't somehow another account recognized as being primary on that machine despite the reimage, but if so, I don't know how to change the fact. It would also seem a bit unreasonable for that failure state to exist immediately after reimaging, with an unknown delay before the account of the user who just logged in comes to be considered primary.
Thank you for posting in Microsoft Q&A forum.
I have deploy the application to software center follow the guide,and it works in my environment.
Here are some main steps that during my deployment.
1.Create a package A just put a content path.
2. Add one task sequence including the A package.
3. Create an application and choose the deployment type of our task sequence,and then deploy this application.
Have a nice day!
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Thanks for checking this from your end. The mismatch in behavior is odd, but your response has prompted me to think of one thing which could be causing the problem.
I am not entirely sure whether the Configuration Manager client on the machines being used to test this has been upgraded to the 2002 client version; it may still be on the one from (I think) 1907. Certainly there is a newer client available in pre-production than is in use on the machines thus far used to test this.
I am now moving forward to test with the pre-production client. If that works, then clearly the issue is a need for client support for the new feature, and my problem goes away.
That did turn out to be the issue; with the newer client installed, the application appears in Software Center.
That said, even though the application is now showing up, I'm still having other issues; any attempt to install it fails with either error code 0x87d00215 or error code 0x800700b7 and (in the latter case) the log message "Environment scope "Global{51A016B6-F0DE-4752-B97C-54E6F386A912}" has already been created". The former has been asked about here within the past few weeks by someone else; the latter's message seems to have only one vaguely relevant hit in Google, which is an old TechNet thread that went nowhere.
The underlying task sequences still work fine, but for anything that needs to install on user demand, it's starting to look like this feature isn't viable yet... which would be a huge disappointment; I was hoping to rely heavily on this as we migrate from another solution.
1.Yes,you are right.Start version 2002,the task sequence has added into the deployment type.
2.Have we seen the smsts.log on our client?Since we use the task sequence to deploy our application,we could check this log to see the related messages.
Look forward to hearing from your further news!
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Yes, I've checked smsts.log, among other logs; that's where I got the "Environment scope "Global{51A016B6-F0DE-4752-B97C-54E6F386A912}" has already been created" message.
IIRC, when the application is triggered through Software Center and fails with error 0x87d00215, smsts.log doesn't even get updated; the process seems to be failing before it gets as far as triggering the task sequence. With error 0x800700b7, IIRC smsts.log does get updated, with the given error. I'd have to double-check to make sure that I'm remembering correctly, but I believe those are accurate.
I plan to keep investigating this today, but am not sure how much further I'll get without more to go on.
Also possibly worth checking on: the fact that, as I noted in the original question, the application(s) with a task-sequence deployment type are not available for selection in an "Install Application" action in another task sequence.
That's not fatal in most cases, because it's entirely possible to add a separate "Run Task Sequence" action and point directly to the same task sequence as the deployment type - but it still doesn't seem correct, and in cases where you want to take advantage of the "is application already installed?" rules built into the deployment type, it can be a problem.
Correction: both smsts.log and TSDTHandler.log do seem to get updated with both commands, although the logged messages have not so far been helpful to me. I was, in fact, remembering that part wrong.
The behavior is weirder than I thought. When I click "Install", smsts.log and TSDTHandler.log don't visibly get updated (although others do, e.g. _SCClient*.log), and the Software Center UI shows "Installing" status, although no relevant activity appears in Task Manager. Something like 3-to-5 minutes later, those two log files do get updated, - but with a timestamp taken from the point where "Install" was clicked, not from the time when the files got the new content.
That's with 0x800700b7. I'm no longer sure the "Environment scope" message is relevant; it's just the most likely message in the lines prior to "Error creating TS environment. Code 0x800700b7", which is the last seemingly-error-related message before the message (different per log file) indicating that the TS deployment has failed.
0x87d00215, for comparison, fails within at most seconds after "Install" is clicked.
Thank you for the kindly reply.
In my environment, my application install successfully eventually. It's a long story.
At first, my lab also get the error 0x87d00215 because my task sequence was failed. I checked my smsts.log and i realized that i didn't distribute the packageA to my DP.
I distribute the content to my DP and refresh my client machine policy, and then i also get this error. I reviewed the smsts.log again, and i find that it could not find the content source file. SO i go back to check the package path settings.
Solution of my lab:
1. Make sure the task sequence variables was the same as package content path name.
2. Set the detection method.
After doing this,my application was install successfully like the image shown below:
I hope this could give us some idea and hopes we could also installed.
Have a nice day!
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
I can't follow this advice directly, because I'm not using a task-sequence variable for the install process; I don't see what value it adds in your example. I'm using TS deployment types as a more-maintainable replacement for Run Script deployment types.
The content path in the package is pointing to the correct location, and the "Run Command Line" action is pointing to the correct package name; this is confirmed by the fact that when I deploy the task sequence to the machine directly, it installs without issues.
There is a configured detection method on the deployment type. I'm not sure what you're suggesting to do in that regard, or why it would help.
Is there any information I could provide which might help narrow down what's failing here?
I'd love to open a support request about this, to get active realtime help, but we don't have the hours to spare...
https://learn.microsoft.com/en-us/answers/questions/132740/application-deployment-type-task-sequence-pre-rele.html seems to be the only other report of the 0x087d00215 issue known to Google. The error message attached to the code appears to be "No task sequence policies are targeted to the provisioning device".
I'm starting to suspect that what I need to examine or affect in order to make any progress here is the deployment type's object in its own right, rather than as an adjunct to the application's object, and as distinct from the task sequence to which the DT points. Unfortunately, there doesn't seem to be any apparent way to do that through the Admin Console.
I just noticed that the name of the DT is not mentioned in any of the server-side log files. I'm wondering whether deleting and re-creating the DT might help, if somehow part of its creation didn't go properly?
I've gone in and deleted the DT from the application, applied the changes, then re-created it from scratch - just in case. The application behavior is the same as before (0x87d00215), and the DT name doesn't appear in the server-side log files. If it's represented by some other ID, which might be in the logs in place of the name, I haven't been able to figure out what that ID is.
I guess I probably need to just give up on using TS DTs until at least the next time we upgrade CM to a new version, and move forward with implementing these DTs in other, less maintainable ways...
There are four objects involved here: the package, the task sequence, the deployment type, and the application.
The package and the task sequence are both fine. This is confirmed, because when I deploy the task sequence by itself (or via a Run Task Sequence action in another TS), it works without issues.
The problem must therefore be somewhere in either the application or the DT. Unfortunately, I can't find anything visibly wrong with either one, and I can't find any way to get much information out of the DT itself at all; its name doesn't even appear in server-side logs, and I don't see any indication of a deeper object ID either.
I totally understand your feelings. Did we checked the Appenforce.log on our client already? This log records the application install behavior.
I remember having looked at that log, but not found anything useful. I just looked at it again, and what's there still doesn't seem all that useful, but I can share it in case you see something I don't. Here's the relevant lines from one of my attempts to install this application yesterday:
46683-firefox-task-sequence-deployment-type-appenforce-l.txt
If you'd like, I can also pass along a file consisting of every line findstr matches as including the name of the deployment type, from any *.log file in C:\Windows\CCM\Logs\ ; it's about 300K, most of it duplicate from multiple attempts over multiple days (some of which may have been with earlier versions). I suspect the useful information will be on adjacent lines which don't get matched, though. As far as I can see, none of the information in the file looks to be sensitive.
This phenomenon is really weird,It’s hard to reproduce in my lab(Since i have tried several times and i really want to help you to solve it). I appreciate your understanding that we are not the best channel to address this issue since the forum is mainly focusing on simple break-fix issues.
To get better support, I suggest you call Professional Support Services so that a dedicate engineer will help you solve this issue in a more efficient way. Thank you for your understanding.
To obtain the phone numbers for specific technology request please take a look at the web site listed below.
https://support.microsoft.com/en-us/help/13948/global-customer-service-phone-numbers
Thank you very much for your kind understanding.
@Fiona Yan-MSFT or @Andrew J Buehler
I submitted a very similar question.
https://learn.microsoft.com/en-us/answers/questions/209040/unable-to-deploy-application-with-a-task-sequence.html
I was able to break the application by simply editing the software version of the application. Though updating the package and redistributing the package (which I think changes the Application) also breaks the application with the same 0x87d00215 error.
If the Application changes after it was deployed, the deployment stops working even on machines where the same exact Package/DeploymentType/Deployment worked. For me, I can get the Application working again by deleting the Deployment and re-creating the Deployment.
Thank you for posting in Microsoft Q&A forum.
Merry Christmas Eve!
For start open task manager and check if there is only one user logged in. Device based deployments will show up for primary session id. Let’s rule this requirement out first.
Turned out not to be related, but thank you for responding anyway, and for trying to help!
(Of course, device-based deployments should show up for every user on the machine, irrespective of how many active sessions there are; if they don't, which I gather is the case, that should IMNSHO be considered a bug. I'm not holding my breath over it getting changed, however.)