V10 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.