Sharepoint Tips and Tricks

How to build a Sharepoint Silverlight Beta 2 Webtart?

2008-06-25T23:43:00.001-07:00

How to build a Sharepoint Silverlight Beta 2 Webtart?

If anyone is in need of the above topic pls add your comments.

SilverLight for SharePoint

2008-06-17T21:04:00.000-07:00

SharePoint is quickly becoming one of Microsoft's most important offerings. Essentially a highly customizable content management system, many companies are finding it a perfect fit for their internal websites.
A key feature of SharePoint is its support for Web Parts. Web Parts are widgets written in ASP.NET to add user customizable functionality to a web site. Architecturally, they fill the gap between controls and full pages.
Microsoft has recently released what they call the Silverlight Blueprint for SharePoint. This is a set of examples and guidance for adding Silverlight-based Web Parts to SharePoint sites. The components included as examples are
Six application component samples are included in the kit to get you started:

A simple “hello, world” sample showing Silverlight in a Web part.
A Silverlight slider control as a SharePoint custom field type.
A navigation control.
A Colleague Viewer that uses lookups in Active Directory by using Windows Communication Foundation.
A Silverlight picture viewer from a SharePoint picture library.
A visual how-to center, created in Silverlight and based on a SharePoint list, for viewing videos.

Microsoft's Blueprint initiative is meant to teach developers how to properly use Microsoft technologies. Unlike the usual collections of examples, their focus is more on how one should use a given library than simply showing what is possible.

HOWTO: Configuring a Office SharePoint Server 2007 Publishing Site with Dual Authentication Providers and Anonymous Access

2008-05-19T09:40:00.000-07:00

Content-centric sites that are managed via a Content Management System typically have very specific requirements. The owners of the content of a content-centric site usually spend most of their time behind the company firewall and login to their corporate Active Directory. Ideally these users need to have a single-sign-on (SSO) experience where they don't have to remember a special username and password to simply login to a Content Management System to author and manage the content on the company Web site. The public-facing portion of the site needs to allow visitors to browse the site anonymously. However, there may be certain areas of the site that require the user to login. These may include premium content, registration, or an e-commerce solution. While the familiar username/password dialog is acceptable in a corporate setting, it is frowned upon on the public realm of the Internet. Therefore, many companies prefer to implement some type of forms authentication where users login using a username or email address and password to gain access to protected areas.

Web Content Management (WCM), one piece in the Enterprise Content Management (ECM) strategy included in Microsoft Office SharePoint Server (MOSS) 2007 adds the capability of hosting and managing content-centric sites to the SharePoint platform. MOSS 2007 is built on top of Windows SharePoint Services (WSS) v3 which is in turn built on top of ASP.NET 2.0. This means that WSS v3 (and MOSS 2007) have full access and utilize everything that ASP.NET 2.0 has to offer… including the pluggable authentication model. It is this pluggable authentication that I will leverage to provide multiple authentication options for a single Web site. In this article I want to demonstrate how to configure a Publishing Site (aka: WCM site) in MOSS 2007 for the previously described common scenario companies encounter with content-centric sites. The goal is to provide an experience that achieves three requirements:

Allow content owners/authors to authenticate on the site using their corporate Active Directory credentials in order to manage the Web site's content.
Allow unauthenticated, anonymous users, to browse the unrestricted areas of the Web site.
Require anonymous user to provide a friendly Web-based form to login in order to consume restricted content.
I'll demonstrate how all three goals can be achieved using MOSS 2007 and WSS v3 in this article. First I'll set up a database to store the information for users accessing the Web site from the Internet. Once that's configured, I'll create two Web applications and a Publishing Site; each Web application, or IIS Web site, will be configured for a specific type of authentication mechanism (Windows Authentication [AD] and Forms Authentication). Then I'll configure both Web applications so they can access the users and roles that will be granted rights within the site (typically read or contribute rights to protected areas of the site). Once both sites are configured to communicate with the forms authentication-based user and role store, I'll configure one Web application to allow users to sign-in and authenticate via a common Web-based form. The last step will be to configure the site for anonymous access so they can browse the site and consume the content. Finally, I'll show you how to require a login for a specific area of the site.

This article is not written as a step-by-step instruction manual on how to configure your site for anonymous access with dual authentication mechanisms. It assumes some experience with WSS v3 and MOSS 2007. While the subject of this article deals with configuring a Publishing Site (aka: Web Content Management Site), everything translates to any type of WSS v3-based site including MOSS sites.

Setting Up ASP.NET 2.0 Forms Authentication User & Role Data Store

Before we can do anything, we first need to create a database that will store all the information, credentials, roles, and users for the forms based authentication site. Then we'll add a single user to this database which we'll use for testing later. Nothing in this step has anything to do with SharePoint as its just plain ASP.NET 2.0.

Create the ASP.NET 2.0 Database

Before we can do anything else, we need to create a database that will store the users and roles. Microsoft has provided a utility, aspnet_regsql.exe, that will create this database for you. It can be found here: %windir%\Microsoft.NET\Framework\v2.0.5027. Executing this file will trigger a wizard that will walk you through creating the ASP.NET 2.0 database. I've named my database AcAspNetDb and configured it for Windows Authentication, as shown in Figure 1 below.

Figure 1 – aspnet_regsql.exe wizard (click for larger image)

Configure Membership & Role Providers

Now that our database is configured, we need to add a single user. In my opinion, the best way to do this is to create a new Web site project in Visual Studio 2005. Why? Because not only does it have an easy way to access the ASP.NET 2.0 administration Web site that will let us add users and roles, but we'll also ensure our database connection strings, membership, and role providers are correctly configured before we bring SharePoint into the equation. I'll use these same connection string and providers in the SharePoint sites later… so we have a good foundation to copy from.
Open Visual Studio 2005 and select File -> New -> Web Site. In the New Web Site dialog, select the template ASP.NET Web Site, set the location to File System. I like to put all my Web sites in the [drive]:\Inetpub directory so I'll put mine in the following directory: [drive]:\Inetpub\AC FBA Utility Site (FBA = Forms Based Authentication). The language is irrelevant so you can pick anything… we won't write a single line of code.

Now, add a web.config file to the site. By default, you'll see a <connectionStrings /> node within the <configuration> node. Here you want to specify a connection string to the database you just created in the previous step. For me, I'll replace the node with the following:

1: <connectionStrings>
2: <add name="AcSqlConnString"
3: connectionString="server=[YourSqlServerName];database=AcAspNetDB; Integrated Security=SSPI;"
4: providerName="System.Data.SqlClient"
5: />
6: </connectionStrings>

With the connection string set up, now we need to specify the membership and role providers. In this article I'm using the ASP.NET SQL membership and role providers, so I need to add the following to the
web.config
file, within the
<system.web> node:

1: 
2: <membership defaultProvider="AcAspNetSqlMembershipProvider">
3: <providers>
4: <add name="AcAspNetSqlMembershipProvider"
5: type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
6: connectionStringName="AcSqlConnString"
7: enablePasswordRetrieval="false"
8: enablePasswordReset="true"
9: requiresQuestionAndAnswer="false"
10: applicationName="/"
11: requiresUniqueEmail="false"
12: passwordFormat="Hashed"
13: maxInvalidPasswordAttempts="5"
14: minRequiredPasswordLength="1"
15: minRequiredNonalphanumericCharacters="0"
16: passwordAttemptWindow="10"
17: passwordStrengthRegularExpression=""
18: />
19: </providers>
20: </membership>
21:
22: 
23: <roleManager enabled="true" defaultProvider="AcAspNetSqlRoleProvider">
24: <providers>
25: <add name="AcAspNetSqlRoleProvider"
26: type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
27: connectionStringName="AcSqlConnString"
28: applicationName="/"
29: />
30: </providers>
31: </roleManager>

There are a few things you should take note of from the above code (marked in bold). First, note the name and connectionString attribute for the providers. When you install the .NET Framework 2.0, default connection strings and providers are specified in the machine.config file (located in the %windir%\Microsoft.NET\Framework\v2.0.5027\CONFIG). You want to make sure you use unique names here and not the names that Microsoft has included as the default names in the machine.config file. If you elect to reuse their names, you'll need to explicitly remove each one by name (via the <remove /> node) or clear all predefined connection strings and providers (via the <clear /> node). To make it easy, I specified unique names, as indicated in bold.

With everything configured, launch the ASP.NET 2.0 Web administration site from within Visual Studio 2005: Website -> ASP.NET Configuration. When the site loads, the first order of business is to switch it from Integrated Authentication to Forms Authentication. To do this, select the Security link and then select the Select Authentication Type link in the Users container. If it isn't selected already, make sure From The Internet (aka: Forms Authentication) is selected and click Done.

Create A User

Next, we need to add a user that we'll later use for testing. Select Security again and then select Create User. I'm going to create a new user with the User Name of Shaji and Password of password. Note I don't have to enter a strong password because of some of the settings I changed in the membership provider in the code above. The E-mail address isn't important, so I'll just enter shajimji@gmail.com and click Create User.
Finally, let's make sure the markup in our web.config file is correct for our membership and role provider. To do this, select the Provider tab and then select Select a Different Provider For Each Feature (Advanced). You should see the membership and role provider that we specified in our web.config. Selecting the Test link for either should confirm they are successfully talking to the database.

At this point, we now have our ASP.NET 2.0 user and role database store configured. More importantly we should have a good template web.config containing the connection string, membership provider and role provider settings that we can copy from when modifying the web.config files for our SharePoint sites. Now we need some Web applications to configure!

Creating Two Web Applications, One For Each Authentication Mechanism

We need some sites to configure for authentication right? I mean, that's the point of the article right?

Creating the http://extranet IIS Web site
First step is to create a new Web application just like you would any other time. From SharePoint's Central Administration Web site, select the Application Management tab, then Create or Extend Web Application and then Create a New Web Application. I'm guessing if you're reading this article, you know how to create a new Web application from here… so I'll spare the details, but I want to point out is that I specified the following:

Set the Description as SharePoint – Extranet 80
Set the Port to 80

Set the Host Header to extranet

Picked NTLM as the Authentication Provider
Specified Anonymous Access to No

After creating the Web application, I then created a new site collection in the Web application naming the site Acme and picking the Publishing Portal site template. If you're having problems and want to see exactly what I selected, you can view Figure 3 displaying the Create New Web Application page or Figure 4 displaying the Create Site Collection page.

At this point we now have a site, configured for Windows Authentication, named ACME at http://extranet. This is the site our content owners will use to authenticate using their Active Directory corporate accounts in order to add, edit, and manage the content on our Publishing site. Make sure everything is working by browsing to the http://extranet Acme site. You should see the Welcome control and the Site Actions menu in the upper right-hand corner of the page. Assuming everything is working, we have now satisfied the first goal listed in the introduction above!

Creating the http://internet IIS Web site

Now we need to extend our Web application to another IIS Web site. This is the site our anonymous, or Internet users, will use to access the site. This site will need to be available to anonymous users as well as provide a mechanism for them to authenticate against, via Forms Authentication, in order to access restricted areas of the site (such as a member's only section). To extend the Acme Web application to another IIS Web site, from SharePoint's Central Administration, select the Application Management tab, then Create or Extend Web Application and then Extend an Existing Web Application. Again, I'll spare you from the details and highlight only a few important points on this page:

Make sure you select the Web application you want to extend… in our case we want SharePoint – Extranet 80. Use the Web Application selector at the top of the page to
pick the correct application.
Set the Description as SharePoint – Internet 80
Set the Port to 80
Set the Host Header to internet
Picked NTLM as the Authentication Provider
Specified Anonymous Access to No
Set the Load Balanced URL Zone to Internet

We'll enable anonymous access later.

Again, if you are having problems, you can see exactly what I selected from Figure 5. Now we have a site that we can configure for our Internet users to access anonymously and also login via Forms Authentication. However, before we do that, there are a few configuration tasks we have to do.

Configure The Web Applications To Communicate With The ASP.NET 2.0 Forms Authentication Data Store

Once you have a Web application created that will host a site, you will need to change its authentication provider to not use Windows Authentication but instead use Forms Authentication as well as configure the site so it can communicate with our user and role data store… the AcAspNetDb we created earlier. To do this, we'll use the connection string, membership provider, and role provider we created and already tested in our utility Web site's web.config file.

Configure http://extranet & http://internet
First, we'll modify the two IIS Web sites (http://extranet and http://internet) web.config files to include the connection string, membership provider, and role provider information so they can both communicate with our user and role store. It's obvious why the http://internet site would need these changes, but why make them to the http://extranet site when we're going to use it for Forms authentication? If we didn't, it would be somewhat difficult and inconvenient (but not impossible) when we needed to grant any special permissions in the Acme Web application to one of the users or roles in our data store. This way, one of our content owners can authenticate using his/her Active Directory credentials and still grant a user who will authenticate via Forms Authentication access within the site.

Open the web.config file for the http://extranet Web site, found in the following directory (if you let SharePoint specify the Web site root directory... otherwise, retrieve it from your specified path): c:\Inetpub\wwwroot\wss\VirtualDirectories\extranet80. Add the <connectionStrings> node, listed above, just after the closing </SharePoint> tag and opening <system.web> tag. Then add the membership and role provider markup, listed above, just after the opening <system.web> tag and save your changes. Do the same thing for the web.config for the http://internet Web site, found here: c:\Inetpub\wwwroot\wss\VirtualDirectories\internet80.

Configure SharePoint Central Administration

Now both Web applications are configured to communicate with the data store. There's one last step we have to do… we need to add the same information to the SharePoint's Central Administration Web site's web.config file. Why? We need to make sure the Central Administration Web site can communicate with the data store in case we want to do any security management of the users and roles in the data store such as configuring policies for the Web application. Repeat the steps above for the Central Administration's web.config which should be found here: c:\Inetpub\wwwroot\wss\VirtualDirectories\[#####]. You need to make one small change… change the defaultProvider attribute on the <roleManager> node to AspNetWindowsTokenRoleProvider. This is necessary because Central Administration still uses Windows Authentication for the role provider. The <roleManager> node for the Central Administration's web.config should look like this:

1: 
2: <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider">
3: <providers>
4: <add name="AcAspNetSqlRoleProvider"
5: type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
6: connectionStringName="AcSqlConnString"
7: applicationName="/"
8: />
9: </providers>
10: </roleManager>

Now we're finally ready to configure the http://internet site for Forms Authentication!

Enabling Forms Authentication On One Web Application

Flipping the switch to Forms Authentication is very simple… it's just all the prep work that's the complicated part. Browse to SharePoint's Central Administration Web site, select the Application Management tab, and then select Authentication Providers. First, ensure you are working with the correct Web application by checking the selector in the upper right-hand corner of the Authentication Providers page (as shown in Figure 6). Once you're on the correct Web application, select the Internet zone link (as shown in Figure 6).

Figure 6 – Authentication Providers page

Note that even though we've selected the http://extranet Web application, we are really modifying the http://internet IIS Web site because that's the one mapped to the Internet zone.

On the Edit Authentication page, we are going to change the Internet zone for the http://extranet Web application to the following settings:

Authentication Type: Forms
Enable Anonymous Access: checked
Membership Provider Name: AcAspNetSqlMembershipProvider
Role Manager Name: AcAspNetSqlRoleProvider

Notice that the names of the Membership Provider Name and Role Manager Name are the names of the providers we entered in the web.config's. Now you see why we had some pre-configuration work to do before we actually made the switch. Refer to Figure 7 to see all settings I selected on the Edit Authentication page.

We now have two different ways for users to get to our Acme Web application:

Via http://extranet, authenticating using Windows Authentication (using their Active Directory credentials)
Via http://internet, anonymously or authenticating using Forms Authentication

Ah.. but we're not quite finished. Even though the http://internet Web site is now configured to allow anonymous users, the Acme Web application has not been set to grant permission for anonymous users to browse the site. You can prove this by trying to browse to http://internet. You'll immediately get redirected to the default SharePoint Forms Authentication Sign In page, as shown in Figure 8.

Figure 8 – SharePoint's default Forms Authentication Sign In Page

Let's prove that the Forms Authentication is actually working with our data store. First we need to add our user to the site. To do this, browse to the http://extranet Web site, select Site Actions, then Site Settings, then People And Groups. Select the New button to add a user to the site. On the Add Users: Shaji page, enter the username of the user we created previously: Shaji. Then click the Check Names icon (little icon with a blue check just below the Users/Groups input box… or press [CTRL]+[K]). In the Give Permission section, select Add Users To A SharePoint Group and select Shaji Visitors [Read] and finally click OK. We've now granted our user access to the site.

To test, open a new browser window and browse to http://internet. You should immediately get sent to the SharePoint Sign In page. Enter the account's credentials (Shaji/password) and click Sign In. You'll then get signed in and redirected back to the homepage of the site. You can see you're logged in because you can now see the Welcome control in the upper right-hand corner of the site. Notice how you can't see the Site Actions menu? That's because we only have the rights assigned to Visitors, which means we can't do anything to the site but browse it.

Last step… let's open the site up for anonymous users…

Enabling Anonymous Access

In order for anonymous users to have access to the Acme Web application and browse the site, we need to turn anonymous access on. In our case though, we only want to turn anonymous access on for the external (or http://internet) site. Before we do this, we should create a new account in our ASP.NET 2.0 database that we can use as an administrative account to make changes to our external site. First, create a new account using the same process in the Setting Up ASP.NET 2.0 Forms Authentication User & Role Data Store: Create A User section above. I'm going to create this account with the following credentials:

Username: FbaAdmninistrator
Password: password

Next, we need to grant this user ownership-level rights to our http://internet site. WSS v3 introduces a new capability where we can specify a user to have full control over a site via Web Application policies. These policies trump any permission setting within the site itself. We'll use this to set a policy to grant the FbaAdministrator full control over our http://internet site. Browse to Central Administration, select the Application Management tab, then Policy for Web application under the Application Security section. Make sure you've selected the correct Web Application from the selector in the upper-right corner of the page (in our case, we want to select http://extranet). Next, select Add Users from the toolbar. On the Add Users page, select the Internet zone (because this is the zone we specified for our http://internet Web Application) and click Next. Finally, enter the user FbaAdministrator in the Choose Users step, select Full Control in the Choose Permissions step, and click Finish. Now you can login to the http://internet site and have full control over the site, just like the site owners have.

Now we can setup anonymous access for our http://internet site. To do this, browse to the http://internet Web site, login using the FbaAdministrator account we just created and configured, select Site Actions, then Site Settings, then Modify All Site Settings. On the Site Settings page, select Advanced Permissions. On the Permissions: Acme page, select Settings, and then select Anonymous Access (see Figure 9). On the Change Anonymous Access Settings: Acme page, select Entire Web Site and click Ok.

To test, open a new browser window and browse to http://internet. You should go straight to the Web site as an anonymous user! You can tell you aren't signed in because there's a Sign In link in the upper right-hand corner of the site where the Welcome control usually is. We have now satisfied the second goal listed in the introduction above!

Configuring A Section Of the Site For Authenticated Users Only

Our last goal was to configure a section of the site so that users must be authenticated to have access to that section's, or site's, content. To do this, we'll have to go back into our site as through the http://extranet. Because the site is now set up for anonymous access, you won't automatically be signed in, so you'll have to click the Sign In link in the upper right-hand corner. Because we created the site using the Publishing Portal template, there's a subsite named Press Releases in our site collection.

Let's make it so this site requires the user to login. Select Site Actions and then Manage Content and Structure. On the Site Content and Structure page, select Press Releases from the left-hand navigation tree and then select Advanced Permissions (see Figure 10).

Figure 10 – Press Releases Advanced Permissions

Next, we'll break the permission inheritance with the parent site and then remove anonymous access to the Press Releases site. First, select Actions and then Edit Permissions. You'll be prompted to accept your changes… select OK. Next, Select Settings, then Anonymous Access, then on the Change Anonymous Access Settings page, select Nothing and click OK.

Now let's test it… open a new browser window and navigate to http://internet. Notice how the Press Releases section isn't on the horizontal navigation (see Figure 11)? Now sign in using the Sign In link in the upper right-hand corner and watch how the Press Releases section now appears since we're authenticated (see Figure 12)! We have now satisfied the third goal listed in the introduction above!

Figure 11 – Unauthenticated User With Press Releases Site Hidden

Figure 12 – Authenticated User With Press Releases Site Visible

Conclusion

In this article I have demonstrated how you can create a Publishing Site in MOSS 2007 and configure it for two types of authentication and at the same time allow anonymous users to browse the site. So where would you go from here? Some possible next steps would include creating a self-registration system for users to create their own accounts and have these accounts automatically registered on the site under a specific role so no additional management action is required by the site owners.

Authentication and Authorization

2008-05-16T23:43:00.000-07:00

At their core, the membership and role providers exist to provide authentication and authorization services to our applications. Authentication is the process verifying the identity of a user. The membership provider can create new users and passwords in a database, and validate a user’s identity using the saved information. The membership provider uses a Microsoft SQL Server database. There is also a membership provider available for Active Directory, but this article will concentrate on the SQL Server membership provider.

ASP.NET 2.0 provides login controls we can drop on web forms to perform authentication with no code required. The controls talk directly to the membership provider. ASP.NET 2.0 also offers controls to support the ongoing maintenance of users, including changing passwords and resetting passwords. All of these controls build on top of features of the membership providers.

Once we know who a user is, we can find out what we will allow the user to do – this is authorization. The role providers in 2.0 allow us to create roles, and map users into the roles. For example, you might build an application with two roles: Administrators and RegisteredUsers. Given a username, the role manager can tell us to which roles a user belongs. Areas of a web application, or specific operations, can be restricted to exact roles.

Of course, your application might have special needs. Perhaps your database is not Microsoft SQL Server. Fortunately, Microsoft implemented both membership and role management using an extensible provider model. The provider model is the keystone of the membership and role services, so we will begin our tour of the functionality by covering what a provider does.

Providers

The provider model in ASP.NET 2.0 provides extensibility points for developers to plug their own implementation of a feature into the runtime. Both the membership and role features in ASP.NET 2.0 follow the provider pattern by specifying an interface, or contract. If you build your component to fulfill the contract a provider defines, you can plug your code into the ASP.NET runtime and replace or extend the existing providers. The provider model in ASP.NET 2.0 includes an infrastructure for the configuration and initialization of providers.

The provider model begins with the abstract class ProviderBase. ProviderBase exists to enforce the contract that all providers need public Name and Description properties, as well as a public Initialize method. Inheriting from ProviderBase are the MembershipProvider and RoleProvider abstract classes. These classes add additional properties and methods to define the interface for their specific areas of functionality.

As an example, the MembershipProvider requires a membership class to implement a ValidateUser method. The default membership provider in 2.0, the SqlMembershipProvider, implements this method by executing a stored procedure in a SQL Server database. If you want to write your own provider to use an XML file as a data store for membership information, you’ll have to write the code for ValidateUser to verify a user’s password against information kept in the XML file.

The beauty of the provider model is this: higher-level application services can build upon a provider and not need to know the details of what happens behind the interface. A good example is the ASP.NET 2.0 membership controls, which include a Login control, a CreateUser control, a LoginStatus control, and more. All of these controls program against the MembershipProvider contract. At some point, the login control will need to invoke the ValidateUser method on the configured provider. The login control doesn’t care if the call travels to a SQL Server database or an XML file. All the login control cares about is passing in a username and a password and receiving a true or false value in return.

The MembershipProvider

The purpose of the MembershipProvider is to provide a layer of indirection between membership controls, like the LoginControl, and the data store containing membership information. The indirection means we can use any data store (SQL Server, Oracle, XML, Web Service, Active Directory), as long as we have a provider to hide the details behind the public methods and properties of a concrete class. As we mentioned earlier, ASP.NET 2.0 includes providers for SQL Server and Active Directory.

A successful .NET installation will configure the SqlMembershipProvider class from the System.Web assembly as the default membership provider. You can verify the default by looking to the machine.config file, which applies settings to all the managed applications on a computer. The machine.config file is found in the config directory where the framework is installed, typically \Windows\Microsoft.NET\Framework\v2.0.xxxx.

Configuring The Membership Provider

The membership section of machine.config contains a variety of knobs we can tweak – many of these tweaks involve user password management.

To take advantage of membership features, all you’ll need to do is use the new Login web controls in ASP.NET 2.0. The CreateUser control provides all the UI and implementation needed to fetch a user’s name, password, email, and security question and answer. The PasswordRecovery control allows a user to retrieve an existing or reset password via email. To all the Login controls in action, take a look the Securing Your Application” ASP.NET tutorials.

The passwordFormat property specifies how the provider will store passwords, and will impact a number of other membership features. The SqlMembershipProvider supports three formats: Hashed (the default and most secure format), Encrypted, and Clear. The hashed format passes a user’s plaintext password and a random salt value through a one-way hash algorithm before storing the password. You cannot retrieve a hashed password. To validate a password, the provider has to salt and hash the entered password and compare the two hash values (for more information on hashing passwords, see Pass The Salt). The provider can also store encrypted passwords (which can be decrypted and retrieved), or store passwords in the clear (which is not recommended).

The enablePasswordRetrieval option determines if the provider will return a user’s password with the GetPassword method. If the password format is set to Hashed, passwords are not retrievable. If the provider keeps passwords in an encrypted or clear text format, you could email a user’s forgotten password to them, but think of the security implications first. A more secure option in the event of a lost password is to reset the user’s password to a new value and email the new password (make sure to enforce unique email addresses with requiresUniqueEmail).

The enablePasswordReset property controls the ResetPassword API. ResetPassword will assign a new, generated password to a user. The PasswordRecovery control can automatically email the new password to a user. It a good idea to set the requiresQuestionAndAnswer property to true to prevent a malicious user from resetting someone else’s password, A value of true means the user has to provide the answer to a security question before resetting their password. The question and answer text is will be required by the CreateUser control when a adding a new user.

A number of properties control the password strength a provider will allow. The minRequiredPasswordLength and minRequiredNonalphanumericCharacters prevent users from choosing a password like “abc”. If you have additional requirements, you can use the passwordStrengthRegularExpression property to force the password to pass a regular expression test. Note: a password generated by ResetPassword will always meet the required password length and required number of non-alphanumeric characters, but may not meet pass the regular expression test.

The SqlMembershipProvider offers a number of features not shown in the configuration above. For instance, the maxInvalidPasswordAttempts and passwordAttemptWindow properties work together to prevent a malicious user from using brute force techniques to break into a user account. Too many bad passwords will lock out a user account and prevent the account from logging in until the account is unlocked with the UnlockUser method.

Membership and SQL Server

Other properties in the membership section control how SqlMembershipProvider interacts with SQL Server. By default, the machine.config file configures membership and roles to work with a SQL Server Express database file in the App_Data directory. Looking back at the configuration excerpt above, we see the connectionStringName property is “LocalSqlServer”. If you locate the connectionStrings section of machine.config you’ll find the following:

You can always override the default setting and point all providers using LocalSqlServer to a remote database, or a non-Express database on the local machine. The first step would be to use the ASP.NET Sql Server Registration Tool (aspnet_regsql.exe) to create a new database. You can find the tool in the .NET framework installation directory (WINDOWS\Microsoft.NET\Framework\2.0.xxxx). If you launch the tool without command line parameters, the tool will launch a wizard to walk through the setup for a new database. The default database name is aspnetdb.

One you’ve configured a database for the provider to use, you can modify the web.config file for your application to redefine the LocalSqlServer connection string to point to the new database.

Alternatively, you can define a new connection string and modify the connectionStringName property of a provider to use the new connection string.

You can test your settings with the ASP.NET Configuration tool (under the Website menu is Visual Studio). On the Provider tab, choose “Select a different provider for each feature”, and you’ll arrive at the following page that allows you to “test” each provider’s connectivity. The administration tool also contains pages to manage security settings, create users, and more.

Another important property to set in the membership configuration is the applicationName property. The applicationName allows one database to support multiple web applications. If you have two web applications and want both apps to share the same user base, give both applications the same applicationName and point them to the same aspnetdb database. If you want both applications to use the same database but not share users, give each application a unique applicationName property.

Using The Membership Provider

If you want to interact directly with the Membership API, one approach is to use the Membership class from System.Web.Security. The Membership class contains only static members and properties, but these static members map to properties and methods on the MembershipProvider, and the component will forward calls to the configured provider when appropriate. Here is an example using hard coded values for a user's attributes.

string username = "SwedishChef";

string password = "bj#kbj1k";

string email = @"swede@mailinator.com";

string question = "The greatest band ever?";

string answer = "ABBA";

bool isApproved = true;

MembershipCreateStatus status;

Membership.CreateUser(

username, password, email,

question, answer, isApproved,

out status);

if(status == MembershipCreateStatus.Success)

{

// party!

}

An even easier interface to the membership provider is to use the ASP.NET 2.0 Login controls: Login, LoginView, PasswordRecovery, LoginStatus, LoginName, CreateUserWizard, and ChangePassword. The Login control, for example, will ultimately call the ValidateUser method of the current membership provider when a user enter their username and password and clicks the Login button. There is no need to write any code if the built-in controls provide all the functionality you need. All of the controls allow customization various levels of customization through styles and templates. You can find the controls in the Visual Studio toolbox under the “Login” category.

Command Line Administration for SharePoint

2008-05-15T19:38:00.000-07:00

Think about how people interact with Windows or Microsoft Office. Some users are avid mousers, using the pointer to navigate menus and toolbars to perform common tasks. Others are comfortable

with the keyboard, quickly executing familiar keystrokes and shortcuts. For any given task, there is almost always several ways to get it done.

The fact is, a graphical interface can be easy to use, but it can be equally cumbersome for tasks that require you to do the same thing repeatedly. Some things are easier to do with the keyboard. If you do any SharePoint® administration, you've probably experienced what it's like to be bogged down in a graphical interface. But SharePoint actually offers a more powerful way to get things done.

The primary interface for managing Windows® SharePoint Services (WSS) and Microsoft® Office SharePoint Server 2007 (MOSS) is the GUI-based SharePoint Central Administration. But SharePoint also includes a command-line tool for more powerful administration. This tool, STSADM.exe, provides all the functionality of SharePoint Central Administration, but with the command-line flexibility many administrators desire. In this article, I will give you a crash course in using STSADM to manage WSS and MOSS. I'll also give you some tips on how to configure your environment and discuss some common STSADM commands. I will even show you some advanced STSADM commands that can make you look like a hero-if the need to use them ever arises

Getting Started

If you haven't stumbled upon STSADM, it could be because it is somewhat buried. In Windows SharePoint Services 2.0, it's in c:\program files\common files\microsoft shared\web server extensions\60\bin by default. The default location in version 3.0 is c:\program files\common files\microsoft shared\web server extensions\12\bin.

To simplify access to this tool, I use two different approaches. First, I simply add that directory to my PATH environment variable. This way I can use STSADM wherever I am in the file system. This, however, is not always an option. My second approach is to create a shortcut to CMD.EXE and set STSADM's location as the initial directory. Why not just point a shortcut directly to STSADM? This doesn't work since STSADM is not interactive. As a result, if you do point a shortcut directly to STSADM, you will be presented with a quick display of its usage and then it will be gone.

When you run STSADM, you need to be a member of the local Administrators group on the Web server, and you need to execute the app locally. This means you cannot use STSADM to remotely administer a SharePoint server.

To see what operations you can perform with STSADM, type stsadm.exe -help in a command prompt. Be sure to check this list after you apply updates and hotfixes to SharePoint since new operations may be added. There is also a handy guide to stsadm.exe operations available at go.microsoft.com/fwlink/?LinkId=77516.

STSADM Basics

Let's start by looking at some of the commands you might use to tweak your existing SharePoint installation. You can use STSADM to add functionality to SharePoint and to modify configuration settings.

STSADM uses the -o parameter followed by the operation you want to perform. Just typing STSADM -operationname will not work. If, for example, you want to add site templates to your installation, you can use the following command:

Stsadm -o addtemplate -filename -title <title> -description

Or, if you want to add a Web Part Package, you can use this command:

Stsadm -o addwppack -filename

For details on usage for any operation, simply pass the operation with no parameters and STSADM will tell you what it expects for input. STSADM -help operationname will also give you usage info.

When managing templates, you can use the enumtemplates operation to see which templates have been added and deletetemplate to remove any that are installed. Similarly, there are commands to work with Web Part packages. You can use the enumwppacks operation to list the Web Part packages installed on each virtual server or Web application, and deletewppack will let you remove any that have been added.

STSADM also has two operations that deal with SharePoint settings: setproperty and getproperty. Executing either with no parameters will give you a list of the properties you can view or manipulate. Like STSADM itself, this list changes with updates and hotfixes. Nevertheless, there are a few properties that are more useful than others. Figure 1 lists some of the properties you may want set after you get SharePoint installed, including the most common properties I hear SharePoint administrators ask about

Property	Function
Alerts-enabled	Turns alerts on or off for your virtual server or Web application.
Alerts-limited	Specifies whether users are restricted to setting a certain number of alerts on the virtual server or Web application.
Alerts-maximum	If alert limits are set, this is the maximum number of alerts that a user can set.
Days-to-show-new-icon	This sets how long the "New" icon appears next to items added to the Web site, like announcement posts, for instance.
Job-immediate-alerts	Specifies how often SharePoint looks for immediate alerts to send out. The default for SharePoint 2.0 is five minutes. You can adjust that interval here. Decreasing the time will increase load on your Web and database servers, so keep an eye on it if you change this property.
Job-daily-alerts	Specifies what time the daily alerts are sent out. SharePoint 2.0 defaults to "between 22:00 and 06:00." If you have users who are not in the same time zone as the server, you may want to adjust this property.
Job-weekly-alerts	You probably see the pattern here. This sets the schedule for weekly alerts

Figure 1

Let's take a quick look at using one of these properties. The following command will have SharePoint send out immediate alerts every 10 minutes:

Stsadm -o setproperty -pn job-immediate-alerts -pv "Every 10 minutes"

Notice I used -pn and -pv instead of -propertyname and -propertyvalue. These are acceptable shortcuts for those times when you don't want to type the entire word. Also note that all the examples and commands I have discussed in this section will work for both versions 2.0 and 3.0 of Windows SharePoint Services.

Daily Administration

Day-to-day SharePoint administration is pretty easy. For most SharePoint administrators, the bulk of daily tasks consist of working with users and sites. STSADM has several operations to streamline these tasks.

I'll start with sites and webs. For purposes of consistency, I will use "site" to refer to site collections and "web" to refer to subsites (also known as subwebs). Some of the terminology is tricky, but if you stay consistent with what STSADM uses, it will be easier to find the command you need.

If you run a large SharePoint installation, you probably spend a lot of time creating new sites for users. I know I find myself repeatedly doing this. Creating new sites can be done quite easily in SharePoint Central Administration. But since I perform this task so often, I find it faster to use STSADM to get the job done.

I use the createsite operation. This is quite simple and takes the following parameters:

url
ownerlogin
owneremail
ownername
lcid
sitetemplate
title
description
quota

You can bring these up at the command prompt by typing stsadm -help createsite (see Figure 2). Of these nine parameters, the only mandatory fields are URL, ownerlogin, and owneremail.

If you have sites that you create on a routine basis, you can go a step further in streamlining the process by writing a wrapper script around STSADM to automate the task. For instance, to automate the creation of personal sites, you can save the following to a text file named createpersonalsite.cmd

stsadm -o createsite -url http://localhost/users/%1 -ownerlogin contoso\%1
-owneremail %1@contoso.com -sitetemplate usersite.stp
-title "Personal site for %1" -description "Personal site for %1" -quota "500 MB"

Figure 2 Createsite Parameters

And then to create a site for the user jsmith, you could simply execute the following:

createpersonalsite.cmd jsmith

By scripting site creation, you save yourself a lot of typing and can make sure all your newly created sites are consistent. The operation createweb provides the same functionality at the web level.

In Windows SharePoint Services 2.0, the only easy way to get an exhaustive list of the site collections on a particular virtual server is to use STSADM. Enumsites lists in XML format all of the site collections on a specific virtual server or Web application. This can be coupled with a Data View Web Part to easily view a list of site collections. (See the sidebar "Working with a Data View Web Part" for more information.)

STSADM provides a deletesite operation for, as you can guess, removing sites. All you need to do is provide the URL. Optionally, you can pass it -deleteadaccounts to have the accounts deleted in Active Directory®. When working with webs you would use the deleteweb operation.

You can also add, delete, and enumerate the users of a site or web. The associated operations are adduser, deleteuser, and enumusers. These operations are handy if users need to be added to a site in bulk, or if you need to maintain a list of users who have access to a site for auditing purposes.

When working with webs you have access to an additional operation, renameweb, that lets you change the name and URL of a web. For example, to rename a web from "oldname" to "coolnewname," use the following:

Stsadm -o renameweb -url http://localhost/oldname -newname coolnewname

This can be a life saver when project names change or business units are realigned. In Windows SharePoint Services 2.0, this is a big issue, as the only way to migrate webs is with SMIGRATE.exe, which does not maintain any user-related settings like membership or alerts. With Windows SharePoint Services 3.0, this is less of an issue, as STSADM can back up and restore webs and sites.

Backing Up and Restoring
One of the best uses for STSADM is backing up and restoring sites and webs. For small to medium-sized installations, this functionality can be the cornerstone of a disaster recovery plan. The backup operation is self-explanatory and very easy to use. Simply tell STSADM which site to back up and where to write the backup file, like this:

Stsadm -o backup -url http://localhost -filename site.bak

This operation dumps the entire site collection to the file site.bak. It includes all site content, such as webs, document versions, lists, and users. It does not back up any site definitions or changes you've made at the file system level of your servers.

While the backup operation is important, it does have a few snags to keep an eye on. If the site is large enough, the Content Database may be locked during the backup process. This may prevent users from accessing any sites in that database until the backup operation is finished. This issue has been mitigated with service packs, but it is still something to keep an eye on as your sites grow. STSADM also uses the server's temp directory when doing backups and restores, so monitor your drive space.

Working with a Data View Web Part

You can couple the enumsites command with a Data View Web Part to create an easy way to view a list of site collections. Let's see how.

First, create a scheduled task that runs:

stsadm –o enumsites –url http://localhost>c:\inetpub\wwwroot\excludedsite\sites.xml

Make sure the XML file is being written out to a directory that is published with IIS, but not managed by SharePoint. Then use Microsoft FrontPage® (or the FrontPage successor, Microsoft Office SharePoint Designer 2007) to add a Data View Web Part to a Web Part page and point it at the URL of the XML file.

The Data View Web Part provides functionality like sorting, filtering, and grouping. You can also make the URL field a link to take you directly to the site. If you would like a list of webs instead, the operation enumsubwebs provides an XML output of the subwebs in a site collection or web

Finally, keep in mind that while STSADM backups work well for small to medium sites, the functionality does not scale particularly well. For very large sites (several gigabytes or more), the backup and restore processes can slow down quite a bit.

Restoring a site is equally simple. STSADM -o restore takes a file created by STSADM -o backup and writes it to a site in SharePoint. You have a lot of flexibility with this command: you can restore a site back to its original location (if, for instance, the site was erroneously deleted), you can restore it as a different site on the same virtual server (perhaps if you want to test a process on a site without the risk of destroying data), or you can restore the site to a completely different server or virtual server.

Restoring to a different site or server makes it a bit easier to do individual document recovery. If you have a site backed up and a user needs a document restored, you do not need to restore the entire site. That would sacrifice all changes made to the site since the backup was stored. Instead, you can just restore the site to a different URL, grab the documents, and save them back to the original site.

In Windows SharePoint Services 2.0, STSADM has one fairly serious limitation. When backing up, it can only deal with sites, not with webs. Administrators made their discontent known and Microsoft responded. In Windows SharePoint Services 3.0, the backup and restore operations can now handle webs. It also adds two new commands: import and export.

To export a web, use the following simple command:

Stsadm -o export -url http://localhost/web -filename backup.dat

Export has handy options, including the -versions switch. This allows you to decide how large your backup files will be by restricting which file versions will be backed up.

To import a web back to the server, use the following command:

Stsadm -o import -url http://localhost/web2 -filename backup.dat

If your site is large enough, the backup file might be in multiple parts. In this case, point STSADM -o import to the first file and it will automatically grab the subsequent files

Expert Operations

Now that you are comfortable with STSADM, I want to show you a couple of operations you can use to get out of a bind. The first is a newly added operation called migrateuser. Version 2.0 does not sync itself with Active Directory. If an account is renamed, it can no longer log in to SharePoint. In the past, there was also no way to migrate user access from one domain user to another. Before Windows SharePoint Services 2.0 Service Pack 2 (SP2), you had to remove the user from every web and manually add the new account.

SP2 introduced a new API and STSADM takes advantage of it. If the account jsmith is renamed to jjones, you can use the following command:

Stsadm -o migrateuser -oldlogin domain\jsmith -newlogin domain\jjones -ignoresidhistory

Since you're not actually migrating accounts, you can ignore Windows security ID (SID) history. Note that this command does not require a URL. It makes the change throughout the content databases, without regard to sites or webs.

Another operation that can get you out of a bind is unextendvs. If you do not want SharePoint to render a virtual server or Web application, you unextend it. Normally, you would do this from the SharePoint Configuration Analyzer. However, in a Web farm, SharePoint Configuration Analyzer requires that your servers are all at the same patch level. It is possible for a server to be out of sync with the rest of the farm and, therefore, it will not get the unextend option in SharePoint Configuration Analyzer. Using STSADM, though, the following command will unextend your virtual server:

Stsadm -o unextendvs -url http://localhost

Once the server is no longer in the Web farm, you can perform the maintenance you need.

On the subject of Web farms, for ease of administration, you may want all of your servers to have SharePoint Configuration Analyzer on the same port. The port is randomly generated when SharePoint is installed, but STSADM includes an operation to change the port to one you specify:

Stsadm -o setadminport -port 1026

This makes all the necessary database changes, it makes the IIS changes, and it adjusts the shortcut to SharePoint Configuration Analyzer in Administrative Tools.

Windows SharePoint Services is a powerful solution and it requires powerful administration. STSADM provides a way to accomplish SharePoint administration, including the automation of configuration and common day-to-day tasks. In fact, sometimes it is the only way to get the job done.

SharePoint impersonation: Id and Ego

2008-05-14T02:38:00.000-07:00

Description:
We probably should have called the title of this article ‘SharePoint and impersonation’ or some other rather predictable title like that, because that’s the topic of this article. But there’s no fun in that, so instead we decided to call it ‘Id, Ego and Superego’, concepts which are borrowed from the famous psychologist Sigmund Freud and applied very loosely to SharePoint.

Freud used the terms Id, Ego and Superego to describe the human character. The ‘Id’ (pronounced as ‘it’) describes the lower, more animalistic parts of our character. The ‘Ego’ part of the human character describes the way most of us act in everyday life, the Ego part is a compromise between needs, lust, morals and realism. Finally, the ‘Superego’ represents higher values, ethics and morale. Maybe you could say that the Superego is what most of us would like to be like.

Sometimes when creating web parts you might want to do things which ordinary users are not allowed to, for instance, when you want to use the SharePoint administration object model to display information about SharePoint. If you’re feeling lucky you could solve the problem by making everybody administrator but chances are you won’t be nominated to win the Microsoft Trustworthy computing award this year – again.

Another solution would be to change the identity to an account with more privileges during the web part life cycle, do the stuff which demand additional privileges, and change the identity back again to the original context. In this article we will show you three different approaches to impersonation and we’ll use the concepts of Id, Ego and Superego to give those approaches a name.

SharePoint OM code sample requiring administrator privileges

To be able to demonstrate that the impersonation code actually works you’ll need to create an account with Reader rights for SharePoint. We use a small code sample which uses the SharePoint object model to display the URL and server id of the current virtual server. You need to be an administrator to be able to do this. If you create a web part you could override the RenderWebPart method like this:

protected override void RenderWebPart(HtmlTextWriter output)

{

string strValue = String.Empty;

try

{

SPSite objSite = SPControl.GetContextSite(Context);

SPGlobalAdmin objAdmin = new SPGlobalAdmin();

SPVirtualServer objServer = objAdmin.OpenVirtualServer(new Uri(objSite.Url));

objServer.CatchAccessDeniedException = false;

strValue += "url: " + objServer.Url + " virtual server id: " + objServer.VirtualServerId;

}

catch (Exception err)

{

strValue = "Error in wp: " + err.Message;

}

output.Write(strValue);

}

The code itself is unimportant, the only thing that is important is that it requires administrator privileges. This makes it an excellent test to see if the impersonation works. By the way, the CatchAccessDeniedException property of the SPSite object is used to specify that access denied errors aren’t handled which prevents authentication dialog boxes from popping up.

If you open a browser by rightclicking it, choosing the ‘Run as’ option and log in with a previously created reader account you’ll see that access will be denied (and if you didn’t set the CatchAccessDeniedException to false you will have plenty of opportunity to notice this).

Policy files

If you want to be able to execute all code samples it’s easiest if you set the trust level in the SharePoint web.config file to ‘Full’, like so:

We like to work with our own custom policy files. If you’re using custom policy files as well and if you want to be able to execute the ‘Id’ and ‘Ego’ approaches make sure the following permissions are present in your policy file:

class="AspNetHostingPermission"

version="1"

Level="Minimal"

version="1"

Unrestricted="true"/>

class="SecurityPermission"

version="1"

Flags="Execution,UnmanagedCode,ControlPrincipal,ControlAppDomain,

ControlEvidence"

version="1"

Connections="True"

version="1"

ObjectModel="True"

UnsafeSaveOnGet="True"

As for the Superego approach, as it turned out, to be able to execute this scenario we found we needed so much permissions that we chose the easy route and used full trust instead.

Ego

In this approach we’ll use a Win32 API call to the LogonUser function to impersonate another user account. The first thing you need to do is import two dll’s, advapi.dll and kernel32.dll. To do this add the following code to your web part class:

[DllImport("advapi32.dll", SetLastError=true)]

static extern bool LogonUser(

string principal,

string authority,

string password,

LogonTypes logonType,

LogonProviders logonProvider,

out IntPtr token);

[DllImport("kernel32.dll", SetLastError=true)]

static extern bool CloseHandle(IntPtr handle);

Advapi32.dll contains the LogonUser function which attempts to log on a user to a local computer. The most important arguments which need to be passed to this function are a username, domain and password. The function returns a boolean value indicating if the logon was successful. A handle is passed (by reference), the handle is very important because it can be used to create a new windows identity.

After that you’ll also need a couple of enumerations which can be used as arguments for the LogonUser function as well. Add the following code to your web part class:

enum LogonTypes : uint

{

Interactive = 2,

Network,

Batch,

Service,

NetworkCleartext = 8,

NewCredentials

}

enum LogonProviders : uint

{

Default = 0, // default for platform (use this!)

WinNT35, // sends smoke signals to authority

WinNT40, // uses NTLM

WinNT50 // negotiates Kerb or NTLM

}

By the way, it’s better to use the Network logon type instead of the Interactive type because of performance reasons and the elimination of the call to DuplicateToken (MS KB article 306158, see http://support.microsoft.com/?kbid=306158 ).

Kernel32.dll contains the CloseHandle function which closes an open object handle. This function is used to close the handle which was the result of the LogonUser call.

The following code shows how to override the RenderWebPart method to impersonate users via the LogonUser API call:

protected override void RenderWebPart(HtmlTextWriter output)

{

string strValue = String.Empty;

try

{

WindowsImpersonationContext objUserContext;

IntPtr objToken;

WindowsIdentity objOrgIdentity;

WindowsIdentity objIdentity;

bool blnReturn = LogonUser(@"myadministrator", "mydomain", "myadminpassword",

LogonTypes.Interactive,

LogonProviders.Default,

out objToken);

if ( blnReturn )

{

objOrgIdentity = WindowsIdentity.GetCurrent();

objIdentity = new WindowsIdentity(objToken);

objUserContext = objIdentity.Impersonate();

SPSite objSite = SPControl.GetContextSite(Context);

SPGlobalAdmin objAdmin = new SPGlobalAdmin();

SPVirtualServer objServer = objAdmin.OpenVirtualServer(new

Uri(objSite.Url));

objServer.CatchAccessDeniedException = false;

strValue += "url: " + objServer.Url + " virtual server id: " +

objServer.VirtualServerId + "

";

strValue += "Identity name after impersonation: " + " " +

objIdentity.Name + "
";

objUserContext.Undo();

strValue += "Indentity name when impersonation is undone: " +

objOrgIdentity.Name;

CloseHandle(objToken);

}

else

{

strValue = "Logon failed!";

}

catch (Exception err)

{

strValue = "Error in wp: " + err.Message;

}

output.Write(strValue);

}

So, to sum up, this is the Ego approach, where the current user context is replaced with a new context.

One of the complaints we hear about the Ego approach is that user credentials are stored in the code which is, and rightfully so, considered unsafe. Well, you shouldn’t store passwords in plain text in code, it’s as simple as that, but there are ways to avoid this. You could save the password in a config file after encrypting it using DPAPI. Another nice solution would be to use SharePoint Single Sign On (SSO) and store the credentials in the credential mapping database.

There is another solution, using credential-less impersonation, which we’ve named the ‘Id’ approach. This approach is explained in detail in a very informative article called ‘Secure SharePoint Code Using Credential-less Impersonation’ by Todd Bleeker ( http://sharepointadvisor.com/doc/16238 ).

Basically, a call is made to the Win32 API RevertToSelf function which terminates the impersonation of a client application. SharePoint uses Internet Information Server 6 (IIS) and IIS 6 uses application pool identities as the context in which worker processes run. It’s possible to revert back from a current user context (which is itself an impersonated identity) to the original identity, which is the application pool identity.

The credentials of the application pool identity are stored safely in the IIS metabase. SharePoint requires the application pool identity to be a local administrator and administrator of the SharePoint content database. So, by dumping the current context and reverting to the application pool’s security context it’s possible to do stuff that requires an extensive set of privileges while avoiding storing credentials in code.

To make this possible you’ll need to import the Advapi32.dll. Add the following code to your web part class definition:

[DllImport("advapi32.dll")]

static extern bool RevertToSelf();

As you can see, the RevertToSelf function isn’t hard to use. The following code shows how to override the RenderWebPart method to revert back to the application pool’s security context:

protected override void RenderWebPart(HtmlTextWriter output)

{

string strValue = String.Empty;

try

{

WindowsIdentity objOriginalUser = WindowsIdentity.GetCurrent();

RevertToSelf();

SPSite objSite = SPControl.GetContextSite(Context);

SPGlobalAdmin objAdmin = new SPGlobalAdmin();

SPVirtualServer objServer = objAdmin.OpenVirtualServer(new

Uri(objSite.Url));

objServer.CatchAccessDeniedException = false;

strValue += "url: " + objServer.Url + " virtual server id: " +

objServer.VirtualServerId + "

";

strValue += "application pool identity name: " +

WindowsIdentity.GetCurrent().Name + "
";

WindowsImpersonationContext objContext =

objOriginalUser.Impersonate();

strValue += "original user name: " +

WindowsIdentity.GetCurrent().Name;

}

catch (Exception err)

{

strValue = "Error in wp: " + err.Message;

}

output.Write(strValue);

}

In the Id approach the current user context is reverted back to the underlying original security context. The big difference with the Ego approach is you don’t need to find a way or place to store credentials of a superuser. Also check out the following link: http://mindsharpblogs.com/todd/archive/2005/05/03/467.aspx , this small article explains a way to do impersonation code in a way that requires a smaller set of security privileges.

MOSS2007 - Content Types

2008-05-11T23:16:00.001-07:00

So as most of you are probably aware now, or maybe not, MOSS2007 now has a concept of what’s called Content Types. Content Types are a way of storing multiple documents in a document library each with their own metadata and behaviours. In SPS2003 and WSSv2 one of the limitations was Metadata. If you wanted different Metadata for each document you would have to create separate document libraries to handle this. Also unless you wrote quite a complex event handler or used a 3^rd Party workflow solution any behaviours you needed to happen based on document types would fire for all documents as there was no way of distinguishing content. So now in MOSS007 this has been changed.

What does a Content Type comprise of?

A Content Type is basically, Metadata Columns and behaviours logically grouped under one name. In the MOSS2007 the Metadata columns are referred to as “Site Columns”.

How do you create a Content Type?

As Content Types can be used on multiple Document Libraries over many Team Sites, they need to be created at the highest level within the MOSS2007 system. The following are the steps needed to create and use a Content Type:

1. Create Site Columns

2. Create Site Content Type

3. Add Site Columns to Content Type

4. Specify any Templates to use for Content Type

5. Associate the Content Types with a Document Library

Select the “Site Settings” and then “Modify All Site Settings” from the Portal home page. Before we can actually add the “Content Type” you need to add the relevant “Site Columns” you wish to use. To do this select the “Site Columns” option from within the “Galleries” section.

The “Site Column Gallery” lists all the Site Columns that are available throughout the MOSS2007 System. They are logically grouped. To create some new columns simply press the “Create” button. Much like SPS2003 you will need to specify the type of Column it will be.

For our example it will be a choice menu. Fill in the details as below:

Once you have added the “Approved Status” column we will create a second called “Sent To Customer”.

Now that we have created two “Site Columns” they should appear in the main “Site Column” listing grouped by the heading “Demonstration Sites Columns”.

Now we have the relevant “Site Columns” Content Types can now be created. To create a Content Types simply select the “Site Content Types” option from the “Galleries” section within the “Site Settings” section of the Portal:
When creating a Content Type you need to specify what base content type this will inherit from. In our case we will chose the “Document Content Types”, and then select the “Document” as the Parent Content Type.

We will also create a new “Content Types” Group so we can logically find them later. This is a nice feature, if we had a large system we may have 100’s of different types. Without the grouping option I could take a while to find the ones we are after. So now we have a single content type. To complete the configuration we still need to complete the following:

1. Add Site Columns to Content Type

2. Specify any Templates to use for Content Type

3. Associate the Content Types with a Document Library

Add Site Columns to Content Type

From the Site Content Type screen for “Demonstration Expenses” select the “Add from Existing Site Columns” option.

Select the “Demonstration Site Columns” group and then select the relevant site column to associate with the Content Type.

The site column should now appear in the columns section of the document library Administration page.

Specify any Templates to use for Content Type

From the Settings section select the “Advanced Settings” and choose to upload a new template. In this case will choose an InfoPath form.

Now follow the steps as before to create the “Demonstration Sales Proposal” Content Type with the following settings.

Associate the Content Types with a Document Library

Create a new Document Library.

Notice when you click the “New” arrow in the document library that is gives the standard options of creating a document based on the Document Template chosen when you created the document library.

To associate the Content Types select the Site Settings option and then “Document Library Settings”.

At this moment in time our document library is not enabled for Content Types. You can see this by looking at the page and NO content type section appears.
To enable Content Types select the “Advanced Settings” option and select the “Allow Management of Content Types” checkbox and apply this.

When you return to the administration screen a new Content Types section will appear.

Select the ”Add from existing site content types”. And then select the “Demonstration Content Types Group” and select both the “Demonstration Expenses” and “Demonstration Sales Proposal” Content Types.
Upon returning to the Administration screen you will now see these listed in the Content Types section along with the default document content type. For our purposes we do not need this default one as we only want to accept our custom content types. To remove a content type association to a document library simply select the content type you wish to delete and then select the “Delete this Content Type” from the settings section.

Now we should only have our two custom content types listed.
So from a user perspective what does it look like now. To see this go into the document library and select the “New” arrow and you should be presented with a new list of templates you can work with.

When you click the “Demonstration Expenses” an InfoPath form should now launch.

Upon selecting the “Demonstration Sales Proposal” a word template should then launch.
I have filled in a copy of each of the template and saved them in the document library like so:

Upon first glance it just looks like SPS2003. Multiple documents in one document library. Also the Metadata does not seem to be there that I chose for the Content Type. In MOSS2007 if you are using Content Types you will not see the Metadata in the “All Items” Views. To access the Metadata simply select the “Edit Properties” option from the document menu.

Notice our custom Metadata appears for that document. Most importantly however in the Content Type option that can be changed. This enables your users to change Content Types if it is more relevant to another one you may have.
If we decide that this one here should be a “Demonstration Sales Proposal” we simply change this but notice what happens to the “Approved Status” field.

It now changes to match the “Site Columns” that are associated with the Content Type. In this example we only have one Site Columns but in the real world you may have many.

So to review:

What are Content Types? What are they used for?

Content Types are a way of logically assigning Metadata and Behaviours to Content Types instead of just a document library. It gives you the flexibility to have a more “free” structured taxonomy and just control the data itself by the content that it is.

Well hopefully this has been useful. I am very excited about this functionality as it now brings a lot more reasons to use MOSS2007 to the table.

Search Features in Office SharePoint Server

2008-05-05T08:59:00.000-07:00

Search Features in Office SharePoint Server
Search in Office SharePoint Server unlocks unstructured and structured information and enables users to find people and expertise. Enterprise Search features are optimized to let people in the organization quickly connect with the information they need, helping users more quickly identify the results that are relevant to them and helping administrators to manage, deploy, and secure the search infrastructure.
Search in Microsoft Office SharePoint Server — Version Comparison
The following table describes new or expanded search capabilities, and differences between Office SharePoint Server 2007 and Office SharePoint Portal Server 2003. The rest of this guide provides more-detailed information about new and enhanced searching capabilities in Office SharePoint Server 2007.

Search User Experience
Searching with Office SharePoint Server 2007 provides benefits for end users and IT professionals administering the system. Office SharePoint Server 2007 and Windows SharePoint Services now share a common implementation of Microsoft Search, providing a more-consistent and more-efficient user experience. The new browser-based Search Center interface is simple, flexible, and highly customizable. It ships with Search tabs that allow users to search across different types of data. Additional tabs can be added easily to the Search Center to create a targeted search experience.
New or enhanced user interface features include keyword search, highlighting of search terms, “Did you mean” spelling suggestions, duplicates collapsing, and definition extraction. These enhancements help users quickly identify the results that are relevant to them. The new capability to subscribe to an RSS feed or sign up for search alerts helps users stay updated with the information they care about without constantly needing to search for the same information again and again.

For More Information
Visit the Office Online Products Home Page (http://go.microsoft.com/fwlink/?LinkID=78509&clcid=0x409). This Web site features the latest news and information about the Microsoft Office 2007 system, including product information, case studies, white papers, information about related technologies, and more.
See also:
· Office SharePoint Server home page on Office Online (http://go.microsoft.com/fwlink/?LinkId=80123&clcid=0x409)
· Office SharePoint Server for Search home page on Office Online (http://go.microsoft.com/fwlink/?LinkId=80124&clcid=0x409)
· Searching in Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkId=80127&clcid=0x409)
· Office SharePoint Server TechCenter (http://go.microsoft.com/fwlink/?LinkId=80125&clcid=0x409)
· Office SharePoint Server for Search TechCenter (http://go.microsoft.com/fwlink/?LinkId=80126&clcid=0x409)
· Office SharePoint Server ELearning (http://go.microsoft.com/fwlink/?LinkId=80128&clcid=0x409)

Son Of SmartPart version 1.0.0.0

2008-05-05T08:58:00.001-07:00

Installation Guide
• Step 1: WSS SP2
Install Windows SharePoint Services Service Pack 2, and make sure your SharePoint site(s) are running version 2.0 of the .NET Framework.
• Step 2: Copy the DWP files
Extract the contents of SonOfSmartPart_1_0_0_0.zip to a temporary folder. Copy all the files with the extension DWP to the WPCATALOG folder of your SharePoint site.
• Step 3: Deploy SonOfSmartPart.dll to the GAC
Navigate to C:\WINDOWS\Assembly (which is the Global Assembly Cache) and drag-and-drop the file SonOfSmartPart.dll from the temporary folder. Alternatively you can use the GacUtil command line tool to deploy the file.
• Step 4: Modify the Web.Config
Open the Web.Config file of your SharePoint site. Look for the SafeControls section and add the following line:

• Step 5: Modify the Web.Config (bis)
Open the Web.Config file of your SharePoint site. Look for the compilation node and replace the compilation node to the following:

• Step 6: Create the UserControls folder
Create a folder named “UserControls” in the folder that is mapped to your SharePoint site (same level as the WPCATALOG folder).

How SharePoint Works

2008-05-04T22:47:00.000-07:00

How SharePoint Works

A Technical Whitepaper for Software Developers and System Architects
Written by Ted Pattison

Over the last few years, Microsoft has made a significant investment in collaborative technologies, Windows SharePoint Services and SharePoint Portal Server are two flagship products positioned to dominate this space. This whitepaper is written to introduce SharePoint’s fundamental architecture and to discuss the opportunities that SharePoint provides to you as a software developer using the .NET Framework.
Windows SharePoint Services (WSS) is a free product that runs on the Windows Server 2003 operating system. WSS supplies a framework for building collaborative Web sites which make it possible for a company to share information and documents across the members of teams, departments and large organizations with unprecedented levels of ease and reliability. Any user can access a WSS Web site using a Web browser or through the new collaboration features built into Microsoft Office 2003 products such as Word and Excel.
WSS also provides the underlying infrastructure for generating user interfaces through the inclusion of Smart Page and Web Part technology. Smart Pages and Web Parts are a very powerful aspect of SharePoint because each WSS site provides a browser-based user interface that is extensible and fully customizable. Web Parts can also be used to store personalization information on a user-by-user basis. We will discuss Web Parts in greater detail later at the end of this whitepaper.
SharePoint Portal Server 2003 (SPS) is a product for building enterprise-level portal sites that is part of the Microsoft Office 2003 System. It is important to note that SPS is built on top of WSS. SPS compliments WSS by adding manageability features designed to assist users navigating through vast amounts of information and documents. SPS also supplies additional functionality to enhance portal sites using indexing, searching, audience targeting and single sign-on.
There is a fundamental difference in the roles played by WSS and SPS. These differences are shown in the table in figure 1. WSS is based on a collaboration theme in the sense that it’s designed to store and share list-based data and documents. SPS, on the other hand, is based on an aggregation theme. An SPS portal site is useful for aggregating information and documents from many different places. SPS adds value by providing users with a quick and easy way to find information and documents that are spread out around a private network or scattered throughout the Internet.

In essence, WSS gives you a place to put all your content while SPS provides the means to navigate and search through your content when you need it. These two roles are quite complimentary to one another. WSS allows an enterprise-level company to create and maintain tens of 1,000s of collaborative Web sites, while one or more SPS portal sites allows users to search through all this content and find what they're looking for.
You should understand that SPS depends upon WSS to provide many essential services. For example, WSS provides SPS with the capacity to track members and share lists and documents. Furthermore, SPS doesn’t supply any code for generating the user interface for a portal site. Instead, SPS leverages the WSS Smart Page and Web Part infrastructure to construct the user-interface for an SPS portal site.
Windows SharePoint Services Architecture
WSS is a free product to any individual or company that has purchased the Windows Server 2003 operating system. The WSS installation files can be downloaded using the Windows Update service or from the following URL:
http://www.microsoft.com/windowsserver2003/technologies/sharepoint/default.mspx.
The WSS framework is built on top of Windows Server 2003, IIS6 and ASP.NET. Figure 2 shows how the fundamental pieces of the WSS framework fit together. Note that before you can successfully install WSS on Windows Server 2003, you must first configure the host computer as an Application Server by enabling IIS6 and ASP.NET 1.1.

Learning about WSS is easier once you know a few facts about its history. WSS is part of the second generation of SharePoint products and technologies. The first generation was built on an earlier IIS-based framework named SharePoint Team Services (STS). The STS framework is similar to WSS in that it provides a collaborative framework for sharing list-based data and documents. However, STS was not built upon on the .NET Framework or ASP.NET. Instead, it was built using a proprietary ISAPI extension.
Customizing and extending STS Web sites has always been relatively difficult due to limited tool support. Site customization is much easier with WSS and the second generation of SharePoint because of WSS-compatible Web designers such as Microsoft Office FrontPage 2003. WSS also offers a much better extensibility model because you can write custom applications and Web Parts for WSS sites and SPS portal sites with Visual Studio .NET using either C# or Visual Basic .NET.
STS and the first generation of SharePoint products and technologies have also suffered from scalability problems. The scaling limitations of STS are due to an underlying architecture that runs a stateful design on front-end Web servers. This flaw makes it impossible to scale out STS Web sites using a Web Farm environment. When Microsoft engineers started to design WSS and the second generation of SharePoint products and technologies, they made it a primary design goal to fix the scaling problems of STS. Consequently, they designed their architecture to support WSS and SPS deployments with tens of 1000s of users and tens of 1000s of Web sites.
WSS architecture is based on stateless front-end Web servers. Their architecture is founded on an integrated storage strategy where all the list-based data and documents associated with a Web site are stored within a SQL Server database as shown in figure 3. A key objective of this integrated storage strategy is that it allows a deployment of WSS Web servers to effectively scale out in a Web farm environment.

WSS relies on two different kinds of SQL Server databases; configuration databases and content databases. As you might suspect, the configuration database holds deployment-specific configuration information for each physical Web server, IIS virtual server and WSS Web site. Content databases, on the other hand, hold data associated with WSS Web sites.
WSS requires exactly one configuration database for each deployment of WSS Web servers. A simple deployment can involve a single host computer running both the WSS front-end Web server components and SQL Server with the configuration database and a single content database. A more scalable WSS deployment involves a Web farm scenario with multiple front-end Web servers. A WSS deployment can also involve multiple back-end database servers. For example, in certain deployments it can offer scaling advantages to spread several content databases across multiple host computers running SQL Server. However, there is only one configuration database for each WSS deployment. The configuration database provides a central repository of information to coordinate all font-end servers and back-end servers.
Each content database stores the data for one or more WSS Web sites. WSS data that is stored on a site-by-site basis includes lists and documents as well as all information pertaining to site customization and personalization. This integrated storage strategy provides a definite improvement over STS where site-specific data was stored in the file system and in the registry in addition to the database. The fact that everything pertaining to a site is stored within a single SQL Server database makes it much significantly easier to backup and restore Web sites under WSS.
The ability to spread the content for different Web sites across multiple backend database servers provides a valuable scaling feature. For example, imagine your company’s marketing department needs several gigabytes of storage and lots of processing cycles because they are constantly storing and retrieving really large graphics files. You can create a WSS Web site for the marketing department which stores its content in a separate content database running on a dedicated host computer running SQL Server. You could then create a WSS Web site for your company's sales department that stores its content within this same content database, or you could store it in a different content database running on a separate database server. The purpose of content databases is to provide a point of scalability and management.
If you’re just getting started with WSS, you can install everything you need on a single computer running Windows Server 2003. Once you have installed Windows Server 2003, configure the computer as an Application Server by enabling IIS6 and ASP.NET 1.1. When you configure IIS and ASP.NET, be certain not to install the FrontPage Server Extensions because they are incompatible with WSS. After that you can install WSS by running the installation program STSV2.EXE.
For single-machine deployments, WSS doesn't require you to use the full-blown version of SQL Server. The WSS installation program can optionally install a special version of MSDE called Windows MSDE (WMSDE). WMSDE is unlike the standard version of MSDE because it doesn’t limit you to 2 GB of storage and 10 database connections. However, WMSDE is more restrictive than MSDE because it only supports table schemas signed by Microsoft. This means you cannot use WMSDE to create your own custom databases and tables.
If you would like to install SPS on a development workstation, the installation process is more complicated. First of all, there are several SPS features that require Active Directory. Therefore, you should prefer to install SPS on servers that are part of an Active Directory domain. Before installing SPS on a host computer running the Windows Server 2003 operating system, first add that machine to an existing Active Directory domain or configure it to be a domain controller. Once the Windows Server 2003 computer is in a domain, next configure it to be an Application Server by enabling IIS6 and ASP.NET 1.1. With SPS, we also recommend that you install SQL Server instead of relying on WMSDE to store the database for portal sites.
Once you have prepared a Windows Server 2003 computer with IIS6, ASP.NET 1.1 and SQL Server and added it to an Active Directory domain, you are ready to run the SharePoint Portal Server 2003 installation. The first thing the SPS installation program does is to install its own specialized version of WSS. The version of WSS used by SPS is required to add extra tables to the configuration database and to each content database that holds an SPS portal site. After the SPS installation program copies the required files to the host computer, it displays a wizard that steps you through the process of creating the configuration database and creating the initial portal site. In addition to adding extra tables to the configuration database and content database, the installation of SPS also creates a few other databases to track data for features such as search and audience targeting.
Before installing either WSS or SPS in a deployment with SQL Server (as opposed to WMSDE), you might be required to add a SQL Login for the Windows account that serves as the identity for the IIS Application Pools used by SharePoint. By default, WSS and SPS configure IIS Application Pools to run under the identity of the NT AUTHORITY\NETWORK SERVICE account. If you don't like this default setting, you can reconfigure any IIS Application pool to use a different Windows account. Whatever Windows account you use, however, needs a SQL login to log on to SQL Server.
Once you have added the a SQL login for the appropriate account within SQL Server, next you must add the account into the Server Roles of Security Administrators and Database Creators. If you don’t follow these steps, you will experience errors when installing or configuring either WSS or SPS. That’s because WSS and SPS by default use IIS application pools that run under the identity of the NT AUTHORITY\NETWORK SERVICE account which has no permissions to log onto SQL Server. You must configure SQL Server to grant this account the permissions to create databases and configure their security settings.
IIS Web Sites and Virtual Servers
WSS Web site configuration starts at the level of the IIS Web Site. A default installation of IIS creates an IIS Web Site named Default Web Site that is configured to listen for incoming HTTP requests across port 80. You can use the IIS Administrative tools to create additional IIS Web sites that listen for incoming HTTP requests on a different port or with a different host header. Figure 4 shows an example of an IIS Web server computer with two virtual servers configured for end-user access.

Note that the installation of WSS adds its own special IIS Web Site named SharePoint Central Administration. WSS uses this IIS Web site to run the SharePoint Central Administration HTML pages. The SharePoint Central Administration Web site is configured on a random port number during installation so that it is less likely to be accessed by an intruder.
In SharePoint terminology, an IIS Web Site is known as a virtual server. A virtual server must be extended with WSS in order to run WSS Web sites. When you install WSS with the default settings, it automatically extends the virtual server that is listening on port 80. You can extend WSS onto another virtual server by using the SharePoint Central Administration HTML pages or by using a WSS command-line administration tool named STSADM.EXE.
WSS is unlike ASP.NET in that it doesn't configure each Web site using an IIS virtual directory. Instead, WSS tracks all configuration information for WSS Web sites inside the configuration database and content databases. This means that once WSS has extended a virtual server and you start creating WSS Web sites that they will not appear in the IIS metabase. Instead an entry will be created in the configuration database and appropriate content database. In reality, IIS doesn't know whether a WSS-extended virtual server contains a single WSS Web site or 10,000 WSS Web sites. The fact that WSS doesn't need to configure an IIS virtual directory for each new WSS Web site offers benefits in scalability and improved maintenance.
When WSS extends itself onto a virtual server, it installs a custom ISAPI filter called the WSS filter (STSFLTR.DLL). The WSS filter intercepts each request routed to that virtual server and determines whether the request should be handled by WSS or IIS. To make this determination the WSS filter inspects the URL of the incoming request and consults the configuration database to determine who should process it. Keep in mind you may have a virtual server in which you plan to run WSS sites as well as other ASP and/or ASP.NET applications.
When WSS extends itself onto a virtual server, it adds a web.config file to the root directory of the hosting virtual server. This web.config file provides initial configuration settings for WSS and for all ASP.NET code that runs from inside that virtual server. By default, this web.config file contains fairly restrictive security settings. You will be required to modify sections of this web.config file when you want your code to run with elevated permissions or when you want to test or deploy a new custom Web Part.
In SharePoint terminology, an URL space is the set of all possible URLs that target a virtual server. WSS divides the URL space of an extended virtual server into managed paths. Paths that are managed by WSS are considered included paths while those that are not managed by WSS are considered excluded paths. When the WSS filter sees a incoming request with an URL that part of an excluded path, it knows to route the request back to IIS for standard ASP and/or ASP.NET processing.
What should you do when you want to host a standard ASP.NET within a virtual server that has been extended with WSS? For example, imagine you want to deploy as ASP.NET Web application at http://AcmeServer/webapp1 so that it's available alongside WSS sites in the same virtual directory. At this point you will need to understand and know how to configure included paths and excluded paths. In particular, you need to add an excluded path for the URL space used by the ASP.NET Web application. Figure 5 shows a screen shot of the user interface provided by the SharePoint Central Administration HTML pages for defining managed paths.

Take note that the screen capture in figure 5 shows the virtual server’s included path as well as its excluded paths. Some included paths such as \sites are defined as wildcard inclusions. The purpose of a wildcard inclusion is make URL parsing more efficient. WSS doesn’t allow the nesting of excluded paths within the URL space of a wildcard inclusion. Once the WSS filter sees the first part of the URL for an incoming request matches a wildcard inclusion such as http://AcmeServer/sites, it knows that the request should be directed to WSS for processing.
When the WSS filter determines the URL of an incoming request is inside an included path, it consults the configuration database to locate the target WSS site. WSS tracks each of its sites in the configuration database using the site's URL and an identifying GUID. There is additional information in the configuration database linking each site to a target content database.
Within a WSS deployment, it is often useful to extend more than one virtual server. The reason you might want to do this has to do with flexibility. Each virtual server can be configured using an IIS Application Pool to run its WSS Web sites in an isolated process. IIS also makes it possible to configure the security authentication requirements differently for each virtual server. One virtual server can be configured to require Basic Authentication while a second virtual server can be configured to require Integrated Windows authentication.
In some deployments, every WSS-extended virtual server will have its own separate content database. However, it's also possible to extend a virtual server so that it attaches to the same content database used by another virtual server. This allows a pair of virtual servers to provide two different access points to a common set of WSS sites. This is valuable because the security settings for each virtual server can be configured independently. For example, a virtual server used to provide public-facing Web sites to users on the Internet is typically configured to require SSL and Basic Authentication. A second virtual server providing access to users behind a corporate firewall can be configured to require Integrated Windows Authentication.
Site Collections, Sites and Workspaces
Within a virtual server, WSS sites are partitioned using site collections. A site collection is a set of one or more sites that constitutes a unit of ownership. Creating a new site collection requires you to supply a Windows login account and an email address for its owner. WSS tracks information about site collection owners so it can grant them administrative permissions and send them email notifications regarding site collection maintenance issues.
A site collection always includes a top-level site that has the same URL as the site collection itself. When you create a new site collection, the top-level site is created automatically. In addition to its top-level site, a site collection can optionally contain other secondary sites that are related to the top-level site through parent-child relationships as shown in figure 6. Every site must be created within a specific site collection and all the sites in the same site collection are stored in the same content database.

The site collection serves as a unit of backup and restore in WSS. The STSADM.EXE administrative tool provides easy-to-use commands for backing up and restoring a site collection. After backing up a site collection, you can later restore it on the same Web server or on a different Web server. You will find that WSS makes it far more difficult to back up and restore individual sites that exist within a site collection below the top-level site. If you are creating a site that you would like to backup and restore independently, you should create the site as a top-level site within a new site collection.
When performing day-to-day maintenance in a large WSS deployment with 100s or 1000s of site collections, it is not necessary to backup site collections individually. Instead, you can perform backups at the level of the content database. Backing up content databases will be easy for many companies because they can use the same maintenance procedures that they use to backup other SQL Server databases.
Now let's take a step back and ask a fundamental question; what is a WSS site?
First, a site is a container for storing content. Site contents are primarily stored in the form of lists, document libraries and child sites.
Secondly, a site is a securable entity whose content is accessible to a configurable set of users. A site can either define its own set of users or it can inherits the users of its parent site. Each site user maps to a Windows account defined within an Active Directory domain or a local Windows security accounts database. A site also contains a configurable set of groups and permissions that define the level of accessibility that various users have on the site's lists and document libraries.
Third, a site is a Web application with an extensible, fully-customizable user interface. A site owner or Web designer can customize the layout and appearance of a site's pages and modify the site's navigation structure using either the browser or Microsoft Office FrontPage 2003.
Finally, a site is the foundation for using Microsoft's Smart Page and Web Part technology. Site owners and Web designers can customize Smart Pages by adding and configuring shared Web Parts. A user can further personalize a Smart Page by modifying, adding and/or removing Web Parts. All the customization data and personalization data associated with the Web Parts on a Smart Page are automatically stored in the content database.
WSS supports a specialized type of site called a workspace. Technically speaking, a workspace is really just a standard WSS site. However, the purpose of a workspace is more narrowly defined than other types of WSS sites. Let's look at a simple example to illustrate this point. A Team Site is not a workspace because it typically contains several different lists, document libraries and child sites. A workspace, on the other hand, focuses on a single item. A document workspace is used to collaborate on a single document or document library. A meeting workspace is used to collaborate before, during and after a single meeting.
Every site is initially created from a site template. A site template is a blue print that defines an initial set of lists, document libraries, Smart Pages and Web Parts that exist within a new site. WSS ships with eight site templates including Team Site, Blank Site, Document Workspace, Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace and Multipage Meeting Workspace. When a site is first accessed after being created, WSS prompts the user to select one of the available site templates using the HTML page shown in figure 7.
Figure 7:Each site is created based on a site template
WSS supports the creation and use of custom site templates. You can customize a site to your heart's content with Microsoft Office FrontPage 2003 and then save the site as a site template. Saving a site as a site template is accomplished with a few clicks in the browser. Once the custom site template has been created, it is then available for creating new sites within the same site collection. With some additional effort, a custom site template can be exported to other site collections and can also be used to create top-level sites.
SPS Architecture
SPS builds on top of the architectural layer provided by WSS. When you create a new SPS portal site, you are really creating a new physical WSS site collection. However, there are a few noteworthy restrictions about how SPS uses WSS. There can be only one portal site per virtual server. Furthermore, the site collection containing a portal site must always be created at the root URL of the hosting virtual server.
Once you have created a portal site at the root of a virtual server, you can then create additional standard WSS site collections within the same virtual server. If fact, that's exactly what SPS does when you execute the Create Site command from a portal site. That is, SPS creates a top-level site within a new site collection. When a portal site user creates a personal site by clicking the "My Site" link, SPS also creates this personal site as a top-level site within a new site collection. This strategy makes it easier to backup and restore shared sites and personal sites within an SPS deployment.
SPS extends the way in which WSS stores content by introducing areas and listings. Remember that SPS is a product designed around the theme of aggregation. Areas and listings are used by portal site content managers to aggregate content from other places. An area is a container of listings and nested subareas. Occasionally, a listing will contain HTML-based text. More often, a listening contains a link to non-portal content such as a document, Web page or WSS list across the network. The key point is that listings allow SPS to link users to non-portal content such as shared folders, Exchange public folders, WSS sites, public Web sites and Lotus Notes as shown in figure 8.
Figure 8: SPS provides Areas and Listing to aggregate information from around the network.
The areas within a portal site are structured in a hierarchy of parent-child relationships. Figure 9 shows a screen shot of the HTML-based interface that SPS provides for working with areas. This user interface makes it relatively simple for portal site content managers to add and delete areas and listings from within the areas hierarchy of a portal site. SPS also makes it simple using the browser to relocate an area or listing to a new location within the areas hierarchy.
Figure 9: Areas make it easy for users to navigate and search through content.
Areas and listings facilitate aggregation because they make it easy to navigate through content both within and external to a portal site. Areas and listings are also integrated with the SPS Search service. When you run an SPS search within the scope of an area, SPS searches through the content and links of that area's listings as well as the content and links of listings within the subareas nested below.
The SPS search service is complimented by the SPS indexing service. The indexing service is designed to build indices by crawling through the content links provided by areas and listings. The indexing service even knows how to crawl through Word documents and Excel spreadsheets and search for specific keywords. Once the set of indices has been built, the SPS search service is able to perform fast searches that allow user to find the content they are looking for.
The WSS and SPS Object Models
WSS and SPS each expose an object model for developers that are writing custom software. The WSS object model allows you to develop administrative applications that create and manage virtual servers, site collections, sites, workspaces and users. You can also design and implement end-user targeted applications using the WSS object model that manage lists and document libraries as well as the items they contain. The SPS object model allows you to programmatically manipulate areas and listings and to automate other features such as the SPS services for search and single sign on (SSO).
The WSS and SPS teams at Microsoft have exposed their object models to you through class library DLLs as well as through a built-in set of Web services. For example, you should add a reference to Microsoft.SharePoint.dll when you want to program against the WSS object model using the class library. If you want to program against the WSS object model using Web services, you should add a Web reference to one of the built-in Web services such as http://AcmeServer/_vti_bin/Lists.asmx.
How do you decide between using the class libraries and Web services? The class libraries are easier to use and they support more features. However, a custom application that uses one of the class library DLLs can only run on a server computer within a WSS or SPS deployment. Programming against the object model of WSS and SPS using the Web services doesn’t provide as much functionality and often requires you to program in terms of XML. However, a custom application built using Web services can be run on an administrator’s desktop computer or a user’s laptop computer. The whole point to using the built-in Web services is that a custom application can be written to communicate with a WSS or SPS deployment from across the network.
When developers begin to program against the WSS object model, there is often confusion surrounding different terminology used between WSS and its predecessor SharePoint Team Services (STS). For example, the new WSS term "Site Collection" is the equivalent of the old STS term "Site". The new WSS term "Site" is the equivalent of the old STS term "Web". The new WSS term "Top-level Site" is the equivalent of the old STS term "Root Web".
While the WSS team has been consistent using the new WSS terminology in their product documentation, the names of classes in the WSS object model are based on the old STS terms. For example, you program against a site collection using an SPSite object. You program against a site using a SPWeb object. An SPSite object provides a public property named RootWeb that returns an SPWeb object representing the site collection’s top-level site. Once you understand this potential point of confusion, the WSS object model becomes easier to learn.
The WSS object model exposed by the class library provides a top-level GlobalAdmin class that serves as an entry point into a WSS deployment. You can use a GlobalAdmin object to enumerate through the virtual servers, site collections and site within a WSS or SPS deployment as shown in figure 10. Within each site, you can then inspect its lists, document libraries, users and child sites.
// get GlobalAdmin object for current WSS deployment
SPGlobalAdmin globalAdmin = new SPGlobalAdmin();

// enumerate through IIS Virtual Servers
foreach(SPVirtualServer vServer in globalAdmin.VirtualServers)
{
// determine which IIS Virtual Servers are extended with WSS
if(vServer.State == SPVirtualServerState.Ready)
{
// enumerate through Site Collections of each Virtual Server
foreach(SPSite SiteCollection in vServer.Sites)
{
// enumeratre through Sites of each Site Collection
foreach(SPWeb Site in SiteCollection.AllWebs)
{
// enumerate through Lists of each Site
foreach(SPList List in Site.Lists)
{
Console.WriteLine(List.Title);
}
}
}
}
}
Figure 10: The WSS object model makes it possible to enumerate a site hierarchy.
This whitepaper is accompanied by two sample applications. The first sample application named the SharePoint Site Browser illustrates how to program against the WSS object model using the class library. We wrote this Windows Forms application to demonstrate techniques required to enumerate through virtual servers, site collections, sites, lists, document libraries and users. A screen shot of this application is shown in figure 11.
Figure 11: The SharePoint Site Browser is a sample application that uses the WSS object model
We wrote a second sample application named the Portal Area Browser that demonstrates how to program against the SPS object model. The code behind the application will show you how to program against the SPS class library DLLs to navigate through areas and inspect their listings. Both of these applications complete with full source code can be downloaded from http://Barracuda.net/downloads.aspx.
Web Part Architecture
The inclusion of Smart Page and Web Part technology is one of the most powerful and enabling aspects of WSS. Smart Pages provide each site with an extensible HTML-based user interface. A site owner or Web designer can customize a Smart Page by adding and configuring Web Parts. Users can further personalize Smart Pages by modifying existing Web Parts and adding new Web Parts. It is interesting to note that the Smart Page and Web Part technology created for WSS is being carried over as a major new feature in the Whidbey release of ASP.NET.
How is a Smart Page different from a standard ASP.NET page? A standard ASP.NET page is stored as a text file on the file system of the Web server. The pieces that make up a Smart Page, on the other hand, are stored in multiple tables inside the content database. WSS constructs Smart Page objects on the fly by retrieving data from these tables. It is this dimension of the Web Part architecture that makes it possible to customize and personalize sites.
Note that the HTML-based interface provided by WSS refers to a Smart Page as a Web Part Page. You can assume that a Smart Page and a Web Part Page are two different terms that mean the same thing. For the remainder of this whitepaper, we will use the term Web Part Page because that is what you will see when customizing WSS sites with the browser or with Microsoft Office FrontPage 2003.
Let's take a moment and examine a Web Part Page from the perspective of a Web Part consumer. If you are a site owner or you have Web designer permissions, you can view and modify a Web Part Page in either Shared View or Personal View. Using the browser, you can switch back and forth using the Modify Shared Page menu as shown in figure 12. Once you have switched over to your personal view, the menu caption in the upper right-hand corner of the Web Part Page changes to Modify My Page.
Figure 12: Web Part Pages can be modified in either shared view or personal view.
To customize the Web Parts on a Web Part Page, you should enable the Design this Page option. You can also add new Web Parts to a Web Part Page using the Add Web Parts menu. If you are working in a Web Part Page in shared view, the customizations you apply to Web Parts are seen by all users. If you switch from shared view to personal view, your modifications are only seen by you. WSS is smart enough to store the shared customization data and private personalization data separately in the content database.
You must be a site owner or have Web designer permissions to modify a Web Part Page in shared view. When a Web Part Page is generated for a user that is neither the site owner nor a Web designer, the page does not provide the ability to switch over to a shared view. Instead, the page only provides a Modify My Page menu. However, the user can still enable the Design this Page option and, consequently, add and customize Web Parts. Any modifications made by the user will be stored as personalized data as opposed to shared data.
A Web Part Page is laid out in terms of Web Part Zones as shown in figure 13. A Web Part is added to a Web Part Page by being placed within a Web Part Zone. WSS allows a site owner or Web designer to create new Web Part Pages using a pre-provided set of templates. With the browser, you can use one of these Web Part Page templates to create new Web Part Page with a pre-defined layout of zones. If you use Microsoft Office FrontPage 2003 to create and design Web Part Pages, you have even more flexibility. That's because you can add, remove and reposition zones on a Web Part Page using the FrontPage page designer.
Figure 13: The SharePoint handler object retrieves data from the content database to assemble and render a Web Part Page.
WSS provide a rendering engine for Web Part Pages by leveraging and extending the underlying ASP.NET infrastructure. WSS routes each Web Part Page request to a custom ASP.NET handler object created from the SharePointHandler class. This handler class is defined inside the Microsoft.SharePoint.dll assembly within the Microsoft.SharePoint.ApplicationRuntime namespace.
For each Web Part Page request, the SharePointHandler object is responsible for retrieving all the necessary data from the content database. This includes the Web Part Page document which defines a layout of Web Part Zones. The SharePointHandler object also must retrieve data from other tables within the content database to determine how Web Parts have been customized and personalized within specific zones. WSS provides the optimization of retrieving all the data it needs for a Web Part Page in a single roundtrip to SQL Server.
After retrieving the data associated with a Web Part Page, the SharePointHandler object is responsible for assembling the logic to generate an HTML page to return to the user. The SharePointHandler object creates an object for each Web Part and initializes it with the appropriate customization and personalization data. Finally, the SharePointHandler object enters the rendering phase where it steps through all the Web Part objects in sequence giving them an opportunity to contribute HTML to the output for the page.
Writing a Custom Web Part
With your newfound understanding of Web Part architecture, let's turn our attention to creating custom Web Parts with Visual Studio .NET. To get started with Web Part development, you should begin by downloading and installing the Web Part Templates for Visual Studio .NET. These templates are distributed in an MSI file that can be found at http://msdn.microsoft.com/sharepoint.
After you have installed the Web Part Templates, Visual Studio .NET will provide a new project template for creating a Web Part library DLL. Visual Studio .NET will also provide various other templates for creating files related to Web Part development such as a source file with the starting point for a Web Part class.
You create a Web Part by authoring a class that inherits from the WebPart class defined inside the Microsoft.SharePoint.dll assembly. The WebPart class exists within the Microsoft.SharePoint.WebPartPages namespace. You are required to override methods of the WebPart class to take advantage of many Web Part features. To create the traditional "Hello, World" Web Part class, you simply need to override a single method named RenderWebPart.

using Microsoft.SharePoint.WebPartPages;
using System.Web.UI;

namespace AcmeWebParts {
public class TedsWebPart : WebPart {
protected override
void RenderWebPart(HtmlTextWriter output) {
output.Write("Hello, World");
}
}
}
Figure 14 shows how custom Web Part classes fit into a larger inheritance hierarchy. As you can see, the WebPart class created by Microsoft's WSS team inherits from the Control class created by Microsoft's ASP.NET team. Therefore, a Web Part is really a specialized type of ASP.NET control. If you have experience developing ASP.NET Web applications or server-side controls, many of the programming techniques you already use can be readily applied when developing Web Parts.
Figure 14: A Web Part "IS AN" ASP.NET control.
When it comes to providing to code to render HTML, there's an important difference between developing ASP.NET controls and developing Web Parts. When you author an ASP.NET control, you render HTML by overriding the Render method. When you author a Web Part, you override the RenderWebPart method instead. Why is this?
The Render method defined in WebPart class contains generic code to generate the Web Part's title bar and borders. This is what is known in SharePoint terminology as the chrome around a Web Part. You should not override the Render method provided by the WebPart class because your resulting Web Part class will not render the standard Web Part chrome correctly. Instead, you should override the RenderWebPart method because this allows you to generate HTML that is displayed properly inside the chrome.
The RenderWebPart method provides the same HtmlTextWriter parameter as the Render method. That means you can generate HTML for a Web Part in the RenderWebPart method using the same techniques you use for a custom ASP.NET control in the Render method. For example, you can generate an HTML table by calling the RenderBeginTag method and the RenderEndTag method of the HtmlTextWriter parameter as shown in figure 15.
override void RenderWebPart(ByVal output As HtmlTextWriter) {

// create HTML table with custom attributes
output.AddAttribute(HtmlTextWriterAttribute.Cellpadding, "5");
output.AddAttribute(HtmlTextWriterAttribute.Border, "2");
output.RenderBeginTag(HtmlTextWriterTag.Table);

// create new row
output.RenderBeginTag(HtmlTextWriterTag.Tr);

// create new cell
output.RenderBeginTag(HtmlTextWriterTag.Td);
output.Write("Name:");
output.RenderEndTag(); //

// create new cell
output.RenderBeginTag(HtmlTextWriterTag.Td);
output.Write("Bob Smith");
output.RenderEndTag(); //

output.RenderEndTag(); //
output.RenderEndTag(); //
}
Figure 15: You use the HtmlTextWriter parameter within the RenderWebPart method to generate the HTML for a Web Part.
A Web Part, like other ASP.NET controls, can be designed to be a composite control containing child controls. If you leverage familiar ASP.NET server-side controls when developing custom Web Parts, you can create detailed views and polished data entry screens without getting bogged down in the details of generating DHTML and JavaScript. For example, you can create sophisticated-looking Web Parts in a hurry using ASP.NET controls such as the DataGrid control, the Calendar control and the ASP.NET validation controls.
You must override the CreateChildControls method to create a custom Web Part with child controls. Your implementation of CreateChildControls should create and initialize child control objects and then add them to the Web Part object's Controls collection. A simple example of creating a TextBox object and a Button object is shown in the class definition for JasonsWebPart in figure 16.
public class JasonsWebPart : WebPart {

// fields to hold child controls
protected TextBox txtName;
protected Button btnSubmit;

// create child control
protected override void CreateChildControls() {
txtName = new TextBox();
this.Controls.Add(txtName);
btnSubmit = new Button();
btnSubmit.Text = "Submit Name";
this.Controls.Add(btnSubmit);
}

// render HTML for Web Part
protected override
void RenderWebPart(ByVal output As HtmlTextWriter) {
txtName.RenderControl(output);
output.RenderBeginTag(HtmlTextWriterTag.Br);
btnSummit.RenderControl(output);
}
}
Figure 16: A custom Web Part class can create child ASP.NET controls.
Examine the implementation of the RenderWebPart method in the class JasonsWebPart and see how it calls the RenderControl method on each child control. When you call RenderControl on a child control and pass it the HtmlTextWriter parameter, the child control responds by writing its HTML into the output stream that will be returned to the user. This example illustrates how a Web Part's implementation of the RenderWebPart method is written to combine the HTML output of all the child controls into a single HTML element.
Web Part Customization and Personalization
One of the most powerful aspects of Microsoft's Web Part technology is its ability to track customization and personalization data. And while this feature is powerful, it's relatively easy to implement from the perspective of a Web Part developer. You simply add properties to a Web Part class and mark these properties with special attributes that have been defined by the WSS team. This strategy represents a great example of the power of declarative programming made possible by the .NET Framework. You are not required to write any code for storing or retrieving either customization data or personalization data. All this is handled by WSS behind the scenes.
Imagine a scenario where you are required to develop a custom Web Part that displays the user's local weather report. However, different users live in different locations. Therefore, your Web Part must be designed to track a personalized zip code for each user. You can design a Web part to track personalized zip codes by defining a ZipCode property with a special set of attributes provided by the WSS team at Microsoft. It's the presence of these attributes in your compiled code that tell WSS how you would like the property value to be customized and/or personalized.
Examine the WeatherReportWebPart class definition of the class in figure 17. This Web Part class defines a public ZipCode property together with a protected _ZipCode field to track the required personalization data. The ZipCode property definition contains the WebPartStorage attribute which has been parameterized for personal storage. The presence of the WebPartStorage attribute instructs WSS to automatically store and retrieve personalization data for this property.
[ XmlRoot(Namespace="AcmeWebParts") ]
public class WeatherReportWebPart : WebPart {

[ // Web Part property attributes
WebPartStorage(Storage.Personal),
DefaultValue(""),
Browsable(true),
FriendlyName("Zip Code"),
Category("User Info")
]
public string ZipCode {
get {
return _ZipCode;
}
set {
_ZipCode = value;
}
}

// field used as backing store for ZipCode property
protected string _ZipCode = string.Empty;

}
Figure 17: Web Part properties are defined with attributes that control how WSS persists its customization and personalization settings.
When the SharePointHandler object initializes a Web Part object from the WeatherReportWebPart class, it checks to see if there is any customization or personalization data for the Web Part in the content database. If WSS finds a pre-existing ZipCode property value, it assigns this value to the ZipCode property while it is initializing the Web Part object. Since the ZipCode property's set block assigns the personalized value to the _ZipCode field, the user's zip code is available to all other methods in the WeatherReportWebPart class throughout the lifetime of the Web Part object. This example demonstrates a common technique where a protected field is used to provide a backing store for the public property value.
When you define a persistent property like ZipCode in a Web Part class, how does a user actually customize or personalize its setting? This is easy because WSS automatically supplies user interface elements that allow users to customize or personalize property settings. When a user runs a menu command on a Web Part Page to modify a Web Part, WSS displays a Task Pane containing Tool Parts on the right-hand side of the browser window.
A Tool Part is a WSS user interface element that allows a user to examine and modify Web Part property values in the Task Pane. When in shared view, a Tool Part allows the user to work with customized values. When in personal view, a Tool Part allows the user to work with personalized values.
WSS provides standard Tool Parts that allow users to inspect and modify Web Part properties. If you don't like the generic user interface elements created by these standard Tool Parts, WSS makes it possible for you to create your own. If you choose to create a custom Tool Part, you can take over control of how the user interface is generated when a user wants to customize or personalize your custom Web Part properties. Authoring a Tool Part is similar to authoring a Web Part because you can build it as a composite control containing child ASP.NET controls.
You have just seen how Web Parts track customization data and personalization data. This is a feature that makes Web Part technology valuable to you as a software developer. Your sites can be customized and personalized by different users in different ways. All the while, you never have to write any code to manage user membership nor do you have to write any code to store and retrieve property values inside the content database. WSS does all this for you so you can spend more time writing other aspects of a Web Part such as your business logic.
Taking Advantage of Other Web Part Development Features
When you are writing code for a Web Part, you might want to program against the WSS object model to access the data for a list or a document library. You might also want to create a custom Web Part that allows a user to inspect or configure the various security settings for a site. However, it doesn’t usually make sense to use the GlobalAdmin object as the entry point into the WSS object model as was shown earlier. Instead, you should acquire an entry point using the SPControl class.
The SPControl class provides two static methods named GetContextSite and GetContextWeb. These two methods allow you to hook into the WSS object model within the context of the current request. The GetContextSite method returns an object that represents the current site collection. The GetContextWeb method returns an object that represents the current site. Both methods require you to pass the ASP.NET HttpContext object associated with the current request. Here’s an example of using the GetContextWeb method from within a custom Web Part to enumerate through the lists of the current site.

SPWeb CurrentSite = SPControl.GetContextWeb(this.Context);

// enumerate through the site’s lists
foreach(SPList List in CurrentSite.Lists) {
this.ListBox1.Items.Add(List.Title);
}
Another important aspect of developing Web Parts involves communicating across the network with Web services and other back-end systems. Web Part are often used to give SPS portal sites and standard WSS sites the ability to acts as gateways into an enterprise-level applications. Microsoft and other companies have already built Web Parts that act as adapters into popular line-of-business applications such as such as BizTalk, SAP and PeopleSoft. You can follow suit and build custom Web Parts that will allow your company's users to access any of your back-end systems.
Web Parts that are written to communicate with Web services and line-of-business applications typically require a set of security credentials to make the initial connection. Given this common requirement, SPS was designed with a Single Sign-On (SSO) service for storing and retrieving security credentials. The SSO service can cache security credentials on a user-by-user basis. It can alternatively store a common set of security credentials used by all the members of an Active Directory group. The SSO service does the work required to track the Windows security ID (SID) of current user when storing or retrieving a set of security credentials from the SSO database. The SSO service also employs the necessary encryption so that security credentials are never stored in the SSO database as clear text.
The Web Part infrastructure supports a feature known as Web Part connections. Web Part connections represent an extensible customization model where two or more Web Parts can be connected together in a provider/consumer relationship. A user can establish a connection between Web Parts using either the browser or Microsoft Office FrontPage 2003. This makes it possible to create Web Part Pages that display sophisticated views of data with master/detail relationships and parent/child relationships. As a developer, you create connectable Web Parts by implementing standard interfaces defined by the WSS team at Microsoft.
The WSS infrastructure for connecting Web Part is based on a loosely-coupled model. That means two Web Part do not require knowledge of each other to be connected together on a page. The loosely-coupled nature of this model provides the flexibility to connect Web Part created by different companies and different development teams. For example, you can create your own custom Web Parts and connect them to standard Web Parts that are distributed by teams within Microsoft.
Web Part Deployment and Distribution
You can deploy a Web Part library DLL on a Web server in one of two different places. First, you can deploy a Web Part library DLL inside a virtual server's \bin directory just like you would deploy assembly DLLs for a standard ASP.NET application. Secondly, you can deploy a Web Part library DLL in the Global Assembly Cache (GAC). A Web Part library DLL in the GAC can be loaded into any virtual server on the hosting Web server machine.
While you are developing and testing Web Parts, it's convenient to configure your Web Part library project to compile its output DLL directly into the \bin directory of the virtual server you will be using for your testing. With this approach, you can instantly test your Web Parts using the browser after you recompile the Web Part library project.
The fact that Web Part Pages are stored inside the content database poses a security risk. Imagine a scenario where some malicious individual is able to access the content database and modify the table that holds all the Web Part Page documents. What would happen if this malicious individual attempted to mount an attack by placing in-line code within the body of the Web Part Page? You should be able to see the potential problem here. Fortunately, WSS can defend itself against this kind of attack.
WSS protects itself by processing Web Part Pages in safe mode. When the SharePointHandler object processes the request for a Web Part Page, it will never execute any in-line code it finds within the body of the page. Furthermore, the SharePointHandler object will only load Web Parts and ASP.NET controls that have been explicitly configured as a safe control. You can configure Web Parts and ASP.NET controls using the section of the hosting virtual server's web.config file.
You will experience an error whenever you run a Web Part Page that attempts to load a Web Part or an ASP.NET control that has not been properly configured as a safe control. Clearly, there must be a set of standard Web Part and ASP.NET controls that WSS marks as safe by default. Whenever you extend a virtual server with WSS, the web.config file that is automatically copied to the root directory contains a element that includes a set of Microsoft's standard Web Parts and ASP.NET server-side controls.
When you deploy a custom Web Part library DLL onto a front-end Web server running WSS, you must modify the web.config file for each virtual server where you plan to run these Web Parts. The element of the web.config file should be modified to include a new element that look like this.

Namespace="AcmeWebParts"
TypeName="*"
Safe="True" />

Note that the preceding example of a element identifies an assembly using its friendly name (e.g. AcmeWebParts). When you deploy a strongly-named assembly DLL, you should not use the simple friendly name. Instead, you should use the fully-qualified, four-part assembly name. You will always be required to use the fully-qualified, four-part assembly name when you have deployed a Web Part library DLL in the GAC. That's because the GAC only allows strongly-named assembly DLLs.
The security layer provided by the Web Part architecture goes beyond requiring that Web Parts and ASP.NET controls are configured as safe controls. A Web Part library DLL running inside the \bin directory is further restricted in what actions it can perform by the element defined within the web.config file.

The element contains the level attribute. The value of the level attribute configures Code Access Security (CAS) permissions that restrict Web Part library DLLs from performing potentially dangerous actions such as connecting to a SQL Server database and accessing the local file system. The element's level attribute is set to WSS_Minimal by default which severely restricts what a Web Part library can do. This default setting often makes it hard or impossible to test and debug custom Web Parts during the development cycle.
You can adjust the elements level attribute setting to WSS_Medium to relax the CAS restrictions. A setting of WSS_Medium usually allows you to test and debug Web Part without security-related problems. In occasional scenarios you might have to adjust the trust level setting to a value of Full to completely disable all CAS-related security restrictions. Note that you should run the IISRESET.EXE command to restart after adjusting the element's level attribute setting inside a web.config file.
Keep in mind that a element's level attribute setting in a web.config file only affects Web Part library DLLs running within the \bin directory. It does affect Web Part library DLLs that have been installed in the GAC. Web Part library DLLs in the GAC are considered to be fully trusted and always run without any CAS restrictions. This can be a factor that influences your decision whether to deploy a Web Part library DLL in the \bin directory of the GAC.
Importing Web Parts
The final aspect Web Part deployment centers around importing description information about the Web Part into a Web Part gallery. WSS supports Web Part galleries at site collection level as well as the virtual server level. However, before you can import a Web Part's description information into a Web Part gallery, you must first create a Web Part description file.
A Web Part description file is an XML file with a .dwp extension. An example of a Web Part description file is shown in figure 18. The Title and Description elements provide friendly text that is displayed to Web Part consumers as they are browsing through the list of Web Parts that can be added to a Web Part Page. The Assembly and TypeName elements provide WSS with the information it needs to load the associated Web Part class at runtime. Remember to use the fully-qualified, four-part assembly name when creating a .dwp file for a Web Part library DLL with a strong name.

AcmeWebParts
AcmeWebParts.WeatherReportWebPart

98052

Figure 18: A Web Part description file is used to import a Web Part into a Web Part gallery.
A .dwp file can optionally contain initialization values for one or more Web Part properties. The .dwp file in figure 17 shows how to use a custom element to provide an initial default value for the Web Part's ZipCode property. The default zip code that's being used in this example is 98052 which is the zip code for Redmond, WA. That means that this Web Part will initially show the weather report for the Microsoft Campus after being placed on a Web Part Page. However, this initial ZipCode property value will be overwritten once it has been customized or personalized by a user.
Once you have created the Web Part description file, you can import the associated Web Part into WSS and use it on a Web Part Page. The simplest way to import a Web Part is choose the Import command from the Add Web Part menu while customizing or personalizing a Web Part Page within the browser. The Add Web Parts menu is available as a sub menu on the Modify Shared Page menu and the Modify My Page menu in the upper right-hand corner of the browser window.
You can also import a Web Part description file into the Web Part gallery of a site collection to make it available to all sites within that site collection. To do this, navigate to the Top-Level Site Administration page and scroll down to the Site Collection Galleries section. Next, click the link with the caption Manage Web Part Gallery. That will bring you to the site collection's Web Part Gallery page. This page provides the option of importing .dwp files.
In addition to importing a Web Part at the site collection level, you can also import a Web Part into the Web Part Gallery for a virtual server. However, the process for doing this is more complex because you must first build a Web Part Package. Once you have built the Web Part Package, you can install it using the STSADM.EXE administration tool.
A Web Part Package is a CAB file that contains a Web Part library DLL and all its associated .dwp files. You can easily build a Web Part Package with Visual Studio .NET by creating a new CAB project. When you create a Web Part Package, you must add a special header file named manifest.xml. The manifest.xml file is required because it contains essential deployment information that WSS needs to properly install and configure a Web Part library DLL.
An example of a manifest.xml file is shown in figure 19. As you can see, the manifest.xml file contains the file name of the Web Part library DLL and a list of .dwp files. It isn't necessary to add the fully-qualified, four-part assembly name of a Web part library DLL to a manifest.xml file. That's because STSADM.EXE administration utility is able to discover the assembly name at runtime when it loads the Web Part library DLL.

Figure 19: Each Web part package must include a manifest.xml file
Once you have built a Web Part Package that contains a manifest.xml file, the Web part library DLL and all the associated .dwp files, you can then install it using the STSADM.EXE administration tool. For example, if you have built a Web Part Package named AcmeWebPartsPack.cab, you can install it using the following command-line instruction.

STSADM.EXE -o AddWPPack -filename AcmeWebPartsPack.cab
When you run this command, WSS copies the Web Part library DLL into the \bin directory each virtual server within the current WSS deployment. You can add the -url parameter to the preceding command-line instruction if you would like to install the Web Part library into only one of the virtual servers within the current WSS deployment.
When you install a Web Part Package with the STSADM.EXE utility, WSS provides the convenience of adding the required elements to web.config files to configure each Web Part being installed as a safe control. This maintenance feature certainly eases large-scale deployment when you are rolling a new Web Part library DLL out into a Web farm environment.
When installing a Web Part Package with the STSADM.EXE utility, you have the option of installing Web Part library DLLs in the GAC. This can be accomplished by using the -globalInstall parameter.

STSADM.EXE -o AddWPPack -filename AcmeWebPartsPack.cab -globalInstall
Using this technique makes it possible to install a Web Part library DLL only once per machine no matter how many virtual servers use it. Also remember that Web Part library DLLs installed in the GAC are not restricted by the trust level defined inside the web.config file. Therefore, you should not install Web Part library DLLs into the GAC casually. You should only install a Web Part library DLL in the GAC when you know it has come from a trusted source and that it poses no security risk at all.
Summary
This whitepaper has provided an in-depth examination into the architecture of SharePoint products and technologies. WSS and SPS are two separate products that have been designed to work well together. WSS provides the foundation for creating collaborative Web site that support customization and personalization. SPS compliments WSS by playing the role of a content aggregator. You have also seen that SPS is fully dependant upon the underlying infrastructure of WSS. The more you know about WSS, the easier it will be to master SPS.
In one sense, SharePoint products and technologies lessen the need for custom software development. That's because WSS and SPS provide so much functionality right out of the box. However, WSS and SPS also provide valuable opportunities to write custom applications and Web Parts. This article has given you a roadmap to get started in the world of SharePoint development.

About the authors
Ted Pattison is a published author and an industry-leading trainer and consultant who specializes in building portal applications and collaborative solutions with SharePoint Products and Technologies. Ted has been recognized by Microsoft as an MVP with Windows SharePoint Services and Microsoft Office Portal Server 2003. He has delivered his advanced SharePoint training over 25 times since September of 2003 and has taught and consulted with developers and system administrators from companies such as Microsoft, Intel, Countrywide, Morgan Stanley, Mattel and Viacom. Ted is also a best-selling author of books focused on developing for the Windows platform and a columnist with MSDN Magazine. For more information, go to http://www.TedPattison.net.