Today’s blog post is a collaboration between our PFE group and premier support. Joao Botto (PFE), Kyle Blagg (PFE), and Scott McArthur (Support) are writing about their favorite device. You will see this post in the askpfeplat and askcore blogs.
Some of you may know that we launched Surface Pro 3 before its gigabit network adapter and Docking Station were available, and that has led to some customers experiencing issues such as:
· Slow PXE performance downloading a boot.wim
· Surface Pro 3 not charging when in docking station
Both of these issues are due to older firmware. When you unbox a Surface Pro 3, there will be newer firmware available, due to the time difference between when the device is manufactured and finally makes its way to you.
This post focuses on the Surface Pro 3, but this same process can be utilized on the Surface Pro and Surface Pro 2 (but not the Surface RT/Surface 2 devices).
If you are deploying a custom image using Microsoft Deployment Toolkit (MDT), System Center Configuration Manager, or other deployment tool you may want to address these firmware issues before you deploy your custom image. We have developed a method to use a USB Windows PE drive that automatically updates the Surface firmware when you boot with it.
Other possible workarounds, instead of using the method describe in this blog post are to have a boot.wim on a USB drive instead of PXE, or go through OOBE and immediately use Windows Update to apply the latest Surface drivers/firmware.
Introduction
Firmware updates reprogram the chips inside your device, making it better than ever before. They are shipped in what we call capsules, but they look like regular drivers:
If this interests you, check out the blog post from the Surface Team about how Windows Update Makes Surface Better
Before you start this recipe you will need the following ingredients:
- Latest Surface Pro Firmware Updates from the driver pack
- Windows Assessment and Deployment Kit (ADK), specifically the Deployment Tools and Windows PE components of this kit
- A USB flash drive
IMPORTANT:
· Do not try to update the Touch Firmware using this method.
· This guidance will not work if the Surface Pro disk was formatted (and a new Operating System wasn’t loaded) or if the disk is encrypted.
· To prevent accidental device shutdown, the firmware updates will only be applied when the device has 40% or more of battery. We strongly recommend you fully charge your battery before proceeding with the firmware update.
Drivers
Extract the Surface driver pack you previously downloaded, and select the EC, SAM and UEFI firmware updates. All these firmware capsules are in the Microsoft > FW folder.
Copy the EC, SAM and UEFI the firmware files to a folder. In my example I called this folder Pro3 and put it in C:\SurfaceFW\Pro3
Reminder: DO NOT try to update touch firmware using this process.
Windows PE
From the ADK you must make sure you have installed the Deployment Tools and Windows PE:
From that point you will have the Deployment and Imaging Tools Environment (which is essentially a command line window with additional tools in the path). Run it as Administrator.
At this point you're ready to start preparing a version of Windows PE x64 that will be used to update the firmware. It's very important to use the x64 version since x64 UEFI isn't able to load an x86 OS.
When you install the ADK the default folder (on a x64 install of Windows) for Windows PE is C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Pre-installation Environment
In that folder you will find the WinPE images for x86 and x64, and some scripts that make the creation of a WinPE flash drive extremely easy.
Change directory to this folder: cd "C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Preinstallation Environment"
From the elevated prompt you will have to start by running the first script by executing the command copype amd64 C:\WinPE_amd64 to place the original WinPE image in that folder.
Then you will use the same elevated prompt to run MakeWinPEMedia /UFD C:\WinPE_amd64 E: (the E: drive is my flash drive, which will be reformatted, and C:\WinPE_amd64 is the working folder I supplied in the previous command).
The first step is to create a folder (in my case c:\mount), and then mount the mount the WinPE image using this command: dism /Mount-Image /ImageFile:E:\sources\boot.wim /index:1 /MountDir:c:\mount
Then you should inject the firmware updates into Windows PE: dism /Image:C:\mount /Add-Driver /Driver:C:\SurfaceFW\Pro3 /Recurse
You should see all firmware updates being successfully injected.
Note: Make sure all three firmware updates were successfully injected into Windows PE. You should see the “The driver package was successfully installed” message like in the example above.
To unmount the WinPE image just run the following command:
dism /Unmount-Image /MountDir:C:\mount /commit
You can now boot to your new WinPE environment by plugging the flash drive to your new Surface Pro (while it's turned off) and then start the device with Power + Volume Down. Keep holding the volume down button until a few seconds after your device displays the Surface logo. Once WinPE loads, you'll see a blank screen and a command prompt will automatically process the updates.
The firmware will be updated without any user interaction and your Surface will reboot automatically when it’s done. You will then see “Please wait while we install a system update” for a few minutes and your Surface Pro 3 will reboot again when it’s ready.
If you want to validate that the update was successful you can boot into the UEFI settings (start the device by pressing Power + Volume Up) and look under device information. If you see the Asset Tag field that would indicate your UEFI firmware was updated from the version that shipped in the original image. Over time this method may not be usable for validation since at some point the image that is shipped with the device will already have this version of the firmware by default. Another option for validating firmware versions is to press Shift+F10 at the first page of the OOBE and open devmgmt.msc to check the firmware versions. Note: If you use this process to update the firmware and then goto Windows Update, you will likely see a firmware update offered. This is normal. The firmware is updated but the driver currently installed is not up to date. The offered update will install the driver that shows the updated firmware
We will be improving this process over time so look for updates to this blog for some additional features such as automatically checking for battery level and other ways to determine the firmware was updated.
Scott “I fix all Surface Issues” McArthur, Kyle “my Surfaces are on TV” Blagg, and Joao “let’s do it!” Botto
Neverest, I just followed this guide and the drivers were injected without any signature issues. Can you redownload the driver pack and try again?
ccatlett1984 you are right, the firmware updates can be added directly to the boot image.
Some drawback that I can see from loading the fw updates directly into the boot images:
– if you are experiencing very slow PXE boot you probably want to quickly update the fw before starting the deployment
– not everyone is using MDT/Configuration Manager
– harder to maintain boot images like this
James F Horvath hopefully this will make your next deployments easier.
JustMe most Surface Pro devices that you buy today will already be up to date in terms of firmware. If the Asset Tag field is even there – which seems the to be the case for you – it means you won’t run into any of the issues mentioned in the introduction
of this post
Jethro Rose, we have been shipping devices with updated firmware for a while now. And internally we deploy very large numbers of Surface Pro 3 every day.
I would love to hear some feedback that you may have, but at this point I am not sure I understand what issue you are running into.
Obrigado Joao
Also, needing to use a different docking station for each new deployment is a little silly.
Seems like the MAC address of the LAN connection comes from the MS SPro3 Docking station, which means that SCCM can’t use that dock again for deployment.
I would like to use 1 docking station for deployment, or perhaps a different device. Any suggestions?
And apologies in advance for asking here in the comment section, but this is real word issues and I hope someone can stumble upon these in the future and they can find some use out of these comments 🙂
Xiao
Victor
Hi Joao
As Jethro Rose is saying, the issue that we are having is when deploying Win 8.1 to the Surface Pro 3 using SCCM, you have to ‘Import Device Information’ into SCCM before you can do deployment. You need the GUID or the MAC address of the Surface Pro 3 before
you can do that. The Surface Pro 3 does not have this information on the box, which means that you have to boot up the surface pro 3 and check the device information inside the UEFI, which is a bit of a hassle, especially if you have to ask users in remote
locations to get that information for you before you can deploy. I hope you understand.
How do you import the device information into SCCM? Do you have a different method? Or do you not use SCCM for deployment?
Thanks
Victor
JustMe, we have seen that behavior when the device was already up to date. Is that not the case for you?
If your Surface Pro needs to be updated it will reboot automatically once it gets into that command prompt and will run the firmware updates.
De nada Victor Oelofse 🙂
I wrote another blog post specifically on the subject of SCCM records being tied to MAC Addresses. Have you checked this one:
http://blogs.technet.com/b/askpfeplat/archive/2014/07/28/how-to-use-the-same-external-ethernet-adapter-for-multiple-sccm-osd.aspx ?
Searching for driver packages to install…
Found 3 driver package(s) to install.
Installing 1 of 3 – C:SurfaceECFirmware.inf: Error – The driver package contai
ns x64 boot-critical drivers, but the drivers are not properly signed.
Use the /forceunsigned option to install the drivers.
Installing 2 of 3 – C:SurfaceSamFirmware.inf: Error – The driver package conta
ins x64 boot-critical drivers, but the drivers are not properly signed.
Use the /forceunsigned option to install the drivers.
Installing 3 of 3 – C:SurfaceUEFI.inf: Error – The driver package contains x64
boot-critical drivers, but the drivers are not properly signed.
Use the /forceunsigned option to install the drivers.
Is 01:00 in the night and I am using the forceunsigned option and praying, as I am supposed to deliver 14 Surfaces to sales 12.00 tomorrow (today)…
Any idea why this happens? I am also unable to add a lot of the drivers from the "Surface Pro 3 – October 2014.zip" to the 2008R2 WDS-driver store, with similar Certificate issues.
Thank you Christophe and SP3 Guy. I’m glad this is useful
I used the forceunsigned and the Surfaces got updated just fine (thanks for guide!). I downloaded the pack twice, once for my WDS server and once on my desktop. On the WDS server, 33 of the x64 drivers fail to to install, but looking at the certficates
on the packages, they look just fine. Something weird going on here, but I am too much of a zoombie to figure it out now. Thanks for rechecking for me.
Twothumbsup, did you try deploying an OS? That should solve the issue as it seems like the device is trying to boot into Windows, but there is no Windows installed
Nothing like Mount-Image, Add-Driver, Unmount-Image, to keep latest drivers for your .wim images updated. Like you mention in this article, remember to add the "/Commit" switch when Unmount to consolidate the changes in the image. Great article!
Victor Oelofse, now I understand your issue.
Most of my customers are advertising to the unknown computers and use PXE. Therefore they do not run into the issue you just mentioned.
I will pass on the feedback to the Surface team.
Thank you audiocode. I’m glad you enjoyed it
Thanks for getting this out, as I’ve been supporting a number of early adopters who’ve been bit by the GigE firmware issue when trying to push an image.
I followed the above steps. It seems like it all worked properly except when I booted into the flash drive from a Surface Pro 2 stuck into a loop of rebooting itself with a a message "Please wait while we install a system update". Any ideas what would
be causing this? The Device doesn’t an OS on it. As I diskparted the HDD prior to this.
I am deploying Windows 8.1 to the Surface Pro 3 using SCCM2012R2. I have updated the driver package with the January 2015 drivers. After deployment I am still shown the System Hardware Update 1/15/2015 from Microsoft Updates.
The .cap files in c:windowsfirmware are ECFirmware.38.7.50.0.cap, SamFirmware.3.9.350.0.cap, TouchFirmware.426.27.66.0.cap and UEFI.3.11.450.0.cap.
From the blog – "If you use this process to update the firmware and then go to Windows Update, you will likely see a firmware update offered. This is normal. The firmware is updated but the driver currently installed is not up to date. The offered update will
install the driver that shows the updated firmware"
Does the January Driver package not have something in it so that I have the correct drivers or am I missing something else?
Thanks
Dave
My device also is into a loop of rebooting itself with a message "Please wait while we install a system update". If I remove the USB thumb drive and try to PXE boot it just goes to the UEFI screen. How many reboots with the USB drive should it do before
the updates have been applied? I am unable to put an OS on the machine unless I PXE boot. Thanks.
Hi this is Scott McArthur and I just wanted to call attention to a blog that I worked on with some of
Hi this is Scott McArthur and I just wanted to call attention to a blog that I worked on with some of
I’ve ran through this twice and it doesn’t update anything. When I boot from the USB it launches a cmd window with the line “x:windowssystem32>wpeinit” it then waits a few seconds then does a carriage return to “x:windowssystem32>” and just sits there.
Nothing happens automatically. Is there anything I can do from here manually to get the updates to take?
oh, maybe it is the latest. The published date on the update is 10/6/14 and I’m pretty sure I received my Surface about that time. Also, do you know the latest firmware version? Above it just says " you see the Asset Tag field that would indicate your
UEFI firmware was updated from the version that shipped in the original image" When I go into the UEFI configuration the only thing that I can see that says any version is at the bottom of the screen – 2.16.1243 and when I go into Device Information I see
"System UUID", "Serial Number" and "Asset Tag" and that is 0, nothing with version information like the above says. Thank you!
215 Microsoft Team blogs searched, 50 blogs have new articles. 129 new articles found searching from
Thank you for this great tutorial. Worked fine for me.
This is a good article. It will help to expedite the build process, especially in the case you spiked out. Having a pre-OS deployment solution makes sense and is something that lots of vendors do, so it’s good to see that MS is following the same course.
You can accomplish the same thing inside MDT, just add the above "drivers" do your winpe driver profile.
This is a complete shambles, and I can not believe that Microsoft released, and is still shipping Pro 3s like this.
I also can not believe that the MAC address is not on the docking station’s box.
Do you guys actually deploy your own hardware? How am I supposed to just have boxes delivered straight to the end user, plug the details into config manager, and have them network boot it?
I need to get the wireless MAC address for the surfacepro3 without turning it on. How can I do this
Hi Joao
As Jethro Rose is saying, the issue that we are having is when deploying Win 8.1 to the Surface Pro 3 using SCCM, you have to ‘Import Device Information’ into SCCM before you can do deployment. You need the GUID or the MAC address of the Surface Pro 3 before
you can do that. The Surface Pro 3 does not have this information on the box, which means that you have to boot up the surface pro 3 and check the device information inside the UEFI, which is a bit of a hassle, especially if you have to ask users in remote
locations to get that information for you before you can deploy. I hope you understand.
How do you import the device information into SCCM? Do you have a different method? Or do you not use SCCM for deployment?
Thanks
Victor
Voici la suite (Part 3) de la procédure de déploiement de la surface Pro 3
Les différentes
Why are we not supposed to deploy the Touch firmware this way? I’ve seen a couple of TechNet blogs with this warning but absolutely zero information to back up the warning. A little perspective would go a long way.
Good stuff here. I’ve got two questions:
1) What happens if some buffoon boots a Surface with newer firmware than what’s injected into boot media created this way? Does the device get the older firmware, or is it smart enough to not go backwards?
2) Do you know of any way to query WMI to get the current version of each of these three firmware devices? Win32_BIOS.SMSBIOSVersion seems to line up with the UEFI firmware but I haven’t had any luck finding the others. I’d like to write some powershell and
use pnputil.exe to install the updates where needed, but don’t want to have to worry about installing an old firmware over a new one.
Scratch that, I just answered my own question. The version is in win32_pnpentity.hardwareID
Thank you for your help, worked great!!
Hello, Why is it that after having Windows is Reinstalled the firmware does not stick, Or is this just happening to me?
Same here – I saw the same updated has requested to reboot and installed multiple time. 2 times as firmware update and 2 times as hardware update, wth
Overview: A recent firmware update for the Surface Pro 3 now allows you to set an asset tag field in
I Could not get the surface pro 3 to boot from USB / USB Network adaptor
To choose bootup device: Reboot holding shift down, then it enters a menu where I could choose to boot on USB. This only worked when rebooting before logging on.
OK .. Appreciate the effort going into doing this but have a few issues.
SCCM 2012 sp2 CU4
OSD TS
PKI infrastructure.
1:
Our SP3 devices come out the box with the Date 6 months out, this in the initial instance causes a failure as once the device has pxe booted it looks for the the deployed TS and can’t find one due to the dates being so far out.
With other devices like laptops and desktop the bios could be manipulated in a pre-stage task to sync the bios date, is can’t be done on the SP3 to my knowledge.
2:
The flashing of the firmware on the above mentioned devices tends to do nothing at all unless we delete the secure boot keys first, then run it. I have seen the blue screen with cmd prompt and know that means its at the same level.
All our device are missing the advanced section in the bios so must not be the latest issue.
Any Ideas on the date issue ??
Cheers
Chris
Today’s Tip… Updating Surface Pro Firmware Offline If you watch the forums, you likely saw posts regarding
Hi Mark
Unfortunately this process is broken at my end. I get as far as applying the update to the image, but the most recent updates are UNSIGNED from Microsoft, so dism tells you that you have to use the /forceunsigned switch.
Ok, that works but each and everytime I try to dism /unmount-image , it succeeds 100%, but at the very end, it throws an error 0xc1420117 no matter what I do. Needless to say, the USB stick will boot WinPE, but nothing happens. I can’t get any of the drivers
to update.
So, the 100-dollar question is, why is this so difficult? Is there some stand-alone executable I can use to at least get the UEFI bios updated like all other manufacturers? If not, why not? It seems my choices are buying a Server 2012 license and going the
SCCM route or this broken WinPE option.
@Reddgum, We developed this method to update the firmware for the SP3 to resolve some PXE and dock issues so that enterprises could deploy via PXE and/or through the dock. Any new devices will already have the updated firmware that resolved these issues.
Using this method shouldn’t really be necessary anymore. Just add the latest drivers/firmware as part of your OS deployment process.
After the april firmware update of the Surface Pro 4, some units have a problem with the fan, which is continuously running even when in sleep mode. Do you think this method could be used to make a rollback of firmware of a surface 4 to a previus version?
Thank you
Hi there. Been struggling for many days to overcome the ‘won’t boot from USB’ problem, and done all of the approaches, Rufus, FAT32, BOOTME, turning off secure boot, side USB on and off, take out microssd etc etc, volume down boot and on and on. and I conclude that as it ‘used to work’ a version of firmware has broken this feature.
Do you know if the latest version of firmware actually resolved this issue? Otherwise is there a way of getting right back to the original first version of firmware that came when I bought my pro 3?
Pulling out my hair
I get this error every time I try to run MakeWinPEMedia I have tried 3 USB thumb drives anyone know what i am doing wrong?
C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Pr
einstallation Environment>MakeWinPEMedia /UFD C:\WinPE_amd64 D:
WARNING, ALL DATA ON DISK DRIVE D: WILL BE LOST!
Proceed with Format [Y,N]?Y
Formatting D:…
ERROR: Failed to format D:; DiskPart errorlevel -2147024809.