-
When SharePoint 2007 was in beta, I wrote a blog article about how to install it on a single machine. This was one of my most popular articles so I thought I’d repeat the process for SharePoint Server 2010 Beta 2.
This article should be read in addition to the official installation guide on TechNet.
Update 21/11/1009: Jie Li also has a great list of tips and resources which he seems to be keeping up to date as information is uncovered. I strongly recommend that you read his Installation Notice for SharePoint 2010 Public Beta article in addition to this one.
This article is based on using Windows Server 2008 R2 as your host OS; SharePoint 2010 can also be installed on Windows 7, but these steps are designed for installing on Windows Server 2008 R2 as I think that will be the most common scenario in dev/test environments. Please see the information about a hot fix required for Windows Server 2008 R2 in the 'general prerequisites' section.
For the purposes of this article it does not matter if the host OS is physical or virtual, however I imagine that most readers will be using virtualisation initially to test these steps out.
Bear in mind that SharePoint 2010 will only run on a x64 OS which excludes being able to use Microsoft Virtual PC 2007 or Microsoft Virtual Server 2005 as they can only host x86 guests. This only leaves either Windows Server 2008 Hyper-V hosted VMs or Windows 7’s ‘VHD Boot’ feature as valid virtualisation options (from the Microsoft stack at least).
General Pre-Requisites
Update 23/11/2009: I have updated my advice to use a full install of SQL Server 2008. Previously, I had advocated using the built-in version of SQL in what is known as a ‘standalone’ configuration, but there are a few bugs with this is beta 2 so I’ve update this article for a full install of SQL 2008 in what is know as a ‘farm’ configuration. As a result this whole section of the article has been updated.
Ensure your machine meets the following pre-requisites:
Downloading the SharePoint 2010 and Office Web Applications
In order to get the best experience in SharePoint 2010 you actually need to install two separate pieces of software, both of which are available on MSDN subscriber downloads if you are a subscriber.
The two packages you should download (in addition to the various patches outlined in the ‘General Pre-Requisites’ section) are:
- SharePoint Server 2010 beta (under ‘servers’). The filename is ‘en_sharepoint_server_2010_beta_x64_x16-19249.exe’
- Office Web Applications beta (under ‘applications’)
Don’t forget to also get your product keys.
If you are not an MSDN subscriber, you can register to download SharePoint 2010 here.
SharePoint 2010 Pre-requisites
SharePoint 2010 has several pre-requisite pieces of software which are neatly packaged into a pre-requisite installer that comes with the download. The server will need to be connected to the internet during this stage as it will download the latest versions of various beta components. If you cannot get your server online, you can download the pre-requisites separately, refer to Jie Li’s SharePoint 2010 Pre-Requisites Download Links article for the links.
To install the prerequisites, follow these steps:
- Run ‘en_sharepoint_server_2010_beta_x64_x16-19249.exe’ (see downloads section above)
- When the ‘SharePoint Server 2010’ menu screen pops-up, choose ‘Install software prerequisites’
- On the ‘Welcome’ screen click ‘Next’
- Accept the license agreement and click ‘Next’
- When the installation is complete, click ‘Finish’ and reboot your server (setup does not mandate that you do this, but I have found that installations generally go better if you do this)
Installing SharePoint Server 2010
This section will guide you through the base installation of SharePoint 2010.
- Run ‘en_sharepoint_server_2010_beta_x64_x16-19249.exe’ (see downloads section above)
- When the ‘SharePoint Server 2010’ menu screen pops-up, choose ‘Install SharePoint Server’
- When prompted enter your product key and click ‘Continue’. If you are an MSDN subscriber, you can download the key from the same place that you got the software from. If you are not an MSDN subscriber, Jie Li’s SharePoint Server 2010 beta key article will help you.
- Accept the License Agreement and click ‘Continue’
- Select ‘Server Farm’ as the installation type. This means that a separate installation of SQL Server 2008 is required.
- Select ‘Complete’ as the server type and click ‘Install Now’. This means that you have all available components installed.
- The installation will now take place, this typically takes about 20 minutes. The final ‘applying updates’ phase does take a particularly long time, but do not worry it will finish eventually. Why not check out some of my team’s great blog articles on SharePoint 2010 whilst you wait? (shameless plug, I know .. sorry! :) )
- Once the installation is complete, you will see a ‘Run configuration wizard’ screen. Keep the ‘Run the SharePoint products and Technologies Configuration Wizard now’ box ticked and click ‘Close’. This will start the farm configuration wizard.
- Click ‘Next’ on the ‘Welcome’ screen
- Click ‘Yes’ on the warning about restating services.
- Choose to ‘Create a new server farm’ and click ‘Next’
- Specific the name of your SQL server and an account that SharePoint will use to access it and click ‘Next’
- Enter a passphrase which will be needed if you add more servers to the farm and lick ‘Next’
- Accept the default settings for the Central Administration Web Application and click ‘Next’
- On the ‘Competing the SharePoint products Configuration Wizard’ screen, click ‘Next’. This will initiate the configuration and may take some time to complete.
- When the configuration process is complete you’ll see a ‘Configuration Successful’ screen, click Finish on this. Doing this will open the browser at the default web application and prompt you to create a new site. Close the browser at this point.
At this point SharePoint 2010 is installed and a default farm has been configured.
As with SharePoint 2007, SharePoint 2010 has a vast array of configuration options and it is not feasible to include them all in this article, therefore the following are recommended (but optional) steps that will cover the basic configuration that is suitable for most scenarios.
Configuring basic farm settings, services and initial Site Collection
This section uses a wizard to configure the basic services for your farm.
- Load Central Administration (Start > All Programs > Microsoft SharePoint 2010 Products > Central Administration).
- SharePoint 2010 contains a new configuration wizard which can be used to configure common services. Load this by clicking ‘Configuration Wizards > Launch the farm configuration wizard’.
- You will be asked whether you wish to participate in the ‘Custom Experience Improvement Program’. It really helps Microsoft if you do participate in this by clicking OK.
- When prompted, choose ‘Walk me through the setting using this wizard …’ and click Next
- On the ‘Configure Your Farm’ screen do the following:
- For the ‘Service account’, add the account that you wish to use for your services by adding it to the ‘Create new managed account’ section. In a production environment, more care needs to be taken in terms of isolating service accounts, but for a development and test environment such as this, it is not usually necessary.
- Accept the default services; this will give you nearly all of the available functionality. It is worth examining this list to get a first glance at some of the new services that are available with SharePoint 2010.
- Click Next. This will initiate the wizard and may take some time to complete.
- The next screen will ask you to ‘Create Site Collection’, do the following:
- Enter something memorable such as ‘Team Site’ for your title
- In the ‘Web Address’ section choose ‘Sites’ from the drop down in the URL and enter your site title in the text box to the right of the drop-down.
- Leave the default template of ‘Team Site’ selected. This will give you the familiar team site template which is the best place to start playing with the new features of SharePoint 2010
- Enter your ‘Primary Site Collection Administrator’, this would most likely be the account you defined in step 5 of this section. In a production environment, more care needs to be taken in terms of isolating service accounts, but for a development and test environment such as this, it is not usually necessary
- Leave all other options as default and click ‘OK’
- On the final ‘Configure your SharePoint farm’ screen, click ‘Finish’
Update 22/11/2009: In beta 2 there are some issues with the user profile synchronisation service application. The main issue is that it does not work in a standalone deployment, i.e. using the built-in version of SQL. If you are using a farm (separately installing full SQL server) and want to experiment with the service, you may wish to refer to this blog article which has a list of steps to get the service working: http://blogs.msdn.com/sharepoint/archive/2009/11/18/path-to-user-profile-synchronization-success-in-sharepoint-2010-beta.aspx
Installing Office Web Applications
The Office Web Applications (browser based versions of Word, Excel, OneNote and PowerPoint) are part of a separate install which goes on top of SharePoint 2010. When installed, these appear as service applications within Central Administration. This section will guide you through the installation and configuration of the Office Web Applications.
- Run ‘en_office_web_applications_beta_x64_456141.exe’ (see downloads section above)
- When prompted enter your product key and click ‘Continue’. If you are an MSDN subscriber, you can download the key from the same place that you got the software from. Note that this is a different key than SharePoint Server 2010.
- Accept the license agreement and click ‘Continue’
- Accept the default file location and click ‘Install Now’. This will start the installation and may take a while.
- Once the installation is complete, you will see a ‘Run configuration wizard’ screen. Keep the ‘Run the SharePoint products and Technologies Configuration Wizard now’ box ticked and click ‘Close’. This will start the farm configuration wizard, though this has already been executed in the ‘Installing SharePoint Server 2010’ section, it needs to be re-run to properly configure the Office Web Applications
- Click ‘Next’ on the ‘Welcome’ screen
- Click ‘Yes’ on the warning about restating services. This will initiate the configuration process and may take some time to complete.
- When the configuration process is complete you’ll see a ‘Configuration Successful’ screen, click Finish on this. Doing this will open the browser at the default web application and prompt you to create a new site. Close the browser at this point.
I hope these steps work well for you, I’ve tested them myself and with colleagues on the various builds leading up to the general beta 2 release. If you do see any variations, please either log a comment and/or contact me directly and I’d be happy to update the article accordingly if enough people see the same variations or have the same problems.
This article was published by
-
Recently, James Kemp and James Daniel, both contributors of this blog, showcased freely available SharePoint software and guidance that has been designed to help Healthcare organisations address common business challenges. A video from this event has now been placed on Microsoft.com. Although aimed at healthcare organisations, the 40 minute video showcases IP that may be of use to almost anyone that wants to use SharePoint Server 2007. The key elements of the video are:
The video references many of the freely available IP, available on microsoft.com. We encourage you to watch the video and try out the software and guidance.
http://www.microsoft.com/industry/healthcare/technology/hpo/knowledgeworker/sharepointvideo.aspx
This article was authored by:
James Kemp
Consultant
Microsoft Consulting Services UK
James.Kemp@Microsoft.com
-
This is the fourth and final post in a series on Records Management using SharePoint Server 2007:
1. Introduction to Records Management, and Definition of Terms
2. Records Management using Standard SharePoint Features
3. Using the DoD 5015.2 Records Management Resource Kit
4. Commonly Requested Enhancements and Features (this post)
In the previous posts, we examined the basics of Electronic Records Management (ERM) and how standard SharePoint Server 2007 features, and the DoD 5015 Records Management Resource Kit can help meet many of the requirements that organisations have regarding Records Management.
This post examines some of the most-requested features from organisations wishing to use the SharePoint/DoD Resource Kit functionality to implement an ERM strategy. These features represent custom add-on functionality that can be developed to enhance the existing features.
Commonly Requested Enhancements and Features
The DoD Resource Kit extends the Records Management functionality of SharePoint Server 2007, but it has been designed specifically to meet the required ways of working specified by the DoD 5015.2 standard. There are many other national and local standards in use around the world which specify different ways of working, for which the Resource Kit may not be suitable. Through working with customers in the UK, our team in Microsoft Consulting Services have found that the following features are often requested.
Document Management
Although what happens when a document arrives at the records centre is critical, often what happens before documents are sent to the records centre may be even more important to the success of a records management solution. This is especially true of SharePoint administrative tasks such as designing and implementing content types. It is important to understand fully the requirements of the document management solution and how it integrates with the records management system.
Distributed content type management
One of the features that is most requested by customers in a records management environment is a distributed Content Type management system. Content types are used to control the definition and structure of content and are especially important in a records management vein, where content types control all processes from routing to retention and expiry.
SharePoint Server 2007 allows for complex structures to be built up around Content Types, but the management of content types is by default restricted in scope to individual site collections. If you want to make a set of content types available across multiple site collections, you must package the content types as a ‘Feature’ and then deploy the Feature across multiple sites – usually considered a ‘development task’ rather than something typical business users would untertake. Furthermore, you will probably want to make changes to your content types over time, meaning that you must also develop a custom means of distributing changes to content types across multiple site collections. This means that, on the records management side, the use of multiple records centers would require careful manual synchronization of content types; on the document management side, careful design must go into the structure of site collections and sites to reduce the impact this has, and inevitably there are organisation-wide content types that must be synchronized across disparate site collections.
It would be desirable to allow content types to be defined and maintained in a single, “master” site collection, and for them to be automatically and periodically distributed to child, or “destination” site collections.
A custom solution can be developed to allow for a single defined metadata repository to be created and maintained and destination sites to automatically retrieve updates when they are made on the master site collection.
Distributed library management
Implementing a records management solution often forces an organisation to re-think how they classify content in collaboration and document management areas. It is difficult to carefully structure and automate a records management system when the source documents are completely unstructured and have no formal metadata system.
Similar to the concept of centrally managing content types and then “distributing” those content types to recipient ‘subscriber’ site collections, a common requirement is that similar functionality be implemented to manage and associate consistent sets of metadata with document libraries. This creates the concept of a “Library Type”, where library settings such as versioning and auditing, and default content types and folders, can be set and maintained on a library template, which is then distributed to targeted destination sites.
For example, you could define a custom “Project Admin” library type. All libraries using our imagined Project Admin type would have versioning turned on, and would include a pre-defined set of ten default document content types with templates – because these settings and content types are defined in the library type. This library can be distributed to every project site within the organisation, and when subsequent updates are made to the library settings or default content types and templates, the updates are re-distributed to project sites.
Note that the concept described above requires a custom solution to implement.
Records Management
Custom automated routing
The routing provided by the default SharePoint records management functionality is based on matching the names of content types of arriving records to locations within a simplistic flat file plan; and the DoD pack supplies no automated routing besides the default functionality. This is fine for small organisations, but generally the volume of records and routing is too large to allow for rudimentary or manual routing.
In general the only sustainable, maintainable system that can be implemented is a rules-based routing system, which examines the content and its metadata before deciding on a location in the file plan and retention and disposition instructions. Such systems must generally be maintained by non-technical users, and must be flexible enough to represent the full gamut of possible properties and locations that the file plan dictates.
This is closely dependant on a single, centrally managed metadata repository, which is shared amongst document management sites and records management centers.
The router must usually allow for the automatic creation of folders if they don’t exist, and for the allocation of fixed ID’s to the folders, either randomly following a fixed structure or based on a pre-defined pattern or file plan numbering system.
Automated Metadata Management
Along with the routing and classification of records, organisations often require records of different types to have additional metadata fields populated and maintained on them. These fields can be populated based on existing properties of the incoming document, the location of the originating document, or properties inferred from a rules definition somewhere. Examples of such properties include the document’s project, business purpose, template information such as customer information, etc.
This type of property management can be handled either on the document management system, where metadata of documents is augmented when they are created and edited based on factors such as where they are located and their purpose and structure; or as they arrive at the records centre and are processed to determine their structure, content and purpose.
Usually included in this type of requirement is a scheme for centrally managing and administering a metadata scheme, whereby organisation-wide metadata structures can be defined and maintained. These structures are often hierarchical “tags” that can be applied to items, forming classification systems for the content and structure of items, documents and records.
Folder-level retention and disposition
Although with various configuration options, both the standard SharePoint Server 2007 features and the DoD pack allow for some level of folder-level retention and disposition, it is often complex to maintain. The ideal strategy is to control the retention and disposition of records based on Content Type, and if the number of ‘classes’ of records defined are small enough, then this is a good strategy to use. However, in organisations that require many classes of content, this can lead to difficulties in maintaining and structuring the content types, and in some cases the only pragmatic solution is to have the ability to define these structures on a folder level.
Default SharePoint Server 2007 functionality does not allow for sequential disposition steps, and the DoD pack mostly enforces this structure on the category, or document library, level. It is often required that folder-level (or at the very least content-type-level) dispositions can be defined.
Customisable export
Included in the DoD pack (as one of the disposition instructions) is the instruction to “export” records (Transfer), either before deletion or as a single instruction. However, the structure that the records are exported in is a SharePoint content-management based structure, which is useful only in the context of restoring those files at a later date to a SharePoint-based system.
The ability to export part, or all, of the file plan in a definable standard format (such as a ‘national archives’-mandated format) is an extremely useful function. This can be done either manually (by selecting to export a part of the file plan) or as a result of a set of records expiring. In the case of government or financial organisations this feature is often required to demonstrate compliance.
Scalability
SharePoint Server 2007 itself is very scalable, and can scale up and out to allow for large amounts of users and data. Certain restrictions on the functionality within the SharePoint Records Center, and the DoD pack, limit this potential however. This is due to many of the features being designed to work well within a single SharePoint site collection, i.e. a single Records Center site. For small organisations or those with a low record throughput, this is ideal. However, for systems declaring thousands of records a month, the recommended maximum storage capacity of a single Records Center site collection (or content database) may be reached relatively quickly; so in those circumstances the system requires modifications in order to scale to the required volumes.
Generally, catering for scale involves designing for multiple records centers to handle the volumes of data. This requires modifying the built-in functionality of SharePoint and the Records Center so that they are multi-centre aware.
In addition, modifications to the design are necessary to avoid software boundaries in any part of the functionality, and to make administration and maintenance tasks manageable when dealing with thousands or potentially millions of items such as records, workflows, events, etc.
Often the system can handle the growth of content in terms of documents and records, but corresponding system entries such as list entries and user population will start to reach the recommended software boundaries. Each case where this is likely to occur must be examined and planned for.
Customized workflows
The combined system of document and records management often involves several workflow processes, from managing of documents to declaration of records to disposition of records. It is very seldom that the out-of-the-box functionality will match the individual nuances of any organisation, and customized workflows are almost always implemented as part of this type of solution.
Reporting
Some organisations have legislative requirements for reporting on usage and adherence to process for their records management solution. For example, government organisations may be required to prove that a certain record was destroyed correctly according to their disposition policies, for FOI (Freedom Of Information) purposes. It is important to review the standard reporting features provided with SharePoint to determine whether they will include enough information to satisfy the requirements. Often a custom reporting framework will be required to extend the amount of detail captured into the standard reports.
Conclusion
Implementing a records management solution for any organisation can be a complex and difficult undertaking. The technology can form only a small part in a project that involves everything from analyzing how people work with their documents, all the way through to how legislation may influence the way records are maintained and destroyed.
However, the technology is often the keystone decision factor in these projects. Cost, complexity, ease of implementation, support availability – they all play an important part in deciding on the design and implementation of a technological solution.
Microsoft Office SharePoint Server provides excellent tools for collaboration and document management, and already has a large footprint in many organisations, serving as a platform for collaboration, document management, search, publishing, and custom development. It has a very distinct role to play in records management implementation as well.
Records management within SharePoint can be implemented up to the level of complexity that is required. It offers great basic-level records management capabilities out-of-the-box, well-suited to meeting the typical records management requirements for small organisations who may be implementing records management for the first time, and organisations where legislation does not heavily influence the management of records.
The DoD 5015 Resource Kit provides additional functionality, which can make an implementation compliant with the DoD 5015.2 standards and cover a large proportion of requirements with records management. The pack is fantastic in extending the built-in functionality with features that are fuller in records management functionality, allowing larger organisations or those more mature in records management more flexibility and possibilities, and easing some of the administrative overhead of records management.
However, as with any technology, the features and limitations must be well understood so that informed design decisions can be made. A proof-of-concept or pilot implementation would be advisable to model the ways of working using this solution. Microsoft Consulting Services have built experience in developing custom records management solutions to the requirements described in this article and can be engaged to assist with similar projects.
The DoD 5015 Resource Kit itself serves to show that SharePoint Server 2007 is an extensible platform, with powerful API’s and a wealth of help documentation and example solutions available in the public domain. If required, it is possible to build on this platform to adapt SharePoint to meet many different standards or ways of working. This allows solutions built using SharePoint Server 2007 to meet the stringent and complex requirements of records management in most large enterprises.
This post was written by Peter Reid and modified by James Kemp and Graham Tyler:
|
|
Peter Reid
SharePoint Consultant
Microsoft Consulting Services UK
Click here to see my bio
|
-
With SharePoint 2010 around the corner, I thought I’d provide a brief overview of the NEW Shared Service model. That is, how the Shared Service Provider (SSP) from SharePoint 2007 has fundamentally changed for SharePoint 2010.
So, what’s this “Service” thing you’re on about?
Well, officially, in SharePoint 2010 terms, a Service is a “middle tier feature that performs the useful function of providing Data or Processing resources and is used by SharePoint features” – nothing new or surprising here then, but worth clarifying I think. There are however some exciting changes in the way such Services are structured, as discussed below.
SharePoint 2010 Shared Service Changes
Firstly, and very importantly, SSPs are gone. The reasons for this include (a) SSPs grouped items that were not necessarily similar, (b) in SharePoint 2007, some users found it hard to deploy and manage SSP’s, (c) SSP’s didn’t necessarily scale to the nth degree (too many services in one DB)
So, what’s replaced the SSP I hear you cry? Well, the new SP2010 concept is “Service Application” or “Service App”, where SSP Services are split out into separate services, for example:
- Profiles, Audiences = People Service App
- Search = Search Service App
- Excel = Excel Service App
- Performance Point = Performance Point Service App
- Visio Services = Visio Service App
- Word = Word Service App
- PowerPoint = PowerPoint Service App
- Office Web Applications = Office Web App
- Project Server = Project Server App
There are a whole host of Service Apps present, but the general idea is that you have an App for each Service, rather than one App with lots of Services crammed into it. The Services, as before, will be managed via Central Admin. The new model can be illustrated well in a diagram, just like the one below:
From the above diagram, you can see many of the benefits the new Service Model provides; amongst other things it allows:
- A more effective targeting of services to the Web apps you’ve created (Web apps consume services on an individual basis)
- Each Web app can use any combination of the available Service Apps
- You can deploy multiple instances of the same Service Apps – giving each one a unique name
- This model also allows Cross-Farm Service Apps
- You can also write your own services that take advantage of the SharePoint infrastructure!
Secondly, some of the services also have their own database, rather than a shared database, like in SP2007. The following services are examples of services that have their own database:
- Search
- People/Profile Import
- Tagging
- Taxonomy
- InfoPath (session state)
- Secure Store
- LOBi
- Web Analytics
- Performance Point
Thirdly, with this new Service model comes some new terms, all of which I’m sure will be used heavily in the next few months. I thought I’d put them out there so everyone knows what they are and can skill up ahead of their colleagues!:
- Service: A set of bits installed on a SharePoint 2010 farm that’s capable of providing some functionality
- Service Application: A specific farm-level configuration of the Service in SharePoint. For example, the specific configuration of Office Web apps Service in your new SharePoint 2010 farm.
- Service Machine Instance: A machine-level instance of the Service running on an app server
- Service App Proxy: A pointer to a Service App that exists on the WFE
- Service Consumer: A SharePoint feature, such as a web-part, that talks with the service and makes its functionality available to an end user
What Service apps are NEW then, and what do they actually do?
You’ve seen from the above that the architecture has been modified and they are lots of NEW Services available in SharePoint 2010. I’ve provided a brief list of some of the new Services and what they do below:
- Access Services - Allows viewing, editing, and interacting with Access databases in a browser.
- Managed Metadata Service - Provides access to managed taxonomy hierarchies, keywords, social tags and Content Type publishing across site collections.
- Secure Store Service –Provides capability to store data (e.g. credential set) securely and associate it to a specific identity or group of identities.
- State Service - Provides temporary storage of user session data for Office SharePoint Server components.
- Usage and Health data collection - This service collects farm wide usage and health data and provides the ability to view various usage and health reports.
- Visio Graphics Service - Enables viewing and refreshing of published Visio diagrams in a web browser.
- Web Analytics Service Application - Enable rich insights into web usage patterns by processing and analyzing web analytics data .
- Word Conversion Service Application – Provides a framework for performing automated document conversions
For more new services info and to get your hands dirty (as it were), I’d encourage you to keep an eye on this blog.
This article was authored by:
James Kemp
Consultant
Microsoft Consulting Services UK
James.Kemp@Microsoft.com
-
The public beta of SharePoint 2010 was announced in Jeff Teper's speech yesterday. Sign up for it now!
Register : http://sharepoint2010.microsoft.com/try-it/Pages/Trial.aspx
-
This is not a normal blog post, but the MCS Uk SharePoint team is very excited! The NDA has been lifted and we can start talking about the new exciting features in SharePoint 2010. New resources have been posted by the Microsoft SharePoint team.
For more resources, take a look at:
- SharePoint 2010 Website - to view SharePoint 2010 in action
- SharePoint 2010 forum- for SharePoint 2010 questions
- SharePoint 2010 PressPass- for the SPC 2009 keynote video, a Q&A with Jeff Teper, and more
- http://technet.microsoft.com/en-us/library/ee428287(office.14).aspx - the new Technet planning centre
- SharePoint 2010 Developer Center - for developer info
- http://www.mssharepointitpro.com - for IT Pro info
- http://www.microsoft.com/sharepoint - for more SharePoint information
-
As you will surely be aware, it is best practice to install production SharePoint farms using something called the “least privilege account principle”. This effectively means that each service account in the farm is dedicated to a specific job and has only the minimum rights required in order to do that job. This is best practice as one of many common steps to ensuring your farm is secure, you can read all about it here Plan for administrative and service accounts (Office SharePoint Server).
If you deploy a custom solution on SharePoint that contains some for of error logging, it is likely that you will want to write events to the Windows event log. These events are typically written to the application log under a custom source that matches the name of your solution/application. Typically the custom source is created as part of the code itself and the code to do this is something like the following:
SPSecurity.RunWithElevatedPrivileges(delegate()
{
if (EventLog.SourceExists("MyCustomSource") == false)
{
EventLog.CreateEventSource("MyCustomSource ", "Application");
}
EventLog.WriteEntry("MyCustomSource", "My message", EventLogEntryType.Error);
});
The problem with the above code is that in a least privilege scenario, this will cause an exception because the code will execute under the context of the Application Pool which will not have any local rights on the machine and is not able to create the event source. You may see an error both on-screen and in the logs along the lines of “The source was not found, but some or all event logs could not be searched.”.
To work around this issue, the event log source must be created under the context of an account which does have increased rights on the local machine. There are several ways of doing this, which include:
- Increase the rights of he application pool account. This is bad practice and effectively mitigates the point of using least privilege
- A .net console application which has similar code as shown above but is manually execute as a local administrator account. This is a decent work around, but introduces a separate piece of custom code which is not always ideal.
- A PowerShell script which creates the event source. This is a better option that a custom .net console application, but is still code and not all environments allow Powershell scripts.
- Do not use custom sources and write to an existing one such as ‘Windows SharePoint Services’. This will cause problems because the SharePoint sources have specific message text files and will not accept generic error messages. Therefore if you do this your messages will always be prefixed by "The description for Event ID 0 from source Windows SharePoint Services cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer."
In my projects, i tend to go for the simplest solution and in this case it is very simple. It turns out that Event Log Sources are simply keys in the registry.
All event log sources are stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog. In this key there are subkeys for each of the logs (Application, System etc) and a further sub-key for each of the sources in that log. All you need to do is add a key which matches the name of the source you wish to create.
All event log sources need to refer to an ‘EventMessageFile’. These files define the message text that is available for events in that particular source. Typically you’ll want to use the standard .net file which allows any text. To do this you need to add an ‘Expandable String Value’ beneath the key you created for your custom source. The value of this should typically be set to “C:\Windows\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll” or “C:\Windows\Microsoft.NET\Framework64\v2.0.50727\EventLogMessages.dll” on 64-bit machines.
Your registry should look something like this:
You can do this manually (on every server in the farm) through something like regedit.,exe or you can create a .reg file which you can simply double click-on to add the registry hive. To create a .reg file, follow these steps:
1. Manually create the registry hive on one mahcine
2. Right-click on the hive (i.e. the key you created beneath HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application and choose ‘export’
3. Save the file as a .reg file
4. Simply double-click the .reg file on other servers to import the key
5. Reboot the machine (you’ll nee to reboot before you can use your custom source)
Once the source is created, the following code will work perfectly:
EventLog.WriteEntry("MyCustomSource", "My message", EventLogEntryType.Error);
This article was published by
-
I recently spent longer than I should have done trying to create what I thought was a fairly simple feature; one that adds a content type to a site collection and also adds a physical file as the document template. This is a common scenario when developing content types to be used in document libraries. The content type bit was easy, I had done that many times before, but adding the document template did take a while to figure out.
It was with a lot of help from my good friend and SharePoint development guru George Bonney that we managed to get it working so I thought I’d share our findings. George has also blogged about in a couple of related articles here and here.
In order to achieve this, you basically need two features:
· Content Type feature: This will create the content type and any site columns that needs to go with it.
· Modules feature: This will upload the document template and associate it with the content type.
As with most features, both of my features contain a feature.xml file and a manifest.xml file. I won’t go into detail about what these files do, if you are unsure, it might be worth having a look at these MSDN articles Feature.xml Files and Element Manifest (feature).
Creating the Content Type Feature
This is very simple, you can either do this via Visual Studio Extensions for WSS 1.1 and simply go to Add > New Item > Content Type, then fill in the gaps; or you can build the feature from scratch. For clarity, I’ll include steps to build your own.
These steps will basically create a simple Content Type called ‘MyContentType’ which will be in its own group, inherit from the default ‘Document’ content type.
1. Create a folder called MyContentType in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\FEATURES on your SharePoint server
2. Create a new file called feature.xml
3. Create a Registry Format GUID for your feature; you can do this using GUIDGen.exe or http://createguid.com/
4. Add the following code to your feature.xml file. Make sure you replace the ‘<Content Type Feature GUID here>’ the actual GUID you generated in step 3 (do not include the curly braces in the GUID).
<?xml version="1.0" encoding="utf-8"?>
<Feature
Id="<Content Type Feature GUID here>"
Title="MyContentType"
Scope="Site"
Version="1.0.0.0"
Hidden="FALSE"
DefaultResourceFile="core"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="Manifest.xml" />
</ElementManifests>
</Feature>
Now we just need to add the content type itself. There are several things to note regarding the ContentType element.
Firstly, the ID specifies the parentage of the content type. There is a whole MSDN article which outlines how Content Type IDs work here. In summary, the ID should be a combination of a new GUID (again, use GUIDGen.exe) and the ID of the parent content type. In this case we want to use the default Document content type as the parent; therefore we need to prefix our new GUID with 0x0101 which is the ID of the document content type.
5. Create a new file called Manifest.xml in the same folder as feature.xml and add the following code in to your Manifest.xml file. Be sure to replace the ContentType ID with ‘0x0101’ plus you own unique GUID, minus the dash symbols.
<ContentType Name="MyContentType" ID="0x0101FE67098470024e0b9272DF90F64061F6" Group="MyContentTypes" Version="0">
<DocumentTemplate TargetName="/_cts/MyContentType/MyDocumentTemplate.dotx" />
</ContentType>
You will note that there is a DocumentTemplate element; this is the key line that maps the content type to the actual document template file. The TargetName property points to url of the document template file once it has been uploaded and uses the url of _cts/<name of the content type>/<name of file>. This Url is a hidden part of SharePoint which you can only see in either SharePoint Designer or by opening the site collection via a Network Place. Inside the _cts folder there is a folder that represents each content type in the site collection. These folders are called Resource Folders and are used to store resources for the corresponding content type.
The content type feature is now complete.
Creating the Modules Feature
Now that the content type feature is complete, we can create the modules feature. This feature will actually upload the doucment template to eth right place in SharePoint (_cts/<name of the content type>)
1. Create a folder called MyModule in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\FEATURES on your SharePoint server
2. Create a new file called feature.xml
3. Create a Registry Format GUID for your feature; you can do this using GUIDGen.exe or http://createguid.com/
4. Add the following code to your feature.xml file. Make sure you replace the ID for the Feature element with the GUID you generated in step 3. Also replace the FeatureId property in the ActivationDependency element with the Feature ID of the Content Type feature GUID (created in step 3 of the Creating the Content Type Feature section)
<?xml version="1.0" encoding="utf-8"?>
<Feature
Id="C81844B4-06DB-478c-B01E-2761B0AEFD69"
Title="MyModule"
Scope="Site"
Version="1.0.0.0"
Hidden="FALSE"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="Manifest.xml" />
<ElementFile Location="MyDocumentTemplate.dotx" />
</ElementManifests>
<ActivationDependencies>
<ActivationDependency FeatureId="<Content Type Feature GUID here>" />
</ActivationDependencies>
</Feature>
There are several key things to note with the above code. Firstly you will note that there are two element manifests, the first point points to Manifest.xml which we will discuss in a moment, the second points to the *.docx file that will be the document template (it does not have to be *.docx, it can be any file type).
Secondly, you will notice that there is an activation dependency. This means that this feature (MyModule) will not activate unless the corresponding feature is already activated. In this case, the activation dependency is the MyContentType feature we created earlier. All you need to do is ensure that the FeatureId property is set to the ID of the MyContentType feature (from feature.xml). This is required because unless the content type exists the MyModule feature has nowhere to upload the document to.
5. Create a new file called Manifest.xml in the same folder as feature.xml and add the following code to Manifest.xml
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Name="MyModule" Url="_cts/MyContentType" RootWebOnly="TRUE">
<File Url="MyDocumentTemplate.dotx" Type="Ghostable" />
</Module>
</Elements>
The Url property in the Module element points to the Resource Folder that the document template file needs to be uploaded to. The File element includes a Path that points to the actual file that you wish to upload (i.e. its location on the local disk on the SharePoint server).
8. Finally you need to actually add the MyDocumentTemplate.dotx file to the feature folder which will be C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\FEATURES\MyModule (just create any old file for this, so long as it has the same name).
Installing and Activating the Features
In an ideal world these two features would be wrapped up into a SharePoint solution package; however in the interest of clarity, we’ll skip this steps and simply install and activate the features on their own.
1. On the SharePoint server open a command box and navigation to C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\bin
2. Enter and execute the following two commands (one for each feature):
Stsadm.exe –o installfeature –name “MyContentType”
Stsadm.exe –o installfeature –name “MyModule”
3. Now enter and execute the following two commands, replacing http://<your web application name> with the url of your web application:
Stsadm.exe –o activatefeature –name “MyContentType” –url “http://<your web application name>”
Stsadm.exe –o activatefeature –name “MyModule” –url “http://<your web application name>”
Your features are now activated on the site collection, your next step is to associate the content type with a document library and start creating documents.
4. Navigate to the document library you want to use your new content type and go to Settings > Library Settings > Advanced Settings. Enable ‘Allow Management of Content Types’.
5. Now add the content type by clicking ‘Add from existing site content types’ in the Content Types section of Settings > Library Settings for your library.
6. You should now see MyContentType in your libraries’ new menu
This article was published by
-
This is the third post in a series on Records Management in SharePoint:
1. Introduction to Records Management, and Definition of Terms
2. Records Management using Standard SharePoint Features
3. Using the DoD 5015.2 Records Management Resource Kit (this post)
4. Commonly Requested Enhancements and Features
In the previous posts in this series I examined what Records Management is, and how standard SharePoint Server 2007 functionality can be used to implement a basic Records Center. This post discusses a publicly-available add-on pack for SharePoint, the DoD 5015.2 Resource Kit.
Using the DoD 5015.2 Resource Kit
The DoD 5015.2 Resource Kit was created to demonstrate that custom Records Management solutions built using the MOSS platform could be made to be compliant with legal standards. Increasingly the most common standard, and the one chosen for certification by Microsoft, is the United States Department of Defense (DoD) 5015 Chapter 2 standard. The certification against this standard was achieved in May 2007 with a solution built using the Resource Kit created for Microsoft by a Microsoft Partner. The certification allowed Microsoft to position SharePoint as a valid solution for US (and often other government) Records Management requirements, and serves as a good yardstick as to the capability of the SharePoint platform to be extended to meet differing customer requirements and scenarios.
An evaluation version of the Resource Kit is available for Microsoft Partners or customers to download from the Microsoft website, but is only available commercially as a production solution by engaging Microsoft Consulting Services or a Microsoft Partner. This is because Records Management implementations are complex and should only be implemented by teams with experience in designing and implementing complex records management solutions.
- The Resource Kit provides additional features that build on the default SharePoint records management capabilities and extend the standard functionality to include several important new areas. Although there are many enhancements that the pack provides on top of SharePoint, let’s take a look at the most important new additions:Enhanced file plan management
- Enhanced retention
- Enhanced disposition
- Enhanced search
- Clearance-based access control
- Related versions and records
DoD Enhanced File-plan management
The DoD Resource Kit allows for better management of a hierarchical file plan. Specifically, it allows the creation of a tree-like folder structure, with the ability to set metadata and control other functionality on either the top-level category, or lower level folders.
The file plan consists of two primary entities:
Categories, or top-level folders. Categories are represented in SharePoint as Document Libraries and serve as the actual physical repositories for the records. Several features can be controlled at the category level, including
· Disposition instructions (including Retention)
· Vital Record Review period and reviewer
· Cutoff instructions
· Metadata such as category unique id and description
Record folders, or lower-level folders. Record folders are represented in SharePoint as folders within the document libraries that represent categories. Features that can be controlled at the record folder level include
· Vital Record Reviewer and Review period
· Whether the folder is open to records or closed
· Supplemental Markings
· Cutoff Trigger
· Metadata such as unique ID
The enhanced file plan management of the DoD Resource Kit allows for much greater control over the structure and order of the file plan. The control over items such as Vital Record Review Period on a folder level allows different content to be grouped by folder and have some of the functionality of cutoffs and retentions applied at that level.
Enhanced Retention
The DoD Resource Kit improves the flexibility and control exercised over the retention of records, specifically allowing for greater control over the triggers for the cutoff of a category or folder, and allowing for event-based disposition of categories. To create a trigger for a cutoff, a new Global Event or Global Period is created. As many of these as necessary can be created and used as the triggers for cutoff of a category or folder.
Global Event
Global Events allow for an event-driven cutoff. For example, an event could be “Termination of employment of John Smith”, and the cutoff could start 2 years after the event is triggered.
Global Period
A global period represents a repeating, set period of time. For example, a global period could be “Financial year”. A global period can be created to represent any period of time.
For triggering a disposition, a Global Event is used, which allows for control over when records are disposed of on a category level. Optionally, a field on a record can be used to decide when disposition occurs – for example, “ten years after record create” can be set as an instruction.
Enhanced Disposition
The DoD Resource Kit allows for greater disposition control than standard SharePoint. Specifically, the pack allows the creation of a sequence of disposition instructions which are followed when the disposition is triggered. The actions are applied on the category level, which means that different top-level folders in the file plan can have different disposition instructions applied to them, and generally trigger a workflow which, on approval, causes the instruction to be applied.
Actions
The disposition instructions that can be applied are
· Destroy
· Transfer
· Destroy After Transfer
· Do Nothing
A Destroy instruction results in the Destroy workflow initiating, in which the record is reviewed and deleted if the destroy is approved. Transfer results in the export of the records to a specified location in a packaged file, and Destroy After Transfer will export and then delete the records.
Sequence
A series of disposition instructions created for a category, which are executed in sequence. For example, the instructions for a category could be
1. Transfer 5 years after event X
2. Destroy 10 years after event x
The events are followed in sequence. The sequence does not necessarily need to follow logically, for example the first instruction in a sequence can be a Destroy instruction. When the workflow for the Destroy instruction is triggered, the record manager can decline the destroy, at which point the next instruction is followed.
Triggers
There are two triggers that can be used to initiate a disposition instruction
Global Event Trigger, where the disposition is triggered based on the occurrence of a Global Event. An example could be the closure of a project or the end of a pending court case.
Record event trigger, which allows the disposition to be initiated on an individual record basis, triggered by a date field on the record. An example of this type of Instruction would be “Destroy ten years after the record was uploaded”. One of the most commonly used fields for this type of trigger is the Cutoff Date which, in combination with the Cutoffs specified on the category or folder, allows for folder-level control of the disposition of records
Enhanced Search
The DoD Resource Kit supplies its own specialized search user interface for records managers, adding some new features which allow for greater property-level searching of records, and the export of the search results into Excel. This provides a basic reporting structure for the records managers, allowing them to search through records based on various properties, and export those results.
This search does not interfere with the standard SharePoint search, and both can be configured side-by-side.
Clearance-based access control
The DoD Resource Kit adds a useful tool for controlling the access to records within the Records Center, based on clearance level. For example, a clearance level of “Top Secret” can be placed on records, and only those users in the “Top Secret” group have access to the record and can change the permissions on the Record.
Although utilizing standard SharePoint permissions under the hood, the feature allows for several levels of clearance/categorization to be applied to a single record, and the intersection of users in these groups is used to determine the Access Control List for these records. For example, tags that could be applied to a record include “Top Secret”, “US Eyes Only” and “Department of Defense Only”. With these tags applied to a record, only those users in all of these groups would have access to the record. This is contrasted to normal permissions in SharePoint, which allows a user in any of the applied groups access to the item.
Related versions and records
The DoD Resource Kit allows for related versions of a record to automatically be linked together. If a record is declared, and the source document is subsequently modified and then re-declared as a record, the pack will automatically link the two records together. In addition, when the earlier record is opened, the pack will warn the user that a newer version exists and allow the user to view that version.
In a similar way, records can be related to each other using a custom-created “record relationship”. An unlimited number of Record Relationship Templates can be created and used. By default, the templates available are Succession, Rendition and Attachment, although this list can be customized and extended.
When viewing the properties of a record, the versions and related records are visible to the user and can be browsed.
DoD Design considerations
The DoD Resource Kit is extremely useful in extending the built-in records management functionality in SharePoint. However, there are some potential (and some deliberate) design constraints that implementers should be aware of.
Routing
The DoD Resource Kit assumes that records will be manually uploaded into the correct location in the file plan by browsing the Record Center. Although the automated routing of SharePoint can be used with the DoD Resource Kit solution, much of the metadata requires manual updating. Practically, this means automated routing of documents is quite tricky, and must be carefully planned (and may require additional custom development).
Clearance level Security
The DoD Resource Kit allows for the adding of protective markings such as “Top Secret” to records, which limits their permissions based on group membership.
However, technically this mechanism works by analyzing and applying the individual SharePoint users that have been granted access by name as individuals to all of the clearance level tags, and then reducing the list of SharePoint users that have been found to be in all applied tags.
Practically, in most cases this means that the users that are in each of the allowed groups for tags must be named SharePoint users. The relatively standard practice of managing permissions via Active Directory groups may result in unexpected results, as the DoD Resource Kit solution is unable to expand out the AD group membershipwhen performing the required group membership intersections. As such, if Active Directory groups are to be used, careful planning and testing must be undertaken. If possible, use individual named SharePoint users when managing permissions within the Record Center to avoid these issues.
Folder-level retention
Practically, it is difficult to apply folder-level retention periods, disposition triggers and disposition actions in a DoD Resource Kit solution. For designs where the disposition can be defined on the category level, this is not a limitation. However, designs must be careful not to build folder-level dispositions in to the system or to design careful processes around folders if this is necessary.
Definition of control structures
Many of the control functions within the DoD Resource Kit, such as Global Events, are list items in specialized lists within the SharePoint site. This means that care must be taken that the number of items in these lists does not exceed the recommended software boundaries for SharePoint (approximately 2000 items per view) to avoid gradual performance degradation. For example, if a folder for an employee must be cut off when the employee leaves the company, then a Global Event must be created for every single employee in the company, which may exceed the 2000 item per view performance boundary guideline. This takes careful planning to implement correctly.
Bulk Workflow Processing
The disposition workflow process for records review and disposition is applied at the Record level in the DoD Resource Kit (and standard SharePoint). This means that when a folder expires, if it has a thousand items in it, then a thousand workflow tasks are created for the administrators. Although bulk processing of tasks can be achieved, the DoD Resource Kit does not apply fields such as folder name to the tasks, and so this functionality must be carefully analyzed when implementing the pack.
Scalability
The DoD Resource Kit follows the implementation of a standard SharePoint Records Center, in that typically only one Records Center would exist at any one time – it is technically possible to create many separate Record Centers sites, but they would be separate entities, managed separately, not sharing a file plan by default and certain other features such as automatic version relations would not work automatically.
Records Centers are also subject to other standard SharePoint planning constraints; for example a site collection (or Records Center) is stored within a single contentdatabase, which has a recommended maximum size of 100GB. This size guideline is intended primarily to keep database backup and restore times within typical IT Department Service Level Agreements (SLAs) and so is arguably a flexible number, depending on the specific SLAs in place at a specific customer and on the tools and techniques they use to backup and restore databases. However Microsoft’s standard guidance is to keep individual content databases to 100GB in size.
Conclusion
The DoD 5015.2 Resource Kit provides many additional records management features and controls that are required to meet the DoD 5015.2 standard. It is a great tool for extending the SharePoint functionality and as long as careful design and planning is undertaken, can meet many of the ERM requirements for medium to large enterprises that need to comply with the DoD 5015.2 standards.
However, implementing the solution is not a trivial exercise and must be undertaken by engaging with either Microsoft Consulting Services or an appropriate Microsoft Partner. Customers who would like to enhance the records management functionality of SharePoint 2007 with particular features available within the DoD 5015.2 Resource Kit but are not required to run their system in a certified configuration should not use the DoD 5015.2 Resource Kit. Alternatively, sample code and documentation is available for the most frequently requested features available within the DoD 5015.2 Resource Kit. For a list of the available samples and documentation please refer to this page: http://sharepoint.microsoft.com/product/capabilities/ecm/Pages/dod-resource-kit.aspx
In Part 4 of the blog series, we examine how the SharePoint platform can be extended with additional records management functionality via further custom development.
This post was written by Peter Reid and modified by James Kemp and Graham Tyler:
|
|
Peter Reid
SharePoint Consultant
Microsoft Consulting Services UK
Click here to see my bio
|
-
This is the second post in a blog series on Records Management in SharePoint:
1. Introduction to Records Management, and Definition of Terms
2. Records Management using Standard SharePoint Features (this post)
3. Using the DOD 5015.2 Records Management Resource Kit
4. Commonly Requested Enhancements and Features
Part 2: Records Management Using Standard SharePoint Features
In the previous post in this series, I provided an introduction to Records Management (RM) and specifically Electronic RM (ERM). I also provided an overview of the forces for implementing ERM within an organization and the basic definitions of terms in ERM.
This, second post, covers the feature set and implementation that is provided by an Out-Of-The-Box (OOB) implementation of Microsoft Office SharePoint Server 2007 (MOSS) with regards to records management.
Much of the technical functionality that records management solutions rely on is already present within the MOSS toolbox, so it comes as no surprise that the standard MOSS functionality for records management utilizes these features. Although requiring a little bit of configuration to set up, the basic records management functionality that you get out of the box with MOSS is a good place to start in implementing records management.
MOSS provides a dedicated area for storing records - a separate site collection based on a special site definition, called the Record Center. This consists of a specialized site, based on a standard SharePoint site but with some extra functionality added to allow for the processes and ways of working that Records Management introduces. However, much of the functionality that the Record Center uses is present under the hood within MOSS.
Let’s take a look at how records management utilizes both
Standard SharePoint features:
· Document Libraries
· Content Types
· Workflows
· Information Management Policies
Specialized Records Center features:
· Official File Web Service
· Record Center Connection
· Routing and iRouter functionality
· Holds
Standard SharePoint functionality
The records management functionality of a standard SharePoint Records Center exploits a lot of the built-in SharePoint components and technology. At a high-level, the following standard SharePoint components and technologies are used in a specialized way in the Records Center:
Document Libraries
Document libraries serve as record repositories in the Records Center. This means that records inherit all the standard functionality of SharePoint document libraries – permissions, folders, content types, auditing, etc. The libraries can be configured in much the same way as standard SharePoint document libraries. However, note that some of the special functionality such as the records router is not folder-aware, and as such, manually adding folders should be performed only with caution and appropriate testing.
Content Types
A common requirement for records is that additional metadata is captured with the record – for example, the identity of the record manager that declared the record, the media type, etc. Because records are based on standard document functionality within SharePoint, the full range of content type functionality such as workflows, information management policies, etc can be applied to records.
Workflows
The Records Center can use and implement all the standard (and any custom) workflows that are used within normal SharePoint document management. In particular, the Disposition Approval workflow is particularly useful in ensuring that items are disposed of (deleted) correctly once their retention period has been exceeded. The Disposition Approval workflow allows a reviewer to review those records that have reached or exceeded their retention periods, and then dispose of or keep the records. The workflow adds a new task for each expired record to the Tasks list, which can then be processed individually or in bulk according to the current view on the tasks list. The provided workflows are limited to deleting records, so export and other disposition instructions are not present unless specifically added in via custom development; but this still provides good functionality for basic disposition of records
Information Management Policies
Information Management Policies are key to providing a lot of the functionality for a records management site.
Information Management Policies exist at either a farm, site collection or content-type level. They allow for the control and administration of content at each of these levels, and provide control over the following aspects of the data:
· Labels
· Auditing
· Expiration
· Barcodes
· Metadata Retention
a) Labels are not usually applicable within a records management scenario, but can of course be used if required. Labels allow for information about a document (or record) to be included when the item is printed, and are useful for legislative purposes. For example, if legislature requires that the classification level of a document is printed along with the document, then the use of Labels will help in achieving this.
b) Auditing is often required for standards or legal compliance purposes, and is often requested in a records management capacity. Although auditing can be defined on the site level, configuring an auditing policy for a Content Type allows for different auditing requirements to be met on different types of content. For example, it may be necessary to audit both views and modifications to financial documents ;but perhaps only to audit modifications to project documents.
Configuring auditing instructs the SharePoint subsystem to add entries to the Audit database whenever actions are performed on items. This is often critical for compliance purposes.
c) Expiration. Vital to being able to define the retention periods and dispositions for records is the Expiration control with Information Management Policies. The expiration policy can be used to cause content to expire after a certain time period, based on information about the item – for example, records can be set to expire 5 years after their creation date. This allows for fine control over the content within a record repository (where an Information Management Policy is applied to a document library) or content of a specific type (where the policy is applied to a content type).
When an item expires, it can be deleted immediately, or a workflow or custom action can be kicked off. Typically, the Deletion Approval workflow is kicked off so that items can be reviewed before being deleted.
Allowing for custom actions to be executed when an item expires allows for customization and extension of the framework
d) Barcodes can be useful if a records management solution encompasses the management of both electronic and physical (paper) documents. The barcode functionality allows for the generation, storage and display of a unique barcode, conforming to international standards, for items within SharePoint. When a document becomes a record, a barcode can be automatically associated with the digital copy. By printing the barcode and attaching it to the paper copy of the record, records managers can easily locate and associate the two copies of the record together, ensuring that they are managed correctly and disposed of together.
e) Metadata Retention is key to records management, often for compliance purposes. Metadata Retention refers to the process whereby all the metadata for an item is retained when the item itself is deleted through an expiration policy. This is important because it is often necessary for legal reasons to be able to prove that an item existed and was deleted according to standard retention policies. Enabling a Metadata Retention policy ensures that this occurs within the Records Center.
Specialized Records Management Functionality
The Records Center exposes some specific functionality that was built in to MOSS specifically for records management. Some of these features are product-wide, and some just exist within a Records Center. They all assist in providing records management functionality
Official File Web Service
Records management in MOSS uses a second storage model, where copies of documents that are declared as records are sent to a separate Records Center site. This is in contrast to a manage-in-place model discussed later.
The Records Center must have a means of receiving records – both manually and electronically. Manual submissions are added to the Records Center in the same way that documents are added to document collaboration areas – by visiting the site in a browser and uploading the document. Electronic submissions are sent to a web service that Microsoft created specifically for this purpose, the Official File Web Service. The service is incredibly simple and allows for submission of a document, along with its metadata and audit information and a classifier which determines the type of record being sent. Documents sent to the Official File Web Service are then processed by a component called the iRouter, which determines which document library within the Records Center the document should be routed to.
“Send To” functionality
When a SharePoint farm has a Record Center link configured through Central Administration, an extra option is added to the “Send To” section of the drop-down menu on each document, with the name of the Record Center that has been configured. Clicking on this link for any particular document takes a copy of the document and its metadata and audit information and submits it to the Official File web service on the Records Center site.
Routing Records using iRouters
By default, a Records Center site includes a Routing list – a list that defines a mapping between the type of content (based on Content Types) that is sent to the Records Center, and the document library or records repository that the document will be routed to. It should be noted that records can only be routed to a document library - not to a sub-folder within that library. This makes for a very flat file plan, but does allow for the division of things such as retentions and security per content type. The routing can also be extended (more on this later) to allow for custom routing handlers.
The default router looks at the Content Type of the source document and compares this to the entries in the routing table to determine where the document should go. If no match is found, the default library, usually called “Unclassified Records”, is used and the record is placed there awaiting review and manual intervention.Custom iRouters can be developed and inserted into this process, so that custom code can be executed when documents of a certain type arrive at the Records Center. This allows for considerable flexibility in routing documents that arrive at the Records Center.
Holds
The SharePoint Records Center allows holds to be placed on records, which prevents the record from being disposed of, even if the expiration date is reached. This is useful when real-world circumstances override the default expiration policy; for example, in cases where a document is relevant to an ongoing court case or a project is being reviewed. Putting those records on hold prevents them from being destroyed along with other records with a similar retention.
Holds in the SharePoint Records Center are enforced through the use of the Holds list, which contains an entry for each record that has a hold on it.
Conclusion
Standard SharePoint functionality provides an excellent platform to get started with records management. It provides many of the basic features required - and by leveraging SharePoint as a development platform, these standard features can be extended to build additional functionality, tailoring the solution to a particular organisation’s ways of working.
In Part 3, we will examine one such way of doing this – including a brief discussion of the DOD 5015.2 Records Management Add-on pack.
This post was written by Peter Reid and modified by James Kemp and Graham Tyler:
|
|
Peter Reid
SharePoint Consultant
Microsoft Consulting Services UK
Click here to see my bio
|
-
This blog series will address the role that SharePoint can play in Records Management within an organization and the abilities and functionality that can be leveraged from the platform. The blog consists of four posts:
1. Introduction to Records Management, and Definition of Terms (this post)
2. Records Management using Standard SharePoint Features
3. Using the DOD 5015.2 Records Management Resource Kit
4. Commonly Requested Enhancements and Features
The blog presents my views as a SharePoint expert into the vast and complex world of Records Management. It must be noted that, even in the space of a four-part series, there is not enough time to even scratch the surface of this multi-faceted, deep and complicated issue, and so this series presents an overview only.
Part 1: Introduction to Records Management, and Definition of Terms
SharePoint is an excellent platform that covers a multitude of scenarios and functions within a business. Key to enabling many of these is the ability that the product exhibits around document management.
Given this ability to manage, store, collaborate on and dispose of documents, SharePoint naturally extends into the world of Records Management. Records Management concerns the storage and deletion of content (usually, but not limited to, documents) according to fixed schedules and policies.
With so many companies using SharePoint for the creation, maintenance, collaboration and dissemination of content such as documents in their day-to-day working, it is useful to define how SharePoint can offer integrated functionality that extends to Records Management.
Records Management
Wikipedia defines Records Management as “the practice of maintaining the records of an organization from the time they are created up to their eventual disposal. This may include classifying, storing, securing, and destruction (or in some cases, archival preservation) of records.” Unsurprisingly, ERM (electronic RM) deals with the concept of RM in electronic systems.
In a nutshell, ERM is the (usually long-term) storage, administration and disposition of documents and other electronic items according to internal or legislative requirements.
Records Management Forces
There are a lot of drivers and forces that cause an organization to adopt a Records Management strategy (part of which will usually be a Records Management System, although this forms only part of the overall RM process which encompasses the workflows, processes, people and external organizations that make up an RM strategy). Since the maintenance, review and disposal of records during and after their ‘normal’ lifecycle is a costly business, organizations must have strong motivations for wanting to retain records.
Generally, organizations have internal and external motivations for wanting to implement RM.
Internally, records may need to be retained as part of the business processes – for example, if the possibility of future litigation looms, for auditing purposes or for the future value inherent in large and long-running stores of data.
Externally, legislative causes are the main influence in RM within an organization. The more regulated an industry, the more likely it is that organizations within the industry will be required to implement a strategy for retaining records. Industries such as defense and banking are prime examples of this.
It must be said that, from experience, generally the legislative requirements for records management are so comprehensive and total that it is rare for an organization to be 100% compliant. In mitigation of this, most industries will pass an audit if they show sufficient progress, or more specifically can demonstrate plans, to move to towards compliance.
Definition of Terms
Records management is a complex and evolving topic, and it is often difficult to keep track of the terms and concepts. The below is my layman's definitions of the terms used in RM, and how they apply to ERMS. The terms will be used in the next parts of the blog series, so feel free to skip them and return when you encounter a term in the rest of the text.
Note: I am a technology expert, not a RM expert, and these definitions reflect my understanding of the topic!
Manage in place vs. Record Move
Traditionally, when a document is declared as a record, it is copied or moved to another location (usually a Records Centre) where the correct security and retention policies are applied to it.
A relatively new trend in records management relies on “manage-in-place” records management, which leaves the document in its current location but declares it as a record and applies the appropriate security, retention and disposition to it. This is called a “manage-in-place” strategy.
Records Centre
A Records Centre is a central location for the administration and management of records. A company may have several records centers, each for different type of records, but usually a single records centre exists. If a manage-in-place strategy is being used, the centre is a location from which eDiscovery is performed, the process of discovering and administering distributed records.
Stubbing
Stubbing is simply the process of leaving a small “stub” in place when a document or record is removed or destroyed. It serves to indicate that a document or record was present at some stage, even though it is no longer present. This can be useful in cases where is necessary for legal reasons, for example, to prove that a record was disposed of or that it once existed.
Record
A record usually refers to an article such as a digital or physical document that needs to be retained for a set period of time and then disposed of in a certain manner. A record can also be a physical item such as a flash drive or DVD, but usually refers to IP retained in a document.
Although in ERMS a record generally refers to a document, often (and more correctly) a record constitutes a set of documents that all share the same purpose, and therefore must be retained for the same time and disposed of in the same manner. For example, when an employee leaves a company, the company is required to retain all documentation relating to that employee for a certain period of years. The set of documents is often stored in the same folder in the FilePlan and that folder is referred to as the employee record.
File plan
The FilePlan refers to the structure and location of records in the records centre. It is often hierarchical and resembles a folder structure, although it can be more taxonomical and multi-faceted. Regardless of the organization, a File Plan is often comprised of hierarchical, embedded folders which contain either other folders at the root level downwards, or records at the leaf level.
How the file plan is structured directly affects how easily records can be maintained and administered. This is a critical consideration given that even the smallest records management sites usually exist for many years, allowing thousands of records to build up.
Retention
The Retention of a record refers to two things: (1) The time period that a record must be retained for after its trigger, and (2) the trigger that causes the retention period to begin. Retention time periods are usually specified in years and will conform to legislation and/or internal policies, and range from one to one hundred or more years.
Triggers are usually event-based. Events can be system-based, automated events such as “when record is declared”, or external event-based such as “when the employee leaves the company”. Events can also be based on dates or periods, such as “close of the financial year”.
Disposition
A disposition refers to what happens to a record when its retention period expires. The name is misleading, as a disposition instruction for a record could be “Review and retain further”. A single disposition instruction refers to an action that can be applied to a record, and a disposition usually is a sequence, or workflow, of disposition instructions.
Disposition is usually the same for, and applied to, a record in the sense of a collection of documents, and as such is often defined and applied at the folder level.
Cutoff
The cutoff of a folder or record refers to the closure of the folder to accepting new documents. For example, a folder that is accepting documents relating to a project can be cutoff at the end of the project, which will close the folder to any new additions and (often) trigger the retention period for those documents. Cutoffs are often automatically performed based on a time period, for example folders can be cut off at the end of the financial year.
Often with time-based cutoffs, a new folder is automatically created and named for subsequent records to be moved to.
Routing
With records management systems that automatically move records into the correct location in the file plan, a Router is responsible for examining the properties of the document, determining the correct location in the file plan and moving the document to that location in the file plan. Where this is not possible a router may alert an administrative user or records manager that information is missing or incomplete, and the administrator can request further information or manually move the record to the correct location.
Routers often relieve the job of records managers that must manually move or declare all records, and are essential in environments where the number of records to be declared per day is above a few tens. Routers most often work by comparing the metadata properties of a document to a set of pre-defined property mappings, or rules, to determine the final location of the record.
Conclusion
Having examined the forces on RM, the definition of RM and the key terms used in its discussion, Part 2 will examine the role that a vanilla SharePoint Installation can play in RM out of the box.
Peter Reid has recently left Microsoft to travel. However, as his post series on RM is so good, we thought we should publish it! This blog post was published by James Kemp and written by:
|
|
Peter Reid
SharePoint Consultant
Microsoft Consulting Services UK
Click here to see my bio
|
-
Recently, the SharePoint Product Team released information regarding the next version of SharePoint; SharePoint 2010. News regarding the next version of Microsoft Office; Office 2010 is also surfacing. As I regularly get questions from customers regarding both products I thought I’d pull together a list of useful resources and information.
So, what is SharePoint 2010 ?
 |
|
It’s the next version of SharePoint. The official answer is “the business collaboration platform for the Enterprise & the Web that enables you to connect & empower people through an integrated set of rich features. Whether deployed on-premises or as hosted services, SharePoint 2010 helps you cut costs with a unified infrastructure while allowing you to rapidly respond to your business needs”. |
What will I need to use SharePoint 2010?
The number one place to get readiness information on SharePoint 2010 is here. I also recommended that you also read the preliminary system requirements.
What other things can I do to get ready for SharePoint 2010?
Where can I get more info on SharePoint 2010?
What is Office 2010?
 |
|
The next version of Microsoft Office. Office 2010 aims to “give you rich and powerful new ways to deliver your best work - whether you’re at work, home, or school - on a computer, Web browser, or Smartphone”. |
What is new in Office 2010?
- See here for videos regarding Word, Excel, PowerPoint, Outlook, OneNote and other Office 2010 client applications
Where can I get info on Office 2010 (client)?
I hope the above information has wet your appetite. We hope to share lots more information with you once more details can be released to the public. Enjoy!
This blog post was published by:
-
A SharePoint MySite is a type of SharePoint site that can be created to allow a user to (a) centrally manage and store their documents, content, links, and contacts, and (b) share information about themselves, such as their skills and interests. Each user within an organisation is normally given the rights to create their own MySite and people often refer to it as “Facebook for my organisation”.
Normally, allowing users to create MySites is a great way of facilitating SharePoint adoption. When a user creates a MySite they automatically become a Site Owner and can therefore experiment with uploading documents, adding lists, Web parts and other SharePoint components. MySites are also easy to use and similar to the concept of a social networking page, which many people are familiar with. Traditionally, the creation of thousands of MySites is often seen as a sign of success as it illustrates users are experimenting with the new software.
However, in some organisations it may be strongly desirable to allow one subset of users to create MySites rather than all users . The most common reason I have found for this is because a SharePoint pilot is running and therefore only a subset of users are allowed access the new SharePoint system. Other reasons for incrementally deploying MySites could include (a) very low spec server hardware, which would grind to a halt or run out of space if thousands of sites were created at once, and (b) low amount of IT resources to help with MySite queries. Ideally, issues (a) and (b) should be resolved prior to launching any SharePoint system.
However, if you still have a strong business case for allowing only a certain groups of users to be able to create a MySite, my recommended approach is to:
1. Make an Active Directory (AD) group called ‘MySite Users’:
2. Add the first batch of users to the AD group ‘MySite Users’:
3. Open up SharePoint Central Administration and click the name of your Shared Services Provider:
4. Within the SSP, under User Profiles and MySites, click Personalization services permissions:
5. On the Manage Permissions: Shared Service Rights page, add the AD group ‘MySite Users’, configure it to allow Create personal site and click Save:
5. On the Manage Permissions: Shared Service Rights page, click NT AUTHORITY\Authenticated Users:
Note: NT AUTHORITY\Authenticated Users is provided by default to allow all users to create a MySite.
6. De-select the Create personal site checkbox and click Save:
As a result of following the steps above, only the initial members of the ‘MySite Users’ AD group will be able to create MySites. When additional users, such as those from other departments within your organisation need to be able to create a MySite, their AD user accounts should be added to the AD group ‘MySite Users’. This process can be repeated until every user within your organisation is able to create a MySite.
For the curious amongst you, below is a picture of what a user will see if they do have permissions to create a MySite:
Below is a picture of what a user will see if they do not have permissions to create a MySite (the ‘MySite’ link is automatically removed):
Enjoy! This blog post was published by:
-
One of the most common and simple ways to customise SharePoint is to directly modify the files that are installed as part of the product (referred to as ‘SharePoint-owned’ files).
This is common practice; but not necessarily good practice for many reasons, the most obvious being that this type of customisation is officially unsupported.
In most cases that are alternative ways of achieving the desired customisation without modifying SharePoint-owned files, however in some cases, modifying SharePoint-owned files is the only option. This article will outline the key considerations around modifying SharePoint-owned files.
(Throughout this article \12\ refers to the ‘12’ hive normally located in the following location on each WFE server: C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\)
Why not modify SharePoint-owned files?
Directly modifying a SharePoint-owned file is by far the easiest and simplest way to make a customisation, however this approach is unsupported for several reasons, the main ones being:
- Modifying these files may ‘break’ SharePoint in some way if you change the wrong part of the file
- A hot fix or service pack may over-write your customised file without notice, which will effectively un-do your customisation
The detail around the support policy are outlined here: http://msdn.microsoft.com/en-us/library/bb803457.aspx
In addition to the support policy, this is generally bad practice because your customisations effectively get lost amongst all of the out-of-the-box files and the customisation becomes very hard to support and maintain. Additionally, customising SharePoint-owned files may cause problems when upgrading to future versions of SharePoint.
Common Modifications and Suggestion Alternatives
This section will outline some of the most common modifications that are made to SharePoint-owned files and possible alternatives which will achieve the same result in a supported way.
Changing anything in 12\Templates\Layouts
The \12\Templates\Layouts folder contains all of the ASPX pages, MASTER pages etc that represent much of the SharePoint user interface. Many customers need to modify these pages to either disable some out-of-the-box functionality or add additional logic.
Rather than directly modify files in the ‘layouts’ folder, it is possible to create a duplication of the entire folder for each web application you have. You can then re-configure the site in IIS to point to the new folder and make your customisations there instead. This way, the original ‘layouts’ folder remains un-touched, but you still have the desired customisations. The added benefit of this approach is that you can apply customisations on a web application basis.
For the purposes of explanation we’ll base this overview on the ‘layouts’ directory however this approach also applies to the following product-owned directories \12\template\controltemplates, \12\isapi and C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\wpresources
To implement this, follow these steps (assuming we are working with a web application called ‘Portal’):
These steps will need to be repeated on each WFE server.
1. Navigate to \12\TEMPLATES
2. Make a duplicate of the ‘Layouts’ folder and rename the folder to ‘Layouts_Portal’
3. Open IIS Manager
4. Navigate to the IIS site which represents the ’Portal’ web application, right-click the ‘_layouts’ virtual directory and open the properties page (advanced settings on IIS7). This is shown in this screen shot (site called ‘MySite’ rather than 'portal’ but you’ll get the idea!)
5. Set the physical path to the folder you created in step 2 (should \12\template\Layouts_Portal)
6. Perform an IISRESET
You can now safely modify the files in the ‘Layouts_Portal’ portal folder and those changes will only affect the ‘Portal’ web application.
WebTemp.xml
\12\TEMPLATE\1033\XML\WebTemp.xml is an XML file which controls which site definitions are presented to users in the Create Site interface. If your solution contains a custom site definition, it needs to be registered here in order to show-up in the user interface.
If you directly modify WebTemp.xml to include your custom Site Definition, this will work but is bad practice.
Fortunately, the site registration mechanism was developed in such a way that any XML file who’s filename starts with ‘WebTemp’ and is located in \12\TEMPLATE\1033\XML is used to register site definitions. This means that you can create a custom WebTemp file (normally called WebTempCustom.xml) in the same location as WebTemp.xml and providing that your IDs are unique and the values are correct, your site will appear in the Create Site interface.
This means you can register you custom Site Definition without modifying the SharePoint-owned WebTemp.xml file.
SPThemes.xml
\12\TEMPLATE\LAYOUTS\1033\SPThemes.xml is an XML file that controls which themes are available for use across the entire farm. Adding a custom theme is a perfectly common and acceptable way to ‘re-skin’ a SharePoint site.
Unfortunately, this is an area where you have to modify SharePoint-owned files if you what to register your custom theme. Unlike WebTemp.xml, it is not possible to add a custom version of SPTheme.xml with your theme’s registration in it. Only the SharePoint-owned SPTheme.xml is used to register themes.
Site Definitions
Many customisations require simple tweaks to SharePoint-owned site definitions such as ‘team site’ or ‘meeting workspace’. As with previous examples, it is simplest and easiest to directly modify the site definition, however this is unsupported.
An alternative approach is to use a technique called ‘feature stapling’ or ‘site association features’ to add the additional functionality. The feature stapling technique allows you to specific additional features that are activated after a site is created from a specified site definition. This allows you to add to the SharePoint-owned site definition without actually changing any of the SharePoint-owned files.
There are plenty of great article which talk about feature stapling. Here are two particularly good ones:
http://msdn.microsoft.com/en-us/library/aa544294.aspx
http://blogs.msdn.com/cjohnson/archive/2006/11/01/feature-stapling-in-wss-v3.aspx
If you do have to modify SharePoint-owned files
If you have to modify a SharePoint-owned file and feel there is no alternative, there are several best practices that should be observed:
1. Understand files that are updated with hotfixes and service packs
It is best practice to ensure you understand the files that are updated by a hotfix or service pack. This is especially true if you have modified or duplicated product-owned files which could be updated as a result of a product update. Normally, whenever a service pack is issued, a list of fixes and files that are update is also published.
This is the list that was published for Service Pack 2: http://support.microsoft.com/default.aspx/kb/970358/
This is the list that was published for the WSS infrastructure updates: http://support.microsoft.com/default.aspx/kb/951695
2. Make Duplicates
If you do have to modify any SharePoint-owned files, ensure you have a duplicate of the original file before you make any changes. This way if your customisation is ever removed, you can restore the original file easily.
It is best practice to monitor changes when hot fixes and/or service packs are applied. If your customised files do get overwritten as part of a product update, then make sure the duplicate is up to the same patch number before you re-apply your customisations. This way you are applying your customisations to the latest version of the file.
Do not include the duplicates in your solution package (see Understanding Solution Retraction).
3. Understand Solution Retraction
When adding files via solutions it is important to understand that when a solution is retracted, it will actually remove any files that are contained within the solution package. If these files are modified versions of SharePoint-owned files, the files will be deleted which may actually break SharePoint until another version of that file is replaced.
The best practices in this area are as follows:
- Do not include backup copies of the original product-owned files in your solution package. These should be manually created and stored. Normally these files are stored on the live servers; however this is not mandatory, so long as copies are kept somewhere.
- It is fine to deploy custom versions of files via a solution, but ensure that a manual step is added to the retraction process to replace the deleted file, usually with a copy of the original backup.
This article was published by
-
Data connections are very used n InfoPath to pull data in from many different sources. The data connections are called UDC files. They areused by the Forms Service Proxy Web Service Protocol to connect to a target Web service. A form template uses the information in a UDC file to connect to a data source.
One thing you have to be very careful of is the naming conventions used when there are multiple UDC connections being made. One such situation arose on a customer site recently where an InfoPath form was accessing multiple UDC links to Web Services. When the form published via SharePoint's Central Admin Site the following error was seen:
“Relative links to Data Connection Libraries located in different SharePoint Site Collections are not supported.”
When checking the forms and the custom controls it was seen that data connections all seemed to be pointing to the same place:
http://[sitecollection]/[subsite]/DataConnections
There was one subtle difference though - some of the references were [sitecollection]/[Subsite]/dataconnections because of the difference in the capitalisation in the URL they are picked up as being data connections in different site collections. It is also the reason for the error message in publishing.
One other thing to note is that the form would publish without any hitches as long as the name and formatting of the Data Connections is consistent across all the data connections.
If you want to know more about UDCX's then have a look at: http://blogs.msdn.com/infopath/archive/2006/10/30/the-anatomy-of-a-udc-file.aspx
![rob_finney[1]](http://blogs.msdn.com/blogfiles/uksharepoint/WindowsLiveWriter/QuicktipADPropertiesmappedtoSharePointPr_BEF6/rob_finney%5B1%5D_thumb.png "rob_finney[1]")
Rob Finney
Consultant
Microsoft Consulting Services UK
robert.finney@Microsoft.com
Click here for my bio page
|