SCCM Task Sequence fails with error 0x87d00269
If you find that your SCCM Task Sequence fails with error 0x87d00269, this post will help you in fixing that. One of the customer reported that while there was no changes made to TS this error still came up. They had tried rebooting their SCCM server to see if that fixes the issue.
I do believe that one has to examine log files (probably more than one) before you try any other things. This error occurred shortly after the installation of the Configuration Manager agent. Let’s look at the log files that we need to analyze to troubleshoot this issue.
SCCM Task Sequence fails with error 0x87d00269
If you find SCCM task sequence fails with error 0x87d00269, follow the steps. At any point during OSD when the TS fails you examine smsts.log file. In this case the smsts.log had an error 0x87d00269. The actual error was Failed to run the action: Error in task sequence. Required management point not found. Error: 0x87d00269. So looking at the error, the initial assumption is the client is unable to contact management point.
Further investigation using ClientLocation.log suggests Location detection issues. The repeated lines found in the log file are :-
Current Management Point is <empty>. Workgroup client is in Unknown location. Local machine is not a member of an AD domain.
LocationServices.log is littered with errors again suggesting that there are connectivity issues. Some the errors that appear in this log file are :-
Unable to find lookup MP(s) in Registry, AD, DNS and WINS. Workgroup client is in Unknown location. Attempting to retrieve lookup MP(s) from DNS. DNS Suffix not specified. No lookup MP(s) from DNS. Failed to resolve 'SMS_SLP' from WINS. No lookup MP(s) in Registry, AD, DNS, and WINS. Won't send a client assignment fallback status point message because the last assignment error matches this one.
The above screenshot suggests the client is unable to find the MP in the Registry, AD, DNS or WINS. Attempting to ping management point server from the command line of the client also failed. However pinging the FQDN of server worked. This suggests that the underlying issue could be with the network configuration. Most likely, there is no DNS suffix in place. So why not add it in task sequence ?.
Edit the task sequence. Click Setup Windows and ConfigMgr step and add SMSMP=sccm server fqdn. After making this change, the error never came up.
This can also be because the computer failed to join the domain during the OSD TS
Agreed. I just experienced the same error message on an Install Application step. The account used to join the domain was missing from the OU’s permissions. I also had the following error messages in the smsts.log : “Failed to connect to MP: 80” and “Failed to connect to MP: 443”. The strange thing is that the step Apply Network Settings was considered successful.
Agreed, after searching the logfile under C:\Windows\Panther\UnattendGC\ setupact.log i’ve come to the conclusion that there is a duplicate SPN in one of our child domains.
I’m encountering this issue on only 1 of 2 of my OSD Task Sequences. I have SCCM published to AD so on the working TS it is pulling the MP information from AD, and I confirmed this in the LocationServices.log. On the other Task Sequence though I am encountering this issue exactly as you have described it. The only difference between the two TS’s is the working one is deploying Windows 7, while the broken one is deploying Windows 10. This appears to have started recently. While I could follow your recommendation and specify the FQDN in the client Installation Properties, I feel I shouldn’t need to. I can reproduce this on the same workstation, the only difference being the TS being applied.
Further more, it appears to only apply when reimaging the workstation from Windows 7 to Windows 10. If the machine failed (as described above) when installing Windows 10, then the same Task Sequence is run again it succeeds.
I am converting the BIOS from legacy BIOS to UEFI and preparing the TPM for BitLocker in the Windows 10 image, but I don’t see how that could be causing this behavior.
After reading this and starting steps to test the recommended resolution, I noticed that the “Use pre-production client package when available” option was checked. When comparing this to the Win7 Task Sequence it was not checked. Unchecked it in the offending Win10 task sequence appears to have addressed the issue. I’m not sure if this is a reported bug or not, but it is in a very specific scenario, so I can’t imagine too many others would have run into it. For the record my SCCM and Client versions are below.
Site Version: 5.00.8634.1000
ConfigMgr Hotfixes applies: KB4163547, KB4339794
Production Client Version: 5.00.8577.1115
Pre-Production Client Version: 5.00.8634.1814
It is the MP you should add.
Thanks for this post. I am pretty new to SCCM and we have this issue on one of our 20 DP’s. I just have a question regarding the SMSMP server. Should I add the fqdn of the MP or the DP?
Comments are closed.