v12 Ignoring View Setting

[mkaec]

When I navigate around and select a job, v12 is ignoring the View setting. For example, if I click Last 24 hours, then click on a job, the bottom pane does not appear. If I go to View, Full View is already selected. I have to change it to Off and then back to Full View. After that, the bottom pane will remain until I leave the section (like click over to Jobs > Backups). Is everyone else experiencing this? I can open a support case if it's not already a known issue.

[Mildur]

Hi Marc

I tried it myself in my lab.I clicked on Last 24 hours --> Statistic pane always opens for me

Maybe you can delete your backup console user config and try again:

Code: Select all

C:\Users\[UserName]\AppData\Local\Veeam_Software_Group_GmbH\veeam.backup.shell.exe\11.0.0.0\user.config

If that doesn't help, please open a case and let us know the case number.

Best,
Fabian

[mkaec]

That fixed it. Thanks!

[mkaec]

The problem came back. I will open the support case.

[mkaec]

Support case: 05979229

It seems like the problem develops after the console is open long enough. I tend to leave the console open for 24/7. Closing and restarting the console will temporarily eliminate the problem.

#MOD: Replaced Contract Number with Case Number

[Mildur]

Hi Marc

Thanks for opening the case. I replaced the contract number (#01) with the case number (#05).

Best,
Fabian

[mkaec]

Thanks. I must have grabbed the wrong field into the clipboard.

[Lazydude]

I've noticed this exact same thing after moving to v12 from v11. I have to switch the view to off, then back to Full View for the Full View to come back on. Not worth the time of opening a case - but just saying same thing here.

[mkaec]

I have succeeded in reproducing this. I left a job selected in Last 24 Hours > Success. After the job aged out of the view, the console removed the job and closed the bottom panel. After that, the view setting started malfunctioning for the rest of the session.

[Mildur]

Hello Marc

Thank you for the update and updating the case.

Best,
Fabian

[mkaec]

In these forums there is periodically criticism of Veeam Support. I think my case is a decent example of a non-ideal experience.

After I posted here describing how to reproduce the issue, I posted the same to the support case. But I also recorded and uploaded a video demonstrating the problem. The video shows the bottom panel going away just as the selected job disappears from the grid. Then it shows the bottom panel not returning as I click on other jobs.

So what did support do next? ... drum roll ... they asked me for logs. I had already provided logs at the start of the case. Death by 1,000 log requests is a common criticism. Armed with a video showing exactly how to reproduce the problem, support went for the same old move of asking for logs. This makes me wonder if this is just a way to get some timer to stop so that the case looks like it is being held up by the customer. I responded that they shouldn't need me anymore. The video shows them exactly what's going on. 11 days later, they wrote back that they were unsuccessful at reproducing the issue and asked for more logs. So, I did it. I took the time to generate and upload more logs. Then I was requested to upload a copy of the entire database. I declined this. Support has still been claiming that they can't reproduce. So, I asked them to do the same courtesy for me that I did for them - record a video of the repro steps so I can see the failure to reproduce and possibly offer suggestions if something wasn't clear in my original description or video. They have not provided that. The latest response I got was that they're checking with R&D "...to confirm if this behavior is unexpected." I would think it would be obvious that this behavior is not by design. I guess they haven't yet gone for the "this isn't a bug, this is a feature request" response that is common in the industry these days. So a plus for that. But almost 4 months since the case was opened there has been zero progress.

How could this have gone better? After I upload the video showing how to reproduce, I get a message back stating "thank you, we have reproduced the problem and sent the details to R&D".

[BackupBytesTim]

I'll agree with support's tendency to just repeatedly ask for logs even after they've already been provided. Really gives me the impression they're more interested in closing the case than actually fixing anything, so if I then forget to upload the same logs all over again they can close it and be done. I've also had people claim the logs I uploaded were from the wrong components, even when they weren't, leaving me the impression that again, they're stalling, or possibly the low level support staff really just don't know what's going on and just reply with predetermined responses all the time. And lately I keep having support ask for logs that the Veeam software doesn't even have any collection method for, they want me to run a separate PowerShell script, which normally I'd be fine doing, but I have no way to do that across all my customers affected by the issues, so it's usually easier for me to just ignore Veeam's support and search the forums for an answer, and asking on the forums, the Product Management staff here tend to be pretty good with at least letting me know if what I'm experiencing is indeed a problem.

Just wish there was some way for Veeam's customers, particularly service providers, and/or customers with a certain number of licenses who must be paying Veeam a decent amount of money for said licenses, to just altogether bypass the initial support process and jump straight to someone who both understands the logs and has a decent understanding of how the Veeam software works. I get greatly annoyed when we have support cases where I have to explain to the support team how things work, or how it's set up in our environment (when it's a perfectly normal/standard setup).

I don't want to be "that guy" who's just never satisfied, but Veeam's development process is too slow for me to be satisfied with "we've identified the issue and passed it on to the R&D team for a fix in a future release". I've seen way too many such issues on the forums where a major release comes and goes and minor releases come to fix issues and a couple years go by and the original still isn't fixed. I don't know how many people are on the dev team, but it seems like even little issues with the interface take years to get resolved, and if anything comes sooner it's usually in a custom "patch" that's not published as a full release. I've literally never seen any other company do that, I'll admit that I've also never used a product that was both so unreliable and confusing to use that I've had to work support this much, and so my experience with Veeam's "hotfixes" may not be the best comparison, but from my perspective if you fixed it, why not publish it an actual released update to everyone? We've tended to accumulate so many different custom "hotfixes" across our environment, I never know if installing a regular update will break things again because some of those "hotfixes" weren't included in the general release. Also it doesn't help anything that installing hotfixes often breaks remote access compatibility from the VBR console to a remote VBR server.

I'll add, before someone labels me as "that guy", I really do want Veeam to work. I know it may not seem like it based on how many issues I've brought up and how many complaints I've had, but I do want it to work. At this point, I'll admit that the biggest reason I want it to work is because I don't have a choice in using something different, but I also just like the idea of it working. However, it definitely does not just work. It is incredibly complicated to set up and even more incredibly complicated to work with on a daily basis, the interface is very counter-intuitive and there are just way too many different things that either don't work or simply lack basic functionality that I would expect to have. And then to top it all off, support is rarely able to solve anything to my satisfaction so all those things that don't just work are nearly impossible to make work, and all the missing functionality I really have no expectation will get added before I just stop using Veeam.

[david.domask]

Hi @mkaec,

First, let me thank you for bringing your concerns regarding the issue being worked up; I can understand the perception of there being a "script", but I'd like to shed some light on why logs are typically requested fairly frequently.

Very often we do need to track items fairly specifically, seeing not only the current error message, but as noted in the case, the conditions leading up to it. For UI issues for example, we have to consider several elements such as the database load, the available resources on the Veeam server and the server hosting the configuration database, the actions taken in the UI; for issues we cannot easily reproduce in lab, we further need to understand what activities specifically trigger it at the log level; while the actions at the UI level may be clear, a lot of activity happens underneath to make the UI appear the way it does, and sometimes we need to compare a few reproduces to understand the steps in your environment leading to it and to understand why we couldn't reproduce in lab.

For example, if it were me handling this case, I would want the additional logs too if I couldn't reproduce with my lab machine, and I'd also get a copy of the configuration database and just try to reproduce your steps on your configuration database; if I could not reproduce in a lab environment with your configuration database, it's not conclusive, but it would be evidence for me to look more at the environment rather than a wide spread issue, as perhaps specific environmental factors lead to it.

Feel free to always ask on the reason for the log request; the engineers are instructed and required to justify the requests, and in this case I can see there was a "sort of" justification, but my expectation is that you would understand from such explanations the same information I relayed above so you could understand why I'm asking for logs and what I hope to understand.

The behavior you're observing is not yet identified as an issue, and we really don't have wide spread reports of such behavior; the before-mentioned "similar" issue I think is not related, and I'm not sure what the initial engineer referred to (theoretically they meant an old v11 issue where sometimes the UI was slow to refresh, but I am not confident based on what I saw in the case that this is relevant; not ruling it out, but just not sure it's relevant.

I will be providing guidance to both of the Engineers you've had on the case on explaining the research process a bit more; I know this case has been open for a bit, but it's really not a wide spread issue, and right now we're requesting the Configuration Database to try to take the strategy I discussed above.

@BackupBytesTim, much of the above applies as well but can you maybe PM me a few cases of interest for you? I'd like to check the history on those cases.

Also, please understand that there are no scripts that the Support Team are required to follow, outside of simple guidance on making sure they're properly greeting you and other niceties. While the forums can often offer _workarounds_ to issues, the root cause often is obscured by such workarounds and very often leave the real cause undetermined and with the potential to re-occur; I can understand that sometimes you just need it working, and sounds like you have some concerns over the product itself in general, so I can appreciate wanting it to just work, but that means that the cause of the issue may not always be there.

However, that being said, I understand you have concerns on the support process in general; if you can PM me a few of the case numbers to check, I will look into it and we can discuss it further.

[mkaec]

David,

It's my opinion that the issue can occur to anyone and there isn't anything specific in my environment causing it. Why isn't it widely reported? I think the issue is minor in the grand scheme of things and many people who might report it find it easier to just restart the console than to risk getting into a time consuming engagement. I reached out because I wanted to help make the product better.

To be honest, when support tells me they can't reproduce it, I think they either aren't trying that hard or I did a poor job explaining the steps. They never did fulfill my request of providing a video of them going through the reproduction steps.

To hopefully stop being asked to provide more things, I built a new VM, installed Veeam B&R, and reproduced that issue. I uploaded a recording of that and the whole VM. Since I was able to reproduce in that VM, support now has 100% of what I do, unless the Hyper-V host could be involved (which would raise some questions about virtualization).

I guess I should have a little perspective. Many other vendors would have closed the case with "recorded enhancement request" and then forgot about it. It's good that Veeam does care about these things, but given that I opened a case with a video showing exactly how to reproduce, I feel like things could have gone much better.

[david.domask]

Hi @mkaec, I can appreciate your point here, and your understanding of the issue. For what it's worth, I have checked the videos and tried the same steps, but in all my lab environments (and testing on some other Configuration Databases I was reviewing for other cases), I simply couldn't reproduce with the steps from the video. The UI updates promptly and correctly and respected the view even if I had a bunch of jobs running on a meager lab machine.

I can understand how you reached your conclusions, but I'd like to offer my perspective on it: instead of poor explanation or incorrect reproduce, it's possible that we just don't quite have the specific item that triggers the behavior you're seeing isolated. This isn't dismissing your testing or the issue itself, it's just a statement of fact that "right now, we do not know why it happens for you but not in the environments we tested in", which while not solution, it's a fair assessment of the situation and an indicator that we need more research.

The part about virtualization _might_ be relevant, but right now it's just not as clear.

Typically with an issue like this, as I alluded to earlier, the first step is to test with the same database in our lab; this helps narrow the scope greatly, and if we _can_ reproduce with your configuration database, this means we can get all the logs we need without having to ask for more It's why I was a bit surprised that we only got to the DB request relatively recently, as usually it's a very fast way to reduce the scope of the research.

I do appreciate that you can still find a positive element of this, as that concept that we're going to work on it even if it's hard to pin down; I don't want to exhaust the good faith behind that positive element, it's more I hope you can see that we do want to solve this also, it's just turning out to not be so clear what is triggering the behavior you are seeing. Right now the case is where it should be, and two of our Advanced/Expert Engineers are working the issue, so I'm hopeful if we can get a copy of the configuration database, we can succeed in reproducing and checking in lab a bit more carefully what is going on.

[kaffeine]

When I navigate around and select a job, v12 is ignoring the View setting. For example, if I click Last 24 hours, then click on a job, the bottom pane does not appear. If I go to View, Full View is already selected. I have to change it to Off and then back to Full View. After that, the bottom pane will remain until I leave the section (like click over to Jobs > Backups). Is everyone else experiencing this? I can open a support case if it's not already a known issue.

Yes, I can confirm this. We're also seeing it on our end on the most recent V12 patch, and the way to make the view pane to re-appear is exactly the you pointed out.

The view pane with the job details just seems to randomly disappear, and so far I couldn't find an error pattern for this behaviour (ie. I still don't get what triggers the disappearance).

[mkaec]

The consistent trigger for me has been to click on a job in Last 24 Hours > Success, bringing up the bottom view pane. Then just leave it there until B&R removes the job from the list. After that, the malfunctioning behavior starts.

[mkaec]

David,

When support first asked me for the configuration database I was warned that "Please be aware that the Veeam database may contain sensitive information, such as server hostnames and IP addresses, and other infrastructure information which may be confidential." This put me on edge that what was being requested may be dangerous and and made me hesitant. It may be correct to disclose this, but I think it would be good to then also mention how Veeam protects uploaded data, and how long it is retained, to give proper context.

I did upload a configuration database (from and along with the new test VM) the other day.

[mkaec]

Here is how my experience has progressed. On 8/17 support responded that they were still unable to reproduce, even using the VM I had provided, and asked me to install the latest patch. I installed the patch, reproduced the issue on the test VM and uploaded a new recording of me reproducing the issue. On 8/28, support responded that they were not able to reproduce and asked me to submit more logs after turning on ExtendedUILogging. I refused and asked them to provide a video of my repro steps failing for them. It would be an extraordinary situation for an issue to be reproducible by me in a VM and not reproducible by support in the same VM. On 9/6, support again asked for more logs and I refused and again asked for a video of my repro steps failing. Then on 9/14 support responded that they were actually able to reproduce the issue. I was happy and thought things would be good from here on out. But things would actually continue to go badly.

On 9/18, I was told that a bug had been raised and was asked if I was seeking resolution to the issue. Well, of course I am. Why I did invest all of this time and energy if not to see through to a resolution? I was then told that I should monitor for future patches and open a support case referencing issue 577135 to ask if the issue had been resolved in the patch. That seems a little onerous for the customer, and a waste of support time, to continually ask "did patch X fix my problem?" like a child on a road trip asking "are we there yet?" I requested that support just let me know when the patch is out that resolves the issue. That's the standard I have experienced with other vendors. They put my case on hold, then when development resolves the issue, support gets pinged and they awaken my case with a note professing good news. I requested that this workflow be applied to my case as this is the most customer friendly way to handle issues like this. I was then told that since the issue is easy to avoid (by not leaving the console open) and easy to resolve (by restarting the console), that those are considered "permanent workarounds" and that my case would be closed. Now I wasn't asking for a hotfix, just to be notified whenever the fix does get released.

The next time I post about an issue in the forums and get asked to open a support case, I will politely decline and link to this thread. Yes, I guess that means you may delete my post. But I have been through enough punishment and the lesson has been learned.

[Mildur]

Hi Marc

Regarding the specific bug you mentioned, I have subscribed to it within our internal RnD system. As soon as there is any information regarding a potential release date, I will update this forum topic to keep everyone informed.

Best,
Fabian