Backup Exec AVVI VMware guest backup resource selection order still broken...

Why? What purpose does locking the threads serve?

So that abandoned discussions are not revived.  If you have a similiar problem, you can start a new discussion and reference the old discussion.

If I check the first thread which you posted, the OP doesn't mention the problem was present in BE 2010. He mentions it was present in BE 2012.

Have you had a look @ this KB for changing the resource order - http://www.symantec.com/business/support/index?page=content&id=HOWTO99628

Lastly, if the issue persists in BE 2014, pls log a formal support case for us investigate the problem further. Thanks.

What is the actual difference between a discussion that is abandoned and not locked and a discussion that is abandoned and locked? Other than, once a thread is locked it's dead in the water.

The whole process of locking discussions, abandoned or not, seems a wholly pointless activity. There is potentially more to gain if the threads are left as they are. At least that way you don't need to open another thread and link back... Just add to the existing thread to try and prompt from the original contributors to respond with the resolution. At least that way you won't end up with thousands of dead end topics that were never resolved and abandoned and have no chance of ever being resolved as they are locked.

The topic of this thread is a classic example of how locking threads, pointlessly, actually hinders the flow of discussion about problems that are identified and remain problems through multiple major releases of the product. Closing the threads does nothing but choke and fragment the conversation.

Anyhow... Right way, wrong way, Symantec way. I guess it's all working as designed!

Whilst a serious matter this is, none-the-less, a distraction from the main subject of the post.

Hi VJware,

My bad. Typo in the first line, which referenced the problem as being identified in Backup Exec 2010, which should have read 2012. I've updated the post to reflect this.

The methods for reordering are easy enough to find in Backup Exec 2014, as they are in previous versions. The problem I am experiencing directly is in trying to change the order of resources for backup in the AVVI selection list. After selecting my vCenter server the selection list shows the sub-folders, created in vCenter, below the site name. You can select the VM gusts here to select which ones you want to back up. NB: If you want to change the resource orders for VM guests at all, you have to select the individual VMs in the selection list. If you select the site or containers, then the object being backed up becomes a wildcard selection of the object and it's subordinates

To change the order in which they are backed up, you select the "Selection Details" tab and then you can move the resources up or down the list to your desired order.

However, when moving the VM guests, using the Up and Down arrow buttons provided, the guests do not move up and down particularly well. You would expect one click of the down button would cause the selected resource to move one step down the list, and one up for the up button. However, this behaviour is not consistent when moving all of the guests. Sometimes the resource has been seen jumping to the bottom of the list and when this happens it has been noticed that other unselected resources (selected for backup, but not currently selected to be moved in the list) can change their order. Basically the interface is jumpy, inconsistent and can change the order of unselected resources, in the list, randomly.

The upshot of this is that it is not possible to get the resources into the order required.

I have opened a case with support, prior to posting this thread. The support engineer and I tested this problem for consistency in its inconsistency, and proved that the interface for changing the resource order is buggy. The engineer said he would escalate this problem to the dev team. I am checking with the community to see if other people have had similar problems, only to discover not only is this a known bug in the product but that this appears to have been a bug identified since Backup Exec 2012!