SmartDeploySupport

Hi R, We do not recommend installing feature updates/in-place upgrades on your reference VM, and that may well be the cause of the issue. If you wish to deploy Windows 10 21H1, you'll want to download the latest ISO from the Microsoft Volume License Servicing Center (VLSC) or some other official source, and build a new reference VM using that ISO. Then retry capture and deployment. Windows should generally activate on its own within a couple of days without any intervention required, assuming that a valid product key was provided (either via the Answer File or when you captured the image). It's unclear exactly what is happening when you activate the licensing troubleshooter, but you can try just running a normal activation command after deployment, to see whether it throws an error. Open an admin command prompt and run this command: wscript.exe slmgr.vbs /ato Assuming this command works as expected, it can even be added as a Task in the answer file, to occur during First Boot as System, if you wish. But you will want to test it first. If you have any questions or issues, feel free to reach out to support@smartdeploy.com. Glenn SmartDeploy Support

Hello, We have seen this issue sometimes - generally, if there is an issue accessing a particular cloud provider due to an API change, we address it in a subsequent SmartDeploy version, so I would suggest that you update to the latest version and recreate your media, and see whether the slow connection persists. I might also suggest that you try one of the other supported cloud providers besides whichever one you're trying - they all generally offer a free tier, so you would be able to see if you're getting better bandwidth on another provider before purchasing. All I can say with certainty is that it's definitely possible to get much faster speeds than that for cloud operations on all of our supported platforms, and it sounds like something may be interfering with your connection - I would suggest checking antivirus and firewall settings, making sure there isn't any sort of bandwidth limit applied to unauthenticated endpoints, etc. If you have any specific questions or want us to take a look at logs, feel free to reach out to support@smartdeploy.com. Glenn SmartDeploy Support

Hello, If you want to add more models to your environment and want to deploy to them, you will want the Platform Packs for those models selected when you create the WDS boot media. That will inject drivers needed to complete deployment such as ethernet and storage drivers. Not all Platform Packs have Windows PE drivers, but a lot of the newer models do. https://support.smartdeploy.com/support/solutions/articles/48001198942-when-do-i-need-to-re-create-my-boot-media- If a Platform Pack does not have PE drivers, you can simply place the Platform Pack where the answer file points to. Default is \\SmartDeployHost\C$\SmartDeploy\PlatformPacks Thanks, Devon SmartDeploy Support

Create boot media in the Media Wizard with only the platform pack for this particular model selected. That should allow the RAID controlled drive to show up.

Hi DeJeon, Thanks for reaching out. If both newly reimaged and existing (not recently reimaged) endpoints all stopped checking in at once, there's a possibility that there is a common cause - perhaps some change in your security environment (antivirus or firewall settings). I'm going to go ahead and open a ticket for you, because there are a lot of potential variables to dig into here, and we'll want to see some logs from the affected endpoints. You may expect an email from us shortly. Glenn SmartDeploy Support

Could depend on what version of Windows 10 it is, if it was upgraded, how it was captured. Please open a support ticket with us and we'll help you get to the bottom of it. https://support.smartdeploy.com/support/tickets/new

It should work, WinRE just needs to be working. So long as the VM your image was created from was a clean install of Windows 10 from a Microsoft .iso for the version of Windows 10 you want it to be. If the VM was upgraded from one version of Windows 10 to another, then that can make WinRE not work. Check it with "reagentc /info" from the command line. If you still have issues, contact us at support @ smartdeploy.com

This is an issue we've seen, but have never been able to replicate. It is a bad cold capture of the image, and it has something to do with the host that SmartDeploy is installed on. You can try a warm capture of the image, and see if that fixes it.

Hi Ric76, We'll follow up via email - we'd like to troubleshoot this further. Glenn SmartDeploy Support

Hello, Please send us the following log from an endpoint that has gone offline and then not returned: C:\Program Files\SmartDeploy\ClientService\SDClientService.log That should provide us with more information. Send to support@smartdeploy.com and refer to this thread when you submit it. Thanks, Devon SmartDeploy Support

This is a v3 bug that we are working to fix in the next release. It has to do with the length of time that has passed since the media was created. For now, recreate your boot media via the Media Wizard and boot from it. You should not receive that error anymore. Sorry for the inconvenience. Thanks, Devon SmartDeploy Support

We're in touch with Nate via email, but for anyone else who runs into this issue: Update to the latest version of SmartDeploy, recreate your media, and retry deployment. If the issue persists, grab a logset from the same PE session (if you can) and email us at support@smartdeploy.com, or submit a ticket via the support form. Glenn SmartDeploy Support

Hi DJ, The 3.0.1005 installer is not too large - about 97MB. Assuming the endpoints at the remote site are connected with a Cloud connection type (which they probably should be), then it shouldn't bog down the connection between offices, but rather, each endpoint would individually reach out to your cloud storage provider to download the installer. If the clients are connected with a Local connection type, that could be the concern - and if that is the issue, I might suggest you configure those endpoints to use Cloud communications only. We can provide a script for this, so reach out to support@smartdeploy.com if you'd like to go that route. Throttling client updates is not currently a feature of the console, but if it's a feature you'd find useful, please shoot an email over to feedback@smartdeploy.com. Our engineering team does read all feedback and feature requests that come to this address. Glenn SmartDeploy Support

I've emailed DJ back about this, but putting it here as well for everyone's info: This is a known bug in V3.0.1000, and it has been fixed in the latest release. Update to the latest version (V3.0.1005 as of this writing) and you should be all set. Feel free to reach out to support@smartdeploy.com if you have any questions or issues. Glenn SmartDeploy Support

UEFI requires FAT32 and we can only make that work up to a certain size. This Toshiba device must be too big, probably 1TB or greater? Need a flash drive, 64GB, 128GB, 256GB all work.

Yes, you need to create your boot media or deployment package with the platform pack for the model you are deploying to selected in the Media Wizard. If you continue to have trouble, please submit a ticket. https://support.smartdeploy.com/support/tickets/new

See if you can move the error out of the way, or Alt+Tab to get back to the splash screen.

Hello, Once you get that error, cancel out of the Deploy Wizard, then Collect Logs and submit them to us in a ticket. https://support.smartdeploy.com/support/solutions/articles/48000984846-collect-logs https://support.smartdeploy.com/support/tickets/new

Hi Joel, That is concerning to hear - I wouldn't expect you to have this much trouble with the automatic client upgrade given that your other Computer Management features are working normally. It is possible to disable the automatic client upgrade feature, so it's possible this was done at some point in the past on this console host. It's not the sort of thing you could've done accidentally (it involves editing a line in a .config file), but I'm not seeing any record of this on your previous tickets, so it would've had to be someone else in your environment. If you run into any issues with the V3 Client, or if you want to troubleshoot this further, please reach out to us at support@smartdeploy.com and we'll be happy to dig into this. Glenn SmartDeploy Support

Hi Joel, Thank you for reaching out. First off, I should mention - the normal behavior of the SmartDeploy Client is that it will update itself automatically with no action required on your part. It's supposed to be a process that's entirely free of headaches - or indeed, any work whatever - for you. The recent exception on this has been the release of SmartDeploy V3, which features completely redesigned client-console communications, and installs alongside your existing V2 (2.0.3090) console. The new communication protocol should mean much more reliable communications and message history between your V3 Clients and the V3 console - but since it was such a drastic change to the software, we didn't want to automatically push out all of the V3 updates only for those endpoints to not be able to talk to the console due to the change in ports and so forth. This side-by-side installation should allow you to upgrade a small number of test clients to V3 (using whatever method you prefer, including manually or using Group Policy, or using the "Upgrade Client to V3" option in the V2 console) and confirm that these endpoints are able to report into the V3 console, and that you're able to perform operations from Computer Management to these endpoints, and then you can upgrade the rest, and uninstall your V2 console. I realize that doesn't address the why of your question under normal circumstances, when we're not rebuilding the software from the ground up. For about half the lifespan of the SmartDeploy console, we actually did allow backward compatibility. However, we eventually came to recognize this as a potential security concern. The console has the ability to send commands to a client which can execute those commands on any endpoint with administrative permissions. This includes administrative functions such as installing software, changing boot options, or changing user permissions. Consequently, we need to make sure that this communication protocol is as secure as we can make it, and that unfortunately means disallowing backward compatibility as a best practice. This helps us ensure that older clients do not stick around carrying vulnerabilities that we have already patched on the console side. I hope that helps address your concern. Our engineering team always welcomes your feedback, and if you have any further thoughts on the matter, please feel free to reach out at feedback@smartdeploy.com. Likewise, if you're running into any support questions, you can reach out to support@smartdeploy.com. And finally, here are few articles from the support portal which may help if you're upgrading to V3: How to upgrade SmartDeploy from V2 to V3 How to troubleshoot SmartDeploy Client upgrades from V2 to V3 Glenn SmartDeploy Support

You're using Ethernet, correct? We will need to take a look at your C:\SmartDeploy\Logs\MediaWizard.log from the SmartDeploy host to see if the driver injected correctly. Please send it to support@smartdeploy.com and reference this thread. Thanks, Devon SmartDeploy Support

Hi Milos, In order to make use of this network driver, you will need to figure out how to extract the driver files (the .inf and any other required files that accompany it) from the .exe or wherever else they may be stored among the package you downloaded. Unfortunately, there is no standard method, as this process varies significantly between manufacturers, who use many different installer types for this purpose. If you would like further assistance on this, please submit a Platform Pack request via the Support Form. Glenn SmartDeploy Support

Hello, Just to verify, you originally got the computers imported into Computer Management in v3? Then once you restarted the host, they disappeared? Please email the following logs to support@smartdeploy.com. C:\SmartDeploy\Logs\SDConsole.log C:\SmartDeploy\Logs\SDAPIService.log That should provide us with more information. Please refer to this thread in the email. Thanks, Devon SmartDeploy Support

Hi George, Please send us your C:\SmartDeploy\Logs\Console.log from the SmartDeploy host to support@smartdeploy.com. Reference this thread and we can take a look. That being said, we release version 3.0 of SmartDeploy today, so you may want to upgrade to that and attempt to re-download your Application Pack and see if that works. https://support.smartdeploy.com/support/solutions/articles/48001188577-how-to-upgrade-smartdeploy-from-v2-to-v3 Thanks, Devon SmartDeploy Support

Hello, We will need to take a look at some deployment logs in order to see what is causing the error. When you boot to the SmartDeploy boot environment, do you see the internal storage disk in the bottom right corner listed? Reproduce the error (so it's saved in memory), then dismiss the error and close out of the Deploy Wizard to return to the main menu. Click Collect Logs and save the zip to a USB or network share. Send us that zip. You can submit a ticket here. Refence this thread in the ticket. Thanks, Devon SmartDeploy Support