Purging "deleted" ($||conflicted) VMs from AppVolumes Database?

[matthiasFF]

So apparently our deleting of Horizon replicas at user logoff led to appvolumes storing a bunch of non-existent VMs and failing to sync them with AD - leading to "$||conflicted" machines.

Can i just purge these from the "computers" table in the SQL Database without consequences?

This guy seems to think it's no problem: Remove ghost VM from App Volumes database - vDrone

Any inputs?

Thanks

[Ray_handels]

Although that guy does now what he is talking about I would not suggest doing that. At first it might seem to work as the computer accounts are no longer available. Downside to this is that thereare a lot of links with other databases and these still hold records for these accounts. It might work well but we have seem some quirky behaviour after deleting info directly from the database.

[matthiasFF]

Thanks.

Yeah that's what i thought. I guess i'll be doing a fresh install when we upgrade...

[howde]

We have these as well in our environment. Problem is, ours show up online from time to time and generate the Error 400: Virtualization Disabled when a user logs into it...thus no AppStacks end up being mounted and the user needs to logout to get a different desktop.

Just wondering if you also have the error 400 issue in your environment?

[matthiasFF]

I don't believe we have an error 400.

A whole bunch of these though:

Sync computer "DOMAIN\OFF10-017$||conflicted22040;" with ActiveDirectory - Failed 5 times
Job error: Sync Computer #<Thread:0x00000000a6ced0> incompatible character encodings: ASCII-8BIT and UTF-8

[SchwarzC]

have the exact same issue now after upgrading to 2.13 - did you ever fixed this issue?

[fdrietatns]

I had the same issue when upgrading from 2.11 to 2.12 when one of our pools was set to 'delete at logoff'.

AV 2.12: Database Pruning

From what i recall, the issue pertained to the agent version on the VM having not been updated yet.

I pruned them from the database without incident and purged the log data.

I wouldn't encourage it but If i were to wrap a procedure around it, it would look like this:

zero the pool

backup the DB

remove any computer entry of the related VMs

build up the pool

check the manager for conflicted

delete/reprovision the machines

monitor the manager for conflicted.

DB change are reflected in real-time. There isn't a need to restart services on the backend.

[howde]

Sorry for the delay. Not on here often. Sadly, we still experience this issue and I have a sneaking suspicion it is related to the DB as well. Since when we upgrade to 2.13.x we plan to use a new DB, we decided against that troubleshooting step.

What we have found as a successful workaround to this is to use the "Refresh Immediately" pool setting. Our specific reason for this problem seems to be related to calls to the DCs from the AVMs. During the machine deletion, during the agent validation process it seems to collide or time out. We moved to agent 2.12.4 which we were told had a mechanism in place to auto-correct but it doesn't work either.

On new pool recomposes, set back to Refresh and then just whack the || conflicted as they show up. Overtime, you are left with a full clean pool with no ||conflicted entries until the next recompose. We effectively went around in circles with support for months before we discovered our own workaround.

[alsmk2]

This issue is back with 2.13.2, after the previous 2.13.x versions appeared to have cleared the messages.

When you say whack it, do you literally mean remove the VM from View and let it recompose, or are you doing something else?

I have a call open with VMware for this at the moment, but it's not really got any traction as yet.

[howde · Accepted solution]

Whack it means...

When ||conflicted entry is identified in AVM as "online", from the Horizon Admin console delete the VM so it spins up new. Ensure the "Refresh Immediately" setting is in place on the pool and once the machine comes up successfully (no ||conflicted), it will be good until the next full pool recompose more or less.

We notice that with the "Delete Immediately" setting on, that there is an unidentified % chance that the machine will come up ||conflicted on every recompose operation. Having it set to Refresh means you just need to have it come up clean once and you are good until next recompose.

Not ideal but the workaround we use right now for 2 sites with roughly 2000 desktops total.