h4x0r

I believe the reason is that the RemoteInstalls folder does not get removed simply when the WDS role is uninstalled...as a result, you have an overlap of files that are corrupt and the new ones you need to implement. Don't forget that you need to have both the x32 and x64 images distributed to your DP. Glad I could help!

They do have USB ports, and I had forgotten to mention the USB NIC as a consideration as well. I have not had great success using USB NIC's in the past...as you point out, there will be a limited number of supported devices there. Thanks!

Are you PXE booting these via legacy or UEFI? I have seen instances where if a device is PXE booted via legacy, but is operating with UEFI, that the format drive step can bugger things up and the apply OS step can't find the partition...but, network boot with UEFI and it formats correctly, and the OS is able to apply. Also, there is this thread regarding UEFI PXE booting issues.

A colleague of mine had a similar issue with his configuration. I think we ended up solving the issue by removing WDS (un-check option on your DP to respond to PXE), renaming the RemoteInstall directory (RemoteInstall.old), *edit* re-enable PXE support on the DP, and then re-creating his boot images (he had MDT integration, so we used that). We did this for both x32 and x64 boot images.

Good day everyone, I would like to pick the brain of the proverbial community think-tank here on the forums. The product We are looking at purchasing a number of (what I am calling) WInBooks for students (Dell 3180's, Lenovo N22, etc). These are basically Windows 10 versions of their ChromeBook counterparts. 11" screens, Celeron/Pentium procs, 4GB RAM with 64/128GB SSD's...and wireless only. The IDEAL solution Generally speaking, I think the solution to provisioning these would be using InTune, but that is not on the table due to budgetary reasons. As such, I do not have CM setup as an MDM. The more likely solution Use WICD and create a provisioning package that we apply when the new laptops are first turned on...apply SharedPC settings, wireless profile, domain join, etc. The concerns/problems We like to image things that come in for a number of reasons...cleans off bloatware from the mfg's, install organizational specific software, customize other settings, etc...however, with most of these devices only having wireless cards and no dedicated NIC, it takes a couple more hoops to jump through in order to image them (currently just using a USB drive). Using WICD to create a provisioning package that we apply at first boot is the simplest solution, but it leaves all the mfg's software installed, as well as trial software that gets in the way. Using a USB drive for OSD gives us a clean laptop and software we want installed, but still leaves us needing to do something about the wireless profile and domain join. Theorycrafting My initial thought was to use DISM to apply a provisioning package(s) at various steps in the TS in order to try and automate the process via TS. For example, first apply a package with the wireless profile immediately after the image is applied, and then during the software installs, apply another package with the domain join (no idea if this would work yet, as I have yet to test it)...this would be contingent upon the wireless profile being applied first, and actually connecting to the network during the Install Applications portion of the TS...and I have no idea if that would work. What else should I take into consideration? Has anyone else dealt with something similar? Perhaps there is a more simple solution that I am missing (can't see the forest for the trees)? All input is appreciated! Thanks!

I'm in 100% agreement with you there There are a number of school districts in our state who have inherited a ConfigMgr setup, either due to being a new hire or someone leaving the department, and they get handed management of CM...I am always telling them: test, test, and then test again.

Thanks for this write up, Niall...I was actually getting ready to start work on this very project here This is particularly useful in my scenario, for a number of reasons. I work for a K-12 school and the AD/network structure is...different, from most places. I do not have access to my WSUS server, AND it sits in the DMZ behind my internet filter (don't get me started). The entity controlling the approved patches for Windows 10 has them on a delayed schedule due to the fact that they test all patches first to make sure that they are compatible in our environment. I have the potential to stand up my own WSUS to use with CM, but the short version is that it isn't happening in the immediate future. So in short, I needed a way to upgrade all my 1511 stations to 1607 (or even the creators update) in a controlled manner, rather than letting WSUS hand out the updates and simultaneously bottleneck my internet filter. Thank you for your work on this!

Thanks Tregelen...you mention different approaches...do you mean thick vs thin images being deployed?

Thanks Rocket Man...I agree that 4min seems ludicrous...I'm sure there are things we could do to better optimize our OSD...but there's no way I could bring it down to that. Do you mind if I shoot you a PM with a couple other questions?

Good day everyone, Let me provide some background...I work for a school district, and we use CM for imaging, software deployment, endpoint security, reporting, etc...fairly standard in my book. In a recent session with some other districts, another tech mentioned that they were able to image a workstation in 4 minutes using their FOG server (FOG is a free imaging tool, runs on Linux...look it up if you are curious). Now, there are a lot of factors that could come into play there...network congestion, SSD vs SATA drive, etc...but part of me is sitting here going, there's no way that they have booted, downloaded an image, applied image, and gone through all the "first boot" setup, and be ready to login in 4 minutes. Obviously I have my own idea of what it means to image a workstation...for me it is the process start to finish, with the workstation ready to go at the login prompt. If we're talking about the time it takes to simply download the WIM file, then that's something else. So I'm curious...based on what I just said (start to finish, all software installed, and ready to login), how long does it take you to image a workstation with ConfigMgr? Please let me know if you use SSD's in your workstations or not. Thanks!

Ha, gotta love that I mean, it is a fairly small inconvenience all things considered, but it makes me wonder what the real culprit is.

Well I ran across some interesting information the other day...I forget why I was looking at this thread on reddit, but from what I can tell, this may be the issue: Hyper-V VM's need to Gen 2 for deploying Windows 10 successfully/correctly. I'm using the same VM that I have for years at this point, and hadn't even thought of changing/checking the VM generation. I updated to the 1511 ADK the other day and noted that I was still experiencing the issue. When I created a new gen 2 VM on my workstation, however, it worked like a charm. I hope this helps for anyone else who might run into this issue.

Thanks for the info...I have it on my to-do list to get that upgraded, but have not had the time just yet. I will update to the latest versions of those and see if that makes a difference in my environment.

Reviving a semi-old thread here...I'm also having the same experience with imaging my hyper-V VM with my captured Win10 image. I haven't had a chance to test this on a physical station however. Other thread that I've come across all share the same issue, but there is never a defined resolution. Has anyone made progress on this?

I would start by checking your site and component status to see if there is anything that needs to be resolved there.