mudkips

This turned out to be as simple as hitting enter as soon as " Succeed to download NBP" was displayed. I've added a PXE response delay to give us time to hit enter, but there's still no indication that you have to do so in order to continue with the network boot. I'm not sure why it fails on a VM, but it works for a physical machine.

I've tried defining the vendor classes and policies as described in the video, but I've had no luck. I've also tried removing all of the DHCP options (60, 66, and 67) as well as defining 60 and 67 only (setting 67 to smsboot\x64\wdsmgfw.efi), but every combination results in the same 0xc0000225 error for a UEFI PXE booted VM, and the same "Succeed to download NBP" message (and then nothing) for a physical machine. Could this be an issue with the boot image? The PXE booting process loads boot.sdi instantly, then proceeds to load the x64 boot image. This boot image was created using the "Create Boot Image using MDT" option within SCCM since the existing boot image broke after the upgrade to SCCM 2012 SP2 CU4. The boot image works fine for BIOS booting. I get the same result if I import a new x64 boot image using winpe.wim from the Windows 10 ADK and use that as the boot image on the task sequence (and again, deploy it to the group so it's loaded by the client). I did find out from Resource Monitor that during the UEFI PXE process, C:\RemoteInstall\SMSBoot\x64\bootmgfw.efi is accessed (but I didn't see an access attempt for wdsmgfw.efi).

I can add an account and add it to the local administrators group during audit mode, and that works fine. Doing this also prevents the defaultuser0 account from being recreated during deployment. This will be my workaround for now, I guess, through we'd prefer to enter OOBE after the task sequence applies the image (or have the actual administrator account available).

I'm trying to set up a task sequence to deploy Windows 10 via PXE. We have SCCM 2012 SP2 CU4 running on Server 2012 (not R2), with WDS 6.5.9200.16384, ADK 10.1.14393.0, and MDT 6.3.8443.1000. It's s single site and single server. I'm building the image from the official v1607 Enterprise ISO in a VM, entering System Audit Mode and doing some minimal config, and then using a freshly-built SCCM Capture Media ISO to handle the sysprep and image capture. Once captured, I create a basic (non-MDT) task sequence and deploy it as available to the unknown computers group for media and PXE only. If I have the task sequence join the domain and install the Configuration Manager client, everything works fine. I end up with an inaccessible defaultuser0 account on the machine, but I can log in with a domain account and do what I need to do / give it to a user. However, if I have the task sequence not join the domain, then I can't log into the machine after the image is deployed. It does the specialize pass and then does the "checking for critical updates" step, reboots, and then it gets to a login screen for "defaultuser0" and I can't log in. I've checked on the source VM after another fresh build from the installation ISO, and the defaultuser0 account seems to get created as part of the Windows 10 Enterprise v1607 installation. Even if I delete this account before capturing the image, the defaultuser0 account shows up after deployment. (We do everything in system audit mode and do not create any accounts.) I've tried setting the options within the task sequence to enable the admin account and set the password, but it's still not enabled and I can't do anything. If I try restarting in safe mode or enabling the command prompt, the only account listed/selectable is "defaultuser0" and I can't log into it at all. I've also tried adding net user command line steps to the task sequence to add a new local user and add it to the local administrators group, but this causes the task sequence to fail with 0x00000002. The task sequence that doesn't join the domain also does not install configuration manager - this task sequences is for machines that will be off the domain and off the network and not centrally managed. My guess is these steps can't run in the WinPE environment, but I was unable to find any relevant info in the smsts log. If I could get the task sequence / capture media to trigger the standard OOBE, I think that would work fine for our purposes. But I don't know how I can do that. The capture media doesn't seem to have any options I can control for the sysprep step. Could I just remove the "Apply Windows Settings" step in the task sequence entirely to achieve the same result? Again, we're not using MDT because this is a simple, bare bones image and task sequence. Our goal is to PXE boot and install Windows 10 Enterprise with updates and a few applications pre-installed. For domain-joined machines, they get policy after booting into the OS and get all the other stuff that they get. For machines off the domain, all we need is access to a local admin account so we can log in and do a light touch config, depending on each user. If this isn't possible without MDT, then we'll look at creating the MDT packages and task sequences. Thanks.

I'm trying to set up a task sequence to deploy Windows 10 via PXE to both UEFI and BIOS clients. We have SCCM 2012 SP2 CU4 running on Server 2012 (not R2), with WDS 6.5.9200.16384, ADK 10.1.14393.0, and MDT 6.3.8443.1000. It's s single site and single server. PXE booting to BIOS clients seems to work fine. When PXE booting UEFI client, it loads the boot file and then throws out 0xc0000225 complaining about \Windows\Syetem32\boot\winload.efi . We're deploying the task sequence to the "Unknown Computers" group, and we only care about x64 clients. The task sequence has an x64 boot image, and is the last task sequence deployed. Do I have to do something special to allow both BIOS and UEFI clients to boot successfully at the same time (and using the same task sequence)? I came across this video which sets up policies and defines different files to load based on vendor class, but I haven't tried any of it yet. We're using SCCM and not WDS directly, so I wasn't sure if it was appropriate. Our DHCP server is the same as the SCCM site server, as well. The only DHCP options I have set are 003 (Router), 006 (DNS Servers), 015 (DNS Domain Name), and 060 (PXEClient). Thanks.

Well I've decided to just grab the client via manual check of Windows Update (for any random things we don't do via PXE OSD). So my Windows Update Group Policy now just has the update server specified, and nothing else configured, as per this image: But it looks like this results in machines getting the default Windows Update settings applied. A 22 hour detection frequency, a daily install at 3 AM, and automatic reboots (even with logged on users). What is the proper way to disable the Windows Update stuff and let SCCM's SUP role handle everything? We currently have a Patch Tuesday ADR that is set to evaluate on 2 PM of the 2nd Tuesday in each month (the SUP syncs at noon and midnight, daily). Deployment is as soon as possible, and deadline is 4 hours after. This way users get notified around 2 PM, and the deadline is 6 PM. The User Experience tabb is set to allow installation outside of maintenance windows, but not restarts. Restart behavior is NOT suppressed. We have a maintenance window of 2 AM to 5 AM every Saturday. We expect: Users to be notified of updates a little after 2 PM on Patch Tuesday. Installation to start a little after 6 PM on Patch Tuesday (or earlier, if the user triggers it). Restarts to happen on the Saturday after Patch Tuesday, between 2 AM and 5 AM (or earlier, if the user triggers it). Should we configure additional items to the Windows Update GPO (disable scheduled installation, disable automatic restart with logged on users, or just disable automatic updates)? Or would this break SCCM SUP / WSUS pushing out updates / scheduling installations at the deadline / scheduling restarts during the maintenance window? This came up because a machine rebooted this morning at 3:15 AM, and I checked windowsupdate.log and Windows Update was the culprit. We didn't expect this machine to reboot until Saturday morning. The other machines were manually restarted during the day - we're still testing so we only have a few machines. The servers of course have the default option set to not schedule installation. Thanks

I have a question about using the Software Update Point to push out the Congifuration Manager client. I've enabled this option in SCCM, and I've set up a GPO so that all domain machines point to the WSUS/SUP site. "Specify intranet Microsoft update service location" is Enabled with both fields set to http://machine.domain:8530 . But I want all domain-joined machines to automatically install the configuration manager client. What I've done to achieve this is set "Configure Automatic Updates" to Enabled, with the options "4 - Auto download and schedule the install", "0 - Every day", and "12:00". The current behavior we're seeing is that while the client is automatically installed as expected, updates cause a restart prompt from Windows Update (once with a countdown timer) in addition to the "Recently installed software requires a computer restart" tray icon from Softare Center. I suspect "Configure Automatic Updates" being Enabled is the cause of this. I've read elsewhere that I should set this option to "Not Configured" so SCCM's SUP can control updating. Is there a way for me to have Windows Update (via the GPO) automatically install the Configuration Manager client without messing with SCCM's SUP control of it afterward? If not, should I just set Configure Automatic Updates to "Not Configured" in the GPO, and manually check updates once for machines joining the domain? I would likely manually check anyway since any machines manually joined to the domain would have to wait to 12:00 (or whatever time I specify) to automatically get the client. If I'm manually joining a machine to the domain I may as well manually click on Windows Update once. And of course, most machines will be deployed via SCCMs OSD stuff via PXE booting. Thanks