In order to successfully deploy the Microsoft Surface Pro 3 with SmartDeploy, you'll need to use SmartDeploy version 1.1.5010 or later.
Additionally, this UEFI Class 3 device automatically adds a BCD firmware entry for any present bootable USB media on each boot. This means that even with the UEFI "Alternate System Boot Order" set to "SSD Only", the machine will still boot to a bootable USB device on each boot.
Therefore when deploying the machine via offline USB media, the machine would reboot back to SmartDeploy once the image had been applied and the machine rebooted for the first time. Not only is this not desired, but it causes an issue with the deployment if you then remove the USB stick, reboot the system, and let the deployment continue.
To this end SmartDeploy 1.1.5010 adds an additional Deploy Wizard advanced feature to shutdown the machine when the Deploy Wizard ends. By selecting this, it will provide a chance to remove any bootable media, and then power on the machine. The deployment will then continue and complete successfully.
If you use PXE boot either from the USB dongle adapter or the dock, and there is no USB boot media present, then you can let the machine reboot as normal.
If you have any issues, please contact us at SmartDeploy Support.
If you are using VMware virtualization products to build reference computers with SmartDeploy, and you want to create a Windows 8.1 or Windows Server 2012 R2 image, you'll need to follow these instructions.
Through testing, we have noticed inconsistent shut down results from within VMware products. When using the Capture Wizard to subsequently capture an image of that machine, the resultant image file does not contain full metadata. If you then attempt to deploy this image, it will result in the following error. "The Platform Pack has support for this computer manufacturer and model, however it does not contain support for this operating system."
As such, prior to capturing an image of a SmartDeploy reference computer that was created using VMware products, you need to do one of two things:
If you are using the Capture Wizard while the machine is powered off you must first perform a full shutdown of the VM. From a command prompt, run “shutdown.exe /s /t 0”. Or, you can use the Settings charm, Power, and then hold down the Shift key while clicking Shut down.
Most customers use VMware Player or Workstation in this fashion.
If you are using the Capture Wizard while the machine is powered on, you must first license and activate the virtual machine.
Many customers use VMware ESX in this fashion.
Microsoft is doing some pretty cool things within Windows 8 to allow you to Refresh and reset your PC to a known good starting point. This should be a much cleaner WinRE implementation than the PC Manufacture's implementations with Windows 7. It also appears to have given us USMT Hard-Link Migration for the masses.
In this related article, talking about improvements in Windows Setup, and more specifically about the new web based purchase/download/upgrade process... they mention the following:
“After this optimized package is created we compress it using an improved compression algorithm specifically for Windows 8 setup, which provides an additional 28% savings. In this example (using the Windows 7 x86 ISO) the size of the download would be reduced from 2.32GB to 1.51GB.”
Considering that the install.wim is nearly 90% of the ISO size, this seems incredible. There has to be some new .wim trickery, since modern compression algorithms run against .wim only produce low single digit percentages.
Here is a list of some of the changes and enhancements in the SmartDeploy 1.1.1920 release.
1803: Ensured all Deploy Wizard, Advanced Options, System Properties work properly.
1812: Allow for multiple Domain's & OU's in answer files
1813: Fixed crash when selecting an image file for deployment that was being copied to
1819: Added messaging if attempting to capture Virtual Box with guest additions installed
1849: Fixed post image task pointing to a missing file causes error
1815: Provide better driver injection status during deployment
1836: Enhanced error messaging when handling corrupt platform packs
1858: Fixed first logon task not running on Windows XP in certain scenarios
1837: Resolved warm capture not working with certain partition layouts
1844: Resolved program self-repairing under certain conditions
1817: Resolved License Wizard false expiration errors in certain conditions
SmartDeploy stores the device drivers for Windows PE in the platform pack for a given model, where necessary. This is to help easily facilitate creating boot or deployment media that supports the network and mass storage for that device.
SmartDeploy versions prior to 1.1.1910:
---Windows PE 2.1
We only add Windows PE drivers if necessary for a given model. This is because many models are covered for both networking and mass storage by the in-box drivers in Windows PE. When we changed from Windows PE 2.1 to Windows PE 3.0, many of the old Windows PE 2.1 drivers were simply removed from the platform packs because Windows PE 3.0 now has in-box support for those devices. Other packs had their Windows PE drivers updated to Windows 7.
The Windows PE node of a platform pack is only used during the Media Wizard, when you are creating boot media or offline deployment media. The other actual OS nodes of the platform packs, i.e. Windows XP or Windows 7 did not change.
Q: I installed SmartDeploy 1.1.1910, and created boot media using my existing platform pack. When I boot my target device, there is no networking. Why not?
A: You need to download and use latest platform packs available from SmartDeploy.com and re-generate boot media with the Media Wizard.
Q: Will my existing combined platform pack work with SmartDeploy 1.1.1910?
A: Since the OS nodes did not change, deployment will work fine. However, you'll need new platform packs if one of your devices requires networking or mass storage support, and it is not present in your boot media.
Q: Will the new platform packs on SmartDeploy.com work with versions of SmartDeploy prior to 1.1.1910?
A: They will work for deployment, but not for creating boot media or offline deployment media with the required networking or mass storage support.
Q: I've spent a lot of time making my single combined platform pack support all my models? What do I need to do update it for use with 1.1.1910?
A: Explore your combined platform pack and see how many "Windows PE 2.1" nodes there are under each one of your models. These are the models that will need to be updated. You can delete these from your existing combined pack, download the new versions, and import them into your combined pack.
For years people have struggled with the best way to capture and share dialog boxes or other objects they see on their computer screen.
The old tried and true method: PrtScn & Alt+PrtScn
The PrtScn button by default captures the entire desktop, and using Alt+PrtScn captures only the active window on the desktop. This is a good start to get what you want captured. You can then open the Microsoft Paint application (mspaint) and paste in what you have captured. The trick here is to make the area in Paint that you’re about to paste into smaller than what you are pasting, this way the resulting image will be exactly what you captured and not have any white space. This works fine, but what if you want more than one window, but not the whole desktop? You have to capture the whole desktop, paste it into Paint, then select just the area you want, copy that, create a new instance of Paint and paste it in. So, it can be done… but it’s tedious. The obscurity of this process and the desire to have more functionality has led many people to purchase 3rd party software like Snagit. While these 3rd party tools aren't that expensive and provide a lot of functionality, I think many people end up purchasing them just for basic functionality.
Microsoft steps in: The Windows Snipping Tool
With Windows Vista and Windows 7, Microsoft includes a handy utility for screen capture called the Snipping Tool. It's installed by default in almost all versions of Vista and 7, other than the basic and lower editions. Its part of the “Tablet PC Components” so if you can’t find it, be sure those components are installed under Windows Features. The easiest way to launch the Snipping Tool is to use Windows Vista and Windows 7’s built in search. Click the Start Button, type in “snip” and it should be at or near the top of the list. Or, if you really just want to go to it, it sits under All Programs, Accessories.
By default the Snipping Tool opens to a rectangular snip, in which you can draw a rectangle around anything you want and it will capture it. There are other options…
The Windows Snip option is much like Alt+PrtScn, but can capture any window you hover over and highlight. There are also configurable options…
With Windows Vista, probably the first thing I like to change is that by default all captures have a red ink boarder. So if you uncheck the "Show selection ink after snips are captured”, that won’t happen anymore. In Windows 7, this is unchecked by default. Also, here lies another neat feature. By default the Snipping Tool is set to “Always copy snips to the Clipboard”. With this, if you really just want to paste what you’ve captured into another program, you don’t have to save the capture first because it’s already in the Clipboard. For example, you can snip something and then just paste it into an IM conversation or email to share it with someone.
Editing tools after capture are fairly limited. You can highlight, use a pen to draw, or directly email the capture. Beyond this is where you would really need a more fully functional 3rd party application if you wanted to resize, add text, or other graphics.
In Windows Vista both Paint and the Snipping Tool default to saving their files as JPEG’s. However, in Windows 7 they have switched both to default to PNG’s. Microsoft has always bounced back and forth on this, but I prefer PNG’s, so I like that they have gone that direction with Windows 7.
In a follow-on to my previous “Windows 7, BitLocker and Recovery” blog, I was wondering what would happen if you installed Windows 7 to an existing partition so that you ended up with a single partition instead of two, and then ran the BitLocker wizard. Or, if you made a 300MB active partition in the beginning of the disk and then told Windows setup to install to the free space.
In the “Hardware requirements for BitLocker Drive Encryption” section of the Windows 7 Help and Support, it states that the system partition must be at least 200MB. Then in the “Set up your hard disk for BitLocker Drive Encryption” section it states… “If your computer does not have a system partition, the BitLocker wizard will create one for you using 200 MB of available disk space.”
Yet the BitLocker wizard follows the Windows PE User’s Guide recommendation of 300 MB. Plus, it moves and reconfigures the Windows Recovery Environment from the boot drive to the newly created system drive.
Let’s summarize what you end up with the 3 scenarios:
Perform a clean install from the Windows 7 product DVD, enable BitLocker after installation.
Install from the Windows 7 product DVD to an existing single partition, enable BitLocker after installation.
Pre-create a 300MB active partition, have Windows setup install to the free space, enable BitLocker after installation.
These are significantly different outcomes. It really makes me think that it was a mistake not having Windows setup create a 300MB system partition and locate the Windows Recovery Environment there from the beginning. Or, maybe Windows setup shouldn’t even bother pre-creating the 100MB system partition. What is funny is that all SKU’s of Windows 7 create it, yet only Enterprise and Ultimate contain BitLocker. BitLocker is the one product feature that really requires two partitions. I could see if the Windows Recovery Environment was located in the 100MB partition by default, but it isn’t.
Having the 300MB active/system partition at the beginning or end of the drive could really be personal preference. If you ever wanted to have a recovery image stored locally on the machine, much like the OEM’s do, then having the 300MB at the beginning makes some sense. This allows you to then have a third partition at the end of the drive large enough to hold your image. I’m going to go with a 300MB system partition at the beginning, and then the BitLocker Wizard doesn’t have to shrink an existing partition later.
Windows 7 has greatly improved and simplified the process of setting up BitLocker and the Windows Recovery Environment. In fact both the separate partition structure required for BitLocker, and the automatic failover to the Windows Recovery Environment are setup by default in Windows 7. With Windows Vista neither of these were setup up by default. With Windows Vista the guidance from Microsoft was to create a 1.5GB system partition for BitLocker, and this is exactly what the BitLocker Drive Preparation Tool did. 1.5GB was plenty big to hold the system files plus a Windows Recovery Environment. But, it oddly still fell short of being able to hold a recovery image of any kind since the base install.wim for Vista Enterprise 32-bit is over 2GB in size. Now with Windows 7, the automatically created “System Reserved” partition is just 100MB. This is an interestingly small size, because the Windows Recovery Environment is too big to fit on this partition. The included Windows Recovery Environment, Winre.wim, in Windows 7 is 138MB. The Winre.wim is located on the boot partition in a Recovery folder, and is set as the default recovery sequence in the Boot Configuration Database for the boot partition.
This all works great, but things start to get interesting when you enable BitLocker. Enabling BitLocker on Windows 7 causes the Windows Recovery Environment to be removed. The Winre.wim and boot.sdi are removed from the Recovery folder and the BCD entries are deleted. This actually causes errors with integrated features of Windows 7. If you go to Recovery in the Control Panel, and click on “Advanced recovery methods”, you will receive the following error.
One interesting aspect of automatic failover with the Windows Recovery Environment is that once you enable BitLocker it will no longer be a seamless process. Meaning that when the system went into failover mode and booted to the Windows Recovery Environment it would prompt for the BitLocker recovery password to first unlock the drive, instead of automatically running the recovery agent. This makes automatic failover not as useful once BitLocker is turned on. Maybe this is one of the reasons that led to the removal of the Windows Recovery Environment when you enable BitLocker.
Having the Windows Recovery Environment located in the boot partition has some drawbacks, because you have to read the Winre.wim file from the Windows partition that might need fixing. Thus, if the MBR or partition table becomes corrupt, you can’t boot to the environment that could fix those issues.
In the Windows PE User's Guide for Windows 7, it suggests having the Windows Recovery Environment on the first partition on the disk, which would be the active/system partition, but makes it 300MB. So, the roughly 30MB of system files along with the Windows Recovery Environment fits no problem. This seems to make a lot of sense, and I don’t see why Windows 7 wasn’t setup this way by default. I also don’t see why the Windows Recovery Environment is automatically removed when you enable BitLocker.