Difference in FLR Behavior (Windows)?

[CurtLeCaptain]

In both the Veeam 9.0 Console as well as the Enterprise manager - I'm finding that I'm being prompted for credentials when restoring files. This wasn't the case in Version 8.0, which is causing my helpdesk some heartburn as their accounts don't have rights to connect to those servers at an admin level.

What I see in the e-mail we get:

File restore by DOMAIN\user
Restore type: In-place restore
Date: 01/15/2016 13:33:58
Status: Error

Log:

Code: Select all

Starting FLR job for VM VMNAMEHERE
FLR job started successfully on server veeamserver.domain.local
VMNAMEHERE: File level restore started
VMNAMEHERE: Mounting restore point
VMNAMEHERE: Batch mode
VMNAMEHERE: Using veeamproxy.domain.local as mount server
VMNAMEHERE: Enabling backup operator privilege
VMNAMEHERE: Dismounting restore point from VEEAMPROXY
VMNAMEHERE: Credentials exception
Failed to connect to guest agent. Errors:
'Cannot connect to the host's administrative share. Host:  [ip.add.re.ss]. Account: [myaccount].
Win32 error:The user name or password is incorrect.
 Code: 1326
'
VMNAMEHERE: Restore failed Error: Failed to connect to guest agent. Errors:
'Cannot connect to the host's administrative share. Host:  [ip.add.re.ss]. Account: [myaccount].
Win32 error:The user name or password is incorrect.
 Code: 1326
'
VMNAMEHERE: Restore job is failed
VMNAMEHERE: Transmission agent has been stopped FLR job failed Updating FLR session history

Just seems odd as of 9.0 it had a major functionality change. I did open a case: 01513442

[foggy]

Hi Curt, indeed, v9 has a major FLR functionality changes: we've introduced mount server, 1-Click FLR without indexing, and some other enhancements as well.

Could you please check whether credentials for application-aware image processing/guest indexing are specified in the job settings?

[CurtLeCaptain]

Yes - credentials are specified in the job settings.

[foggy]

Then, provided credentials are correct and mount server (veeamproxy.domain.local) has access to guest OS (you can open ADMIN$ share on this VM from the mount server using those credentials), there should not be any prompt during files restore to original location. Please continue working with your support engineer on this.

[stuartmacgreen]

Has this been resolved?
I am seeing similar symptoms.

Using BEM to Restore/Keep a file to the source VM.
The Guest OS Credentials used in Guest Processing successfully pass all the "test now" tests.
But get the same:

Credentials exception
Failed to connect to guest agent. Errors:
'Cannot connect to the host's administrative share. Host: [192.168.1.54] Account: [veeamservice].
Win32 error:The user name or password is incorrect.
Code: 1326

Running Veeam 9 Update 1.

[foggy]

Stuart, are you able to open ADMIN$ share on the affected VM from the mount server using these credentials? What mount server is specified in the repository settings?

[stuartmacgreen]

I will log a Support case. My mount server is the same repository server the backup files are located that I am using to restore from.
This server I can logon as the credentials in Guest Processing.
Its not making sense... see if support can make sense of it.

[foggy]

Yep, opening the case is recommended. Thanks!

[sdis68]

Hello,

We try to use the Enterpise Manager to restore file within some VM but we face to certain problems.

When we try to restore a file on a Windows VM that is not in the same IP range that the backup server, it didn't work. The server keep asking for OS guest credentials. But if we try to restore a file on a server in the same IP range that the backup server it works.

In the VeeamMount log file it says "Cannot connect to the host's administrative share.".

Is there any limitations due to IP range when we restore file trough Enterprise Manager ? I coudln't find anything in the documentation.

Thanks.

[Dima P.]

Hi sdis68,

Mount Server server that is used to perform restore VM guest OS files and application items to the original location must have access to the backup repository with which it is associated and to the original VM, thus restore to original location is failing.

[sdis68]

Hi,

The mount server is accessing the backup repository and the original VM. But when the original VM is in another subnet that the mount server it doesn't work.

I will open a case.

Thanks

[foggy]

Nicolas, if you are able to open ADMIN$ share on the VM from another subnet from the mount server using the same credentials that are specified in the job settings, please open a case for closer investigation. Thanks.

[stuartmacgreen]

Case # 01813599
In the end what worked was the recommendation to use credentials of a|the Local Administrator account of the computer that is the target for the restore.
So a DOMAIN account that is a member of a group; that group is in the Local Administrators group on the domain computer for the restore; using those credentials DO not work.
I would have expected this to work.
:/

[foggy]

Is UAC enabled on the affected VM?

[stuartmacgreen]

Confirmed UAC is disabled.

[foggy]

And just to double-check, since you didn't mentioned that clearly, you were able to open ADMIN$ share on the VM using that DOMAIN account from the repository server?

[stuartmacgreen]

Yes, I was able to use that DOMAIN account from the repository server, and from the backup server to access the ADMIN$ share on the target VM for the restore.