To cut long story short, with RTM (and latest technical previews), the setup.exe switch /migratealldrivers seems not working.

http://winaero.com/blog/windows-10-setup-exe-command-line-switches/

The problem here is, that if I let Win10 to interfer the drivers, Ill get some broken drivers or Microsofts own drivers I dont want. After In-Place upgrade, if I install drivers with pointing plug&play to my SCCM model driver folders, Ill be okay. So during entire process, drivers gets broken one way or another.

I would love to migrate all Windows 7 and Windows 8 drivers, that Windows 10 setup program would not touch it. Same behavior happends, if setup.exe is launched manually from DVD. Specially video driver is a problem here, because Microsofts driver is not usable.

If it's just the video driver you're having problems with, you could create a simple package / program that includes either the vendor's setup files for the video driver. I'm pretty sure that atleast Nvidia, AMD and Intel provide those. You would run this step after the upgrade.

http://blogs.technet.com/b/configmgrteam/archive/2015/06/16/revised-content-for-the-win10-in-place-upgrade-via-task-sequence-for-configmgr.aspx

First, the idea is that there will be no need to create any driver packages or programs to execute driver installations. Otherwise, it would be pointless to use rollouts with In-Place Upgrades, and we could go back to Wipe-and-Load.

That /migratealldrivers doesntt work, Im sure of that now. Probably it was introduced in some Technical Preview version, but its not valid anymore in RTM.

What I did, is to copy existing driver folders and files from SCCM driver share which were imported to Windows 7 installations. This way these drivers will be used during In-Place Upgrades. I can already tell from my today experience, that Intel HD dislplay driver thingy is solved By that.

Still, the question remains, can there be a downside to this use? Is it possible that Windows 10 will pick worse driver from W7 driver share, instead of using its own better driver?

Im qoing to continue the investigation and testing. Any thoughs are much appreciated :) 

ps. also RTM seems to have much more drivers in its own store than technical preview releases.

• Edited by yannara 19 hours 51 minutes ago

Have you already tried this? http://blogs.technet.com/b/configmgrteam/archive/2015/06/16/revised-content-for-the-win10-in-place-upgrade-via-task-sequence-for-configmgr.aspx

First, the idea is that there will be no need to create any driver packages or programs to execute driver installations. Otherwise, it would be pointless to use rollouts with In-Place Upgrades, and we could go back to Wipe-and-Load.

That's a terrible and inaccurate expectation/assumption. How do you expect it to have all of the drivers for every model possible including future models? Supplying drivers will always be a fact of life even for in-place upgrades. Hopefully it won't happen often, but it will happen.

Also, there's no guarantee that the Win7 drivers will work in Win10 so there has to be a way to supply updated ones. Once again, this shouldn't be the norm, but it will happen.

Anything is possible for driver selection but I trust the folks that designed the process were smart enough to add the appropriate logic.

You really should post these questions in a Windows forum though as they have nothing to do with ConfigMgr.

Torsten, yes that is the one Ive been using lately.

Jason, if we rollout 100% machines of a customer organization with In-Place Upgrade, there will be a left-overs /old models, which we will be replacing in a future with the brand new machines. So if an old model will then brake at some point, running on W10, a user will receive newer model deployed via Wipe-and-Load W10.

A device manager with uninstalled devices is unaccapteble situation in In-Place Scenario. And that needs to be solved, or we will get back to the wipe-and-load idea. Somehow this automatization needs to get better.

Jason, since Im using ConfMgr to In-Place Upgrade, naturally Im asking these questions here, lets not argue about this. Driver management is a part of OSD.

The only working process for now Im thinking is, that before running In-Place Upgrade on a spesific group of models, that model will be checked for newer drivers and these will be extracted to Driver Share, which will be provided during In-Place Upgrade, staging the drivers to local drive.

"A device manager with uninstalled devices is unaccapteble situation in In-Place Scenario. And that needs to be solved, or we will get back to the wipe-and-load idea. Somehow this automatization needs to get better."

I don't disagree, but what do you expect here for it to be able to come up with a working driver? It's not magic, you still need to test and provide what it doesn't have by default.

I'm not arguing about where the question belongs; however, you are asking about what Windows 10 does with drivers and so you will get a much broader audience and thus better replies in a Windows specific forum. The in-place upgrade run really has nothing to do with ConfigMgr, ConfigMgr is simply kicking off a Windows process and what happens after that, including with drivers, has nothing to do with ConfigMgr.

My understanding is the /migratealldrivers is not intended to be used for an OS upgrade from previous versions of Windows to Windows 10 but instead to roll out Windows 10 refreshes (going from an older build to a newer build of Windows 10). That's likely why it's "not working" when you try to use it to pull Windows 7/8 drivers during an in-place upgrade: it probably only works against the win10 driver store.

I could be way off here, of course. 

I know there's a feature in USMT 10 that moves apps and drivers as well ... but I've not played with that at all nor am I aware if it's a similar function or completely unique.

That's a terrible and inaccurate expectation/assumption. How do you expect it to have all of the drivers for every model possible including future models? Supplying drivers will always be a fact of life even for in-place upgrades. Hopefully it won't happen often, but it will happen.

Just be clear, Im only talking about current models which now runs W7 and needs to be upgraded. Future models will be "modeled" to W10 traditional way.

With In-Place upgrade, the idea is to diminish all the work, we had to do during XP->W7 rollouts.