9 Replies Latest reply on Mar 29, 2018 7:44 AM by howde

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

    matthiasFF Novice

      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?



        • 1. Re: Purging "deleted" ($||conflicted) VMs from AppVolumes Database?
          Ray_handels Master
          Community WarriorsvExpert

          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.

          • 2. Re: Purging "deleted" ($||conflicted) VMs from AppVolumes Database?
            matthiasFF Novice



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

            • 3. Re: Purging "deleted" ($||conflicted) VMs from AppVolumes Database?
              howde Novice

              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?

              • 4. Re: Purging "deleted" ($||conflicted) VMs from AppVolumes Database?
                matthiasFF Novice

                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

                • 5. Re: Purging "deleted" ($||conflicted) VMs from AppVolumes Database?
                  SchwarzC Enthusiast

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

                  • 6. Re: Purging "deleted" ($||conflicted) VMs from AppVolumes Database?
                    fdrietatns Enthusiast

                    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.

                    1 person found this helpful
                    • 7. Re: Purging "deleted" ($||conflicted) VMs from AppVolumes Database?
                      howde Novice

                      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.

                      • 8. Re: Purging "deleted" ($||conflicted) VMs from AppVolumes Database?
                        alsmk2 Enthusiast

                        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.

                        • 9. Re: Purging "deleted" ($||conflicted) VMs from AppVolumes Database?
                          howde Novice

                          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.

                          1 person found this helpful