Jump to content
DeployCentral

SmartDeploySupport

Administrators
  • Posts

    904
  • Joined

  • Last visited

Posts posted by SmartDeploySupport

  1. Ted,

    Yes, you will have to manually update the clients. You can select all the machines you want to update via CTRL-A. Yes, most likely you will have to remove that entry from the database. Please email support@smartdeploy.com and refer to this thread. By the end of the day tomorrow, these forums won't be available due to some upgrades on the backend. I can then show you the steps to get into the database.

    Thanks,

    Devon

    SmartDeploy Support

  2. Hello,

     

    Try restarting the "MongoDB" service, as that can sometimes resolve this type of issue. If that doesn't work we may need to do delete the authentication collection the mongo databsae. Let us know how it goes with restarting that service first.

    If you still have issues, send an email to support@smartdeploy.com and reference this thread and I will provide you the steps to delete the authentication. 

    Thanks,

    SmartDeploy Support

    Devon

     
  3. Hello,

    I'll answer your last question first - Autologon can indeed be configured in your SmartDeploy answer file. You can combine this with an Answer File Task to run the command during First Logon as User.

    I should note, login is only necessary if the remote client must run in a user context - if the Bomgar application can be installed for all users under the authority of the LOCALSYSTEM account (which can perform most software installations without issue), then you can run the installation command during First Boot as System instead. This will run behind the Windows login screen, and no logon will need to occur for the installation to happen.

    You'll want to test this to make sure it meets your needs - we don't have any specific expertise with the Bomgar application, but such applications sometimes have configurable switches which determine whether they are available for remote connections prior to user login. You'll want to test this procedure on a machine that you have local access to, so that if you need to log on locally to determine the current status of the application and/or troubleshoot installation failure, you will be able to do so.

    I should also note, we do not recommend renaming the local Administrator account (i.e. the built-in account with the name of Administrator). SmartDeploy's default behavior is to restore the state of the local Administrator account - disabled or enabled - as it existed on the reference VM (and this requires the account to have the specific name of Administrator). If you do not wish to use the local Administrator account, you can disable it on the reference VM and it will be disabled on the target device as well. Any additional local administrator account(s) you create will not be affected - they should not be touched by Sysprep or SmartDeploy. You could also use a free Microsoft solution like LAPS to manage local administrator passwords at the AD level if you wish.

    If you have any questions, feel free to reach out to Support.

    Glenn
    SmartDeploy Support

  4. Hello,

    What I would recommend is deploying your software as a post image task, or Application Pack. That way you don't have to join the domain on your virtual reference machine. The application would install after the domain join during deployment.

    You won't want to join the domain on the virtual machine because it can cause issues like you're experiencing. If you want to see the deployment logs, boot the target machine from your SmartDeploy boot media. Select Collect Logs and save the zip to a USB or network location.

    Thanks,

    Devon

    SmartDeploy Support

  5. Hi Andrew,

    You will want to run the following command on your virtual reference machine before running the Capture Wizard:

    Get-AppxProvisionedPackage -Online | Out-GridView -PassThru | Remove-AppxProvisionedPackage –Online

    Just to note, if AppX packages are provisioned for All Users, and you uninstall it just for a user, then that will make Sysprep fail.  If they are provisioned packages, they have to be removed for all users.  We use the above PowerShell command to do that.  Sometimes takes some effort to figure out what package name goes with which app.

    Thanks,

    Devon

    SmartDeploy Support

  6. Hi there,

    I can confirm as of this writing that the web-based console is still on the roadmap and under active development. No ETA available at this time.

    If you have any questions or feature suggestions for the web console, please feel free to reach out to feedback@smartdeploy.com.

    Glenn
    SmartDeploy Support

  7. Hi Jason,

    It does essentially occur during FIRSTBOOT, but there are a few additional steps to the automation.

    If you include an Application Pack as a part of deployment, the SmartDeploy service does the work of installing the SmartDeploy Client, during First Boot as System. As soon as the SmartDeploy Client Service starts up for the first time, it will install the pending Application Packs.

    So the timing is essentially during FIRSTBOOT, but another step occurs beforehand.

    The difference being that the SmartDeploy service only runs along with reimaging operations, and then shuts itself down permanently, while the SmartDeploy Client Service will remain installed and run automatically at every startup.

    Glenn
    SmartDeploy Support

  8. Hi Jason,

    Thanks for reaching out.

    >Post-image deployment, is it normal for the login screen to appear before all applications are installed / tasks are completed?

    Yes, this is normal behavior. SmartDeploy has no mechanism to delay the appearance of the Windows login screen. Any "First Boot as System" tasks will be executed behind the Windows login screen under the authority of the LOCALSYSTEM account (they are executed by the SmartDeploy service).

    >FYI - I tried sending a message via PowerShell as the first task, hoping that it'd actually pop-up for me to see at the login screen; unfortunately it did not work.

    This is also normal - and is due to the execution of these tasks as LOCALSYSTEM. No window will be displayed for the logged-on user, nor would does that user have any ability to interact with any window that does appear as a result of the process. This is why tasks must be silent/unattended, because a user will not have any means to click through to the end of the process.

    >If I recall correctly, SCCM had, at the very least, pop-up messages indicating that things were still being worked on in the background, so I knew the machine wasn't finished until that message went away.

    It's been a while for me personally, but I believe you're correct about this. If this is a feature you'd find useful in SmartDeploy, please shoot an email to feedback@smartdeploy.com to let us know. I can't make any promises about future product features, but our engineers do read all feedback and feature requests that come to this address.

    Please let us know if we can assist with anything else.

    Glenn
    SmartDeploy Support
    support@smartdeploy.com

  9. Hi Jeremy,

     

    I just replied to your ticket that you submitted to support. Looks like one of the required services shut down which was causing the issues you were seeing. Once you restarted the SmartDeploy host, those services started back up and that is why you started to see machines to check in.

    If you still have issues, please reply to the ticket thread.

    Thanks,

    Devon

    SmartDeploy Support

×
×
  • Create New...