Ask Slashdot: Uses For a Small Office Server? 260
ragnvaldr writes "I'm the 'IT guy' for an office of about a dozen people. And when I say IT guy, I mean I'm the only one here who can use google well enough to figure out how to make things work. We have a 500GB Mac server with a Drobo with 6TB of storage attached. So far all this server does is back up data, and I want to make it a little more useful. We also have a Filemaker server on it, which I have yet to learn how to use at all, let alone efficiently. Any suggestions to make this machine a little more useful?"
Please Mod This Up (Score:5, Interesting)
It's rare to see such a combination of technical experience, and familiarity with the realities of implementing a solution in a small business environment.
Usually you can only get one or the other from any particular individual. This is solid advice and a good starting point. It should be modded up.
Re:Hire a professional... (Score:4, Interesting)
There's nothing wrong with doing things oneself, if one does them right.
I frequently have to pick my jaw off the floor when I look at what professionals have done. Which, mind you, isn't always the fault of the professionals, but can be because those professionals aren't mind readers and don't now what's so obvious to a company's manager that he never tells them. Or a manager who has to stay within a budget, and orders a half-assed job. Or a manager who can't write contracts and don't have anyone technical enough to verify specs.
Sure, I just as often have seen internal snafus, where someone hacked up something terrible.
That's "just as often", not "more often".
'Cause quite frankly, the "professionals" can be quite incompetent too, and often are. They hire people based on the demand for work they get, and are legally obligated to fulfill a contract and give a customer what he asks for, not what he needs. The professionals are the ones who ask the customer "what browser do you use?" and then proceed to code a project for that browser, and are the assholes responsible for why so many companies are still at IE6. Who uses authentication that works for the test user, but won't work for remote users, or the sysadmin who doesn't use Windows. Who foists upon the customer completely idiotic platform requirements (including both OS versions, JVM versions and network specifics). Who take shortcuts, including hardcoding and incorrect assumptions.
Because robustness was never a consideration; just getting the job done and move on. Hell, if it breaks, it's a good chance they get hired back to fix it!
In short, professionals are dangerous. What you want are experts. And most professionals aren't; they are consultants on a H1B or in-between real jobs, who know just enough to be dangerous, working for profit, not pride.
In this case, I too think the OP should leave well enough alone, but not for your flawed reasons.
If a system is already used for backups, it is one of the most important systems the business has. It should be treated as blessed, and not to be messed with, only replaced when that day comes. It's so critical that it deserves the "legacy" stamp from day one, no matter how modern it is at that point.
Do not look for unused capacity on critical systems. There is a chance that you break them, but also the reverse risk that what you implement itself becomes critical to the business, and that higher demand on the existing system will break your new functionality.
Do you really want to be responsible for restores not working the day lightning strikes, because your app needed a patch that invisibly broke backups? Or do you want your app to become a favourite of managers, and then suddenly become sluggish or not work at all once someone decides to back up the new Hawaii or Europe office during what's business hours for you?
Also, untangling two critical functions running on the same system without business impact can be a daunting task, which is best avoided.
tl;dr: Don't mess with critical systems. This is not the unused capacity you are looking for. Move on.
You're asking the wrong people (Score:4, Interesting)
And I say this as an IT guy myself.
You can put together all the fancy features you like. I don't care what they are, what is important is what the business can benefit from.
So you need to do two things:
1. Don't speak to us. Speak to the people in your company who are driving the business.
2. Stop thinking in terms of "clever things I can do with the server" and start thinking in terms of "things I can do that offer a tangible benefit to the business". 99 times out of 100, those things will fall into one of four categories:
a. Bring money in - either directly or indirectly.
b. Save money.
c. Reduce risk.
d. Make life easier for someone else in the business.
B and C are relatively easy. A is seldom found in IT; D often requires people to change the way they work. Getting people to change the way they work is generally very difficult, so unless the benefit is so absolutely vast that even the most deluded, stuck-in-the-mud person would see huge benefits to it before you've even finished explaining your idea, you may well be wasting your time. If you have an idea that offers only small benefits but requires significant changes to how people work, forget it.