Does SharePoint Portal Server support document encryption?
SharePoint Portal Server 2003/Microsoft Office SharePoint Server 2007 can be configured to leverage Rights Managenent Service (RMS) which allows for the encryption of documents through RMS policy each time a document is requested from a Document Library, the RMS policy will be applied to documents whether they are requested through the Office client, WebDav or FrontPage – RPC.
* While SQL Server 2005 supports certificate-based encryption within the store, encryption will have to be manually implemented through stored procedures using the new SQL Server 2005 TSQL support and technologies for certificate management and encryption. As a result, a SharePoint Portal Server implementation of these technologies is not supported.
Are encrypted documents indexed?
Windows RMS will provide the capability to envelope e-mail and Office Documents that provide limitations as to what actions a user can perform against that file through Information Rights Management (IRM) in Microsoft Office 2003 in addition to adding the capacity to add document expiration, check-in limitations, and more. For additional information surrounding IRM I recommed visiting: http://office.microsoft.com/en-gb/assistance/HA011401841033.aspx. In Microsoft Office SharePoint Server 2007 server integration with RMS and integration with other RMS systems permits policies set on Document Libraries to apply to files that have left the site; with this in mind, the immediate benefit results in the content within the Document Library to be indexed by Microsoft Office SharePoint Server 2007.
Before you can leverage RMS and IRM you must deploy an RMS system in your environment; for additional information on planning and deployment of an RMS system, visit http://technet2.microsoft.com/windowsserver/en/technologies/featured/rms/default.mspx.
Prior to upgrading to Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0 one of the prerequisites some of you may have already noticed is running PRESCAN.EXE from the installation directory. This post will hopefully provide some insight into PRESCAN.EXE as well as best practices on when it should be run.
PRESCAN.EXE has two primary purposes:
- It parses and saves List definitions with the associated Lists. SharePoint Portal Server 2003 Service Pack 2 already incorporates this feature whenever a list is modified; however, this process should be completed for all Lists, so prescan calls the SharePoint Portal Server 2003 Service Pack 2 method to persist that data.
- PRESCAN.EXE will report on common issues that will result in a failed upgrade; therefore, running PRESCAN.EXE, addressing reported issues, and resolving those issues, and re-running PRESCAN.EXE to verify those fixes is a best practice when planning a Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0 upgrade. The most commonly detected issues are:
- Database Orphans This is a class of issue where an object exists, but the pointer with the parent object is broken and/or corrupt. Classic examples include situations where a site exists in the content database; however, does not exist in the configuration database and a web that points to a site collection that no longer exists.
- Missing Site Definitions This issue is rare at best ad exists when a site collection has been removed/deleted – sites under this classification will not be upgraded and in addition those sites will not render in SharePoint Portal Server 2003/Windows SharePoint Services 2.0.
Typically these issues will manifest as a result of failed STSADM backup and restore sequences, but also can occur at the SQL level.
Depending on the nature and growth of your environment, PRESCAN.EXE is best run one (1) week prior to the production upgrade allowing time to address issues uncovered, and again prior to the upgrade itself to ensure that those previous issues have been resolved in addition to identifying new issues, if any.