Pick up a good book on sharepoint services. Well worth the money. But to
answer your questions and get you going:
1) I would not just dump files into a document library. Usually by looking
at the files, and adding metadata, you will get a better "feel" for the
subsites you want. You can actually create a better organized system if you
take it file by file. And with sharepoint and its more granular user
control, you can delegate that task, so now *you* won't have to be
responsible for moving all of those files. You can enlist help.
2) Site collections are *usually* (but not always) for larger organizations
which truly need separate application and memory pools in IIS. For simple
permissions, a simple subsite will suffice.
3) Separate server. SxS is very tricky to pull off, and when something does
go wrong, it impacts too many non-WSS things (WSUS, reporting, etc.)
4) Very company-dependent. I don't know at all enough about your
organization to make that guess. My advice? Start with the internal
database, and if you actually follow #1 above and start loading data
*slowly* and you pay attention to your performance monitors, you'll know if
you need to migrate to SQL Server. And that migration is fairly
straightfoward and documented on technet.
"Jack" <dontaskwhoiam2001@newsgroup> wrote in message
> The client is pushing me on WSS but I am not really familiar with it.
> That's why I am here with some basic questions.
> The server is SBS 2003 R2 Std. It has a few company wide shared
> folders which are about 80GB for each.
> 1. Should I move those folders into Doc Library? Or, is there a reason
> that I shouldn't?
> 2. There are some shared folders that are only accessible to managers.
> Should I create a separate Site Collection for this?
> 3. Should I install WSS 3.0 on a separate member server or do a side
> by side install?
> 4. If I install WSS 3.0 on a separate server, do you think the
> "Windows Internal Database" can do most of jobs or I'd better go for
> standard SQL?
> Thanks in advance