Welcome to KnowledgeLink - The AKG Blog

Sending alerts to groups in SharePoint 2007

Posted by Michael Perry on Wed, Jan 30, 2008 @ 11:01 AM

Creating an alert that sends to a group can be a powerful feature in SharePoint, however even though it seems straight forward there are some tricks to make it work and it is 'clunky' in some areas. The first trick is that the groups need to be 'email enabled security groups'. Distribution lists do not show up in the people picker. The second trick, and the one that is not documented is that you will need to explicitly add the group that you intend to email to a permission group in the site collection, site, or list, etc…  Basically wherever you have your permissions defined for the content you are alerting on. The basic viewers or visitors groups will suffice. N.B. I would still recommend adding users explicitly by user account to the members group of a site so that the site will show in their membership webpart of their mysite.

Now just create the alert as you would conventionally from the 'Alert Me' item on the action menu of the list or library.

In the 'Send Alerts To' item remove your own name from the list and add in the group name. Make sure you select the options correctly! After the alert is created an email will be sent to the group announcing that they have been subscribed to an alert.

Now please be a considerate corporate citizen when configuring the alert as the members of that group may not appreciate the flood of emails that they may receive.

The Limitations

Let me digress here and show what an alert looks like for an individual user. In this case I have created an alert to myself on a document library called docs. If go to the actions menu, then alerts, then select, 'view my existing alerts on this site', you will see the following screen.

Note that the alert called 'Docs' is a hyperlink to the edit alert page. From here you can modify the alert such as changing the frequency, the change type, etc.

Now for the group alert. The only way to access the alert is to go to Site Actions / Site Settings. Then select 'User Alerts' from the Site Administration column.

In the drop down list 'Display Alert For' you will now be able to see the group name that you specified. Click update to show the details. You will notice that from this screen the list of alerts for either users or groups is not a hyperlink.

So the big downside is that you cannot modify the alert for the group. You can only delete it and recreate it, which will send another announcement email to the group.

Original content source: Gavin's SharePoint Blog

Read More

Topics: moss sharepoint, sharepoint moss, moss, SharePoint, MOSS 2007, limitations, Team Sites, Microsoft SharePoint technology, Microsoft, technology implementation, site collection, alerts, site

Automatically Turning on the Publishing Feature on a SharePoint Team Site

Posted by Michael Perry on Mon, Jan 28, 2008 @ 11:01 AM

The Collaboration Portal template included as a part of SharePoint 2007 is a template that I use most often because of the features that it provides. It is a central location for master pages and CSS styles that are used throughout the sub-site of the main portal. One problem I have found with this is that when a team site is created under a collaboration portal the master page is not applied. When I go to "Site Settings -> Look and Feel -> Master Page" after a team site is created I see the following error messages:

This is because the Publishing Feature is not activated on a team site by default. I can do one of two things to correct this issue. One choose the master page I wish to apply to the site and second is to go to "Site Settings -> Site Administration -> Site Features" and enable the Office SharePoint Server Publishing feature.

Either of these choices may not be an option if your organization has governance policies that dictate what master pages are applied to a team site when it is created. This is also a problem for site owners that may not know how to delve through the SharePoint Site Settings to find how to change the master page for their site, also if you are creating many sub-sites this could be an administrative burden. Trying to find newly created team sites and then applying the proper master page throughout each site in the site collection.

In my search for an answer to this problem I found that there are many people who have either created a new team site definition or a SharePoint feature to fix this problem. Although a new site definition is a possible solution I do not need any new list or libraries with the team site when it created so I decided to go with a SharePoint feature to enable the Office SharePoint Server Publishing Feature when a team site is created.

There is a little known feature (at least to me until lately) called the "Publishing Stapling" feature. What this feature does is it enables the Publishing feature on a select set of SharePoint site templates. Here are a few of the templates that are included in this feature: SPSPORTAL#0 – Collaboration Portal, CMSPUBLISHING#0 – Publishing Site. If you want to see all the templates included in this feature go to the following directory: "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\PublishingStapling" and look in the publishingStapling.xml file. Naturally these are sites that would have publishing enabled but what about the sites that are created under these publishing portal templates? After researching this subject I found that many people have created custom solutions that enable either the publishing feature or the automatic application of a master page upon site creation but I was looking for a solution that would not require code to be deployed to the SharePoint Server. I looked for and answer on Microsoft's MSDN and TechNet sites but only found the following:

Retrieved from: http://support.microsoft.com/kb/936908

What is feature stapling?

A basic explanation of feature stapling is that it is used to attach one or more features to a SharePoint site definition without modifying an existing site definition or creating a new site definition. Fro a more detailed explanation I recommend reading Chris Jonson's blog on "Feature Stapling in WSS V3".

After reading this TechNet article I decided to create a simple stapling feature based off the Publishing Stapling feature that would be applied the SharePoint Publishing feature whenever a team site is created in the SharePoint Farm. This way when site owners create a new team site publishing will be enabled and the site will inherit the master page from the site above it. If the site owner wants to change the look and feel of the site they can either choose the default.master page or turn off the Publishing feature but the site will maintain the same look and feel of the main portal site throughout the site collection by default. So now how did I do this?

The easy way would have been to add the STS#0 – Team Site into the existing Publishing Stapling feature but this file could be changed whenever an update or patch is applied, also it usually not a good idea to modify files in the 12 hive that are installed during the SharePoint installation. So I created a copy of the existing Publishing Stapling feature and then made modifications to the copied files. Here is a step by step explanation of what I did.

  1. Copy the "PublishingStapling" folder in the following location: "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES"
  2. Renamed the "Copy of PublishingStapling" folder to "MyPublishingStapling"
  3. Renamed the file in the "PublishingStapling" folder from "PublishingStapling.xml" to "My PublishingStapling.xml"
  4. Opened the "feature.xml" file in the "PublishingStapling" and made the following changes:

Here is the original: "feature.xml" file:

<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="001F4BD7-746D-403b-AA09-A6CC43DE7942"
Title="Publishing Features Stapling"
Description="Staple Publishing features"

<ElementManifest Location="publishingstapling.xml"/>


Here is the file after my modifications:

<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="001F4BD7-746D-403b-AA09-A6CC43DE7943"
Title="My Publishing Features Stapling"
Description="My Staple Publishing features"
<ElementManifest Location="Mypublishingstapling.xml"/>

As you can see only minor modification were made and I changed the Feature Id so it would not conflict with the existing Publishing Stapling feature and install properly. Also note that this feature is scoped to the entire farm, this feature could be scoped to the web application or site collection level depending on the requirements for your SharePoint Farm.

  1. Then I opened the "MyPublishingStapling.xml" file.

Here is the original "MyPublishingStapling.xml" file.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="SPSPORTAL#0" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="SPS#0" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="SPSREPORTCENTER#0" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="SPSTOC#0" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="SPSTOPIC#0" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="SPSNEWS#0" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="SPSNHOME#0" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="SPSSITES#0" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="SRCHCEN#0" />

    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="CMSPUBLISHING#0" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="BLANKINTERNET#0" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="BLANKINTERNET#1" />
    <FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="BLANKINTERNET#2" />

    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="SPSPORTAL#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="SPS#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="SPSREPORTCENTER#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="SPSTOC#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="SPSTOPIC#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="SPSNEWS#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="SPSNHOME#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="SPSSITES#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="SRCHCEN#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="CMSPUBLISHING#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="BLANKINTERNET#0" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="BLANKINTERNET#1" />
    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="BLANKINTERNET#2" />

Here is the file after I removed the default entries and added the Team Site definition:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

    <FeatureSiteTemplateAssociation Id="94C94CA6-B32F-4da9-A9E3-1F3D343D7ECB" TemplateName="STS#0" />


As you can see you could add other site definitions to this file so when any site is created the publishing feature is enable but we decided to only enable publishing on Team Sites since they are the most widely used. Although through feature stapling you could enable custom workflows to be enabled whenever a Meeting Workspace is created using this example.

Once the files have been modified all that is left to do is to install the feature using stsadm.exe.

Here are the commands I used to install the feature:

Stsadm.exe –o installfeature –filename MyPublishingStapling\Feature.xml

Once this command is completed the feature is installed. On the environments where I have installed this feature I did not have to activate it after installing the feature. I ran the activate feature command just to be safe.

Stsadm.exe –o – activatefeature –filename MyPublishingStapling\Feature.xml

Once this command completes it will state that the feature has already been activated to the farm. If you are installing and activating this feature to a web application or site collection the stsamd.exe command will be different. Please review Microsoft's site foe the stsadm.exe index of commands here: http://technet.microsoft.com/en-us/library/cc263384.aspx

The last operation to perform is a reset of IIS for the feature to be used on any new Team Sites that are created.


There may be other ways to do what I have shown in the post but most that I have found require some programming which may not be optimal in some environments. If you find a better way or even another way of doing this please send me an email and let me know.

Read More

Topics: sharepoint best practices, collaborative technology, moss sharepoint, sharepoint moss, SharePoint, Collaboration, Team Sites, best practices, Publishing Stapling

Enabling the Mobile Web View on MOSS Collaboration Site

Posted by Michael Perry on Mon, Jan 28, 2008 @ 11:01 AM

The mobile web view is not enabled on a MOSS Collaboration Portal site by default. You can still access the mobile web view by going to http://YourPortalSiteURL/_layouts/mobile/default.aspx To enable the mobile web URL of http://YourPortalSiteURL/m on a MOSS collaboration portal you must use the stsadm tool to activate this feature. You can use the following command to active the mobile web feature:

Read More

Topics: sharepoint best practices, collaborative technology, office collaboration, moss sharepoint, sharepoint moss, sharepoint deployment, moss, SharePoint, portal, Mobile Web

Faster, Better, Cheaper

Posted by Lindsay O'Bannon on Fri, Jan 25, 2008 @ 09:01 AM

Most technical issues are resolvable. A well-trained, capable technical support representative will usually be able to find a good resolution to nearly any problem – given enough time. Time, however, is a very expensive commodity. In the technical support market, where billing is based on the number of minutes on the phone and contracts may be in the millions of dollars, it only makes sense to minimize the time a representative spends on each issue. And, of course, the sooner a resolution is found the happier the customer will be. This means that the most crucial tool in a support environment is a well-populated database containing known problems and solutions. Traditionally such a database has been a slowly-changing and maintained by a small group of contributors. This approach has value, but also has a great many drawbacks. There is a need for a faster, more accessible database which can be updated by any user – a wiki.

Read More

Topics: knowledge management, KM, knowledge transfer, knowledge Sharing, Sharepoint 2003, Wiki

Why SharePoint Implementations Succeed (or Fail)

Posted by Sue Hernandez on Tue, Jan 22, 2008 @ 11:01 AM

It has been proven time and again that simply introducing new technology to a business or a business/functional unit does not automatically solve their needs. This is particularly relevant with SharePoint technologies, which has been marketed as a "self-service" business solution. This gives the users direct involvement in setting up their sites; however, this can often back-fire if enough thought has not been put in to the content, layout, and usage of the sites.

Read More

Topics: sharepoint best practices, collaborative technology, Collaboration, knowledge management, Microsoft SharePoint technology, best practices

What is SharePoint made of?

Posted by Lindsay O'Bannon on Thu, Jan 17, 2008 @ 11:01 AM
What is SharePoint Made of?

by: Benjamin Hartley

Tags: lists SharePoint web parts

SharePoint can be a pretty scary thing at first. It's full of a bewildering array of tools: sites, collections, web parts, lists, document libraries, calendars, wikis, meeting spaces… sometimes it just seems like too much – almost as if SharePoint has too much functionality.

Wouldn't it be nice if there were a simpler way to look at SharePoint? A secret truth behind all the pieces, that puts them all together? There is.

I was working on SharePoint for several months before I finally realized this: SharePoint is built entirely, almost exclusively, on lists. Every piece of information in SharePoint is stored in a list. If you start poking into the guts of your site, behind the web parts, you'll find them. Lists. The wikis? Lists. The calendar? Lists again. Even the document library is a list.

But these are very different kinds of information! They shouldn't all be lists, right?

Well, not exactly. A list is just a container full of information kept in some sort of order. It can be a list full of text, with a unique number assigned to each entry. It can be a list of documents, with metatags and other information for organization – a document library. It can be a list of dates and times, with other information added on – a calendar.

Of course, this begs the question: if these are all lists, why do they look so different? Web parts are the answer. Web parts are components which perform the actual function of displaying lists. Web parts are very particular as to the lists they'll display, but they display those lists exactly as you want them to display. A web part can turn a list of dates into a calendar, or a list of text entries into a wiki. But at the heart of it, they're all lists. In fact, CorasWorks uses lists to control the display of menus!

So, in essence there are three parts to SharePoint: the Lists, which contain information, the Web Parts, which control how list information is displayed, and Web Sites, which contain Web Parts. There are a few exceptions, but the vast majority of SharePoint's functionality comes from these three basic elements.

For day to day use of SharePoint, this really isn't all that important. Whether or not you're aware of how the parts of SharePoint interact, they'll continue to function. To truly understand SharePoint, though, it's crucial to realize what the various pieces do and how they interact.

Read More

Topics: SharePoint, lists, web part

Building a Simple Web Part for MOSS 2007 using Visual Studio 2005

Posted by Janetra Meyers on Fri, Jan 4, 2008 @ 03:01 AM

The purpose of this post is to show how to build a simple web part in Visual Studio 2005 and deploy it to a MOSS 2007 SharePoint site. The Hello World web part is a web part that displays simple text using ASP.Net 2.0 and the C# programming language. View Tutorial (in PDF file format).

Read More

Topics: SharePoint, MOSS 2007, ASP.NET 2.0, C#, Hello World, web part