Feature request - mount to console by default

[RGijsen]

Hi,
since V10, when doing guest-file restores, by default it mounts on the backup server. That's very annoying to us, as it takes quite a while to mount a large backup. As we usually need to mount it to the console-machine, after pressing that button it again takes a (relatively of course) long while to mount. We do this in order to be able to access the files from either a command prompt (ie robocopy) or simply explorer.

Can we get an option to enable 'mount to console' by default? Or is there a magic registry key for that already maybe?

[foggy]

There's no such a registry value. If you're not using FLR and just do a robocopy/Windows Explorer, you can simply specify the server running the console as a mount server in the repository settings.

[RGijsen]

Coming back to this, even if it's been a while. Our management server, where we run the Veeam console from, is NOT a mount-server and it shouldn't be. If I understand correctly the mount server is also the one used for instant recoveries. That should (in our environment) never run through a remote console server, but through the backup server itself, which is specced accordignly, and also firewall-wise it's better. As the Veeam host itsels is not part of any domain, using robocopy or explorer to a FLR mounted on the backup server gives all kind of authentication issues. In the past (pre v10 that is) the FLR was mounted on the console machine by default, at least in our setup. And that's the way we want it.

So I want to push my request again. We'd really appreciate an option to mount a FLR session to console by default, rather than having to do additional steps.

[Helge.T]

+1 for that FR, I have quite a large customer with the exactly same request.

[RGijsen]

In a service request I recently had, I also opted for a feature request. The representative told me to use the forum to get request acknowledged, as the forum is monitored tightly. I told him the forum never once responded to consider a request I or my colleagues did. And yet again, in this topic, that's what happens again. I get ONE respond from foggy this time, which basically tells me the feature I want is not in the product. Well, that's why we do requests, isn't it? I / we really love Veeam as it (most of the time) 'just works', but I must say the last couple of years, they are less and less listening to their customers and more and more dictate us how we should use our systems. Something a certain Veeam representative that sends out weekly digests accuses for example Microsoft of (remember the Office365 rant?).

So, please tell me, is this the way to place an 'official' feature request, and how long for someone from Veeam to respond? I'm not talking about implementation time, if at all, but just the acknowledgement of the request.

[Gostev]

Simply sharing your use case and any issues with it here on the forum constitutes the official feature request and triggers certain processes even if you don't explicitly request anything. The information you provided is enough for us to take a note about this issue and start tracking it, otherwise we'd follow up with additional questions. But in your case everything is clear - and if this becomes a common request, we will prioritize it for one of the future releases.

The support representative is incorrect though in that we have some process here that requires the feature request to be "acknowledged" somehow before we action it... sorry they misinformed you, they are simply unaware about our processes.

[RGijsen]

Any update on this? It keeps annoying the hell out of us.

[Gostev]

It was too late to include in v11, but we will consider this for future releases.

[RGijsen]

It's been over a year now, and this still annoys the h#ll out of us EVERY single FLR session. This realy seems like a very trivial option to include, yet it didn't make any of the updates so far. When can this be expected?

[Gostev]

There has been literally no other requests for this, so we can't prioritize it over other pending FLR enhancements. We don't add features just because they are trivial to add, rather we look at demand and value to the product.

[RGijsen]

That doesn't mean it can't be fixed right? Also it wasn't an answer to my question, as when of if at all we can expect this to happen. Just roughly. By the way, in this very thread it another user that requested this.

In our own company we of course also have a list of user requests. Some will take quite some time to implement, so we'll have to prioritize some things over others. But there's also some requests that just make sense, and take such little time to implement that we process them before other bigger changes that might have requested before those. And that makes those customers super happy. This very request was done over a year ago and absolutely nothing was done to make us (or Helge.T) a more happy customer (at least not visible to us). Sorry that I can't appreciate that.

by the way:

We don't add features just because they are trivial to add, rather we look at demand and value to the product.

In V9, when we did a FLR, it automatically mounted at the console we were actually running the Veeam console from. So the functionality actually changed in this regard, and not to a positive for us. This is not about a new feature, it's about getting removed functionality back.

[MrSpock]

+1

[Gostev]

Unfortunately, I can never comment on when any particular pending feature request might be delivered even roughly. But this one certainly won't be delivered before a few much more pressing FLR enhancements with literally hundreds of requests across the past 5-10 years. While this above is just not a common request in comparison.

[Gostev]

We do this in order to be able to access the files from either a command prompt (ie robocopy) or simply explorer.

By the way, may be you will like our Data Integration API as a workaround for some of those use cases meanwhile.

[RGijsen]

Unfortunately, I can never comment on when any particular pending feature request might be delivered even roughly. But this one certainly won't be delivered before a few much more pressing FLR enhancements with literally hundreds of requests across the past 5-10 years. While this above is just not a common request in comparison.

I understand you can't give any ETA's. But WOW... without trying to be a bitch here... if you have requests open for 10 (TEN!) years, you have some serious issues...

Anyway, it's a bit more clear again how Veeam works for us.. Thanks for the insights. I'm totally disappointed with Veeam at the moment. And not about this particular request, but with the attitude shown here in general. Yet at the same time you made my day making me realise our company (the one I am 50% owner of) has different standards.

I'll revisit this post in 10 years to see if anything has changed. No pun intended.

[Gostev]

10 years wasn't a typo... I finally was able to get one of the oldest FLR feature requests into V12

I would not say these issues are somehow special or unique to Veeam though. In fact, I would be surprised for any successful company with over 1 million active product installs not to have 10 times more feature requests than available R&D resources can handle in 1 year. Just imagine how many requests we get with all those customers wanting something from us based on their processes and needs. All we can do is navigate as best as we can in prioritizing those feature requests while considering a dozen of variables.

[RGijsen]

Yeah. well this is probably my last reply on this as I know discussing this is useless. Of course I understand things change when you grow to a large scale. Yet small customers are JUST as important as big ones to us. The fact that there's only a few people with me in this specific request, doesn't justify (to me) keeping those people 'unhappy'. If there is THAT many requests and THAT much of a backlog... then there is probably some understaffing going on. And yes I know you can't make everybody happy.

In the past I worked for one of the top 500 companies. And I can tell you it's an absolute breath of fresh air to be working in a small company again, if for bureaucratic reasons alone. On the other hand, when I was the lead for Citrix environments for Europe, Middle-East and Africa for this company, I can tell you all I had to to with MS, VMWare, HP, Dell and yes even Veeam (we were rather early adopters I think in 2009) is snap my fingers and they would line up to fix our problems. Not because of me, but because of 'the business case' of being in a large company. Now we are with just a few people, and whenever we have an issue, I have to keep struggling and pushing and pushing to even get our issues or requests acknowledged.

When we started our own company, I promised myself to handle every single customer equally. Be they just alone, or with 500 workplaces (its not like I have 50.000 sized customers). It works out great for us and our customers, who are extremely loyal to us.

Don't get me wrong - I'm an advocate for Veeam products. They just work. But still I feel, especially after your last few posts in this thread we as a customer are not taken seriously. And that feeling should never happen to any customer. Just my $.02.

Thanks for understanding. (That's how these discussions are usually cut off right?)

[Gostev]

We too try to be fair to our customers regardless of their size. And it just would not be fair to prioritize a request from 3 customers until we have addressed other existing requests from 30 and 300 customers. I also hope for your understanding here

[RGijsen]

Hi,
it's been almost been another year. And we still would want this feature back (as it WAS in there before) very badly. A few days back I read an interesting post about the 15-minute-bug initiative, which I personally really like the idea of: https://pointieststick.com/2022/01/18/t ... nitiative/. It's more or less the way we work ourselves as well. Whenever we are working on a big change or researching something that takes long, whenver a small change comes in which can be done in a short time, we tend net to let that customer wait for that big change to be done. Now I'm not sure if 15 minutes, or any exact time would be a good measure, but you'll get the idea.
Still wanting this feature in, which I really feel is extremely simple to get back in using a checkmark (as mounting to console is just a single button, so when a chekcmark is set, just call the function behind that button rather than the default mount-to-backup-server function), and pleases some customers.
I'm completely willing to volunteer for the first 15 minute feature request

[RGijsen]

Meanwhile we are with Veeam V12, and this very simple to implement thing, which was in there before, is still not back. I'm 100% unsatisfied with this. As a best-practice, we have our Veeam machines not domain joined, to lower it's dependencies when sisaster strikes. But that means, mounting a file-level restore at the Veeam server side, means you can't access it without using (local) credentials of that Veeam machine. And those credentials should never be used, as they need to be admin credentials too.

So I still want to push this. The frustration level is enourmous when Veeam finally mounted a 6TB fileshare with millions of files which takes minutes (fair enough) just to be unmounted again, and then mounted to the console machine in order to be actually able to use it.

[RGijsen]

It's still not there. I'd like to bump this up again. This week I've had to recover several individual files from a 6TB file server, which by today standard is not even that big. It hosts millions of files though, not sure if that's the reason, but when mounting this for file-level restore, it takes 5 or so minutes before it's mounted on the backup server. But I want it on our console machine, as the backup server is locked down, is not in a domain.

So please again I'd like to bring up this feature request. It's a very quick change (it was in there before even! It's removed functionality) imho, we've first requested this 4 years ago.

[RGijsen]

And now we're at 12.3, and still nothing has been done with this.

[RGijsen]

Hi. I've had a feature request since 2020, which was for V10. We're now at V12.3, but no-one responds to my request anymore when I ask for a status, for over two years now. We don't feel really taken seriously anymore by Veeam. But here I go again. A new year, new spirits, let's try again!
Basically, in the past we had the option to mount a FLR to the console-machine by default. Since that has been removed (V9 still had it IIRC), FLR from our file server has become a pain. Our fileserver isn't even big, about 6TB or so, but it has about 14 million files. Mounting an FLR session of that fileserver takes something like 4-5 minutes. Our backup server is obviously not domain joined, so it's a hassle to connect to a FLR session using SMB to the backup server itself (and with NTLM being depricated by MS, it might even be considered insecure or imposibble after that). So after mounting it on the backup server, I always need to click 'mount to console', and then wait another 4-5 minutes is needed to mount it on our management server where the console runs.

This makes FLR rather frustrating. Removing a useful feature, and then getting a response, and I quote 'There has been literally no other requests for this, so we can't prioritize it over other pending FLR enhancements. We don't add features just because they are trivial to add, rather we look at demand and value to the product.' Well... then why was it removed in the first place? Also, in our book this IS adding value, namely faster FLR restores. Maybe others aren't requesting as they don't know any better. But in the past, this simple option was just there making FLR on larger systems much more usable. It's just one of those little things that improve the experience.

So, I sincerely ask to review / reconsider this again, and if other people here think this is useful, please report in this thread too. Thanks!

[david.domask]

Hi RGijsen,

Thank you for sharing your thoughts on the matter -- while I'm sorry to tell that currently the behavior remains, a few questions if I could on the situation and the use-case here.

1. What is the purpose in your workflow for the mount to console part? Checking your previous topic, you mention performance, but not quite sure I'm getting it. Mounting to console basically allows you to interact with the mount as if it were in Windows explorer, and not quite getting how it relates to performance

2. Is it feasible to set a mount server in your environment that is better positioned for your restore purposes?

3. If performance is the main concern, has Instant Disk Recovery been tested? It can prove to be more performant in many cases.

[RGijsen]

Our backup server is isolated. It's severely firewalled too. We use a management server, on which the tools are installed we need, and work from there. Veeam console is installed there too. When we would RDP into our Veeam server, and would start console there, we are running using a local admin account, as obviously our Veeam server is not domain joined. This means, as per NTFS, we have issues accessing files on those disks, as it would need the 'administrators' group in the permissions, which certainly isn't always there. Apart from that, while the backup server can connect to SMB to other VM's, it would be a hassle as we'd need to map a drive with credentials.
On our management machine, we are usually logged in with an account which has enough permissions to access te resources we need, both from domain and firewall perspective. So point 2: this IS the best place to have the console for us. Yet it always mounts on the backup server first.
Instant disk recovery isn't a thing on Hyper-V IIRC. But still, I don't want to restore a whole disk (I might not even have space to restore the main file server disk), we usually need to restore just one or a few files. It worked great until V9, so my 'goal' is to get that functionality back, as that was so much more convenient.

However, if you state the behavior remains what do you mean with that?