Jump to content
DeployCentral

SmartDeploySupport

Administrators
  • Posts

    904
  • Joined

  • Last visited

Everything posted by SmartDeploySupport

  1. We'll reach out on your support ticket for this one. SmartDeploy Support
  2. Hi Anthony, We will need to take a look at a deployment log set. Boot the target machine from your SmartDeploy boot media and select Collect Logs. Save that zip to a USB or network location and submit a ticket here. Refer to this thread in the ticket please. https://support.smartdeploy.com/support/solutions/articles/48000984846-collect-logs Thanks, Devon SmartDeploy Support
  3. Hello, I noticed you submitted a ticket with this same issue. I will reply to the ticket shortly once I go through the complete logs. Thanks, Devon SmartDeploy Support
  4. We've followed up by email to request logs. Glenn SmartDeploy Support
  5. Hi Rick, I noticed you submitted a ticket with this question as well. I will follow up to that ticket shortly. Thanks! Devon SmartDeploy Support
  6. Hi Chin, Save C:\Program Files\SmartDeploy\ClientService\SDClientService.log from the client machine. Submit a ticket here and refer to this thread and attach that log and I can take a look.
  7. It appears you have a ticket open on this issue, so we will follow up accordingly. Glenn SmartDeploy Support
  8. Hi Nick, For this, we'll want to see a complete deployment logset. We'll be in touch via email with further instructions. Glenn SmartDeploy Support
  9. Please send your C:\SmartDeploy\Logs\MediaWizard.log from the SmartDeploy support. You can submit a ticket here: https://support.smartdeploy.com/support/tickets/new Please refer to this thread in the ticket. Thanks, Devon SmartDeploy Support
  10. Hi Chipuk, If there are any other SmartDeploy consoles installed somewhere, be sure they are signed out. If they are, please send us the following logs from the SmartDeploy host: C:\SmartDeploy\Logs\SDConsole.log C:\SmartDeploy\Logs\SDAPIService.log Create a ticket here and attach those files. Please reference this thread in the ticket. Thanks, Devon SmartDeploy Support
  11. Not at this time. Managing Windows Updates is not currently a feature of SmartDeploy, but I believe it is on the product roadmap, so please send any thoughts about what you'd like to see in such a feature to feedback@smartdeploy.com. The best method for managing Windows Updates currently is to simply install them on your reference VM - note that we only recommend installing Security and Quality Updates onto your reference VM. You should not install any Feature Updates to your existing VM (e.g. Version 21H1 to 21H2), as this involves a Sysprep run and a full in-place upgrade on the VM, and may leave it in an unreliable state for deployment. See: Best Practices to Create Your Reference Virtual Machines Thanks, Devon SmartDeploy Support
  12. Hi Dave, From the client machine, please send the following log: C:\Program Files\SmartDeploy\ClientService\SDClientService.log From the SmartDeploy host, send the following logs: C:\SmartDeploy\Logs\SDAPIService.log C:\SmartDeploy\Logs\SDConsole.log That should provide us with more information to investigate further. Create a ticket here and refer to this thread. Thanks, Devon SmartDeploy Support
  13. That's definitely not intended behavior. I'll reach out via email for logs. Glenn SmartDeploy Support
  14. Hello C Thelen, Just to verify, you want to install RealVNC Server via an Application Pack that silently (Without user input) runs. After it's installed, you want to run that .bat file correct? If you can point me to the vncserver.exe (Is it this?), I could create the Application Pack for you, or if you want to send me your current Application Pack, send it to support@SmartDeploy.com and I can take a look. Be sure to reference this thread in the ticket. Thanks, Devon SmartDeploy Support
  15. Hi BeetleJelly, To see what occurred, we will need to take a look at the following log from the endpoint you're attempting to deploy to: C:\Program Files\SmartDeploy\ClientService\SDClientService.log Submit a ticket here and refer to this thread and attach that log and I can take a look. Thanks, Devon SmartDeploy Support
  16. That's quite alright - auto-update is how the clients used to behave, but we removed that in response to user feedback. It is still possible to update your clients en masse if you wish - just click on a single client, and press Ctrl-A to select all, then you can update them all at once. You can also use Shift-Click to select a range of clients, or Ctrl-Click to select specific ones. Feel free to reach out to support@smartdeploy.com if we can assist further. Glenn SmartDeploy Support
  17. Hi DJ, There are a few possibilities: 1) This feature is limited to Pro users, so if you are not subscribed at the Pro tier, please contact your account rep if you'd like to try this feature out - we can enable it temporarily for anyone who wants to try it out. 2) As of this writing, the SmartDeploy V3 console is backward compatible with previous client versions (and we have no current plans to change this), so your clients may still be on 3.0.1020 or a previous version, which is not capable of gathering the software inventory data from your endpoints. Update your clients to 3.0.1030, and the data should populate automatically in Software Management in time. The update frequency is upon SmartDeploy Client Service startup, and once per hour after that (see this KB for more details). 3) There may be some other dysfunction in your environment, so if you have checked 1 and 2 and the issue persists, please reach out to support@smartdeploy.com and we will assist with further troubleshooting. Glenn SmartDeploy Support
  18. Hi Kris, If you created any local administrators on the reference VM prior to capture besides the local, built-in Administrator account (the one specifically called Administrator that exists in every Windows installation, but is disabled by default), then those other administrative accounts should still work. If the local, built-in Administrator account was enabled on the reference VM, it should also be enabled on the deployed endpoint. And if you entered a password for that account when you captured the image (which is an optional setting in Capture Wizard), then that password should work for the local Administrator account. If you did anything unusual, like rename the local Administrator account, that could interfere with this functionality. I've opened a ticket for this issue - I'll send a request for logs to send if the issue persists. Glenn SmartDeploy Support
  19. Create your boot media with the ZBook Power G8 pack selected in the Media Wizard, that will add in the Serial IO driver and should allow it to work. If it still doesn't work, submit a ticket and include the Media Wizard log. https://support.smartdeploy.com/support/tickets/new v2=C:\SmartDeploy\Logs\Media.log v3=C:\SmartDeploy\Logs\MediaWizard.log
  20. Depends on the phase. PREIMAGE and POSTIMAGE: These occur in WindowsPE, before and after the image is applied, respectively. SPECIALIZE: These occur after reboot, during the Sysprep SPECIALIZE phase (executed essentially by the Sysprep process itself - they are written into the Sysprep Unattend.xml files). For your specific question, domain join occurs after these tasks would be executed, so if they are domain-join dependent, you'll want to run them during... FIRSTBOOT: First Boot as System. These occur behind the Windows login screen, and are executed by the service that is just called "SmartDeploy" (not to be confused with the SmartDeploy Client Service), under the authority of the LOCALSYSTEM account, which has admin-equivalent permissions, more or less, and can be used to install software as long as you're using a silent/unattended command line for the installation. FIRSTLOGON: First Logon as User. These are written into the RunOnce area in the Windows Registry, and are executed under the authority of whichever user logs in first. This can be combined with Autologon if that's useful. We have some examples here, if that's helpful: Answer File Tasks If you there's anything specific you're trying to accomplish and it isn't working as expected, go ahead and open a support ticket and we'll assist however we can. Glenn SmartDeploy Support (support@smartdeploy.com)
  21. Glad to hear it! Please let us know if we can assist with anything else. Glenn SmartDeploy Support
  22. SmartDeploy is essentially just passing through whatever key you provide (either in Capture Wizard or via an Answer File/in Deploy Wizard), and Windows is attempting to install that key (during Sysprep\Specialize) and then activate the endpoint. I haven't used this particular activation method myself, but from the docs, you seem to be on the correct track here using the GVLK to prepare these endpoints to be activated via AD. My best guess is that it's possible that Windows simply recognizes the GVLK and refuses to install it during the Specialize phase, which means that the endpoint would indeed have whatever OEM key may have been present on that endpoint prior to installation, which would not work with AD-based activation. We could look at a deployment logset to confirm whether this is the case (there should be some evidence of the attempt and result in the detailed Sysprep Specialize log), but from your description, I believe you've potentially found a workaround already. Try this: Deploy to an endpoint without specifying any product key. Then log into the endpoint, open an admin command prompt, and run this command: slmgr.vbs /ipk [enter the GVLK here, without any brackets] You can run this command to confirm which key is currently installed (it will display a portion of the installed key): slmgr.vbs /dlv If the GVLK installed without error, you could attempt to run the activation command at this point as well: slmgr.vbs /ato However, I'm not sure what this command will do in an AD activation scenario, so you may want to hold off on that and just see whether the activation resolves itself within a day or so, as the endpoint communicates with your AD environment. If you have any questions, feel free to reach out to support@smartdeploy.com. Glenn SmartDeploy Support
  23. Not a bad idea! Recreating media is not something we specifically call out in that article, but you're correct to note that it affects the console even if the console is not performing that specific deployment. We'll take a look at that and see if we can add some clarity. Glenn SmartDeploy Support
  24. Hi Martin, Yep, makes perfect sense. Your WDS boot media contains a WindowsPE boot image and a SmartDeploy software layer that operates independently of whatever console version is installed. It is delivered to PXE boot clients by the WDS server, and the console has no involvement with its deployments (other than, perhaps, to register their appearance in Computer Management after the deployment is complete, if your answer file included the checkbox to install the SmartDeploy Client). Any endpoints that you reimage using your existing WDS boot media will still be reimaged using SmartDeploy V2, and will still install the V2 Client (and only be able to report into the V2 console). To fix the issue, you'll want to re-run Media Wizard on the V3 console to recreate your answer file and WDS boot media, then replace the boot image on your WDS server. Any endpoints that you reimage from that point forward (again, assuming you check the box for client installation) will report into the V3 console only. If you have any questions or issues, feel free to reach out to support@smartdeploy.com. Glenn SmartDeploy Support
  25. No problem, glad to hear it. Glenn SmartDeploy Support
×
×
  • Create New...