Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Need Guidance in Building an Intranet

Status
Not open for further replies.

ShawnF

IS-IT--Management
Oct 1, 2001
149
US
Hello,

The company I work for wants to build an intranet-based training program for new employees. The training will include short "how-to" video clips, quizzes, and will keep a running tab on each users's progress.

I'm new to web servers and intranet stuff and need some guidance. I'm not even sure if this is the best forum to post on, but I'll start here for now. For some background info for you, the Intranet web server will not be accessible remotely. It will only be accessed by one or two client PC's at our facility. An outside source will be building the site in terms of designing the pages and layout, and once it's "done" it will be transferred to the server which has not been purchased yet. But it will by my responsibility to order the hardware/software. I could outsource the hardware software portion, but I figure we're better off if I do it myself.

1. What are the preferred methods for the type of hardware needed (SCSI or of EIDE drives, amount of memory, processor(s), storage space, etc...)? I realize I probabliy haven't given enough info to truely determine the hardware requirements, but I can say it won't be a huge intranet. Our company has under 100 employees and only one or two client PC's will even access the training intranet program.

2. Software? Should I do Windows 2000, 2003, Linux (which version?), Unix, Apache, other? I know Windows, but I do not know the others. I want something that is "secure" and stable, I might be able to learn Linux and Apache, but the time factor may not be in my favor.

3. To access the Intranet server, will the user have to type in the internal IP of the server or can I make an internal w ww.someaddress.com? Must this configuration be done on the web server or is it done on a domain controller?

4. I want to be able to control which users and computers can and cannot access the intranet. For the most part I don't want any computers to access this server with exception of one or two WinXP Pro clients. From the client(s), various users will have unique logons. Should/can the unique login's be set up on the Windows Domain level, or can something be setup from within the Intranet server?

5. Any good websites for help on any of these questions?

I don't expect to become a top notch web server admin overnight, but I'd like this project to give me some good starter experience. It'll be an internal server only, so I will have some fudge factor-ability in it.

Thanks!

Shawn
 
I can't really give you specific answers, but maybe a brief description of what's worked for me might help.

A company I work for is also quite small, and the network has a mix of PC & Mac clients. We got a package server deal with MS Small Business Server installed (basically NT4 with a few extras). IIS came as standard, so it was simply a case of building ASP / ASP.NET pages in specific directories. Anyone with a browser on the network was able to access it, regardless of platform. We didn't bother setting up domain names, but it can be done, instead entering IP addresses manually and creating a bookmark. I guess I'm lazy!

For the logins, we used ASP.NETs built-in authentication controls. A simple XML file on the server specifies which directories need to be protected, and a list of users/passwords is defined. They can be stored in a database or in the same configuration file. A generic login page gets called without having to worry about adding extra logic to your pages. Windows also comes with it's own authentication which may suit your needs better, depending on how much the server is going to be doing. It may be a better option, for example, if you are doing more than just serving web pages, but centralising your email services too.

It's been a while, so I can't tell you exactly how everything was set up. I can tell you that the manuals were reasonably clear, but there was still a lot of trial and error. It's one of those things that, once set up, you don't really need to worry about it again for quite some time.

Hope
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top