Application Aware Image Processing: Guest OS account dilemma

[MartinC]

Hi

I'm having a problem reconciling our security policy with the requirements for the "Guest OS Credentials" for Application Aware Image Processing. I thought I'd air it on the forum to see if there is a workaround.

Our network security policy states that all "administrator" accounts must have passwords that change periodically. Consequently service accounts have to be non-Administrator or Windows "built-in" accounts. This conflicts with the Veeam B&R requirement that we provide the credentials for a local Administrator in the Application Aware Image Processing. I'd prefer not to have to update the job properties every time the password changes.

On investigating this further, according to Microsoft VSS documentation the VSS Requestor can be a member of the "Backup Operators" group and does not have to be an Administrator. That would be fine however, when I try this Veeam B&R is unable to install the Agent:

Starting guest agent
Cannot upload guest agent's files to the administrative share [C:\WINDOWS].
Cannot create folder [C:\WINDOWS\VeeamVssSupport] in guest.
VIX Error: You do not have access rights to this file Code: 13

I wondered if there is a supported workaround by granting "Backup Operators" permissions on specific shares and folders to enable this to work? Is it even possible?

The environment is VMware ESX v4.1 and all VM's are Windows 2008 R2.

Thank-you in advance.

[Bunce]

Interested in this also. Had to run through this yesterday and change password on all our jobs. At a minimum, should be able to set this at a global level and apply to all

Ideally, it would support the new Managed Service Account (MSA) feature where password changes are managed automatically via AD (similar to computer accounts)

. Consequently service accounts have to be non-Administrator or Windows "built-in" accounts..

By non administartor, do you mean Domain Admin or Local Admin?

if the latter, could you get away with placing your service account in a new security group (eg YourDomain\LocalServerAdmins), and adding this group to the local Administators group on VM's you need to backup using AAI? You can easily deploy this group to local admins using Group Policy Preferences.

You'd still be giving the account local admin privs on the VM's but it wouldn't need to be a 'Domain Admin' so might satisfy your policy?

[MartinC]

Bunce

Thank-you for the reply.

When I say "non-Administrator" I mean that the service accounts which have non-expiring passwords cannot be members of the local machine "Administrators" group so neither Local Administrator nor Domain Administrators can have non-expiring passwords. On the other hand, members of the "Backup Operators" group can have non-expiring passwords.

[Gostev]

The account has to be local administrator, as explained on the corresponding wizard page.

[MartinC]

Gostev

Okay. That's a shame. Perhaps that can go on the wish-list for future versions. I'm sure this restriction will be similar for many large corporate environments.

It appears that this restriction is imposed by the Veeam usage of VSS rather than Microsoft's implementation of VSS. Would it help if there was an option to leave the agent permanently installed? Then it could be installed once using an Administrator and subsequently all VSS operations could be performed using "Backup Operators"... Just thoughts...

Thank-you for clarifying the issue.

[Gostev]

OK, at first this has nothing to deal with the Veeam usage of VSS. You are wrongly assuming that our agent is nothing but simple VSS requestor, which is not the case. Our application-aware processing logic does far more than that (you can learn more about it from stick FAQ topic, but in short VSS interop is only small part).

You are correct that partly this requirement comes from not having persistent in-guest agent, but rather using run time process. It should not be too hard to provide an option of having "permanent" agent install (although this only welcomes usual agent management hell, which is one thing why our customers prefer us over competing solutions). However, it may not allow to completely get rid of administrator privileges requirement because of other things this in-guest process is doing to facilitate correct image-level backup.

Thanks for bringing this to our attention though. Each request raises the priority of the corresponding feature, and makes us take a look at it sooner rather than later.

[derekf]

This is also a major headache with us and potentially all other Service Providers who want to use Veeam. This is made even worse by the fact that we can't even use VMtools quiescence on Windows 2008 R2 servers meaning we only have crash consistent backups - possibly the only, albeit fairly big, deficiency we've found with Veeam

[chrisBrindley]

Have you found a work around to this issue, I am also running into this problem as mentioned in a newer post, seems like this topic has no answers