Fileservers


Why a fileserver?


Often thought of as the exclusive province of larger firms, almost all businesses can benefit from the installation of a fileserver. The benefits might not be as readily apparent as for some other kinds of IT investment, so let's first of all take a look at the kind of setup found in a typical server-less small office, and see where this goes wrong:

Peer Sharing: Chaos in a handy-sized package.

Microsoft's Windows OS heavily promotes this method of working- that is, the sharing-out of data from your personal "My Documents" folder to other users on the local network. Smaller networks often tend to start-off this way. While this at first sight seems like a very flexible approach -and it has several major drawbacks. The most obvious is the lack of control over who can access what, and where. Security is at best minimal, at worst, nonexistent.

The maintenance costs of a peer-sharing group tend to be high. Consider a group of five peers; if each user wishes to access the "My Documents" folder of his chums, then that particular computer will need to make four 'connections' to the other computers. Five people need to do this, so in total 4x5 or 20 connections need to be established. For ten peers, the maximum that Windows supports, you would need to establish 90 'connections' between computers.  If any of these connections cannot be established, or fails, it may cause considerable nuisance. The high number of posts on the Microsoft helpdesk-forum relating to peer-sharing underlines the fact that maintaining a network of this kind is akin to a plate-spinning exercise. Or, to use a Scottish analogy, a bit like painting the Forth Bridge. IT staff will spend a large part of their working day dealing with reports like "Computer B can see computers A,D and E, but not computer C" and the like.

Poor Security 

On a peer-network, each person wishing to use a computer  must have an account (with logon-name and password) on each and every computer they wish to use.  Thus for ten computers, and ten users wishing to log-on at any computer, there will be one hundred user-accounts to set-up and manage. Clearly this is impractical, and the usual workaround is to dispense with security,  such that users do not need to log-on, but instead just switch-on and go.  Either that, or it is simply accepted that no-one but the regular user can access any particular computer. This obviously creates problems if a user is sick or on vacation.  Thus, peer-networks  will invariably have poor security, with little to prevent unauthorised access to data,  and no way of tracking users' activities, either.

No Backups

More seriously,  with the data stored on personal computers,  the onus to back-up that data falls onto the users of those computers - and the one thing you can be absolutely sure of, the chore of backing-up will soon be forgotten about. When a serious data loss occurs, chances are that no-one will know who was supposed to be backing-up that data, let alone whether any backups were actually done.  In fact, a major data-loss incident is often the trigger for investigating the purchase of a server.

Advantages of a Server:


With data stored in a central location, it is much easier to find the document you're looking for.  Plus, centralised storage gives you the option to categorise documents  according to job, customer or function, instead of by username. Any user can access any document to which they have security rights, without requiring access to another user's computer. 

A server will typically have some means of automated backup. Often this will be a tape drive.  This would normally perform the backups out-of-hours. This avoids slowing the system whilst  work is in progress, and ensures that all documents which have been properly closed at end-of-work are included in the backup.  An important feature of server backup is its rotational nature. That is, there should be several copies of critical data,  the replacement-cycle of  which should allow  for a lost file to be recovered, even if its loss is not immediately noticed.

Users will authenticate to the server instead of logging-on to their own computers.  This makes possible a more selective form of security, where the Administrator has the power to control access to key areas (for example, accounts data) on a user-by-user basis. The fact that users must log-on also allows for greater accountability of their actions - for example should undesirable material be found on a server share, the person who put it there can generally be identified, as can the time at which it was done. 

Maintenance costs for a server-based LAN are generally lower than for peer-groups.  The server itself can often be administered remotely,  saving a great deal of leg-work or driving.  Since each computer needs to make a connection to only one other (the server)  the problems with maintaining numerous computer interconnections -the bane of the peer-group setup- are largely eliminated.


Hardware


A quick scan of the Dell or HP websites will reveal that prebuilt server prices vary enormously, depending not only on model, but on equipment fit.  What I will say here is that for smaller offices,  prebuilt servers almost always offer poor value for money.  While self-build of desktop PCs  is scarcely economic these days, servers are one case where the build-to-order approach has a lot going for it.  The key issue with ready-assembled servers from the likes of Dell is their heavy use of specialist parts, parts which are mostly unobtainable from anywhere other than the manufacturer. In fact there is no justification for this, the specialist parts in these servers offering little or no performance advantage over standard parts available from almost any wholesaler.  The disadvantage, as if I need say more, is that a fault developing in a server containing non-mainstream parts will present major problems of spares supply.  Yet, a site's server is the one computer where lengthy downtime would not be acceptable.  Thus, the spares-availability issue weighs heavily in favour of a build-to-order server, where standard off-the-shelf parts are used. 

Thus, for smaller sites  I would strongly recommend building as opposed to buying prebuilt, where servers are concerned.  A lower price, plus the ability to use off-the-shelf replacement parts are the key advantages.  For sites requiring an Enterprise-class server,  prebuilt may be the only option, but in that case the question of spares and support should be thoroughly researched.

Whatever specification you choose, a substantial  part of the cost will be the backup subsystem.  (and online catalogue server-prices are often deceptively low because they omit this key element from the spec, yet a server is of little use without backup.)  Tape is still the only  acceptable medium for rotational backup, and reliable tape hardware is relatively costly.

Software


The standard Windows Server package, currently Windows Server 2003, will cost about the same as basic hardware.  This is a substantial cost,  and can in fact be avoided by using Linux instead of Windows as the server software.  Whether to take this route depends on precisely what you want the the server to do for you - a Linux server can perform all of the standard functions, however it may not be able to run specialist processes which have been specifically  for Windows servers.

There also exists a "Small Business Server " version of Microsoft's server product-line,  which consists of the core server product, plus a number of other products all encapsulated into one single package.  This costs perhaps 50% more than the core server product alone, but substantially less than its component parts if bought separately.  In some cases this might offer a more cost-effective solution, especially if you plan to use Exchange as your mail platform.  

There are two key points about SBS, though. The first is that despite its name, it consists of an amalgamation of several heavyweight corporate software packages.  A corporate site would normally split these packages across several servers. Running them all on a single server will place huge demands on that server, thus don't expect sparkling performance.  The other issue with SBS, and the critical one from an engineer's point of view, is that thanks to its monolithic nature, a problem with any one service -for example email- is liable to lead the whole network having to be taken offline whilst the problem is investigated -which needless to say will be very expensive in terms of lost working time!  This, I feel, is the Achilles' heel of SBS, and is the main reason I don't recommend it.  There is a saying about putting all of your eggs in one basket...

For a small site with less than ten users, another option exists, in that it is possible to use a desktop OS for the server. This is sometimes the most economic approach.  The disadvantage is that should the firm grow to more than ten users, the server's  software cannot be upgraded, it must be replaced in-toto.  Thus for smaller sites, subject to the ten-user limit,  the use of Windows 2000 or XP Professional  may be quite acceptable.  This obviously represents a substantial cost saving.

Our advice would in most cases would be to go for the standard Windows Server package.

Timescale


The key mistake here is that of rushing.  A server, whether built or bought, needs to be tested thoroughly before its deployment.  This will require at least a week or two of benchtesting time.  Those firms which oblige in rushing servers onto site to beat impossible deadlines may think they are doing the client a favour, but in reality they are not. Almost invariably they will be still sending engineers to site months later, desperately trying to resolve ongoing problems. Problems which by rights should've been spotted and investigated before delivery. Once a server is in daily use, taking it offline is generally not an option.  Thus, any faults which went unnoticed due to a rushed deployment will be very much more difficult to track-down than if they had been dealt-with on the testbench, before delivery.  All in all, a reasonable timescale for deploying a server, from first quote to delivery,  is a month. Yes, it can be done in less, but wisdom of doing so is extremely questionable.