New AVAST server - trouble deploying to non-domain clients

Hi everyone, I recently had to change which server our AVAST Enterprise Administration Console was installed on. I tried to set up the new AEA Console as similarly as I could to the old one. One difference I couldn’t avoid, though, was that the old server was not joined to a domain, and the new one is. With the new installation, I cannot remote install to non-domain clients.

Prior to the migration, I could add a new computer to the computer catalog like this:
Name: 10.2.0.152
Domain: WORKGROUP
IP: 10.2.0.152

I would then deploy remotely using these user settings on the installer package:
Domain: WORKGROUP
Account: admin

Since the new installation, I’ve been getting the following errors in my remote install log:
01/13/18 15:32:28: SpawnThreads
01/13/18 15:32:28: 10.2.0.152: StartSetup
01/13/18 15:32:28: 10.2.0.152: Connecting
01/13/18 15:32:28: 10.2.0.152: OpenSCManager error 5 (Access is denied)
01/13/18 15:32:28: 10.2.0.152: OpenSCMImpersonated
01/13/18 15:32:28: 10.2.0.152: LogonUser Administrator 10.2.0.152 error 1326 (The user name or password is incorrect)
01/13/18 15:32:28: 10.2.0.152: LogonUser Administrator 10.2.0.152 error 1326 (The user name or password is incorrect)
01/13/18 15:32:28: 10.2.0.152: RemoveOnError
01/13/18 15:32:28: 10.2.0.152: CloseConnection
01/13/18 15:32:28: 10.2.0.152: Finished with error
01/13/18 15:32:28: TerminateAll
01/13/18 15:32:28: rinstInstall end 0

I have verified that I can successfully deploy to computers that are joined to the same domain as the AVAST server (I set up a second remote installer package with the user name set to the domain administrator credentials). I found a forum post from 2015 (https://forum.avast.com/index.php?topic=171717.0) that I thought might solve my problem. I’ve gone into my domain controllers and made sure all of my administrator accounts can run as a service, but am still having the same error.

Any suggestions/advice here are appreciated. I’d really like to avoid taking my AVAST server off of the domain if possible, even if that was how the old setup was.

To deploy in WORKGROUPS you should:

  1. Have an account with the same Username and Password (not required, but recommended).
  2. Have access to the C$ and ADMIN$ shares of the target PCs.
  3. Use * as domain in the Deployment credentials.
  4. Use the username only in the Deployment credentials (don’t add WORKGROUP or the HOSTNAME in front of it - the wildcard in domain, will substitute the information with the HOSTNAME of the currently deployed computer).