These are hard limits and cannot be changed (except for the SQL timeout - and who's sticking around for 5 minutes for a page to load).

We (livePoint) hit the Site URL limit while doing a migration from 03 to 07 - when you upgrade sites, it assumes (correctly) that you do not want to keep the URL numbering system (sometimes referred to as site buckets) implemented by SPS and replaces it (that part of the URL) with the site name.

If you have a deep tree or long site names in an upgrade that results in a URL longer than 255 characters, this will make some functionality crap out (e.g. "Open Document" works, but "Open in Word" does not from the website JavaScript menu).

From Harsh's blog - SharePoint 2007 Maximum Limitations

There are also the following limitations where performance degrades after reaching these numbers (From Technet)...

The following table lists the recommended guidelines for people objects.

The following table lists the recommended guidelines for search objects.

The following table lists the recommended guidelines for logical architecture objects.

The following table lists the recommended guidelines for physical objects.

Here's an article from Kathy Hughes about some of the relevant questions that organisations need to ask their hosting provider if they are looking to host their SharePoint solution with a third party.

General cost / plan structure

Does the host support MOSS platform or do they only support WSS platform?
Does the host offer both standard and enterprise MOSS licensing (enterprise covers things like BDC and Forms Services)?
Is cost based per SSP (Shared Services Provider) and if so then how many Web applications does that include, i.e. are there additional costs (including monthly costs) for each additional Web application?
Is the number of site collections under each Web application unlimited and cost-free?
Lock in period, i.e. 12 months or 24 months?
Initial setup cost?
CAL (client access license) cost/user – monthly cost?
Content storage per plan and bandwidth allowances/limitations?

Administration

What degree of Administrative rights will you have, i.e. access to a Central Administration site, ability to upload custom applications and Web parts, including DLLs and solution files, able to modify the web.config file, standard access for things like SharePoint Designer 2007 customizations, ability for e-mail enabled lists and creation of DL’s within SharePoint sites? If you are limited on accessing things like the 12 Hive (for instance on a non-dedicated server and where you are sharing the server with other customers) does the host have the ability to do that on your behalf, i.e. a technical person and/or team that can help deploy custom solutions?

User management

How does the host handle user accounts and user access, for instance, using a shared AD? Do they allow different authentication providers? Do they have a password reminder Web part/system in place? If you choose to use AD for authentication, what are their AD policies (if any), such as changing passwords every 2-3 months and is there extra cost involved for managing user accounts? Do they offer any ADFS for intranet users, for instance, the client’s existing AD accounts and where the client doesn’t want to have multiple logons and/or user accounts for internal users?

Post-deployment plan upgrades

What are the implications (if any) of you upgrading your plan after the initial deployment, for example, from a MOSS standard license to a MOSS enterprise license? Are there any add-on costs? What if you want an additional SSP, say for geographically dispersed deployments, what will the additional cost be – the same as the first SSP cost?

Backups and restores

What is their backup and restore/redundancy strategy? Are they able to restore individual files and do they have offsite file storage? What are the associated costs for data restoration?

Technical support and expertise

What is the host’s knowledge of both MOSS and WSS like? Do they have a technical team to help deploy any custom solutions (on the proviso they allow custom solutions and don’t allow direct server administrative access, say to a dedicated server)? Do they have a SLA?

Customization

Does the host offer any customization services and if so what are the costs? Does the host offer any additional site templates, such as the Microsoft SharePoint templates? Are there any issues with you editing sites using SharePoint Designer 2007?

As part of implementing a new site for a new client onto a shared environment, there are some things that need to be done to keep the sites completely independent from each other. One of those things is to restrict the people picker to not display users from the other site. For Example:

Fabrikam's users should not be allowed to pick from a group of AD users that includes users from the Litware company. Contoso uses SQL Authentication and should not be allowed to pick from or see any AD users.

So how do you do it? Well, in an environment such as this, your MOSS Service accounts get their own individual Organizational Unit as do the Users for each SharePoint site. This allows you to apply Group policies like (for example) "No user within the Fabrikam OU can log on to any machine", as well as facilitating easier management of User and group objects.

Then you create separate application pools with separate App pool service accounts for each SharePoint site - this way, if the App Pool account gets locked out it only affects one site (This could happen when a service is set up to use the same account as the app pool to run, but the password is then changed on the account and the app pool). Minimize cross-site impact by sandboxing the applications as much as possible.

Then you open up Active Directory Users and computers, Click on the View Menu, then Advanced Features. This allows you to modify the security settings for each object within Active Directory including Org Units.

Create new Security groups called something like sec_MOSS_NoAccessFabrikam and sec_MOSS_NoAccessLitware - add them into the MOSS Service Account OU.

Add the App Pool user for Fabrikam's MOSS Site into the Security Group sec_MOSS_NoAccessLitware.
Add the App Pool user for Litware's MOSS Site into the Security Group sec_MOSS_NoAccessFabrikam.

Right-click on the Org Unit for the Fabrikam site users and go Properties. Under the Security Tab, Click "Add" and add the Security Group sec_MOSS_NoAccessFabrikam.

Assign the group sec_MOSS_NoAccessFabrikam Deny Full Control rights. Apply, OK. Rinse & Repeat for the other sites using AD Authentication.

There are 3 reasons for doing it this way.

# 1 - Deny overrules Allow, just like Rock Beats Scissors. Give that user virtually any access you want on the domain, and the deny rule will prevent enumeration of accounts in that OU (By default, Authenticated users have read on all AD objects)

# 2 - If you were naming your sec groups something like sec_MOSS_AllowAccessFabrikam and applying Deny security to that group on all other OU's, then you can't give users rights to enumerate users in more than one OU (See # 1)

# 3 - Using Allow-type groups to deny access (like in point # 2), You also then need to add All existing groups to each OU every time you create a new OU. With the method above, you are only adding the sec group to the OU once, then managing the users within the groups the same way you normally do.

For MOSS sites using SQL forms based authentication like Contoso's site, you take a different approach - using functionality within STSADM.exe, you can prevent a site from doing AD lookups if the site uses Forms based Authentication.

From the STSADM.exe PeoplePicker Property name usage guide here...

http://technet2.microsoft.com/Office/en-us/library/f3f4f755-d9c8-4dbd-9caa-4faaa732da1d1033.mspx?mfr=true

Do not search Windows Active Directory when the current port is using forms authentication.

To search from a membership provider only, use the following syntax:

stsadm -o setproperty -url http://server -pn "peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode" -pv yes

To search a membership provider and Windows Active Directory, use the following syntax:

stsadm -o setproperty -url http://server -pn "peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode" -pv no

Note:

If the value is set to "Yes," the People Picker will not try to search or resolve a user against Active Directory if the current zone does not use Windows authentication.

If you know of an easier way to do this, please add a comment.

Brad

Just stumbled across this while looking at some information blogged by Serge Lenbet - an interesting White paper on the business benefits of blogs and wikis - http://www.microsoft.com/technet/windowsserver/sharepoint/techref/blogs.mspx (Direct to the document - Blogs and Wikis in Business.doc).

Introduction

Who Should Read This Paper

This paper provides business and technical discussion about the use of wikis and blogs in the business environment. The use of wikis and blogs, or Weblogs, in business is the latest development in the fast-moving content publishing revolution that has been created by the Internet and Web technologies. Like all technological advances, they are already affecting the way we work. Microsoft® Windows® SharePoint® Services 3.0 now offers both wikis and blogs, so business and technical decision-makers can understand what the technologies offer and the technical and business considerations for their adoption. The wide-ranging business and technical impact of wikis and blogs means that the information about uses and management is pertinent to many staff members within a company, because of the enormous variety of business applications of blogs and wikis. The paper includes discussion and examples of uses that are relevant to board, business, and technical managers, such as program management, departmental and organizational collaboration, partner team working, and compliance.

Overview

The terms wiki and blog have become synonymous with the increased freedom of discussion offered by the World Wide Web. Although the Web has always provided a platform for expression, blogs and wikis have removed many of the technical and financial barriers that existed previously. Blogs and wikis enable anyone, both technical experts and casual browsers, to write Web pages and publish them for other Internet users to see.

The reason for this is the limitless opportunities offered by such an easy-to-use yet structured communications medium, not only for personal use but also as a business development tool. In many ways, they are the embodiment of the Web 2.0 concept, because they are representative of the evolution from the technological focus of the Web—Web 1.0—into a business medium, where the technology is a means of delivery. Both blogs and wikis provide the business services, independence, and collective intelligence that business users need, in a lightweight interface that is flexible enough for any business model. They have also engendered community values in Web sites to a far greater degree than was ever previously possible, because they are discursive and collaborative in nature. These features, above all others, have made them into revolutionary forces, comparable to e-mail. The ability to alert users to information changes is an essential development. Increasingly bloggers and wiki users use Really Simple Syndication (RSS) to broadcast change announcements for information held on a site, because the rapidly changing development environment requires a near real-time notification method.

Like e-mail, blogs and wikis are now moving into mainstream business services, and it is important to establish good practice for their planning, deployment, and management, because business tools deliver increased productivity only if you implement them effectively.

Blogs

Blogs are essentially personal journals or commentaries created by individuals, perhaps within teams or organizations, for broad consumption and published on the Internet. Communities on the Web use blogging Web sites to air their opinions or add to an existing body of material on a given subject area. The purpose of blogs may vary from site to site; for example, some bloggers use the medium as a diary, and others provide supporting or antithetical views on a topic. The postings—the term used for publishing of a blog entry—are usually self-moderated. Blogging sites provide a browser-based user interface for writing and publishing posts.

Wikis

A wiki is a Web site that enables users to add new content or amend existing content. As soon as you post on a wiki all users are able to contribute, by adding or amending the original document. They do not have to ask permission, from the author or an administrator, because everyone is empowered to contribute. Windows SharePoint Services 3.0 provides history and version management, so that no original thinking is lost. The wiki community manages change and ensures accuracy and relevance.

This shared-document collaboration element is the main difference between blogs and wikis. The originating author relinquishes ownership of the content on publication. The authors do not need to write HTML, because the content appears in a basic editor interface that enables anyone with basic keyboard skills to add, amend, reorganize, or delete information. More advanced wiki software enables advanced editing, such as support for rich text fonts, graphics, and HTML tags. This means that collaborative development is fast—the term “wiki” comes from the Hawaiian word for “quick.” Initially, researchers and developers used wikis for rapid development of ideas, but this has extended to project managers and others in more traditional business disciplines.

SharePoint as a Collaborative Platform

Windows SharePoint Services and Microsoft Office SharePoint Portal Server have established a place in the portfolio of business software of many companies, from large enterprises to small businesses. The key user features of the Windows SharePoint Services technologies include their support for:

· Collaborative sharing.

· Flexible content types.

· Browser interface.

For infrastructure support staff and developers, Windows SharePoint Services offers:

· Enhanced security with Active Directory® directory service.

· Integration with the Microsoft Office system.

· A rich developer environment through Web Parts and support for .NET development tools.

Microsoft has included support for blogs, wikis, and RSS in Windows SharePoint Services 3.0, to extend the collaborative options for business users, as a direct result of the growing business interest.

Business Applications of Blogs and Wikis

Like e-mail, the business uses for blogs and wikis are manifold. Wherever there is a meeting, an e-mail, a set of collaborative notes, or a discussion, there is potential for a blog or a wiki; that is how pervasive both of these platforms may become. When you assess the possible uses within your own organization, it is important to distinguish between the best uses of the two options, because a wiki is a collaborative site, and a blog publishes an individual’s thoughts rather than a shared document. Blogs encourage collaboration by sharing ideas, but they do not share access to a single document; the dialog in a blog develops chronologically.

Business Blogging

Business blogging demands the same administrative and management rigor as other business practices: security, supportability, and recoverability. Casual users are almost certainly unaware of the existence of these administrative features when they use instances of blogging sites on the Internet. Large blogging sites provide managed hosting solutions, without advertising this provision.

However, the ability to implement and maintain a service is not a good reason for deploying a blog site; these are rationales for product selection. As with all business solutions, the first thing that you need to identify is the business problem. Blogs are communications methods, so first you should look at issues of communication, both internally and with external partners or customers.

Internal Blogs

Blogs offer an immediate, impromptu, and simple means of expressing ideas that a user can publish for others to read. Unlike instant messaging (IM), these ideas have a permanent location, which is accessible by any number of people, all of whom can respond with their own ideas. These postings are not as intrusive as either IM or e-mail messages, because readers can pick the time that best suits them to look at a blog. Blogs also negate the necessity for sending bulk e-mail.

Blog sites usually display content in reverse chronological order, so users can review the thread of a discussion with a greater degree of ease and certainty than is available with e-mail.

You can theme company blogs, similar to a well-organized mailbox. Contributors and readers can select the themes or topics that interest them, and ignore those that they feel are irrelevant. You can create sites at team, departmental, division, or organization level, with the number and variety of blogs limited only by the imagination of those making the sites and postings. These are self-regulating, in the broadest terms. If a site is not interesting or appropriate, fewer people will contribute to it. Even site creators stop contributing when they realize that no one is listening.

External Blogs

External blogs are a particularly useful way to communicate small chunks of information to your customers or partners. On the Web, blogs often provide self-help sites, with tips, tricks, and solutions that are posted in a thread format. This is similar to the traditional online community, but posting is far easier and little administration is necessary.

One of the problems with blogs is that they are self-regulating so a reader cannot always be sure that a posting is correct. For a business, it is essential that any communication delivered to customers is not only technically correct, but that it also adheres to company publishing style guidance and standards. While you may be able to manage contributions from within your company through company policies, you cannot regulate what external contributors may post.

Blogging Scenarios

Blogs are useful for a wide range of communications, but it is often easier to visualize applications of the technology from examples. The following three scenarios are common to a number of businesses.

Field Service and Customer Service Collaboration

Knowledge bases are popular in technical and service organizations, to support field staff and call-center staff. Companies often create knowledge bases from recorded incidents, in which there has been a customer complaint or a component malfunction, and publish these service logs through a browser or other application interface. Although knowledge bases are invaluable, especially if a good indexing engine enables readers to interrogate by using queries, they have a number of limitations:

· Advice is only supplied after a problem has occurred. They are not preemptive but reactive when a situation arises.

· The information does not provide scope for questions. A reader cannot ask for further clarification, because call-logging systems provide information about the calls that are logged, rather than provide a discussion forum.

· Many knowledge base engines lack the flexibility and sophistication to include non-text information, such as diagrams, hyperlinks, and references.

A blogging service provides a much more agile medium than a call-logging system, because a field service or customer service operative can put forward good practices, ideas, or advice from which others can benefit. The ability to post comments or new blogs based on the same theme enables users of the system to provide a greater depth of information, beyond a basic fix. Blogs can also be useful when undertaking research before a problem arises, by providing an opportunity to post questions on topics that have yet to initiate a customer call.

Research

Research demands peer communication in all areas of business. Modern, multinational business may make telephone communication difficult due to time zone differences, but for everyone telephone conversations or conference calls mean that notes must be taken and rewritten, with the potential risk of loss of information or misinterpretation of dialogue. Blogs negate all of these problems because they:

· Enable participants to work at times appropriate to them.

· Provide a written record of all comments and ideas.

· Enable contributors to marshal their thoughts and formulate their ideas before posting them.

Blogs also enable participants to pre-publish ideas in a discursive format, before any official publication. This encourages the rigorous review of ideas, and better-disciplined research practices.

Shift-handover Information

Many work environments, such as hospitals or call centers, demand a thorough handover of information between shifts. Often handovers involve a verbal report or paper-based notes, which may be incomplete or difficult to read. Use of blogs enables shift workers to:

· Provide readable handover information to all other workers, without the necessity of calling the whole team together.

· Maintain a record of handover notes, which enables audit of handover notes. This may be particularly important in industries that have to provide proof of regulatory compliance.

· Query handover information, expediting problem escalation.

For businesses or organizations, the handover notes, which usually exist outside any computerized systems, can now be brought under central control. This can mitigate problems that are caused by ineffective or poor handover practices.

Business Wikis

Businesses and organizations can readily capitalize on the collaborative functionality of wikis, but may view with suspicion the ability to change content without source and version management. The flexibility of a wiki is its greatest strength, because it enables peers to work together to change or update a work without the need to increase e-mail traffic or take up excessive time in meetings and conference calls.

Wikis can also negate the need for all of those meetings and conference calls. The old adage “run it up the flag pole and see who salutes” describes one of the unique wiki benefits. Wikis have even been used to design event and conference agendas ahead of time. The same applies to your business. You do not need to have meetings about what meetings you should have; a wiki enables your business thinkers to define the agenda online. The wiki will reflect what is worth talking about, and what is not.

Using wikis demands trust between group members. It also requires some basic guidelines for wiki behavior, covering such thorny issues as deleting or modifying the contributions of others. While these may differ from one group to another, it is probably the case that amendments should use a strikethrough font or a highlighting standard. This enables users to reinstated “deleted” text after further discussion. Without this you will probably find that every wiki member maintains their own copy of the discussion, which negates the shared document ethos.

Internal Wikis

The use of wikis for internal collaboration is fast gaining credibility among businesses. In line with other rapid development and modeling methodologies, wikis offer a unique environment for synthesis of ideas. The ability to work as a team on a single document, or an element within a document, enables teams to assimilate quickly all team member inputs. This real-time collaborative development enables groups to quickly identify and agree on key points in a project, plan, or strategy. Just as you can with blogs, you can construct wiki sites at any number of levels, for small or large groups, so they can resolve a policy framework or complete a project plan, in a structured or an informal manner.

External Wikis

Many businesses regard wikis as most suitable for in-house development, because it is possible to manage and police a site through company policies and standards. It is important to move beyond this limitation and take a lesson from the success of wikis on the Web. Wikipedia, from Wikimedia Foundation Inc. (www.wikipedia.org), is probably the best known of all wiki sites. Within its categorized structure, Web users can read and modify pages, and add insights into an encyclopedic range of topics. This may seem dangerously open, but it works. For a business or an organization, there must be greater consideration for inaccuracies or intentionally misleading postings, especially from contributors outside the organization.

Because customers and your organization seldom undertake collaborative development in this way—with contributors potentially deleting or amending existing content—it is most likely that partner groups will work together on a wiki. Irrespective of the theme of the wiki site—technical, marketing, or administrative—it is possible to design and develop inter-company strategies and products in a way that would normally be impossible, without the effort and expense of establishing physically disparate groups in the same location.

Wiki Scenarios

Like blogs, there is a danger that wikis can become forums that are dominated by a few people who are keen contributors. For a wiki to work best, the whole team must feel that their input is both important and urgent. As a rapid development tool, your wikis should be time focused with well-defined deliverables. With these goals achieved, the wiki should be “closed” and new sites created, as necessary. The overall aim may require a large wiki with subsections or categories that maintain a record of the project throughout its lifetime. This type of development finds application in any number of business situations, such as brainstorming, working together on an agenda, or event planning. Here are three examples that would apply across all commercial organizations.

Human Resources Structures

Human Resources personnel often want to liaise with staff in other departments within an organization, to establish effective job descriptions or develop a vacancy advertisement. Design discussions such as these often lead to an ongoing round of meetings to get all parties to agree to the final wording. Use of a wiki in these instances facilitates:

· Remote discussion. The final live document contains discursive notes so that the rationale behind the decisions is clear to all.

· Document access for all parties throughout the development process. This minimizes the number of major overhaul reviews and shortens the design life cycle.

· Collaborative contributions from the right people at the right time.

It is important to remember that while a wiki provides an invaluable discussion forum for job descriptions or new employee induction information, it is not a secure delivery mechanism. Published information for something like an induction program must come under a version management framework, and not be open to unrestricted or unapproved changes.

Compliance Standards

Compliance is an important feature of modern business because industry and statutory regulations demand a great depth and breadth of adherence to policy rules. Because these requirements extend across businesses and organizations, it regularly becomes necessary to establish diverse, multidisciplinary teams. Communication and drafting of company policies requires operational, legal, and management input, which can make the development of such policies, and therefore compliance, slow to achieve or incomplete. Use of a wiki provides:

· An auditable process for policy development.

· A cross-departmental collaboration platform.

· An easy-to-use facility for all staff, from the IT literate to IT novices.

As stringent and far-reaching compliance and business standards regulations develop across many industries, it is becoming increasingly important to create inclusive management teams and to provide flexible but auditable discussion forums, like those afforded by wikis in Windows SharePoint Services.

Project Working

All project managers know that the key to success is communication. Often, project communication is independent of other project documentation. The use of wikis, and blogs, can centralize all documentation and provide a structured repository for current discussion and an archive, when project elements finish. Wikis provide:

· A shared space for public project notices and notes, based on a Web browser.

· A discussion forum for project planning.

· An ongoing resource for the life of the project, which captures the decision-making processes throughout the project life cycle.

Used as an ongoing project notice and discussion board, a wiki can provide an invaluable tool for project and program management.

Good Practice Considerations for Blogs and Wikis

The lack of centralized control is one of the major considerations when you assess the place of publishing technologies within a business or any other organization. Providing a platform for individuals to put their personal views on a public forum has a range of potential issues, including legal concerns. Ill-considered or offensive comments, factual inaccuracies, exorbitant claims, or simply poor use of language can reflect poorly on a business, irrespective of whether the postings are for internal or external consumption. Many companies and organizations are reticent about implementing blogs and wikis, because there are concerns about the uses of such sites and the accountability of management for the views expressed therein. The vast majority of contributors use blogs and wikis responsibly, as proven by the huge numbers of successful and informative sites that are available on the Web. However, an ill-judged posting could have far-reaching ramifications.

Blogs and wikis are also proving very popular. The amount of information that individuals want to share seems inexhaustible. While this may be more limited in a business environment, it is still important to consider the e-mail experience; many workers now receive so much unnecessary e-mail that some are finding its usefulness as a communications mechanism greatly reduced. However, blog sites are also finding that spam, and particularly “comment spam,” is becoming an issue.

The popularity has also spawned a fast-growing range of blog and wiki servers. As with all products, there will inevitably be a rationalization of suppliers, but for a business or organization with limited support and development resources, even a small explosion of competing products—especially products that are client-based rather than server-based—may lead to a period where, rather than nurturing collaboration, the sites become a maze of lost ideas.

Technical Business Benefits of Using SharePoint for Blogs and Wikis

Windows SharePoint Services 3.0 provides an exceptional platform for collaborative working, particularly with its fundamental interoperability with personal programs from the 2007 release of Microsoft Office, such as Microsoft Office Word and Microsoft Office Excel®. In addition to enabling document sharing, the blog and wiki facilities now provide more secure, manageable communications and publication features, which resolve many of the concerns voiced by some organizations.

Managing Posts in SharePoint

Blog sites and wikis, together with RSS information updates, give a huge boost to collaborative working. You can quickly set up discussion and development forums for internal staff, external partners, and customers. You can also manage the issues of content veracity and suitability, because Windows SharePoint Services 3.0 provides moderated publishing within its workflow. This offers you control over changes and additions to both blog sites and wikis through a publishing management interface. An administrator can allow restricted rights to some users to publish and edit, based on group or individual access profiles. Contributors can post new blogs or edit wiki pages, but a site administrator must authorize these additions and amendments. This may be unnecessary for all sites, but it can be made mandatory for sites that are open to partners and customers. The flexible security configuration that is available in Windows SharePoint Services gives you this key site management facility.

You can delegate management services within business groups to editorial staff who can administer both technical and linguistic information, which helps to provide a consistent blog or wiki voice and message.

Windows SharePoint Services 3.0 also supports version control in wikis. In addition to configurable group and user access, you can manage and restore versions by using the Check Out and version management features, as shown in Figure 1.

Figure 1. Wiki version management

Infrastructure Integration and Management

Windows SharePoint Services 3.0 offers integration within your existing Windows infrastructure, such as Active Directory, and enhanced security based on the Microsoft Windows Server System™, which enables you to extend your current management and security policies to accommodate new technologies smoothly. This tight integration is essential when you work with open forums, such as blogs and wikis. The proliferation of wiki and blog engines, some of which run from a client rather than a server host, will provoke major security concerns. Spontaneous publication may lead to security breaches, even if users only publish information within an organization. Blogs and wikis have the potential to become a major social engineering threat, but with Windows SharePoint Services 3.0 you can help ensure that they are controlled by your organization’s security policies.

Microsoft Office Integration

Ensuring that users are comfortable within the blog and wiki environment is important because these are publishing tools for non-technical staff. The interface offers a full range of formatting for text and graphics, as well as the essential spelling and grammar checkers. These, together with the templates that are available, reduce support and user training costs, which can significantly lower the total cost of ownership. Users can also use the 2007 Microsoft Office system to provide familiar tools for blog contributors to your Windows SharePoint Services 3.0 or other blog sites.

Conclusions

Wikis and blogs have established themselves on the Web as a particularly effective means of publishing information and collaboration in a wide variety of scenarios. Their ease of use and, when used with Windows SharePoint Services 3.0, adherence to your organization’s security and publication standards make them an ideal vehicle for increasing your ability to offer a collaborative working space. Like all new technologies and working practices, it is best to work on a pilot project first, so that you can decide what works well for your organization. When you have established good practice guidelines, you will probably find that wikis and blogs become as integral a part of your communications infrastructure as e-mail.

This is a piece of functionality that can enhance the "Stickiness" of a SharePoint site, especially in large organizations - yet it hardly ever gets a mention. As a consultant, I'm always looking for ways to wow people during demos, to add value during a deployment and to increase people's dependence on MOSS / WSS (because it generates income). Here are some scenarios where using this has an immediate collaborative benefit:

1. Permanent record for all communication to a distribution list (eg team announcements). New starters can be pointed to the team site and can quickly get up to speed with what the team's been up to.
2. Permanent indexable, searchable record of communiqués from an IT help desk. Build up your issue resolution knowledge bank with no extra effort on the user's part.
3. Legislative requirements requiring you to keep all email communications for 7 years, then dispose of them? Sounds like Email-enabled Document Libraries + Information Management to me :)

The instructions for configuring these settings can be found here: http://technet2.microsoft.com/Office/en-us/library/88317397-e0cb-47c7-9093-7872bc6852131033.mspx?pf=true

Before you configure incoming e-mail settings in Office SharePoint Server 2007, confirm that:

• You have read the topic Plan incoming e-mail (Office SharePoint Server) [http://technet2.microsoft.com/Office/en-us/library/ca092ed2-4aa2-4c2e-b273-661ca6a76e011033.mspx] .
• One or more servers in your server farm are running the Internet Information Services (IIS) Simple Mail Transfer Protocol (SMTP) service, or you know the name of another server that is running the SMTP service. This server must be configured to accept relayed e-mail from the mail server for the domain.
• One or more servers in your server farm are running the Microsoft SharePoint Directory Management Service, or you know the name of another server that is running the SharePoint Directory Management Web Service.
• The application pool account for the SharePoint Central Administration Web site is delegated the Create, delete, and manage user accounts task for the container in the Active Directory directory service.
• The application pool account for Central Administration, the logon account for the Windows SharePoint Services Timer service, and the application pool accounts for your Web applications have the correct permissions to the e-mail drop folder.
• The domain controller running Active Directory has a Mail Exchanger (MX) entry in DNS Manager for the mail server that you plan to use for incoming e-mail.

All of these configuration steps are described in detail in the following sections.

Here is an article that shows how to hook up multiple authentication service providers to a single SharePoint Site Collection using Alternate access mappings.

This is ideal for Extranet scenarios where you want the External users to be registered in a SQL server (and so not clutter up your AD) but you still want to be able to have internal users access it using NTLM Authentication.

Note that anything other than an AD membership provider will result in a degraded user experience (You will only be able to display user information captured in your membership provider, and you will lose some of the "Online Aware" user features)

==================================================

WSS - http://technet2.microsoft.com/windowsserver/WSS/en/library/b6bc8fec-c11c-4ed7-a78d-3ad61c7ef6c01033.mspx?mfr=true

MOSS 2007 - http://technet2.microsoft.com/Office/en-us/library/40117fda-70a0-4e3d-8cd3-0def768da16c1033.mspx?mfr=true

==================================================

Using different authentication methods to access a site

You can configure Web applications in Windows SharePoint Services 3.0 to be accessed by up to five different authentication methods or identity management systems. The following figure illustrates a partner application that is configured to be accessed by users from two different identity management systems. Internal employees are authenticated by using one of the standard Windows authentication methods. Employees of the partner company are authenticated against their own company's identity management system.

To configure a Web application to be accessed by two or more different authentication systems, you must configure additional zones for the Web application. Zones represent different logical paths of gaining access to the same physical application. With a typical partner application, employees of a partner company access the application through the Internet, while internal employees access the application directly through the intranet.

To create a new zone, extend the Web application. On the Extend Web Application to Another IIS Web Site page, in the Load Balanced URL section, specify the URL and zone type. The zone type is simply a category name applied to the zone and does not affect the configuration of the zone.

After extending the Web application, you can configure a separate authentication method for the new zone. The following figure shows the Authentication Providers page for a Web application that is configured by using two different zones. The default zone is the zone used by internal employees. The Internet zone is configured for partner access and uses ASP.NET forms to authenticate partner employees against the partner identity management system.