A few years back – an (ex) employee posted on the Adexis blog about the fun of Surface laptops and deployment in SCCM
https://blog.adexis.com.au/2018/04/09/microsoft-surface-laptops-and-sccm-os-deployment/#comment-1478
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.
https://docs.microsoft.com/en-us/surface/surface-pro-arm-app-management
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