Brian Wilson : Deployment

Office SharePoint Server 2007 : Search : Configuring NTFS permissions for NTFS file share/ folders (that don't inherit permissions) for the search default content access account (xCacls)

Brian Wilson — Thu, 17 Jul 2008 12:26:00 GMT

Here is a step by step guide (I had to write it up anyway J ) to configuring permissions for the search default content access account for NTFS folders that have many folders and files that don’t inherit permissions on your network.

1. Download XcAcls.exe (cAcls is depreciated and does not support batch files)

This command-line tool allows you to set all file system security options that are accessible in Windows Explorer. XcAcls does this by displaying and modifying the access control lists (ACLs) of files. XcAcls is especially useful in unattended installations of Microsoft Windows 2000 Professional or Server. By using this tool, you can set the initial access rights for folders in which the operating system resides.

http://www.microsoft.com/downloads/details.aspx?familyid=7a3e2241-d7d0-42b6-b86e-6eda88726c01&displaylang=en

2. Install tool using setup program

3. Configure environment variable so that you can call xcAcls from any folder in command prompt

· Navigate to the install location: e.g. “C:\Program Files\Resource Kit” and copy this path into your clipboard.

· Open up your machine’s environmental variables (Right Click my Computer, Properties )

· Open the Path variable and append the install location to the path. Be sure to add a trailing semi colon.

· Hit Ok 3 times.

4. Add the default search access account using the xCacls utility.

a. Fire up a command prompt. Ensure that it is running under user privileges that have access rights to the folder structure you want to change.

· To fire up a command prompt in a specific user context : “runas /user Domain\username”. E.g. “runas /user CORPDOMAIN\networkfileshareadminaccount”

b. Execute the following command : xcacls C:\FOLDERSTRUCTURE\BASEFOLDER /T /E /C /G YOURDOMAIN\SEARCHCONTENTACCESSACOUNT:R /Y

For the exact meaning of each parameter:

· /T recursively walks through the current folder and all of its subfolders, applying the chosen access rights to the matching files or folders.

· /E edits the ACL instead of replacing it. For example, only the administrator will have access to the Test.dat file if you run the XCACLS test.dat /G Administrator:F command. All ACEs applied earlier are lost.

· /C causes Xcacls.exe to continue if an "access denied" error message occurs. If /C is not specified, Xcacls.exe stops on this error.

· /G user:perm;spec grants a user access to the matching file or folder.

o R Read

o C Change (write)

o F Full Control

o P Change Permissions (special access)

o Take Ownership (special access)

o X EXecute (special access)

o E REad (Special access)

o W Write (Special access)

o D Delete (Special access)

· /Y disables confirmation when replacing user access rights. By default, CACLS asks for confirmation. Because of this feature, when CACLS is used in a batch routine, the routine stops responding until the right answer is entered. The /Y option was introduced to avoid this confirmation, so that Xcacls.exe can be used in batch mode.

Result : All folder and files below and including the parent folder (e.g. basefolder) will be have the specified account added to their security settings. This includes files and folders that are set to not inherit permissions from their parent.

Please don’t forget to test first on isolated folder structure first.

Event Handlers - Part 3: Register Event Handlers plus free Site Settings – Manage Event Handlers Add-on solution

Brian Wilson — Sun, 18 Mar 2007 21:31:00 GMT

This post is the third post of a 3 post series.

Post 1: Everything you need to know about MOSS Event Handlers

Post 2: Developer Solution Starter Kit (Building and deploying event handlers to MOSS)

Post 3: Registering Event Handlers plus Site Settings - Manage Event Handlers

In the first post, I discussed the benefits of using Event Handlers in Microsoft Office SharePoint Portal Server 2007 (MOSS).

In the second post, I discussed how to develop and deploy Event Handler solutions for Microsoft Office SharePoint Portal Server 2007 (MOSS).

In this post I will discuss the various mechanisms to attach (register) your event handler assembly to a site, list, or content type. The "Site Settings – Manage Event Handlers Add-on" solution is hosted on CodePlex. Here is the link:

Codeplex Project : http://www.codeplex.com/SPSCustomAdmin/

(If any of you are interested in getting involved, I am interested in building more Site Settings addons. Please email me at brwil at microsoft dot com if you would like to get involved in expanding this framework. I will discuss the ideas i have in more detail in a future blog post.)

Overview

So you have deployed the assembly to the farm, now what? How do I register an event in your assembly for a Site, List, or Content Type?

I will describe three ways to deploy your assembly’s events.

1) Manage EventReceivers via Code

2) Deploy event handlers using the Feature framework of MOSS 2007

3) A cool custom Site Settings Application I built to manage (view, add, edit and delete) event handlers.

Managing EventReceivers via Code

The site (SPWeb) object, the list (SPList) object and the Content Type (SPContentType) object expose a collection called EventReceivers based on the SPEventReceiverDefinitionCollection class.

This collection maintains a set of SPEventReceiverDefinition objects (events) attached to a site, list or content type.

Adding Event Handlers (SPEventReceiverDefinition)

This class provides an “Add” method to attach a new SPEventReceiverDefinition (We created and deployed these to MOSS in Post 1 and 2.) The Add method asks for three bits of information:

· SPEventReceiverType: This tells SharePoint the type of event receiver we are adding to the EventReceiver collection.

· Assembly name: The name of the assembly. E.g. “Litwarehandlers, Version 1.0.0.0, Culture=neutral, PublicKeyToken=a6ab42c509981682”

· Class name: The name of the class. E.g. “Litwarehandlers.SiteHandlerClass”

(An easy way to get this information is to use our trusty old friend, Lutz Roeder’s Reflector application. Simply reflect the class and copy and paste the information you need.)

Once attached, the site, list or content type will now start picking up these events and executing your assemblies code.

Modifying Sequence Numbers

Another important property you may want to set for each event you attach is the Sequence Number. The sequence number determines the order your event assemblies’ fire. This is especially important when you have created multiple assemblies that are all attached to the same Site, List or Content Type event.

To modify the Sequence Number, you need to retrieve the SPEventReceiverDefinition object from the EventReceivers collection.

· Site: site.EventReceivers

· List: list.EventReceivers

· Content Type: site.ContentTypes[content type name].EventReceivers

A suggested best practice (and only my opinion), do not use sequence numbers below 10000 as SharePoint uses event handlers extensively to run SharePoint Workflows, etc. These event handlers use Sequence Numbers, starting at 1000.

Deleting Event Handlers (SPEventReceiverDefinitions)

When removing definitions, here is what you have to do:

Site:

· Attach to the site (SPWeb)

· Lookup the SPEventReceiverDefinition object in the site.EventReceivers collection.

· Use the delete method of the SPEventReceiverDefinition object to remove it from the collection.

· Call the site.Update() method.

List:

· Attach to the site (SPWeb)

· Retrieve the list : (site.Lists[GUID or listname])

· Lookup the SPEventReceiverDefinition object in the list.EventReceivers collection.

· Use the delete method of the SPEventReceiverDefinition object to remove it from the collection.

· Call the list.Update() method.

Content Types:

· Attach to the site (SPWeb)

· Retrieve the SPContentType (site.ContentTypes[SPContentTypeId])

· Retrieve the SPEventReceiverDefinition object : (SPContentType.EventReceivers[GUID])

· Use the delete method of the SPEventReceiverDefinition object to remove it from the collection.

· Call the SPContentType.Update() method.

Managing assemblies using Features

It is possible to create a feature that deploys your event handler to the assembly.

MSDN has an example on how to achieve this: http://msdn2.microsoft.com/en-us/library/ms453149.aspx

See screenshot of the xml you need to write to deploy an event via the features framework:

Limitations:

· It is difficult to see what event handlers are installed and the sequence they are firing for a site, list or content type. To modify, requires rebuilding the feature with the correct settings.

· Using a feature, “hardcodes” the event handler to an individual list or Content Type. Each time you want to use the SAME event handler, you are forced to write another feature to register it.

In my opinion, wrapping functionality as a feature is cool, but is overkill for registering event handlers. This is my reason for building a view, add, edit and remove application via Site Settings. See below! J

Managing EventReceivers using Site Settings application assemblies

Features

The Manage Event Handler site settings application provides you with the ability to view all events that have been associated to a site, any list of that site, and all Content Types for that site.

You can add event handlers, edit the sequence numbers and delete events registrations. Once the feature is activated, it is accessible from the Site Settings of any site

Feature – Event Handler Screenshot

Site Settings Event Handlers Screenshot

Manage Event Handlers" style="WIDTH: 916px; HEIGHT: 844px" height=844 alt="Site Settings > Manage Event Handlers" src="http://blogs.msdn.com/photos/brian_wilson/images/1909625/original.aspx" width=916 mce_src="http://blogs.msdn.com/photos/brian_wilson/images/1909625/original.aspx">

View Event Hhandlers Screenshot:

Add Event handlers Screenshot:

Edit Event handlers Screenshot:

Delete Event handlers Screenshot

Firstly, download the solution deployment code and wsp file from CodePlex here, and install in your SharePoint environment. (If you pick up any issues or have feature requests, please let me know so that I can add these to future releases.)

How to install

1. Follow the steps in my previous post in the "Deploying your assembly to staging and production" section. It provides step by step instructions on how to install a wsp file.

2. Navigate to any site and open Site Settings.

3. Open “Site Features” under the Site Administration column.

4. Activate the new feature called “Manage Event Handlers”. This enables event handler management application for this site.

5. Navigate back to Site Settings. A new option is now available under the “Site Administration column” called “Manage Event Handlers”. Select this option.

Notes

I have removed the ability to edit or delete native SharePoint generated event associations as this may affect the stability of SharePoint Out-Of-The-Box functionality. Only YOUR events can be managed.

Content Types (and their associated event handlers) can only be managed via the root site of the site collection.

In case you are wondering how to go about building your own site settings applications I have posted the code on CodePlex. I am planning on building an additional site settings administration application to manage and configure site properties.

Summary

If you have any questions, add a comment and time permitting, I will try to respond as soon as possible.

Event Handlers - Part 2: Building and Deploying Event Handlers (Including Event Handler Starter Solution Kit)

Brian Wilson — Sun, 18 Mar 2007 17:04:00 GMT

This post is the second post of a 3 post series.

Post 1: Everything you need to know about MOSS Event Handlers

Post 2: Developer Solution Starter Kit (Building and deploying event handlers to MOSS)

Post 3: Registering Event Handlers plus Site Settings - Manage Event Handlers

Overview

In the first post, I discussed the benefits of using Event Handlers in Microsoft Office SharePoint Server 2007 (MOSS). Today I intend to discuss how to develop and deploy event handlers to your farm environment.

I have used CodePlex to host the Event Handler Solution Starter Kit Project. The solution starter kit contains two projects, one project that contains the assembly and another that contains a solution deployment package builder project.

Download the EventHandlerSolutionStarterKit.zip to get started.

(In the third post, I will discuss the various mechanisms to attach (register) your assembly to a site, list, or content type. I will also share a cool add-on I developed for MOSS that allows you to manage event handlers via a custom Site Settings Administration Application).

Building Event Handlers for SharePoint

Development Environment

I recommend building a Virtual PC that has MOSS 2007, and Visual Studio 2005. There are numerous posts out there on how to build your environment, so I won’t go into that.

One point I will make is to keep a copy of virtual hard disk once you have finished building it. I find MOSS 2007 Virtual PC’s degrade over time due to defragmentation, dev, etc. It is easier to make a copy of your original hard disk and continue developing.

Steps

Use the following steps if you want to create your solution from scratch otherwise download the starter kit and continue from Step 7.

1) Open Visual Studio 2005.

2) Create a new class library project.

3) Reference the Microsoft.SharePoint assembly.

4) Rename the default class to the name you want to give your event handler class. E.g. ItemHandler

5) Add your “using” statement: “using Microsoft.SharePoint;”

6) Inherit from the following SharePoint base classes depending on what type of event handler your want to create:

a. Site : SPWebEventReceiver

b. List Columns : SPListEventReceiver

c. List Items : SPItemEventReceiver

d. Email : SPEmailEventReciever

7) In your class, type “override” and let IntelliSense provide you with a list of events to override.

8) Implement the logic in the overridden method(s).

9) Compile, fix errors, recompile until build succeeds.

10) Strongly name your assembly ( sign your assembly )

a. Right Click your Class Library Project

b. Select Signing Tab

c. Choose a strong name key file:

i. <browse> = select a previously created key file.

ii. <new> = create a new key file.

Deploying your Assembly to staging and production

Steps

1) Create a solution deployment file (*.wsp file)

A solution deployment file is simply a cab file with a manifest file. It contains all the files and information of your solution. The manifest file tells SharePoint what to do with the files in your solution.

To get started, download my solution starter kit. This contains a visual studio deployment file creator project based on Vincent Rothwell’s fantastic visual studio deployment project template to create the *.wsp file. Have a look at his blog and codeplex project for more information on using this functionality:

· Blog: VS.Net SharePoint Solution Template on CodePlex

· CodePlex: http://www.codeplex.com/sptemplateland/

NOTE: I have customized the CreateManifest.vbs script in the deployment project so that it only creates the relevant entries to deploy the assembly dll to the GAC.

If you want to build your own deployment project from scratch or learn more about this feature of MOSS, have a look at the following articles on the Microsoft Developer Network (MSDN):

· Solutions Overview

· Creating a Solution

· Deploying a Solution

· Upgrading a Solution

· Retracting a Solution

· Localizing a Solution

· Solution Schema

2) Register your wsp file using stsadm.exe with SharePoint

Once you have created your SharePoint solution deployment file, you need to tell SharePoint about this. Here are the steps you need to follow to register your solution in SharePoint:

· Open up Command Prompt (Start > Run > cmd.exe)

· Navigate to the location of stsadm.exe utility in the “12” hive by typing the following into the command prompt (assuming default installation to C: drive)

o cd\

o cd C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN

· Run the following command

stsadm.exe –o addsolution –filename C:\replacewithpathtofile\filename.wsp

3) Push solution to SharePoint farm

You have two options:

· Navigate to Central Administration >Operations > Solution Management. You should see your newly added solution in the list.

o Click on it to view the solution details page.

o Select Deploy Solution on the toolbar.

· Alternatively, you could replace the option above and deploy the solution via the command prompt using the following command:

stsadm.exe –o deploysolution –name filename.wsp –local –allowgacdeployment –allcontenturls

Summary

A sign of a great developer is the ability to put the finishing touches on the development effort. When it comes to deployment, you aim to achieve the following goals:

1. Simple to deploy!

o Use SharePoint solution deployment (*.wsp) files

o Script the installation to deploy your wsp files

o Document (Readme) files for any settings/ procedures to install/ “gotchas”.

2. Simple to maintain!

What maintenance tasks must be performed by SharePoint Administrators? Is it documented? If you or they left the company, would your solution degrade and die a horrible death (which would inevitably be blamed on you)? Where are you storing your maintenance documentation? Have you thought of adding tasks to SharePoint Central Administration Task List to remind people of administrative tasks?

3. Simple to upgrade!

This is something that we often forget to think about upfront, resulting in loss of our solution’s future agility. All solutions are developed in phases. The first phase is normally the core of the solution. Subsequent phases add on functionality to your solution. These need to be deployed to replace/ add on to your solution. SharePoint Solution Deployment manages this for you, so know and use this feature of MOSS 2007.

4. Consistency and Repeatability!

This applies to how your solution is deployed to staging and production environments. You will not always be the person deploying it! Follow a standard pattern of deployment to minimise mistakes or random variations in the deployment process.

If you have any questions, add a comment and time permitting, I will try to respond.

Goodluck!