Skip to main content
  • EN

After a long time fighting with it, I just disabled the ping test and things worked pretty good.  It appears when the VM’s boot, unless you are watching the console and click OK to the network discovery, it will fail.  If you do they work fine and stay up.

They are all static IP, auto MAC address from VMware. I do notice SureBackup gives them a new MAC, which could be causing this, but I’m not about to change 100’s of VM’s to static MACs in VMware as it’s not even concurrent if I wanted too.

 

To skip all the time wasted troubleshooting, It appears when the new MAC boots up, it was hitting the private network instead of the domain network firewall. Odd, because it’s still “on the domain” with the DC’s in my Veeam Lab. 

 

a GPO added allowing inbound from the specified networks of my machines to the private network as well as domain network has solved this issue and Ping test is now working, along with RDP and not having to click the Windows notification. 

 

That was a pain, but happy it is fixed. There was next to no info on this specific issue anywhere so it might be environment related, but between the forums, here, google, etc. it was a dead end. I think I may have even mentioned it support but can’t recall.  Either way it wasn’t a “Veeam” issue so they couldn’t have fixed it.

 

 

Hi @Scott, yep have had this one all too often, I always suggest creating an allow firewall rule for all profiles for ICMP to mitigate this. This is because the Microsoft service “Network Location Awareness” is noticing metrics change (new MAC addresses for example), and identifying that this must be a new network.

awesome you shared this info for everyone getting into the same issue.

Always the network, or DNS faiult, isn't it? 😂

Just kidding,

thanks for sharing.

Yeah, great to hear stories like this so others can benefit.  Love networking. 😋

awesome you shared this info for everyone getting into the same issue.

Always the network, or DNS faiult, isn't it? 😂

Just kidding,

thanks for sharing.

ALWAYS DNS…….. it’s funny how many times I have said that and the issue ended up being DNS 🤣

Yeah, great to hear stories like this so others can benefit.  Love networking. 😋

I search forums often to solve my own issues before calling support. :)

I’ve solved vehicle issues on Honda/Toyota forms. Computer issues, storage, Veeam you name it.

 

Being a Veeam / Storage nerd it’s nice to talk to like minded folk and see all the posts here.

 

I look at R and D, I often go back and post the resolution to my questions.  I even used one as a reference once when I had the issue and was able to use my comment to fix it. haha. 

 

@Scott  I do like you but from experience opening a support ticket at the same time can save some time on a blocking situation. If I haven't solved it within two hours, I open a ticket a ticket now. I agree it's much more satisfying to solve it yourself but sometimes when it ends up by a private fix 😵

@Scott  I do like you but from experience opening a support ticket at the same time can save some time on a blocking situation. If I haven't solved it within two hours, I open a ticket a ticket now. I agree it's much more satisfying to solve it yourself but sometimes when it ends up by a private fix 😵

Nothing wrong with calling support. I agree, there is a point in time where calling makes much more sense than wasting a day on something that can take them 5 minutes to fix. Sometimes the tickets I DO create, I fix while waiting for a call back. 

 

I learn better by “doing” and poking around in logs, applications, menus, reading documentation, etc. For myself even if I don’t fix the issue right away it’s never time wasted. That being said, I have a job to do, and people are also being paid to help me when I create tickets so there is a fine line of when to know your limitations.

 

There are also times where I won’t even try to fix something before submitting a log bundle and phoning in. I know my skillset and where it ends. 

 

 

Comment


Terms & Conditions