I couldn't agree more, Scott. The reality is, that a large segment of healthcare and insurance still rely on fax type transmissions in their day to day operations. So unfortunately the "fax" is not going away any time soon.

What is happening is a migration to digital/online faxing solutions that offer encrypted transmission, secure retrieval, and secure portals.

In my situation, I can't do a thing about eliminating faxes, but what I can do is require they be done using secure methods. Online digital fax solutions, like eFax, goldfax, etc... can bridge this gap, and let me do away with the physical fax machine. My only problem is making a case for this migration with those that hold the purse strings.

Easy to quantify economically, but much harder to convey the security issues and still ensure day to day operations.

I know, it's an easy answer, but I'm fighting an internal battle with HR and I need to mount a case for why an online fax service is more secure than a physical fax machine.

I have outlined the obvious like plain text printouts, physical access to the machine, saved faxes in the buffer/memory, the insecurity of analog transmissions, etc...

I was hoping that maybe someone had some definitive documentation on the insecure nature of physical faxes, or a comparison of online vs. physical fax security.

@coliver Nice! - I knew I'd hit gold with this crew

Looking at Webex or GotoMeeting/webinar solutions for up to 100 participants. What are your recommendations fellow mangos?

Agreed - I dumped them too about two years ago. We had a consultant that was trying to push us to Azure. They didn't last long. Once they started getting real questions they knew they picked the wrong place.

I don't know how any company can trust them for critical infrastructure with this kind of oversight. And it took them 3 hours to figure it out? Yeah, that's bad.

Yep - I think they're f***ed

Looks like Rackspace just killed their credibility:

https://www.theregister.co.uk/2017/06/29/rackspace_hit_with_global_outage/

OOPS!

@matteo-nunziati Agreed, it should. In reality though, if this had been a production system with critical data, the free version would not have helped, but with the paid version, support may have been able to save their data.

I'd go back to looking at the NICs. In Hyper-V the management console can have one physical NIC, and the VMs another physical NIC. Ensure that VMQ is disabled as @dafyre mentioned, and check the configuration of the VM NIC. You may want to try swapping the NIC assignments and then try your tests again.

If teaming is enabled for the VM NICs, I would check this config, and possibly dissolve the team to test.

@Danp No worries - just asking the question. I wasn't sure if this was in a production setting, and if it was critical data. IMHO - If it's worth backing up, it's worth having a proper solution, and most proper solutions are paid solutions. Don't get me wrong, I like free solutions, especially for testing. Sounds like that was your plan.

Not to be a Negative Nelly, and it sounds like this may not have been important data, but why would one use an unpaid, non-supported, backup solution? To me, while you may be saving a few pennies, the risks far outweigh the savings.

Depends - Generally nothing, but there could be a situation where the primary DHCP is offline, and the client gets a new IP from the rogue DHCP server. If the new DHCP is not configured properly for your network, then clients would lose access to network resources and possibly the internet. This all depends on the config of the rogue DHCP server.

Your TTL on DHCP leases can play a big role in how long this takes to detect. On the other hand, there is DHCP scanning utilities that can identify any DHCP servers on the network.

As a side note; If I caught an end-user doing something like this, they would be relegated to yellow pads and cheap pens.

@scottalanmiller - nope - you have to bring them. It's the rules.

@Minion-Queen You know who @kkreutzer is right? That's my Karen And @scottalanmiller and @Dominica - she better get to see the girls when we come out to Mango!

Oops - just realized you already found a supplier.

Scott, give these guys a call, they should be able to either get what you need or tell you where to find it.

http://www.nventawires.it/

Sede Legale
Via Ferdinando I D'Aragona, 87
Tel: +39 0823 1606 730
Fax: +39 0823 1606 736
Email: [email protected]

@Minion-Queen

It also sounds like he is going to end up owning the city. Jim, I hope you plan on suing them for more than just what they owe. They harmed you and your business, maybe irreparably.

The gall of the city and the sheriffs department are astounding.

@scottalanmiller said in MSP charged with extortion:

@jimk said in MSP charged with extortion:

@scottalanmiller Thank you Scott. I see your forum replying technique has not changed. I always loved the way you break up the answers for multi-part posts.

For easier comprehension and better responses

Obviously, not for the Chamber

The solution to removing them and re-establishing the vSwitch and VM Adapters was to remove the Hyper-V Role and then reinstall the role.
Specifically the following steps:

1. Remove the network connections to the VMs
2. Remove the vSwitch
3. Dissolve the NIC Team
4. Remove the Hyper-V Role
5. Reboot
6. Create new NIC Team
7. Reinstall Hyper-V Role (Create vSwitch during role installation)
8. Reboot
9. Reattach the VMs and assign IPs if necessary

Everything appears to work as normal now. Unsure of what caused the issue, but may have been related to a hard shutdown caused by a power outage and failure of the backup generator.