Config Mangler

80070002 is file not found - guessing your site is PS1 so the content it's missing 00091

1802 is baseline now so you can install that straight off. 16 core / 96 Gb is to support the maximum number of clients which is 50,000 when SQL is installed locally. It supports more clients if SQL is local . We're supporting 15,000 clients on an 8 core, 64Gb VM and performance is fine. SQL will take all the memory if you let it so that needs restricted.

Might it be this line "Setup exit code: 0x00009C4F (40015) - Wrong OS Version"

This is now escalated with Microsoft for a code review. To be clear this failure only happens when rebuilding from Windows 10 to Windows 10 using the SCCM client. We think the failure happens when there are updates pending in Windows. It doesn't happen every time so it may be a combination of certain updates. My point with Microsoft is that the SCCM client should be able to handle this particularly if you are doing a wipe and load and don't care about updates.

There is no choice here. You have to use the ADK to support your 1710 installation. https://docs.microsoft.com/en-us/sccm/core/plan-design/configs/support-for-windows-10#windows-10-adk p.s. Not sure I would manage 7 and 10 alongside. Why not migrate them (install the client from new server) when you want to build Windows 10 then let the old server die out.

PXE doesn't work across subnets unless you have IP helpers / relay enabled on the routers. Can you test PXE on the same subnet initially to prove it's working?

You would think it's a BIOS / timing type issue as it can't see the disk and goes into WinRE mode. It continues after a manual reboot or two! BitLocker not an issue as I'm getting the same behaviour on laptops and unencrypted desktops. I have updated a HP EliteBook 820 G3 (which is a current model) to the latest 1.24 BIOS but still the same. Have logged a premier call now so will report back.

Happens on wipe and load of existing Win 10 clients - these can be 1607 or 1703. Doesn't happen on the in-place upgrade. Suspecting ADK / PE area at the moment.

We are experiencing build failures in maybe 10-15% of cases since SCCM 1710 upgrade. OSD initiated from the SCCM client can lead to a failure on reboot into WinPE where the computer goes into the WinRE recovery environment. If the computer is power cycled it will continue the build. This is happening on three different types of hardware. I can get to a command prompt in WinRE so can provide logs though can't see anything in SMSTS log. It's the same issue as reported here but changing the language setting didn't help. https://www.reddit.com/r/SCCM/comments/7ktj8q/sccm_1710_boot_image_keyboard_layout_recovery/ SCCM environment: Server 2012 R2 SCCM 1701 + KB4057517 ADK 1709 Target OS Windows 10 x64 Enterprise 1703 Any thoughts?

MS have seen sense and extended support for Windows versions for 6 months. https://blogs.technet.microsoft.com/windowsitpro/2018/02/01/changes-to-office-and-windows-servicing-and-support/

Not exactly what you're seeing but there are (as ever) problems with updates https://support.microsoft.com/en-gb/help/4058258 look at known issues at the end

SCCM 1702. We enabled Express updates and it worked for a while. It used to be possible to search for "Delta" within the All Software Updates list but this now returns nothing. If I check the properties of a CU I can see the express update listed under the Content Information tab . wsyncmgr.log looks ok, a WSUS synch is done daily and was successful. I don't see any express files in the CCM cache so I don't think it's making it to the PC (1703). I think Microsoft had problems with Express updates and pulled some updates it hasn't worked since then. Any ideas what to look at. Are Express updates working for anyone else?

If you do a new test task sequence - build and capture - it will add the BIOS and UEFI partitioning automatically - so just copy the steps from that. Yes it works Win 10 . I would also add the TS variable OSDPreserveDriveLetter = false after the Partition UEFI step otherwise you may not get letter C: allocated to the disk

Yes ^^^

If UEFI is enabled in the BIOS then it will build UEFI. If it's legacy then it's legacy! Simple as that. The result of this is that you may need to look in to using BIOS tools to automate the BIOS changes. We're going to wait till 1703 is deployed as that has non destructive tools to convert to UEFI (MBR2GPT).

Search your SMSTS.LOG on the Win 7 client for one of the applications e.g. FoxitReader801 and that should show why it's skipping the installation. Oh and use CMTRACE.EXE to make the logs a lot more readable.

Path to the installer is \\servername\sitename\tools\consolesetup.exe There is an MSI in there too so you could probably package that.

If it is not joining the domain it will not install apps. You need to troubleshoot that area first. Most likely either network connectivity (no IP address, no NIC driver, no ping server FQDN etc.) or the account used is not doing the join.

OK found 2 ways round this. Disabling the following group policy: 'Block launching Windows Store apps with Windows Runtime API access from hosted content'. We had set this on recommendation from a PEN test. Also the following unattend settings have the same effect: <settings pass="oobeSystem"> <SkipMachineOOBE>true</SkipMachineOOBE> <SkipUserOOBE>true</SkipUserOOBE> Note: These settings are deprecated in 1703 but work for now.

It was Group Policy - apologies to Gavin1973 who suggested that That's why my first build worked until a reboot - policy hadn't applied to it yet. Not sure which policy is doing this yet - we already had Consumer Experience disabled. Gavin - what's the private store key you changed? p.s. Adding a reboot after the SCCM Client install brought back it displaying the TS progress box during the build.

So you are still missing the driver for the wired NIC. Import the correct one (Win7 x86 or x64 as appropriate) into your driver package and right-click the driver package to update content. You don't need to update the Boot images, just import the driver.

Glad I'm not the only one with this problem! We just updated a test TS with 1703 yesterday and get this error. Strangely the first build I did worked, logged in, all looked good. Then I rebooted and it auto-logged in as defaultuser() - the screen would go blank but I could remotely access it. A few more reboots and the dreaded "Why did my PC restart" appeared. I've since built the same hardware twice with no changes. It completes but goes straight to the "Why ...." screen every time now. It is definitely using UEFI. The drive is definitely C: - Group Policy does not apply during OSD so can't see it's that. Could be as simple as a re-order as suggested above so will probably add a reboot after the SCCM client. I will look at the unattend.xml and upgrading the ADK to 1703 next. I also don't see the TS progress any more, just get "Just a moment..." displayed and a spinning wheel.

Try building from a USB stick to rule PXE in or out as the problem? Try legacy boot on one of the devices to rule UEFI in or out?

It's definitely NIC drivers. There are three drivers in play here. PXE just works as it's embedded in the PXE controller on the PC. Next level is Windows PE - which is where you are failing. You need to import the appropriate NIC driver (x86 or x64) and update the boot images. Whilst looking at the boot image, ensure the command prompt is enabled WinPE. In the part where it's preparing the network you can press F8 to get a command prompt up. If this doesn't happen, in the properties of the boot image you are using go to the customisation tab and tick the "enable command support" option. Last level is the Windows NIC driver. This needs imported as well to match the OS. If that isn't done the build will fail later on, normally when joining the domain.

OK... You say it's doing the drivers. Are you getting an IP address - what does ipconfig /all tell you?