We just set up a new batch of Prod VM Zimbra servers in order to move off of our aged hardware. We have the new servers set up and the old Mailstores linked into the new environment to allow us to use zmmboxmove to move accounts from the hardware mailstores to the VM mailstores. This process worked fine in our Dev and Test environments, but we have an extra twist in our Prod environment. Over time, we've had to add mounts to our HSM storage area to deal with increasing quotas and mail storage. On the current Prod hardware Zimbra, we have three HSM volumes named secondary1, secondary2, and secondary3. On our new VM servers, we are doubling the number of mailstores, thus starting with a single HSM volume. This creates a problem when you move an account from the old mailstore server to the new VM mailstore server. When the zmmboxmove command is run to move an account, all mail for the account will go into the /opt/zimbra/store directory. When HSM runs for the first time, it will move older mail to the new server's secondary1 volume. Unfortunately, neither of these processes apparently reset the Volume ID associated with each mail item. So, we end up with some folders or messages that can't be accessed and give a "No Such Volume" error when clicked. Re-indexing the account does not fix the issue either.
Has anyone had to deal with this type of issue and found a Zimbra command or scriptable way to update the Volume ID in the message database? We have found the field in the mySQL message database and could potentially come up with a script to modify this field, but if there is an easier/quicker way to accomplish this, we would love to know.
Thanks,
Tim Ross
Application Administrator
Enterprise Applications Group
Cal Poly State University, San Luis Obispo