Prasad Pasem

70-542

2007-10-24T10:16:00.001+05:30

Enforce document storage business rules by using Document Policy

1. Create a custom document policy

2. Deploy a document policy by using a policy feature

MOSS Custom policies part 1 - Creating a custom information management policy
An information management policy in SharePoint 2007 is a set of rules and actions that help an organization to manage the content in their SharePoint sites. Policies are assigned to lists and content types. Therefore they make it easy to enforce a policy without your users having to think about it. This MSDN page contains a nice overview of the architecture of the policy architecture in SharePoint.
Out of the box there are 4 policies:
• Expiration
• Auditing
• Document Labels
• Document Bar Codes
These 4 policies are available as “Policy Features”. These can be used to specify the policy for a SharePoint list or a content type. These polices can be specified at the site collection level to be used throughout the whole site, or directly at the list/content type.
The nice thing is that the policy framework is an extensibly framework, so you can write your own information management policies. This will be the first of a number of posts on this topic. The first part shows you how to create and register a policy so that it can be used. The scenario I used for this example is not very useful, but I wanted to have a simple policy to start with.
Because I was listening to the latest Depeche Mode DVD (Live in Milan) when reading the SDK, I decided to create a “Policy of Truth”. Administrators the specify a policy can enter a number of keywords. When new content is added to SharePoint lists (or document libraries) that have our policy assigned, our policy will check the metadata for the presence of one of the keywords. When one of the keywords is found, and the metadata also contains the word “truth” or “proof”, a link to the item is submitted to a central list in a special site collection. This way, we can easily manage our version of “the truth”. Not very useful, but pretty straightforward and it covers most aspects of building a custom policy.
Step 1 – Create the policy feature
In the first step we will create the policy feature. To do this you need to implement the IPolicyFeature interface. At this stage we will only implement an empty Policy feature to be sure that we get it registered correctly. The actual work done by the policy will be covered in the next post. Here is the code for the poliy feature:
public class PolicyOfTruth : IPolicyFeature
{
public PolicyOfTruth()
{
}

public void OnCustomDataChange(PolicyItem policyItem, Microsoft.SharePoint.SPContentType ct)
{
}

public void OnGlobalCustomDataChange(PolicyFeature feature)
{
}

public bool ProcessListItem(Microsoft.SharePoint.SPSite site, PolicyItem policyItem, Microsoft.SharePoint.SPListItem listItem)
{
return true;
}

public bool ProcessListItemOnRemove(Microsoft.SharePoint.SPSite site, Microsoft.SharePoint.SPListItem listItem)
{
return false;
}

public void Register(Microsoft.SharePoint.SPContentType ct)
{
}

public void UnRegister(Microsoft.SharePoint.SPContentType ct)
{
}
Add this to a class library, strong name the assembly and add it to the GAC. IPolicyFeature can be found in the Microsoft.Office.RecordsManagement.InformationPolicy namespace. To use this you need a reference to Microsoft.Office.Policy.dll.
Step 2 – Create the manifest
In a later step we will register the new policy. To do this we need a manifest. I saved this to a manifest.xml file that is loaded by the process that registers the policy.

xmlns:p="urn:schemas-microsoft-com:office:server:policy" group="Policy">
dlccore
Policy of Truth

This policy helps us to achieve the goals set in our
'one version of the truth' project

Ton Stegeman
policyoftruthsettings.ascx

You can add keywords here.
If any of these keywords is found in the item's metadata and the metadata also has
the word 'truth' or 'proof', then the item is considered to be the 'truth'. And our
truth is something we need to manage. Separate your keywords with a ';'

TST.POC.PolicyOfTruth, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=503edd7b21a430b3

TST.POC.PolicyFeatures.PolicyOfTruth

The name and description are used to describe your policy. The ConfigPage and ConfigPageInstructions are used on the page that is loaded when a user creates a new policy. The instructions are displayed in the left column of the page and the ASCX in the ConfigPage element is loaded when a user checks the box for our “Policy of Truth” policy. The AssemblyName and ClassName elements are the reference to the policy feature we created in step 1.
Step 3 – Create the configuration page.
The configuration page is the page that is loaded when a user creates a policy using our feature. The screenshot below shows the control for this specific policy.

To create this control, you create a new ASCX file and copy that to the SharePoint LAYOUTS folder. The contents of my PolicyOfTruthSettings.ASCX file:

<%@ Assembly Name="TST.POC.PolicyOfTruth, Version=1.0.0.0, Culture=neutral, PublicKeyToken=503edd7b21a430b3"%>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls"
Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities"
Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Control Language="C#" Inherits="TST.POC.PolicyOfTruth.PolicyOfTruthSettings" %>


	class="ms-input" ToolTip="Enter your keywords here." /> id="RequiredValidatorKeywords" ControlToValidate="TextBoxKeywords" ErrorMessage="At least one keyword is required." Text="Please enter on or more keywords separated by a semicolon." EnableClientScript="false" runat="server"/>

You can see here the this control inherits a custom class that I have created called “PolicyOfTruthSettings”. This class inherites from CustomSettingsControl and is compiled into the same assembly as created in step 1. The CustomSettingsControl can be found in namespace “Microsoft.Office.RecordsManagement.InformationPolicy”. It is an abstract control with some abstract methods that our CustomSettingsControl needs to implement. Here is the code for this class in my example:
public class PolicyOfTruthSettings : CustomSettingsControl
{
private SPContentType _contentType;
private string _customData;
private SPList _list;
protected TextBox TextBoxKeywords;

public override Microsoft.SharePoint.SPContentType ContentType
{
get {return _contentType;}
set {_contentType = value;}
}

public override string CustomData
{
get
{
XmlDocument doc = new XmlDocument();
XmlElement rootNode = doc.CreateElement("data");
doc.AppendChild(rootNode);
XmlElement keywordsNode = doc.CreateElement("keywords");
rootNode.AppendChild(keywordsNode);
keywordsNode.InnerText = TextBoxKeywords.Text;
_customData = doc.InnerXml;
return _customData;
}
set {_customData = value;}
}

public override Microsoft.SharePoint.SPList List
{
get {return _list;}
set {_list = value;}
}

public override bool LoadPostData(string postDataKey,
System.Collections.Specialized.NameValueCollection values)
{
string oldData = this.CustomData;
string newData = values[postDataKey];
if (oldData!=newData)
{
this.CustomData = newData;
return true;
}
return false;
}

public override void RaisePostDataChangedEvent()
{
}

protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
if ((base.IsPostBack) || (string.IsNullOrEmpty(_customData)))
{
return;
}
using (XmlReader reader = XmlReader.Create(new System.IO.StringReader(_customData)))
{
reader.ReadStartElement("data");
reader.ReadStartElement("keywords");
TextBoxKeywords.Text = reader.ReadString();
reader.ReadEndElement();
reader.ReadEndElement();
}
}
}
The most important parts of this control are the CustomData property and the OnLoad. All custom data that you collect using the controls in the CustomSettingsControl is saved with the policy as xml. You can see that when you export a policy. See the last step for an example of the policy we are developing. A warning here: you should be careful with this xml, because if you create some xml that cannot be parsed or has another error, SharePoint will crash the page leaving you with a corrupt policy that cannot be removed. In my case I created a site collection policy that made all other policies inaccessible, so I had to re-create the site collection. So be warned!. In the CustomData property the xml is generated with the values of the controls. The OnLoad reads the xml string and sets the values for the usercontrol(s) in your editor.
Step 4 – Register the policy feature
The last step after you have deployed the assembly and the ascx file is to register the policy feature in the PolicyCatalog. Although I am not 100% sure, I think there is 1 policy catalog for each MOSS server. This MSDN page in the SharePoint Server 2007 SDK contains more information. The way to register your custom policy is doing it programmatically. I do it in a custom tool that makes it easy to register / unregister the custom policy. The best way to do it (and the way SharePoint does it) is by creating a new SPFeatureReceiver object that registers the policy. Here is the code to register our policy:
PolicyFeatureCollection policyFeatures = PolicyCatalog.FeatureList;
foreach (PolicyFeature policyFeature in policyFeatures)
{
if (policyFeature.Id=="TST.POC.PolicyFeatures.PolicyOfTruth")
{
MessageBox.Show("Policy was already installed");
return;
}
}
string manifest = System.IO.File.ReadAllText("manifest.xml");
PolicyFeature.ValidateManifest(manifest);
PolicyFeatureCollection.Add(manifest);
This piece of code first checks if the policy is not registered. If it is not, it reads the manifest for the policy from the manifest.xml file. Then this manifest is validated and added to the PolicyFeatureCollection. The objects referenced here are in the same namespace that we used in step 1 and 2.
And if you need to unregister it:
PolicyFeatureCollection policyFeatures = PolicyCatalog.FeatureList;
foreach (PolicyFeature policyFeature in policyFeatures)
{
if (policyFeature.Id == "TST.POC.PolicyFeatures.PolicyOfTruth")
{
PolicyFeatureCollection.Delete(policyFeature.Id);
return;
}
}
Step 5 – Test
After you successfully registered your policy feature, you are now ready to test if your policy is available. To create a policy at the site collection level, go to “Site collection policies” in the Site Collection Administration. When you click Create, the “Policy of Truth” should be available:

When you check the box, you will see the screenshot from step 3. After creating and saving the policy, you can export it to an xml file. If you open this file, you can see that the data we entered in our custom control, is stored in the policy xml. This was done by the CustomSettingsControl from step 3. An example of the xml:

The truth about SharePoint
This policy manages 'truth' items on SharePoint in our portal

SharePoint list items and documents that are considered to be the truth about SharePoint
Technologies, will be managed by our 'truth manager'.

Policy of Truth
This policy helps us to achieve the goals set in our 'one version of the
truth' project

SharePoint; MOSS; WSS

You can also directly assign a new policy on a list or a content type, or you can assign the policy we just created for the site collection.

Manage records by using Office SharePoint Server 2007 record management features
----------------------------------------------------------------------------

MOSS Custom policies - creating a handler to submit items to the records center
In the first part of this series, I introduced a custom information management policy. In the previous post I created and registered the custom policyfeature. We ended up with a policy that we could create and setup. In this post, we’ll create the handler that will make the policy do some work. The sample policy that I was working on is the “policy of truth”. In case a user submits an item containing the word “truth” in combination with one of the keywords in the policy setup, the policy will do it’s work. Because I was also preparing for the beta exam 70–542, I decided to submit the item to a records repository. If you want to learn more about the Records Center in SharePoint, this item on the Records Management Team Blog is a good starting point.
I will post the most important code bits here. When the series is complete, I will post the full code (I’ll need to do some cleaning up first….)
Step 1 – Create the repository handler
First we will create a new class that will handle the list items. It will check if the item needs to be submitted and if so, it will submit the item. Our “RepositoryHandler” has a method called “HandleListItem”. This takes a SPListItem as parameter.
Step 2 - Get the keywords from the policy
First the handler needs to find out what keywords the user has set when setting up the policy:
private string GetKeywords(SPListItem item)
{
// get the keywords from the policy options
Policy policy = Policy.GetPolicy(item.ContentType);
PolicyItem policyItem = policy.Items[PolicyOfTruth.PolicyId];
string keywords = string.Empty;
using (XmlReader reader = XmlReader.Create(new System.IO.StringReader(policyItem.CustomData)))
{
reader.ReadStartElement("data");
reader.ReadStartElement("keywords");
keywords = reader.ReadString();
reader.ReadEndElement();
reader.ReadEndElement();
}
return keywords;
}
The PolicyId of the PolicyOfTruth feature is a static property that just returns the id of the policy:
public static string PolicyId
{
get { return "TST.POC.PolicyFeatures.PolicyOfTruth"; }
}
Step 3 - Check if we need to submit the item
This bit of code checks if any of the keywords and the word ‘truth’ is found in one of the metadata fields of the list item. This code is very simple, because my goal was to get the policy working, not to create something for a useful scenario.
private bool HandleItem(SPListItem item, string keywords)
{
bool handle = false;
// for now just do documents in a doclib.
if (item.ParentList is SPDocumentLibrary)
{
string[] keywordItems = keywords.Split(new char[] { ';' });
foreach (string keyword in keywordItems)
{
foreach (SPField field in item.Fields)
{
if (item[field.Id] != null)
{
string value = item[field.Id].ToString();
if ((value.ToLower().IndexOf(keyword.ToLower().Trim()) > -1) &&
(value.ToLower().IndexOf("truth") > -1))
{
handle = true;
break;
}
}
}
if (handle) break;
}
}
return handle;
}
Step 4 - Setup the connection to the records center
To submit the item to the records center, I used the code sample from the ECM Starter Kit (part of the MOSS SDK). First you need to get a web reference to the webservice of the records center. If you don’t have a record center yet, the first thing to do is create one. The webservice can be found on this url: http://office2007:3736/_vti_bin/OfficialFile.asmx. In my case the records center is running on port 3736 of my server called ‘office2007’. My web reference is called ‘Repository’. Setup a connection:
TST.POC.PolicyFeatures.Repository.RecordsRepository repository = new Repository.RecordsRepository();
repository.Credentials = System.Net.CredentialCache.DefaultCredentials;
repository.PreAuthenticate = true;
Step 5 – Add properties for the records center
The next thing is to add a property to the item that will get submitted to the records repository. In this property we will save the accountname of the user who initially created the item. To do this, you create a new RecordRepositoryProperty:
Repository.RecordsRepositoryProperty[] repositoryProperties = new Repository.RecordsRepositoryProperty[1];
repositoryProperties[0] = new Repository.RecordsRepositoryProperty();
repositoryProperties[0].Name = "SubmittedBy";
repositoryProperties[0].Type = "Text";
repositoryProperties[0].Value = item["Created By"].ToString();
Step 6 – Submit the document
To submit the document to the records center, you first have to read it into a byte array. Then call the SubmitFile method. This takes the byte array, the properties array we created as parameters. You also need the pass the name of the routing. I have not yet created a special routing for my items, so I used the default routing called “Unclassified Records”.
byte[] doc = item.File.OpenBinary();
string result = repository.SubmitFile(doc, repositoryProperties,
"Unclassified Records", item.Url, item.Web.CurrentUser.Name);
Step 7 – Handling the result
The SubmitFile method of the OfficialFile webservice returns a xml string. Here is a way to find out what happened. In case of success, the handler updates the item that was submitted. It saves the current datetime in a custom field that was added to the content type by the policy.
result = string.Format("{0}", result);
XmlDocument xml = new XmlDocument();
xml.LoadXml(result);
XmlElement root = xml.DocumentElement;
string resultCode = root.SelectSingleNode("ResultCode").FirstChild.Value;
string additionalInformation = string.Empty;
if (root.SelectSingleNode("AdditionalInformation") != null)
{
additionalInformation = root.SelectSingleNode("AdditionalInformation").FirstChild.Value;
}
if (resultCode == "Success")
{
item[truthFieldName] = DateTime.Now;
item.Update();
}
return string.Format("Submitted to records center: {0} - {1}", resultCode, additionalInformation);
In my example code it generated a new result string that is returned by the HandleListItem method on the repository handler.
In this post we created the handler that makes our policy do some work. In the next post, I will put it all together, so that it will be a working custom information management policy.
MOSS Custom policies part 3 - implementing the custom policy
This is the 3rd and last part in a small series on how to create a custom information management policy for SharePoint 2007.
In part 1 the policy was introduced and we created the policy feature and created the setup control that allows our users to configure the policy.
Part 2 shows how to create the handler that actually does some work and submits a document to the records center
The final part will put it all together. It also has all code attached. You can find the zip file at the bottom of this article.
Step 1 – Registering the PolicyFeature
In the first part we implemented the IPolicyFeature interface, but it didn’t do anything. The first method we will implement is the Register method. This is called when the policy is assigned to a content type. This is the perfect place if you need to do some extra configuration. I will do 2 things here:
• Setup an event receiver for the content type.
• Add an extra site column (and create if it doesn’t exist) to the content type.
To setup an event receiver for the content type, we’ll add this code to the register method:
Assembly assembly = Assembly.GetExecutingAssembly();
SPEventReceiverDefinition eventReceiver = ct.EventReceivers.Add();
eventReceiver.Name = "Policy of Truth";
eventReceiver.Type = SPEventReceiverType.ItemUpdated;
eventReceiver.SequenceNumber = 200;
eventReceiver.Assembly = assembly.FullName;
eventReceiver.Class = "TST.POC.PolicyFeatures.PolicyOfTruthHandler";
eventReceiver.Update();
The event receiver itself will be implemented in one of the next steps. The code to setup the site column to the content type is added below. This will first check if a field with internalname “SentToTruthRepository” is available in the content type. If it is not it will check if this field is available as a site column. If the site column is not yet available, it will create it as a readonly site column. The value of this field will only be updated by our policy, and users should not be able to change it manually. This last bit adds the site column to the Content Type.
string fieldName = "SentToTruthRepository";
// test if field is linked to content type
foreach (SPFieldLink link in contentType.FieldLinks)
if (link.Name == fieldName)
return;
SPField repositoryField = null;

using (SPWeb web = contentType.ParentWeb)
{
// check if site column exists in the site
foreach (SPField field in web.AvailableFields)
{
if (field.InternalName == fieldName)
{
repositoryField = field;
break;
}
}

// add site column if it does not exist
if (repositoryField == null)
{
string xml = " xml += "DisplayName=\"Sent to truth repository\" Required=\"TRUE\" Format=\"DateTime\" ";
xml += "ReadOnly=\"TRUE\" Group=\"Policy Columns\" />";
string newField = web.Fields.AddFieldAsXml(xml);
repositoryField = web.Fields.GetFieldByInternalName(newField);
}
}
// add field to content type
SPFieldLink newLink = new SPFieldLink(repositoryField);
contentType.FieldLinks.Add(newLink);
contentType.Update(true);
Step 2 – Unregistering the policy
The method UnRegister on the policy feature is called when a policy is detached from a content type. This is the place to unregister the event handler that we created in the first step. You can also remove the extra site column from the content type, but I decided to leave it.
public void UnRegister(Microsoft.SharePoint.SPContentType ct)
{
if (ct == null)
{
throw new ArgumentException();
}
SPEventReceiverDefinition delete = null;
foreach (SPEventReceiverDefinition eventReceiver in ct.EventReceivers)
{
if ((eventReceiver.Name == "Policy of Truth") && (eventReceiver.Type == SPEventReceiverType.ItemUpdated))
{
delete = eventReceiver;
break;
}
}
if (delete != null)
delete.Delete();
}
Step 3 – Creating the event handler
The next step is to create the event handler we used in step 1. This will use the handler we created in the previous part. This handler check the item for the policy rules and submits the item to the records center. The event handler is a normal event reveiver for SharePoint list event. For demo purposes I have only implemented the ItemUpdated event.
public class PolicyOfTruthHandler : SPItemEventReceiver
{
public override void ItemUpdated(SPItemEventProperties properties)
{
DisableEventFiring();
RepositoryHandler repository = new RepositoryHandler();
if (repository.HandleListItem(properties.ListItem))
{
string truthFieldName = "Sent to truth repository";
properties.ListItem[truthFieldName] = DateTime.Now;
properties.ListItem.Update();
}
EnableEventFiring();
}
}
The RepositoryHandler you see here is the handler I created in the previous part of this series. The code to update the list item and set the date in the special site column, has moved from the repository handler to the event handler. The eventhandler first calls DisableEventFiring() to prevent the update of the list item by the policy from firing the event a second time. For the update this works, but for some strange reason the ItemUpdated event fires twice in the process. As soon as we call the SubmitFile method on the OfficialFile.asmx webservice, the event gets fired a second time. This way we end up with 2 documents in the records center each time we change an item. I’ve spent quite a bit of time trying to stop this, but I didn’t succeed. I decided to leave it as is, because I wanted to get the policy working and it is not a real world scenario.

Step 4 – The rest of the policy feature
Our policy feature also implements the method “ProcessListItem”. According to the policy sample in the ECM Starter Kit (MOSS SDK), this method is called for list items of the content type that were added before the policy was in place. Items that we not handled by the vent handlers (because the event handlers were not there yet) will we processed by ProcessListItem when the policy is assigned. I tried to test this using my custom policy of truth, but couldn’t get it to work.
To be a full working solution our policy should also implement the OnCustomDataChange method. This is called when the custom setup of the policy is changed. In our case this is when an administrator changes the keywords. Our policy feature should then check which documents are considered as ‘truth documents’ and these should be added to the records center.
Step 5 – Testing the solution
Here are the steps how I tested the custom policy:
• Create a new content type called “Whitepaper”
• Create a new custom policy for this content type. Activate the Policy of Truth and set the keywords to SharePoint and WSS

• Assign the content type to a document library

• Upload a new document to the document library and set the title to “The truth on SharePoint development”

• Navigate to your records center and test if your document was submitted to the records center. It should be submitted as an unclassified record. Please note that my testdocument was uploaded twice. I explained the reason for that above in step 3.

• Open one of the xml files in the “Properties” folder and notice that we also set a custom property while submitting the file to the repository: ‘SubmittedBy’.

• Go back to the document library that has the document we just added. Change the view to include the field “Sent to truth repository” field. Notice that this field now has a value. This was set by the policy after successfully submitting the document to the records center.

Overview of all parts:
Provide custom Information Rights Management rights policy templates in Office 2007
Updated: March 26, 2007
The 2007 Office release includes predefined groups of Information Rights Management (IRM) permissions, such as Do Not Forward, that users can apply to documents or e-mail messages. As an Office administrator, you can also define custom IRM rights policy templates to provide different packages of IRM rights for information workers to use in Office applications.
Before users can apply IRM permissions in Office applications, rights management services and software must be installed. For specific requirements, see Planning for Information Rights Management in the Office 2007 system .
Note:
The ability to create content or e-mail messages with restricted permission using IRM is available in the following suites: Microsoft Office Professional Plus 2007, Microsoft Office Enterprise 2007, and Microsoft Office Ultimate 2007. IRM is also available in the stand-alone versions of Office applications.
For corporations, administrators can create a custom permission policy that configures various people and groups with customized IRM permissions. In some cases, this can greatly simplify the process of setting permissions: a single custom permission policy can replace the user's need to select multiple permission settings.
Creating rights policy templates
You create and manage rights policy templates by using the administration site on your Windows RMS server.
The steps are as follows:
1. On the RMS administration site, under Administration Links, select Create a policy rights template.
2. Specify the settings for the template, including its name, which users or groups (via distribution lists) receive which permissions, expiration policies, and so on.
3. Submit the template information to create the template.
For specific instructions on how to create, edit, and post custom permissions policy templates that include groups of Office permissions rights, see "Rights Policy Templates" in Enabling Information Protection in Microsoft Office 2003 . The instructions are for Office 2003, but the process works the same in the 2007 Office release. In addition, more detailed information is available in RMS Help.
The rights that you can include in permissions policy templates for the 2007 Office release are listed in the next section.
Permissions rights
Each IRM permissions right listed in the following table can be enforced by Office applications configured on a network that includes a server running RMS.
IRM right Description
Full Control Gives the user every right listed below, and the right to make changes to permissions associated with content. Expiration does not apply to users with Full Control.
View Allows the user to open IRM content. This corresponds to Read Access in the Office user interface.
Edit Allows the user to edit the IRM content.
Save Allows the user to save a file.
Extract Allows the user to make a copy of any portion of a file and paste that portion of the file into the work area of another application.
Export Allows the user to save content in another location or format that may or may not support IRM.
Print Allows the user to print the contents of a file.
Allow Macros Allows the user to run macros against the contents of a file.
Forward Allows e-mail recipients to forward an IRM e-mail message.
Reply Allows e-mail recipients to reply to an IRM e-mail message.
Reply All Allows e-mail recipients to reply to all users on the To: and Cc: lines of an IRM e-mail message.
View Rights Gives the user permission to view the rights associated with a file. Office ignores this right.
Predefined groups of permissions
The 2007 Office release provides the following predefined groups of rights that users can choose from when they create IRM content. The options are available on the Permission dialog box for Word, Excel, and PowerPoint. In the Office application, click the Microsoft Office Button, point to Prepare, point to Restrict Permission, and select Restriction permission to this document to enable the permission options listed below.
IRM predefined group Description
Read Users with Read permission only have the View right.
Do Not Forward In Outlook, the author of an IRM e-mail message can apply Do Not Forward permission to users in the To:, Cc:, and Bcc: lines. This permission includes the View, Reply, and Reply all rights.
Change Users with Change permission have View, Edit, Extract, Export, and Save rights.
Advanced permissions
Other IRM permissions can be specified in the advanced Permission dialog box in Word, Excel, and PowerPoint. In the initial Permission dialog box, click More Options. For example, users can specify an expiration date, allow other users to print or copy content, and so on.
In addition, Outlook by default enables messages to be viewed by a browser that supports Rights Management.
Deploying rights policy templates
When the rights policy templates are complete, post them to a server share where all users can access the templates or copy them to a local folder on the user's computer. The IRM policy settings available in the 2007 Microsoft Office system ADM (Office12.adm) file can be configured to point to the location where the rights policy templates are stored (either locally or on an available server share).
Note:
The 2007 Microsoft Office system template and other ADM files can be downloaded from 2007 Office System Administrative Templates (ADM) on the Microsoft Download Center. For more information about how to use Group Policy with Office applications, see Enforce settings by using Group Policy in the 2007 Office system .

When the rights policy templates are available, complete the IRM policy Specify Permission Policy Path. IRM locates the rights policy templates stored in the location specified.
To configure the IRM rights policy templates location in Group Policy
1. In Group Policy, load the Office Outlook 2007 template (Outlk12.adm) and go to User Configuration\Administrative Templates\Microsoft Office 12 system\Manage Restricted Permissions.
2. Double-click Specify Permission Policy Path.
3. Click Enabled.
4. In the Enter path to policy templates for content permission text box, type the complete path to the IRM permission policy templates.
5. Click OK.

Audit Windows SharePoint Services content by using a custom policy
--------------------------------------------------------------------------------

Introduction to information management policies

Organizations can define and use information management policies on Microsoft Office SharePoint Server 2007 sites to enforce compliance with corporate business processes or legal or governmental regulations for the management of information. Information management policies enable site administrators or list managers to control how content is managed.
In this article
________________________________________
What is an information management policy?
How information management policies can be used in a site
________________________________________
What is an information management policy?
An information management policy is a set of rules for a type of content. Information management policies enable organizations to control and track things like how long content is retained or what actions users can take with that content. Information management policies can help organizations comply with legal or governmental regulations, or they can simply enforce internal business processes. For example, an organization that must follow government regulations requiring that they demonstrate "adequate controls" of their financial statements might create one or more information management policies that audit specific actions in the authoring and approval process for all documents related to financial filings.
Policy features included in Office SharePoint Server 2007
Each individual rule within an information management policy is a policy feature. Office SharePoint Server 2007 includes several predefined policy features that organizations can use individually or in combination to define information management policies for their sites. The policy features included in Office SharePoint Server 2007 are:
Auditing The Auditing policy feature helps organizations analyze how their content management systems are used by logging events and operations that are performed on documents and list items. Organizations can configure the Auditing policy feature to log events such as when a document or item is edited, viewed, checked in, checked out, deleted, or has its permissions changed. All of the audit information is stored in a single audit log on the server, and site administrators can run reports on it. Organizations can also use the Office SharePoint Server 2007 Object Model to write and add custom events to the audit log.
Expiration The Expiration policy feature helps organizations delete or remove out-of-date content from their sites in a consistent, trackable way. This policy feature helps organizations manage both the cost and risk associated with retaining out-of-date content. Organizations can configure an Expiration policy to specify that certain types of content expire on a particular date or within a calculated amount of time after some document activity (such as creating or editing).
Barcodes The Barcodes policy feature enables organizations to track physical copies of documents or list items that have been printed from a site. The Barcode policy feature creates a unique identifier value for a document. Users can then insert a barcode image of that value into the Microsoft Office documents they create. They can also use a barcode on a physical copy of a document to search for the original copy of that document on the server. By default, barcodes are compliant with the common Code 39 standard (ANSI/AIM BC1-1995, Code 39). Organizations can use the Office SharePoint Server 2007 Object Model to install other barcode providers.
Labels The Labels policy feature also enables organizations to track physical copies of documents or list items that have been printed from a site. The Labels policy feature automatically generates text labels based on document properties and formatting that a site administrator or list manager specifies. When users insert labels into Microsoft Office documents, the labels are updated automatically with the information from the document's properties.
Top of Page
Custom policy features
Organizations can also create and deploy custom policy features to meet specific needs. For example, a manufacturing organization might want to define an information management policy for all draft product design specification documents that prohibits users from printing copies of these documents on nonsecure printers. To define this kind of information management policy, the organization can create and deploy a Printing Restriction policy feature that can be added to the relevant information management policy for the product design specification content type.
Top of Page
Information management policy integration with 2007 Microsoft Office system programs
There are a couple of ways that Office SharePoint Server 2007 information management policies can be exposed to users within the 2007 Office release client programs. When you configure an information management policy on the server for a specific content type, list, or library, you can write a policy statement that is displayed to users who work with the content that is subject to this policy. The policy statement can inform users that the information management policies are enforced for the document, or it can provide detailed information, such as the fact that a document expires after a certain period of time. When users open documents that are subject to information management policies in one of the 2007 Office release client programs, this policy statement is displayed. Additionally, if an information management policy includes the Barcode or Label policy feature, the policy can be configured to require users to insert barcodes or labels into Microsoft Office documents when they try to save or print them from an 2007 Office release client program.
Top of Page
How information management policies can be used on a site
To implement an information management policy, you must add it to a list, library, or content type on a site. The locations where you either create or add an information management policy affect how broadly the policy applies or how broadly it can be used. You can:
Create a site collection policy and then add this policy to a content type, list, or library You can create a site collection policy in the Site Collection Policies list for the top-level site in a site collection. After you create a site collection policy, you can export it so that site administrators of other site collections can import it into their Site Collection Policies list. Creating an exportable site collection policy enables you to standardize the information management policies across the sites in your organization.
When you add a site collection policy to a site content type, and an instance of that site content type is added to a list or library, the owner of that list or library cannot modify the site collection policy for the list or library. Adding a site collection policy to a site content type is a good way to ensure that site collection policies are enforced at each level of your site hierarchy.
For more information, see Create an information management policy for a site collection.
Create an information management policy for a site content type in the top-level site's Site Content Type Gallery, and then add that content type to one or more lists or libraries You can also create an information management policy directly for a site content type and then associate an instance of that site content type with multiple lists or libraries. If you create an information management policy by using this method, every item in the site collection of that content type or a content type that inherits from that content type has the policy. If you create an information management policy directly for a site content type, it is more difficult to reuse this information management policy in other site collections, because policies that are created this way cannot be exported.
NOTE To control which policies are used in a site collection, site collection administrators can disable the ability to set policy features directly on a content type. When this restriction is in effect, users who create content types are limited to selecting policies from the Site Collection Policies list.
For information about creating an information management policy for a site content type, see Change a site content type.
Create an information management policy for a list or library If your organization needs to apply a specific information management policy to a very limited set of content, you can create an information management policy that applies only to an individual list or library. This method of creating an information management policy is the least flexible, because the policy applies only to one location, and it cannot be exported or reused for other locations. However, some organizations may need to create unique information management policies with limited applicability to address specific situations.
NOTES
You can create an information management policy for a list or library only if that list or library does not support multiple content types. If a list or library supports multiple content types, you need to define an information management policy for each individual list content type that is associated with that list or library. (Instances of a site content type that are associated with a specific list or library are known as list content types.)
To control which policies are used in a site collection, site collection administrators can disable the ability to set policy features directly on a list or library. When this restriction is in effect, users who manage lists or libraries are limited to selecting policies from the Site Collection Policies list.
For information about creating an information management policy for a list or library, see Specify information management policies for a list, library, or list content type.
Introduction to Information Management Policy
An information management policy is a set of rules for a certain type of important content. Policy enables administrators to control and evaluate who can access the information, how long to retain information, and how effectively people are complying with the policy itself. The most common creators and enforcers of policy are compliance officers, records managers, IT staff, and others with similar responsibilities.
With Microsoft Office SharePoint Server 2007, you can apply policies that enable you to manage your content according to your business processes. Office SharePoint Server 2007 contains several policy features you can customize for your needs, as well as an extensibility framework that enables you to create, customize, and deploy your own policies and policy features.
By using policies, you benefit in the following ways:
• Administrators can set and manage "the rules" for a content type from a single location, including both client-side and server-side policy features.
• Policies are tightly coupled to the content, both within Office SharePoint Server 2007 and in downloaded Microsoft Office system content. Administrators can be confident that policies applied to content are always being enforced, wherever the content goes within their company.
• Policies require little involvement from end users, as corporate policies are automatically and transparently followed.
In Office SharePoint Server 2007, each policy is a collection of instruction sets for one or more policy features. Each policy feature provides a specific kind of content management functionality. You can assign a policy to either a content type or a list.
For more information about content types, see Content Types in the Microsoft Windows SharePoint Services 3.0 SDK.
Policy Architecture
The following figure shows the conceptual relationships of the various policy elements.

Logically, each policy is a collection of instruction sets for one or more policy features. A policy feature is an assembly that provides some content management functionality to Office SharePoint Server 2007, and possibly to 2007 Microsoft Office system documents in client applications as well. For example, Expiration, Auditing, Document Labels, and Bar Codes are all policy features included in Office SharePoint Server 2007.
For more information about these policy features, see Policy Features Included in Office SharePoint Server 2007.
Each policy is represented by an XML document. For each policy feature that you want to include in a policy, you include an instruction set, called a policy item, in the policy. A policy item is an XML node within a policy that contains the settings for only one policy feature. These settings include information required for all policy items, such as the ID and name of the policy feature. It can also include a custom data element, which only the policy feature must be able to parse.
For each policy feature in a policy, there is only one policy item. You can include the same policy feature in multiple policies; in each policy, the feature would have a single associated policy item.
For more information about policy features, see Policy Feature Overview.
In addition, a policy feature can use one or more policy resources. A policy resource is an assembly that assists the policy feature by providing some functionality the feature needs. For example, the Bar Code policy feature uses a Bar Code Provider, which generates the bar codes, as a policy resource. Similarly, the Expiration policy feature employs an Expiration Formula Calculator as a policy resource to determine a document's actual expiration date. This policy feature also uses an Expiration Action policy resource to determine what action to take when an item reaches its expiration date.
Policy features can use multiple resources, but each policy resource can be used by only one policy feature.
For more information about policy resources, see Policy Resource Overview.
There is one policy collection per site collection; this collection can contain any number of policies. Each policy contains any number of policy items, and each item encapsulates settings information for—and points to—a single policy feature. Multiple policies can contain a policy item that points to the same policy feature. Each policy feature, in turn, can employ any number of policy resources to assist its operation. Each policy feature employs its own collection of policy resources; policy resources are not shared between policy features.
You can assign only one policy to a given content type or SharePoint list. However, that policy can contain any number of policy items
Plan information management policies
Updated: November 16, 2006
In this article:
• About information management policies and policy features

• About information management policy reporting

• About information management policy integration with the 2007 Office system applications

• Policy features available in Office SharePoint Server 2007

• Plan information management policies

About information management policies and policy features
An information management policy is a set of rules for a type of content. Each rule in a policy is a policy feature. For example, an Information Management policy feature could specify how long a type of content should be retained, or it could provide document auditing. Information management policies enable you to control who can access your organizational information, what they can do with it, and how long the information should be retained.
Note:
In this topic, the term "policy" refers to information management policy unless otherwise specified.
Policies can be implemented to help an organization comply with legally mandated requirements, such as the need to retain records. For example, a Human Resources policy, used in an organization to ensure that employee records are handled in accordance with legally recommended guidelines, could include the following policy features:
• Auditing, to record the editing and viewing history of each employee-related document.
• Retention, to ensure that work-in-progress content is not kept for an unnecessarily long period of time.
• Labels, to ensure that physical copies of each document are properly identifiable.
• Print Restrictions, to ensure that sensitive employee-related documents are only printed on secure printers. Note that this is an example of a custom policy that must be implemented using the Office SharePoint Server 2007 object model or acquired from a 3rd-party software vendor.
Policy features are implemented as programs that run on the Office SharePoint Server 2007. They can be enabled and configured by a server administrator and, once enabled, they can be used by site administrators to define policies. Office SharePoint Server 2007 includes five policy features to help you manage your content. By using the Office SharePoint Server 2007 object model, you can design and install custom policy features that meet unique enterprise needs.
A policy feature may use one or more policy resources, which are programs that provide some functionality to a policy feature. For example, a policy resource for a Barcode Generation policy feature could provide the unique barcode value. You can develop custom policy resources and install them to support policy features.
When your organization uses 2007 Microsoft Office system client applications along with Office SharePoint Server 2007, policies are enforced both on the server and in the client applications. This is done transparently; policy features that apply to a document are described in a policy statement associated with the document, and policy-aware applications prevent users from doing tasks that violate the document's policy.
To implement a policy, associate it with content types, libraries, or lists in sites.
Note:
In the Site Content Type Gallery, you can apply a policy to any custom content type, but you cannot apply a policy directly to a core content type.
You can associate a policy with a library, list, or content type in the following ways:
• Associate policy features with a site collection policy, and then associate that policy with a content type or with a list or library. The top-level site of a site collection includes a Site Collection Policies gallery where administrators of the top-level site can create new policies. After creating a Site Collection policy, you can export it so that administrators of other site collections can import it into their Site Collection Policy galleries. This enables you to standardize policies across your organization.
When a Site Collection policy is associated with a content type and that content type is associated with a list or library, the owner of the list or library will not be able to modify the Site Collection policy in the list or library. This ensures that policies assigned to a content type are enforced at each level of the site hierarchy.
• Associate a set of policy features directly with a content type, and then add that content type to one or more lists or libraries. To ensure that a policy created using this method will be used in an entire site collection, associate it with a content type in the top-level site collection's Site Content Type gallery. Then every item in the site collection of that content type, and every item of a content type that inherits from the original content type, will have the policy. When you use this method of associating a policy with a content type, it is harder to reuse the policy in other site collections, because policies created using this method cannot be exported.
Note:
To more tightly control which policies are in use in a site collection, site collection administrators can disable the ability to set policy features directly on a content type. When setting policy features on a content type is restricted, content type designers can only associate policies from the Site Collection Policies gallery with content types.

• Associate a set of policy features directly with a list or library. You can only use this method if the list or library does not support multiple content types. This method of creating a policy is only useful for a narrowly defined policy that applies to a single list or library.
Note:
To more tightly control which policies are in use in a site collection, site collection administrators can disable the ability to set policy features directly on a library. When setting policy features on a library is restricted, content type designers can only associate policies from the Site Collection Policies gallery with libraries.

Top of page
About information management policy reporting
To track how policies are being used in each Web application in your solution, you can configure information management policy usage reporting using Microsoft Office SharePoint Server 2007 Central Administration. Information management policy reports help you monitor how well your organization uses policies. Because policies are often implemented to help an organization comply with particular regulations, frequent monitoring of policy usage can help you ensure that your organization is compliant.
Office SharePoint Server 2007 includes a default policy report template in XML-SS format, and you can create a custom report template based on the XML-SS schema. You can specify a schedule for policy reporting and you can generate reports manually.
A policy report is generated for each site collection in a Web application. For each list and library, a report records:
• The number of items using each policy.
• For each policy in use, either based on a Site Collection policy or configured in a content type, a summary of that policy — its description, along with a description of each policy feature.
For more information about creating and deploying a custom Site Collection policy report, see the Deployment for Office SharePoint Server 2007 guide.
Top of page
About information management policy integration with the 2007 Office system applications
Office SharePoint Server 2007 information management policies are exposed in 2007 Office release clients. When you configure an information management policy on the server, you can write a policy statement that informs information workers about the policies that are enforced on documents. For example, the policy statement might indicate that a document will expire after a certain period of time, or that it is sensitive information that should not be communicated outside the company. The statement might even provide a contact name if the information worker needs more information about the policy.
The policies that are included in Office SharePoint Server 2007 are exposed to information workers through 2007 Office release client features. For example, when a label is defined as part of a policy, users can insert labels into documents from the Insert menu of most 2007 Office release client applications. If a label is required, users are prompted when saving documents in which a label has not been inserted. Similarly, users will be able to insert barcodes from client applications if that policy feature is part of the document's policy.
Custom policy features can also be integrated in 2007 Office release clients. However, you must implement policy-specific behaviors that you want to be available from 2007 Office release client programs, and you must give users a way to install these behaviors on their client computers via mechanisms such as add-ins to make them available from 2007 Office release client programs. For example, if you implement a custom policy feature that restricts the printers that can be used to print a content type, you must provide a custom add-in for Microsoft Office clients to enforce the restriction from Office client applications.
Top of page
Policy features available in Office SharePoint Server 2007
This section describes the policy features that are included in Office SharePoint Server 2007.
• Expiration The Expiration policy feature helps dispose of content in a consistent way that can be tracked and managed. You can set content of a specific type to expire on a particular date, or within a calculated amount of time after some document activity (such as creating the document).
• Auditing The Auditing policy feature logs events and operations performed on documents and list items. You can configure Auditing to log events such as:
• Editing a document or item
• Viewing a document or item
• Checking a document in or out
• Changing the permissions for a document or item
• Deleting a document or item

• Labeling The Labeling policy feature specifies a label to associate with a type of document or list item. Labels are searchable text areas that Office SharePoint Server 2007 generates based on properties and formatting that you specify. For example, in a law firm, a document related to a legal matter could include a label containing the clients' names, the case number, the attorney assigned to the matter, and so forth. Labels are particularly useful in printed versions of documents as a way to display document properties in printed copy. Along with using labels for documents, you can associate a label with a list item and include that label in views of the list.
• Barcode The Barcode policy feature enables you to track a document in physical copies by creating a unique identifier value for a document and inserting a barcode image of that value in the document. By default, barcodes are compliant with the common Code 39 standard (ANSI/AIM BC1-1995, Code 39), and you can plug in other barcode providers using the policies object model.
Top of page
Plan information management policies
When planning your solution's policies, first determine organization-wide policy needs, and then design Site Collection policies to meet those needs and distribute those policies for inclusion in all relevant site collections' Site Collection Policy galleries. This might require planning custom policy features. Note that, if your policy requires custom policy features and resources, those features and resources must be installed and enabled on all server farms on which your solution is used. See the Deployment for Office SharePoint Server 2007 guide for more information about deploying and enabling Office SharePoint Server 2007 features and resources.
A typical example of an organization-wide policy is one designed to promote best practices in auditing and expiring product specifications across the divisions of an organization. A single Site Collection policy is designed to be applied to all product specifications so that they are consistently audited and retained. After defining the Site Collection policy and testing it, it is exported and then imported to Site Collection Policy galleries of other site collections in which product specifications are stored. It is then associated with all product specification content types in the various site collections to impose the policy on all product specification documents.
Worksheet action
To help you plan information management policies, use the Policy worksheet (http://go.microsoft.com/fwlink/?LinkId=73307&clcid=0x409). Create a separate worksheet for each policy you are planning, and in each worksheet record:
• The purpose of the policy, such as "Policy to apply to all product specifications."
• The site collection in which the policy is being designed.
• The scope at which the policy is being defined. If the policy is to be used across multiple site collections, define it in the Policy Template gallery. Define a policy for a content type if the policy is more narrowly targeted to a single content type in a site collection.
• Each policy feature, such as "Expiration" or "Auditing." Optionally enter configuration notes for a policy feature. For example, for Auditing, you could specify which actions to audit, such as "Editing Items." If the feature is custom, list all resources that must be installed for the feature to work.
• All content types that the policy will be applied to and list all site collections in which the content types are in use.

Manage records by using Office SharePoint Server 2007 record management features
------------------------------------------------------------------------------------------------------------------------------------

Streamlining Records Management Using SharePoint Server 2007 Workflow
Published: December 2006
The Microsoft Legal and Corporate Affairs (LCA) Records Management team created an efficient inventory tracking solution that gives Microsoft employees easy access to physical records information and eliminates the need to handle inventory searches manually. Building on Microsoft® Office SharePoint® Server 2007 and Microsoft Office InfoPath® 2007, the new solution uses forms and workflows to automate the collection and management of inventory data. The results are enforced inventory through team-established business rules, increased accuracy of inventory data, and easy access to inventory information. These results enable the LCA Corporate Records Management team to more effectively manage document records.
Situation
The six-member LCA Corporate Records Management team at Microsoft is responsible for managing approximately 2 million container items that are stored within 200,000 boxes. In addition to handling legal records that must be stored for specified periods of time, the team handles a large number of boxes containing various work materials or project-related content that Microsoft employees provide for historical reference. Hard copies of these documents grow in volume by 30 percent annually, which makes keeping track of the content in every box, and the location of every box, a daunting task.
The team frequently receives inquiries from Microsoft employees who are interested in accessing content or who want to retrieve a box that is stored in the records storage facility. Although employees are required to capture information about the boxes and their respective content before sending that information to storage, the inventory lists for the boxes are often incomplete. In the past, this issue resulted in decreased productivity when the team needed to locate or recreate lost documents. To assist in the search for content, the team relied on a combination of inventory lists in hard copy, stand-alone spreadsheets, and documents often lying loosely on office shelves.
Obtaining accurate and consistent inventory lists, and ensuring document ownership, can be an expensive and time-consuming process. The time required to verify information and to ensure that source information is accurate and current increases the costs that are associated with records management. Additional costs accrue from re-creating data or confirming the accuracy of data that an employee has entered.
The team's previous inventory tracking system relied on three applications that were deployed in the mid-1980s and early 1990s. However, the code for this system had become increasingly difficult to maintain, and the system could not be scaled to meet present and future inventory tracking needs.
The team's previous records management system had a first-year cost of $90,000 U.S., and ongoing annual support and maintenance costs of approximately $70,000, much of which was associated with inefficient retrieval. The team managed company-wide inventory and tracking records by having employees record their inventory lists on stand-alone spreadsheets. However, because all container items are stored off-site, employees could not see the inventory within the boxes for which the inventory lists were being created. At some point, the employee would want to physically see the boxes, thereby requiring the team to arrange for the boxes to be delivered from the off-site storage location. If the inventory list happened to be inaccurate because an employee had previously removed an item, the entire process—which may have escalated to include other personnel involved in finding, and in some cases recreating, the missing document or documents—was a waste of valuable time. When expanded to a company-wide scope, managing information retrieval in this manner became a daunting challenge.
For these reasons, the team set out to create an efficient tracking solution that could take advantage of Microsoft technology and thereby improve the team's time-consuming, inefficient records management processes. The team sought a system that would also give employees access to records information, to alleviate the company-wide reliance on a six-person team to individually handle every records request.
Solution
By taking advantage of Office SharePoint Server 2007 and Office InfoPath 2007, the team created a new inventory tracking solution to standardize, manage, and increase the accuracy of electronic inventory lists. The new solution can scale to meet the company’s present and future document storage needs. The new solution also provides process workflows and effective search tools that support inventory queries and analysis. To update its records management and inventory tracking system, the team used server-based forms and workflows that Web browsers and smart client interfaces can access.
New features of Office SharePoint Server 2007, such as Records Center and SharePoint lists, provided the team with a simple and solid foundation for tracking inventory without the need for database deployment. Employees can simply access inventory lists via browser-enabled forms, which enforce inventory collection rules that ensure the completeness and accuracy of records. With easily administered SharePoint lists, users can simply create new service requests, add new users, or transfer ownership of content to another user. The Records Center feature itself has a feature called Litigation Hold, which properly identifies and safeguards materials that are needed for litigation. Through Microsoft Office Excel® 2007 integration, employees who work with numerous boxes can use spreadsheet management tools to keep track of the content in those boxes.
Out-of-the-box Office SharePoint Server 2007 search functionality supports queries against metadata, scanned images, and documents that are saved to the inventory lists of records boxes, extending the power of search to encompass more types of content. Additionally, by using the Office SharePoint Server 2007 extensibility framework, the team was able to easily customize and extend the functionality of Office SharePoint Server 2007 by integrating it with the Microsoft Visual Studio® 2005 development system. An example of this customized functionality is the ability to use Office SharePoint Server 2007 to perform mass updates of box ownership when employees change roles or leave the company.
The Office InfoPath 2007 information-gathering program is a robust forms solution development platform that the team easily integrated with Office SharePoint Server 2007 and Visual Studio 2005 to automate its records management business processes. The team used the Office InfoPath 2007 data validation, conditional formatting, connectivity, and other features to deploy efficient forms solutions without the need for additional programming development. For automated forms-driven business processes, the team relies on templates for administration and management, enabling employees of all skill levels to easily create and deploy electronic forms that reduce the amount of data reentry, while improving the quality and accuracy of the data collected. The integration of Office InfoPath 2007, InfoPath Forms Services, and Office SharePoint Server 2007 enables the team to also use Office InfoPath 2007 forms and workflows to automate inventory workflows and to apply business rules to ensure that the contents of each box are fully cataloged.
The team now has an integrated, extensible platform that provides control over the storage, security, distribution, and re-use of electronic content. When completing inventory list forms, employees can now build forms by using a simple drag-and-drop interface, with pre-built templates that include sophisticated data connectivity features. Automatic updates of published form templates now ensure that all employees are working with the most current version. Microsoft Office Word 2007 documents and Office Excel 2007 spreadsheets are converted to InfoPath form templates that enable data integrity, version control, and structure. The solution uses Office InfoPath 2007 Forms Services to deploy forms to mobile devices so that remote users can use Web browsers to complete the forms without installing Office InfoPath 2007.
The team's new solution implements many features that are available in Office SharePoint Server 2007, including the ability to attach labels and barcodes to items. The Records Center feature adds features that are particularly essential to an enterprise-wide records-keeping system, such as the implementation of document retention and document-holding processes.
Figure 1 shows the technologies and applications that make up the LCA Corporate Records Management application. The solution is implemented as a set of features that integrate with Office SharePoint Server 2007. The team deployed Office SharePoint Server 2007 with the following technologies: Microsoft Windows® SharePoint Services version 3.0, Internet Information Services (IIS) version 6.0, Microsoft SQL Server™ 2005, Windows Workflow Foundation, a programming model, a run-time engine, and tools for building workflow functionality into Microsoft .NET Framework version 3.0 applications, which enables the execution of the Office system workflows.

Figure 1. LCA Corporate Records Management application structure
LCA Corporate Records Management Solution Components
As shown in Figure 2, the new LCA Corporate Records Management solution implements four distinct applications, including the SharePoint Server 2007 Records Center Site, Kofax scanning, a conversion application, and a custom developed Handheld Barcode Reader application.

Figure 2. Components of the LCA Corporate Records Management solution
The LCA Corporate Records Management application is the main application in the LCA Records Management team solution. The application consists of customized Web Parts and Web Parts pages. The team uses the Office SharePoint Server 2007 object model to perform the operations.
Data Conversion
The purpose of the data conversion program is to transition the existing records management system to the new Office SharePoint Server 2007 lists. The data conversion program is a batch program that connects to the existing records management database, reads the raw data from tables, translates the data into the new LCA Corporate Records Management schema, and uses the Office SharePoint Server 2007 object model to insert the data into LCA Corporate Records Management lists. The data conversion program runs only once, after the program is installed on the same server on which Office SharePoint Server 2007 is installed. The purpose of the data conversion program is to convert existing data into a single Windows SharePoint Services list that is based on the LCA Corporate Records Management list schema that is used in Office SharePoint Server 2007.
Handheld Barcode Reader
The Handheld Barcode Reader application runs on a Windows Mobile® 2003–based device that has the Microsoft .NET Compact Framework version 2.0 installed. The Handheld Barcode Reader application accesses lists in the LCA Corporate Records Management application, and it reads and compares barcode values. The Handheld Barcode Reader application also caches list items, which enables the user to review and update inventory status via the application even when out of wireless local area network (WLAN) range. The .NET Compact Framework application interacts with the LCA Corporate Records Management solution via the Lists Web service in Windows SharePoint Services.
LCA Corporate Records Management Solution Infrastructure
The LCA Corporate Records Management solution uses a Web server farm configuration. The Web server farm is located in the extranet and is configured for corporate domain access as well as non-domain access. The farm consists of two servers that each have Office SharePoint Server 2007 installed. The Web farm servers host IIS, Microsoft ASP.NET version 2.0, Windows Workflow Foundation, Windows SharePoint Services 3.0, and the Office system.
Each server also runs Microsoft Windows Server® 2003 with Service Pack 1 (SP1), and each hosts the indexing and full-text search functionality of the Office system along with the Kofax scanning service. The main database server, within the Web server farm, runs SQL Server 2005 for the new records management system. The server running SQL Server is based on Windows Server 2003 SP1 and hosts all of the databases that Windows SharePoint Services and the Office system use. Everything in the LCA Corporate Records Management application runs on the .NET Framework or on the .NET Compact Framework.
The LCA Corporate Records Management solution takes advantage of the additional infrastructure that Office SharePoint Server 2007 and the Office system applications supported in the solution provide. The LCA Corporate Records Management user interface (UI) includes at least one custom Web Part page, which creates an HTML container to provide structure and consistent styles to individual Web Parts that support the LCA Corporate Records Management team's mass update actions. Web Parts are implemented within a framework that contains a set of controls that administrators can use to organize a portal Web page in a way that enables portal users to customize the appearance, content, and behavior of a Web site by using a Web browser. Changes the user makes are saved and are recalled for subsequent visits. Because the LCA Corporate Records Management solution is driven by metadata, business users can implement the functionality of Web Parts. This is accomplished by custom control components, developed as Web Parts that are embedded into the Web pages that support the Web Parts framework.
Search Page for Mass Updates
In the Office system, search terms called views (which include the formatting of results) can be created, edited, and saved by users. By using views, a content owner looking for information on the items in a records box can perform a full text search against the main off-site storage list.
To enable the search page for mass updates, the records box content owner creates a view that contains the search criteria that he or she saved with a unique file name. The content owner can assign the view with permissions to add a layer of protection over more sensitive data or content records. LCA Corporate Records Management team users also can create a new view, or they can modify an existing view by using different search criteria. The team can use search results to do a metadata search based on a variety of criteria, and it can perform actions on a selected list of items within a search results page.
Inventory list searches can display the results of a full text search and use the Search Core Results Web Part and the Form Web Part, both available out of the box in Office SharePoint Server 2007, to enable the user to select items from the results and send those items to the team as a check-out request.
As illustrated in Figure 3, a user goes to the LCA Corporate Records Management Web site and initiates a search. The user selects one or more returned items, and then starts the workflow. The team receives the request and activates it. Then, the LCA Corporate Records Management application automatically routes the request to the LCA courier, who puts the requested items onto the Courier List. The LCA courier physically retrieves the items from an off-site repository and delivers them to the user.

Figure 3. LCA Corporate Records Management workflow

During the pick-up or drop-off of the items, the LCA courier reads the container barcode, locates the task that is associated with the specific container or item, and then makes updates to the task status. This action triggers the workflow to perform the updates on the database record associated with that container or item, and sends notification to the team that the tasks have been completed. When a user initiates an instance of this workflow, the user can create one or more tasks for the team. Many items and containers may be involved, and the tasks may be distributed among staff. However, in order to avoid conflict, no two tasks can be simultaneously in progress for the same container.
Security
Windows NT Authentication is also employed so that anyone who has a network account in the Microsoft domain can access the LCA Corporate Records Management application. Different levels of user access are assigned, and user groups are defined as either Viewers or LCA Users, with varying permissions that are described as follows.
Viewers
The Viewers user group may contain any internal user who has an account in the Microsoft domain. By default, this user group has limited access and limited permissions assigned to it, but can access Web Parts that allow querying and submitting requests for information. Items that a specific Microsoft user within this group either owns, or for which the user is a contact, are visible to only that user. Only the owner or the contact of an item can check out or conduct a search against that item.
LCA Users
The LCA Users user group consists of multiple user groups that are defined by their respective roles within the overall LCA team, which enables the LCA Corporate Records Management team to control, at the group level, access to specific items. For example, items that belong to the Litigation user group are visible only to members of that user group. Currently, there are three LCA Users user groups:
• Human Resources, Immigration, and Litigation
• Members (the LCA Corporate Records Management team)
• Administrators (who have Full Control permission on the LCA Corporate Records Management portal)
Benefits
The new records management solution gives the LCA Corporate Records Management team an integrated, streamlined process for generating electronic inventory lists that are automatically updated. Business rules that are integrated into the solution ensure that inventory lists conform to those rules, thus eliminating costly errors. For example, checking for workflow rules, transposition errors, and relationships between elements can be defined within the inventory list rules. These integrated business rules provide a new level of precision for the team and improve the way inventory lists are produced.
Office SharePoint Server 2007 provides a distributed solution that simplifies mass updating of content ownership, thereby minimizing the administrative costs that were associated with the previous records management system. In addition, because the Office SharePoint 2007 lists are simple to maintain, the user can easily perform a variety of administrative tasks, such as opening a service request, adding a new user, or changing the owner of the data.
The estimated first-year cost for the new records management system is approximately $80,000, with annual support and maintenance costs expected to be approximately $15,000—a substantial cost savings over the previous records management system. The new system is expected to deliver a return of investment in less than two-and-a-half years. What really drives much of the cost is not the storage, but the retrieval of the documents. Enforcing accurate inventory control upon the submission of items to storage greatly reduces unnecessary retrieval, thereby saving time and resources.
Productivity has also been enhanced by giving employees direct access to content records and by reducing the misidentification of boxes. The accuracy of inventory was increased by using forms to automate the cataloging of box contents and workflows. Also, accessing documents by using new, metadata-based inventory searches has been expedited by enabling queries against scanned documents or images, and by exporting records to integrated server-based spreadsheets for quick analysis.
The new solution uses Office InfoPath 2007 and InfoPath Forms Services to pre-populate drop-down fields and Office SharePoint Server lists, helping to ensure the accuracy of entered information. The database is driven by business rules that are enforced within Office SharePoint Server 2007 and applied any time a user accesses the LCA Corporate Records Management application through their internet browser or the Office InfoPath 2007 client.
The key benefit of this solution is that the business rules are integrated into the server system that manages the application for the employees, and are therefore automatically incorporated when a user goes to the Office SharePoint Server 2007 Web site portal to update an inventory list. The new process eliminates the team's responsibility of maintaining company-wide, spreadsheet-based inventory lists. The inventory lists are now enforced with business rules, the accuracy of the lists is ensured, and the team can focus on more important tasks.
Conclusion
Through the creation of an efficient tracking solution, the LCA Corporate Records Management team has streamlined its records management processes. The solution has enhanced employees' productivity, applied business rules to ensure that the contents of each stored box are fully cataloged, increased the accuracy of its inventory, and provided expedited inventory searches, which enables more effective management of company records.

Integrating Business Data with Office SharePoint Server 2007 by Using the Business Data Catalog (BDC)
-------------------------------------------------------------------------

Configure the Office SharePoint Server Search service (Office SharePoint Server)
Updated: February 28, 2007
In this article:
• Server-level configuration

• Farm-level configuration

• SSP-level configuration

• Site collection-level configuration

This article describes the process of deploying the search features for Microsoft Office SharePoint Server 2007 that are related to crawling content. If you have not already done so, we highly recommend that you first read the topics described in Chapter overview: Plan search (Office SharePoint Server) and fill out the companion Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkID=73748&clcid=0x409). As you proceed through this article, refer to this worksheet so that you have the information you need to configure these search features.
Server-level configuration
The procedures in this section are performed at the server level. To perform these procedures, you must be a member of the Administrators group for each server on which you want to perform them.
Install protocol handlers
The following protocols are supported by the default protocol handlers:
• bdc
• bdc2
• file
• http
• https
• rb
• rbs
• sps
• sps3
• sps3s
• spsimport
• spss
• sts
• sts2
• sts2s
• sts3
• sts3s
Refer to the Protocol handlers section of the Plan to crawl content worksheet to review your decisions for installing additional protocol handlers. When installing the protocol handlers on your index server, follow the appropriate installation instructions provided by the manufacturer of each protocol handler.
Note:
You must be a member of the Administrators group on each server on which you want to install an additional protocol handler.
Install and register IFilters
The procedures used to install and register IFilters vary among different IFilters. Refer to the File type inclusions section of the Plan to crawl content worksheet for the IFilters you decided to add.
This section includes instructions for installing and registering the following IFilters. If an IFilter that you need is not listed here, contact the manufacturer for instructions for installing third-party IFilters. If you do not need to install additional IFilters, skip to the next section.
Note:
You must be a member of the Administrators group on each server on which you want to install an IFilter.
Install and register the OneNote IFilter
Before Microsoft Office OneNote 2007 files can be crawled and indexed, you must first do the following:
• Install Office OneNote 2007 on the index server. This installs the OneNote IFilter.
Note:
The Office OneNote 2007 IFilter can crawl both OneNote 2003 and Office OneNote 2007 files. The Office OneNote 2003 IFilter can crawl OneNote 2003 files only.

• Add the OneNote file extension to the File Types list.
• Register the OneNote IFilter.
Note:
You must be a member of the Administrators group on the index server to perform the following procedures.

Add the OneNote file extension to the File Types list
1. Open the administration page for the Shared Services Provider (SSP).
To open the administration page for the SSP, do the following:
1. In Central Administration, on the top link bar, click Application Management.
2. On the Application Management page, in the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.
3. On the Manage this Farm's Shared Services page, click the SSP for which you want to open the administration page.

2. On the Shared Services Administration page, in the Search section, click Search settings.
3. On the Configure Search Settings page, in the Crawl Settings section, click File Types.
4. On the Manage File Types page, click New File Type.
5. On the Add File Type page, in the File extension box, type one, and then click OK.
Note:
Do not type the period character "." before the file extension.

Register the OneNote IFilter
1. On the index server, click Start, and then click Run.
2. In the Open box, type notepad, and then click OK.
3. Type or copy the following text into Notepad:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\Filters\.one]
"Extension"="one"
"FileTypeBucket"=dword:00000001
"MimeTypes"="application/msonenote"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.one]
@="{B8D12492-CE0F-40AD-83EA-099A03D493F1}"
4. In Notepad, on the File menu, click Save As.
5. In the Save As dialog box, in the File name box, type onenote.reg, and then click Save.
6. On the index server, double-click the onenote.reg file that you just created.
Note:
This step starts the process of setting the necessary registry keys for registering the OneNote IFilter.

7. If the Open File - Security Warning dialog box appears, click Run.
8. In the Registry Editor dialog box, click Yes.
9. Click OK to close the Registry Editor box.
10. Restart the index server.
Note:
The index server must be restarted for the IFilter registration to take effect.

After you restart the index server, you must start a full crawl of the locations that contain Office OneNote 2007 files before they can appear in search queries. If your document libraries require check-out to edit the files, Office OneNote 2007 files will often be in checked-out state. Any updates to the checked-out files that are saved to the library will not be crawled until the files are checked in. In general, we recommend that administrators do not require that files be checked out before they can be edited for document libraries that are intended for storing OneNote files.
Top of page
Farm-level configuration
The procedures in this section are performed at the farm level. To perform these procedures, you must be a farm administrator.
Create crawler impact rules
Use the following procedure, along with the decisions you recorded in the Crawler impact rules section of the Plan to crawl content worksheet, to create crawler impact rules.
Create crawler impact rules
1. In Central Administration, on the Application Management tab, in the Search section, click Manage search service.
2. On the Manage Search Service page, in the Farm-Level Search Settings section, click Crawler impact rules.
3. On the Crawler Impact Rules page, click Add Rule.
4. On the Add Crawler Impact Rule page, in the Site section, in the Site box, type the site name that will be associated with this crawler impact rule.
Note:
When typing the URL, you must exclude the protocol. For example, do not include http:// or file://.

5. In the Request Frequency section, select one of the following options:
• Request up to the specified number of documents at a time and do not wait between requests. If you choose this option, use the Simultaneous requests list to select how many documents you want the crawler to request at one time when crawling this URL. You can specify the maximum number of requests that the Office SharePoint Services Search service can make at one time when crawling this URL.
• Request one document at a time and wait the specified time between requests. You can specify a delay (in seconds) between requests, when crawling this URL. When this option is selected, the Office SharePoint Services Search service makes one request per site at one time, and then it waits for the specified amount of time before making the next request. In the Time to wait (in seconds) box, type the time to wait (in seconds) between requests. The minimum time to wait between requests is one second, and the maximum time is 1,000 seconds.

6. Click OK.

Configure farm-level search settings
Use the following procedure, along with the decisions you recorded in the Farm-level search settings section of the Plan to crawl content worksheet, to configure your farm-level search settings.
Configure farm-level search settings
1. In Central Administration, on the Application Management tab, in the Search section, click Manage search service.
2. On the Manage Search Service page, in the Farm-Level Search Settings section, click Farm-level search settings.
3. On the Manage Farm-Level Search Settings page, in the Contact E-mail Addresses section, type the e-mail address of the person in your organization whom external site administrators can contact if problems arise when their site is being crawled.
4. In the Proxy Server Settings section, if you want to use a proxy server when crawling, select Use the proxy server specified and then do the following:
• In the Address box, enter either the NetBIOS name or the IP address of the proxy server.
• In the Port box, type the port to use for this proxy server.
• To bypass this proxy server when crawling local addresses, select the Bypass proxy server for local (intranet) addresses check box.
• To specify addresses for which to bypass the proxy server when crawling, enter those addresses in the Do not use proxy server for addresses beginning with box.

5. In the Timeout Settings section, do the following:
• In the Connection time (in seconds) box, enter the number of seconds you want the server to wait while connecting to other services.
• In the Request acknowledgement time (in seconds) box, enter the number of seconds you want the server to wait for another service to acknowledge a request to connect to that service.

6. In the SSL Certificate Warning Configuration section, select the Ignore SSL certificate name warnings check box if you want to trust that sites are legitimate even if their certificate names are not exact matches. Otherwise, ensure that this check box is unselected.
7. Click OK.

Configure the trace log
The trace log can be very useful for analyzing problems that may occur. Events that are written to the trace log are especially helpful because you can use them to determine what configuration changes where made in Office SharePoint Server 2007 before the problem occurred.
By default, Office SharePoint Server 2007 saves two days of events in the trace log files. This means that trace log files that contain events that are older than two days are deleted. When you are using either the Office SharePoint Server Search service or the Windows SharePoint Services Search service, we recommend that you configure the trace log to save seven days of events.
You can use the Diagnostic Logging page in Central Administration to configure the maximum number of trace log files to maintain and how long (in minutes) to capture events to each log file. By default, 96 log files are kept, each one containing 30 minutes of events.
96 log files * 30 minutes of events per file = 2880 minutes or two days of events.
You can also specify the location where the log files are written or accept the default path.
Configure the trace log to save seven days of events
1. In Central Administration, on the Operations tab, in the Logging and Reporting section, click Diagnostic logging.
2. On the Diagnostic Logging page, in the Trace Log section, do the following:
• In the Number of log files box, type 336.
• In the Number of minutes to use a log file box, type 30.
Tip:
You can use any combination of number of log files and minutes to store in each log file you want to achieve 10,080 minutes (seven days) of events.

3. Ensure that the path specified in the Path box has enough room to store the extra log files, or change the path to another location.
Tip:
We recommend that you store log files on a hard drive partition that is used to store log files only.

4. Click OK.

Trace log files are invaluable for troubleshooting issues related to configuration changes of either the Office SharePoint Server Search service or the Windows SharePoint Services Search service. Because problems related to configuration changes are not always discovered right away, we recommend that you save all trace log files that the system creates on any day that you make any configuration changes related to either search service. Store these log files for an extended period of time in a safe location that will not be overwritten. See step 3 in the procedure above to determine the location where the system stores trace log files for your system.

Programmatically enhance the search service.
-----------------------------------------------------------------------------

SSP-level configuration
The procedures in this section are performed at the Shared Services Provider (SSP) level. To perform these procedures, you must be an SSP administrator for Search.
Open the administration page for the SSP
Use the following procedure to open the administration page for the SSP that you want to configure.
Open the administration page for the SSP
1. In Central Administration, on the top link bar, click Application Management.
2. On the Application Management page, in the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.
3. On the Manage this Farm's Shared Services page, click the SSP for which you want to open the administration page.

Specify the default content access account
Use the following procedure, along with the decision you recorded in the Default content access account section of the Plan to crawl content worksheet, to specify the content access account that the crawler will use, by default, when crawling content.
Specify the default content access account
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl settings section, click Default content access account.
3. On the Default Content Access Account page, in the Account box, type the domain and user name for the account (in the form domain\username).
4. In the Password and Confirm Password boxes, type the password for the account.
5. Click OK.

Create content sources
Use the following procedure, along with the decisions you recorded in the Content sources section of the Plan to crawl content worksheet, to create your content sources.
Use the following procedure to create a content source of any of the following content source types:
• SharePoint sites
• Web sites
• File shares
• Microsoft Exchange public folders
Create content sources
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.
3. On the Manage Content Sources page, click New Content Source.
4. On the Add Content Source page, in the Name section, in the Name box, type a name for the content source.
Note:
Each content source name must be unique within the SSP in which it is created.

5. In the Content Source Type section, select the type of content you want to crawl by using this content source.
6. In the Start Addresses section, in the Type start addresses below (one per line) box, type the URLs from which the search system should start crawling.
Note:
For performance reasons, you cannot add the same start addresses to multiple content sources.

7. In the Crawl Settings section, select the behavior for the type of content you selected.
8. In the Crawl Schedules section, you can specify when to start full and incremental crawls.
• You can create a full crawl schedule by clicking the Create Schedule link below the Full Crawl list.
• You can create an incremental crawl schedule by clicking the Create Schedule link below the Incremental Crawl list.

9. Click OK.
10. Repeat steps 4 through 10 for any additional content sources you want to create.

Use the following procedure to create a content source of the business data content source type.
Create content source for business data
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.
3. On the Manage Content Sources page, click New Content Source.
4. On the Add Content Source page, in the Name section, in the Name box, type a name for the content source.
Note:
Each content source name must be unique within the SSP in which it is created.

5. In the Content Source Type section, select Business Data.
6. In the Applications section, select Crawl entire Business Data Catalog to crawl all applications registered in the Business Data Catalog or select Crawl selected applications and select the specific applications you want to crawl.
7. In the Crawl Schedules section, you can specify when to start full and incremental crawls.
• You can create a full crawl schedule by clicking the Create Schedule link below the Full Crawl list.
• You can create an incremental crawl schedule by clicking the Create Schedule link below the Incremental Crawl list.

8. Click OK.
9. Repeat steps 4 through 9 for any additional content sources you want to create.

Create crawl rules
Use the following procedure, along with the decisions you recorded in the Crawl rules section of the Plan to crawl content worksheet, to create crawl rules.
Create crawl rules
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl Settings section, click Crawl rules.
3. On the Manage Crawl Rules page, click New Crawl Rule.
4. On the Add Crawl Rule page, in the Path section, in the Path box, type the path affected by this rule. You can use standard wildcard characters in the path. For example:
• http://server1/folder* contains all Web resources with a URL that starts with http://server1/folder.
• *://*.txt includes every document with the txt file extension.

5. In the Crawl Configuration section, select one of the following:
• Exclude all items in this path. Select this option if you want all items in the specified path to be excluded from the crawl.
• Include all items in this path. Select this option if you want all items in the path to be crawled.

6. If you chose to exclude all items in this path, skip to step 8. Otherwise, you can further refine the inclusion by selecting any combination of the following:
• Follow links on the URL without crawling the URL itself. Select this option if you want to crawl links contained within the URL, but not the URL itself.
• Crawl complex URLs (URLs that contain a question mark (?)). Select this option if you want to crawl URLs that contain parameters that use the question mark (?) notation.
• Crawl SharePoint content as HTTP pages. Normally, SharePoint content is crawled by using a special protocol. Select this option if you want SharePoint content to be crawled as HTTP pages instead. When the content is crawled by using the HTTP protocol, item permissions are not stored.

7. In the Specify Authentication section, do one of the following:
• To use the default content access account when crawling URLs affected by this crawl rule, select Use the default content access account.
• If you want to use a different content access account, select Specify a different content access account, and then do the following:
In the Account box, type the account name that can access the paths defined by this crawl rule. Examples are user_name and DOMAIN\user_name.
In the Password and Confirm Password boxes, type the password for this account.
If you want to prevent basic authentication from being used, select the Do not allow Basic Authentication check box.
• To use a client certificate for authentication, select Specify client certificate, and then click a certificate on the Certificate menu.

8. Click OK.
9. Repeat steps 4 through 8 for each new crawl rule you want to create.

Reorder your crawl rules
After you create all your crawl rules, we recommend that you specify the order in which you want the rules to be applied while content is being crawled. Crawl rules are applied in the order in which they are listed. Therefore, if two rules cover the same or overlapping content, the first rule that is listed is applied. Use the following procedure to specify the order of your crawl rules.
Reorder crawl rules
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl Settings section, click Crawl rules.
3. On the Manage Crawl Rules page, in the Order column in the list of crawl rules, select a value in the drop-down list that specifies the position you want the rule to occupy. Other values are shifted accordingly.

Configure the file type inclusions list
Use the following procedure, along with the decisions that you recorded in the File-type inclusions section of the Plan to crawl content worksheet, to add file types from the file type inclusions list.
Add file types
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl Settings section, click File types.
3. On the Manage File Types page, click New File Type.
4. On the Add File Type page, in the File extension box, type the file name extension for the file type that you want to add (for example, type doc).
Note:
Do not precede the file type with the period "." character.

5. Click OK.
6. Repeat steps 4 through 7 for any other file types you want to add.

You can also delete file types from this list for the file types you don't want the crawler to include in the content index. Use the following procedure, along with the decisions you recorded in the File-type inclusions section of the Plan to crawl content worksheet, to delete file types from the file type inclusions list.
Delete file types
1. On the Manage File Types page, position the cursor over the file name extension that you want to delete, and then click Delete on the menu that appears.
2. In the message box, click OK to confirm that you want to delete the file type.

Crawl the content
Before the content can be indexed, you must first crawl the content. You can either crawl the content defined in a particular content source individually, or crawl all the content specified by all content sources at one time.
Crawl content defined in a particular content source
Use the following procedure to crawl content defined in a particular content source.
Crawl content defined in a particular content source
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.
3. On the Manage Content Sources page, position the cursor over the content source you want to crawl, and then click Start full crawl on the menu that appears.

Crawl content specified by all content sources
Use the following procedure to crawl content specified by all content sources.
Crawl content specified by all content sources
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.
3. On the Manage Content Sources page, in the Quick Launch, click Start all crawls.

Create managed properties
Use the following procedure, along with the decisions you recorded in the Plan managed properties section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to create managed properties.
Create managed properties
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl Settings section, click Metadata property mappings.
3. On the Metadata Property Mappings page, click New Managed Property.
4. On the New Managed Property page, in the Name and type section, in the Property name box, type the name of the managed property you want to create.
5. In the Description box, type a description for this managed property.
6. Under The type of information in this property, select a property type.
7. In the Mappings to crawled properties section, select one of the following:
• Include values from all crawled properties mapped. Select this option if you want values from all crawled properties to be mapped. A query for a property in a document in which all crawled properties are mapped returns a result if any of the crawled properties that are mapped match the query.
• Include values from a single crawled property based on the order specified. Select this option if you want only a single value mapped. When multiple crawled properties are mapped to a managed property, the one that is chosen will be the first in the list that has a value for a given document. You can reorder the list by using the Move up and Move down buttons.

8. If you selected Include values from all crawled properties mapped, skip to step 12.
9. Click Add Mapping to add a mapping to the list.
10. The Crawled property selection dialog box appears. Configure the settings as follows:
1. On the Select a category menu, click either All categories or a specific type of document category (for example, Office or SharePoint).
2. In Select a crawled property, select a crawled property to map to the managed property that you are adding.
Because the list of crawled properties is likely to be long, you can type the name (or the first part of the name) of the property that you are looking for in the Crawled property name box and then click Find.
3. Click OK.

11. Repeat steps 9 through 10 for each additional crawled property that you want to map to this managed property.
12. On the New Managed Property page, in the Use in scopes section, select the Allow this property to be used in scopes check box if you want this managed property to be available for defining scopes.
13. Click OK.
Note:
Changes to the property mappings take effect on a document-by-document basis as soon as a document is crawled, regardless of the type of the crawl. A full crawl ensures that the changes are consistently applied to the entire index.

Create shared scopes
Use the following procedure, along with the decisions you recorded in the Plan scopes section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to create shared scopes.
Create shared scopes
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Scopes section, click View scopes.
3. On the View Scopes page, click New Scope.
4. On the Create Scope page, in the Title and Description section, in the Title box, type a title for the scope.
5. In the Description box, type a description for the scope that informs administrators what the purpose of the scope is.
Note:
These descriptions are not visible to users.

6. Your credentials are automatically entered in the read-only Last modified by box.
Note:
Last modified by settings are not visible to users.

7. In the Target Results Page section, select one of the following:
• Use the default Search Results Page. Select this option if you want search results from this scope to be presented by using the standard Search Results page.
• Specify a different page for searching this scope. Select this option if you want search results from this scope to be presented on a custom page. If you select this option, type the URL for the custom Search Results page in the Target results page box.

8. Click OK.

Create scope rules
Use the following procedure, along with the decisions you recorded in the Plan scopes section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to create scope rules.
The following table describes the four scope rule types that you can choose from when creating a scope rule. For simplicity, a separate procedure is provided for each scope rule type.
Scope rule type Purpose
Web address Select this option if you want the scope to include or exclude content from any resource in the search index that can be identified either by a URL (such as Web sites, file shares, and Exchange public folders) or by a host name, domain name, or subdomain name.
• Folder. Select this option if you want to include or exclude items in the folder and subfolders of the indicated URL (for example, http://site/subsite/folder).
• Hostname. Select this option if you want to specify a host name. All items in the host name will be included or excluded from the scope (according to the behavior rules).
• Domain or subdomain. Select this option if you want to specify a domain or subdomain (for example, widgets.contoso.com). All items in the domain or subdomain will be included in or excluded from the scope.

Property query Select this option if you want the scope to include or exclude content that has a managed property with a particular value. For example, Author="John Doe".
Content source Select this option if you want the scope to include or exclude content that was crawled by using a particular content source.
All content Select this option if the rule should not restrict the scope (the scope will include or exclude all content in the search index).
Use the following procedure to open the Add Scope Rule page.
Open the Add Scope Rule page
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Scopes section, click View scopes.
3. On the View Scopes page, position the cursor over the scope that you want to edit, click the arrow that appears, and then click Edit Properties and Rules on the menu that appears.
4. On the Scope Properties and Rules page, in the Rules section, click New rule.

Use the following procedure to create scope rules by using the Web address scope rule type.
Create scope rules by using the Web address scope rule type
1. On the Add Scope Rule page, in the Scope Rule Type section, select Web Address.
2. In the Web Address section, select one of the following options and provide the address you want to associate with this rule:
• Folder. Select this option if you want to include or exclude items in the folder and subfolders of the indicated URL (for example, http://site/subsite/folder).
• Hostname. Select this option if you want to specify a host name. All items in the host name will be included or excluded from the scope (according to the behavior rules).
• Domain or subdomain. Select this option if you want to specify a domain or subdomain (for example, widgets.contoso.com). All items in the domain or subdomain will be included in or excluded from the scope.

3. In the Behavior section, select one of the following options:
• Include. Select this option if you want the rule to be applied (if another rule precludes its inclusion, it won't be included). The Include option is analogous to the logical operator AND.
• Require. Select this option if you want the rule to be applied regardless of other rules. The Require option is analogous to the logical operator OR.
• Exclude. Select this option if you want items that match this rule to be excluded from the scope. The Exclude option is analogous to the logical operator AND NOT.

4. Click OK.

Use the following procedure to create scope rules by using the Property query scope rule type.
Create scope rules by using the Property query scope rule type
1. On the Add Scope Rule page, in the Scope Rule Type section, select Property Query.
2. In the Property Query section, select the managed property that you want to use to limit the scope from the Add property restrictions menu.
3. In the = box, type the string (value) that the managed property needs to match.
4. In the Behavior section, select one of the following options:
• Include. Select this option if you want the rule to be applied (if another rule precludes its inclusion, it won't be included). The Include option is analogous to the logical operator AND.
• Require. Select this option if you want the rule to be applied regardless of other rules. The Require option is analogous to the logical operator OR.
• Exclude. Select this option if you want items that match this rule to be excluded from the scope. The Exclude option is analogous to the logical operator AND NOT.

5. Click OK.

Use the following procedure to create scope rules by using the Content source scope rule type.
Create scope rules by using the Content source scope rule type
1. On the Add Scope Rule page, in the Scope Rule Type section, select Content source.
2. In the Content Source section, in the corresponding menu, select the content source from the list that you want to associate with this rule.
3. In the Behavior section, select one of the following options:
• Include. Select this option if you want the rule to be applied (if another rule precludes its inclusion, it won't be included). The Include option is analogous to the logical operator AND.
• Require. Select this option if you want the rule to be applied regardless of other rules. The Require option is analogous to the logical operator OR.
• Exclude. Select this option if you want items that match this rule to be excluded from the scope. The Exclude option is analogous to the logical operator AND NOT.

4. Click OK.

Use the following procedure to create scope rules by using the All content scope rule type.
Create scope rules by using the All content scope rule type
1. On the Add Scope Rule page, in the Scope Rule Type section, select All Content.
2. Click OK.

Specify authoritative pages
Use the following procedure, along with the decisions you recorded in the Authoritative pages section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to specify authoritative pages.
Specify authoritative pages
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Authoritative Pages section, click Specify authoritative pages.
3. On the Specify Authoritative Pages page, in the Authoritative Web Pages section, in the Most authoritative pages box, list the URLs that are central or authoritative.
Note:
Separate the URLs by hard returns so that you list one full URL per line.

4. In the Second-level authoritative pages box, list the URLs that are secondary.
5. In the Third-level authoritative pages box, list the URLs that are tertiary.
6. In the Non-authoritative Sites section, in the Sites to demote box, list the URLs that you want to mark as unimportant when search results are returned (for example, URLs of sites that contain outdated information but are kept for record-keeping).
Note:
Any URL or item whose prefix matches the provided URLs in the Sites to demote box is demoted.

7. If you want the ranking calculations to begin after you click OK, in the Refresh Now section, select the Refresh now check box. If the check box is cleared, ranking calculations occur according to a predetermined schedule.
8. Click OK.

Create server name mappings
Use the following procedure, along with the decisions you recorded in the Server name mappings section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to specify server name mappings.
Specify server name mappings
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl Settings section, click Server name mappings.
3. On the Server Name Mappings page, click New Mapping.
4. On the Add Server Name Mapping page, in the Address in index box, type the address for the crawled content.
5. In the Address in search results box, type the address that you want users to see on the Search Results page when they receive query results for the address you typed in the Address in index box.
6. Click OK.

Manage search-based alerts
Search-based alerts are active, by default. However, you can deactivate them. Refer to the decision you recorded in the Search-based alerts section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), and do the following steps if you want to deactivate search-based alerts.
Deactivate search-based alerts
1. On the Shared Services Administration page, in the Search section, click Search settings.
2. On the Configure Search Settings page, in the Crawl Settings section, click Search-based alerts.
3. On the Configure Search-based Alerts page, click Deactivate.

Top of page
Site collection–level configuration
The procedures in this section are performed at the site collection level. To perform these procedures, you must be a site collection administrator for the site collection on which you want to perform them.
Create scopes at the site collection level
Site collection administrators can choose to use scopes that were created at the SSP level, copy scopes that were created at the SSP level and modify them, or create new site collection level scopes.
Use the following procedure, along with the decisions you recorded in the Site-collection level scopes section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to copy shared scopes at the site collection level.
Copy shared scopes
1. On the top-level site of the site collection on which you want to create a scope, click Site actions, point to Site Settings, and then click Modify All Site Settings.
2. On the Site Settings page, in the Site Collection Administration section, click Search scopes.
3. On the View Scopes page, position the cursor over the name of the shared scope you want to copy, and then click Make Copy on the menu that appears.
Note:
The copy of the shared scope appears in the Unused Scopes section of the View Scopes page.

Use the following procedure, along with the decisions you recorded in the Site-collection level scopes section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to create scopes at the site collection level.
Create scopes at the site collection level
1. On the top-level site of the site collection on which you want to create a scope, click Site actions, point to Site Settings, and then click Modify All Site Settings.
2. On the Site Settings page, in the Site Collection Administration section, click Search scopes.
3. On the View Scopes page, click New Scope.
4. On the Create Scope page, in the Title and Description section, type a brief title for the scope that will best explain it to your users. You can also type a fuller description for reference by site administrators.
5. Ignore the Display Groups section for now. We will assign display groups to scopes later in this article.
6. In the Target Results Page section, select one of the following:
• Use the default Search Results Page. Select this option if you want search results from this scope to be presented by using the standard Search Results page.
• Specify a different page for searching this scope. Select this option if you want search results from this scope to be presented on a custom page. If you select this option, type the URL for the custom Search Results page in the Target results page box.

7. Click OK.

Create scope rules at the site collection level
Use the following procedure, along with the decisions you recorded in the Site-collection level scopes section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to create scope rules.
The following table describes the scope rule types that you can choose from when creating a site-collection level scope rule. For simplicity, a separate procedure is provided for each scope rule type.
Scope rule type Purpose
Web address Select this option if you want the scope to include or exclude content from any resource in the search index that can be identified either by a URL (such as Web sites, file shares, and Exchange public folders) or by a host name, domain name, or subdomain name.
• Folder. Select this option if you want to include or exclude items in the folder and subfolders of the indicated URL (for example, http://site/subsite/folder).
• Hostname. Select this option if you want to specify a host name. All items in the host name will be included or excluded from the scope (according to the behavior rules).
• Domain or subdomain. Select this option if you want to specify a domain or subdomain (for example, widgets.contoso.com). All items in the domain or subdomain will be included in or excluded from the scope.

Property query Select this option if you want the scope to include or exclude content that has a managed property with a particular value. For example, Author="John Doe".
All content Select this option if the rule should not restrict the scope (the scope will include or exclude all content in the search index).
Use the following procedure to open the Add Scope Rule page.
Open the Add Scope Rule page
1. On the top-level site of the site collection on which you want to create a scope rule, click Site actions, point to Site Settings, and then click Modify All Site Settings.
2. On the Site Settings page, in the Site Collection Administration section, click Search scopes.
3. On the View Scopes page, position the cursor over the scope that you want to edit, click the arrow that appears, and then click Edit Properties and Rules on the menu that appears.
Note:
You cannot add scope rules to shared scopes at the site collection level.

4. On the Scope Properties and Rules page, in the Rules section, click New rule.

Use the following procedure to create scope rules by using the Web address scope rule type.
Create scope rules by using the Web address scope rule type
1. On the Add Scope Rule page, in the Scope Rule Type section, select Web Address.
2. In the Web Address section, select one of the following options and provide the address you want to associate with this rule:
• Folder. Select this option if you want to include or exclude items in the folder and subfolders of the indicated URL (for example, http://site/subsite/folder).
• Hostname. Select this option if you want to specify a host name. All items in the host name will be included or excluded from the scope (according to the behavior rules).
• Domain or subdomain. Select this option if you want to specify a domain or subdomain (for example, widgets.contoso.com). All items in the domain or subdomain will be included in or excluded from the scope.

3. In the Behavior section, select one of the following options:
• Include. Select this option if you want the rule to be applied (if another rule precludes its inclusion, it won't be included). The Include option is analogous to the logical operator AND.
• Require. Select this option if you want the rule to be applied regardless of other rules. The Require option is analogous to the logical operator OR.
• Exclude. Select this option if you want items that match this rule to be excluded from the scope. The Exclude option is analogous to the logical operator AND NOT.

4. Click OK.

Use the following procedure to create scope rules by using the Property Query scope rule type.
Create scope rules by using the Property Query scope rule type
1. On the Add Scope Rule page, in the Scope Rule Type section, select Property Query.
2. In the Property Query section, select the managed property that you want to use to limit the scope from the Add property restrictions list.
3. In the = box, type the string (value) that the managed property needs to match.
4. In the Behavior section, select one of the following options:
• Include. Select this option if you want the rule to be applied (if another rule precludes its inclusion, it won't be included). The Include option is analogous to the logical operator AND.
• Require. Select this option if you want the rule to be applied regardless of other rules. The Require option is analogous to the logical operator OR.
• Exclude. Select this option if you want items that match this rule to be excluded from the scope. The Exclude option is analogous to the logical operator AND NOT.

5. Click OK.

Use the following procedure to create scope rules by using the All content scope rule type.
Create scope rules by using the All content scope rule type
1. On the Add Scope Rule page, in the Scope Rule Type section, select All Content.
2. Click OK.

Manage display groups
To support a customized search experience, you can set up new display groups with which to associate your scopes, and you can assign scopes to the default display groups. Site administrators can also control the order in which scopes appear within a particular display group. After you create a display group, designers can modify the Search Box Web Part to display it.
Create a new display group
Use the following procedure, along with the decisions you recorded in the Display groups section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to create display groups at the site collection level and to assign the scopes you want to them.
Create display groups
1. On the top-level site of the site collection on which you want to create a display group, click Site actions, point to Site Settings, and then click Modify All Site Settings.
2. On the Site Settings page, in the Site Collection Administration section, click Search scopes.
3. On the View Scopes page, click New Display Group.
4. On the Create Scope Display Group page, type a title and description that easily identifies the purpose of the group.
5. In the Scopes section, select the check box next to each scope that you want to include in this display group. You can manage the ordering of the scopes in the group by using the Position from Top lists.
6. In the Default Scope section, in the Default Scope list, select the scope that you want to be applied if users do not make a choice on their own.
7. Click OK.

Assign scopes to default display groups
Use the following procedure, along with the decisions you recorded in the Display groups section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to assign scopes to the default Search Drop-down and Advanced Search display groups.
Assign scopes to default display groups
1. On the top-level site of the site collection on which you want to assign scopes, click Site actions, point to Site Settings, and then click Modify All Site Settings.
2. On the Site Settings page, in the Site Collection Administration section, click Search scopes.
3. On the View Scopes page, in the Title column, click Search Dropdown.
4. On the Edit Scope Display Group page, in the Scopes section, select the check boxes for the scopes you want to be included in this display group, and clear the check boxes for the scopes you want to remove from this display group.
5. Optionally use the Position from Top lists to specify the order in which the scopes will appear to the user for this display group.
6. Click OK.
7. On the View Scopes page, in the Title column, click Advanced Search.
8. On the Edit Scope Display Group page, in the Scopes section, select the check boxes for the scopes you want to be included in this display group, and clear the check boxes for the scopes you want to remove from this display group.
9. Optionally use the Position from Top lists to specify the order in which the scopes will appear to the user for this display group.
10. Click OK.

Modify the Search Box Web Part for a new display group
Use the following procedure to modify the Search Box Web Part for a new display group.
Modify the Search Box Web Part for a new display group
1. Go to the Search Center page on the site collection on which you want to modify the Search Box Web Part.
2. Click Site actions, and then click Edit Page.
3. In the search box, click Edit, and then click Modify Shared Web Part.
4. In the Search Box tool pane, click the plus sign (+) next to Miscellaneous.
5. In the Scope Display Group text box, type the name of the display group that you want to use, and then click Apply.
6. Click OK to close the tool pane.
7. On the Search Center page, click either Publish or Check In to Share Draft, depending on your site permissions and workflow.

Create keywords and Best Bets
Search keywords and Best Bets enable you to provide two important features to help your users get the search results they need:
• Search keywords enable you to create a glossary of important terms within your organization. When a user types the keyword in a search query, the definition that has been created for that keyword is displayed at the top of the Search Results page.
• Best Bets enable you to prominently present editorially selected search results. Best Bets are URLs to pages, documents, or external Web sites that you associate with particular search keywords. When a user types a keyword in a search query that has one or more Best Bets, the Search Results page prominently displays the Best Bet URLs, including the title and description of each one.
Best Bets are most helpful in situations in which a site administrator wants to promote specific pages. Because the Best Bet URLs are displayed prominently on the Search Results page, end users may be more inclined to view them.
Use the following procedure, along with the decisions you recorded in the Keywords and Best Bets section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409), to create keywords and Best Bets.
Create keywords and Best Bets
1. On the top-level site of the site collection on which you want to create keywords and Best Bets, click Site actions, point to Site Settings, and then click Modify All Site Settings.
2. On the Site Settings page, in the Site Collection Administration section, click Search keywords.
3. On the Manage Keywords page, click Add Keyword.
4. On the Add Keyword page, in the Keyword Information section, in the Keyword Phrase box, type the keyword phrase you want to create.
5. In the Synonyms box, type the synonyms you want to associate with this keyword phrase. You can type more than one synonym by separating them with semicolons.
6. If you want to associate a Best Bet with this keyword, in the Best Bets section, click Add Best Bet. Otherwise, skip to step 13.
7. If this is the first Best Bet you will create on this site collection, skip to step 9. Otherwise, in the Add Best Bet dialog box, do one of the following:
• To create a new Best Bet, select Add new best bet and then skip to step 9.
• To select an existing Best Bet, select Select existing best bet, click the Best Bet you want from the Select best bets from the list below box, and then click OK. Skip to step 13.

8. In the URL box, type the URL you want to associate with this Best Bet.
9. In the Title box, type the title you want to associate with this Best Bet. This title appears in the Select best bets from the list below box, when selecting an existing Best Bet.
10. In the Description box, type a description for this Best Bet. This description appears with the Best Bet on the Search Results page.
11. Click OK.
12. If you want to create a definition for this keyword, in the Keyword Definition section, type the definition that you want to appear next to Best Bets for this keyword on the Search Results page (optional).
13. In the Contact section, type the user name of the person to inform when the keyword is past its review date (optional).
14. In the Publishing section, you can optionally choose end and review dates for this keyword.
15. Click OK.
16. Repeat steps 4 through 16 to create additional keywords and best bets.

Plan for business data connections with the Business Data Catalog
Updated: November 16, 2006
In this article:
• About the Business Data Catalog

• Plan connections to the Business Data Catalog

• Plan business data presentation

• Worksheets

The Business Data Catalog is used to connect data from line-of-business applications that have managed properties used by enterprise search in Microsoft Office SharePoint Server 2007. After applications are registered in the Business Data Catalog, the business data types and properties selected by administrators can be used in SharePoint sites, SharePoint lists, and relevant business data Web Parts. These sites, lists, and Web Parts can then be used to analyze and act on business data.
The line-of-business data used by the Business Data Catalog can combine with the core business intelligence functionality of Microsoft SQL Server 2005 Analysis Services and SQL Server 2005 Reporting Services, Excel Services, and key performance indicators (KPIs) based on data sources in data connection libraries. The result is an integrated view of business data and business processes across your organization.
As part of planning for your initial deployment Office SharePoint Server 2007, you should understand how to connect applications to the Business Data Catalog and how to present that data in sites, lists, and Web Parts. Then, you can plan for more specific features that use business data, such as business data profiles, business data actions, reports, and dashboards. Together these plans form a comprehensive deployment plan that you can use along with planning worksheets during the initial deployment of Office SharePoint Server 2007.
About the Business Data Catalog
The Business Data Catalog is a service for registering line-of-business applications and certain business data types and properties of those applications. The Business Data Catalog is managed from the Shared Services Administration page for each Shared Services Provider (SSP). For each line-of-business application used by the Web applications and site collections of an SSP, you must first register the line-of-business application and the business data types and properties that you want to expose to users.
After registering applications in the Business Data Catalog, you can decide how to present and use the data of those applications in sites, lists, and Web Parts. Properties in the Business Data Catalog appear in business data profiles and can be used in business data lists and Web Parts, or in filter Web Parts that filter the view of business data Web Parts. These Web Parts can then be used in building SharePoint sites, including reports and dashboards, that display business data. You can find data by crawling properties of business data as part of business data content sources. As with any other crawled properties, the crawled properties of business data are mapped to managed properties for search, and those properties are used during queries to prioritize relevant search results. Properties about users can be associated with properties in user profiles imported by profile services from directory services, such as the Active Directory directory service or Lightweight Directory Access Protocol (LDAP) directory services, or added as additional properties of user profiles.
By using line-of-business data in your SharePoint sites, you can integrate data analysis from these sites with data analysis based on data connection libraries. This allows you to build knowledge about your key business processes, make decisions, and act on those decisions.
For example, a sales department for a large organization uses a line-of-business application that tracks products, sales associates, customers, sales offices, and individual sales. The SSP administrator registers the applications, along with relevant business data types for products, customers, and sales offices. For each of these business data types, the SSP administrator includes relevant properties. For example, for customers, the properties for location, address, description, and purchasing manager are included.
You can create a business data list from sales data in a data connection library, and you can add columns for properties registered in the Business Data Catalog. This list of customers and sales can then be used in business data Web Parts used by reports, so you can compare sales across customers in the Report Center site. By mapping the relevant properties to managed properties in search, someone searching for a specific location where a customer is located will find that customer near the top of search results.
Top of page
Plan connections to the Business Data Catalog
Start the plan for the Business Data Catalog by considering the line-of-business applications used by your organization. Large databases and data warehouses will typically be accessed by using data connection libraries, and not the Business Data Catalog. The Business Data Catalog is the place to register line-of-business applications.
For each application, it is important to consider the following factors:
• Properties that will be helpful in analyzing business processes and making business decisions.
• Properties that are less relevant or contain data that you do not want to display widely in your organization.
• Sites that will use business data, such as reports, dashboards, and personalization sites.
• Web Parts that are used by SharePoint sites that have business data, including Business Data List Web Parts and KPI Web Parts.
• Lists you need to build business data Web Parts.
• Business data actions you want to create and the properties those actions are based on.
• Properties you expect users to use when searching for business data.
The details of planning properties of business data profiles, business data lists and Web Parts, business data actions, and the properties for searching for business data are described in greater detail in other articles. When you plan for the connections to the Business Data Catalog, it is important to first focus on which applications to connect and how to make those connections.
You should consider that most users in your organization will not have direct access to the line-of-business applications. This is a good idea for several reasons. Some data might be sensitive and not all data in the application will be displayed in sites, lists, and Web Parts. You also want to limit the performance impact on the servers that host line-of-business applications. For these reasons, a common practice is to copy data in a line-of-business application to another server, and then use that location in the Business Data Catalog and business data content sources.
To further limit access to the data, it is a good idea to use a single account or a group that contains a small number of accounts both for accessing the business data in the application and for crawling the data for search. In the case of search, it is a good idea to create a crawl rule for business data applications that uses the administration account for each line-of-business application as the crawling account for each business data start address.
After applications are connected, all included business data types and properties can be used in sites, lists, and Web Parts by any users who have the appropriate permissions. Typically, site collection administrators will create a SharePoint group for viewing business data and include users who have responsibilities to analyze and act on business data. Often, users will act on business data by making business decisions that are not directly involved with the application itself. If acting on data requires changing the data in the underlying database, each user can make changes based on their permissions to the relevant database.
For business data actions that use forms hosted by InfoPath Forms Services, the proper security settings must be configured according to plans for InfoPath Forms Services, so that users who use the forms can expect the data to be updated in the underlying application and not just a duplicated location used by the Business Data Catalog.
If a duplicated location is used, it is a good idea to plan for how often the data in that location is synchronized with the line-of-business data on the application server.
After you decide who has access to data and which applications you want to register, you should consider which business data types and properties to include. The simple rule to use is that if you want users in your organization to analyze data based on a set of business data types, those business data types should be included in the Business Data Catalog.
As you plan for the initial deployment, start with the business data types that you know are most likely to be analyzed by users in your organization, based on the purpose and key business processes of your sites. Include those business data types and plan for the properties that are most likely to produce useful results. For example, for a customer service site, it makes sense to include business data types for customers and for sales associates, enabling users that have the appropriate business data permissions to view and compare sales across customers or sales associates and make business decisions based on the results.
Worksheet action
Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record each connected application and the relevant business data types and properties, along with the accounts that have permission to the application server, any server that contains a copy of data that is used by the Business Data Catalog, and the accounts that are members of SharePoint groups that have access to the data in the Business Data Catalog.
For data sources based on SQL Server databases and other relational databases that will be stored in data connection libraries, record the planned data source and the relevant business data types and properties used by SQL Server 2005 Analysis Services and SQL Server 2005 Reporting Services when analyzing and displaying the data.
For more information about the business data types and properties used in the Business Data Catalog, see Plan for business data profiles .
Top of page
Plan business data presentation
After you have connected line-of-business applications and the data for relevant business data types and properties to the Business Data Catalog, you can consider how you will present that data in the organization so that it can be used in data analysis, collaboration, and business decision-making.
You should consider the business data that you want for each site in your planned site structure. Based on the purpose of each planned site, you can identify the applications, business data types, and properties to use in building the business data lists and Web Parts used in each site. After you ensure that the relevant data is available in the Business Data Catalog, you can plan the relevant Web Parts and SharePoint lists used by each site.
Worksheet action
Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record the KPIs, reports, and business data lists and Web Parts based on each data source, and add the properties used by each list or Web Part. For KPIs, record the planned calculation method and the targets for each indicator level of the KPI.
Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the sites that use business data applications for your site collection hierarchy and for each site collection. Also record the business data Web Parts and SharePoint lists that are used for each site.
For more information about planning business data in personalization sites or sites that use targeted Web Parts, see Plan My Sites .
For more information about planning business data in SharePoint lists, see Plan business data lists .
For more information about planning business data Web Parts, see Plan business data Web Parts .
For more information about planning business data actions, see Plan business data actions .
For more information about planning business data search, see Plan for business data search .
Plan business data Web Parts
Updated: November 16, 2006
In this article:
• About business data Web Parts

• Plan core business data Web Parts

• Plan specialized business data Web Parts

• Plan KPI Web Parts

• Plan Excel Web Access Web Parts

• Plan SQL Server 2005 Analysis Services Web Parts

• Plan filter Web Parts connected to business data Web Parts

• Plan deployment of Web Parts

• Worksheets

In Microsoft Office SharePoint Server 2007, business data Web Parts are used in reports, reports-enabled pages such as the Report Center site, and other SharePoint sites including personalization sites to display a Web-based view of business data that promotes analyzing, reporting, and acting on that data in a way that builds knowledge within your organization.
As part of planning for your initial deployment of Office SharePoint Server 2007, you should understand the different varieties of business data Web Parts, understand how they are used to display business data and promote business intelligence, and plan the specific Web Parts to deploy for each site.
About business data Web Parts
Business data can be displayed in SharePoint lists and Web Parts for the pages and sites in each site collection used by your organization. The sources of this data include Microsoft SQL Server 2005 and its related applications, such as SQL Server 2005 Reporting Services, and line-of-business applications registered in the Business Data Catalog.
Business data can be exposed directly in lists by using the Business Data List Web Part. It also can be exposed through Web Parts designed specifically for personalization features. Depending on where the Web Parts are used, the experience is completely different. If it is just a simple list, the experience is much like using any SharePoint list, except that the data is connected to the data source and updates automatically. If it is a single Web Part within a report, the owner of the page controls the interactivity and it might simply be a display of that data. If it is on a multi-report summary page, it can be filtered along with other business data Web Parts on the page. If it is on a personalization site or personal site, the information in the Web Part is targeted by audience, and only information relevant to the viewer is presented. There are also specific Web Parts for common line-of-business applications, such as SAP.
Types of Web Parts that are used to display business data on SharePoint sites include:
• Core business data Web Parts
• Specialized business data Web Parts
• Key performance indicator (KPI) Web Parts
• Excel Web Access Web Parts
• SQL Server 2005 Analysis Services Web Parts
• Filter Web Parts that are connected to business data Web Parts (for example, the Current User Filter Web Part and the Property Profile Filter Web Part used on personalization sites, and the Business Data Catalog Filter Web Part)
These Web Parts are used to create pieces of business intelligence that can be displayed in reports linked from the Report Center site, other SharePoint sites that have reports or business data, in multi-report summary pages also known as dashboards, and on personalization sites.
Data connection libraries expose Office data connection (.odc) files and universal data connection (.udcx) files.
Top of page
Plan core business data Web Parts
The core business data Web Parts include:
• Business Data List Web Parts
• Business Data Details Web Parts
• Business Data Association Web Parts
• Business Data Actions Web Parts
• Business Data Catalog Filter Web Parts
The first four business data Web Parts are used to display information based on the data stored by SQL Server and reported by SQL Server 2005 Reporting Services, and the properties of line-of-business applications registered in the Business Data Catalog. The first three of these Web Parts then can be added to reports in the Report Center site or other pages that display reports or business data.
The Business Data List Web Part presents business data in a simple list form, including several items from one type of business data in the Business Data Catalog. An example is a list of customers from a customer service database. That list can be connected to a filter Web Part to show information that is based only on the current user or a specific value for a property of the relevant business application. You also can edit the view properties of a Business Data List Web Part, just as you can edit the view of any list, to filter by property or limit the number of items shown in the Web Part. The Web Part also can be targeted to audiences so that only some users see the Web Part.
The Business Data Details Web Part displays the details of a single item, such as a single customer in a customer database.
The Business Data Association Web Part presents a related list that shows a list of items related to an item of another business data type. An example is a list of customers who work in a particular sales region. Related lists can be associated with more than one source business data type to narrow the focus of the list. An example is a list of sales orders by a customer in a particular sales division. The source business data types are the customer and the sales division, and the items in the list are sales orders. As with the view for the Business Data List Web Part, the view for the Business Data Association Web Part can be filtered or limited to a specified number of list items, and can be connected to filter Web Parts or targeted to audiences.
The Business Data Actions Web Part adds a simple URL to a page associated with the action named in the link. It is used to enable users to perform common actions from business applications directly from the Web browser. Often, a Business Data Actions Web Part is found on the same page with a related business data Web Part, so users can see information and act on it immediately. For example, a Business Data Actions Web Part for the "View Customer Profile" action could be found on a dashboard that has an Excel Web Access Web Part that displays sales for a customer and a KPI Web Part that shows customer satisfaction. An analyst seeing a low customer satisfaction KPI could correlate that information with recent sales reports and then click the business data action link to find out more about the customer and contact them to improve customer service.
The Business Data Catalog Filter Web Part filters other Web Parts on a page based on values found in SQL Server 2005 Reporting Services or the Business Data Catalog. It is often used in combination with business data Web Parts to filter the view, and any recognized property can be used by this filter. For more information about filtering data, see Plan dashboards and filters .
Top of page
Plan specialized business data Web Parts
Specialized business data Web Parts include:
• IView Web Part (SAP)
• WSRP (Web Services for Remote Portlets) Consumer Web Part
The IView and WSRP Consumer Web Parts support the presentation of data from SAP and WSRP portlets, respectively. If your organization uses SAP or remote portlets, these Web Parts enable you to integrate these Web Parts into your Web Part pages so that you can have a single view of all business data instead of different sites for different Web-based views of business data.
To use the IView Web Part, you must perform the following steps:
1. Configure SAP for the site.
2. Select an SAP server and IView for the Web Part.
3. Ensure that both the SAP server and IView are trusted on the site.
To use the WSRP Consumer Web Part, you must perform the following steps:
1. Configure WSRP producers for the site.
2. Select a portlet server and portlet for the Web Part.
3. Ensure that both the portlet server and portlet are trusted on the site.
Top of page
Plan KPI Web Parts
KPI Web Parts present business data with graphical indicators of the current status of a key business process. For example, a KPI can use traffic light icons to indicate that customer satisfaction is exceeding, meeting, or failing to meet goals. If customer satisfaction exceeds a preset goal, calculated by counting the percentage of positive satisfaction ratings across your organization, the customer satisfaction KPI is displayed with a green traffic light icon. If customer satisfaction is failing to meet minimum goals, the customer satisfaction KPI is displayed with a red traffic light icon. Otherwise, it is displayed with a yellow traffic light icon.
Each KPI in a KPI List Web Part and the single KPI in each KPI Details Web Part is evaluated based on a single value from a data source, either from a single property or by calculating an average or total across the selected data. Because they are calculated across a range of data rather than displaying data in list form, they can be more useful when measuring performance across groups or projects. However, by calculating a range of data for a specific person, such as a list of sales for a single employee, a KPI can evaluate individual performance.
The two KPI Web Parts display a list of KPIs calculated independently, or details for a single KPI. You can connect KPI Web Parts to filter Web Parts to filter each KPI by specific properties or users. Data sources for KPI lists include:
• SharePoint lists The data comes from a SharePoint list that might include business data from the Business Data Catalog or SQL Server 2005.
• Excel workbooks The data comes from an Excel workbook.
• SQL Server 2005 Analysis Services The data comes from database stores known as cubes, for connections in a data connection library.
• Manually entered information The data comes from a static list, rather than based on underlying data sources. This is used less frequently, for test purposes prior to deployment or on occasions when regular data sources are unavailable but you still want to provide performance indicators.
If the KPI List Web Part is added to a page, you must provide a link to a KPI list that contains KPIs. KPI List Web Parts can include links to the details of each KPI. When you click the link for the KPI, a customizable details Web page appears that contains additional information. The view of KPI List Web Parts based on SharePoint lists can be limited or filtered just as the view of any list.
The KPI Details Web Part displays performance indicators for a single item in a KPI list.
For more information about planning KPI Web Parts, see Plan key performance indicators .
Top of page
Plan Excel Web Access Web Parts
Excel Web Access Web Parts are available for personal sites and personalization sites. The Excel Web Access Web Part is used to provide information from a specific worksheet directly within the Web Part by using Excel Calculation Services. It also enables the ability to perform analytics in the Web browser without affecting the underlying worksheets or data sources. Users who have the appropriate permissions can start an Microsoft Office Excel 2007 window directly from this Web Part to edit the worksheet. The Excel Web Access Web Part also can be used to perform analytics on data from SQL Server 2005 Analysis Services.
Top of page
Plan SQL Server 2005 Analysis Services Web Parts
SQL Server 2005 Analysis Services Web Parts are available for personal sites and personalization sites. The SQL Server 2005 Analysis Services Web Part presents data directly from SQL Server 2005 Analysis Services. This part can be used in reports or multi-report summary pages, or in other sites that use business data such as personalization sites.
Top of page
Plan filter Web Parts connected to business data Web Parts
One feature of business data Web Parts is the ability to filter the data displayed on each Web Part by using one or more filter Web Parts. Filters can be connected to a single Web Part or to all the Web Parts on a page. When several business data Web Parts are connected to a single filter, the data in all of the business data Web Parts can be filtered by the same property and value. For example, a page can filter data from all of its business data Web Parts over the last month or for a certain user. Such multi-report summary pages, known as dashboards, can be very useful in presenting a uniform view of business data in your organization.
Top of page
Plan deployment of Web Parts
Each of these Web Parts must be added to a site and then connected to the underlying data source. After that connection is made and the Web Part displays business data, it can be used to create a page around the Web Part called a report. It can also be used in a multi-report summary page that displays multiple business data Web Parts. Reports can appear in the Report Center site or any other reports site, and business data Web Parts can be used in other sites such as personalization sites.
Site planning enables you to identify the Web Parts you plan to create that use business data. Each Web Part requires certain properties. You will want to decide which properties are most relevant for the viewers of each Web Part on a site.
The sites and pages that commonly use business data Web Parts include:
• The Report Center site
• Other sites that use reports
• The default dashboard for the site collection
• Personalization sites
For an initial deployment, consider the Web Parts that you will use for each of these sites. Although you can use business data Web Parts on any site, it is not necessary to plan for the Web Parts of those sites, which are created during ongoing operations. For each Web Part:
• List the applications and business data types you need to implement the Web Part.
• List the properties you need to implement the Web Part, so that you can include those properties in the business data profile for the appropriate business applications and business data types.
• Ensure that the information for each property and business data type of each application is complete enough to be useful when it is imported.
• Plan to create lists that business data Web Parts are based on.
• Consider the security implications of each list, and note the SharePoint groups that will have access to each list and corresponding Web Part.
• Decide whether the Web Part's view should be limited or filtered. For more information, see Plan business data lists .

• Decide whether the Web Part is connected to filter Web Parts. For more information, see Plan dashboards and filters .

• Decide whether the Web Part should be targeted to specific audiences, for each site that uses the Web Part. For more information, see Plan for personalized Web Parts .

• Consider whether the purpose of this Web Part is already fulfilled by another Web Part or site to minimize unnecessary duplication of functionality. For more information, see Determine sites and subsites .

Although planning Web Parts will take time, it allows you to understand the scope of your Web Part deployment before you begin, so that you can prioritize what is most important for initial deployment, and schedule lower priority sites and Web Parts for later deployment. It also reduces deployment time by identifying data sources and lists on which business data Web Parts are dependent.

--------------------------------------------------------------------------------

Provide custom search capabilities by creating an enterprise search Web Part.
Customize the display of search results by modifying the Search Core Results XSLT.
Display results from a Windows SharePoint Services search Web service.
Display the results of a keyword query.

-----------------------------------------------------------------------------------

Introduction

Search is typically designed to locate a particular document, not to answer a question such as “How are my sales doing this quarter”. It is possible to converge BI and Search to make the retrieval of data from Line of Business applications, Corporate Reports and other elements of BI applications easier for end-users to locate. Market leaders such as Microsoft recognize that search is a critical information access point for all corporate data, regardless of where its location or format, and has recently released new features in Office SharePoint Server 2007 such as the Business Data Catalog that enable these types of capabilities.
The following sections walk you through the required steps to integrate the various platform components of the overall search-enabled BI solution, namely SQL Server 2005 Analysis Services and Reporting Services with Office SharePoint Server 2007 Search, the Business Data Catalog, and Excel Services. The solution will reuse the Adventure Works sample databases.

Prerequisites
The configuration of the solution assumes the use of two servers, both with Windows Server 2003 R2 and on the same domain. One server, called the “database” server, is dedicated to SQL Server Analysis Services and Database Engine, the other server, called the “front-end” server, is dedicated to SQL Server Reporting Services and MOSS. Putting all components on one server machine, while feasible, will have you miss some important security considerations, and is not representative of a real production environment.
The “database” server must have the following components installed:
• Microsoft SQL Server 2005 Database Engine with Service Pack 2
• Microsoft SQL Server 2005 Analysis Services (SSAS) with Service Pack 2
• SQL Server 2005 Sample Databases (AdventureWorks)
The “front-end” server must have the following components installed:
• Microsoft SQL Server 2005 Reporting Services (SSRS) with Service Pack 2
• Microsoft Office SharePoint Server 2007 (MOSS) Enterprise Edition
• Microsoft Reporting Services Add-in for SharePoint
The following client applications must also be available:
• Microsoft Excel 2007 (to publish Excel Services dashboards to MOSS)
• Microsoft SQL Server Management Studio
• Microsoft Visual Studio 2005 for Business Intelligence (to publish Adventure Works SSAS database and reports)
• Microsoft Visual Studio 2005 (optionally, to implement MOSS search security trimming)
Deploying Prerequisite Components
This section provides key pointers for deploying the pre-requisite components. It will not cover the detailed steps required to install these components, as the Microsoft documentation, referred to in the References section, provides all the necessary information. However, there are certain tips and tricks discussed below that you need to be aware of.
Tips for Installing SQL Server 2005
You need to deploy SQL Server 2005 Database engine SP2 and SQL Server 2005 Analysis Services SP2 on the “database” server. You can use either the default instance (used by the sample solution described here) or a named instance for each server application. The Service Pack 2 of SQL Server 2005 is required for configuring Reporting Services in SharePoint Integration Mode. Reporting Services will be configured on the “front-end” server. We’ll come to that later.

Tips for Installing MOSS and Reporting Services Add-in for SharePoint

You need to deploy MOSS Enterprise on the “front-end” server using the farm option, not standalone or basic, and point to the “database” server for creating the various SharePoint content and search databases. The Enterprise Edition is required for the use of the Business Data Catalog and Excel Services features. These features are not part of the Standard Edition. By default, you can have all shared services, in particular Search, Business Data Catalog, and Excel Services, run under the same Shared Service Provider. In a real-world production environment, these services are distributed across multiple servers to properly scale out, which does not impact the configuration of the sample solution.
You also need to install the Reporting Services Add-in for SharePoint. It will simply add Reporting Services Management Options in the Central Administration > Application Management tab.

Deploying AdventureWorks Sample Databases
The AdventureWorks sample databases can be found at the Microsoft Download web site. Make sure to use the latest SQL Server 2005 samples published in February 2005. AdventureWorks OLTP database, DW data warehouse, and BI project and database are all needed for the sample solution. The AdventureWorks DW Cube needs to be built and deployed from Visual Studio 2005 for Business Intelligence.
Creating a Site Collection in MOSS and Configuring Excel Services

You need to create a new Web Application with port 80 and host header “reportcenter”, and then create a site collection with the template “Report Center” found under the Enterprise tab. Do not forget to add the Host Header “reportcenter” as Alias in your DNS server. The new Site Collection can be accessed by typing http://reportcenter/.
You will not be authorized to run any Excel dashboards in the http://reportcenter site until you explicitly specify it in the settings. Under the Shared Service Provider Application tab, add http://reportcenter to the Trusted File Location (enable Trust Children and Trusted data connection libraries and embedded). Navigate to the sample dashboard to ensure that Excel Services is working properly.
You will notice that a default “Reports Library” document library was created as part of the Report Center, which stores all the sample dashboards and reports. You will be publishing the AdventureWorks samples to this library later on.
Finally, you need to add a New Site under Site Actions with the template “Search Center” (stored under the Enterprise tab). This will add a Search tab to your MOSS Portal.

Configuring Reporting Services in SharePoint Integrated Mode
You need to install SQL Server 2005 Reporting Services SP2 on the “front-end” server. You do not need to install the Report Manager sub-feature since report management will be done in MOSS rather than a dedicated Report Manager site.
In Report Server Configuration Manager, start by creating a new ReportServer database in SharePoint Integrated Mode. You will also need to specify

Figure 1: Reporting Services Configuration Manager – Create a New Report Server Database in SharePoint Integrated Mode
For more information about installing Reporting Services in SharePoint Integrated Mode, go to the article Configuring Reporting Services for SharePoint 3.0 Integration in the reference section.

Configuring Custom Components
This section provides detailed information about the steps and code samples required to get all the custom components setup, such as the dashboard and report aspx pages, BDC application and the Security Trimmer.
The sample solution uses two entities, Product in SSAS and Employee in SSRS, to illustrate the BI Search capabilities of the MS platform.

Deploying AdventureWorks Sample Reports to Reporting Services

The SQL Server 2005 SSRS AdventureWorks Report samples can be found as part of this package. Open the sample solution in Visual Studio 2005 for Business Intelligence. Set the data sources to point to your reporting services server. In the deployment properties, since Reporting Services is running in SharePoint Integration Mode, specify the full SharePoint URL pointing to the Reports Library document library in the http://reportcenter site. New report and data sources folders will be created as specified in the URL.

Figure 2: BI Development Visual Studio 2005 – Report Server Solution Deployment Options

Deploying AdventureWorks Sample Excel 2007 Dashboard to Excel Services

As part of the package, an Excel 2007 dashboard has been provided with AdventureWorks PivotTable reports. The sample dashboard will be published to Excel Services to demonstrate the use of the Product entity for SSAS.
1. Open the file in Excel 2007 and Edit the Connection String to provide a valid user ID and password:
Provider=MSOLAP.3;Password=pwd;Persist Security Info=True;User ID=domain\userID;Initial Catalog=Adventure Works DW;Data Source=ServerName;MDX Compatibility=1;Safety Options=2;MDX Missing Member Mode=Error
Make sure that the Excel Services Authentication Settings are set to None. Otherwise, the connection string will not save the User ID and Password.
Note that the sample solution embeds security information into the Excel file for simplicity. For a detailed discussion on security considerations, go to related section in this document.
2. Go to Start > Publish > Excel Services and type the URL http://reportcenter/ReportsLibrary/Adventure Works DW SSAS Product.xlsx to publish the workbook in the Reports Library.
3. In the Excel Services Options, you need to select the PivotTable and Chart reports items to show: Chart_ProductTrend, Product By Territory and Channel, and add the parameters: Product, Product2

4. Navigate to the dashboard link to confirm that the dashboard can be opened with Excel Services.
Creating the Dashboard and Report Pages
Two pages will need to be created to display the business intelligence information. The first page displays information about the Product entity in Excel Services and SSAS.
1. In the http://reportcenter site, create a new Blank Web Part Page called “dashboard.aspx”.
2. Add the following three web parts: Query String (URL) Filter Web Part and two Excel Web Access Web Parts.
3. Configure each Excel Web Access Web Part to display the product-related PivotTable reports published in http://reportcenter/ReportsLibrary/Adventure Works DW SSAS Product.xlsx. Set the following Web Part properties:
a. Set the Workbook property to http://reportcenter/ReportsLibrary/Adventure Works DW SSAS Product.xlsx.
b. Set the Named Item property to “Chart_Trend” or “Product By Territory and Channel” respectively
4. Configure the Query String (URL) Filter Web Part to pickup parameter “ProductID” from the URL query string.
a. Set the Query String Parameter Name property to “ProductID”
b. Leave the Default Value property to Blank
c. Go to Edit > Connections > Send Filter Values To and select the Excel Web Access web part title for Name Item “Chart_Trend”
d. Set the Filter Value to “Product 2”
e. Go to Edit > Connections > Send Filter Values To and select the Excel Web Access web part title for Name Item “Product By Territory and Channel”
f. Set the Filter Value to “Product”
5. Test that the page is picking up the URL string parameter “ProductID” correctly by typing the following URL: http://reportcenter/Pages/dashboard.aspx?ProductID=[Product].[Product].%26[355]
Note: PivotTable parameters running against SSAS require the UniqueID of the parameter value, e.g. [Product].[Product].&[355]. The “&” character has to be URL encoded to “%26” to be properly picked up by the Query String (URL) Filter Web Part. In a later section, you will need to update the XSLT in the search result page to enable such URL encoding.

Figure 4: Sample Excel Dashboard page

The second page displays information about the Employee entity in SSRS.

1. In the http://reportcenter site, create a new Blank Web Part Page called “report.aspx”.
2. Add the following two web parts: Query String (URL) Filter Web Part and Report Viewer Web Part.
3. Configure the Query String (URL) Filter Web Part to pickup parameter “EmployeeID” from the URL query string.
4. Configure the Report Viewer Web Part to display the employee-related report called “Employee Sales Summary”.
5. Connect the Query String (URL) Filter Web Part parameter to the Report Viewer Web Part parameter “EmpID”.

Note: If you do not see the Report Viewer Web Part in the gallery, import it from the following location: :\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\ReportServer\ReportViewer.dwp.

6. Test that the page is picking up the URL string parameter “EmployeeID” correctly by typing the following URL: http://reportcenter/Pages/report.aspx?EmployeeID=284

Figure 5: Sample Report page

Defining the Business Data Catalog Application for Analysis Services

The first entity to be mapped in the BDC is the Product Dimension of the AdventureWorks cube. The entire BDC XML definition can be found in the attached package.
In order to produce tabular data that the BDC can consume, an SQL linked server name has to be created and an OPENQUERY statement needs to be defined.
In SQL Server Management Studio, run the following SQL statement:
EXEC sp_dropserver 'LINKED_OLAP' -- run if the linked server exists
EXEC sp_addlinkedserver
@server='LINKED_OLAP', -- local SQL name given to the linked server
@srvproduct='', -- not used
@provider='MSOLAP', -- OLE DB provider
@datasrc='', -- analysis server name (machine name)
@catalog='Adventure Works DW'
A “LINKED_OLAP” linked server object will be created under Server Objects > Linked Servers.
Make sure that the MSOLAP OLE DB Provider found under Server Objects > Linked Servers > Providers has the property “Allow inProcess” selected.
Figure 6: MSOLAP OLE DB Provider Properties

The Product Dimension data is now going to be exposed to SQL Server as an SQL View object. For more information on how to query cube dimensions, refer to an excellent article about Querying Dimensions in MDC in the Reference section. Create a new database called “LINKED_OLAP” and create the following view called “Product”:

CREATE VIEW [dbo].[Product]
AS
SELECT
CAST([[Product]].[Product]].[Product]].[MEMBER_UNIQUE_NAME]]] AS nvarchar(255)) AS ProductID,
CAST([[Measures]].[ProductName]]] AS nvarchar(255)) AS ProductName,
CAST([[Measures]].[Color]]] AS nvarchar(255)) AS Color,
CAST([[Measures]].[Class]]] AS nvarchar(255)) AS Class, CAST([[Measures]].[Size]]] AS nvarchar(255)) AS Size,
CAST([[Measures]].[Style]]] AS nvarchar(255)) AS Style, CAST([[Measures]].[Weight]]] AS nvarchar(255)) AS Weight,
CAST([[Measures]].[SubCategory]]] AS nvarchar(255)) AS SubCategory
FROM OPENQUERY(LINKED_OLAP,
'WITH
MEMBER Measures.ProductName AS [Product].[Product].MEMBER_NAME
MEMBER Measures.Color AS [Product].[Color].MEMBER_NAME
MEMBER Measures.Class AS [Product].[Class].MEMBER_NAME
MEMBER Measures.Size AS [Product].[Size].MEMBER_NAME
MEMBER Measures.Style AS [Product].[Style].MEMBER_NAME
MEMBER Measures.Weight AS [Product].[Weight].MEMBER_NAME
MEMBER Measures.SubCategory AS [Product].[Subcategory].MEMBER_NAME
SELECT
{
Measures.ProductName,
Measures.Color,
Measures.Class,
Measures.Size,
Measures.Style,
Measures.Weight,
Measures.SubCategory
} ON 0,
[Product].[Product].Children PROPERTIES MEMBER_UNIQUE_NAME ON 1
FROM $Product
')

Run the following SQL statement to make sure that your linked server is running correctly:

USE [LINKED_OLAP]
SELECT * FROM Product

The results should look like this:
Figure 7: Tabular Data from the AdventureWorks Product Dimension

Note that we are selecting the Member Unique Name for the Product ID. The ID is what will be indexed by MOSS Search and passed to Excel Services for rendering the dashboard.
Important: Make sure that the default crawling account used by MOSS to index content sources such as the BDC application has the appropriate rights to query the database, and in particular query the Product view in the LINKED_OLAP database. If you don’t know the crawling account name, go to the Shared Service Provider Application Tab and look up the account name in Search Settings under the Search section.

The Business Data Catalog definition file is an XML file that models and describes the Product entity, how to crawl it in MOSS and access it from the dashboard.aspx page. The file called “SSAS BDC Definition.xml” is part of the package that comes with this white paper. To load the BDC application, perform the following steps:

1. Edit the file to set the connection string to point to your database server and database name
RevertToSelf
SqlServer
sql server name
LINKED_OLAP
SSPI
2. Edit the file path to the dashboard.aspx page if the site name of page name is different from the default values.

3. Go to MOSS Shared Service Provider Management Tab
4. Go to Import Application link in the BDC Application Management session
5. Browse to the sample file “SSAS BDC Definition.xml” and Upload.
6. Navigate to the list of BDC Application and click on the newly added database application called by default “MSOLAPBI”.
7. Edit the security and make sure that your testing User Account or User Group has Edit and Execute rights to the application.

Below is an overview of the SQL queries defined in the BDC application definition file. None of the queries need to be modifled unless you named the Product view or other field names differently.

Two methods are defined in the BDC application for the Product Entity.
The GetProductID method, of instance type Finder and SpecificFinder, returns one or more Product entities using the following parameterized SQL query:

SELECT * FROM Product WHERE (ProductID BETWEEN @MinProductID AND @MaxProductID)

The ProductIDEnumerator method, of instance type IDEnumerator, returns the collection of all Product ID’s using the following SQL query:

SELECT ProductID FROM Product

The MOSS Indexing engine first queries ProductIDEnumerator to list of entities of type Product, and then calls GetProductID to retrieve each individual Product record with related attributes.

Defining the Business Data Catalog Application for Reporting Services
The second entity to be mapped in the BDC is the Employee report parameter of the Employee Sales Summary report data set, connected to the AdventureWorks OLTP database. The entire BDC XML definition is called “SSRS BDC Definition.xml” and can be found in the attached package.
Important: Make sure that the default crawling account used by MOSS to index content sources such as the BDC application has the appropriate rights to query the AdventureWorks database, and in particular query the HumanResources.Employee,
Sales.SalesPerson, Person.Contact records. If you don’t know the crawling account name, go to the Shared Service Provider Application Tab and look up the account name in Search Settings under the Search section.
To load the BDC application, you need to perform the following steps:
1. Edit the file to set the connection string to point to your database server name. The database name is “AdventureWorks”.
RevertToSelf
SqlServer
sql server name

SSPI
2. Edit the file path to the dashboard.aspx page if the site name of page name is different from the default values.

3. Go to MOSS Shared Service Provider Management Tab
4. Go to Import Application link in the BDC Application Management session
5. Browse to the sample file “SSRS BDC Definition.xml” and Upload.
6. Navigate to the list of BDC Application and click on the newly added database application called by default “SSRS”.
7. Edit the security and make sure that your testing User Account or User Group has Edit and Execute rights to the application.

Below is an overview of the SQL queries defined in the BDC application definition file. None of the queries need to be modifled unless you named the Product view or other field names differently
The following two methods are defined in the BDC application for the Employee Entity.
The GetEmployeeID method, of instance type Finder and SpecificFinder, returns one or more Employee entities using the following parameterized SQL query:

SELECT E.EmployeeID, C.FirstName + N' ' + C.LastName AS Employee
FROM HumanResources.Employee E INNER JOIN
Sales.SalesPerson SP ON E.EmployeeID = SP.SalesPersonID INNER JOIN Person.Contact C ON E.ContactID = C.ContactID
WHERE
ORDER BY C.LastName, C.FirstName

The EmployeeIDEnumerator method, of instance type IDEnumerator, returns the collection of all Employee ID’s using the following SQL query:

SELECT E.EmployeeID
FROM HumanResources.Employee E INNER JOIN
Sales.SalesPerson SP ON E.EmployeeID = SP.SalesPersonID INNER JOIN Person.Contact C ON E.ContactID = C.ContactID
WHERE (E.EmployeeID BETWEEN @MinEmployeeID AND @MaxEmployeeID)
ORDER BY C.LastName, C.FirstName

An action to call the report.aspx page for each Employee ID needs to be defined. This action will be the default action provides in the search result.

Note that if you were to use an existing Reporting Services implementation (not in SharePoint Integrated Mode for example), you could simply link the action to the actual report server link and feed the appropriate report parameter value in the URL. It would look something like this:

http://MyServer/ReportServer?/SampleReports/Employee Sales Summary&EmpID={0}

Crawling and Indexing the Business Data Catalog Applications

You are now ready to crawl and index both BDC Applications. Make sure that the user account used to run searches has access to the BDC Applications.
1. Go to MOSS Central Administration and click on the Shared Services Administration link pointing to the Search Shared Service Provider
2. Go to Search Settings in the Search seciton
3. Click on the Content Sources link
4. Click on New Content Source
a. Input the name of the content source e.g. "MSOLAP BDC Application"
b. Select content type as Business Data
c. Select the BDC Application instance "MSOLAPInstance"
d. Check the box "Start a full crawl of this content source" and click OK
e. Perform the steps a. through d. for Content Source "SSRS BDC Application" and Application instance "SSRSInstance"
5. Click on Start Crawl Now.

Note: Check the Crawl Log to make sure that the data is being indexed. If you are running into any issues, monitor SQL Server with the SQL Server Profiler to ensure that the proper user account is connecting to it and executing the queries. Moreover, the MOSS log files located at :\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS can provide detailed error information.

Updating the Search Result Web Part XSLT Template

As discussed earlier, The UniqueID of the Product entity needs to be passed to the Excel Dashboard. The “&” character needs to be URL encoded as “%26” for the Excel dashboard link to work. The XSLT template of the Search Result Web Part needs to be modified to enable proper URL encoding.
1. Run a sample search in MOSS and edit the Search Result page.
2. Edit the Search Core Result web part properties
3. Click XSL Editor and Edit the text in NotePad
4. Add the following “replace-string” template right before the template

5. Update the template that constructs the search result list item and replace the url variable with the following:

Note that a sample file “Search Core Results.xslt” is included in the package. However, in real world deployments, customers often customize the search result list with the XSLT template.

Running Sample Searches
You are now ready to get business intelligence in the search result.
1. Run a search for “Amy Alberts” and click on the link to report.aspx that will display Amy’s sales performance in SSRS.
2. Run a search for “mountain bikes” and click on of the product links to dashboard.aspx. It will display the actual financial performance of the product line based on SSAS data.

Security Considerations for Real-World Deployments
In a real world deployment, some careful considerations need to be given to security.
First of all, it is recommended to have Kerberos configured in your environment so that Excel Services can function properly in a Windows Authentication mode, where the MOSS logon account is passed to SSAS via Excel Services to run the actual PivotTable query.
Moreover, it is highly unlikely that all entity data (product or employee) would be accessible to an end-user. Therefore, you will need to effectively trim the values a user doesn’t have access to from the search result. This can be implemented via the ISecurityTrimmer interface of the MOSS Search object model, or a BDC method instance of type AccessChecker. For more information, refer to the References section.

Conclusion
This paper has provided a guide to setup a complete search-enabled BI solution using MOSS and SQL Server 2005 Search and BI features. This paper also covered the key search scenarios encountered by end-users when looking for mission-critical business intelligence. The Microsoft platform can be leveraged by partners such as BA-Insight to deliver compelling BI Search applications to the marketplace today.
User Profiles and Audience Targeting
------------------------------------------------------------------------

Carl Franklin and I recorded DNRTV #3 on SharePoint 2007 last weekend. This show was targeted towards ASP.NET 2.0 Developers, and we dove into two specific aspects
a) Interacting with the API
b) Writing Custom Web Parts
The show, should be online in about a month's time. Meanwhile, you can check out my code-magazine articles and developer.com and codeguru.com articles, and of course my blog about writing custom webparts. I have talked quite a bit about writing webparts, but the other portion - interacting with the API, I haven't talked much about (atleast publicly).
In this DNRTV show #3, I talked about interacting with the API, and the specific example I choose was a couple of utilities I have written with help from Angus Logan (Microsoft Australia), and will be available on codeplex.com. These utilities target user profiles and profile properties, but before I dive into what these utilities are all about, let me explain the background and set a stage for the need for these utilities.
If you are already familiar with User Profiles and Audience Targeting, then dive straight to the bottom of this blogpost where I talk about these tools that promise to make your life easier in production environments.
So lets start. First let us talk about "User Profiles".
User Profiles
MOSS 2007 has a fantastic feature called "User Profiles". Put simply, your MOSS 2007 sites and site collections will be accessible by a set number of users. These users will be split up into groups, and the key differentiation between each user will be their login_id (account name). Out of the box, you can use Windows Authentication, but still there is a primary key of sorts that differentiates one user from another. However, in any organization, a user is more than just a login_id. He has an address, a phone number, email, his manager, HR information, and a number of other things. In other words, a user has a "profile".
This "profile" information is generally stored under a number of systems in an organization - it could be a SAP system, a database, Active Directory, GAL (outlook/exchange), and others. Whatever it may be, SharePoint 2007 provides you with a convenient way to synchronize such user profile information from such stores of information. I have blogged earlier about a step by step process of syncrhonizing such information on both a full import basis and an incremental import basis. Without going into those details in this blogpost, in short, you can import such profile information from Active Directory, Active Directory Resource, LDAP or BDC. BDC further implies that you can import information from anything that has a web service, or can be accessed using ADO.NET. In addition to an import, you can specify mapping. So, "Postal Code" in your SAP HR system may mean "ZipCode" in SharePoint - so on and so forth.
The obvious question here is, what benefit can you garner from having all this profile information synchronized from multiple "islands of information" within your organization? An obvious benefit is, your users now get a "face". Literally, having a full user profile means, you see something like -

... rather than, "MyDomain\Smalik". (Curious about my picture?)
Also, right off the bat, alerts will work because you now have a proper email address associated, you are able to do hierarchical org charts, and a number of other benefits. The really cool thing however is that you can define custom properties, and you can do "Audience Targeting".
Audience Targeting
Audience Targeting refers to the ability, that you as a user can create content, targeted to certain audiences. It is as easy as this, Once you have imported profile information into MOSS 2007, you can say, Create an audience of users that are in California, and Report to Joe Schmoe. This becomes an audience called "Joe Schmoe's croonies in California". Now, Joe Schmoe, or anyone else, can target content to only that group of individuals.
How is this done, you ask? Here is how.
1. All this magic lives under Shared Services. So go ahead and under Central Admin, open Shared Services for the web you wish to create audiences on.
2. Click on the link that says "Audiences".
3. Under "Audiences" create a new audience, specify the rest of the information. I am going to create an Audience called "Smart People".
4. Next, SharePoint will ask you to choose rules for that audience. Go ahead and specify some rules. Rules, as you would notice, let you segregate the audiences based on a certain specific user, or group, or based on a property value. You would note that the properties you see in the dropdown, are the same properties you defined in the user profile properties collection. (Read that again - this is where light bulbs should go off). I am going to create a single rule, where personal site contains "winsmarts".
5. When you are done specifying the rules, go ahead and click "Compile Audience". In my case, there was one guy (me), who matched the criterion - whose personal site included the word "winsmarts", so the "Smart People" audience is now populated with one single user - me (how convenient). LOL.
My audience is now setup, and you can see this as below -

With my audience setup, the next obvious question is, "How can I use this audience?". In other words, if I had really complex concept that I wished to communicate to only "Smart People", how would I do it? easy.
1. Setup a list.
2. Go to List Settings, and under "Audience Targeting Settings" check the checkbox that says "Enable Audience Targeting".
3. Now, go ahead and add a List Item, you should see "Target Audiences" as one of the information(s) you can specify.
4. Type in the necessary information, specify "Smart People" as the target audience. This is show as below on a list of type "Calendar" -

Now when you click "OK", this content will appear to only people who are of target audience "Smart People". In other words, if a user has "winsmarts" as a part of his personal website, he will see this content - others won't.
That, I gotta say, is pretty incredibly powerful.
What about those tools then?
At the beginning of this blogpost, I talked about a couple of tools I have written, with help from Angus Logan (Microsoft Australia), that make your "user profiles" life easier. The two tools are as follows -
a) The first tool allows you to easily transfer profile properties from one web to another web.
b) The second tool, allows you to easily transfer actual profiles based on these proeprties from one web to another web.
These are very very useful if you are moving your site deployment between development and production, or from intranet to extranet, or any other such scenario.
My next couple of blog posts will walk you through these two utilities, how I wrote them, and the code will be available on codeplex.com very very shortly.
--------------------------------------------------------------------------------
Provide variations of Web content.
-----------------------------------------------------------------------------------
Customizing and Branding Web Content Management-Enabled SharePoint Sites (Part 3 of 3): Creating and Configuring WCM-Enabled Sites
Contents
• Introduction to Creating and Configuring WCM–Enabled Sites
• Creating a Publishing Portal
• Configuring the Site for Forms Authentication
• Allowing Anonymous Access
• Creating Site Variations
• Conclusion
• About the Author
• Additional Resources
Introduction to Creating and Configuring WCM–Enabled Sites
Web content management (WCM) is enabled in Microsoft Office SharePoint Server 2007 through a set of features—many of which rely on Windows SharePoint Services 3.0—that are discussed in the first article of this series. The second article discussed the extensibility options you have as a developer. (For links to the first two articles in this series, see Additional Resources.) To conclude this series, I take an administrator's approach to WCM. Starting with the steps to create an Internet site, I show you how to configure and tune your site for anonymous access and forms authentication. I also demonstrate how you can create and configure site variations.
Creating a Publishing Portal
A company typically hosts an Internet site in its own site collection and a dedicated Microsoft Internet Information Services (IIS) Web site (a Web application). The steps to create a site are not much different from the steps you take to create team sites or a portal site. You actually make the decision very late in the process at the level of the site template you select. For an Internet site, you select the Publishing Portal template.
To create an Internet site by using Office SharePoint Server 2007, open Central Administration. In the Application Management section, click Create or Extend a Web Application. This option enables you to enter all the settings for the creation of a Web application, the authentication provider (Kerberos or NTLM), and the application pool configuring the worker process running your Internet site. You can, on this page, immediately turn on anonymous access at the level of IIS.
After you extend the Web application, you can create a site collection with the top-level site based on the Publishing Portal template.
Configuring the Site for Forms Authentication
Prior to Office SharePoint Server 2007, Windows SharePoint Services and Microsoft Office SharePoint Portal Server 2003 relied completely on IIS 6.0 to authenticate visitors to the sites. Visitors needed a valid Windows account—either a local account or, in a real-world scenario, typically a domain account.
In Windows SharePoint Services 3.0, the visitor accounts can be stored in and managed from any identity store. You can configure your Web application to allow everybody to visit the SharePoint sites that allow anonymous access, and then provide custom authentication when needed by using Microsoft ASP.NET 2.0 forms authentication and leveraging the ASP.NET 2.0 authentication provider model. For example, you might have accounts for one or more visitors responsible for authoring and managing the content in the Internet site. You can also configure anonymous access in combination with Windows authentication instead of Forms authentication.
Preparing the SQL Server Data Store
ASP.NET 2.0 provides two default authentication providers: Microsoft SQL Server Membership and LDAP Membership. If these are not sufficient, the ASP.NET 2.0 authentication provider model enables you to create your own custom membership providers if you decide to store the accounts in another data store.
Suppose that you want to use Microsoft SQL Server 2005 to store your accounts. How do you start? First you need a database to store the accounts. You could use any database, but ASP.NET includes a ready-to-use database named aspnetdb. To create this database in Microsoft SQL Server 2005, you execute a small command-line tool named aspnet_regsql.exe. You can find this tool in your Microsoft .NET Framework folder. A wizard in the tool guides you through the steps to create this database.
Switching the Authentication Mode
The default authentication mode for the new Internet site created is Windows authentication. If you want to configure the Web application to use Forms authentication, use the following procedure.
To use Forms authentication
1. Open Central Administration, and then click Application Management.
2. In the Application Management page that opens, in Application Security, click Authentication Providers.
3. In the Authentication Providers page that opens, click Default.
4. In the Edit Authentication page that opens, do the following:
a. In Authentication Type, select Forms.
b. In Membership Provider Name, type AspNetSQLMembershipProvider.
5. Click Save.
This procedure changes the authentication portion of the web.config file for the site to the following.
Xml
Copy Code

Office SharePoint Server 2007 includes a sign-in page that you can replace with a custom sign-in page. (The BLANKINTERNET site definition also includes a sign-in page definition.)
Populating the Accounts Database
Before you can log on to the Internet site, you must have an account provisioned by the aspnetdb SQL Server database. Currently, none are defined. Several ways exist to populate the users table inside the database with custom accounts. For example, you can choose to execute a stored procedure, or you can use the ASP.NET Web Site Administration tool, which provides a browser-based front end for the database. I explain the latter method here.
To open the ASP.NET Web Site Administration tool
1. In Microsoft Visual Studio 2005, create a blank ASP.NET 2.0 Web application.
2. Modify the web.config file to set the mode of the element to Forms instead of Windows.
Xml
Copy Code

3. Replace the empty tag with the following.
Xml
Copy Code

This change overrides the definition found in the machine.config file.
4. In the toolbar of Solution Explorer, click ASP.NET Configuration. The ASP.NET Web Site Administration tool opens in your browser.
5. Click the Security tab. Use the links on this tab to add accounts to the aspnetdb database.
The machine.config file (located in the config folder of the .NET Framework folder) contains an entry that directs ASP.NET to SQLExpress. If you always want to use the aspnetdb database that is created in SQL Server 2005, you might want to modify the element directly in machine.config. If not, make the change in every web.config file associated with the Web applications where you want to use the aspnetdb database in SQL Server 2005. You also need to change the web.config file of the Internet site and the web.config file of Central Administration. The web.config file of Central Administration is located in C:\inetpub\wwwroot\virtualdirectories\GUID, where GUID is unique for your own computer. Consult your IIS manager to determine your GUID.
Defining the Administrator Account
None of the accounts created in the Microsoft SQL Server database have access to the Internet site. And you do not have a way to get access to the site and define a user as an administrator of the site. However, Central Administration provides an option to define users for the Internet site via the Policy for Web Application administrative link on the Application Management page without having to log on to the site itself. On the page, you can add one of your custom user accounts and grant it the role of the administrator in the Internet site. The new administrator can then log on and assign roles to the other custom accounts. If you are targeting the Internet, use the Default zone.
Figure 1 shows how the People Picker control verifies the names you type against the accounts stored in the SQL Server database. If the People Picker is not able to verify an account, a red squiggle appears under the name. If this occurs, verify that you modified the tag in the web.config file of Central Administration.
Figure 1. Using People Picker control with SQL Server accounts

You can now use the administrator account to sign in to the Internet site. If sign in succeeds, you see a welcome page and can manage the other user accounts.
Allowing Anonymous Access
The last step is configuring the Internet site to allow anonymous users to visit the site. You already turned on anonymous access at the level of IIS. There is an additional step to take in the Internet site itself. Currently the anonymous users do not have any authorization to access the top-level site. On the home page of the Internet site, you can find a shortcut to the administration page where you have the option to give anonymous users authorization to the complete site (Figure 2).
Figure 2. Authorizing anonymous users

To grant access to anonymous users
1. On the home page of the Internet site, click Enable anonymous access.
2. In the Change Anonymous Access Settings page that opens, under Anonymous users can access, click Entire Web site.
3. Click OK.
If the Enable anonymous access link has been removed from the home page of the Internet site, use the following procedure.
To navigate to the Anonymous Access administration page
1. On the Site Actions menu of the Internet site, click Site Settings.
2. In the Users and Permissions section, click Advanced Permissions.
3. On the Settings menu, click Anonymous Access.
You can configure anonymous access per site in your site collection. For example, you can hide one or more sites from anonymous users and make those sites available only to authenticated users.
Before you test your anonymous access, explicitly log out by using the Welcome control at the top of the site.
Creating Site Variations
Site variations are definitely one of the most exciting additions to Office SharePoint Server 2007, making it possible for companies to support multilingual, multidevice, or just plain multi-anything Web sites. Generally, you use site variations to modify a source site, and Office SharePoint Server 2007 duplicates those modifications to any variations of this site.
For example, imagine a multilingual scenario in which a company decides to support three languages for their external Web site: Flemish, Dutch (yes! Flemish is different from Dutch), and English. Being based in Brussels (Belgium), the company designates the Flemish version of the site as the master or source site. The content managers perform their work on the master site. They want to see their work—that is, all of the pages created—duplicated in an automatic way in the Dutch and English sites. Site variations provided by Office SharePoint Server 2007 allow you to accomplish this task.
Note:

Office SharePoint Server 2007 cannot translate the sites. Translation of the created content is typically a step in a custom workflow triggered when a content author publishes a page—in this example, in the Flemish site.
Artifacts Enabling Variations
Site variations rely on a number of artifacts:
• First and most important are variation labels. In the multilingual scenario discussed earlier, Flemish, Dutch, and English are variation labels. One of your variation labels must be the source variation label.
• Office SharePoint Server 2007 allows for a fully scheduled and automatic duplication of work done in the source variation label. Administrators determine schedules to fit their way of working.
• Site variations use the Windows SharePoint Services solutions framework and everything it offers. An internal list named Relationships stores all of the metadata involved.
• Resources, such as pictures, can be shared (or referenced) by all variations, or administrators can decide to maintain dedicated resources per variation label.
Starting with Site Variations
By default, site variations are not turned on. Site collection administrators must first configure the site variation settings.
To access the site variations settings
1. Open a site, such as the Internet site created in the beginning of the article.
2. On the Site Actions menu, click Site Settings.
3. On the Site Settings page, under Site Collection Administration, click Variations.
Now you need to decide where you want to start varying the site. Your options are to start from the top-level site ("/") or from one of the subsites in the site collection. You can use the Browse button to select a subsite.
You can take control of the duplication process yourself or let Office SharePoint Server 2007 take care of it. You can also configure other options:
• Re-create a deleted page in the variations when the source page is republished. This option can enforce the consistency between the variations, but in some scenarios you might not want to do so.
• Update Web Parts on target pages. When a content author creates a new source page, you might want to have all of your target pages created, but you might not want to preserve a link to the source page.
• Notify persons that need to be aware of the creation of new subsites or pages.
• Reuse resources (such as a picture) by simply referencing it, or make a local copy of the resource. The latter choice is useful if the resources need to be translated.
Creating Variation Labels
Now you create the variation labels, one for each of the languages you want to support.
To create a label for the source variation
1. On the Site Settings page, click Variation Labels.
2. On the Variation Labels page, click New Label.
3. On the Create Variation Label page, type the name of the label, such as Flemish, and a description of the label.
4. In the Display Name box, type the name that represents the variation in the user interface.
5. In the Locale list, select a locale. If your site variations begin at the top-level site, the locale allows your site to switch to the language variation based on the culture setting in the browser.
6. In the Hierarchy Creation section, select the portion of the source variation that you want to duplicate to the other variations.
7. In the Source Hierarchy section, select Set this variation to be the source variation. You can have only one source variation.
8. Select the site template on which to base the site variation.
9. Click OK.
Next you create all of the other site variation labels that will duplicate the content and infrastructure created in the source variation. Only the title, description, display name, and locale are available to set. This is because you already have defined the source variation. Remember that you can have only one source variation for your site collection.
As a final step, you create the infrastructure by clicking Create Hierarchies in the toolbar of the Variation Labels page. After Office SharePoint Server 2007 creates the variations, you see an overview similar to Figure 3.
Figure 3. Variation Labels page

Tuning the Navigation
If you return to the home page of your Web site, you can see three subsites—one for each of the variation labels (Figure 4). (The Press Releases subsite that is visible in the figure is not part of the variations infrastructure.)
Figure 4. Three language variations for your Web site

The home pages of your site variations still need to be approved before they are published. The master page associated with your site contains a small ASP.NET user control named VariationLabelsMenu.ascx that Office SharePoint Server 2007 displays on your pages (Figure 5), which allows a user to jump to the corresponding page in other variations.
Figure 5. Variations Label menu

For variations based on language, you probably want to hide the variation sites. Remember that Office SharePoint Server 2007 directs a user to the appropriate language of the site based on the locale as defined in the language settings of the browser. So a Flemish visitor with the Flemish locale set in Internet Explorer sees the Flemish variation. If the specified locale is not available as a site variation, the user sees the source variation.
You can hide variations from the navigation by clicking Modify Navigation Settings on the Site Settings page at the Site Collection Level.
Authoring Pages
A content author creating a new page in the source variation sees the page duplicated in the other variations. The update of the variations can happen automatically, or you can activate it manually by using the Page Editing toolbar where the Update Variations action is available.
The pages created in the variations can be involved in a workflow that handles the translation process. One possible scenario is that a translator is notified by an e-mail message to navigate to the new page and translate it.
Conclusion
This final article in this series provided insight into the steps involved in configuring an Office SharePoint Server 2007 site for anonymous access and forms authentication, and discussed the configuration of a site to support multiple variations of the content delivered with the site.

Using Parameters In Dashboards
Today we have a guest post from Dan Parish, who is a program manager on the Excel Services team. Dan is going to explain a bit more on how to use Excel Services to set up dashboards that are driven by parameters.
Back in the original posts regarding Excel Services, Dave mentioned that Excel Services is targeted at consumers and explorers of workbooks. As such, Excel Services doesn't allow you to simply type into any cell or create new workbooks on the fly. Dave also mentioned that we do understand that in some scenarios some cells need to be edited, and this post discussed the idea of 'parameters', those being specifically marked cells that can be edited on the server. Let’s take a closer look.
Why use parameters?
In the firts public beta, we only allowed you to mark single cell named ranges that were either blank, or contained a value (i.e. no formulas) as parameters. With the most recent beta build, however, we also added in the ability to mark PivotTable Report Filters as parameters. Since PivotTable and OLAP Formulas are the only way to refresh external data with Excel Services this release, this allows you to be able to drive your external data queries using web parts other than the Excel Services web part (called Excel Web Access or EWA for short).
What are some examples of where this would be useful? Well, let's say that you are creating a dashboard and want to display several different charts of data related to a stock chosen by the user. You can create these charts in Excel and display them using Excel Services, but you probably wouldn't want the user to have to select the stock in each web part separately. Instead you'd want the user to be able to pick the stock once, and have all of the other web parts update.
Using SharePoint's Choice or SQL Server Filter, and Excel Services, you can do just that. Another example might be that you have a report that you want to filter based on the region a particular SharePoint user is in. Using SharePoint's Current User filter and Excel Services, you can do that too. The possibilities really are varied and numerous.
Creating a dashboard using Excel Services with Parameters and SharePoint Filters
So now I want to provide a bit of a walkthrough as to how you can create one of these dashboards yourself. In this case I have a simple workbook that contains a PivotTable of all my store's sales data, and an associated PivotChart. I want to put both of these in a dashboard and have them be filtered by one central control that contains a list of the items I sell, so that if I select one or more items from the list, both the PivotTable and PivotChart will update to show me sales information related only to the selected items.
Creating the workbook and using a Data Connection Library
The first step is obviously to create the workbook. I have all of my data stored in an OLAP database, and I've exported my ODC file to a new document library in SharePoint this release called a Data Connection Library (DCL). This blog has talked about DCL's before, but at a high level a DCL is a document library specifically made to store Excel and InfoPath external data connection files. By storing my ODC file here and referencing it directly from my workbook, I can have Excel Services also use it and by simply changing the ODC file in this one location, I can update the connection information automatically for every other workbook that uses it as well.
Defining a PivotTable Report Filter Parameter
Once I've got my workbook created, I need to define a parameter. In this case, I want to filter my PivotTable Report Filter that contains the list of items. Parameters have to be named ranges, so I first give a name to the PivotTable Report Filter (the actual cell that contains the filter). Now, to publish the workbook to the server and define a parameter at the same time, I choose Office Button > Publish > Excel Services. On the dialog that appears I can select where I want to save my workbook, and then I can click the Excel Services Options button. Here there is a Parameters tab where I can add in the named range that I just created as a parameter. Only named ranges that are valid to become parameters will show up as possible choices here.

(Click to enlarge)
Laying out the dashboard page
Once I've created my parameter and saved the workbook to the server, all I need to do is setup my dashboard the way that I want it to look. I can do all of this in my web browser without writing a line of code: it’s all point and click. In this case, I've added two Excel Web Access web parts, and one SharePoint SQL Server Filter control.

(Click to enlarge)
Configuring the Excel Web Access web parts
First I'm going to setup the two EWA web parts. When I click the link within the leftmost EWA web part to open the tool pane, I can then either enter the path to the workbook that I just saved directly, or I can click on the "..." to the right of the text box to launch a file picker and select the file that way. I can also specify the name of the object that I want to display. I simply do this for both EWA web parts specifying 'PivotTable1' to display for the first, and 'Chart 1' to display for the second.

(Click to enlarge)
Configuring the SQL Server filter
The next thing I need to do is to configure the SQL Server filter. To do that, I click the link to open its configuration tool pane, and then browse to the same ODC file that my Excel workbook is using. Automatically, the filter displays all of the dimensions in the cube. If I select the same dimension my Report Filter is using, I'll see all of the hierarchies in that dimension. After I do that, I can then select the same level that the Report Filter is using, give the web part a display name, and I'm good to go.

(Click to enlarge)
Connecting the filter control to the EWA web parts
The final thing that I need to do is to connect the SQL Server filter to each of my EWA web parts. To do that, I select the “edit” dropdown at the top right of the filter control, and then select Connections > Send Filter Values To > (name of my EWA web part). A dialog will pop up, and if I select “Get Filter Values From” and then click Configure, I'll see a list of all of the parameters in the workbook that the EWA is currently displaying. I then select the parameter I want to send the filter value into, and click OK. That's it. I do the same for the second EWA and I'm done. Note that you can also configure connections going the other way, by selecting Connections > Get Filter Values From on the EWA web parts.
Now, if I select a different item in the filter control, both of my EWA web parts will update.

(Click to enlarge)
This is just a simple example. SharePoint ships with many different filter controls including ones that can pass the current user or any known properties about them, one that can take parameters from the query string and pass them in, one that lets you enter a hard coded list of items filter (which is a great way to do data validation with Excel Services), and many more. This example was just one way that you can incorporate the business logic that you have in Excel into a dashboard and really integrate it into the whole experience.
Introduction to Excel Services and Excel Web Access

Excel Services is a Microsoft Office SharePoint technology that makes it simple to use, share, secure, and manage Microsoft Office Excel 2007 workbooks (.xslx, xslb) as interactive reports in a consistent way throughout the enterprise.
________________________________________

________________________________________
In this article
________________________________________
What is Excel Services?
What is Office Excel Web Access?
How do Excel Services and Office Excel 2007 work together?
Interacting with an Excel workbook in Excel Services
Excel Services scenarios
Creating "one version of the truth"
Connecting to data in a secure way
Excel Services and Information Rights Management
Using Excel Services with other Business Intelligence features
________________________________________
What is Excel Services?
There are three basic components to Excel Services that interact with each other and together form the overall structural design of Excel Services.
________________________________________

Excel Calculation Services (ECS) is the "engine" of Excel Services that loads the workbook, calculates in full fidelity with Microsoft Office Excel 2007, refreshes external data, and maintains sessions.
Excel Web Access (EWA) is a Web Part that displays and enables interaction with the Microsoft Office Excel workbook in a browser by using Dynamic Hierarchical Tag Markup Language (DHTML) and JavaScript without the need for downloading ActiveX controls on your client computer, and can be connected to other Web Parts on dashboards and other Web Part Pages.
Excel Web Services (EWS) is a Web service hosted in Microsoft Office SharePoint Services that provides several methods that a developer can use as an application programming interface (API) to build custom applications based on the Excel workbook.
Because Excel Services is a component of Microsoft Office SharePoint Server 2007, you can also take advantage of many SharePoint technology features such as, controlling, securing, and managing access to spreadsheets, server-based performance, and ability to scale well when users are added.
________________________________________
Top of Page
What is Office Excel Web Access?
Excel Web Access is a Web Part that displays data and charts from an Excel Workbook, has a similar "look and feel" to Microsoft Office Excel, such as sheet tabs, outline buttons, and drop-down arrows, and provides a number of ways to customize the Web Part.
________________________________________

The top section contains the title, and a toolbar which has several menus, commands, and a drop-down list.
The main window displays one or more worksheets in Worksheet view, a named item, such as a chart or an Excel table in Named Item view, and optionally an outline area.
The Parameters Task Pane has parameter labels, text boxes for data entry, and optional tool tips that provide more information about each parameter.
The bottom section displays refresh data messages.
________________________________________
Top of Page
How do Excel Services and Office Excel 2007 work together?
You must first create an Excel workbook by using Office Excel 2007, and then save the workbook in Excel Services. In essence, Office Excel 2007 is the authoring tool and Excel Services is the reporting tool.
________________________________________

A workbook author, often a business analyst, uses Office Excel 2007 to create the Excel workbook, optionally specify named items for viewing, and optionally define parameters.
The workbook author saves the workbook to a document library (or to a network or Web folder) in Excel Services, where it is managed and secured by a SharePoint administrator.
The workbook author and other users can create reports, Web Part Pages, and Business Intelligence dashboards that use the workbook.
Many business users can access the workbook by viewing it in a browser, and even refresh the data if the workbook is connected to an external data source.
With appropriate permission, business users can copy the current state of the workbook and any interactions made during the current session, such as sorting and filtering, to a client computer for further analysis either as an Excel workbook or a snapshot.
________________________________________
Top of Page
Interacting with an Excel workbook in Excel Services
Although you cannot edit the cells in the Excel workbook in Excel Services, you can interact with the data in a number of ways. To answer specific, unanticipated questions you might have about the data, you can often find and display information by using the following interactive features:
View the latest formula results by recalculating data in the workbook.
Refresh live data from an external data source, such as a database or an Online Analytical Processing (OLAP) cube.
Navigate to different worksheets, parts of worksheets, or selected named items in the workbook, such as a chart or an Excel table.
Sort and filter data.
Expand or collapse levels of data and use a report filter in a PivotTable report.
Temporarily change the values of cells by entering parameters to update the results of a formula or do simple what-if analysis.
Obtain different results or views by selecting data from another connected Web Part, such as a Filter Web Part or List View Web Part, on a dashboard or other Web Part Page.
NOTE You can also copy the Excel workbook, open it in Excel 2007 on your computer, and then use all the features of Excel, including what-if analysis and well-formatted printing.
Top of Page
Excel Services scenarios
Of course, there are countless ways that you can use Excel Services, but the following is a representative list of scenarios and examples to help you better understand how you might use Excel Services.
Business intelligence dashboards An executive committee has access to several company dashboards that act as an up-to-date financial scoreboard for the company. To continuously assess company performance, the main dashboard summarizes Key Performance Indicators (KPIs), such as sales goals, target revenues, and profit margins, on a monthly basis. Additional dashboards summarize market news to help analyze financial risk for current and new projects, and to display charts of critical financial data to help evaluate different investment portfolios.
Marketing analysis information system A marketing department in a company that sells athletic clothing and equipment maintains an information portal page that summarizes key demographic data, such as gender, age, region, income-level, and preferred leisure activity. Most employees in the marketing department can optionally open the Excel workbooks on their computer and do "what-if" analysis of all data, or print well-formatted reports. Over time, users can also easily add reports for others to share.
Professional sports players statistics A major league sports organization shares past and present statistics on all players' performance and salaries. This data is used to make trades and to negotiate salary contracts. New reports and analyses are created, revised, and shared by owners, especially during the pre-season.
Retail store decision-making tool A retail chain summarizes critical point-of-sales data on a weekly basis and shares it with suppliers, financial analysts, and regional managers. Reports include current items below inventory, top 20 selling items by sales categories, important seasonal data, and transaction counts by each store.
Sales account management report system A sales group accesses a set of daily briefing reports that capture key data such as the top sales people, progress towards monthly sales targets, successful sales programs, and low-performing channels of distribution. Additional reports summarize sales by key variables, such as region, product line, and month, sales calls per week, and the number of closed calls. When individual sales people display these reports, they can automatically see their sales numbers because the system identifies them based on their user name.
Engineering project daily summary An engineering group develops a Web Part Page that summarizes key project schedule data such as bug counts, status of specifications, progress diagrams, feature trends and priorities, and links to key resources and contacts. The data is drawn from several external data sources, such as project databases and lists of specifications.
Proprietary financial analysis calculation model A large financial institution has researched and developed a pricing model that is private intellectual property. The results of the formula need to be shared with some investment managers, but the formula that is used to calculate the pricing model must be secure and never be publicly revealed. This pricing model is extremely complex and takes a long time to calculate. Every night, the pricing model report is calculated and created on a fast server, saved to a trusted location, and displayed on a Web Part Page, but only to those who have appropriate permission.
Top of Page
Creating "one version of the truth"
In most enterprises, you often need to create critical workbooks at a specific point in time, often on a regular schedule. For example, you might create a secure workbook at an agreed-upon date and time every fiscal quarter to confidently compare sales, inventories, revenues, and profits between fiscal quarters. You do not want to be concerned that the information in the workbook was changed by another user and that unexpected differences in calculations and results complicate your decision-making. This is sometimes called creating "one version of the truth", which means that when you compare the same workbook report with other users, you can rely on a unique point in time (the date and time that the workbook was created) to verify a consistent view of the data.

A master workbook contains cumulative financial data that is regularly updated.
A workbook is published at the end of each fiscal quarter.
"One version of the truth" simplifies decision-making and comparisons between fiscal quarters.
For more information, see Roadmap for publishing an Excel workbook as "one version of the truth".
Top of Page
Connecting to data in a secure way
For some Excel workbooks saved to Excel Services, all the data is stored in the workbook. To update the data in Excel Services, the Excel workbook must be saved again. For other workbooks, there are one or more connections to external data sources, such as a database or OLAP cube. These connections contain information about how to locate, log in, query, and access the external data source. Although this connection information can be stored in the workbook, often it is stored in an Office Data Connection (.odc) file, especially when the data is shared by many users and the connection information needs to be updated. The workbook author or an administrator can create the connection information by using Excel 2007 to author the connection, and then to export the connection information to a .odc file.
A Data Connection Library (DCL) is a special SharePoint document library that can be defined as a trusted location library and that makes it easy to store, secure, share, and manage .odc files. For example an administrator may need a to move a database from a test server to a production server, or update a query that accesses the data. By using one .odc file saved in a DCL, administration of this connection information is much easier and the user's access to data is more convenient because all workbooks use the same connection file and a refresh operation, whether on the client or server computer, gets up-to-date changes to that connection file. You can even set up Office SharePoint Server and a user's client computer to automatically detect changes to the connection file and use the most up-to-date version of that connection file.
For more information, see the Microsoft Office Excel 2007 Help system and the Office SharePoint Server Central Administration Help system.
Top of Page
Excel Services and Information Rights Management
Information Rights Management (IRM) is a way to provide privacy protection for a Microsoft Office document and to ensure that sensitive information is only viewed by appropriate people. For example, you may want to report quarterly financial data only to select members of an executive committee one month before the data becomes publicly available in a financial statement, so they have time to prepare public relation responses and make appropriate business decisions.
Windows SharePoint Services Version 3.0 or later supports IRM on a document library and all the documents in that library (whether or not those individual documents are enabled with IRM). Once the document is uploaded to a document library enabled with IRM, the document, in effect, becomes IRM-enabled.
Excel Services does not support loading Excel workbooks that have been enabled with IRM, and it does not load an Excel workbook if it is enabled with IRM or comes from a document library enabled with IRM. However, if you want to take advantage of IRM, you can load an Excel workbook without IRM into Excel Services, open the workbook as a snapshot, and then save the snapshot to a document library that is enabled with IRM.
For more information, see the Microsoft Office Excel 2007 Help system and the Office SharePoint Server Central Administration Help system.
Top of Page
Using Excel Services with other Business Intelligence features
Excel Services is part of a collection of Office SharePoint Server features collectively called Business Intelligence that an individual, a team, or an entire enterprise can use. These features are designed to work together and support quick, robust development of customized decision-making tools that can access a variety of data sources — often without the use of code.
The Report Center
The Report Center provides a central location for various Business Intelligence data and objects, and contains special document libraries for storing reports, lists, Web Parts, Web Part Page templates, and .odc files. Within the Report Center, users can also search for items by using categories, view a calendar of upcoming reports, and subscribe to reports that they find relevant.
By default, an Excel workbook published and saved to a document library in the Report Center is single-click enabled to open the workbook in browser view, which is a convenient way to see the workbook without adding it to a Web Part Page.
The KPI List Web Part
The KPI List Web Part gets data from SharePoint lists, Excel workbooks, Microsoft SQL Server 2005 Analysis Services, or manual data entry, and then displays a Key Performance Indicator (KPI), which is a visual cue that communicates the amount of progress made toward a measurable goal. By using KPIs, you can easily visualize answers to the following questions:
What am I ahead or behind on?
How far ahead or behind am I?
What is the minimum I have completed?
Users can even drill down on the KPI items to see the detail behind the visualization. For instance, if the status of a KPI is red (indicating a problem), clicking on that KPI will automatically take the user to a report page that shows how the trend of the KPI over time, what the thresholds are, and the data that was used to determine the current status of the KPI.
Each area of a business may choose to track different types of KPIs, depending on the business goals that they are trying to achieve. For example, to increase customer satisfaction, a call center might set a goal to answer a specific number of calls within a shorter period of time. Or the sales department might use KPIs to set performance goals, such as the number of new sales calls made per month.
Filter Web Parts and the Apply Filter Button
You can use the Filter Web Parts to display only the subset of data that you are interested in viewing in other Web Parts and optionally the Apply Filter Button to perform the filter operation. For example, a data source can contain a five year history of multiple products for the entire country/region. By using the Filter Web Parts and Apply Filter Button, you can simultaneously display pertinent data for only one sales region, one product, or the current year in several Excel Web Access Web Parts.
Office SharePoint Services has a number of different Filter Web Parts that enable you to enter or to choose one or more values to change the contents of one or more Web Parts on a page to display exactly the information that you need.
For more information, see Connect Filter Web Parts to Excel Web Access.
Office Shared Services Dashboards
Microsoft Office SharePoint Server 2007 Dashboards are tools that are used to communicate status, observe trends, anticipate problems and opportunities, make decisions, and drive actions — often with graphics and charts. A Dashboard is a Web Part Page that displays information, such as reports, charts, metrics, and Key Performance Indicators (KPIs), from disparate data sources.
You can create your own dashboard by using a Dashboard template to quickly connect existing Web Parts, add or remove Web Parts, and customize the appearance of the page.
The following Web Parts can be included with the Dashboard template.
Web Part Use to
Excel Web Access Display an Excel workbook, selected worksheets, or a named item, such as a named range or a chart.
KPI List Display a KPI graphic and the data behind it.
Filter (and Apply Filters button) Specify how to filter data and perform a filter operation.
Related Information Link to related pages.
Summary Describe information about plans and status.
Contact Details List the name of the person to contact about the dashboard

Open a workbook in Web browser view

Instead of opening a workbook in Microsoft Office Excel Web Access on a Web Part Page, you can open a workbook in Web browser view. Web browser view is a convenient way to display the workbook in the browser. For example, you may want to confirm the contents of a workbook that you just uploaded to a document library, or another user added the workbook and you are not familiar with the workbook contents. When you open a workbook this way, you display a Web page (xlviewer.aspx) that automatically uses the Excel Web Access Web Part for you.
1. Open the document library that contains the workbook.
2. Point to the workbook item.
3. Click the arrow next to it.
4. Click View in Web Browser.
TIP You may want to change the default action when you click an item in a document library to open the workbook in Web Browser view. On the document library toolbar, click Settings, click Document Library Settings, click Advanced settings under General Settings, and in the Browser-enabled Documents section, select Display as a Web page.
Display an Excel workbook in Excel Web Access

To view and interact with a Microsoft Office Excel workbook in Microsoft Office Excel Web Access, enter the workbook URL or UNC in the Office Excel Web Access Web Part Workbook property.
NOTE The workbook author should save the workbook from Microsoft Office Excel 2007 to a Microsoft Windows SharePoint Services document library or network folder by clicking the Microsoft Office Button , clicking Publish, and then by clicking Excel Services.
1. If necessary, create a Web Part Page and add the Excel Web Access Web Part.
For more information about creating Web Part Pages and adding Web Parts, see Microsoft Office SharePoint Services Help and Windows SharePoint Services Help.
2. In the opening instructions, click the link Click here to open the tool pane.
The Web Part Page and Web Part enter Edit Mode and the Web Part Tool Pane is displayed.
3. Enter the URL or UNC of the workbook in the Workbook text box.
To easily locate a workbook, click Select a Link and use the Select a Link -- Web Page Dialog window.
4. To save changes and exit Web Part Edit Mode, at the bottom of the Web Part Tool Pane, click OK.
5. To exit Web Part Page Edit Mode and view the workbook in Excel Web Access in Web Part Page Display mode, at the top of the Web Part Page, under the Site Actions drop-down menu, click Exit Edit Mode.
NOTE Alternatively, you can connect a List View Web Part of a document library to the Excel Web Access Web Part and then pass the URL of the workbook that is stored in the document library to the Excel Web Access Web Part. For more information, see Connect a List View Web Part to Excel Web Access.

Site Page Fundamentals

2007-10-18T10:01:00.000+05:30

Chapter 2, “SharePoint Architecture,” introduced you to the key differences between application pages and site pages. You learned that application pages have an advantage over site pages in that they perform better and provide a developer with the ability to add in-line code. You also learned that site pages have some key advantages over application pages because they can be created dynamically and can also be customized by users on a site-by-site basis.
Chapter 2 discussed the role of the SPVirtualPathProvider component and introduced the principles of page ghosting and unghosting. As you remember, page ghosting is an optimization used with site pages in which a single page template can be used to process multiple page instances across many different sites. For example, the home page for every team site in a Microsoft Windows SharePoint Services (WSS) farm is based on an underlying page template named default.aspx that resides on the file system of the front-end Web server. A page template, such as default.aspx, is compiled into an assembly dynamic-link library (DLL) and loaded into memory just once per Web application. However, this page template and its efficient usage of memory can still be used to serve up pages for thousands of sites. This is an obvious advantage toward scalability.
When a user customizes a site page by using the SharePoint Designer and then saves those changes, a customized version of the page definition is stored in the content database. While this provides flexibility from a customization standpoint, it also can have a negative impact on performance and scalability. When the customized page is requested, its page definition must be retrieved from the Backend database server by the SPVirtualPathProvider component and then fed to the ASP.NET compiler, where it is parsed and loaded into memory. You can imagine that a Web application with thousands of customized pages requires more memory because each customized page definition must be separately parsed and loaded into memory within the application pool that is hosting the current Web application.
You should note that customized pages are not processed by using the standard ASP.NET model in which a page is compiled into an assembly DLL. Instead, customized pages are parsed by the ASP.NET page parser and then processed using the no-compile mode feature that was introduced with ASP.NET 2.0.
As a developer, your initial reaction to this might be to question why customized pages are processed in no-compile mode. Your instincts likely tell you that compiled pages run faster than no-compile pages. However, no-compile pages can be more efficient and more scalable in certain scenarios. This is especially true in a large WSS environment where the number of customized pages can reach into the thousands or tens of thousands.
No-compile pages can be loaded into memory and then unloaded in a manner that is not possible for compiled pages because the .NET Framework doesn’t really support the concept of unloading an assembly DLL from memory. The closest equivalent would be to recycle the current Windows process or the current .NET AppDomain. However, this type of recycling involves unloading all assembly DLLs from memory, not just those assembly DLLs that haven’t been used recently. Furthermore, the .NET Framework places an upper limit on the number of assembly DLLs that can be loaded into a .NET AppDomain.
No-compile pages provide higher levels of scalability because they do not require loading new assembly DLLs or managed classes into memory. Instead, the processing of no-compile pages involves loading control trees into memory. WSS can manage the memory usage for the control trees associated with customized pages more efficiently because they are not compiled into assembly DLLs. For example, once WSS has finished processing a customized page, it can unload the page’s control tree to free up memory for other purposes. Furthermore, nocompile pages eliminate the need to go through the compilation process, which actually provides faster response times for pages upon first access.
Programming with SPFile Objects
WSS tracks each site page as a file within the content database. You can access a site page through the WSS object model by using the SPFile object. For example, assume that you want to program against the home page for a site. You can obtain a reference to the required SPFile object by using the GetFile method of a SPWeb object.
SPWeb site = SPContext.Current.Web;
SPFile homePage = site.GetFile("default.aspx");
The SPFile class makes it possible to read and write to the contents of a site page. For example, the OpenBinary method of an SPFile object returns a binary array containing the page contents. The OpenBinaryStream method returns a System.IO.Stream object. Each of these methods provides an approach for reading the contents of a site page. An SPFile object also provides a SaveBinary method that allows you to update the contents of a site page as well. Note that updating the contents of a site page by using this method customizes the page and moves it into an customized or unghosted state.
The SPFile class provides several other methods for managing site pages within a site such as Delete, MoveTo, and CopyTo. The Delete method, as its name implies, removes the target file from the site. MoveTo makes it possible to move a file, such as a site page, to another location so that it’s accessible through a different URL. CopyTo allows you to clone a site page with a copy. Note that if you call CopyTo on an uncustomized page, it creates another uncustomized page. Likewise, if you call CopyTo on an customized page, it results in the creation of a customized page in an unghosted state.
Tip
Ghosted and uncustomized are terms used to describe site pages served up using file system templates. Unghosted and customized both refer to pages that exist entirely in the database, which no longer depend on a file system template.
The SPWeb object for a site also exposes a Files property with a public Add method that allows you to add new site pages. There is an overloaded version of the Add method that allows you to pass a stream object with the contents of the new page. The following example demonstrates writing the contents of a new page to a MemoryStream object and then using it to create a new site page named Hello.htm.
// write out new page in memory stream
MemoryStream stream = new MemoryStream();
StreamWriter writer = new StreamWriter(stream);
writer.WriteLine("");
writer.WriteLine("Hello, World");
writer.WriteLine("");
writer.Flush();
// add new page to site
SPWeb site = SPContext.Current.Web;
site.Files.Add("hello.htm", stream);
Note that the Add method doesn’t support adding a new site page that is associated with an underlying page template. Therefore, site pages created by using the Add method are always created as customized pages in an unghosted state.
The SPFile class provides a CustomizedPageStatus property that makes it possible to determine whether a site page has been customized and placed in an unghosted state. The CustomizedPageStatus property is based on an enumeration type named SPCustomizedPageStatus. If a SPFile object for a site page has a CustomizedPageStatus property value of Uncustomized, it means that the page is still in a ghosted state. A site page with a CustomizedPageStatus property value of Customized has been customized and is in an unghosted state. The SPFile object also provides a method named RevertContentStream that removes any customizations and returns an unghosted page to its initial ghosted state.
SPFolder Objects
The files within a WSS site are structured within a hierarchy of folders. Each folder is represented in the WSS object model with an SPFolder object. Each SPFolder object contains a
Files property that allows you to enumerate through its files. If you want to enumerate through all of the files at the root folder of a site, you can access the RootFolder property of a SPWeb object and then use a foreach loop to enumerate through all of its files.
SPWeb site = SPContext.Current.Web;
SPFolder rootFolder = site.RootFolder;
foreach (SPFile file in rootFolder.Files){
// process each file
}
The WSS object model also makes it possible to enumerate through the folders within a folder. This, in turn, makes it possible to write code that enumerates through all of the folders within a site to discover all existing files. The following code displays an example of custom code that starts at the root folder of a site and uses recursion to populate an ASP.NET TreeView control.
const string SITE_IMG = @"\_layouts\images\FPWEB16.GIF";
const string FOLDER_IMG = @"\_layouts\images\FOLDER16.GIF";
const string GHOSTED_FILE_IMG = @"\_layouts\images\NEWDOC.GIF";
const string UNGHOSTED_FILE_IMG = @"\_layouts\images\RAT16.GIF";
protected override void OnLoad(EventArgs e) {
SPWeb site = SPContext.Current.Web;
SPFolder rootFolder = site.RootFolder;
TreeNode rootNode = new TreeNode(site.Url, site.Url, SITE_IMG);
LoadFolderNodes(rootFolder, rootNode);
treeSiteFiles.Nodes.Add(rootNode);
treeSiteFiles.ExpandDepth = 1;
}
protected void LoadFolderNodes(SPFolder folder, TreeNode folderNode) {
foreach (SPFolder childFolder in folder.SubFolders) {
TreeNode childFolderNode = new TreeNode(childFolder.Name,
childFolder.Name,
FOLDER_IMG);
LoadFolderNodes(childFolder, childFolderNode);
folderNode.ChildNodes.Add(childFolderNode);
}
foreach (SPFile file in folder.Files) {
TreeNode fileNode;
if (file.CustomizedPageStatus == SPCustomizedPageStatus.Uncustomized) {
fileNode = new TreeNode(file.Name, file.Name, GHOSTED_FILE_IMG);
}
else {
fileNode = new TreeNode(file.Name, file.Name, UNGHOSTED_FILE_IMG);
}
folderNode.ChildNodes.Add(fileNode);
}
}
Note that this code is also written to provide different images that allow the user to distinguish between pages that are customized and those that are uncustomized. A graphic of the resulting TreeView control is shown in Figure 3-1.
Figure 3-1: A WSS site contains a hierarchy of folders and files. Files such as .aspx and .htm pages can either be in an uncustomized or customized state.
Working with Page Templates
Up to this point, the discussion of page templates has revolved around using the standard page templates that are built into WSS. It is now time to explore how to create your own page templates and integrate them into a custom business solution. You can create and integrate custom page templates by using either a feature or a site definition. Because we have not yet discussed site definitions, this chapter focuses on the use of custom page templates within the context of a feature.
Examples of using page templates in this chapter are based on a Microsoft Visual Studio project named CustomSitePages that contains a feature of the same name. (The project is included on the companion Web site for this book.) Figure 3-2 displays the Solution Explorer window for this project. As you can see, the project contains a feature.xml and an elements.xml file like the other features that we built in earlier chapters. However, this feature also contains several .aspx files that are used to define site page templates, such as Page01.aspx and Page02.aspx. The CustomSitePages project also contains several ASP.NET user controls as well as the code for an ASP.NET custom control that will be discussed later in this chapter.
Figure 3-2: The CustomSitePages project demonstrates how to build a feature with custom site page templates.
If you open and build the CustomSitePages project, you find a post-build event that runs a batch file named Install.bat. This batch file copies the feature files along with the page templates into the proper location within the TEMPLATE directory and then installs the CustomSitePages feature by using the stsadm.exe command-line utility. Note that the CustomSitePages feature is designed to activate within the context of a site. After the feature is installed, you can activate it within any site in the current farm and follow along with these examples.
When the CustomSitePages feature is activated, it contains declarative logic in elements.xml to provision site page instances from its page templates. The code in the FeatureActivated event extends the navigation components of a WSS site by adding two new drop-down menus to the top link bar with menu items to navigate to the newly provisioned site page instance. The technique for adding these drop-down menus to the top link bar is explained later in this chapter.
Let’s start with a simple definition for a page template. Examine the following definition for the page template named Page01.aspx.
<%@ Page MasterPageFile="~masterurl/default.master"
meta:progid="SharePoint.WebPartPage.Document" %>

Hello World

A simple page template used to create site pages

The Page directive at the top of this page template assigns a value of~masterurl/default .master to the MasterPageFile attribute to link to the standard master page used by site pages within WSS sites. We will defer a more detailed discussion of master pages and the MasterPageFile attribute until later in this chapter. For now, simply assume that this site page template is designed to link to the standard master page.
You should also notice that the Page directive in the previous example contains a meta:progid attribute with a value of SharePoint.WebPartPage.Document. This attribute is included to make that page compatible with the SharePoint Designer, and is also available in the SPFile object’s ProgID property. Once site page instances have been provisioned by using this page template, users can open these pages with the SharePoint Designer and customize their content.
This simple example demonstrates the power and elegance of master pages in WSS development. You should be impressed at how little text is needed to define a simple page template. All that’s really required for a simple page template is to link to a master page and supply some unique content for the placeholder named PlaceHolderMain. As you learn more about how WSS uses master pages, you will discover that there are many more named placeholders that you can optionally override within your page templates to enrich them with all types of content such as controls, scripts, and styles.
Now that you’ve seen how to create a simple page template, it’s time to put it to use. Keep in mind that a page template, such as Page01.aspx, serves no purpose until you begin using it to provision site page instances. This can be done by creating a feature that contains a special type of element known as a Module.
A Module element can be thought of as a file set. When you create a Module, you add one or more inner File elements. The key point is that each File element is used to provision an instance of a file from a file template. Remember that the file template exists on the file system of the front-end Web server, whereas the file instance being provisioned is being created inside the context of a particular site.
In this particular case, we want to provision an instance of a site page from the page template named Page01.aspx. Note that the top-level directory of the CustomSitePages feature contains a nested directory named PageTemplates that contains all of the page templates. When you define a Module element, you can specify a Path attribute that points to a source directory, such as PageTemplates. You can also specify a Url element if you would like to instantiate the resulting site page instance within an inner folder instead of at the root folder of the target site.

Note that the File element within this example is created with a Url attribute that points to the source file for the page template. When you activate a feature that contains this Module element, WSS provisions a site page instance within the target site at the following relative path.
SitePages/Page01.aspx
The user can navigate to this page by using the Site Pages drop-down menu and clicking on the menu item with a caption of Site Page 1. Figure 3-3 depicts the resulting site page instance.
Figure 3-3: A Module element allows you to provision a site page instance from page templates.
Note that the File element in the previous example contains a Type attribute with a value of Ghostable. When a site page instance, such as Page01.aspx, is provisioned, it initially exists in an uncustomized state and benefits from the principles of page ghosting. This means that you can activate this feature in a thousand different sites within a Web application and that all sites use a single compiled version of the page. Page ghosting also makes it possible to make changes to the page template on the file system of the front-end Web server and have those changes affect all of the sites that have pages provisioned from this page template.
Only two possible settings exist for the Type attribute: Ghostable and GhostableInLibrary. These two settings are used to differentiate between files that are provisioned inside a document library and those that are not. In this case, the site page instance has a Type of Ghostable because it is not being provisioned inside a document library. Later in the chapter, you will encounter an example of a File element whose Type attribute value will be defined as GhostableInLibrary.
You should also note that when defining a File element, you can optionally include the Name element. This makes it possible to provision a site page instance with a name that differs from the name of the underlying page template. This technique wasn’t used in the previous example, so the resulting site page instance was provisioned with the same name as the page template. However, you can extend the Module element shown earlier to provision several different site page instances from a single page template and give them all different names.

Safe Mode Processing
It’s important to understand that all customized site pages are parsed and processed in a special mode known as safe mode. The primary motivation for safe mode involves the fact that standard users can modify the contents of site pages. In other words, a user (such as a site owner) possessing no administrator privileges within the farm can make any modifications to a page within a site. Consider a scenario in a large farm in which a site administrator attempts to mount an attack on the Web server by writing C# code within a customized site page inside an in-line script block. Safe mode prevents this type of attack by disallowing in-line script in any customized source.
Examine the code in the page template named Page02.aspx. It contains a simple in-line script to write a message back to the browser.
<%@ Page Language="C#" MasterPageFile="~masterurl/default.master"
meta:progid="SharePoint.WebPartPage.Document" %>
ContentPlaceHolderID="PlaceHolderMain">

Page 2

<% Response.Write("Hello world from server-side script!"); %>

Note that this page and the in-line script run just fine as long as the page remains uncustomized in a ghosted state. Remember that WSS compiles a ghosted page into an assembly DLL for processing. However, as soon as a user modifies any aspect of this page with the SharePoint Designer and moves the site page into an unghosted state, WSS then begins to use safe mode to process it. Because the page contains in-line script, WSS refuses to process it in safe mode and generates the error message shown in Figure 3-4.
Figure 3-4: Customized pages run in safe mode and cannot contain in-line script.
You obviously don’t want your users to experience error messages like the one shown in Figure 3-4. For this reason, you should avoid adding in-line script to page templates. Following this guideline helps to eliminate scenarios in which pages mysteriously stop working after they are edited by users with the SharePoint Designer.
In rare cases, you might decide to turn down or turn off the protection afforded by safe mode. In this situation, you can add an entry to the web.config file of the hosting Web application to instruct WSS to change the behavior of safe mode processing. For example, assume that you want to allow in-line scripts for site pages inside the SitePages folder in a site at the path of /sites/Sales. You can accomplish this by adding the following PageParserPath element within the SharePoint section of the web.config file.

VirtualPath="/sites/Sales/SitePages/*"
IncludeSubFolders="true"
CompilationMode="Always"
AllowServerSideScript="true" />

If you examine the PageParserPath element, you see that the VirtualPath attribute has a Web application relative path followed by an asterisk, which includes every site page in that particular folder. Also note that the CompilationMode attribute has a value of Always and the AllowServerSideScript attribute has a value of true. This instructs the safe mode parser to compile all site pages into assembly DLLs and allow in-line script.
Note that a page must be compiled into an assembly DLL to support in-line script, which means that it is not valid to assign a value of Never to the CompilationMode attribute while assigning a value of true to the AllowServerSideScript attribute. Also note that you can assign a value of Auto instead of a value of Always to the CompilationMode attribute. This has the effect of compiling only pages that contain in-line script. When the CompilationMode attribute has a value of Auto, pages without in-line script are still run in no-compile mode.
It is possible to enable in-line script for all site pages within a Web application by configuring the VirtualPath attribute with a value of /* and then setting the CompilationMode attribute to a value of Always or Auto. However, two significant factors should motivate you not to do this.
The first factor is security. By enabling in-line script for all site pages within a Web application, you open the door to attacks on the Web server because any user who has the ability to customize a page can freely write managed code that executes on the Web server.
The second factor pertains to scalability. Earlier in this chapter, I discussed how no-compile pages are more scalable than compiled pages in a large Web application. WSS experiences scaling problems if your Web application attempts to compile and load thousands of assembly DLLs for all of your customized pages. At the very least, you should prefer a CompilationMode setting of Auto instead of Always so that only pages that actually contain script are compiled into assembly DLLs, whereas those pages that do not contain script continue to be parsed and processed in no-compile mode.
Safe Controls
Safe mode processing goes a step beyond protecting against in-line script by also considering what controls a user might place on a customized page. For example, imagine a scenario in which a site administrator tries to mount an attack by adding a server-side control to a site page and parameterizing it in a certain way. Safe mode allows the farm administrator to determine which controls can be used in pages that are processed in safe mode.
Customized pages can only contain server-side controls that are explicitly registered as safe controls. Registering a control as a safe control is accomplished by adding a SafeControl entry into the web.config file for the hosting Web application.

Assembly="Microsoft.SharePoint, …"
Namespace="Microsoft.SharePoint.WebControls"
TypeName="*"
AllowRemoteDesigner="True" />

Note that the standard web.config file for a Web application automatically includes SafeControl entries for the standard server-side controls and Web Parts included with ASP.NET and WSS. In the next section, you will learn how to add a SafeControl entry that is required to place a custom server-side control on a customized page. In Chapter 4, “Web Parts,” we will revisit the topic of safe controls and discuss how they pertain to custom Web Part deployment.
Note that a PageParserPath element, in addition to allowing in-line script, can also override the default safe mode behavior and allow for server-side controls that are explicitly registered as safe. For example, you can allow the users of a particular site to add any server-side controls to customized pages by using the following entry within the web.config file.

VirtualPath="/sites/Sales/*"
AllowUnsafeControls="true" />

Note that using this option affects only which server-side controls can be added to a page when customizing a page with a tool, such as the SharePoint Designer. This configuration option does not extend to control instances when users are adding Web Parts to Web Part zones on a page through the browser. Assembly DLLs containing Web Parts must always be explicitly registered by using SafeControl elements for users to be able to place them inside Web Part zones.
Although you have just learned several ways to disable safe mode or lessen its effects, you should remember to proceed here with extreme caution. It’s usually best to leave safe mode with its default behavior. WSS was engineered with safe mode processing to protect the farm from attacks and allow WSS to scale out the way it was designed in large farm environments.

Sharepoint server 2007 security

2007-10-17T18:12:00.001+05:30

Trust Levels and Code Access Security
Code access security, commonly referred to as CAS, defines the execution permissions granted to a piece of code that runs in a partially trusted location. This concept is similar to user authorization, although it is the code and not a user account that is authorized. A partially trusted location does not fully trust the code that it contains and creates a restricted security context (that is, a sandbox) to isolate its code from the rest of the system.
Because the partially trusted location runs with restrictive permissions, it limits the attack surface of the system and is the most secure location from which to run code. The partially trusted location allows code to run in predefined security contexts without risk of compromising critical personal or corporate data. In WSS, each Web application’s bin directory is a partially trusted location in which code access security is enforced. Because of this fact, it is the preferred location to deploy Web Part applications. The least trusted location is the most secure place from which to run your code. Likewise, code that is trusted the least is the most secure because it is less likely to compromise the system.
The most common misunderstanding about CAS policy is that developers often think the least-trusted code is bad because we don’t trust it, and the code that we fully trust must be good. (We do trust it, don’t we?) In fact, the opposite is true. Because we do not grant trust for an unknown functionality, we know that we can trust the code not to execute malicious operations beyond its scope of defined trust. It is similar to having a dog on a leash. If the dog is loose, it may or may not behave. Yet the cat across the street may be too difficult to resist even if the dog does behave 99 percent of the time. If the dog is on a leash, however, you can trust that it will not run into the street. It is more trustworthy because there is an element of control that forces it to behave, regardless of the cat across the street.
Tip
Least-trusted code is the most trustworthy code.
The Global Assembly Cache (GAC) is a fully trusted location for WSS, as is the _app_bin location. (The _app_bin location is a special location for WSS infrastructure components that should not be used for custom code.) Certain WSS components, such as feature receivers and event handlers, must be deployed to the GAC, so you should create separate assemblies for Web Parts to enable deployment in the bin directory. You should also think of your Web Part assemblies as security containers, in which the CAS policy is applied to the entire assembly. You may wish to limit the scope of a Web Part assembly by the security that it requires. If you have Web Part code that requires an abnormal amount of trust, it may be better to isolate that component in a security-isolated assembly rather than raise the trust of the rest of your code.
Tip
The Web application’s bin directory is the preferred location for Web Part code because it has the most secure CAS policies. Web Part assembly DLLs that are installed in the GAC always run with full trust and cannot benefit from the ability to run code with partial trust in WSS.
CAS policies are aggregated into ASP.NET trust levels. Trust levels for the WSS Web application are defined in XML files and referenced in the Trust element of the web.config file. The trust level defines the amount of trust that is granted to predefined code groups running within the Web application context. This condition applies only to Web applications where code is deployed in the bin directory as a partially trusted code location. Code that runs as event handlers, admin console applications, or any other application outside of the Web application is not restricted and runs in full trust.
Default settings in the web.config for both WSS and Microsoft Office SharePoint Server (MOSS) run Web applications under a level of minimal trust. The custom trust levels that WSS defines and runs under are defined in the 12\CONFIG directory and include WSS_Minimal and WSS_Medium. These files are located at 12\config\wss_minimaltrust.config and 12\config\wss_mediumtrust.config. WSS also manages custom trust levels, defined as WSS_Custom, that are derived from solution package CAS policies. These CAS policy files are defined by the system by copying the most recent policy file and applying updates as needed. WSS maintains a change set per installed solution package. As a solution package is either deployed or retracted, it modifies the web.config of the Web site to which it is being installed.
Although most WSS developers tend to ignore CAS and the WSS trust levels by simply running in the full trust level or installing to the GAC, it is important to understand how WSS manages CAS because you might not be in control of the deployment environment. Although you can also bypass CAS entirely by running your assemblies in the GAC, this is not as secure as using controlled CAS policies. CAS policies affect not only your code, but all assemblies that might be available in the application. If you do not want to deal with CAS policies, it is better to install to the GAC than to set the trust level to full trust.
The benefit of strict CAS policies is that they allow the code to perform only trusted operations. For example, if you run in a restricted CAS policy (such as one derived from WSS_Minimal) that allows your code to call into the WSS object model, security demands within your code can prevent an untrusted assembly from using your code to call into the WSS object model. You can also have code that is allowed to make calls to certain trusted online XML data sources, such as security-scrubbed RSS feeds from NewsGator Online, while disallowing Web requests to unknown XML data sources by using the WebPermission’s ConnectAccess property. CAS policies allow IT to use third-party components without enabling the same level of trust that is granted to internally generated code or limiting the context in which code can execute. Web Part solutions that contain feature receivers should place the feature receiver in an external assembly that can be GAC installed, thereby maintaining a restrictive CAS policy for the Web assembly.
Tip
Full trust escalates trust not only for your Web Part assembly DLL, but for all Web Part assembly DLLs.
The WSS_Minimal trust level denies code the right to execute certain calls or access certain resources such as Structured Query Language (SQL), Web requests, and even WSS object model access. These permissions are defined as CodeAccessSecurity classes and CodeAccessSecurityAttributes that are defined and demanded in the .NET Framework and Microsoft.SharePoint.Security.dll assembly. The WSS_Minimal trust level is the most secure, in which only Microsoft Web Parts and very basic functionality in custom Web Parts can execute. WSS_Medium is a common choice for most organizations because of its ease of development for Web Part developers, maintaining a balance of trust and ease of configuration. On the other hand, the default WSS_Minimal trust level is the most secure but requires more work to configure custom applications. As a SharePoint developer, you should always create components that can be installed to WSS_Minimal trust, with explicit trust policies documented and included in the solution package.
Tip
When using WSS_Minimal trust and solution-managed trust levels, WSS manages the trust levels and creates custom trust levels based on the original configuration and installed solution packages. This is the recommended approach to maintaining WSS trust levels.
Within certain environments, you may wish to switch the trust level from WSS_Minimal to WSS_Medium or even full trust. This can be a viable choice for initial development environments, but for commercial or enterprise applications, you want to ensure that your solution has the correct permissions to execute (and no permissions not needed to execute). You may often want to develop in full trust and switch to WSS_Minimal to test your solution package deployments.
Tip
As discussed in Chapter 9, “Solutions and Deployment,” solution packages are the supported and recommended way to set custom security levels. Other than switching the trust level during initial development, editing and managing security manually in configuration files is not maintainable on large scales and is not a recommended practice.
To examine the security ramifications of code access security, we will examine the SecurityWebPart code in Listing 10-1 that contains several security-sensitive calls, each of which demands a more sensitive security level. This Web Part runs in its entirety only in full or custom trust levels unless it is deployed to the GAC. For initial development (on the development box), we will deploy this assembly in full trust mode.
Listing 10-1: The example SecurityWebPart class demonstrates CAS security policies.
CAS Example: Security Web Part
using System;
using Microsoft.SharePoint;
using System.Security.Principal;
namespace LitwareSecurity {
// An example Web Part demonstating CAS requirements
public class SecurityWebPart : System.Web.UI.WebControls.WebParts.WebPart {
protected override void RenderChildren(System.Web.UI.HtmlTextWriter writer) {
// Runs in WSS_Minimal
writer.Write(string.Format("Thread.CurrentPrincipal: {0}
",
System.Threading.Thread.CurrentPrincipal.Identity.Name));
// Requires System.Security.Permissions.SecurityPermission
// with SecurityPermissionFlag.ControlPrincipal
// denied in the WSS_Minimal trust level..
writer.Write(string.Format("Current user: {0}
",
WindowsIdentity.GetCurrent().Name) );
// Requires System.Security.Permissions.SecurityPermission
// with SecurityPermissionFlag.ControlPrincipal
// denied in the WSS_Minimal trust level.
using (WindowsImpersonationContext wic =
WindowsIdentity.Impersonate(IntPtr.Zero)) {
writer.Write(string.Format("Impersonated application pool user: {0}
",
WindowsIdentity.GetCurrent().Name));
}
// Requires Microsoft.SharePoint.Security.SharePointPermission
// with ObjectModel = true
// denied in WSS_Minimal, allowed in WSS_Medium
writer.Write(string.Format("Current site: {0}
",
SPContext.Current.Web.Title ));
// Requires Microsoft.SharePoint.Security.SharePointPermission
// with Impersonate=true
// denied in the WSS_Medium trust level,
// allowed in Full or custom permissions
SPSecurity.RunWithElevatedPrivileges( delegate() {
writer.Write(string.Format("RunWithElevatedPrivileges user: {0}
",
WindowsIdentity.GetCurrent().Name));
}
);
}
}
}
However, before deploying to a staging, quality assurance, or production environment, we want to create a solution package with the appropriate CAS policies. The LitwareSecurity Web Part project is included in the code samples and includes the Web Part in Listing 10-1. To see CAS in action, first deploy the LitwareSecurity assembly manually in full trust mode. Next, add an instance of the SecurityWebPart to the page. Running this Web Part in anything but full trust breaks the Web Part.
To examine the effects of code access security, run this Web Part code in full trust and then reduce the trust levels to see what breaks. When reducing trust to WSS_Medium or lower, you will see an error message similar to the following:
The "SecurityWebPart" Web Part appears to be causing a problem. Request for the permission
of type 'Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security,
Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' failed.
Although we cannot grant the CAS policy for the assembly within the assembly itself, we can define it within the solution package and set it during the installation. During initial development, we might choose to simply run the Web application in full trust for rapid prototyping, but we want to sign the assembly and set its trust level explicitly before deployment. Within the assembly, we also request the security permissions it requires, which causes an early failure at deployment time rather than a more obscure runtime error. Failed permission requests cause the assembly not to load and provide details in the form of a System.Security.Policy.PolicyException, with a message stating something similar to “Required permissions cannot be acquired.” By providing requests, we are letting the runtime know which permissions we require. The following example displays the permission request for the SharePoint permission.
[assembly: SharePointPermission(SecurityAction.RequestMinimum, ObjectModel=true)]
By specifying the security action RequestMinimum, we are letting the runtime know that this is a minimal permission grant required for the assembly to run correctly. We could also use the RequestOptional security action that lets the runtime know that we would like a certain permission, but our assembly will still run even though it may be less functional without this permission. For example, we may want to enable certain functionality that requires permissions to use the SQL client, but this is not required for all Web Parts. Within the assembly, we could specify this by using the following permission request.
[assembly: SqlClientPermission(SecurityAction.RequestOptional, Unrestricted=true)]
Likewise, if you want to refuse certain permissions from your assembly to take extra precautions to defend against luring attacks, you could use a RequestRefuse security action. The following permission refuses to allow the SQL client permission.
[assembly: SqlClientPermission(SecurityAction.RequestRefuse)]
Security requests from the assembly do not grant the permissions. They only let the runtime know that the permissions are required for execution. For the LitwareSecurity assembly, prior to creating the policy in the solution package manifest, we will first document the intentions and needs of the assembly by performing the correct permission requests in the assembly information file. The following permission requests define the required minimal permissions needed for the LitwareSecurity assembly as well as some optional permissions required for our SecurityDebugWebPart Web Part.
// Minimum permissions for the assembly to load:
[assembly: AspNetHostingPermission(SecurityAction.RequestMinimum)]
[assembly: SecurityPermission(SecurityAction.RequestMinimum,
Execution=true)]
[assembly: SharePointPermission(SecurityAction.RequestMinimum,
ObjectModel=true, Impersonate=true, UnsafeSaveOnGet=true)]
// Required by the optional Security Debug Web Part:
[assembly: EnvironmentPermission(SecurityAction.RequestOptional)]
[assembly: SecurityPermission(SecurityAction.RequestOptional,
ControlPrincipal = true)]
After defining the permission requests, the next step is to configure the CAS policy for the assembly. We will do this through the solution package, first by signing the assembly with the Litware public key and then by defining security policy in the solution package manifest.
Tip
For a refresher on solution packages, see Chapter 9.
You can modify the solution manifest file to grant the required CAS levels for your Web Part assembly DLLs. When defining CAS policies, you can define the trust based on the assembly’s public key BLOB that is shared by all assemblies signed with your private key, or you can configure more granular trust based on the location of the assembly. Listing 10-2 shows a solution manifest that defines the permissions for Litware Security example code.
Listing 10-2: Security policy in the solution manifest
Litware Security Solution Package Manifest
xmlns="http://schemas.microsoft.com/sharepoint/">

Description="Permission set for LitwareSecurity">

Flags="Execution,ControlPrincipal,UnmanagedCode" />

version="1" Read="UserName" />

Namespace="LitwareSecurity" TypeName="*" Safe="True"/>

Note that within the solution manifest, each permission is defined in a NamedPermissionSet element. WSS creates a named permission set from this information. Within the permission set is a list of IPermission nodes, each of which defines a permission we are granting to members of this permission set. These IPermission nodes match the security requests we have already defined on the assembly. The three SharePoint permissions are also available in XML files in the 12\config folder. For a listing of the most common permissions used in WSS code, see the sidebar “Common Permission Definitions for WSS Applications” that follows.

Common Permission Definitions for WSS Applications
SharePointPermission Defines permission to access the object model and permission to impersonate. ObjectModel, UnsafeSaveOnGet, and Impersonate are the optional properties that define the actual permission. UnsafeSaveOnGet specifies that the code has permission to update the database on a GET request. Note that this is also required for Web Service updates.

EnvironmentPermission Defines permission to access the environment, including the current Windows user.
Read="UserName" />
SecurityPermission Defines permissions specified by the SecurityPermissionFlag enumeration including AllFlags, Assertion, BindingRedirects, ControlAppDomain, ControlDomainPolicy, ControlEvidence, ControlPolicy, ControlPrincipal, ControlThread, Execution, Infrastructure, NoFlags, RemotingConfiguration, SerializationFormatter, SkipVerification, and UnmanagedCode. The WSS_Minimal trust level grants the SecurityPermission with the only Execute flag to code running in the bin directory.
Flags="Execute" />
AspNetHostingPermission Defines permission to access protected ASP.NET controls. This permission is granted in the WSS_Minimal trust level.

WebPermission Defines permission to access Web resources, including Web services. The ConnectAccess element defines which URLs can be accessed.

The permissions defined in the solution manifest are applied to the custom permission configuration managed by WSS. The following permission set is generated from the solution package.
Name="litwaresecurity.wsp--1">

version="1" ObjectModel="True" Impersonate="True" />
Flags="ControlThread, UnmanagedCode" />

From the solution package, WSS modifies a copy of the WSS_Minimal permission set (or whichever permission set is referenced from web.config). For each solution package, a corresponding PermissionSet is created. The manifest GUID is applied to the solution package name, and a corresponding CodeGroup element is created. This code group is assigned to a permission set, and all code that matches its membership conditions is assigned this permission. In this case, the LitwareSecurity.dll assembly located in the bin directory is assigned to this permission set. The following code group is created from the solution package in the security configuration.

Url="$AppDirUrl$/bin/LitwareSecurity.dll" />

The Listing 10-1 code example presented four methods that deal with identities and security. Each of these methods requires a specific grant of trust in order to execute. Because code access security is explicitly defined, it can be used to identify and audit security risks of an application. For example, we know that this assembly cannot be used to compromise a sensitive SQL database because we know it does not have the required permissions. Likewise, because this assembly does not have the System.Net.WebPermission granted, we know that it cannot be used to send data to remote Web endpoints regardless of any malicious code it could contain. Likewise, you could grant a restrictive System.Net.WebPermission that allows HTTP requests only to trusted endpoints, which enables the IT organization to limit its portal’s attack surface by restricting executable code to predefined sandboxes. In securitysensitive environments, the manifest file of the solution package is an auditable asset that should be examined before deployment.
Troubleshooting Code Access Security
Before deploying your solution package, you want to test it against the WSS_Minimal trust level. To do this, set the trust level to WSS_Minimal and run your installer script. Then, place Web Parts from the package on a Web Part page. If your code has not been granted the correct permissions, its security demands will fail. In the Web browser, you may get a security exception stating that the request for a security permission failed. At this point, you can search for the permission type in a tool, such as the Microsoft Visual Studio Object Browser, to find the arguments for the permission type. WSS permissions are defined in the 12\config directory; however, you may need to search MSDN or the appropriate class library for the correct properties and syntax. In general, permissions take the form of .
Next, examine the created permission set in the 12\config directory that corresponds with the WSS_Custom permission referenced in the web.config you are testing. Another common error is invalid configuration of the membership configuration. If you are not getting the expected results, check the IMembershipCondition element of your code group. For bindeployed assemblies, this is either the public key BLOB from the signed assembly manifest or the URL of the assembly location, such as $AppDirUrl$/bin/LitwareSecurity.dll in our example. This URL is created based on the assembly name in the solution manifest (without the file extension suffix), which is the simple file name and not the strong name of the assembly. The solution package creates either UrlMembershipCondition references based on the file name or StrongNameMembershipCondition references based on the public key BLOB from the assembly manifest.
Tip
Microsoft Visual Studio 2005 Team Edition for Software Developers contains code analysis tools to help you write more secure code. Analyzing your code with Visual Studio exposes and helps you fix common CAS-related security vulnerabilities.