SharePoint world of ECM and Information Management

SharePoint Tip #28. Do you know “that Limited Access permission used to traverse access to items”?

SharePoint provides different levels of permissions, from the “Full Access” to “Limited Access”. Last one is not documented clearly and designed to cover some side-effects of item’s hierarchy.

Cite from “Permission levels and permissions” article:

“The Limited Access permission level is designed to be combined with fine-grained permissions to give users access to a specific list, document library, item, or document, without giving them access to the entire site. However, to access a list or library, for example, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted”

"Limited Access" allows no direct access to site content at all, but is intended to allow users to traverse the site in order to access the items within it that they have explicit permissions to see.

For example, the user might have access only to one page of a site, but still need access to style sheets and other supporting site infrastructure in order to view it. In that case the user would need "Limited Access" permissions on the site and "Restricted Access" to the page.

Current "SharePoint Tips and Tricks" series has been moved to its own "SharePoint SandBox" site, to leave the place for others SharePoint posts on this blog

STSADM MergeContentDB possible database corruption

MS Support posted an warning regarding STSADM mergeContent DB.

Symptoms
=============================
Under certain circumstances, the mergecontentdb Stsadm operation may fail. These circumstances include combinations of significant site collection size, user traffic, and SQL Server load. When the command fails, both the source and destination databases can be corrupted.
If you use mergecontentdb, make sure that you:
• Always back up both the source and target databases before using this operation.
• Set the site collection to be read-only before using mergecontentdb  to move it.
• Refrain from cancelling the operation (either on the front-end Web server or the server running SQL Server).
• Run the command during off-peak hours, because mergecontentdb places significant additional load on the server running SQL Server.

Alternatively, consider using Batch Site Manager and the method described here. Because the Batch Site Manager works with site collections by using the Stsadm backup and restore operations with the –url parameter, we recommend that you not use Batch Site Manager for site collections larger than 15 GB.
The Batch Site Manager is included in the SharePoint Administration Toolkit:
• Microsoft SharePoint Administration Toolkit v3.0 x86
• Microsoft SharePoint Administration Toolkit v3.0 x64
Microsoft will release an official KB article for this issue, will keep you posted if the KB is released. Thanks all.

URL http://social.msdn.microsoft.com/Forums/en-US/sharepointgeneral/thread/e9cd9836-5a50-42b3-bf2f-02338a3168f3

SharePoint CMS joke

Today I’ve seen a joke in twitter regarding SharePoint CMS, which made my day. Can’t stand not to share

“Working with the SharePoint CMS is like eating sushi with oars instead of chopsticks.”

Thanks http://twitter.com/jurgenappelo

SharePoint Tip #27. Do you know “How to make Web Part zone WCAG compliant”?

SharePoint provides you a nice ASP.NET model of Web Parts functionality. But when we are building the internet faced public sites and trying to apply Web Content Accessibility Guidelines (WCAG) on Web Part Zones it come back and bite us. The major problem is that Web Part zone is not WCAG compliant.

There are several ways to achieve desired behaviour

1. use “Accessibility Kit for SharePoint”. It seems to be very logical step to consider :) There are 25(!) different adapters, which have to address accessibility of Web Parts, but harsh reality is that none of them address Web Parts Zones compliance. Yep, it’s not a joke :) So, cross out this point 
2. Use *custom* adapter on the top of WebPartZone to render content with <DIV> tag. Unfortunately SharePoint integrated a lot if JavaScripts to their web parts zones, that current approach breaks drag-n-drop functionality of Web Parts. (I reckon that’s why AKT didn’t address this issue)

In these days using custom adapters is the only way to achieve WCAG for Web Parts Zone. It won’t work for the intranet sites, due to broken drag-n-drop functionality, but for public sites it has not disadvantages, because you usually don’t allow users to change layout of public sites.

You can find custom adapter for the Web Parts zone there.  Thanks to eigilm for this code.

Have anything to add?! Send your tips to be published via this form

10 new SharePoint Templates

Microsoft just released 10 new SharePoint template for your sites

Detailed info: http://blog.drisgill.com/2009/03/microsoft-released-10-new-sharepoint.html

Download: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0a87658f-20b8-4dcc-ad7a-09ad22641f3a

SharePoint Tip #26. Do you know “How to create Central Administration feature”?

Sometimes you are developing some serviced or administrative application for SharePoint and what to have feature on the level of Central Administration. Something like “SharePoint Administrative Toolkit”

To achieve such level activation you need to add additional attributes to your feauture definition

1. AutoActivateInCentralAdmin= “TRUE”
2. Hidden=”TRUE”

You can set the same settings programmatically, using SPFeatureDefinition.AutoActivateInCentralAdmin property

Consider using SPFeatureReceiver class to avoid feature being activated on other Web Applications, except the Central Administration (webApp.IsAdministrationWebApplication check in receiver)

Source

Have anything to add?! Send your tips to be published via this form

SharePoint Tip #25. Do you know “How to calculate Content DB grow”?

SharePoint content databases grow very rapidly when used in document imaging system or in file share replacement scenarios. With this in mind it is important to consider growth and overhead factors when determining how much content will eventually be stored in a given content database.

Use the following formula to calculate Content DB size.

Low:  1.2 * [Raw Storage Size] = ContentDB Size 
High: 1.5 * [Raw Storage Size] = ContentDB Size

If possible, separate each data file to exist on separate logical units consisting of unique physical disk spindles

Source

Have anything to add?! Send your tips to be published via this form

Joel’s SharePoint Backup and Restore Q&A

Joel published Q&A section from his Backup/Restore WebCast, which I recommend to read there.  The most important things from that webcast and Q&A are:

1. SQL Cluster does not work in a VMWare Environment. Will be working in future versions of vmWare.
2. SQL Replication is not supported to synchronize databases in SharePoint, albeit some vendors have “replication” solutions, like Infonic and Synergy.
3. Microsoft doesn’t support replica for SharePoint database synchronizations.
4. vmWare clone is good for recovery & snapshot is for backups.
5. The easiest way to restore a site is with Quest Recovery Manager.
6. Avoid shrinking the transaction log whenever possible.
7. Quest Recovery Manager does recovery only, not backups.
8. STSADM does NOT export/import lists. Need to use Quest Recovery Manager, object model such as content migration API, or STSADM extensions.

SharePoint Tip #24. Do you know “How do I tune the MOSS Object Cache for performance”?

Steve Sheppard published nice recommendation regarding optimizing the MOSS Cache performance and how to measure the performance.

Citing the tips section from his post

We feel this level of cache performance will meet an economical customers performance needs without unduly sacrificing their limited memory resources. The steps to achieve this are fairly straightforward and must be applied in an iterative fashion until the desired level of performance is achieved. The recommended steps are:

1. Start with the default cache settings of 100MB on the site collection.
2. Capture at least 8 hours worth of performance data from the WFEs while the system is under a typical load using the "SharePoint Publishing Cache/Total number of cache compactions" counter. Since we are interested in tracking compactions per hour it is acceptable to  capture this data at 1 minute intervals.
3. After analysis of the data, if we are exceeding the threshold for acceptable cache compactions we will need to add an additional 50MB to the Maximum Cache Size value and run the test again.
4. We should continue this process until such time as we have achieved an acceptable cache compaction rate.

You can find the full post there

Have anything to add?! Send your tips to be published via this form

SharePoint Tip #23. Do you know “how to make MOSS sites rendered correctly in IE8”?

Some Web sites may not be displayed correctly or work correctly in Windows Internet Explorer 8. There is a KB956197 on Mictosoft site, explaining this problem.

This issue affects the MOSS sites to be rendered fine. The good thing of this that it’s very small fix to apply on the master page to have your SharePoint sites rendered correctly – you need to set the IE7 compatibility explicitly.

Just add the following code to the META section of your master.Page

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

This will force your site to be displayer in IE compatibility mode and it renders without any glitches and nothing stops you to use IE8 for your SharePoint environments.

Have anything to add?! Send your tips to be published via this form

SharePoint Tip #22. Do you know “how to manage large list performance”?

When a list or library has a large number of items, you must carefully plan its organization and how users need to access the data to help preventing adverse effects on performance.

For best performance, do not exceed 2,000 items in a list level. For example, the root of the list or a single folder. In case if you must create and browse large lists, use the following best practices.

1) Create Indexed Colum

An index on a column enables Microsoft Windows SharePoint Services 3.0 to quickly analyze the data in that column, even when working with thousands or millions of items

2) Use only one Indexed Column in view

3) First column that is used to filter the view must have  an index

4) Change the default view of the list to a customized filtered view that follows these recommendations:

•    The view returns fewer than 5,000 items.
•    The first column that you use to filter the view has an index that sufficiently reduces the total number of items returned.
•    The view displays only those columns that are absolutely required.
•    The view includes as few lookup columns as possible. Each lookup column in a list that is included in a view causes an additional join and additional calls to the database.

Source

Have anything to add?! Send your tips to be published via this form

SharePoint Tip #21. Do you know “about the problems of two SSPs in farm”?

The main role of the SSP is to serve as the provider of key centralized services to consuming sites and portals. It was designed with isolation in mind that Web Application Web Application is working with the single SSP only, so that an organization would have a single SSP from which all of its sites could consume enterprise-level services.

Each Web Application in SharePoint farm must get its Shared Services from a single SSP. It’s not possible to use different SSPs for certain Shared Services. Neither is it possible to say that a certain SSPs only provides certain services. The concept of the single SSP works well for hosted scenarios and non-global organizations and companies.

There are several scenarios for having multiple SSPs:

1. Index Server scale. There is a recommended maximum of 50 million items per Index Server. Since you can only have 1 Index server per SSP. If you can more than 50 million items to index, you may need to split the load across multiple SSPs.
2. Privacy. Some parts of the organization may actually want to host their own My Sites, Profiles etc and the split is seen as a good thing.
3. Geographically Dispersed deployments.

In such scenarios isolated SSP doesn’t provide required functionality, especially for User Profiles and Personalization. So, you have to configure the farms with multiple SSPs. There are no limitation to have several SSPs in farms, but that configuration introduces additional level of complexity to have services synchronized.

In case of multiple SharedServices you end up with duplicated services. If you do have 2 SSPs, then you have 2 My Sites per user, 2 profiles per user, 2 sets of search indexes etc.  Such configuration requires additional steps to keep the SSPs in sync with each other and make sure that user's are redirected to the correct SSP for their My Site.

To simplify synchronisations Microsoft provides tool “User Profile Replication Engine” (part of SharePoint Administration Toolkit) to maintaining consistent user profile data throughout the complete SharePoint ecosystem, including geographic deployments. It does multi-master data replication from one source to multiple destinations in the form of a full or incremental synchronization.

Source

Have anything to add?! Send your tips to be published via this form

SharePoint Tip #19. Do you know “when to use Web Services and when API”?

SharePoint provides you two models for development – Web Services and API for object model. But very often developers are a bit confused about what to use and when.

SharePoint API provides access to all pillars of SharePoint – advanced functionality via features set and good performance . It’s a preferable solution when code resides on the SharePoint server with the access to server to deploy features and other’s library.

SharePoint Web Services provide almost the same level functionality to manage SharePoint. There is a small performance challenged due to object’s serialization/de-serialization and network latency, comparing to API. But the principal only difference with API in the context of usage. Web Services are applicable to remote SharePoint instances, when you have limited access, or don’t have any access to deploy your features and libraries. The only way to manipulate with SharePoint data in this case is via standard Web Services, which can be found in the following MSDN article.

There is a tend that Microsoft moves their services online and we have Microsoft Online Services which demonstrate how SharePoint, Exchange and other servers works in SaaS model. In this case managing online SharePoint services is available only via Web Services.

Have anything to add?! Send your tips to be published via this form

SharePoint Tip #20. Do you know “about Site Objects limitations in size”?

When you plan the architecture of you SharePoint farm you should be aware about the following limitations in size of SharePoint objects. Keep your items below those numbers to have adequate performance, otherwise it degrades significantly if you overstep those values

So, Recommended sizes are:

Have anything to add?! Send your tips to be published via this form

SharePoint Tip #18. Do you know “why to use dedicated Web Server for crawling”?

By default, Office SharePoint Server 2007 uses all of the front-end Web servers in the server farm to crawl content in the same server farm. The index server sends requests to each front-end Web server in the farm. The front-end Web servers get the requested content from the SharePoint sites in the farm and forward that content to the index server for indexing.

This works well for small-to-medium-size organizations. Large organizations, however, tend to crawl more content than small organizations. This can translate into hundreds of gigabytes or even terabytes of content that is being crawled and indexed, what places a heavy load on the front-end Web servers. Such load cause negative impact on the performance (CPU usage and up to 50% of trafic) of all front-end Web servers in your server farm.

To improve the overall performance in large farm configure a dedicated Web server for crawling content, especially if you are crawling a server farm that contains more than 500 gigabytes (GB) of content or if you are crawling content over the WAN
Consider removing this dedicated server from NLB routing

Source

Have anything to add?! Send your tips to be published via this form