B&R Console takes forever to come up on the actual B&R server, but not on workstations ...
I hope someone can help me. I manage my B&R server by installing the console on my Win 10 workstation. That’s all fine, it takes the B&R Console some seconds to come up, but it does.
But on the desktop of the actual B&R server itself, if I try and bring the console app up, it will take forever - at the moment, I’ve been waiting 20 minutes. The console application came up on my workstation in a few seconds, but still hasn’t come up on the desktop of the server.
And I’m not sure why. It can’t be a firewall issue, it will eventually come up (or used to - it’s been a long time since I actually tried to use the console app directly on the server). I see no error messages, just the warning that it’s taking longer than expected to happen.
The server itself is running fine - all jobs are executing as expected. It’s just the console app not coming up on the desktop of the server. I have no problems using the console my my workstation, I can create jobs, run jobs, do backups, do restores, etc. All is as it should be. It’s just the console app not coming up on the server itself.
This is VBR 12.1.1.56, running on Windows 2016.
Page 1 / 1
I know this has been a long standing issue with the console but has improved greatly over the versions. Are you able to upgrade to 12.2 and see how it performs? I cannot give you a good answer but if a real problem which yours seems to be waiting that long I would contact Support to see what might be in the database or other causing the slow launch.
Haven’t really heard of this issue before @MikeLeone . It takes a minute or so to open regardless, but certainly not 20m. Aside from a server reboot, or even a Console install repair, I concur with Chris to contact Support to see if they have any answers for you.
Well, it’s not really a problem, since I would not be using the console app on the actual server, I would be (and am) doing all my work from the console app in my management VM. And that does come up - slowly, as Shane said, but within a minute. It’s on the server that’s an issue. And we try really hard to not do any work directly on the server. In the same way that MS does not recommend installing the SQL Studio Management app directly on the SQL server (although I believe that’s more of a security reason).
I haven’t always had the most productive responses from Support, but perhaps I will open a ticket.
Thanks
Understood. Keep us posted Mke.
Yeah if it is not a problem then I would not worry but if you are using the Console more on the VBR server then a ticket will be good. Keep us posted.
When you launch the console are you connecting to the server via localhost, dns lookup, or IP address?
Try all thee and see which is quicker. Could be an interesting experiment.
When you launch the console are you connecting to the server via localhost, dns lookup, or IP address?
Try all thee and see which is quicker. Could be an interesting experiment.
That actually would be a great test. Maybe it is DNS.
Its *ALWAYS* DNS!
When you launch the console are you connecting to the server via localhost, dns lookup, or IP address?
Try all thee and see which is quicker. Could be an interesting experiment.
That actually would be a great test. Maybe it is DNS.
It’s localhost …
When you launch the console are you connecting to the server via localhost, dns lookup, or IP address?
Try all thee and see which is quicker. Could be an interesting experiment.
That actually would be a great test. Maybe it is DNS.
It’s localhost …
So to me that would be fast to launch versus using IP/DNS FQDN. I guess at this point check with support and see what they say or don’t use the console on the server. Better security doing it that way anyway.
Same delay whether I use localhost, DNS or IP. No, I don’t want to use the console app directly on the server desktop. I want my operators to use the console app only from their privileged VMs (the VM where they do their privileged operations, such as backup, AD-related operations, etc - anything that requires specific privileges). If the console app won’t come up directly on the server, so much the better, in my opinion. LOL Especially seeing that it doesn’t seem to interfere with the operation of the server in any way.
To me, operators shouldn’t be logging onto the desktop of the server at all. And even admins should only log on to do things like upgrade Veeam, or other sorts of updates that must be applied directly to the server - not do daily operations directly on the server.
Same delay whether I use localhost, DNS or IP. No, I don’t want to use the console app directly on the server desktop. I want my operators to use the console app only from their privileged VMs (the VM where they do their privileged operations, such as backup, AD-related operations, etc - anything that requires specific privileges). If the console app won’t come up directly on the server, so much the better, in my opinion. LOL Especially seeing that it doesn’t seem to interfere with the operation of the server in any way.
To me, operators shouldn’t be logging onto the desktop of the server at all. And even admins should only log on to do things like upgrade Veeam, or other sorts of updates that must be applied directly to the server - not do daily operations directly on the server.
Agreed 100%. That is the model we are/have moved to with our new domain for Veeam where all operators run the console from either local laptops or from jump boxes in the DC but not from the VBR itself. Only privileged users have RDP access (enforced with DUO Security).
There was someone within the past yr who actually wanted to know if there was a way to not install the Console with VBR. There isn’t, but would be a great ask/add imo.
One other thing to try.
I see you are using Windows Session Authentication.
Is your B&R Server a stand alone device on a separate network or domain? (another one of those best practice things)
If so, it may be taking a while to authenticate while your domain joined workstations don’t have that issue being on the domain and all that.
BTW Shane, that was my suggestion to make the console installation an option while installing the server. Still like that idea.
Doug
Maybe the PMs will add that ability “soon” ♂️
No, all my Veeam servers are all members of our single domain, and on the same subnet.
No, all my Veeam servers are all members of our single domain, and on the same subnet.
So then it would not be related to Domain vs Workgroup. Hopefully support helps out on this one as I am curious to the answer or if there are tweaks.
What do your system resources look like on the server? I’ve seen it take a while for the console to respond and usually it’s low on resources, I think typically RAM when this has happened to me. Although I’m usually already into the console when I experience the slowness.
My server has 128G RAM, and memory utilization is usually running around 74%, from what I see according to Task Mgr.
UPDATE: I logged back into the server this morning. The console still wasn’t up. LOL … then a couple minutes later, it did come up. I wasn’t watching, but when I clicked back onto the VM, I saw it up.
So eventually it does come up. But 24 hours seems a tad long … LOL
My server has 128G RAM, and memory utilization is usually running around 74%, from what I see according to Task Mgr.
UPDATE: I logged back into the server this morning. The console still wasn’t up. LOL … then a couple minutes later, it did come up. I wasn’t watching, but when I clicked back onto the VM, I saw it up.
So eventually it does come up. But 24 hours seems a tad long … LOL
Umm yeah that is a wee bit long. LOL
Hopefully you get an answer from Support on this one as I am interested to see what they say. Someone told me just all more vCPU and RAM if a VM.
I haven’t had time to open a ticket yet. But hopefully today. It won’t be a high priority, so I doubt they will get back to me today. But you never know.
Yeah...curious to hear what they find the cause is…
Still like that idea.
♂️