1. FIREFOX PROFILES FOR CUSTOMER MANAGEMENT

Someone's boss at an MSP created more than 80 profiles in Firefox, each with a different set of bookmarks and plugins for the various customers they managed. While it's not the most elegant solution, it actually worked – until someone accidentally deleted one of the profiles and they lost all customer data in the profile.

When reviewing this case, IT pros noted that a Firefox Multi-Account Container plugin could make this a somewhat effective (if completely unscalable) fix. Our take. Don't do it!

2. CUSTOMER PASSWORDS IN A SHARED XLS FILE

This one is a big no-no, but apparently, it happens more often than you'd think. In fact, several IT Pros we consulted confirmed they did this very thing when they worked for MSPs. The passwords were hopefully hashed, but they were still stored in an Excel spreadsheet on a shared drive. And while the IT Pros we asked didn't go into the details of what kind of hashing algorithm they used, we can only assume it wasn't anything too serious.
The crazy part? It's still a more secure solution than everyone having a sticky note on their monitor. Still, don't do it. Settle for nothing less than a robust and secure password solution, always.

3. PLAINTEXT PASSWORDS IN A BATCH FILE

But wait, that won't be the only password incident on our list. Another IT Pro told us how a company he worked with was authenticating NetLogon with a batch file that used the actual password in plaintext. That means no one even needed passwords. Everything would just "work" as intended, regardless of who logged in. This is the epitome of the "well, it hasn't caused a problem yet" kind of IT management. How do these things even happen? Have you checked your NetLogon setup lately?

4. MISALIGNED MONITORS

Okay, this one is inexcusable, but it's not the MSP's fault. A tech went to fix a monitor issue for a client and noticed they had them set up so that you had to scroll off the left side of the left monitor to get to the right one. After realigning them, the customer complained until they reset it because they were "used to it." If you've ever worked in an MSP, you probably have a story or two like this, where a simple fix is possible but turned down because change is hard. Work on educating your customers and having them on board with your IT strategy, so issues like these don't happen.

5. SNEAKERNET

Ever heard of the sneakernet? That's when instead of properly setting up a network for file sharing, you just… well, you just copy the files to a USB drive and physically walk them to where they need to go.

This happens more than you think in poorly managed companies, but this one takes the cake. An MSP booked a client with three separate networks for three different business applications. Each one had its own AD server, a pfsense box, and an application server. Instead of being interconnected, end users would just be attached to the one they used the most and then sent communications out through the internet to reach the other two. Nothing made sense here, but it had "grown organically," so no one saw it as a problem. That is actually how most of these issues happen. It starts with several minor problems and temporary fixes that slowly grow into a monster. It may still work, but it isn't the right way.

6. PERCUSSIVE MAINTENANCE

Sounds fancy, doesn't it? Want to know who is an expert in the percussive maintenance field? Fonzie from Happy Days. Yep, this is the practice of physically knocking or hitting a device to make it work. The worst part is that sometimes it does work, and then some techs or end users think it was actually because of them banging on the hardware. No, threatening a stack with a screwdriver will not make it function correctly, no matter how many times you say it has in the past!

7. VIRTUAL BACKUPS

Okay, follow me here. A virtual machine (VM) was backed up to a drive on the same Hyper-V host. That host was the domain controller (DC), and the second DC was a VM on that original host. Yes, that means what you think it means. The entire ship sinks if that single machine goes down. It hadn't yet, so it "worked," right? Insert the "he can't keep getting away with it" gif here. Don't do it, kids!

8. NET START FWSRV

Okay, this one is kind of brilliant in its laziness. An IT Pro that has been in the industry for a while related a story about a Microsoft ISA firewall issue. It would often crash if there was an issue with storage latency, but instead of fixing the actual problem, his boss just set a repeating batch script with "net start fwsrv" to run every second. This is the kind of fix that gets you out of there in time for happy hour at the bar, but not exactly the one you want to be paying for if you're a client.

9. EXECUTIVE EXEMPTION

Ever been asked to set up a comprehensive security protocol - but then leave the executives exempt? It's widespread and almost always seems to be the reason for a high-profile data leak. It's the "Do as I say, not as I do" of the IT world, and it almost always comes back to bite the company in the end. But in the meantime, those executives enjoy exemption from what is otherwise a sound security policy. To them - it works great! To the customers who have their data leaked - not so much. The moral of the story: Never allow for executive security exceptions.

10. JUST TURN IT UPSIDE DOWN

It would be easy to dismiss this one as fake if only it didn't feel so familiar. A tech goes out to a company owned by a parent organization with its own MSP. When he boots up the machine in question, the display is upside down. When they ask why an employee walks over and just flips the monitor around and lies it on the tower. The other tech didn't know how to fix it or didn't want to and had left them with this "fix." You can't make this stuff up.