Jeff Harris

That's pretty odd that it's only happening to the platform packs. The next time this happens, try moving the ppk files out of C:\SmartDeploy\Platform Packs\ to some place like C:\Temp, and then cut/paste them back. You don't need to walk through the import option inside the console for each one. 

(Also; I am assuming you didn't change your SmartDeploy directory from the default C:\SmartDeploy)

39 minutes ago, Sunny Bharucha said:

In regards to that ~500 MB file; what actually is contained in that file? Is it just the SmartPE + Answer file? If so, my question really was, where is the actual image + platform pack being transferred from, if I've already uploaded my deployment package to the cloud? 

Correct, the network deployment package contains the SmartPE boot image and your answer file. Provided you've walked through the steps to create an answer file for a cloud deployment, SmartDeploy will look to the cloud for the image and the platform pack. 

When you right-click a computer and click deploy, the network deployment package containing the SmartDeploy boot image and answer file is copied to the target computer (a few hundred MB). Then it will restart and boot into SmartDeploy and should your answer file have the instructions for an unattended cloud deployment, that's what would happen. 

I believe the recommendation is still to avoid this sort of scenario by keeping SmartDeploy installed on a VM on-site to act as the hub for console initiated network deployments. Maintaining connectivity without a site-to-site VPN can be problematic and may cause more work for you. 

I believe the problem is related to the AppX apps and sysprep in v1709 specifically, and not the profile. Hopefully this is fixed in the next large update. We actually went through this same thing a few versions back with Windows 10. 

We have seen issues with Windows 10 v1709 Store appx packages (and the Windows Store itself) not functioning after deployment.

The first thing we recommend is that you try to fix your current VM. Power on your reference VM, launch the Windows Store, and install all available app updates. Once the updates have all completed, gracefully shut down the VM (shutdown /s /t 0), then retry capture and deployment.

For some users experiencing this issue, it has resolved it. We’ve also seen success in creating a new local administrator account, or using a domain account. The process of creating a new profile allows for the Start Menu apps to re-provision. 

Unfortunately, if that does not fix the issue, the only workaround that we can recommend would be to rebuild the VM in the manner specified below.

To build a new VM and ensure that no apps are updated in the process, complete these steps:

1. Build a brand new VM. Set the network adapter to either be disabled or not connected. 
2. Install Windows 10 1709 from MS VL .iso (or any other official media which has not been customized for specific hardware).
3. Go through OOBE. Once you reach the desktop, open an administrative command prompt and run the following command: 

           reg add HKLM\Software\Policies\Microsoft\WindowsStore /v AutoDownload REG_DWORD /d 2

This registry value will prevent the Windows Store apps from auto updating.  Once this is set you can open the VM settings and enable the network connection (and provide internet connectivity), then continue setting up your VM.

Once your VM is setup, do a clean shutdown (command line SHUTDOWN /S /T 0) and capture. 

You will want to add a Task to the deployment to remove the AutoDownload setting, so that the apps will update properly on the deployed device. You can add this in Deploy Wizard (or Answer File Wizard), Advanced, Tasks.  

I've seen this sort of failure with Wipe and Load in instances where the target devices previously had Windows 7 installed, and the image is for WIndows 10. The reason is that the system partition for Windows 7 is smaller than 10, and thus it can't fit. We always recommend using Wipe and Load whenever possible.

You can create an empty platform pack that may help in this case.

You'll want to have a site-local host running SmartDeploy, and any clients on that site configured to use that host. You can do a one-time copy of your corporate image to that host, then use RDP to download packs, create answer files and network deployment packages, and initiate your network deployments. 

(UpdateD)

You could do something like this; 

On a workstation that's connected to the network, run the following command: (You may need to verify your interface name) 

      netsh wlan export profile name="NameOfWirelessNetwork" folder=c:\temp interface="Wireless Network Connection"

Then copy the NameOfWirelessNetwork.xml file to a place on your reference VM like C:\Temp\

Then you'd add a 'At First Logon' task to your Answer File, using the Tasks tab in the Advanced settings of the Answer File wizard with the following command:

      cmd /c netsh wlan add profile filename="C:\Temp\NameOfWirelessNetwork.xml"

Alternatively, you could keep the xml on a network share, and use GPO to import the wlan profile. You may also need to do some tweaking to the xml file dpending on which security method you use. You an find examples on TechNet for this. 

I'd be interested to see the file count between the 2 images once complete. Capture time is most related to the make up of the reference VM disk, but can also be affected by disk/network speed, or any real-time file scanning in place. It sounds like you would need to look at what's in your reference VMs. 

Steve, we may need to look at your logs to get a better idea of what's going on. Reach out to support@smartdeploy.com for assistance. 

Sysprep with CopyProfile is sort of broken in Windows 10 1709. Here's a lengthy TechNet post with users reporting different behavior.

We're hoping it's resolved in the next update. There are some work-arounds to get it working well enough, but nothing seems to be a magic bullet. 

I've seen instances where Windows Defender real-time scanning affects capture time. I would look at that first.

Also; SmartDeploy does a file-by-file copy to create the image. The difference in your images doesn't just have to be file size to make a difference in image creation time. The 35GB and 40GB VHD sizes aren't necessarily a reliable indicator of what's being used by files. 

Here's a link to a blog topic that covers manually specifying the local settings in greater detail. You'll have better luck explicitly setting the language this way. 

The Answer File wizard offers you the opportunity to set the locale for the deployment. Have you set your locale there?

On 1/15/2018 at 8:33 AM, lphooper03 said:

I was successful once I went to my Microsoft Volume License account and downloaded the most up-to-date version of Windows 10, with the Fall Creator's update already installed as part of the image. 

We do recommend to avoid in-place upgrades, of Windows, and any other software if possible. 

Glad to hear it completed the copy. That stage of the deployment is using the normal Windows copy commands. There's no standard time to copy regardless of size since given all the factors that can affect the copy time. 

If there's an error, or it doesn't progress you can cancel to return to the SmartDeploy boot menu, open a command prompt and locate the X:\Windows\Temp\Scanstate.log file. This can shed some light on what's happening. (Alternatively, you can click the Collect Logs button on the SD boot menu and this log will be included in the zip file.)

This sort of error could be caused by;

• Anti-Virus or some other security software installed on your reference VM
• Snap-shots of your reference VM
• The reference VM configured to use EFI mode
• Anti-virus software on your SmartDeploy host

I would address those items first, and try again. If you need to have A/V software on your image, I recommend using the Tasks pane to script the installation post image. 

Following that, if you still have issues try a warm capture which is outlined on page 76 of the user guide. https://www.smartdeploy.com/wp-content/uploads/SmartDeployUsersGuide_V2.pdf

This isn't a common problem. Something like this would require a review of the logs after deployment. You can contact support@smartdeploy.com (attach the logs from deployment) and we'll take a look. 

My first step would be creating a new answer file, and new boot media and re-trying deployment to rule out those pieces as potential culprits. 

On 1/8/2018 at 1:52 PM, Amanda said:

We have the M.2 SSD in the 7050s. Would you be able to update the platform pack for the Dell 7050 for the NVMe drive? 

We have changed methods for this particular driver. We have a patch for installing direct to your Windows 7 reference VM, instead of placing the driver in the platform pack. Contact support@smartdeploy.com for details and access to this patch. 

As of this time, SmartDeploy does not install software packages on their own. You would need to include your desired software in your image by installing in on your reference VM before capturing.

You can use the SmartDeploy Cmd Prompt command; smartwim /info [wim file] to view details of the wim to make sure it's ok. Other than that I'd make sure you have the latest version of SmartDeploy installed, and try uploading a different boot wim to your WDS host to rule out a problem there. 

If you have a support contract with SmartDeploy, you can contact support@smartdeploy.com for additional help.

You'll need to make sure you are using the Media wizard to create and upload your WDS boot media, before uploading your Windows 10 image file. Here's the link to the SmartDeploy guide for integrating with WDS. Try starting back at the top of this document. 

https://www.smartdeploy.com/wp-content/uploads/SmartDeploy_WDS.pdf

I re-sent that file attached to a private message. Check that and let us know if you can access it. 

You're installing Smart Deploy? Check the properties of the downloaded setup.exe file to make sure that it's not being blocked. If you have any anti-virus or other security software installed; that could also be interfering with installation.