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.
Thursday, July 17, 2008
Saturday, July 5, 2008
Connecting Web Parts in SharePoint Portal Server 2003, Part 2
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
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
A right mark will indicate whether the page is in design view as displayed below.
Friday, July 4, 2008
Creating a Basic Web Part
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 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:
C#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.
Copy CodeStep 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.
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. |
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.
Thursday, July 3, 2008
Presentation on SharePoint WebParts to Bellingham .NPresentation on SharePoint WebParts to Bellingham .NET Users Group ET Users Group
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
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
Wednesday, July 2, 2008
Office SharePoint Server 2007 - Forms Based Authentication (FBA) w/MySites Walk-through - Part 2
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.
- Click on the Share Services Provider's link in the left navigation in Central Administration.
- 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
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
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
Subscribe to:
Posts (Atom)