Configuring Security on the Records Center

The security settings for the Records Center site are even more critical for your enterprise information management environment than security on other SharePoint sites. Once a repository is defined and users begin submitting documents to it, they will expect that those documents are safe, secure, and immutable until the documents expire and are purged. If documents in the repository can be edited or deleted outside of the defined file plan rules, the Records Repository site loses its value as a records store. For this reason, you should design and implement a much stricter set of security settings on the Records Repository site than might be necessary on most SharePoint Server 2007 sites.

Important 

The Records Center site template does not have a higher intrinsic security level than other SharePoint Server 2007 sites. It is up to you to craft a tight security environment.

It is highly recommended that you create a separate Web application for each Records Repository. This helps ensure that security is maintained at the highest level by removing any implicit or inherited permissions that might be present on an existing Web application or parent site. After creating the repository Web site, you must consider what rights users will need to interact with the site. Table 10-4 lists the various rights required to perform operations on the site.

Table 10-3: Records Center Required Rights
Open table as spreadsheet

Task	Required right
Submit to repository	Read Item right in source site
	Add Item right in repository
Call the Records Repository Web Service	Edit Item right in the repository
Manage records	Edit Item right in repository
Create record series entries	Add Item right in Record Routing list
Create holds	Add Item right in Holds list
Manage and release holds	Edit Item right on file that is on hold
	View Item right on Holds list
View documents in search results	Read Item right in repository

Configuring User and Group Permissions

In most cases, documents will be submitted directly to the Records Repository by users who are responsible for the content of the document. They will use a menu item on the Send To menu (discussed in the "Submitting Content to the Records Center" section) to send a copy of the document through the Records Repository Web Service. The Send To command executes the call to the Web service under the Application Pool Identity account associated with the source site's Web application. This architecture allows users to submit documents without having permissions to add items directly to the Records Repository site. The recommended approach is to grant only the Application Pool domain accounts the right to add items to the repository.

The Records Center site automatically creates the "Records Repository Web Service Submitters for [site name]" user group and gives it permissions to submit records to the site using Web Services. You can use this group to grant limited rights to Application Pool accounts to add documents to the site. Other rights that you will have to assign to users will be Read rights for users who need to search for and retrieve documents from the repository for research or historical review purposes. Records managers in the Records Repository site need to have Edit Item rights to manage the documents that have been submitted and Create Item rights in the Record Routing and Holds lists. In general, a best practice is to set the security level to give most users the correct permissions across the site, and then grant selected users or groups elevated permissions where necessary. You might also need to restrict permissions on some items even further. Although there is no explicit "deny" right at the list level, you can remove specific groups from document libraries that should have restricted access.

Best Practices 

Configure all users to have Read permissions on the Records Repository for search and retrieval purposes. Configure a smaller group of records managers to have Edit permissions on the Records Repository.

Configuring Policy Settings in Central Administration

In Central Administration, administrators can control the settings that apply to all policies across the server farm. To access these settings, open the Operations page in SharePoint 3.0 Central Administration and click the Information Management Policy Configuration link under Security Configuration. For each of the policy features (Labels, Auditing, Expiration, Forms Conversion For Archiving, and Barcodes), the administrator has the option to make the policy available (the default setting) or to deactivate it for all future uses of the policy. To disable the policy, the administrator can select the Decommissioned option, which leaves the policy feature available for any sites that currently use the policy but prevents any new uses of the policy. Decommissioning a policy actually removes the policy setting from the Edit Policy page for any newly defined information management policies.

From the Central Administration page, you can configure the schedule on which Expiration policies are processed and force the processing of expiration policies. The default schedule for expiration processing is once every 24 hours, starting at 11:00 PM, as shown in Figure 10-15. Because expiration processing places additional load on the server, you should change the start and end times so that they do not overlap with data-backup or content-indexing operations. In cases where it is not mission-critical that documents be purged immediately, and where it is difficult to schedule a daily time slot for the processing, you can configure the processing to run on a weekly or even a monthly basis. SharePoint Server 2007 will process all documents that have expired since the last processing run. Be sure to allow the server a longer period of time between the start and end times so that it can complete the processing of all documents marked to expire.

Figure 10-15: Configuring the expiration policy

The other policy that allows for additional customization is the barcodes policy. If you have installed one or more custom barcode generators, you can choose one in Central Administration using the Barcode Style list. By default, only one style is available, which is the ANSI/AIM BC1-1995 (Code 39) style. For the default style, you can also choose whether the barcode should be generated with only numbers (0 through 9) or with both numbers and letters (A through Z). The 10-digit format used by SharePoint Server 2007 for generating barcodes results in 10 billion combinations when using the numeric-only format. Normally that would be enough, but for greater randomness and variation, the alphanumeric format provides 4.8 quadrillion possible values.