www.johntimney.com

MOSS audit logs if enabled and left to go wild can grow very fast indeed.  Every 150,000,000 entries will consume about 40gig of database space.  So about 300 bytes per audit record give or take a few bytes.

if you enable item level auditing then this will grown at a rather rapid rate and few architects actually consider this additional space requirement when they plan their corpus storage.  

http://msdn.microsoft.com/en-us/library/bb397403.aspx

Working this out is based on the number of transaction per day that will be audited, so you need to know which sites will have auditing enabled.  

In a site trying to achieve compliance, or prove an audit trail as legally admissable the audit storage requirements can be taking up space that the MOSS admin has not factored in, and can't find.  If you have vanishing space - look here first!

The lesson here is don't enable auditing without thinking carefully about the impact of it from a performance perspective (item level auditing is a performance killer) and from an audit management perspective.  Fortunately, Microsoft recently released the
the infrastructure update for MOSS which contaisn the new Trimauditlog Stsadm command.  It basically allows you to manage the audit table and remove old entries (hooray!) without hacking the DB audit table which is of course unsupported.

http://technet.microsoft.com/en-us/library/cc706879.aspx

One tip worth remembering.  if you are clearing out the dbo.AuditData table you might want to back it up.  This is explianed in the Item Level auditing paper

By default SharePoint 2007 has Diagnostic logging turned in Central Administration logging and reporting, and typically stores 48 hours worth of log data. The default setting can be as much of a killer as the Audit logs to the unwary.

As well as Audit Logs, Diagnostic Logging can also consume a considerable amount of disk space in the “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS” folder.

On a heavy site, each log file can be about 150-200 meg. With new log files being created every 30 minutes this can quickly eat up 15 to 20Gb of space over a 2 day period. So be careful that your root partitions on your WFE servers are large enough to cater for poor diagnostics logging planning.

One of the good things about MOSS is that it can roll content up to higher tiers using content rollup, search and RSS webparts.  Combined with MOSS publishing templates you can create a very intuitive intranet or website.

The first few levels of a good intranet (and in fact most good websites) are usually given over as a "communications" layer where almost everyone in the organisation has read access.   It's ideal for the MOSS publishing templates as information is typically read only, easily structured and not subject to huge upheavals and constant change.   Surfacing niche information from different team sites usually works well for a broad consumer audience and allows the projects to concentrate on project related information and COMMS to fish for quality content.

Content rollup is a strategy!  The right strategy with an understanding of rollup approaches allows you to package your intranet and allow it to grow from the inside – without many of the usual issues connected to information being hard to find for end users, and poor or cumbersome navigation making structure changes very difficult.  Your intranet therefore becomes quite a tight entity where it counts, at the consumer face.

Content rollup in a nutshell means that as internal projects start to come on board and take advantage of the collaborative features they need to operate their project, whoever is responsible for managing the public face of the site can easily access and expose relevant information using content rollup through rollup, search and RSS webparts.  Of course this does assume they have the correct read security model in place for content they wish to expose.  So, team sites also need some form of structure thinking applied to them to make sure this is achievable, as do references to external sites and how that information might be surfaced on your own site using RSS perhaps, or custom search results.

A rich choice of pre-defined templates from FAQs and press releases to documents makes deployment easy at the public face, whilst helping to preserve flexibility and design freedom for more advanced users.  Rolled up content rollup can be scheduled with start and expiry dates with optional email alerts to notify on expiry. You can allow any type of files you deem are appropriate, but its normally a good idea to restrict the use of video to designate areas –  as video can show a speaker's personality it can be used to strengthen the corporate culture through messages from the CEO and other executives, or expose technical expertise though mysite blogs containing video.  Again, easily surfaced on the intranet home page, but located elsewhere in the site structure.    Of course video has a huge impact on bandwidth so has to be carefully planned in. The worst intranets are those bloated so much they underperform, or are so hard to navigate you can’t find anything.
So think carefully about how your Public area can surface information and links into you publishing site with a rollup strategy and you’ll have a very fluid intranet or internet service with little actual work.

Pointers:

This is an excellent article on how to do cross site collection rollup of content using a Search webpart.
http://www.devcow.com/blogs/jdattis/archive/2007/04/17/SharePoint-2007-How-to-Rollup-Content-from-multiple-Site-Collections.aspx

A great article on dynamically filtering the Content Query Webpart results
http://www.andrewconnell.com/blog/archive/2008/02/18/Subclassing-the-Content-Query-Web-Part-Adding-Dynamic-Filtering.aspx

How to rollup content from more than one content type
http://www.sharepointblogs.com/mykiep/archive/2007/06/30/overriding-the-content-query-web-part.aspx

Using a Dataview and Sharepoint Designer to enhance rollup
http://blogs.msdn.com/sharepointdesigner/archive/2007/04/24/spdatasource-and-rollups-with-the-data-view.aspx

A deep dive into the Content Query webpart
http://sharepointkb.wordpress.com/2008/07/25/sharepoint-content-query-webpart-customizable-powerful-and-invaluable-to-anyone-who-uses-sharepoint/

A multiple RSS feed consolidation webpart
http://codeplex.com/FeedReader

A good write up on MOSS RSS Webpart
http://www.datasprings.com/Resources/ArticlesInformation/SharePointMOSS2007RSSFeeds/tabid/831/Default.aspx

Someone asked me the question "how secure is sharepoint?"

I actually think thats very hard to answer within the context of which the question is being asked.

“how secure is sharepoint?”  We'll - how secure is any online system?

Kerberos, AD, Federated AD (policy based), SSL encryption, Forms Authentication, Token based security, is all supported.  Permissions enforce security to the granular level and strengthen it based on zones of access (ie different access for internet audience than intranet audience).

Its worth looking at Joel Olesons blog entry on this which covers a lot of the enhancements in security for MOSS 2007

http://blogs.msdn.com/joelo/archive/2007/04/06/security-improvements-in-sharepoint-server-2007.aspx

Most public instance of MOSS use ISA Server and https encryption with forms authentication.  So it’s really as secure (probably more so) as using an online banking system in terms of data transmission and storage.  You only have proxied access to the internal system over HTTPS from an internet access point, you are never really on the servers even – which makes hacking it very difficult.  When you add forefront into the mix its hardened even further.

From an architectural view, this kind of security approach means it can be security hardened to the nth degree as a product.  Architecture of the underlying application for hardened security is quite an art form and you can go overboard easily.

For reading:  I would start here with the roadmap and downloadable book on the requirements for hardening a  MOSS instance.

http://technet.microsoft.com/en-us/library/cc263518(TechNet.10).aspx

Most people tend to run Central Admin on a single server, as its usually a bit of a pain to run it load balanced.  Now that is not normally an issue - that is of course until you lose the server its running on.

Try as hard as you might, you wont be able to just enable it on another server as the farm thinks its already provisioned.  That means you will have to reprovision it on a different server, get Central Admin up and running on an alternative box and then take the old Central Admin application out of the farm.

There is a tool to help you with this and its good old psconfig.exe.

The trick in enabling a replacement Central Admin server is to ensure you provision with a new port, because if you don't the timer job that activates the newly provisoned server will not run, and the old Central Admin allocation will remain active leaving you with two innaccesible Central Admin applications.

So, on the new server as a precaution run:

psconfig.exe -cmd adminvs -unprovision

and then run it again to provision a new Central Admin service, ensuring you specify the replacement port number.

psconfig.exe -cmd adminvs -provision -port 8080 -windowsauthprovider onlyusentlm

You should now be able to access Central Admin on the new port, allowing you to go into Operations and delete the application for the old service.  When you get the old server re-instated make sure the old application isn't still lurking. 

Replication is rarely the solution to poor wan links in MOSS - and MOSS deployment support over WAN is not good.  Bear in mind that as soon as you replicate content DB's or sites and have them attached to another site collection in a remote farm you have a possible synchronisation issue unless your audience is read only.

A decision to replicate has to be based on planning with a consideration for WAN link data consumption when adding a MOSS farm.  What's the impact - you need to know the volume a link has to carry before you deploy a farm, as that should form part of your planning exercise to see if new working practice when using MOSS will swamp your network, and it will if you do not plan it up front.  Simple rules like how many read and write operations per day of a typical document size are going to travese our network should be at the front of your mind.  Can the doc converter service help me, can I use publishing to offset traffic - what can be anonymous to offset load etc etc.

Also, if you do chose to replicate - how much data needs to go from one site to another or vice versa and before you decide that have you looked at the options like ISA server caching requests etc. and of course the possibility of harnessing WSS instances at remote sites for collaborative working and consolidating search or shared services centrally.

One other thing to consider is to have two farms in this type of low bandwidth scenario and use content publishing to replicate fixed data (like rarely changing HR policy) between sites, but there are many factors to consider (cost and techncial complexity of course can make this prohibitive).  If this isn't an option and you must replicate then take a look at DocAve from Avepoint as it can do two way replication with synching.
http://www.avepoint.com/products/sharepoint-administration/sharepoint-replication

I've not tested it (yet) but I hear its a fine fish in a river full of slippery eels!

As usual Joel Olsen has a word to say with respect to replication, more for redundancy than in a low bandwidth sceneario, but also as usual the words do carry a lot of value.

Read more here:

http://blogs.msdn.com/joelo/archive/2007/04/02/replication-and-high-availability.aspx

and here:

http://blogs.msdn.com/joelo/archive/2008/01/17/global-sharepoint-deployment-partner-solutions.aspx

I've been asked this question a few times, and I can honestly say I don't have a defacto answer for it.  Can MOSS really do Fileplans?  Myself and a good friend Brian English (who know more than me about information flow in MOSS) had a chat about this.

MOSS doesn’t provide great tools for defining a Fileplan and then enforcing it from that. However many organisations, inc Government, document their File plan in MS Excel or even Word so this isn’t necessarily a huge shortcoming. If the implementation and Design of the FilePlan is in the same tool and that tool doesn’t separate the two activities you run the risk of quality audit non-compliance. If one tool does everything, how do you know that it is doing what it is meant to do, and not what someone has mistakenly set it up to do. This is a common check for ISO9001 Quality Auditors in all sorts of areas which can result in the Fileplan design therefore having to be documented off-the system that enforces it anyway.

So, File-plans are normally defined outside of MOSS, depending on how you want to organise your information storage and the policies around it.  This is then mapped into MOSS using a combination of document workspaces, libraries, lists, image libraries etc. either at a root site level (department) or at a team site level (team) or an individual level (mysite – typically no policy other than manual process enforcement). 

This would include definition of Metadata which could be applied to each document and list item and views hrough which to improve exploitation.

You would build site templates to represent how the taxonomy of these storage areas (for want of a better description) would sit, and the structure for new sites based on the breakdown of the fileplan and new sites would be created to represent this taxonomy and the fileplan breakdown as it was expected to be applied. These can be reused to provide a consistent site structure, they may include standard data, e.g. document templates or links to help or template references (other sites) that you want to deliver to each site. You need to be careful which approach is used as embedding data in site templates can cause problems over time if the data changes significantly and there are a lot of sites that then need updating.

All areas of information storage in MOSS can be team centric (but they don’t have to be) as they can be divisional centric – but those team centric views on information can have policies applied to feed the records centre from anywhere to ensure the fileplan requirement is met.  So the structure of any “drop zone” in the records centre so to speak can have information policies applied that ensure the requirements of the fileplan are met. Ie. If it’s this type of document (email) move to folder X in the record centre and retain for two years then delete. The concept of content types supports the fileplan definition stage, so fileplan elements should be mapped into content types and the content types mapped to MOSS Information Management policy whihc can for all sense and purpose drive your fileplan enforcement.

There is a specific site called the document centre which is designed to offer a more robust document centric view on an organisation than a document library in a team site, where a less formal more hierarchical top level file structure can be created that represents how a logical view of the information might be managed – but it’s a bit of a forced taxonomy.  This though can be applied at any level, as can a folder hierarchy that represents taxonomy based on lists and libraries.  So it all depends on “what” you trying to do with your fileplan and whether it can be done in MOSS.

There are no fileplan modelling tools in MOSS.  You are expected to do this outside of MOSS and enforce the policy of fileplan object types based on specific content types.   MOSS also has no support in its record centre for hierarchical fileplans - you need third party tools like Wisdom, which is MOREQ2 compliant and conforms to the UK National Archive standards.

At this stage, I would probably start repeating an excellent article writtien by MVP  Zlatan Dzinic which goes into more details than I intend to do, and so I'm going to divert you over to that.

http://dotnet.org.za/zlatan/archive/2007/09.aspx

Hopefully I've wet your appetite and Zlatan can serve you the main course!

I came across a very interesting article t'uther day while fishing about for something totally unrelated.  However, its a doozy and if your into MOSS development you'll want to read it.

It's by MVP Ted Pattison (and others) who specialise in WSS development type stuff and the code is available on codeplex.

In a nutshell, its an explanation and a bunch of code to get you developing much faster on WSS based projects.  Go read it, and grab the code - it'll save you a load of time.

http://msdn2.microsoft.com/en-us/magazine/cc337895.aspx

An interesting article has appeared on Technet around planning for a global MOSS deployment.  Its interesting as most customers I am dealing with currently have this very issues to content with and have no clue where to start really.

The article at technet asks questions that usually only the hardened MOSS archietct would consider like how to start planning for Enterprise Search and calculating expected global bandwidth requirements, hence it merits a place as one of the important hyperlinks that you should pay a quick visit.

Microsoft currently supports three different deployment configurations to accommodate geographically dispersed sites with Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0.  You can read about them here.

http://technet2.microsoft.com/Office/en-us/library/30587057-b4df-4708-a4a7-905f37878eae1033.mspx?mfr=true