none
Specific model suddenly fails on any "Application" install, packages work fine

    Question

  • We have been testing and tweaking our Task Sequence for several weeks now and had previously imaged Lenovo T420s's without issue.  Yesterday we rebuilt a T420s, a T430s, and Optiplex 760 and a Hyper-V VM.  Both T420's fail when they get to a step to install an Application (we disabled the initial app that was failing and experienced the same behavior on any of the Application installs).

    Some snippets from smsts.log:
    Right before the failure we get "Policy evaluation failed, hr=0x87d00267" followed by "Failed to run the action: Install App123.  Download Failed (Error: 87D00267; Source: CCM)"

    In the CIDownloader.log at the same time we see:
    GenerateDCMUrlPrefix failed (0x87d00269)
    CIDownloaderJob({GUID}): DownloadPackages failed (0x87d00269).
    CCIDownloaderJob::StartDownload - MP not found - will retry.
    CIDownloaderJob({GUID})::CCIdownloader Job::QuueueRetry - Job is set to fail immediately on error - no retries.
    CIDownloaderJob({GUID}): QueueRetry failed (0x87d00267).

    In the LocationServices log we see multiple entries of the following about two minutes or so before the failure:
    Unable to retrieve AD forest + domain membership
    Failed to refresh security settings over MP with error 0x8007054b
    No security settings update detected
    Retrieved lookup MP [PrimarySiteServerFQDN] from Registry
    Attempting to retrieve lookup MP(s) from AD
    Using default DNS suffix ourdomain.com
    Attempting to retrieve default management point from DNS
    Failed to retrieve DNS service record using _mssms_mp_p10._tcp.ourdomain.com lookup DNS returned error 9852
    ..
    Failed to resolve 'MP_P10' from WINS

    Now having said all this, there are a few "packages" that download and install immediately before the "application" without issue.  As soon as it hits the application it fails right away.  The applications as it stands are standalone tasks within the TS with a single application specified.

    The driver set has not changed for any of the models and are being applied correctly.  Again this issue only affecs the T420s. (haven't tested ALL models yet but of the ones we have tested so far this one fails consistently).  Again, a few weeks ago we were able to build the T420s fine.

    I ran a continous ping to the local MP during the packages installing correctly and the applicaiton failure and it stayed consistent with a <1 ms response.

    The only tweaks we have made since last installing (that i can recall for sure) was removing the CCMHOSTNAME parameter from the Setup Windows and ConfigMgr step as the clinet was intermittently flipping over to "internet" and failing to download package. This issue happened on ALL models we tested. Once we removed that and left only SMSMP=MPFQDN SMSCACHSIZE=7000 CCMLOGMAXSIZE=1000000 builds starting working again...that is until we tested the T420s.

    Anyone seen this before or have any ideas on what to look for to diagnose this?  We have tested several times and the issue is persistent each time on this model.  We have removed the object from the ConfigMgr database and AD and rebuilt with the same result.  Again we also tested multiple T420s's and get the same result on both.  I am thoroughly stumped on what could be causing this.

    Tuesday, February 12, 2013 3:36 PM

Answers

  • Yeah, so false alarm.  It was the switch for sure.  Still odd but all models (tested thus far) are now building again without issue.
    Tuesday, February 12, 2013 10:43 PM

All replies

  • Also forgot to mention, all machine (with the exception of the VM) are being build on off the same switch.
    Tuesday, February 12, 2013 3:38 PM
  • Hi,

    Does the T420's join the domain succesfully during OS deployment? the errorcode "0x8007054b" translates to "The specified domain either does not exist or could not be contacted"

    And the error  9852  "No DNS servers configured for local system"

    Could indicate that there are no network Connection or no DNS server configured, try using the F8 command prompt and check the network Connection and that the FQDN can be resolved.

    That is where I would start.

    Regards,
    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec



    Tuesday, February 12, 2013 3:51 PM
  • Is the machine in the Domain, when It boots up after failing the TS?


    Best Regards
    Claus Codam
    Consultant, Developer
    Coretech - Blog

    Tuesday, February 12, 2013 3:51 PM
  • Thanks for the reply guys.  To answer the question yeah, it definitely joins the domain. 

    Major update to this thread however...  we realized this morning that the switch we are using was indeed swapped out since we last built the T420s.  We took the new switch out of the picture and the app failures stopped!  Still very odd that it would join the domain, come up and download/install multiple "packages" right before it would fail on any "Application". 

    Testing another T420s now to ensure it wasnt a fluke but feel good that it isn't as I coule readily reproduce the issue over and over when connected to the switch.

    Thanks again for the responses gentlemen. 

    Tuesday, February 12, 2013 5:09 PM
  • Yeah, so false alarm.  It was the switch for sure.  Still odd but all models (tested thus far) are now building again without issue.
    Tuesday, February 12, 2013 10:43 PM
  •  We had the same error a week or so after upgrading to SP1. We had deployed more than 500 identical computers before we more or less out of the blue got the problem.

    Every Install Application task that runs after a reboot fails with the same error message you get.

    In our case the problem only occured in very certain scenarios. The error was only seen on Lenovo M92p desktops and Lenovo T430s laptops when they had certain SSD disks in and was installing on 1Gbit LAN. The SSDs are Samsung 830 256GB and Micron C400 256GB.

    We had two M92p running next to each other and verified failure and succes.

    The failing one had the Samsung disk and the succesful on had either a normal 500GB harddrive or a Kingston SSDNow 256GB disk.

    When we swapped the disks around, the error followed the disk so that caught my attention.

    I also noticed the Kingston SSD is significantly slower than the Samsung and Micron.

    When I saw the error in LocationServices.log, I tried to verify network connectivity by running a simple ping of the primary site and parse the output to a file just before the Install Application would fail.

    The server answered just fine, but still SCCM gave the error in LocationServices.log afterwards.

    So the error occurs on:

    Machines with fast SSD's on 1Gbit

    Same machines rarely failed on 100mbit.

    When we replaced the SSD with a slower disk, it works.

    We tried the scenarios on 3 different floors and also in another country.

    We have the latest SSD firmware revisions installed. (we found a bug in the Micron firmware on Lenovo as well).

    Our workaround so far is:

    Before running an Install Application, wait 5 minutes. This works.

    Could probably be less than 5 minutes, but 30 seconds wasn't enough in our case.

    Problem is if you have an Install Application task with more than one app and one of them exits with 3010 and causes a reboot.

    The next step will then fail and we can't add the task between them..

    I'm working with PSS now to hopefully find the problem.

    / Heine Jeppesen

    Tuesday, March 19, 2013 8:09 PM
  • Hi Heine, Did Microsoft PS provide any feedback? I am having sporadic issues with "Install Applications" task sequence steps and may be facing the same issue. I am hesitant to add a 5 minute wait and was wondering if MS provided a better workaround. 

    Please let me know when you get the chance.

    Thank you.


    Rob 

    Monday, April 15, 2013 7:28 PM
  • Hi William

    I'm also facing similar issue. Applications unable to install on VM during OSD TS. Please let me know how did you fix this?

    http://social.technet.microsoft.com/Forums/en-US/configmanagerosd/thread/da1f2735-d472-42cd-a0c4-609598a0be89


    Cheers | Navdeep Sidhu

    Tuesday, April 16, 2013 1:02 PM
  • Same exact problem here. I can repro this behavior on all 12 of my Lenovo X1 Carbons with SanDisk SD5SG2256G1052E SSD's. Packages install fine during OSD, but as soon as an application attempts to install it fails with error code 615 and same hr=0x87d00267 error in smsts.log. The same OSD TS works perfectly on all other machines (various Dell Precision Workstation models, VMs, etc.). I tried adding a 5 minute delay as the 1st step before the applications install and it worked for the first 2 applications in the list, but then the rest of them failed again with error 615 (there are 22 applications broken into 3 "Install Application" groups).

    The X1 Carbon doesn't have onboard LAN so I'm using a Lenovo USB 2.0 Ethernet dongle (Model U2L 100P-Y1) which is only a 10/100Mbps adapter so I am already throttling to 100Mbps. Unfortunately it's the only Ethernet dongle that supports PXE on the X1 so I can't test at 1Gbps. I'd love to hear if anyone has found any other workarounds. I have a case open with Microsoft but they have no solution yet.

    Tuesday, April 16, 2013 5:14 PM
  • Hi

    Are you able to install an application on any VM during OSD TS? If yes then let me know whether you are using SP1 & also any special configuration done in OSD TS because in my case, not even a single application is being installed on VM. I have not used 5 minutes delay as you mentioned.


    Cheers | Navdeep Sidhu

    Tuesday, April 16, 2013 5:38 PM
  • Using SP1. No issues with OSD on VMware VMs. Are you sure you have "Allow this application to be installed from the Install Application task sequence...." checkbox checked in the application's properties?
    Tuesday, April 16, 2013 6:00 PM
  • The issue for us was PortFast not being enabled on the switch we were working on.  Was very odd behavior given the process would work all the way up until application installs and then fail.  As soon as we got PortFast enabled the problem disappeared.  Crazy but true.  I would highly recommend you have your network team validate the switch config.  ;-)

    Tuesday, April 16, 2013 7:47 PM
  • Hi William

    It really sounds weird that PortFast is stopping an application to be installed on VM however I'll ask Network guy to enable PortFast & will check whether application gets install on VM.


    Cheers | Navdeep Sidhu

    Wednesday, April 17, 2013 8:51 AM
  • I think SP1 is making the difference. As far as "Allow this application to be installed......" checkbox is concerned, this option is required if you are deploying the applications using dynamic variable.

    Did you try to install the installations on VM without SP1 by any chance?


    Cheers | Navdeep Sidhu

    Wednesday, April 17, 2013 8:57 AM
  • Trust me NavdeepSidhu, I know it sounds strange for sure.  After 2 days of troubleshooting every corner of the Task Sequence, drivers and various hardware, we realized the switch we were connected to had been changed out.  (This was an extension of our production network into a conf room where we were collaborating).  We moved the port back to the old switch and Bingo...everything started working again.  We swapped the switch to get a bigger one anyway and after hooking it up the machines starting failing again.  Then realized PortFast had not been enabled.  Turned it on and everything started working again.

    I should note, for us...We were/are able to build VM's (on the same subnet as the SCCM Server) without issue.

    Hopefully this is the issue for others as it makes for a quick and easy fix.

    Wednesday, April 17, 2013 1:26 PM
  • In my scenario, VM is part of a different network subnet & may be that's why applications are failed to install.  I'll try to build & install applications on a VM by keeping it into the same network subnet where SCCM server resides.

    Thanks for your inputs William.


    Cheers | Navdeep Sidhu

    Wednesday, April 17, 2013 1:40 PM
  • We have PortFast enabled on our switches, so that's not the problem in our case.

    I also doubt it is PortFast in our case, as I can run a simple Ping <MP.fqdn> >C:\test.txt in a commandline just before the Applications fails.

    So the network is up and running when the applications fail.

    I haven't heard from PSS yet, but I will try to push the case a bit harder now that more people seemingly have similar problems.

    Thursday, April 18, 2013 6:00 AM
  • Update:

    Without SP1, packages are being successfully deployed during OSD TS on a VM however applications are unable to install.

    With SP1, I'm able to deploy applications on VM without enabling PortFast.

    Hence there might be a bug in SCCM 2012 (without SP1) which stops to install application on a VM during OSD TS.


    Cheers | Navdeep Sidhu

    Thursday, April 18, 2013 10:18 AM
  • I tried moving my Lenovo X1 Carbon to a Netgear switch and various Cisco switches with portfast enabled. Same behavior - exit code 615 during application installs. However, once I added a 30s delay before each Application Install step my applications started to install properly. So my OSD TS now looks like this:

    • .....
    • Restart Computer
    • Delay 30s (cmd.exe /c "ping -n 30 localhost" > NUL)
    • Install Applications Group 1 (9 applications)
    • Delay 30s
    • Install Applications Group 2 (9 applications)
    • Delay 30s
    • Install Applications Group 3 (4 applications)
    • Restart Computer
    • .....

    I'm not sure why the delay makes a difference, but it does. I can sort of understand after a reboot where if portfast weren't enabled the SCCM client could startup faster than the network stack can initialize. But once the OS is up I can't see why it would need another delay in between Install Application groups.

    • Proposed as answer by BMMx2 Thursday, April 18, 2013 2:15 PM
    Thursday, April 18, 2013 1:29 PM
  • BMMx2,

    I'm "glad" you're seeing the same as we are. ;-)

    If any of the applications in your Application Groups causes a reboot (exitcode 3010), you TS will fail again.

    That's the biggest issue with this problem - We use dynamic applications, so during the OSD process we determine what applications are needed based on user requirements and set TS variable for them. Problem is that some applications cause a reboot, so the TS will fail again after that :-(

    I also tried 30 seconds, but that wasn't enough for us. So I just put 5 minutes in, as the issue was becoming a big problem because of the Win7 rollout - Never had the time to find the minimum time necessary.

    I tried 2-3 other versions of NIC drivers (newer and older) without any luck. Also ensuring BIOS, SSD firmware etc. was at the latest level.

    No matter what, I ended up with the delay on the SSD based machines.

    -Heine

    Thursday, April 18, 2013 2:12 PM
  • If any of the applications in your Application Groups causes a reboot (exitcode 3010), you TS will fail again.

    That's the biggest issue with this problem - We use dynamic applications, so during the OSD process we determine what applications are needed based on user requirements and set TS variable for them. Problem is that some applications cause a reboot, so the TS will fail again after that :-(

    -Heine

    This issue is very well documented by MS in below link

    http://support.microsoft.com/kb/2717295

    So the solution is to upgrade SCCM site server hierarchy to either Update Rollup or SP1. This will solve the problem.


    Cheers | Navdeep Sidhu

    Thursday, April 18, 2013 2:30 PM
  • Yes, the reboot was fixed in CU1 - the other problem, not so much ;-)
    Thursday, April 18, 2013 2:34 PM
  • I tried moving my Lenovo X1 Carbon to a Netgear switch and various Cisco switches with portfast enabled. Same behavior - exit code 615 during application installs. However, once I added a 30s delay before each Application Install step my applications started to install properly. So my OSD TS now looks like this:

    • .....
    • Restart Computer
    • Delay 30s (cmd.exe /c "ping -n 30 localhost" > NUL)
    • Install Applications Group 1 (9 applications)
    • Delay 30s
    • Install Applications Group 2 (9 applications)
    • Delay 30s
    • Install Applications Group 3 (4 applications)
    • Restart Computer
    • .....

    I'm not sure why the delay makes a difference, but it does. I can sort of understand after a reboot where if portfast weren't enabled the SCCM client could startup faster than the network stack can initialize. But once the OS is up I can't see why it would need another delay in between Install Application groups.


    So is this the final solution for this behavior? I have the same situation in a location A, but in a location B I could install same SSD models just fine. Sure network switch and DP varies on different location.
    Thursday, August 1, 2013 9:00 AM
  • I tried moving my Lenovo X1 Carbon to a Netgear switch and various Cisco switches with portfast enabled. Same behavior - exit code 615 during application installs. However, once I added a 30s delay before each Application Install step my applications started to install properly. So my OSD TS now looks like this:

    • .....
    • Restart Computer
    • Delay 30s (cmd.exe /c "ping -n 30 localhost" > NUL)
    • Install Applications Group 1 (9 applications)
    • Delay 30s
    • Install Applications Group 2 (9 applications)
    • Delay 30s
    • Install Applications Group 3 (4 applications)
    • Restart Computer
    • .....

    I'm not sure why the delay makes a difference, but it does. I can sort of understand after a reboot where if portfast weren't enabled the SCCM client could startup faster than the network stack can initialize. But once the OS is up I can't see why it would need another delay in between Install Application groups.


    So is this the final solution for this behavior? I have the same situation in a location A, but in a location B I could install same SSD models just fine. Sure network switch and DP varies on different location.

    I had a case open with PSS with the problem and they confirmed it was a bug.

    However it won't be fixed until 2012 R2 and they didn't have any better workaround, than the delay.

    /Heine

    Thursday, August 1, 2013 10:08 AM
  • I had a case open with PSS with the problem and they confirmed it was a bug.

    However it won't be fixed until 2012 R2 and they didn't have any better workaround, than the delay.

    /Heine

    Could you please be more spesific, what exactly is a bug? I see, that this situation may vary. Other have solved this be re-capturing the image on MDT based TS. Some one had solve this by refreshing local admin password and update content on DP. My case is strange too - on one location both SATA and SSD based laptops works fine, but on other location only SATA works, SSD fails right at the first app with download failure. If I disable first app step, the second will fail.

    Thanks!

    Thursday, August 1, 2013 3:56 PM
  • So is this the final solution for this behavior? I have the same situation in a location A, but in a location B I could install same SSD models just fine. Sure network switch and DP varies on different location.


    I managed to solve my issue by chaning the lan router to a faster one. The also was some miss-configuration in that router. That´s why in location A everything worked, but not in B. Apperantly, the Application Install step requires quite fast network connection with SSD disk. Just creating delay steps didn´t do the trick.
    Thursday, August 15, 2013 4:05 PM
  • All,

    I had the same problem with Applications (not Packages) failing for only one model of our estate. All other laptops and desktops built fine, but not the model Viglen 644M. At first I thought it was a driver that needed upgrading, but it turned out that the fix was adding in the delay that BMMx2 suggested. There is very recent SCCM SP1 CU2 out that mentions a fix for applications failing - I intend to install this in a couple of weekends and will report back whether it fixes our issue.

    http://support.microsoft.com/kb/2854009

    I should note that it failed at different applications, and about 60% of the time went all the way through, but if we deployed a large number of machines the failure rate was closer to 90%. The error codes also differed each time which made it hard to troubleshoot, we experienced errors (0x87d00269), (0x8004005) and one more which I don't have with but will update later.

    As part of our troubleshooting we double-checked that our DHCP lease time was enough for the duration of the build (ours is 4 hours) and that PortFast was enabled on our switches (which it was).

    Regards,

    Michael



    Wednesday, August 28, 2013 4:16 PM
  • Hi, I've had this exact issue with my deployment at a customer site. I've got a case open at PSS. Actually I have found something that could be a solution to this issue.

    I've done some extensive testing including remaking the image with diffrent versions of IE. When doing this I removed a couple of software updates I've added to deploymentworkbench.

    The two patches I've removed is the requirements for App-V 5.0.

    KB2506143 and KB2533623. And for some reason I do not experience any of thees issues anymore.

    The SCCM is a 2012 SP1 with CU2.

    Hope this helps out for you guys!

    Kindest Regards
    Björn

    Wednesday, September 18, 2013 2:56 PM
  • Thank a lot for your Feedbacks here :)

    I had the same error (0x87d00269) on a specific Site, had also Notebooks with SSDs, but there wasn't a Problem with that.

    The main Problem was on a lack of Network connectivity in the Room where we staged our machines. In an other Room, everthing works fine...

    We are now looking, what of the Network made those Problem (Switch, Cables, etc).

    Tuesday, September 24, 2013 8:54 AM
  • We are also seeing this issue with Applications failing during the task sequence on our remote "slow" sites, it seems to be affecting DELL workstations, all our notebook fleet are installing applications fine, everything is installing correctly on the normal fast network.

    I wonder if R2 will fix our issues, currently on CU1.

    Sunday, October 20, 2013 11:15 PM
  • For those wondering if SCCM 2012 R2 resolves this issue -- it does not. In fact, I just began experiencing it right after upgrading to R2 from 2012 CU2.

    In our case it's Dell OptiPlex desktops experiencing the problem (older, non-SSD model). PortFast enabled by default on all of our switching infrastructure. Just began occurring this morning, so we're still early into the diagnosing portion.

    We're just attempting another build at a different physical location at the same site (same secondary site). Will also began trying at other locations throughout our org and see what happens. Our failure is happening on an application, after 3 other applications and 1 package have successfully run.

    Wednesday, October 23, 2013 5:11 PM
  • That's interesting we use the same Dell Optiplex desktops also non SSD models, we haven't updated to R2 just yet, I noticed that our network driver is about a year out of date might look at importing the latest driver to see if that fixes the issue, I have tried the delay ping mentioned above but that has not helped, funny its only affecting the Dell desktops only.
    Wednesday, October 23, 2013 9:02 PM
  • Even this is an old an already answered post:

    I had the same Problems and the suggestions with the delay didn't work.

    I installed KB2459530 (http://support.microsoft.com/?kbid=2459530) which solved the Problem on my side (so far...)

    I tried the Resolutions from this article: http://support.microsoft.com/kb/938449/en-us because I also had this Event id Messages.

    I've written a small blog post about this:
    http://sccmfaq.wordpress.com/2013/11/21/sccm-2012-install-windows-7-on-ssd-fails-with-error-0x87d00267/

    Thursday, November 21, 2013 11:43 AM
  • Installing KB2459530 at the beginning of the TS worked for me as well. Thank you for the blog post Martin. Would have taken me a while to figure this one out :)
    Wednesday, January 22, 2014 11:51 PM