mount server in Backup Enterprise Manager - broken by design?

[pirx]

Case 06063994

I was pushing my colleagues and users towards Backup Enterprise Manager. They should use BEM for VM and FL-Restores, not Veeam Console anymore. We removed the VBR users and created users in BEM. Some of the user had a VBR account before. VBR is v11, BEM is v12 already.

1. one user got the error "The default FLR Helper Appliance settings are not set for VMware infrastructure", he was not able to perform any FLR since then (2,5 months now)
2. to correct this, it seems to be necessary to start a FLR in VBR Console ass the user and specify the mount server there, the users profile is then updated in DB. Which in kind of strange as BEM should work without the need for a VBR user..
3. I just noticed now, that this can and will never work! The mount server is a static entry in the user profile in VBR DB. There is no option to specify a mount server in FLR in BEM. At least I do not see it and support also doesn't. This is not only broken for users with a bad or empty mount server option in DB. It is also broken as I can only have _one_ mount server for all FLR sessions. We have locations around the world, I just tried a FLR of a VM that is located in China - which is using the mount server in Europe. Bad idea. Timeout. Does not work. The local repositories all have local mount server configured. Or a temp appliance could be used. But as there is no option to choose - it's just unusable.


Please tell me that support and me is missing something here. If not, please at least tell me that this is at the top of the features that will be implemented. My current impression after putting more and more effort into it, is that BEM is not suitable for larger and more complex environments. At least when we are finally on VBR 12 we have the Instant Recovery and change restore location option finally

[HannesK]

Hello,
Unfortunately, you describe a known design limitation.

There is a SQL hack to get around 2. One can write the FLR settings directly to the database. This needs to be done "per user". Below is V11 code for MS SQL. I did not check V12, but if you look into the table, I assume that you can figure out if something needs to be changed.

Code: Select all

DECLARE @myid uniqueidentifier
DECLARE @myUsername AS varchar(100);
DECLARE @myUserSID AS varchar(100);
DECLARE @myHostName AS varchar(100);
DECLARE @myHostID AS varchar(100);
SET @myid = NEWID()

-- CHANGE THE FOLLOWING VARIABLES TO YOUR NEEDS
SET @myUsername = 'VBR02\restore1' -- CHANGE THIS TO THE USERNAME
SET @myUserSID = 'S-1-5-21-1170214841-2965465822-4039967163-1001' -- CHANGE THIS TO THE USER SID
SET @myHostName = 'lnxdemo01.veeam.lab' -- CHANGE TO HOST DNS NAME OR FQDN (preferred) AS IT IS ADDED TO VBR
SET @myHostID = 'f9d922c4-199e-451c-ad2d-96313ebd977c' -- CHANGE THIS TO THE HOST ID, use PowerShell CMD on VBR Server: Get-VBRServer -Name <server name> | select Name,ID

PRINT 'Value of @myid is: '+ CONVERT(varchar(255), @myid)
INSERT INTO [dbo].[FlrApplianceConfigurations] VALUES (
@myid,
@myUsername,
@myUserSID,
1,
NULL,
'<LinuxViFlrOptionsInfo FolderRef="" StorageContainerId="" NetworkAdapterId="">
  <CommonOptionsXml>
    <LinuxCommonFlrOptions>
      <HostId>00000000-0000-0000-0000-000000000000</HostId>
      <UseNovellAppliance>False</UseNovellAppliance>
      <ProductionNetworkVlanId>0</ProductionNetworkVlanId>
      <RemoteMountHostId>00000000-0000-0000-0000-000000000000</RemoteMountHostId>
      <RemoteMountHostName>' + @myHostName + '</RemoteMountHostName>
     <IPProperties>
        <UseStaticIp>False</UseStaticIp>
        <StartFtp>False</StartFtp>
        <StaticIp />
        <SubnetworkMask />
        <DefaultGateway />
      </IPProperties>
    </LinuxCommonFlrOptions>
  </CommonOptionsXml>
  <ResourcePoolRef />
</LinuxViFlrOptionsInfo>',
0,
'00000000-0000-0000-0000-000000000000',
1,
@myHostID)

Improving the situation is planned, but I cannot provide a timeline.

Best regards,
Hannes

[pirx]

Hi Hannes,

thx for your feedback. I'll try out the sql script next time, would be good to get this information to support team too, would have saved weeks of debugging. Regarding the general limitation... that's what I feared. Sadly this is one more limitation in the Veeam ecosystem that makes features in our environment unusable.