Michael O'Donovan's SharePoint and Stuff : Windows SharePoint Services

ComponentOne Release 3 Web Parts for SharePoint

modonovan — Thu, 19 Feb 2009 22:10:41 GMT

“ComponentOne Web Parts leverage the power of Microsoft's Silverlight technology for superior performance, styling, animation, and interactivity. Version 1 of ComponentOne SharePoint Web Parts includes three feature-packed web parts:

ComponentOne DataGrid™ for SharePoint
ComponentOne Chart™ for SharePoint
ComponentOne Maps™ for SharePoint

These web parts access both SharePoint lists and SQL Server data. They are easily configurable by administrators and, if permissible, by end users alike” – http://labs.componentone.com/WebParts/

WSRP Toolkit for SharePoint Released

modonovan — Thu, 18 Dec 2008 15:49:28 GMT

I have been asked this question numerous times. “Does SharePoint produce WSRP compliant content, so that other portal technologies can render SharePoint content such as lists and web parts?” My answer would always be “No”, SharePoint is a WSRP consumer not a producer…well now there is some GREAT NEWS…..that has changed.

Microsoft has released the WSRP Toolkit for SharePoint to CodePlex. This toolkit consists of sample code for producing WSRP conformant content for SharePoint lists and libraries.

You can find the SharePoint Product Team announcement here http://blogs.msdn.com/sharepoint/archive/2008/12/05/announcing-the-wsrp-toolkit-for-sharepoint.aspx, and

2 Video Samples here:

For many other great resources on interoperating with SharePoint, be sure not to miss the Resources for Interoperability with SharePoint Site which has many interop resources.

SharePoint End-User Training Released

modonovan — Mon, 10 Dec 2007 10:12:23 GMT

This is a great new resource to download and either install on a user's desktop or in you SharePoint environment for all users to access. It includes videos, tutorials, articles and more.

Download it now

SharePoint Pedia has Gone Live

modonovan — Mon, 05 Nov 2007 17:57:58 GMT

Check it out at http://sharepointpedia.com, looks pretty cool. Another awesome example of a solution built on MOSS.

Use Windows Live Writer to create blog posts ... for MOSS

modonovan — Fri, 14 Sep 2007 14:54:33 GMT

I have just recently downloaded Windows Liver Writer Beta (http://get.live.com/betas/home), and have used it to create my previous blog post. The tool is very simple to use, and the best part about it is that it can be used to post entries to a MOSS hosted Blog site. And it Just Works, with proper in context previous, categories, uploading of images in the post and more!!! The screen shots below how simple it is to setup:

Step 1: Choose SharePoint as the blog destination (other than Windows Live Space or Other)

Step 2: Specify the path the SharePoint Blog site where blog posts should be created

Step 3: Configure the authentication mechanism

Step 4: Create your blog post, preview it (this is really cool, check the image below of this blog post) and then hit "Publish"

MOSS 2007 and WSS 3.0 SDK's released

modonovan — Tue, 23 Jan 2007 10:09:00 GMT

The MOSS 2007 SDK includes the WSS 3.0 SDK, so you don't need to download both if you are going to download the MOSS 2007 SDK.

Here are the links:

SharePoint Server 2007 SDK: Software Development Kit and Enterprise Content Management Starter Kit

Windows SharePoint Services 3.0: Software Development Kit (SDK)

ISA 2006 - SharePoint Publishing Wizard

modonovan — Thu, 05 Oct 2006 09:21:00 GMT

I was recently made aware of the new SharePoint publishing wizard in ISA 2006, which essentially allows you to easily and securely expose your SharePoint implementation to the internet / extranet. It also supports forms based authentication and SSO between other web applications sitting behind the ISA 2006 Server(s) e.g. Outlook Web Access.

View Technical Article ...

SharePoint Services and App Pool Account Permissions

modonovan — Tue, 14 Jun 2005 06:06:00 GMT

Firstly Daniel McPherson has contacted me and we seem to be talking again. Since moving to his "new" role he has become very distant, probably because he is spending so much time doing excellent work with our partners and customers. He of course has also been a big influence in the content of this blog.

For some time I have been confused about the permissions required for service accounts in SPS and application pool accounts. Most of this confusion has been based on not actually understand exactly what these things do. I have tried to summarise my findings below. I still not 100% happy as I haven't answered the "why" questions e.g. why does the SPSAlert service account need the "Power User" role, surely all it does is talk to the DB and send emails. Therefore I am very happy to accept all comments that will help in this understanding.

There are essentially 4 types of management user accounts (i.e. excluding business users) that need to be given permissions in an SPS solution. They are:

Account(s) which the SPS services will run as i.e. service accounts

Database configuration account

Content crawler access account

Application pool account

Service Accounts:

In order to understand the permissions required for service accounts, it is important to understand what the services actually do.

SharePointPSSearch (mssearch.exe) - Microsoft SharePoint Portal Server Search service provides indexing and searching over the portal and external content. Servers that run the Search Service will parse through the indexed data and return results to the users. It is also responsible for gathering and indexing all of the searchable portal content both internal and external. This service account should be a member of the “Power Users” group on all machines running Portal Server. SPS uses SMB to propagate the Indexes (from Index to Search server), the reason the service account needs the power user role will have to do with the fact that it needs to maintain a “share” for the copying.
SPSAlert (SPSNotificationService.exe) - The purpose of the SharePoint Portal Alert service is to notify a user, when the user requests it, that there is a change to a designated item, document, list, or document library on the website. Alerts are managed by the job server. This service account should be a member of the “Power Users” group on all machines running Portal Server.
SPSAdmin (Spsadmin.exe) - SharePoint portal administration - SPSAdmin is a service that was written to maintain the configuration of each server in a SharePoint Portal Server deployment. Essentially, this service runs on each server in the farm and is responsible for checking the configuration database every 30 seconds to ensure that the local server is performing its assigned roles. E.g. SPSAdmin can stop and start services that SharePoint Portal Server needs, including SPSSearch. It can also add or delete catalogs and can add or delete search applications as needed. In the SharePoint Portal Server Central Administration/Component Selection area, each server in the farm must be assigned at least one role to perform in the farm. When a role is assigned to a server in the farm, it is recorded in the configuration database. The SharePoint Portal Administration service checks this database every 30 seconds to ensure that the server is performing its assigned role or roles. If the service discovers that there is a modification in the server’s roles, the service will “turn on” or “turn off” those portions of the server’s code to either stop performing a role or to start performing a role. Should run as an account that is a SharePoint Portal Server administrator i.e. member of “Power Users” group on all machines running Portal Server. There is a SQL Server database restore scenario (which can be found in the “Disaster Recovery in SharePoint Products and Technologies” chapter in the SPS resource kit) that in order to work dictates that the spsadmin service account must either be a member of the Administrator’s group on the Web front-end server or be a Windows SharePoint Services administrator. According to recommended security practices, you should not grant the spsadmin account administrator rights; on the server, the spsadmin account should be granted as few privileges as possible. By default, the content access account is granted Windows SharePoint Services administrator rights. You should create a new Windows security group, and add both the content access account and the spsadmin service account to this group. Then, using the Windows SharePoint Services administration Web pages, you should change the Windows SharePoint Services administrator account to be this Windows security group.
SSOSRV - Single sign on service - Provides single sign-on services for line of business applications. This service should run as an account that is a member of the “Power Users” group on all machines running Portal Server.
SPTimer (OWSTIMER.EXE) – This is not actually a SPS service, but rather a WSS service. The SharePoint Timer Service sends notifications and performs scheduled tasks for Windows SharePoint Services. This service account should be a member of the “Power Users” group on all machines running Portal Server.

Note: during the installation of SPS all services mentioned above are set to run as the account specific as the database configuration account. This can be changed afterwards but I haven’t found any documentation that steps you through this and hence don’t recommend changing it.

Database configuration account:

Used for administrative operations that create, modify, or grant access to the configuration or portal site databases. The configuration database administration account is the user name and password that SharePoint Portal Server uses when connecting to the configuration database or when propagating full-text indexes from index management servers to search servers. The SharePoint Central Administration web site’s application pool identity is also configured to run as this user account by default. There is some confusion here about permissions of the account used for this. In the SPS Admin guide and the during SPS installation it states “The account must be a member of the Power Users group on this server” and explicitly states “Specifying an account that is a member of the local Administrators group on the server on which you are installing SharePoint Portal Server is not recommended”, however the Microsoft Solution for Intranets Guide suggest that this be given “Local administrator rights on search and index servers”. I recommend going for the more secure option of just Power users and if this doesn’t work upgrade to Administrators.

The account must have the Database Creators and Security Administrators server roles on this SQL Server instance. In addition, the account must be a domain account if you have more than one server in your configuration. The following user rights are granted automatically to this account (the configuration database administration account) on the local server: “Replace a process level token”, “Adjust memory quotas for a process”, and “Log on as a service.” Note: all services are also set to use this account during installation of SPS, and the SharePoint Central Administration web site’s application pool is also configured to run as this user account during installation, hence it will be added to all the local groups for an app pool account e.g. STS_WPG etc.

Content Access Crawler Account:

This account is used as the default account for crawling content sources defined for a content index. The account must have read access to the content being crawled. What is generally recommended, especially if there are several WSS virtual servers that need to be crawled, is to use a user account that has Windows SharePoint Services administrator rights. Otherwise you will need to give the account rights to every web site on every WSS virtual server that needs to be indexed. Remember; users who perform searches will only get results back that they have permissions to access. By default, the content access account is granted Windows SharePoint Services administrator rights, however as mentioned previously it is recommended that you create a new Windows security group, and add both the content access account and the spsadmin service account to this group. Then, using the Windows SharePoint Services administration Web pages, you should change the Windows SharePoint Services administrator account to be this Windows security group.

You are prompted for the user name and password for this account immediately after SPS has been installed, during the initial configuration. This can be changed at any time by using the SPS administration web pages.

Application Pool Identity:

The application pool identity is essentially what the ASP .Net code of the portal site will be executing as. The user account used here must have the standard rights in order to run an application pool, and must obviously have rights to read and write to the SQL Server databases for the portal. When the portal is created the designated user account is given these permissions automatically, hence you shouldn’t need to change this. However, in the references section is a link to an article which describes how to change identity of existing application pool or change application on a portal site if needed. The following rights are required for the application pool identity:

Must be a member of the IIS_WPG, SPS_WPG, and STS_WPG groups on the web server

Must be a Db_owner on these databases; portal site _SITE database, _SERV database, _PROF database, and for the configuration database (by default, this is SPS01_Config_db)

You are prompted for the user name and password for this account immediately after SPS has been installed, during the initial configuration to setup default IIS sites application pool to run as the chosen user.

In summary, a recommended scenario would be:

It may be easier to have a single user account as the service account for all SPS services, a single account for content crawling a single account for the configuration db access and then an account each for each application pool. E.g.:

Add “Domain\ServiceAcc” to “Power Users” group on all Portal Servers. This account will be used to run all SPS services, will be the database configuration account and will be the application pool identity for the SharePoint Central Administration web site. Grant this account the Database Creators and Security Administrators roles in SQL Server.

During SPS install specify the Domain\ServiceAcc as the database configuration account
Just after SPS installation, during SPS configuration specify the Domain\ContentCrawlUserAcc as the content crawler account and Domain\PortalAppPoolUser as the application pool identity for the default portal application pool
Create custom “SharePoint Administrators” group
Add “Domain\ContentCrawlUserAcc” to the custom “SharePoint Administrators” Group
Add “Domain\ServiceAcc” to the custom “SharePoint Administrators” Group
Using the Windows SharePoint Services administration Web pages, you should change the Windows SharePoint Services administrator account to the custom “SharePoint Administrators” group
Ensure that user cannot change password and password never expires are selected for these user accounts in AD.
A good practice is to ensure that "user user cannot change password" and "password never expires" are selected for these user accounts in AD

How to add presence/pawn to SharePoint contacts list

modonovan — Wed, 11 May 2005 05:57:00 GMT

I have often been asked to add the presence icon and functionality to custom developed web parts or SharePoint pages. As you are probably aware this is a very simple thing to do, the secrect lies in calling the IMNRC jscript function passing in an email address in the rendered html. e.g. IMNRC('administrator@somewhere.com'). You don't really need to know, or probably don't care how this actually works behind the scenes, so in summary; the IMNRC function calls an ActiveX control (called "name.dll") on the users machine which does the work, this control is installed with Office 2003. So developing web parts of custom SharePoint web pages with presence support added is pretty easy.

However, recently I had the requirement to show presence info on the email address field in the out of the box contacts list for WSS sites. I am not 100% sure why this feature was not added by the product team, but I guess it's because your contact list may have email addresses from users outside of your organisation and hence the presence information wouldn't make much sense. Anyway, I set myself the challenge of adding this. In theory it is not that difficult, you need to modify the CAML in the schema.xml for the contacts list to change the HTML that is rendered for the allitems view, i.e. inject the IMNRC function call for the email address field. In theory easy, in practice a little bit of a pain. I have therefore attached the sample CAML that I used in schema.xml for the contacts list. This is the viewbody section in the all contacts view i.e. <View BaseViewID="1">. Remember, this is sample code that you must test fully before deploying. Good luck!

Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Web part caching options, how to choose

modonovan — Wed, 27 Apr 2005 06:17:00 GMT

I don’t think there is a default answer to which caching technique you should use for your custom web parts. However it is important to understand the differences between using the ASP .Net cache object, the Web Part cache memory and database stores and the Caching Application Block found in the Enterprise Library.

There is plenty of documentation on the asp .net cache object so I don’t want to go into too much detail. In summary:

Allows you store objects in memory
When the web application is recycled the entire cache is lost
When items are added they can have an expiration policy based on time (a sliding window if needed) and/or dependencies on other objects e.g. if a file changes on disk, then the cache item becomes invalid
Items are removed from cache when they expire or if memory pressures on the machine mean that items must be purged from the cache. ASP .Net will then remove items based on their priority, even if they haven’t expired.
A web part is really just an ASP .Net server control and hence there is no reason why you cannot implement caching in the control like you would any other server control. Either caching objects used by the control or the html rendered by the control. There is nothing web part specific in this scenario. One advantage of using this model is that multiple instances of your control can share the same cache, for example on 200 web part pages you have the same web part with the same data irrespective of the user viewing it. Here you would like to cache the data only once, not 200 times or even more if you do it on a per user basis. Also, you are using the ASP .Net cache which is tried, tested and …and works!

If you choose to use the built in caching functionality of the web part framework you have the option of storing the cache in memory or in SQL Server. This is designed to be configurable, i.e. changing an option in web.config will change the store for **ALL** web parts for that web application. In some way you could say that this is something that an administrator can change at any stage, however the reality is that this is not the case.

Web part cache – in memory:

Actually this just uses the ASP .Net cache object.
Items can be cached per user or per web part. In other words using this will not allow multiple instances of a web part to share the same cache, if you want this you must use ASP .net cache object directly or the caching app block. However, if you don’t want this type of uniqueness then this is great option.
When items are added to the cache the web part framework adds extra text to the cache item key so that it will make the key unique for either the user, or the web part instance.

Web part cache – in SQL Server

What happens here is that the object you choose to cache is serialised with the web part into the database, along with the rest of the web part properties. This is obviously not seen by the developer.
You object that you cache must be serialize-able. Obviously! And must be marked as such otherwise the web part framework will not attempt to write it into the DB.
Once again items can be cached per user or per instance of the web part, the same as the web part in memory option.
There are a couple of really good reasons why you might choose to do this. Firstly, because the cached content is the database all the web servers in the farm share the same cache and application recycle won’t remove your cached data. Unlike the asp .net cache, if a user is load-balanced between web server the user will see the same cached data. Secondly, you probably have more database storage capacity than memory.
Obviously this will be slower that an in-memory cache. How much really depends, you will need to do the appropriate testing. As mentioned earlier the downside of the choosing to cache web part data in SQL or in memory is that it applies to all web parts, therefore if you do this, you could have every web part cache living in the DB.

Caching application block

Developed by PAG group at Microsoft and all source code is made available to you. You can change source code as needed, however for this discussion I am assuming this has not been done.
In some ways this is similar to the ASP .Net cache object, however it has been designed to work in any .Net application not just web apps.
It stores all cache items in a hashtable, which will be lost if the application recycles. This is where a backing store could be used.
If a backing store has been configured then every time an item is added to the hashtable it is also added to the backing store e.g. a SQL Server database table. If the application recycles, the hashtable is lost. When the application starts the hashtable is pre-populated with items from the backing store. The backing store is not used as cache store so that many web server can share the same cache; the backing store is there to recover cached data when an application recycles.
You get advanced time expiration policies e.g. when an item is added to the cache you can specify that is expires on Monday at 11pm. More info on this can be found in the docs for the block.
You have control over the configuration of cache scavenging e.g. maximum number of items allowed in the cache, when items are scavenged etc
You can have multiple caches in one application with different settings e.g. one may have a backing store and the other may not.
Like using the ASP .Net cache directly, your web part could use this as the cache store.
In general I have not found this caching application block to be useful for web parts. If I was developing a smart client it would be something that I would look at.

Idea: have a configuration property on the web part that dictates where the cache will be stored, either the ASP .Net cache directly or using the web part cache framework. This means that you can have control over which web part items are stored in memory and which items are stored in the database.

Also, there are many other options that you may come up with e.g. if using the smart part and asp .net user controls, then you could use asp .net output caching. Let me know your thoughts.

If you want more specifics, give me a shout.