An irritating issue today was solved – with some help from Veeam forums. I recently went through the Veeam Certified Engineer training and test (yes I passed!). As a result of that learning, I wanted to enabled guest file indexing and / or application aware processing. Here is what it looks like:
However, during the setup I used the Test Now button (I always use the test button). Which is seen in the image above in the bottom right. When I do that I hit an error. It is very long but it starts with Connecting to guest OS via VIX Error … and ends with 4. Here is what it looks like:
In the first screenshot you can see I am using thewhites\mwhite account which is mine and of course it has all access. I tried a number of different accounts – including the domain admin service account I had planned on, and nothing worked. Google found first an article that suggested trying domain\user instead of user@domain. I have a policy on new stuff using user@domain and old stuff using domain\user. But I had already tried both with no luck. Google also brought me to this article where it seemed he had the same issue as me. Certainly the same error. But I did not like the idea of removing and installing VMware Tools. It was the internal forums for Veeam where someone suggested to try a local account. And that worked – in my case I used the local administrator account. What does success look like?
If you create a local service account on each machine, put it in the local administrators group, and create ONE identity in the Veeam Managed Accounts area it will work for all your machines. Of course managing the password will suck but at least you will not have to create a managed account in Veeam for each VM! So it would look like this:
Notice you see in Guest OS Credentials administrator and not domain\something? This account and password will work on each VM that has the matching account and password.
Yes, I know this sucks. I like to have much better password management. If you used a tool like this one you could change the account every 60 or 90 days and make one change in Veeam to account for the new password. Not idea, but better.
Any better ideas would be much appreciated. Also, why a member of domain admins where domain admins is a member of local admin, doesn’t have the necessary rights, but the local admin does, would be great to understand.
- 4/11/18 – another co-worker (thanks Hannes) shared a very nice table that helps with the permissions side of this. I much appreciate being able to share it. Stay away from the methods with the red asterisk if you can at all help it.
- 10/28/16 – more info on this issue can be found in this article. Thanks Nick for this!
- 6/29/16 – One of my co-worker (thanks Tom) suggested that this could be caused by the RDS role in the OS of the VM. The solution to that is using a local account as I mention above.
- 6/29/16 – Another interesting comment (thanks Luca) was that if the VM was using UAC you need to use a local account, but it it was not using UAC a domain admin should work. That was not my experience but it is worth remembering as I saw comments like that elsewhere.
=== END ===