That's my next step. In the morning I'll delete that rogue boot image from SCCM and give it a try.
I was going to try it this afternoon but got pulled off on a production problem. Thanks Mike From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On Behalf Of Jason Sandys Sent: Monday, August 8, 2016 2:27 PM To: mssms@lists.myitforum.com Subject: [mssms] RE: ConfigMgr 1511 PXE Boot Selection Have you deleted the boot image altogether? What happens if you create a new TS? Does that boot image ID still show up? J From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Marable, Mike Sent: Monday, August 8, 2016 1:10 PM To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> Subject: [mssms] RE: ConfigMgr 1511 PXE Boot Selection No, we have never used that boot image. It's not assigned to any task sequences and is no longer on any of the DPs ore the PXE server. It is not the image that the system is booting from either. As the system is booting below the progress bar it shows CM1008BE which matches what the SMSTS log shows as loading. I was really hoping that removing that boot image was going to fix the problem. From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Jason Sandys Sent: Monday, August 8, 2016 1:31 PM To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> Subject: [mssms] RE: ConfigMgr 1511 PXE Boot Selection That's the boot image being delivered though (based on the log snippet provided earlier). Are there any task sequences deployed at all with that boot image assigned? J From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Marable, Mike Sent: Monday, August 8, 2016 11:29 AM To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> Subject: [mssms] RE: ConfigMgr 1511 PXE Boot Selection That turned out to be a rogue boot image on the PXE server. I've pulled that one off so the only boot images on the server are the original 32bit., ADK 8.1 production image and the 64bit, ADK1511 development image. I then restarted the WDS service and thought I was home free. I still get SCCM staging the 64bit ADK 1511 boot image. The log still references the CM1000024 (the rogue boot image). So I pulled that boot image off of all the DPs. Restarted WDS and tried again but it still staged the boot image and still referenced the CM100024 package. From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Jason Sandys Sent: Monday, August 8, 2016 11:10 AM To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> Subject: [mssms] RE: ConfigMgr 1511 PXE Boot Selection What is CM100024? Have you tried updating the boot image on the DP? J From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Marable, Mike Sent: Monday, August 8, 2016 9:48 AM To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> Subject: [mssms] RE: ConfigMgr 1511 PXE Boot Selection Unfortunately is just states that they don't match. At the start of SMSTS log is shows that it PXE booted from the proper boot image: [cid:image001.png@01D1F1C8.6784E190] Yet after selecting the development task sequence it just claims that they do not match: [cid:image002.png@01D1F1C8.6784E190] There's no explanation as to why SCCM felt that they did not match. From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Jason Sandys Sent: Monday, August 8, 2016 10:03 AM To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> Subject: [mssms] RE: ConfigMgr 1511 PXE Boot Selection Check smsts.log. It will tell you why it is essentially re-staging the boot image. Typically this only happens with media when the version of the boot image on the media doesn't match the version on the DP but as note, smsts.log should clearly reflect what's going on. J From: listsad...@lists.myitforum.com<mailto:listsad...@lists.myitforum.com> [mailto:listsad...@lists.myitforum.com] On Behalf Of Marable, Mike Sent: Sunday, August 7, 2016 9:49 PM To: mssms@lists.myitforum.com<mailto:mssms@lists.myitforum.com> Subject: [mssms] ConfigMgr 1511 PXE Boot Selection I'm trying to sort out what's going on with our PXE server now that we've upgraded to 1511 and why it's behaving differently from what I'm reading. We've recently upgraded our 2012 R2 environment to 1511. We have not yet upgraded to 1602 or 1606. That is in the works. First some quick background. We have a single PXE enabled DP. On that we have the original, production boot image that we've been using for ages. Let's call it "BootImage1". This image is a 32bit boot image based on ADK 8.1. It is the boot image assigned to our production build task sequence which is advertised to "All Systems". After upgrading to 1511 we began development of a new build and it uses a new 64bit boot image based on ADK 1511. Let's call that one "BootImage2". This development build is only advertised to a development collection. Now, when we PXE boot any production machine SCCM offers up BootImage1 since that is the only one available through the deployment to All Systems. So far, so good. The problem is when we PXE boot one of the machines being used in development of the new build. Since they are members of both the "All Systems" collection (with the production build deployed) and the "Development Build" collection (with our development build deployed), SCCM has to decide which of the 2 available boot images to offer. Since BootImage2 is the most recent, or "newest" on the PXE server it is offered. Again, so far so good. Now from what I've read, if the boot image that the machine uses matches the one that is assigned to the selected task sequence, then the task sequence will just start. Granted what I've found was written for 2007 and 2012. What we're seeing is that even though the machine booted using BootImage2 and we select the DEV build (with BootImage2 assigned), SCCM stages BootImage2 and then reboots the system. When the system reboots it then automatically begins the selected task sequence. SCCM ignores what boot image was used to boot the system. It's a bit annoying and I'm sure that once we go production with this new build and pull the older BootImage1 out of the environment things will be smooth. The bigger problem is that with this new build we are 1) making the switch to BitLocker for encryption and 2) now going to support UEFI systems. Prior to the Networking team getting the DHCP options sorted we were booting from USB media. Now when we go to rebuild a BitLockered UEFI machine SCCM attempts to stage BootImage2 but the only partition visible is the OS partition, but that is encrypted by BitLocker. Since the partition will not be available to boot from then the staging fails. We have to boot from USB boot media which doesn't trigger the boot image staging, or clean the disk of partitions and PXE boot. I don't understand why SCCM does not recognize that the development machine booted from the proper boot image, but instead stages the same boot image and reboots? Has something changed in 1511 and how the PXE boot selection process is being handled? Or is there just something I'm missing or something we may have configured wrong? Thanks Mike Marable Microsoft Systems Engineer Lead Enterprise Device Engineering and Management MCPS, MCITP, MCTS, MCSA, MCSE, MS [Profile<http://www.mycertprofile.com/Profile/5319166625>] [Blog<http://thesystemsmonkey.wordpress.com/>] ---------------------------------------------------- "Every great dream begins with a dreamer. Always remember, you have within you the strength, the patience, and the passion to reach for the stars to change the world." -Harriet Tubman "The two most important days in your life are the day you are born and the day you find out why." -Mark Twain "If it was easy everybody would do it." -Eric Thomas ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues
