A few years back – an (ex) employee posted on the Adexis blog about the fun of Surface laptops and deployment in SCCM
Personally, i’ve deployed a lot of Surface Pro 3’s and 4’s…. but not so much after that…. until now.
During the week i was called into a client to find out why their new Surface Pro devices were not PXE booting.
Once i attended site, had a look at the pxe log – and saw unsupported architecture… strange…. both the boot images are distributed and boot roms are correct…
Upon further investigation and google – i found that the devices were Surface Pro X’s which are ARM based and not supported for deployment via SCCM or MDT.
the TLDR of the article is that the Surface Pro X is not an enterprise device…. the client managed to get devices replaced with Surface Pro 7’s – and they actually got a refund, as the 7 was slightly less expensive than the X….
Onto the surface pro 7’s….
These can be detected in the task sequence via a MWI query of
SELECT * FROM Win32_ComputerSystem WHERE Model = “Surface Pro 7″
Or by using the custom model variable from global conditions….
I prefer having one application with multiple deployments, each with a global condition of model…. this keeps the driver database less cluttered and is, for want of a better term, “neat”.
Issue with this is that the Surface Pro 7 drivers install fine from the MSI, but kill the task sequence…. given the time restraints on this project, i didnt really have time to check… so i extracted the drivers from the MSI, imported them as drivers and allowed auto-apply to do its job.
TL;DR version of the whole article
- Surface Pro X – no you cant deploy it via SCCM and yes it is shitty/confusing naming from MS
- Surface Pro 7 – installing drivers via MSI will kill your task sequence – extract the drivers and install them as part of auto apply or apply drivers instead