Linux is, to all intents and purposes, a Unix clone (for a more accurate description I suggest you look elsewhere as it's not relevant to this document) and as such the incorporates the excellent networking abilities of the latter. It is this trait (among others) which has lead to its' increasing deployment in the Internet server market. It could provide a low cost replacement strategy for the problem at hand and yet allow for the expected network growth at little or no extra cost.
That Linux was an effective and cost-effective server solution was not in question but we need to know whether it could provide a specific solution in this case. Could Linux fulfil all the roles provided by the current serverPC, including file-serving, internal mail, network faxing and Internet mail redistribution. Initial enquiries showed that it could and so the question became less of "can Linux do it?" and more "can I make Linux do it?".
Before presenting any argument for deployment to management it seemed prudent to research said argument. This would serve the additional purpose of educating myself in the finer details of Linux Administration. My Linux experience stemmed from a few months use at home and as Linux was not in use within the company I was to all intents and purposes the Linux expert.
I started my research lurking at newsgroups, particularly uk.comp.os.linux (u.c.o.l.).Although lurking can be frowned upon in some circles it is something I recommend in early stages of a project like this. Reading other peoples questions and answers gives valuable insight into your approach to future projects you may encounter. They say it is a fool who does not learn from others mistakes. In addition I had a copy of the book "Learning RedHat Linux" published by O'Reilly (http://www.ora.com). This book was used when installing my home version of Linux and is excellent for this purpose. It also contains a very significant chapter on Samba - a networking application which allows Linux to act as a fileserver for Windows9x PCs. I also made extensive use of the Linux Documentation Project (tLDP - http://www.tldp.org) especially the Linux Users Guide, the System Administrators Guide and the Network Administrators Guide.
I cannot stress enough the importance of the research to the outcome of the overall project. There are many phrases and anecdotes which accurately summarise this, including "forewarned is forearmed" and the five P's (proper preparation prevents poor performance).
Note:- I am aware of the sixth P often prepended to that statement but I chose not to include it.
My initial research revealed the direction I should go and what specific programs I should learn more about. These included:-
Although there were alternatives (postfix and exim for e-mail spring to mind), these appeared to suit my purpose and a quick question to u.c.o.l. confirmed these as good choices. I was aware that network fax serving could be done and that tools were available - articles in Linux Journal helped as did advice from u.c.o.l. users.
This proved to be one of the most anxious tasks of the early stages. It was one thing to bring myself to the realisation that Linux provided the best solution and quite another to consider guiding my boss(es) to the same conclusion.
Although there was virtually no outlay cost involved (always a good stumbling block to remove) there was the matter of time. The project would involve certain amounts of time for me to learn as I went and this in turn would involve a longer overall timescale before the solution was in place.
The temptation was to point out the faults of the existing solution and then present the Linux proposal as an all conquering hero. This was unlikely to work as it could have been interpreted as me pushing a solution simply because I liked the idea. In addition had I presented this argument any delay (or perceived one) in deploying the Linux server would be harder to explain. I had to present my argument as a benefit for the company. To this end I could use the existing problems but I had to be careful to avoid a "Linux for Linux sake" point of view.
As it happened all my concern was for nothing - during a conversation about the existing server the IT manager suggested the very solution I was about to argue for! However he did require some reassurances which were all along the lines I have discussed here. Your situation will of course be different but in any case it must surely be beneficial to present as objective an argument as possible.
I chose to use RedHat 6.0 for this project. This was down to a very simple reason - I already had a copy and could therefore get started quicker. Also I was used to it as I had been using it at home. I can see no real reason why in this case one distribution should be used over another except for personal preference. There are some server editions of several distributions and again use of these is in the realms of personal preference. I have limited experience of various distributions and thus feel inadequately qualified to make a recommendations, my advice would be that you may want to eliminate as many unknowns as possible and thus learning the nuances of a different distribution may cause further hindrances.