Jeff Harris

It looks like you contacted support, but for anyone else who's reading this thread with the same problem;

I would manually check the wim info by opening a command prompt using the tile in the Tools section of SmartDeploy, and then running smartwim /info [pathToWimFile]

The Answer File wizard uses this same tool to retrieve this info, so you can use it to verify the retrieval of the image name without stepping through the wizard. If it's not working, I would try copying the wim file locally. 

SmartDeploy has the ability to do console initiated deployments. If you install the SmartDeploy Client on a computer, and it can reach the SmartDeploy console system, you could "push" a deployment form the console to the remote computer.

The caveat here, is remote/VPN network connections may not office the best performance and could lead to problems in the imaging process.

The files in "C:\Program Files (x86)\SmartDeploy\SmartDeploy Enterprise" would be SmartDeploy_x64.iso and SmartDeploy_x86.iso. If those files are missing, then you'll need to re-install SmartDeploy. There's no official 'wds.iso' so I'm assuming that's just DVD boot media that was created by someone, and named as such. Whenever you update SmartDeploy, you have to re-create your boot media. I suspect your wds.iso if from an older version. 

Also; the absence of any wims/images following the 'get-mounted' is good, as it means there isn't a mounted image stuck. That would be related to a problem creating new boot media. But if the SmartDeploy_x64.iso and SmartDeploy_x86.iso files are missing; you need to re-install SmartDeploy.

You can send them a USB drive with SmartDeploy boot media on it, but it's going to either follow the answer file as an unattended deployment, or require action from a user at the remote site. 

You  could in theory perform deployments remotey, while using USB if you have VPN and KVM access to the systems. 

I would expect your assumption to be correct. But, as with most things, I'd recommend thorough testing. 

Please try returning to your master image, and booting into Audit mode  and allowing 15-20 minutes for the Store apps to update. You may even try removing the original problem apps you mentioned above. Then re-capture and try the deployment again. 

We're still testing this behavior. Hopefully Microsoft fixes this sooner than later. 

In place of those apps, is there a tile with an arrow pointing down? 

Something is may be going on. We might have to have you upload your image for us to investigate. Use the Collect Logs button in the SmartDeploy boot menu, and send that zip file and details to SmartDeploy support for further troubleshooting. 

As I said;we're still testing the behavior of the AppX applications to be able to have repeat behavior. It's been a big pain point in sysprepping Windows 10. Certainly don't uninstall the Windows Store app. I'm not sure if there's a way to side-load that app. I have seen people who's run into errors where sysprep breaks in cases where they removed apps for one user, but not another. 

There are some TechNet discussions with some commands for using PowerShell to get a list of the AppX applications, and then uninstalling them for all local user accounts, however if you have only 2-3 local users, you can remove the apps manually. In any case; it's just going to require some testing.

Did you install Office via the Office 365 portal?; If so; you need to make sure that you don't actually open any of the Office applications on the reference virtual machine before you shutdown and capture it. If you did that; simply uninstall and reinstall Office. 

The BSOD error 0x0000007B is the Storage Device inaccessible screen we've seen, and resolved with the nVME patch I sent you.

You may have to use the Collect Logs tool, and send that zip file and details to SmartDeploy support for further troubleshooting. 

Are you using the CopyProfile switch with Sysprep? 

You don't need to troubleshoot SmartDeploy in this case; it's a bug related to the AppX applications in Windows 10 1709 and Sysprep. There are numerous sysprep users reporting issues like that, with a range of possible solutions they've found. We're currently testing a solution. Please try creating a new VM, installing Windows 10, and do not make any changes to the Windows Store apps (as far as deleting/installing) and then trying again. 

Did you also install the KB3087838 hotfix? I believe that both are required. 

Can you try the warm capture method outlined on page 76 of the User Guide and see if that helps? I'd want to rule out the boot wim being used in your WDS/PXE setup. 

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

Do you have snapshots of the VM?

Was the VM on a domain at one time? Or was the VM on the domain, then you took a snapshot before dis-joining the domain?

I can't say for certain;  but I would look at C:\Platform\dism.txt and look for the gap in the time stamps there first. You may be able to identify the culprit there. 

I would first try deploying the image to another device, or a virtual machine to rule out a driver/ppk issue to at least know if the image is good. If the image deploys it may be something that requires reviewing the logs to see what's happening. I recommend contacting SmartDeploy Support.

Stephen; this may require some more investigating since you may have a unique problem. If you haven't already, please contact support@smartdeploy.com.

In Bobby's case, the version of SmartDeploy pre-dates an update we made specifically to support the deployment of Windows 10. 

Be sure to periodically check to make sure you're on the latest version of SmartDeploy, and remember that when you update you must also re-create your boot media. (You do not need to re-capture your images.)

On 10/30/2017 at 12:06 PM, lphooper03 said:

Moral of the story: Don't upgrade your image. Rebuild it with a newly installed (and updated) OS. 

Yes! Always do this!

I've seen this error before in instances where users have 2 virtual disks attached to their reference VM, and only 1 on the target device. (There was a bug in a recent version where this would happen even if the 2nd disk wasn't selected during capture.) - If this is the case, please detach the 2nd disk and re-capture. 

I'm assuming you're using the USMT feature, with the local option selected. You could also try selecting backup to network location and see if that helps.

It sounds like you'll need to gather up the logs in C:\SmartDeploy\Logs in a zip and contact support@smartdeploy.com to see what's going on.

One thing I always check when troubleshooting the console initiated network deployments is the network utilization on the SmartDeploy. You''ll be able to see a lot faster if the boot image is actually being copied to the client.

This sounds like the connection to the mid-form 7040 isn't happening. Are the systems in the same subnet/network? Can you verify the Windows Firewall isn't blocking traffic, or perhaps SmartDeploy has to pass through a different firewall appliance to reach that client and the traffic is being blocked. 

The recommendation is to avoid in-place upgrades, especially when upgrading between Windows 8 and Windows 10. However, that doesn't necessarily mean that an update to 1709 is going to break anything. It may increase the overall size of the image, but it should work as intended.

You can always make a backup of your reference VM and perform a test capture/deployment. Remember; if you want to use VM snapshots in this case; you'll need to do a warm capture bybooting the reference VM to the SmartDeploy ISO.