Moss and Wss

How do I install Active Directory on my Windows Server 2003 server?

2008-07-17T01:58:00.001-07:00

First make sure you read and understand Active Directory Installation Requirements. If you don't comply with all the requirements of that article you will not be able to set up your AD (for example: you don't have a NIC or you're using a computer that's not connected to a LAN).

Note: This article is only good for understanding how to install the FIRST DC in a NEW AD Domain, in a NEW TREE, in a NEW FOREST. Meaning - don't do it for any other scenario, such as a new replica DC in an existing domain. In order to install a Windows Server 2003 DC in an EXISTING Windows 2000 Domain follow the Windows 2003 ADPrep tip.

A Great Way to Master Active Directory... Watch These Videos!

Have you seen the Active Directory Training videos by Train Signal? I highly recommend this course, as you will learn much more than you will from books (which never seem to have enough detail!). Their learn by doing approach is excellent because it shows you the "ins and outs" of Active Directory instead of reading pages and pages of theory.

-Daniel Petri, Petri IT Knowledge Base

Click Here to Watch Active Directory Videos!

Windows 2000 Note: If you plan to install a new Windows 2000 DC please read How to Install Active Directory on Windows 2000.

Windows Server 2003 Note: If you plan to install a new Windows Server 2003 DC in an existing AD forest please read the page BEFORE you go on, otherwise you'll end up with the following error:

Here is a quick list of what you must have:

*

An NTFS partition with enough free space
*

An Administrator's username and password
*

The correct operating system version
*

A NIC
*

Properly configured TCP/IP (IP address, subnet mask and - optional - default gateway)
*

A network connection (to a hub or to another computer via a crossover cable)
*

An operational DNS server (which can be installed on the DC itself)
*

A Domain name that you want to use
*

The Windows Server 2003 CD media (or at least the i386 folder)
*

Brains (recommended, not required...)

This article assumes that all of the above requirements are fulfilled.
Step 1: Configure the computer's suffix

(Not mandatory, can be done via the Dcpromo process).

1.

Right click My Computer and choose Properties.
2.

Click the Computer Name tab, then Change.

3.

Set the computer's NetBIOS name. In Windows Server 2003, this CAN be changed after the computer has been promoted to Domain Controller.
4.

Click More.

5.

In the Primary DNS suffix of this computer box enter the would-be domain name. Make sure you got it right. No spelling mistakes, no "oh, I thought I did it right...". Although the domain name CAN be changed after the computer has been promoted to Domain Controller, this is not a procedure that one should consider lightly, especially because on the possible consequences. Read more about it on my Windows 2003 Domain Rename Tool page.

6.

Click Ok.
7.

You'll get a warning window.

8.

Click Ok.
9.

Check your settings. See if they're correct.

10.

Click Ok.
11.

You'll get a warning window.

12.

Click Ok to restart.

Step 2: Configuring the computer's TCP/IP settings

You must configure the would-be Domain Controller to use it's own IP address as the address of the DNS server, so it will point to itself when registering SRV records and when querying the DNS database.
Configure TCP/IP

1.

Click Start, point to Settings and then click Control Panel.
2.

Double-click Network and Dial-up Connections.
3.

Right-click Local Area Connection, and then click Properties.

4.

Click Internet Protocol (TCP/IP), and then click Properties.

5.

Assign this server a static IP address, subnet mask, and gateway address. Enter the server's IP address in the Preferred DNS server box.

Note: This is true if the server itself will also be it's own DNS server.

If you have another operational Windows 2000/2003 server that is properly configured as your DNS server (read my Create a New DNS Server for AD page) - enter that server's IP address instead:

6.

Click Advanced.
7.

Click the DNS Tab.
8.

Select "Append primary and connection specific DNS suffixes"
9.

Check "Append parent suffixes of the primary DNS suffix"
10.

Check "Register this connection's addresses in DNS". If this Windows 2000/2003-based DNS server is on an intranet, it should only point to its own IP address for DNS; do not enter IP addresses for other DNS servers here. If this server needs to resolve names on the Internet, it should have a forwarder configured.

11.

Click OK to close the Advanced TCP/IP Settings properties.
12.

Click OK to accept the changes to your TCP/IP configuration.
13.

Click OK to close the Local Area Connections properties.

Step 3: Configure the DNS Zone

(Not mandatory, can be done via the Dcpromo process).

This article assumes that you already have the DNS service installed. If this is not the case, please read Create a New DNS Server for AD.

Furthermore, it is assumed that the DC will also be it's own DNS server. If that is not the case, you MUST configure another Windows 2000/2003 server as the DNS server, and if you try to run DCPROMO without doing so, you'll end up with errors and the process will fail.
Creating a Standard Primary Forward Lookup Zone

1.

Click Start, point to All Programs, point to Administrative Tools, and then click DNS Manager. You see two zones under your computer name: Forward Lookup Zone and Reverse Lookup Zone.
2.

Right click Forward Lookup Zones and choose to add a new zone.

3.

Click Next. The new forward lookup zone must be a primary zone so that it can accept dynamic updates. Click Primary, and then click Next.

4.

The name of the zone must be the same as the name of the Active Directory domain, or be a logical DNS container for that name. For example, if the Active Directory domain is named "lab.dpetri.net", legal zone names are "lab.dpetri.net", "dpetri.net", or "net".

Type the name of the zone, and then click Next.

5.

Accept the default name for the new zone file. Click Next.

6.

To be able to accept dynamic updates to this new zone, click "Allow both nonsecure and secure dynamic updates". Click Next.

7.

Click Finish.

You should now make sure your computer can register itself in the new zone. Go to the Command Prompt (CMD) and run "ipconfig /registerdns" (no quotes, duh...). Go back to the DNS console, open the new zone and refresh it (F5). Notice that the computer should by now be listed as an A Record in the right pane.

If it's not there try to reboot (although if it's not there a reboot won't do much good). Check the spelling on your zone and compare it to the suffix you created in step 1. Check your IP settings.

Enable DNS Forwarding for Internet connections (Not mandatory)

1.

Start the DNS Management Console.
2.

Right click the DNS Server object for your server in the left pane of the console, and click Properties.

3.

Click the Forwarders tab.
4.

In the IP address box enter the IP address of the DNS servers you want to forward queries to - typically the DNS server of your ISP. You can also move them up or down. The one that is highest in the list gets the first try, and if it does not respond within a given time limit - the query will be forwarded to the next server in the list.

5.

Click OK.

Creating a Standard Primary Reverse Lookup Zone

You can (but you don't have to) also create a reverse lookup zone on your DNS server. The zone's name will be the same as your TCP/IP Network ID. For example, if your IP address is 192.168.0.200, then the zone's name will be 192.168.0 (DNS will append a long name to it, don't worry about it). You should also configure the new zone to accept dynamic updates. I guess you can do it on your own by now, can't you?

Step 4: Running DCPROMO

After completing all the previous steps (remember you didn't have to do them) and after double checking your requirements you should now run Dcpromo.exe from the Run command.

1.

Click Start, point to Run and type "dcpromo".

2.

The wizard windows will appear. Click Next.

3.

In the Operating System Compatibility windows read the requirements for the domain's clients and if you like what you see - press Next.

4.

Choose Domain Controller for a new domain and click Next.

5.

Choose Create a new Domain in a new forest and click Next.

6.

Enter the full DNS name of the new domain, for example - kuku.co.il - this must be the same as the DNS zone you've created in step 3, and the same as the computer name suffix you've created in step 1. Click Next.

This step might take some time because the computer is searching for the DNS server and checking to see if any naming conflicts exist.

7.

Accept the the down-level NetBIOS domain name, in this case it's KUKU. Click Next

8.

Accept the Database and Log file location dialog box (unless you want to change them of course). The location of the files is by default %systemroot%\NTDS, and you should not change it unless you have performance issues in mind. Click Next.

9.

Accept the Sysvol folder location dialog box (unless you want to change it of course). The location of the files is by default %systemroot%\SYSVOL, and you should not change it unless you have performance issues in mind. This folder must be on an NTFS v5.0 partition. This folder will hold all the GPO and scripts you'll create, and will be replicated to all other Domain Controllers. Click Next.

10.

If your DNS server, zone and/or computer name suffix were not configured correctly you will get the following warning:

This means the Dcpromo wizard could not contact the DNS server, or it did contact it but could not find a zone with the name of the future domain. You should check your settings. Go back to steps 1, 2 and 3. Click Ok.

You have an option to let Dcpromo do the configuration for you. If you want, Dcpromo can install the DNS service, create the appropriate zone, configure it to accept dynamic updates, and configure the TCP/IP settings for the DNS server IP address.

To let Dcpromo do the work for you, select "Install and configure the DNS server...".

Click Next.

Otherwise, you can accept the default choice and then quit Dcpromo and check steps 1-3.

11.

If your DNS settings were right, you'll get a confirmation window.

Just click Next.

12.

Accept the Permissions compatible only with Windows 2000 or Windows Server 2003 settings, unless you have legacy apps running on Pre-W2K servers.

13.

Enter the Restore Mode administrator's password. In Windows Server 2003 this password can be later changed via NTDSUTIL. Click Next.

14.

Review your settings and if you like what you see - Click Next.

15.

See the wizard going through the various stages of installing AD. Whatever you do - NEVER click Cancel!!! You'll wreck your computer if you do. If you see you made a mistake and want to undo it, you'd better let the wizard finish and then run it again to undo the AD.

16.

If all went well you'll see the final confirmation window. Click Finish.

17.

You must reboot in order for the AD to function properly.

18.

Click Restart now.

Step 5: Checking the AD installation

You should now check to see if the AD installation went well.

1.

First, see that the Administrative Tools folder has all the AD management tools installed.

2.

Run Active Directory Users and Computers (or type "dsa.msc" from the Run command). See that all OUs and Containers are there.

3.

Run Active Directory Sites and Services. See that you have a site named Default-First-Site-Name, and that in it your server is listed.

4.

Open the DNS console. See that you have a zone with the same name as your AD domain (the one you've just created, remember? Duh...). See that within it you have the 4 SRV record folders. They must exist.

= Good

If they don't (like in the following screenshot), your AD functions will be broken (a good sign of that is the long time it took you to log on. The "Preparing Network Connections" windows will sit on the screen for many moments, and even when you do log on many AD operations will give you errors when trying to perform them).

= Bad

This might happen if you did not manually configure your DNS server and let the DCPROMO process do it for you.

Another reason for the lack of SRV records (and of all other records for that matter) is the fact that you DID configure the DNS server manually, but you made a mistake, either with the computer suffix name or with the IP address of the DNS server (see steps 1 through 3).

To try and fix the problems first see if the zone is configured to accept dynamic updates.

1.

Right-click the zone you created, and then click Properties.

2.

On the General tab, under Dynamic Update, click to select "Nonsecure and secure" from the drop-down list, and then click OK to accept the change.

You should now restart the NETLOGON service to force the SRV registration.

You can do it from the Services console in Administrative tools:

Or from the command prompt type "net stop netlogon", and after it finishes, type "net start netlogon".

Let it finish, go back to the DNS console, click your zone and refresh it (F5). If all is ok you'll now see the 4 SRV record folders.

If the 4 SRV records are still not present double check the spelling of the zone in the DNS server. It should be exactly the same as the AD Domain name. Also check the computer's suffix (see step 1). You won't be able to change the computer's suffix after the AD is installed, but if you have a spelling mistake you'd be better off by removing the AD now, before you have any users, groups and other objects in place, and then after repairing the mistake - re-running DCPROMO.

5.

Check the NTDS folder for the presence of the required files.

6.

Check the SYSVOL folder for the presence of the required subfolders.

7.

Check to see if you have the SYSVOL and NETLOGON shares, and their location.

If all of the above is ok, I think it's safe to say that your AD is properly installed.

Connecting Web Parts in SharePoint Portal Server 2003, Part 2

2008-07-05T01:25:00.000-07:00

Connecting Web Part Exercise

I am using an ICellProvider Web Part to display the functionality of a connectable Web Part. The Cell Provider Web Part contains a textbox where end users can enter a value and a button. When the Cell Provider Web Part is connected to another Web Part, the value entered to the textbox will be passed to the consumer Web Part. Article two in this series will focus on how to create Cell Provider Web Parts.

The end users select the dropdown arrow at right hand corner of the Web Part when they are ready to connect the Web Part. End users should make sure that the page is in design view. The information about the Web Part will display as shown below, explaining the functionality of the Web Part.

The developer has the option to enter a meaningful description about the Web Part when developing it.

It will display a list of Web Parts that are compatible to connect to the Web Part as displayed below.

Currently only one Web Part is indicated compatible with the Provider Web Part. Simply clicking the "Cell Consumer Web Part" will connect the Cell Provider Web Part with "Cell Consumer Web Part".

A right sign will indicate which Web Part is connected to what as displayed below.

Article three in this series will focus on how to create ICellConsumer Web Parts.

The connection between and ICellProvider and ICellConsumer Web Part.

The value entered in the textbox at Cell Provider Web Part will get consumed by Cell Consumer Web Part.

Disconnecting the Web Parts

To remove the connection between two Web Parts, navigate to design view of the Web page and click the connected Web Part title. (The connected Web Part title will display with a right mark in front.). A message will display to confirm your action as displayed below:

Removing connection between Web Parts.

Web Services and Connectable Web Parts

Web services are mainly developed to provide specific data to a consumer. The developer has full control over exposing the Web service. The connectable Web Parts provide the option to the end user. The connectable Web Part can stand alone as individual Web Parts providing their dedicated information and then connect them together to provide filtering of information.

For example, there can be an employee list Web Part and employee details Web Part. Both of the Web Parts can stand alone providing information. If the end user wants to display the details of a selected employee, the end user has the option to connect the employee list Web Part to the employee detail Web Part. In this way, when the end user selects an employee from the employee list, the selected employee details will display in the details Web Part.

If you develop a Web service to cater to the above scenario, the developer has full control of the end result. The functionality provided by the Web service is not visible to the end user and the end user won't have knowledge or control to reuse the Web service if they need to in the future. At the end of the day it's reliant on whether you want to create a dedicated Web service or individual Web Parts that can stand alone and work together if needed.

The biggest benefit Web Parts have over a Web service is the reusability and the option for the end user to have control of their environment. This is a very important aspect in a portal architecture where end users have control over what they see. Portals are mainly developed so that end users can gather information relevant to them and centralize it. End users having more control over their environment is better than depending on a developer in a portal environment.

Conclusion

The connectable Web Parts are similar to normal Web Parts. The only difference is they are inheriting from a connection interface class that provides capability to communicate with other Web Parts at run time, so they can act as service if needed. Articles two and three of this series will show how to develop connectable Web Parts using the ICellProvider and ICellConsumer interfaces.

Connecting Web Parts in SharePoint Portal Server 2003, Part 1

2008-07-05T01:24:00.000-07:00

Microsoft's SharePoint Portal Server lets different developers and organisations develop Web Parts that can communicate with each other. A Web Part is a modular unit of information that works with Windows SharePoint Services Web sites only.

Web Parts contain Web-based content and are the building block of a Web Part Page. You can also create connections between Web Parts so that when you perform an action in one Web Part, it changes the contents of another Web Part.

The SharePoint architecture supports standard Connection Interfaces for passing information among Web Parts at runtime. The connectable Web Part will act as a provider Web Part by providing information to another Web Part or as a consumer Web Part by consuming information from a provider Web Part. Two Web Parts supported by a connection interface can be connected by an end user with either Microsoft Office Front Page or an Internet browser.

Connection Interface Details

There are few a different connection interfaces that provide different behaviors. The difference is mainly found in the amount of information that can be passed from one to another. For example, one interface can support providing a single value to a consumer Web Part. There are other interfaces that support more than a single value.

The connectable Web Part raises an interface event that executes an action in Web Parts connected to it. These connection interfaces act as pairs by either being a provider or consumer Web Part. An event from the provider will trigger an action in the consumer Web Part, and an event from the consumer Web Part will trigger an action in the provider Web Part. The following are some of the connection interface pairs and their functionality.

Connection Interface Pairs and Their Functionality
Connection Interface Pair	Functionality
ICellProvider, ICellConsumer	Provide or consume a single value from one Web Part to another.
IRowProvider, IRowConsumer	Provide or consume a single or multiple rows of values from one Web Part to another.
IListProvider, IListConsumer	Provide or consume an entire list from one Web Part to another.
IFilterProvider, IFilterConsumer	Provide or consume a filter value.

There are more connection interfaces available from the SharePoint architecture. However, I am mainly looking at interfaces connected using an Internet browser. There are a few more interfaces that are supported by Microsoft Front Page.

Web Parts can be connected only if they are compatible with each other. If Web Parts are not compatible, the Connection menu item in the Web Part will be disabled, and a tool tip will display the reason why it is disabled.

Compatibility Rules

The Web Part won't be able to connect to itself either directly or through a chain of connections. There are a few compatibility rules that SharePoint architecture follows when determining whether the Web Parts are compatible.

Are the Web Parts connecting as opposite pairs? For example, only ICellProvider interface can be connect with ICellConsumer interface.

Is the Web Part connecting through a Transformer? The Web Part architecture supports connecting dissimilar Web Parts with each other through transformers. For example, the IRowProvider Web Part can connect with either the IRowConsumer or the ICellConsumer Web Part. When it is connected to an ICellConsumer Web Part, the transformer determines which field will be consumed from the provider Web Part. The following are some of the transformers supported by connecting through a browser:

IRowProvider to ICellConsumer
IRowProvider to IFilterConsumer

The following are some of the interfaces that support the cross page connections. This means Web Parts in two different pages can communicate with each other.

Interfaces Supporting Cross Page Connection
Source page Interface	Target page Interface
IRowProvider	IFilterConsumer
IFilterProvider	IFilterConsumer

Web Parts can run on the client side, server side, or both. The connectable Web Part only can connect with other connectable Web Parts in the same location. This means both Web Parts should run either client side or server side. A client side Web Part won't be able to connect to a server side Web Part and vice versa.

When the developer creates the Web Part, he can determine the number of connections supported by the Web Part. This is done when the interface is registered in the code. The connection number can be either one or unlimited.

Connect Web Parts Through an Internet Browser

According to the SharePoint Portal Server 2003 Client section on Microsoft's SharePoint Portal Server 2003 System Requirements page, "To use the SharePoint Portal Server 2003 client, you need:

Portal access

Microsoft Internet Explorer 5.01, plus the latest service pack

Internet Explorer 5.5, plus the latest service pack

Internet Explorer 6, plus the latest service pack

Internet Explorer 5.2 for Mac OS X, plus the latest service pack

Netscape Navigator 6.2 or later

Netscape Navigator 6.2 for Mac

Netscape Navigator 6.2 for UNIX

Portal management

Internet Explorer 5.5, plus the latest service pack

Internet Explorer 6, plus the latest service pack

The Web page that contains the Web Parts should be in design view to support the connection functionality; otherwise, the connecting Web Part option won't be available to the end user. To access the design view of a SharePoint Web page, navigate to the top right hand corner and select Modify My Page or Modify Shared Page depending on whether the end user is using personal or shared view. Then select Design this page option from the dropdown menu as displayed below.

A right mark will indicate whether the page is in design view as displayed below.

There are more options available in a Web Part menu when its holding page is in design view. The Web Parts "Connections" option only is available when the Web Part is displayed in design view.

Creating a Basic Web Part

2008-07-04T22:57:00.000-07:00

This walkthrough provides the steps for creating a basic custom Web Part that you can add to your Web Part page. It is a simple HelloWorld Web Part demonstrating how to create a Web Part that derives from the ASP.NET 2.0 WebPart class for use in a SharePoint site.

Note:
For more information about ASP.NET Web Parts, see the following ASP.NET 2.0 documentation: ASP.NET Web Parts Quick Start and ASP.NET Web Parts Pages.

Prerequisites

Windows SharePoint Services 3.0

Visual Studio 2005

Step 1: Create an ASP.NET Web Part assembly

To create a simple Web Part, you start by developing an ASP.NET Web Part assembly. To start, you can create a class library project with a class that derives from the System.Web.UI.WebControls.WebParts.WebPart base class.

Create an ASP.NET Web Part Assembly

Start Visual Studio 2005.
Start a new C# class library project.
Type HelloWorldWebPart as the project name.
Add a reference to System.Web.

In your .cs file, copy and paste in the following code:

Copy Code

using System;
using System.Text;
using System.Web.UI.WebControls.WebParts;
namespace MyWebPartLibrary

{
 public class HelloWorldWebPart : WebPart
   {
    protected override void Render(System.Web.UI.HtmlTextWriter writer)
     {
        writer.Write("Hello, World!");
     }
   }
}

Compile the solution. Now you have an assembly that contains your HelloWorldWebPart Web Part.

Step 2: Place your assembly in the bin or global assembly cache

Within a SharePoint site, you can deploy a Web Part assembly to one of two locations:

bin directory: The bin directory is a folder stored in your Web application root directory. For more information, see How to: Find the Web Application Root.

Note:

If a bin directory does not exist you must add one. Web Parts cannot be stored in the _app_bin directory.
global assembly cache: The global assembly cache enables you to share assemblies across numerous applications. The global assembly cache is automatically installed with the .NET runtime. Components are typically stored in C:\WINNT\Assembly.

Note:
If a bin directory does not exist you must add one. Web Parts cannot be stored in the _app_bin directory.

Each location has advantages and disadvantages, as described in the following table.

Deployment Location	Advantages	Disadvantages
bin directory	A partial trust location. By default, code that runs from this directory has a low level of code access security (CAS) permissions. Because administrators must explicitly raise permissions granted to a Web Part so it can function properly, they can prefer that assemblies run in the bin directory with a known set of required CAS permissions. A bin directory is specific to a Web application. This makes it possible to isolate code to a particular Web application.	If you want your Web Part to run everywhere, you would need to deploy your bin assembly.
global assembly cache	A global location where signed assemblies can be deployed. Assemblies run with full trust by default. They are globally installed, so they will work in any Web application.	Generally no CAS restrictions on code installed to the global assembly cache; therefore, you lose the defense-in-depth security benefit.

Deployment Location

Advantages

Disadvantages

bin directory

A partial trust location. By default, code that runs from this directory has a low level of code access security (CAS) permissions. Because administrators must explicitly raise permissions granted to a Web Part so it can function properly, they can prefer that assemblies run in the bin directory with a known set of required CAS permissions.

A bin directory is specific to a Web application. This makes it possible to isolate code to a particular Web application.

If you want your Web Part to run everywhere, you would need to deploy your bin assembly.

global assembly cache

A global location where signed assemblies can be deployed. Assemblies run with full trust by default. They are globally installed, so they will work in any Web application.

Generally no CAS restrictions on code installed to the global assembly cache; therefore, you lose the defense-in-depth security benefit.

For the purposes of this sample, we are placing the assembly in the bin directory.

Step 3: (Optional) If using the bin directory, set special security attributes

By default, code access security permissions for the bin directory are low; only pure execution is allowed. Although the sample in this walkthrough can run with the minimal trust level, in most cases you need to elevate these permissions to make your assembly run correctly, for example, if your Web Part requires access to the SharePoint object model.

There are two ways to elevate permissions:

(Recommended) Create a new trust policy file, and point your web.config file at the new file. This option is more complicated but it gives you a precise attribution of permissions for your Web Parts.

For more information about trust policy files, see Microsoft Windows SharePoint Services and Code Access Security.
Raise the net trust level of the bin directory. In the web.config file in the Web application root, there is a tag called with a default attribute of level="WSS_Minimal". You can change this level to WSS_Medium. While this option is simpler, it grants arbitrary new permissions you might not need and is less secure than creating a new trust policy file.

To raise the trust level of the bin directory

Locate the web.config file in your application root and open it for editing.
Locate the trust level tag, . Change the trust level to WSS_Medium.

Step 4: Add your Web Part to the SafeControls List

A fundamental assumption of the Windows SharePoint Services technology is that untrusted users can upload and create ASPX pages within the system on which Windows SharePoint Services is running. To prevent these users from arbitrarily adding server-side code within ASPX pages, Windows SharePoint Services provides a SafeControls list, which is a list of approved controls that they can use.

The SafeControls list is a list of controls and Web Parts specific to your SharePoint site that you have designated as safe for invocation on any ASPX page within your site. This list is contained in the web.config file in your Web application root.

To add your Web Part to the Safe Controls list

Open the web.config file in the application root.
Add a safe control entry for your custom assembly to the web.config file as follows:

[xml]

Step 5: Create a .webpart file for your Web Part

Every Web Part should have a .webpart file, which is an XML file that describes the Web Part. The .webpart file also makes your Web Part appear in the Web Part gallery. This procedure describes the easiest way to create a .webpart file.

To Create a .webpart file for your Web Part

After you have deployed your Web Part and registered it in the Safe Control list, navigate to http://myserver/_layouts/newdwp.aspx, where myserver is the name of the server on which your SharePoint site is deployed.
Select the check box next to MyWebPartLibrary.HelloWorldWebPart.

Click Populate Gallery and the Web Part is added to the Team Site Gallery.

Note:
To create a .webpart file for your Web Part, you can select Edit for the Web Part in the Web Part Gallery, and then click Export. You are prompted to provide a location in which to put the .webpart file.

Step 6: Add your Web Part to a Page

In this step, you import the Web Part to a page in any SharePoint site. The following procedure explains the steps for adding the Web Part to a page.

To add and test your Web Part

Navigate to the Web Part page on your SharePoint site where you want to add the Web Part.
In the Web Part page, click Site Actions, and select Edit Page.
In the Web Part zone where you want to add the HelloWorldWebPart, click Add a Web Part.
At the bottom of the Add Web Parts dialog box, click Advanced Web Part gallery and options.
Open the Team Site Gallery and drag the HelloWorldWebPart onto the page. The Web Part displays the SharePoint look and feel.

Presentation on SharePoint WebParts to Bellingham .NPresentation on SharePoint WebParts to Bellingham .NET Users Group ET Users Group

2008-07-03T03:59:00.000-07:00

Andrew Robinson, the president of the Bellingham .NET Users Group, invited me to give a talk to his group. I will be giving them a talk on "WebParts for SharePoint 2007" on Wednesday January 8, 2007 starting at 6:00 PM. Bellingham is the most visited city accross the border for British Columbians and I look forward to forging closer ties between .netBC and the Bellingham .NET Users Groups.

Here is the extract of my talk:

WebParts for SharePoint 2007

WebParts provide the fundamental building blocks for creating custom applications for SharePoint. This session will show you how to efficiently and quickly use your ASP.NET 2.0 and C# skills to develop WebParts for deployment into SharePoint 2007. Most of the development, testing and debugging will be done in Visual Studio .NET 2007. We shall then deploy the WebPart as a feature into Windows SharePoint Services 3.0 (WSS 3.0). We will also look at WebPart communication and modifying WebPart verb menus.

Wednesday January 9, 2008

The files that make up my presentation can be downloaded from here.

Thursday January 10, 2008

I had an enjoyable time at Bellingham. There were 13 people in attendance. Pizza was great and I was glad that they serve water instead of the dreaded pop.

FBA pointing to Active Directory

2008-07-03T03:54:00.000-07:00

SharePoint and ExCM can use any Membership provider for operations like authentication, add users, reset passwords. The .NET framework provides two membership providers out-of-the-box (ActiveDirectoryMembershipProvider, SQLMembershipProvider). You can use the ActiveDirectoryMembership provider to connect to AD or AD LDS (ADAM). MOSS 2007 comes with an an additional provider named LdapMembershipProvider which can be used to connect to AD via LDAP or other LDAP sources. However, not every provider supports the same operations and the AD/LDAP providers can be more difficult to implement.

When selecting a provider you also have to think about Role and Profile providers. SQL supports all three provider types. AD supports only membership and the LDAP provider supports membership and roles. This is the reason why most customer choose to implement SQL membership, because it is fully functional and scales well. Please take a look at some of the links below for more information...

General

(Authentication Samples)
http://technet2.microsoft.com/windowsserver/WSS/en/library/91035419-980e-4230-b3ae-67253b94af4a1033.mspx?mfr=true

(Plan authentication settings)
http://technet.microsoft.com/en-us/library/cc288081.aspx

(Forms based authentication in MOSS)
http://blogs.msdn.com/harsh/rss_tag_FBA.xml

(How to use Membership in ASP.NET 2.0)
http://msdn2.microsoft.com/en-us/library/ms998347.aspx

LdapMembershipProvider

(LDAP Membership Provider Class)
http://msdn2.microsoft.com/en-us/library/microsoft.office.server.security.ldapmembershipprovider.aspx

(Configure forms-based authentication against an LDAP data store in Office Project Server 2007)
http://technet.microsoft.com/en-us/library/cc197721.aspx

(Moss LDAP Membership Provider)
http://blog.hametbenoit.info/Lists/Categories/Category.aspx?Name=Security

(Using LdapMembershipProvider in SharePoint, and get it to work!)
http://www.sharepointblogs.com/rhulsman/archive/2006/12/12/using-ldapmembershipprovider-in-sharepoint-and-get-it-to-work.aspx

ActiveDirectoryMembershipProvider

(Active Directory Membership Provider Class)
http://msdn2.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider.aspx

Alternate Access Mappings

(Plan alternate access mappings)
http://technet2.microsoft.com/windowsserver/WSS/en/library/c8ccffce-5162-46af-a3ef-1d7914e8efee1033.mspx?mfr=true

(Configure alternate access mapping)
http://technet2.microsoft.com/windowsserver/WSS/en/library/8642f748-f169-4799-8fe9-8140fbb23fbf1033.mspx?mfr=true

Office SharePoint Server 2007 - Forms Based Authentication (FBA) w/MySites Walk-through - Part 2

2008-07-02T06:08:00.000-07:00

As promised, here is part 2 of my series on hooking up Forms based authentication on a SharePoint 2007 site AND integrating your web application with MySites and the Personalization features of Office SharePoint Server 2007.

I am going to assume that you have read and gone through all of the steps in part 1 of the series. The steps below ARE dependent on part 1 and I will be making some references to it. If you have not gone through part 1, I encourage you to read this entire post before trying to implement the solution. There are quite a few caveats and very UNINTUITIVE steps. Since none of this is documented (to my knowledge), I have to say that since it is undocumented, it may be unsupported as well. What I can say for certain, that in my 2 or 3 support calls to Microsoft regarding this issue, I had given up on them helping me. Essentially I was told on more than one occasion that "it's not supposed to work" or "it does not work". Of course after those answers, I had to prove to myself that either it does work or support was right. They do after all claim that this is "pluggable" authentication, and other than the obvious features, like Office integration, or SharePoint Designer integration, I expected all of the functionality to work. The following is the fruit of my labor. As a side note, this effort, although it may seem simple after you go thru the steps, took me about 5 weeks of nights and weekends trying to get the sequence of steps and the steps themselves defined.

One major disappointing caveat is MySite search. Search works fine against the FBA site to which we have a "mirror" intranet version, like we do in our example, but unfortunately we do not have a Windows authentication version of each and every MySite. I guess we could, technically, but really, that's not going to happen. I have heard however, through a very reliable source that Microsoft is working VERY VERY hard on getting the SharePoint search crawler to be able to penetrate forms based authentication sites and just maybe, might have a solution in Q2. I am optimistic about this and can't wait, then we really have a fully searchable FBA solution.

So here goes...

Assumptions

Like any good assumer, I am going to list all of my assumptions here. If you think that anything is missing, please do let me know and I will update this list.

You have created and configured a Shared Services Provider (SSP) and can link to its setting page using either of the following two methods.
- Click on the Share Services Provider's link in the left navigation in Central Administration.
- Click on the Create or configure this farm's shared services link in the Office SharePoint Server Shared Services section of the Application Management tab in Central Administration, then select Edit Properties from the dropdown menu that appears when you hover over its name.
The SSP Administrative Site URL and the MySite Location URL are each on their own web applications.

It is possible and sometimes desirable for some to locate their MySite site collections within the same Web Application of the site to which they are associated. What I mean by this is that there are two very different ways in which to setup MySites and they are as follows. Let's pretend for the sake of conversation, that our site is www.microsoft.com.

Method #1 - The site www.microsoft.com is its own Web Application. In turn, www.microsoft.com/mysite is where the MySites site collection is located. The main benefit to this design is that since we are using FBA as our authentication method, the same cookie will work for both sites and we will not have to log into our MySite independently of logging into the main site. The main drawback is that MySites will now be created in the same content database(s) that the www.microsoft.com Web Application is using. This may be an issue when it comes to scaling and capacity planning. Chris Johnson has outlined the steps needed to produce this scenario here.

Method #2 - The site www.microsoft.com is its own Web Application. In turn, my.microsoft.com is where your MySites site collection is located. The main benefit to this is that MySites are stored in a separate Web Application and can be managed independently. The main drawback is that since we are using FBA as out authentication method, we will have to log into our MySite separately, the cookie will not be shared.

Microsoft's best practice dictates that you use Method #2, so that is what I have done in my walkthrough.
As indicated above, for the purpose of this post, my SSP Administrative Site URL is http://ossdev:23456/ssp/admin.
As indicated above, for the purpose of this post, my MySite Location URL is http://ossdev:23457.
You will NOT access the URL in the previous bullet until instructed to do so. This has the potential to create problems, so please resist the urge.
You will NOT click on the MySite link until instructed to do so. This also has the potential to create problems, so please resist the urge.

Update the Shared Service Provider Administrative Site's web.config File

The web.config file of the Shared Service Provider needs to be updated with the same information you placed into the web.config of your FBA web application.

Determine File Path to web.config.

Open Internet Information Services (IIS) Manager.
Expand Web Sites and select the Shared Service Provider's website, in my case, SharePoint_SSP_Default1 - 23456. Yours will most likely be different so be sure you select the right site.
Right click on the above website and select Properties.
Select the Home Directory tab.
In the Local path textbox take note of the entire string. This is the folder on the file system that contains the web.config for the http://ossdev:23456/ssp/admin web application. We will be updating this file next.
Open Windows Explorer and browse to the folder noted in step 5.
Make a backup copy of the web.config file.

Add Connection String

Add the following connection string snippet immediately above the tag. Be sure to replace the bolded text with the appropriate values from your environment.

AspNetDbFBADemoConnectionString" connectionString="Data Source=OSSDEV;Initial Catalog=AspNetDb_FBADemo;Integrated Security=True" />

Add Providers

Add the following membership provider and role manager elements immediately inside the element. Again, be sure to replace the bolded text with the appropriate values from your environment.

FBADemoMember">

AspNetDbFBADemoConnectionString">
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
applicationName="/"
requiresUniqueEmail="false"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
name="FBADemoMember"
type="System.Web.Security.SqlMembershipProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" />

FBADemoRole">

AspNetDbFBADemoConnectionString">
applicationName="/"
name="FBADemoRole"
type="System.Web.Security.SqlRoleProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" />
Save and close the web.config file.
Perform an IISReset and verify that you can still access the SSP.

Update the MySite Host Web Application's web.config File.

The web.config file of the MySite Host Web Application needs to be updated with the same information you placed into the web.config of your FBA web application.

Determine File Path to web.config.

Open Internet Information Services (IIS) Manager.
Expand Web Sites and select the MySite Host website, in my case, SharePoint_MySite_Default1 - 23457. Yours will most likely be different so be sure you select the right site.
Right click on the above website and select Properties.
Select the Home Directory tab.
In the Local path textbox take note of the entire string. This is the folder on the file system that contains the web.config for the http://ossdev:23457 web application. We will be updating this file next.
Open Windows Explorer and browse to the folder noted in step 5.
Make a backup copy of the web.config file.

Add Connection String

Add the following connection string snippet immediately above the tag. Be sure to replace the bolded text with the appropriate values from your environment.

AspNetDbFBADemoConnectionString" connectionString="Data Source=OSSDEV;Initial Catalog=AspNetDb_FBADemo;Integrated Security=True" />

Add Providers

Add the following membership provider and role manager elements immediately inside the element. Again, be sure to replace the bolded text with the appropriate values from your environment.

FBADemoMember">

AspNetDbFBADemoConnectionString">
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
applicationName="/"
requiresUniqueEmail="false"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
name="FBADemoMember"
type="System.Web.Security.SqlMembershipProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" />

FBADemoRole">

AspNetDbFBADemoConnectionString">
applicationName="/"
name="FBADemoRole"
type="System.Web.Security.SqlRoleProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" />
Save and close the web.config file.
Perform an IISReset and close all your browser windows, but DO NOT try and access this URL yet.

Assign FBA Admin User Personalization services permissions.

Remember in part 1, we created a handful of FBA users. One of those users (spadmin) was created to be used as an administrator for our FBA site. We are going to re-use that user here to manage the SSP once we "flip" it to Forms Authentication. Yes, that's right, we are going to switch the authentication method of our SSP Administration site to Forms! How else did you think it would wok with FBA users? Ideally, you should probably go and create another user for this, maybe sspadmin or something similar.

Browser to your SSP Administration Site.
Click on Personalization services permissions in the User Profile and My Sites section.
Click on the Add Users/Groups link.
Type spadmin into the Users/Groups textbox and click the Check Names button , watch SharePoint resolve the user, then check all of the permissions and click Save. This will ensure that when we make the switch to Forms Authentication on the SSP site, that our FBA admin user will actually be able to perform the operations listed here.
Perform an IISReset and close all your browser windows.

Switch Authentication Providers for SSP and MySites

Click on the Authentication providers link in the Application security section on the Application Management tab in Central Administration.
Verify that the SSP Web Application is selected in the Web Application dropdown in the top right hand corner of the page.
Click on Default.
Select Forms as the Authentication Type, and enter the appropriate values for the Membership provider name and the Role manager name as they exist in this web application's web.config, then click OK.
Perform steps 1 to 4 again for the MySite Web Application.

Update Site Collection Administrator for SSP and MySites

We now need to update the Site Collection Administrators of the SSP and MySite host so we can go make some more changes.

Click on the Site collection administrators link in the SharePoint Site Management section of the Application Management tab in the Central Administration.
Switch the Site Collection dropdown to the SSP admin Site Collection. Remember, you may have to switch the Web Application to get the correct list of Site Collections (this is done in the popup). I know of some people who are not too fond of this user interface, myself included). Notice that since we switched the Authentication Type of our SSP to Forms, we will see a squiggly under the Windows account that was previously the Site Collection Administrator.
Delete the squigglied name (is that a word?) and replace it with spadmin, the FBA admin user we discussed earlier. Click the Check Names button and watch SharePoint resolve the FBA admin user, then click OK.
Repeat steps 1 to 3 for the MySite Host Site Collection.

Assign My Site Host Permissions to FBA Users

The following steps were the most unintuitive steps ever, in my opinion, and if anyone can tell me why it is required for FBA/MySite integration, but not for Windows/MySite integration I would love to know. That said, here are the steps.

Browse to your SSP Administration site.
You will be prompted with the standard out of the box FBA login form. Log in as spadmin.
Click on the My Site settings link in the User Profiles and My Sites section on the SSP Home page.
Click on the My Site Host Permissions link in the loft navigation.
You will be prompted with the standard out of the box FBA login form. Log in as spadmin. You will be directed to the People and Groups page.
Click on the Site Permissions link in the left navigation.
Click on Add Users under the New menu item.
Add the 3 roles we created in part 1, Administrator, Manager and Employee. Ideally we would have created a role that holds all of the FBA users (maybe call it Everyone). Had we done that in part 1 (we did not and I apologize), we would only have had one role to add here and so long as we always assigned new users to the Everyone role we would never have to come to this page again. As it stands now, if we were to create another user and place them in a new role, they would not be able to create a MySite. I think you get my drift here. Give them Read permission directly and click OK.

Actually, doing this doesn't actually give users permission to create a MySite, but permission to use the MySite Host site should they already have the permission to create a MySite. The next section will grant users permission to create MySites.
Close all your browser windows.

Grant Personalization Services Permissions

The next set of steps, as mentioned above is to grant our FBA users the appropriate permission to allow them to create MySites and use the personalization features of Office SharePoint Server 2007.

Browse to your SSP Administration site.
You will be prompted with the standard out of the box FBA login form. Log in as spadmin.
Click on the Personalization services permissions link in the User Profiles and My Sites section of the SSP Home page.
Click on the Add Users/Groups link.
Type Administrator;Manager;Employee into the Users/Groups textbox and click the Check Names button , watch SharePoint resolve the roles, check only the Create personal site and Use personal features permission, and click Save. This grants these roles the permission to create a MySite and to use the personalization features.
Your screen should resemble the following screen shot.
Perform an IISReset and close all your browser windows.

Assign Roles to Default Reader Site Group

Ideally, we don't want users to have to assign other users Read permission just to view the public areas of their MySites. When using Windows authentication, the default is to allow all authenticated users to read other users MySites. Such a group does not exist when using FBA. Had we created some sort of Everyone role, as suggested earlier in this post, in part 1 of the series, we could have leveraged that role, however, since we did not, we will have the same scenario as before manifest itself should we decide to add a new role in the future, after making the following changes. So lesson learned #1 would be to create an Everyone role in your role manager and place all of your users in it.

Browse to your SSP Administration site.
You will be prompted with the standard out of the box FBA login form. Log in as spadmin.
Click on the My Site Settings link in the User Profiles and My Sites section on the SSP Home page.
Scroll down to the Default Reader Site Group section and type or append Administrator; Manager; Employee into the textbox. You can leave NT AUTHORITY\authenticated users in the textbox or remove it, it does not matter at this point, then click OK.
Close all your browser windows.

Test You Solution!

Remember, I made allot of assumptions at the beginning of this post. One of those assumptions was that you had completed part 1 of this series. Under the assumption that you have completed part 1, test your solution using these steps.

Browse to http://fbaextranet.attis.org and first login as spadmin. You should see a My Site link in the top right hand corner of the page. DO NOT CLICK ON IT YET.
Verify that the Employee role is in the pre-created Visitor SharePoint group and that the Manager role is in the pre-created Member SharePoint group (I have to assume you know how to do this!).
As I mentioned earlier, since we set our My Site Host site collection up on a separate Web Application than our website, we will need to log to our My Site independently of this site. You may now click on the My Site link!
Login as spadmin and watch the MAGIC!
Check it out!
Close your browser, open a new one and browse to http://fbaextranet.attis.org again.
Login as Employee1. You should see a My Site link in the top right hand corner of the page. Remember, this user was created in part 1. Click on the My Site link, logon as Employee1 and again, watch the MAGIC!

Caveats

Of course, this solution has a couple of caveats. The biggest issue I have come across is Search. At present time, the crawler simply cannot deal with Forms Authentication yet. This is not a problem for the main website as the crawler simply enters through another zone. The following TechNet article explains how the crawler interacts with multiple zones and authentication modes in great detail. I encourage you to read it. With that said, MySite Search does not work OOB (I say OOB because I am sure someone will come up with a clever solution at some point) because all of the MySites lie behind Forms Authentication.

Now go forth and integrate your Forms Authentication Solutions with MySites and your SSP's. it will be interesting to see if there is going to be a supported or documented solution put forth by Microsoft. I guess we will just have to wait and see!

Office SharePoint Server 2007 - Forms Based Authentication (FBA) Walk-through - Part 1

2008-07-02T06:07:00.000-07:00

A while back a client asked me to set up Forms Based Authentication (FBA) for them. I said sure (of course) and started to research the steps required to accomplish this. In my oodles and oodles of research I had found many useful but somewhat partial posts. What I mean by this is that not one of the posts I have encountered in my research had ALL of the steps required to get this to work, I was left to aggregate steps from different areas. Most posts assumed you were running as an administrator, maybe even that your SharePoint application pools were running as system accounts with unlimited privileges (on both the operating system and in the database), no "real world" scenarios if you will. Also, all of the posts never made mention of Office SharePoint Server, they all centered around Windows SharePoint Services (more on that later). My aim here is to provide a series of posts that include the following:

Each and every step required to setup FBA using the built in Asp.Net Membership and Role providers (Part 1). I will demonstrate one way to accomplish this. There are others and they will be mentioned, but not looked at in any detail.
How to enable MySites and the Personalization features included with Office Server and have them actually work with a site using (FBA).
A natural extension of 1 and 2 that will demonstrate how to hook into the ADAM membership provider, and get it functioning with MySites and the Personalization features as well.

Initially, after setting FBA up successfully (Part 1), my client then asked me to enable MySites. That's when all hell broke loose. Not only did this not work right away, but after 3 unsuccessful calls to Microsoft support (they could not get it to work and kept parading me in circles, and still are for that matter, maybe they will read this and call me back), and quotes from Microsoft employees saying "it's not supposed to work" or "it does not work", I am pleased to say that it does in fact work and I will show you how (Part 2).

Before we begin I have to say that since I have been told that "it's not supposed to work" or "it does not work", and since I have not found any reliable documentation indicating how to do this, I must add a disclaimer that if it does not work for you, something is different between our environments, or to please call Microsoft . I will do my best to be as detailed as possible about my environment and all of the steps involved. If anything is unclear, please leave a comment and I will do my best to make it a little clearer. One last thing I would like to mention is that I have successfully implemented MySite functionality as well as the other Personalization features of Office SharePoint Server 2007 with Forms Authentication using both the built in Asp.Net Membership and Role providers as well as with an ADAM Membership provider. I have recently received an ADAM Role provider from Adam Buenz and plan on testing that soon but fully expect it to integrate seamlessly (with his help if needed, I hope).

So here we go, this is going to be a long one so bear with me. In the end of the series you will have MySite and the Personalization features working seamlessly with Forms Authentication in your Office SharePoint Server 2007 environment! Good Luck!

One assumption I have made in this process is that you have already created a Shared Services Provider and started the Office SharePoint Server Search service. Also, I am logged on to the development machine as a domain administrator. The term browser in this series means Internet Explorer 7. All of the below steps are to be performed on the Guest machine.

Environment

My environment is as follows. Keep in mind that any variation from this could produce different results. Again, if I forget to mention something obvious, please let me know and I will update the list.

Host Machine

Intel(R) Pentium(R) M processor 1.86GHz 1.86GHz
2.00 GB of RAM
Microsoft Windows XP Professional, Version 2002, Service Pack 2
VMWare Workstation, Version 5.5.3 build-34685

Guest Machine

Intel(R) Pentium(R) M processor 1.86GHz 1.86GHz
1.00 GB of RAM
Microsoft Windows Server 2003, Standard Edition, Service Pack 1
Active Directory (Domain Controller)
Microsoft SQL Server 2005, Service Pack 1
Microsoft Visual Studio 2005
Microsoft Office Server 2007, Version 12.0.0.4518

FBA User & Role Store

Database Creation

We need a place to put our users. The Asp.Net 2.0 Membership and Role providers include a database. The steps to install the database are as follows:

Open up a command prompt by clicking Start...Run, then typing cmd and pressing Enter.
Switch to the Asp.Net 2.0 Framework directory by typing
cd c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
and pressing Enter.
Type aspnet_regsql to launch the ASP.NET SQL Server Setup Wizard.
Click Next.
Choose Configure SQL Server for application services (the default choice) on the Select a Setup Option screen and click Next.
Specify the SQL Server name (your machine name), database name to create (I used AspNetDb_FBADemo), and the credentials to use for this process (database creation). I generally prefix my Membership and Role provider databases with AspNetDb_ such that they appear together in Microsoft SQL Server Management Studio and are easily identifiable should I need to access them, such as to update Security (Step 10). Click Next.
Confirm your settings on the Confirm Your Settings screen and click Next.
The process takes a few seconds and then The database has been created or modified screen appears. Click Finish to close the wizard.
Open Microsoft SQL Server Management Studio and confirm that the database was successfully created.
One step that I have not seen mentioned ANYWHERE is to make sure that the account that is running the application pool that will be used by the sites you create below have access to the database we just created. This step is critical as SharePoint will NOT be able to find your users and roles if it does not have the permissions to look for them. This step is what I like to refer to as the MAGIC step that no one tells you about, so I am ruining the surprise and telling you the secret. You will thank me later.

User and Role Creation

Microsoft has given us a great database schema to use as a membership and role provider data store but has not really supplied a "good" tool to manage its contents. When you think about it, this actually makes sense. The providers are intended to be used by other applications so maybe one of the assumptions made was that the tools to maintain the users and roles will be provided by the applications that consume them.

Thankfully, the Microsoft Visual Studio 2005 team had the foresight to create a somewhat rudimentary web application to help us manage the membership and role provider data store. The caveat is that the tool must be launched from Microsoft Visual Studio 2005. You can immediately see that this is not a very good option for those that will be managing the users and roles, i.e.: real users of your application.

I will now walk you thru a set of steps to create a few users and roles that we will be using later.

Create a folder on your desktop called FBA Management Site.
Open Microsoft Visual Studio 2005.
Select File...Open...Web Site.
In the Open Web Site dialog, choose the File System icon on the left side of the dialog, then browse to and select the FBA Management Site folder created in step 1.
Click Open.
In the Solution Explorer, right-click on the web site and select Add New Item.
Select Web Configuration File and click Add. There is no need to rename the file, web.config is fine.
Replace the empty element with the following snippet. Be sure to replace both

Using the Active Directory Membership Provider with Forms Authentication in MOSS 2007

2008-07-02T05:05:00.000-07:00

Because MOSS 2007 supports the ASP.NET membership provider model there are new worlds in which SharePoint can tread that it has not be able to in the past. Specifically, MOSS 2007 represents a fantastic platform for the presentation of a public internet web presence. In fact, there is a site template that allows for the establishment of a public web site. In order to successfully present a public site, there are several considerations that had to be added to MOSS to enable this. Foremost is the degree of integration with ASP.NET 2.0 features. Specifically, for a internet web site that presents secure content, MOSS will support Forms authentication with ASP.NET 2.0 Membership and Role providers. Whenever there is an established Active Directory in the DMZ (as is becoming really populare for auditability, group and user membership and provisioning and management, etc.) MOSS can use Active Directory as its ASP.NET Membership provider store thorugh the ActiveDirectoryMembershipProvider found in ASP.NET 2.0.

Challenge: Allowing public internet users to connect to a public web site hosted in MOSS 2007 using Forms authentication and Active Directory as the information store

Solution: Configure MOSS 2007 to support forms authentication with the Active Directory Membership provider

Result: Users can now log into a public web site without NTLM prompts and using a custom login page and have their security credentials established using Active Directory

TODO: Determine if the full MOSS user profile is available. It seems that some of it is, but further testing and customization testing is required.

Implementation Details:

* Modify the web.config of the site collection
o For the specified site collection which should use Forms/Active Directory authentication (assuming you have already created a Web Application and an Site Collection), browse to and open the web.config (This file can be found by interrogating the IIS web site for the web application's virtual directory home directory)
o Insert the following sesctions into the web.config
+ After the configSections section insert the following (be sure to replace the ldap string with a valid one for your domain)

LDAP://win2003eebase.charrandev.com/CN=Users,DC=charrandev,DC=com
name="ADServices"/>

+ In the system.web section insert the following (note the version of the ActiveDirectoryMemberShipProvider class found in the GAC by looking at c:\Windows\Assembly)

o Do this for the default SharePoint Administration Site as well. This will allow you to add the first site collection administrator.
+ Note the attributeMapUserName attribute because it allows you to enter just the username and not the UPN (format of account@domain.com)
* Go To SharePoint Central Administration and change the Authentication Provider for the Web Application
o In SharePoint Central Administration, select Authentication Providers under Applation Management's Application Security section.
o Click the Defaul provider and modify the authentication Type to be Forms authenitcation (make sure you have the right web application selected)
o Enable anonymous access and specify the name of the provider we placed into the web.config file (in this case "ADProvider")
o For public sites, I usually disable client integration
o Go to to the site collection administrators on Aplication Management and select the first administrators for the site from the domain specified in the ldap connection string of the ADProvider

You should now be able to visit the site and get prompted for forms authentication based on a standard login form that MOSS/WSS maintains for forms authentication. Ostensibly, you can modify this page, or supplant another page using SharePoint Designer 2007.

SharePoint and Microsoft Learning Gateway Links/Resources

2008-07-02T04:59:00.000-07:00

-on (Free)

SharePoint Learning Kit

www.codeplex.com/slk

Microsoft Learning Gateway Refresh

www.codeplex.com/lg

Advanced Wikis, Blogs,

www.codeplex.com/cks

Community Kit for SharePoint Education (Site Template)

http://www.codeplex.com/CKS/WorkItem/View.aspx?WorkItemId=1463

Moodle WebParts for SharePoint

www.codeplex.com/Moodle2003WP

Education SharePoint add-ons (Purchase)

Course Builder VLE

www.sharepointlms.com

Scholaris VLE for SharePoint (available from Ergo

www.ergo.co.uk

Provisioning tool for SharePoint Learning Kit and other VLEs. Information pulled from MIS System

www.salamandersoft.co.uk

SharePoint/Education Website

Microsoft UK Education Site

http://www.microsoft.com/uk/education/

Microsoft Schools Blog

http://blogs.msdn.com/ukschools/

Microsoft Education

http://www.microsoft.com/education

Microsoft Education Test Drive Website

http://www.microsoft.com/education/testdrive/

Live@Edu

http://my.liveatedu.com/

Microsoft Learning Gateway

Introduction to Microsoft Learning Gateway

http://www.sharepointblogs.com/ajp/archive/2007/12/19/introduction-to-the-microsoft-learning-gateway.aspx

Microsoft Learning Gateway Website

www.learninggateway.net

Demo Sites
Community Kit for SharePoint: Education

http://sharepoint.microsoft.com/sharepoint/cks/se-alpha

Microsoft Demo Site for Education

http://www.runaware.com/microsoft/en-us/edu/td

Case Studies

Shirelands Collegiate Academy

http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=201511

Long Eaton School

http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000000162

Leeds Learning Gateway

http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000001225

Other Education Case Studies from Microsoft

http://www.microsoft.com/casestudies/search.aspx?IndTaxID=1570

Twynham School

http://www.sharepointblogs.com/files/folders/ajp/entry12906.aspx

Resources

Resources for Education: Microsoft SharePoint

http://www.sharepointblogs.com/files/folders/ajp/entry14774.aspx

Learning for the Future: A Vision of Connected Learning Communities. Microsoft document on BSF and the Microsoft Learning Gateway

http://www.sharepointblogs.com/files/folders/ajp/entry15753.aspx

Building Schools for the Future Showcase

http://www.microsoft.com/uk/education/building.mspx

Connected Learning Gateway: BETT Presentation

http://download.microsoft.com/documents/uk/publicsector/ppt/Connected%20Learning%20Gateway.ppsx

Industry Insiders Blog on SharePoint Learning Kit

http://blogs.technet.com/industry_insiders/pages/introduction-to-scorm-and-sharepoint-learning-kit-slk.aspx

Videos

Shirelands Learning Gateway

http://www.microsoft.com/casestudies/resources/Files/201511/Shireland_Learning_Gateway_in_Action_1500k00.wvx

Long Eaton

http://www.microsoft.com/casestudies/resources/Files/4000000162/LongEatonOfficeandVistainAction384k.wvx

BSF Showcase

http://download.microsoft.com/documents/uk/education/bsf/BSFShowcaseTrailer.wmv

The Future

Silverlight Coding

New Line Learning Showcase at BETT

http://www.sharepointblogs.com/ajp/archive/2008/01/17/silverlight-with-sharepoint-and-excel-for-education.aspx

The Revolution in Education: A personal statement on the future of IT in Education

http://www.sharepointblogs.com/ajp/archive/2008/02/27/the-it-revolution.aspx

Interfarm Shared Services

2008-07-02T04:58:00.000-07:00

Overview

If Intra-farm shared services are web apps consuming from SSPs within the same farm, then Inter-farm are web app(s) consuming from SSPs outside the farm. (MSDN:Shared Services Overview) (TechNet:Plan Shared Services Providers). Because of the WAN limitation, (can't consume SSP across the WAN) many people discount a solution with more than 1 farm. Before you dismiss this whole post, consider this... It really isn't that strange to create 2 farms in the same region... Why you may ask... You may decide that you want to do collaboration with Out of the box functionality maybe some custom master pages and layouts, but pretty much no custom assemblies or custom site defs or web parts. On the other farm, you create your Intranet Portal with custom web apps for your business and it becomes much more application centric. Sean Livingston has put together a service offering white paper focused on hosting customizations that we should be sharing as soon as we can get it published.

Let's say you have a few web apps, quite a bit of content. (Don't waste your time with this if you have one web app.)

Why have the SSP in a separate farm? (Sam from MSW is a fan.)

1. If you have Multiple farms then it consolidates management for Search, Profiles, My sites, etc...

2. Can reduce number of servers and disk space for Query. If high availablity of the site is important, but search isn't, you could save a bunch on disk space by having your Index/Query/WFE SSP farm all on one box thus reducing the storage needed on query since it would be on the same box. You could even use the same SQL environment for the 2 farms.

3. Politics - The SSP is a very hot commodity, by putting it in it's own farm you can optimize the disks, SQL, the management from top to bottom could then be managed in a vacuum. This doesn't have to make sense from a technical point of view to see how multiple groups could divide their farms then consume a common "enterprise search" experience.

What to avoid...

You may think, why not run Search in a separate farm with the Search SKU (Microsoft Office SharePoint for Search Standard or Enterprise) and have it provide shared services. Won't work. Both parent and child farms need to be the same SKU (hence same features).

What you may not know...

Excel services although it shows up as a shared service, it's basically config for the safe locations. The Excel services are still with the consuming farm for rendering and calc purposes.

Forms services are always on the front ends for rendering. There's actually no real way off offloading the forms rendering to an app server if you wanted to, but you can offload document conversions i.e. the document HTML transformation service.

Contrary to some rumors there is no magic latency calculation to consuming shared services over the WAN.

Some Additional Information

Some data from the multi farm Visio deployment docs. I noticed this doesn't come up in search. Guess our favorite Internet search engines like Live don't have Visio Ifilters.

Model: Office SharePoint Server Inter-Farm Shared Services

Snippet from the Visio (good stuff):

Shared Services Providers can be configured to provide services to multiple Microsoft® Office SharePoint® Server 2007 farms. Utilizing Shared Services Providers across farms:

Reduces the number of services that provide the same role.
Dramatically reduces hardware, resource, and network bandwidth use.

Centralize administration of Shared Services Providers.

· Intra-farm shared services are offered by a parent farm to one or more child farms [Joel: One to one or one to many relationship]

· A parent farm is configured to provide shared services to other child farms.

· Child farms are configured to consume shared services from the parent farm.

· A farm cannot be both a parent farm and a child farm. (Joel: This is not saying the same as Intra-farm)

Only one Shared Services Provider can participate in inter-farm shared services:

· Parent farms can only share one Shared Services Provider to child farms. However, a parent farm can include more than one Shared Services Provider for its own use (see Parent Farm left).

· Child farms can only consume services from one Shared Services Provider. However, a child farm can include more than one Shared Services Provider for its own use. (see diagram)

Shared services consumption for child farms can be reconfigured at any time (not true in SPS2003):

· A child farm can disassociate from a parent farm and be configured to either consume shared services from a different parent farm or use its own Shared Services Provider.

· Child farms can consume shared services from a parent farm when connected to the central network and then switch to consume services from its own Shared Services Provider when it is disconnected. Child Farm 3 (see diagram) illustrates a farm with a standby Shared Services Provider that is used when the farm is disconnected.

· Parent farms can be re-configured as stand-alone farms at any time. Parent farm administrators should alert administrators of affected child farms before reconfiguring the Shared Services Provider as a stand-alone Shared Services Provider.

The following limitations apply to Inter-farm shared services:

· Parent and child farms must reside within the same Active Directory forest. If the farms reside in different domains, there must be a trust relationship configured between the domains.

· Inter-farm shared services is not supported across a WAN. A child farm cannot be associated with a Shared Services Provider at a parent farm if the two farms are separated by WAN links.

· Parent farms must have all Office server products installed that are used by child farms. For example, if a child farm includes Microsoft Office Project Server, then Office Project Server must be installed on the parent farm for shared services to work correctly. If a child farm uses the [Enterprise] CAL of Office SharePoint Server, then the parent farm must also use the [Enterprise] CAL (as opposed to the [Standard] CAL).

Simulate Parent / Child relationship in SharePoint 2007 with Folders & Content Types

2008-07-02T04:56:00.000-07:00

One can create Parent / Child (A.K.A. Master / Detail) relationships in SharePoint 2007 by using lookups to reference a parent list from a child list. I will discuss another way of creating a Parent / Child relationship by adding a content type inside a folder.

We will create a parent / child relationship between company and employees. Here are our sample entities:

Company Parent (CompanyId, CompanyName)
Employee Child (Name, EmployeeId, Branch)

The strategy will be to make the "Company Parent" entity a folder which contains "Employee Child" items. To accomplish this we will create two new content types for each entity.

The "Company Parent" content type:

1) Site Actions ==> Site Settings ==> Site Content Types

2) Create

• Name: Company Parent
• Select parent content type from: Folder Content Types
• Parent Content Type: Folder
• Existing group: Custom Content Types
• Click OK

3) Click on "Add from new site column" on the "Site Content Type: …" page under column.

• Column name: CompanyId of type Number
• Click OK

NOTE: We will reuse the "Title" field to be the CompanyName.

The "Employee Child" content type:

1) Site Actions ==> Site Settings ==> Site Content Types
2) Create

• Name: Employee Child
• Select parent content type from: List Content Types
• Parent Content Type: Item
• Existing group: Custom Content Types
• Click OK

3) Click on "Add from new site column" on the "Site Content Type: …" page under column.

• Column name: EmployeeId of type Number
• Click OK

4) Click on "Add from new site column" on the "Site Content Type: …" page under column.

• Column name: Branch of type "Single line of text"
• Click OK

NOTE: We will reuse the "Title" field to be the EmployeeName.

Now we can go about our normal business of creating a custom list and using our two newly created content types "Company Parent" and "Employee Child".

1) Site Settings ==> Create
2) Click on "Custom List" under the "Custom Lists" column.

• Name: CompanyEmployees
• Click OK

3) Settings ==-> List Settings
4) Click on "Advanced Settings" under the "General Settings" column
5) At the very top, change Allow management of content types?" to Yes.
6) Click on OK
7) Under "Content Types" click on "Add from existing site content types".
8) On the "Add Content Types:" page

• Select site content types from: Custom Content Types
• Add "Company Parent" and "Employee Child" content types.
• Click on OK

Let’s add some dummy data.
1. Click on the "CompanyEmployees" list
2. Click on the little arrow beside New. You should see this:

3. Select "Company Parent"
4. Add the following bogus company data:

• Name: ACME Corporation; CompanyId: 123
• Name: Bogus Enterprises: CompanyId: 456

5. Add bogus company employees to "ACME Corporation"

• Click on "ACME Corporation". This causes the folder to open.
• Add the following employees to the ACME Corporation by clicking on New ==-> Employee Child:
• Title: Jane Doe; EmployeeId: 111; Branch: Downtown
• Title: James White; EmployeeId: 222; Branch: Airport
• Click on "Bogus Enterprises". This causes the folder to open.
• Add the following employees to Bogus Enterprises by clicking on New ==-> Employee Child:
• Title: Judy Black; EmployeeId: 333; Branch: Main Street
• Title: Brandon Wiley; EmployeeId: 333; Branch: Riverside
• Add another employee to ACME:

This concludes configuration and data entry. Let us now use the SharePoint 2007 Object Model to get at this data.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
public class CompanyEmployees {
static void Main(string[] args) {
SPSite site = new SPSite("http://srvr/");
SPWeb web = site.AllWebs["/"];
SPList list = web.Lists["CompanyEmployees"];

foreach (SPListItem order in list.Folders) {
Console.WriteLine("Company ID : {0}", order["CompanyId"]);
Console.WriteLine("Company Name : {0}", order["Title"]);

SPQuery empItemsQuery = new SPQuery();
empItemsQuery.Folder = order.Folder;
SPListItemCollection empItems = list.GetItems(empItemsQuery);
foreach (SPListItem empItem in empItems) {
Console.WriteLine("\tEmployee ID {0}: {1} {2}",
empItem["EmployeeId"],
empItem["Title"],
empItem["Branch"]);
}

}
}
}

The above application will produce the following result:

Company ID : 123
Company Name : ACME Corporation
Employee ID 111: Jane Doe Downtown
Employee ID 222: James White Airport
Company ID : 456
Company Name : Bogus Enterprises
Employee ID 333: Judy Black Main Street
Employee ID 444: Brandon Wiley Riverside

Microsoft Sharepoint and Widows Sharepoint Services

2008-06-26T21:16:00.000-07:00

Microsoft Sharepoint and Windows Sharepoint Services