SharePoint 2007: Permissions, permissions, permissions.

Update: Joel Olsen has a great post about permissions:

http://blogs.msdn.com/joelo/archive/2007/06/29/sharepoint-groups-permissions-site-security-and-depreciated-site-groups.aspx

SharePoint 2007 permissions functionality has increased so much (granularity / SharePoint groups / permission inheritance), that it is quite easy to get confused when trying to setup your permissions. As usual, Ton Stegeman has quite a few good articles about Permissions etc.

The basic idea is to create Permission Levels, and assign these permission levels to users or groups. Having the ability to inherit / break permissions as the need arises it ensures that virtually any kind of fancy permission setup can be implemented. It takes quite a lot of experimenting to understand and setup the permissions correctly, but with careful thinking and tweaking you should have quite an elegant end result.

Permission (Levels)
Permission levels are the various different rights which you can assign to different people / groups in a SharePoint site. By default, each site comes with a number of permission levels (Full Control / Design / Contribute / Read etc.) which you can customise to suit your needs. To create additional parent levels, go to the Site where you want to create a new permission level. Click on People and Groups > Site Permissions > Settings > Permission Levels. Here you can create your new custom permission levels. You can create permission levels from scratch, or copy existing permission levels.

After setting up the permission levels that you need, you need to setup the groups.

When you click on People and Groups you will be greeted by the following menu.

By default you are taken to the Groups

Groups -> contains all the groups within the Site Collection. Here you are able to see all the groups that exist in the current site collection.

You can customise this list (to show only the groups which are relevant to the current site), by cicking on Settings > Edit Group Quick Launch. You will then be able to choose which groups should be visible when you click on the Groups link (for the current site). This is especially useful, when you are not inheriting permissions from the parent site. Since you will probably have created custom groups for this site, this will allow you to show only those groups which are relevant to the current site.

In the groups you can also setup which groups will be the Owners / Members / Visitors for the current site. This is done by clicking Settings > Set Up Groups and assignin the rights to the appropriate groups. For most users this should be sufficient.

All People -> used to view (and manage) all people for the current site collection. What you will see is all users in the current site collection. It doesn't matter from which site you click the All People link, you will always see all the people which have some kind of permissions in the current site collection.

Site Permissions -> this is where the interesting stuff happens ;) (the assigning of permission levels to users group).

Once you have created your required permission levels, you need to assign these permission levels to particular users or groups in your site.

Your site must not inherit from its parent, to break the inheritance you need to click on Actions > Edit Permissions (and click Ok). What this does is create an exact copy of the permissions of the parent site. At this point you still basically have the same permissions as the parent. You can now remove any permission levels you don't need, and create new users / groups with the permissions levels you have setup earlier.

Anything which can be done for sites, can also be done for each list in each site, and each item in each list! Now that's what I call fine permission granularity!

Confused? Practice makes perfect ;) I will try to make another post with a few good examples...

SharePoint 2007: Content Deployment - Moving your content from Server to Server

The last cool feature that seems (up to now) to work like a charm in 2007 is Content Deployment. Basically, you can use content deployment to migrate your build from development to production. If you search for content deployment, I'm sure you'll find the nice MSDN blog which states how wonderful the content deployment is ... well, it is!

Ton Stegemen has a good blog about this: http://www.sharepointblogs.com/tonstegeman/archive/2006/12/30/17335.aspx
Even though Ton has code to do all the steps, you can do all of it without any code, through the Central Administration only.

The steps are:

1. In the Destination Server go to Central Administration > Operations > Content Deployment > Content Deployment Settings, and set the server to Accept Incoming Content Deployment Jobs.



2. There are other settings which you can do in this page like Encryption, or which server in a farm you will use for Import / Export. For my testing I didn't need any of them.


3. Content deployment allows you to choose which Web Application / Site Collection to deploy to, therefore you need to make sure that the destination infrastructure has been setup correctly.


4. The Site Collection you want to migrate to must be an empty Site Collection, i.e. it is very important to create a site collection based on a Blank Site template. If you don't have a blank site, you will get various errors. Most of them will be due to the fact that a number of Objects would have been already created. E.g. if you've created an (empty) Collaboration portal (assuming that all content will be copied to it), the content deployment will fail (because it will try to overwrite already existing objects and fail). Therefore, start with a clean slate (i.e. a Blank Site template).


5. On the Source Server you need to create a Content Deployment Path from Central Administration > Operations > Content Deployment > Content Deployment Paths and Jobs. Create a new path, choose the Source Web Application / Site Collection, then specify the url of the Central Administration on the destination server. Don't put the Site Collection url, because Content Deployment works from Central Administration of the Source to the Central Administration of the server.



6. Define the Authentication method that the Source Central Administration will be using to run on the Destination Central Administration. This means that the account you provide must have Central Administration rights on the destination server. This is another critical step. My test setup was between a normal network, therefore I used a Integrated Windows authentication account and used an account which existed on the destination server. Once you provide the correct credentials, the Central Administration will connect to the destination, and allow you to select the Web Application / Site Collection to deploy to.

7. As soon as the Path is created, a Quick Deploy Job is automatically created. However, this is not the Job that you should use to Deploy all your content. This should be used for any updates, after you have migrated all the content already.



8. Create a new Job (Migrate All) from the Path you have defined. Click the Path, and Create Job. Select the Path which you have created on the previous steps. Define whether you want to copy the entire site collection, or only a subset, and define a schedule (or run once). Run once allows you to run the Job ad hoc. Choose deploy only new, changed or deleted content, and specify email to send confirmation of finished job






9. Therefore you should now have:

• Destination Server which accepts Incoming Content Deployment Jobs connections.
• Web application with a blank site Site Collection created on it.
• Content Deployment Path with correct authentication from Source Server to Destination Server.
• Job (Migrate All) which will be used to Migrate all the content.

11. Click on the Migrate All Job, and Click Run now. Wait until all the content is copied!
12. Once all the Content has been deployed if you update the source, you can re-run the jon to migrate new content to the destination.

Issues I have encounterd:

• If you try to migrate the content using the Quick Deploy, it will succeed, however nothing will be actually copied. When I tried to re-run, I an unknown error was thrown. Once this error was thrown, I had to delete the Web Application at the destination and re-create it from scratch, and also create the Path and Job all over again! Bug maybe?


• If you have enabled Self-Service Site Management, you need to ensure that any additional Site Directories have already been created on the destination Web Application. The content deployment will not create the Site Directories. For each Site directory you have, you must create a Site Directory based on the Blank Site template on the destination. Besides this you must create a new Path to each Site directory and a job which will copy the contents of the Source Site Directories.

Questions raised by the migration and which require testing: What happens when you migrate a build to a client, the client starts doing their changes, and then you need to update with another version of the build?

Still need to investigate this and probably other issues, however, the first encounter seems quite nice.

SharePoint 2007: Web Capture Web Part

If you have experience with SharePoint 2003, you are most probably in love with the Web Capture Web Part.

To install this Web Part on WSS 3.0 you need to fiddle around a little. You can't just download the Office Web Parts and Component from MS, because it will complain that you need WSS 2.0 installed to be able to install the file...

Thanks to this post on Shane Young's blog, you can get the Web Capture in SharePoint 2007.

First of all you need to get a copy of the Office Web Parts (Web Capture) Cab files. If you have the Office Web Parts installed on a V2, you can get the cab file from
c:\program files\common files\micrsofot shared\web server extensions\60\wppacks

The cab file which contains the Web Capture file is "microsoft.office.dataparts.cab".

Edit: if you don't have the cab files, you can download them from here:
http://www.2shared.com/file/3663746/d9ecea5d/MicrosoftOfficeDataParts.html (New download link)

Copy this file to your 2007 installation, put it in an accessible location (C:\spswebparts) and run the following command:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm -o addwppack -filename "C:\spswebparts\microsoft.office.dataparts.cab" -globalinstall

followed by iisreset. Et voila, you can add the Web Capture web part to your web part zones!

You should be able to install most Web Parts from 2003 using this method!