History of portals Key Share Point Features 1. Understanding Business Scenarios 2. Augmenting Personal Productivity 3.

Increasing Team Productivity 4. Supporting Remote Workers 5. Integrating with partners and customers 6. Analysis and design consideration 7. Documenting the business vision 8. Documenting policies and practices 9. Allowing external activities 10. Managing content Server Requirements Prerequisites SPS Controller 1. Microsoft windows server 2003, Enterprise edition 2. Active directory 3. Microsoft Exchange 2003 SPSPortal
1. Microsoft windows server 2003, Enterprise edition(with all update pack)

2. Microsoft 3. Microsoft 4. Microsoft 5. Microsoft SPSClient

Office 2003, Including InfoPath and Front page Visual studio.Net 2003 Sql server 2003 (with sql server service pack 4) Sharepoint Portal server 2003(with service pack)

1. Microsoft Windows XP Professional 2. Microsoft office 2003, Including InfoPath and Front page SharePoint Services

SharePoint Portal Server Web components Index Component Search Component

Job Server

Site and Sub sites

W O R K S P A C E S

M S O F F IC E

Web Sites

Lists

SharePoint Services

Document Repository

Custom Web Parts for SharePoint Portal 2007 Developing and Deploying Custom Web Parts for SharePoint Portal 2007 Overview and difference with SPS 2003: Developing Web Part for SharePoint Portal 2007 is different as compared to developing for SPS 2003. Web Parts Developed in .Net 1.1 for SPS 2003 used the SharePoint.WebPartPages namespace, however the Web Part in ASP.Net 2.0 is found under the System.Web.UI.WebControls.WebParts. Development of Web Part in VS 2005 To Get Started with creating Custom Web Part for MOSS 2007 in Microsoft Visual Studio 2005, Open the IDE and create a new C# project, Select Class Library as Project Type. Name It as NewWebPart.

Add a reference to the System.Web from .Net components into the project. The System.Web dll contains the required namespace of System.Web.UI.WebControls.WebParts .

In The Project explorer view rename the Class1.cs with NewWbPart.cs to be consistent with this example; this will result in renaming the Class name as well. With the help of using keyword include the namespaces as shown in the code example below. Derive / Extend the NewWebPart Class from the WebPart Class ( System.Web.UI.WebControls.WebParts.WebPart), and add the code as shown below. The CreateChildren Control is same as in .Net 1.1, that it would create and add controls to this Web Part Class,. In this case I have only added a WebControl.Calender Object. The RenderControl Method is an override for the WebPart Base Class and calls the RenderChildren Method, this causes the Children Controls to be rendered on the Particular HtmlTextWriter passed as a parameter to the method. using System; using System.Collections.Generic;

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

namespace NewWepPart { public class NewWebPart : WebPart { protected override void CreateChildControls() { Calendar cldr = new Calendar(); cldr.Enabled = true; cldr.ShowGridLines = true; cldr.ShowTitle = true; cldr.EnableViewState = true; cldr.SelectedDate = DateTime.Now; ? Controls.Add(cldr); ?

public override void RenderControl(HtmlTextWriter writer) { RenderChildren(writer); } } } Build the project and on successful built you are ready to Deploy the Web Part to the Portal Site.

Deployment of Web Part: In order to deploy a web part to a SharePoint portal 2007 site, we must have the URL of the site to which we want our web part needs to be deployed (displayed in fact). As it is mentioned earlier that the Web Parts developed in .Net 2.0 environment does have a .CAB project , instead an assembly is created on build of project. Now there are two choices to deploye the assembly to the SharePoint porta directory.

Deploy the assembly to the Assembly Folder (GAC) (requires the assembly to be stron named). Put the assembly to the bin folder of the portal directory.

For the sake of simplicity, the later choice is being demonstrated in this example. Putting Assembly in Bin Folder: The MOSS 2007 creates every portal in the inetpub\wwwroot\wss folder. The easies way to find the bin folder from these folder hierarchies is to go from inetmgr console. Locate the appropriate portal (for which u want to deploy the web part), identified with the port number. Right click and have Properties. Under the Home Directory Tab, note the path in Local path text box. Verify if the bin folder exists in the specified path by opening it in browser. If the folder doesnt exist then create one. Now copy the assembly form the project output folder and paste it in bin folder of portal.

However there is another work around for putting the assembly in to the portals bin folder again ad again each time the Web Part Project is built with changes. Right click on the project name (NewWebPart) in the VS.Net 2005 IDE and click properties. Under the Build page paste the same path copied from inetmgr console into the Output Path. As shown in figure below. This will result in the lates assembly automatically deployed to the bin folder every time the project is built.

Adding the Safe Control Entry: Even though the assembly is present in the Portals Bin folder, there is another step required to make the Control (Web Part) assembly usable on the Portal Pages. Since the control will need to render on multiple machines in different browsers with as many user accounts as the organizations have. There is a need to declare the control as safe. To do so open the web.config file placed under the portals directory in the VS.Net 2005 IDE.

Then edit the file in the section of SafeControls, create a new SafeControl entry for our assembly as shown below. Save the file and close it.

<SafeControls> . . .

<SafeControl Assembly="NewWebPart" Namespace="NewWebPart" TypeName="*" Safe="True" />

</< SPAN></< SPAN>SafeControls>

Configuring Portal to use NewWebPart Since now the web part have been written and deployed to the desired portals directory. The next task is to use the web part on the Portals Site. The Web Part Deployed to the portal can be placed on any site within that Portal. For convenience this NewWebPart is demonstrated to be placed on the home page of default Portal. Open the portal site in the internet explorer; in this case http://oss1 is the URL for the default portal, ensuring that the current logged in user has the administrative rights on the portal site. To begin with, the first step is to add the newly deployed web to the Portals web part gallery, since the portal is using the configuration databases to keep record of the contents of the portal, our newly created web parts information doesnt exist in the database. We need to add the web part to the Web Part Gallery before we can use it. To do so, the following steps should be followed.
1. Click on the Site Actions button and then select Site Settings.

2.

On the site settings page under Galleries column click on the Web Parts.

On the Web Part Gallery Page click on the New button, to add the new web part assembly to the gallery.
3.

On the New Web Parts page locate the NewWebPart in the list, check the check box on the left and click on the Populate Gallery button the top of the page. This will result in the Web Part entry creation in the Web Part Gallery list, and hence it can be used from now on from the gallery. It can be notices easily that the Web Parts developed form the new Frame work of 2.0 have an extension of .webpart after their names. Whereas in earlier versions, it was a .dwp file. Both the .webpart and .dwp files are the XML definition of the Web Part.
4.

Until this step the web part is ready to be used on the site by selecting it from Web Part Gallery. Click on the Site Actions button on the page and then select Edit Page, this will modify the appearance of the page to enable the edit view. In this view Web Part Zones are highlighted so that a user can add a web part to the zone, Click on the Add a Web Part button in the left zone to add the Web Part.
5.

Select the NewWebPart from the web part list . it is found under the Misc section and then click on? Advanced Web Part gallery and options.
6.

In the? Add Web Part Pane at right , select Home Gallery and then drag the NewWebPart from the pane into the Web Part Zone.
7.

Click on the Exit Edit Mode link on the page and the site will return to the view mode.
8.

Installation Installing a New Microsoft Office SharePoint Server 2007 Portal: Stepby-Step Instructions In this post, I'll demonstrate with words and screen shots how to install and get working a portal using Microsoft Office SharePoint Server 2007. Installing this product is not difficult, but it does require some forethought and planning. You can use this post as a reference for getting your version of MOSS 2007 installed. You need to have downloaded the software from Microsoft's site. For information on how to do that, please go here. Once you have registered and downloaded the software, you're ready to start. First, you'll need Windows 2003 Server, fully patched and ready to go. I believe I've seen blog postings recently that indicate that you can install MOSS07 on a Vista server. I'll leave that discussion for other threads and posts. Once you have the operating system ready to go, you'll want to start by running the setup.exe for MOSS 2007. Figure 1 illustrates that after you start the installation process, you'll need to enter a valid product identification key code. This key code can be found on the download site and should have been a part of what you did to get the software in the first place.

Figure 1: Product Identification Key Code Input Screen After entering the product identification key code, click Continue. The next screen is the licensing agreement screen. Now, I always recommend that you read the licensing agreement since it is a legal document and you are bound by its' terms. But I also recognize that in the 10+ years I've been in this industry, I've never seen an agreement that I didn't agree with.............if you get my drift.

Figure 2: Licensing Agreement Screen. Be sure to select the "I accept the terms of this agreement" check box and then click Continue. The next screen will give you the chance to select which type of installation you wish to commit. The Basic installation is used for those who:

Need to install everything on a single server Do not need to grow into a multi-server farm Need a quick, easy deployment during installation with lead administrative effort

The Advanced option is selected by those who wish to install MOSS 2007 selecting some of the customizable features. In this illustration, we'll select the Advanced option and follow that route.

Figure 3: Installation Type Selection Screen After clicking on the Advanced button, you'll find that the selections default to StandAlone (Figure 4). However, we'll choose Complete. The meaning of the three options is as follows:

Complete: Enables all of the options for one server to offer the entire range of MOSS 2007 services and features to the network. You can scale out this deployment, start and stop services on this server and use a SQL server to host your databases.

Web Front End: Enables only those options that allows the server to run as a web front end server. What this means is that server is merely the entry and exit point (or one of them among the other WFE servers) for the farm. The actual servers that users will consume will be hosted on other servers (presumably). This cannot be the first choice of a farm unless you plan on installing other servers in the farm to offer the services and features that users will want to consume. Stand-Alone: Similar to complete, this option enables all of the services and features for the MOSS 2007 farm, but assumes that there is no SQL server, so the MSDE engine is installed locally on this server. You cannot scale out this server into a larger MOSS 2007 farm.

Note that in reality, all of the MOSS 2007 binaries are installed in all three choices. All these choices really do is (pragmatically, not technically) turn on and off the code that is required for the server to fulfill the functions that have been assigned to it. Note also that you can select the location where the binaries should be installed in the File Location tab and then sign up to give feedback directly to Microsoft if you'd like to do this. Make your selections, then click Install Now.

Figure 4: Server Type Selection Screen During the installation, you'll be presented with a status bar that is illustrated in Figure 5.

Figure 5: Installation Status Screen After installation has completed, you'll be given the chance to run through the SharePoint Products and Technologies Configuration Wizard (Figure 6). You'll use this wizard to commit the initial configuration options for your new SharePoint farm.

Figure 6: Entry screen to the SPPT Configuration Wizard. Note that you can come back to this screen using the Administration menus that automatically install with the SharePoint Server binaries One you start the SPPT wizard, you'll receive a pop-up box (Figure 7) that will inform you that certain services are going to be stopped. Be sure it is a good time to stop these services before moving on with the configuration options for your farm.

Figure 7: Informational Pop-Up Box The following set of screens in the SPPT Configuration Wizard are design to help you setup the farm. In Figure 8, you'll be able to create a new farm or join and existing farm. Farm membership, at the server level, is determined by which servers are using the same configuration database in SQL and which servers are not. In my illustration, I want to create a new farm, so I select the "No, I want to create a new server farm" radio button. If I had wanted to connect to an existing farm, I would have selected the other radio button.

Figure 8: Connect to a server farm configuration screen in the SPPT Wizard After making our selection in Figure 8 and then clicking Next, I'm taken to the next screen illustrated in Figure 9. On this screen, I can enter the following configuration values:

The SQL database server name. I'm not clear if this is the host name or netbios name, but I suspect this is the host name. However, you don't need the FQDN here, but you do need name resolution to this server or SQL Instance. The farm configuration database name is needed in the next input box. Note that the screen just asks for a name, but you need to understand you're entering the most persistent database name for the entire farm - the

farm configuration database name. Be sure this name supports your database naming convention. You should decide the name of this database in advance of getting to this screen

The database access account will need to be a member of the local admins group on each SharePoint server along with having db_creator and db_security permissions in SQL. I would suggest you have an account setup just for this purpose in your Active Directory and that you have a strong password associated with this account.

Figure 9: Configuration Database Settings Screen in the SPPT Wizard in Figure 10, you'll be asked to decide which type of security settings you want to use for your farm. First, you can specify a pre-selected port number for central administration to run on or you can allow the wizard to randomly assign a

port number. As you can see, this instance of the wizard randomly selected 17386 as the port number for Central Administration (CA). If you want CA to run on a different port, then select the check box and enter the desired port number. The issue of NTLM vs. Kerberos is one that you may at some point wish to consider. Do you want the CA application to run using NTLM (NT Lan Manager) for security authentication or Kerberos? If the latter, there are some special configurations you'll need to complete for your Active Directory (AD) before Kerberos will work. I'm finding that most administrators are happy with NTLM, though those in a larger and more secure implementations are increasingly using Kerberos. For purposes of my illustration here, I'm selecting NTLM.

Figure 10: Configure SharePoint Web Application configuration screen in SPPT Wizard

After you click Next, you'll be given a status bar that indicates how the SharePoint configuration is going. Depending on the type of server you're installing and the options you're installing, you could have as few as seven tasks or as many as eleven. Figure 11 illustrates the progress screen. Note that the caption below the status bar will inform you about the configuration actions that are being executed during this process.

Figure 11: Configuration status bar screen in the SPPT Wizard After the configurations have been executed and committed to the SQL Server database, we finally get to CA where we can further configure our farm. We can start and stop services (Figure 12) on this server and then create web applications. In order to have portal, you'll first need to start the Office SharePoint Server Search service and then create a Shared Services Provider (SSP). I'll start the search service.

Figure 12: Services configuration screen in CA When the search service is started, you're presented with another web page for search configuration administration that needs to be completed before the search service can start. The configuration options are pretty clear. Out of the shoot, you'll use this server for both indexing and servicing queries from users until you can get enough servers in your farm to quarantine those options in your farm. Select a location that has enough disk space for your indexes. You should plan on a space allotment of 20% relative to the amount of information you wish to index. You'll also need to input an email address, a service account and whether or not there is a dedicated WFE for all crawling activities. For now, in my illustration, since this is the first server in the farm, I'll accept the defaults and click OK.

Figure 13: Search configuration screen After starting the search service, the next thing I need to do is create a SSP. In order to do this, I'll navigate to the Application tab in CA, click Create or

Extend a Web Application, then click Create a New Web Application, then make the configurations necessary that you see in Figure 14. Most of this is pretty self-explanatory, so I won't go through each input in detail. Suffice to say that I've done two things not illustrated here. First, after creating this web application, I then web back into CA, selected the Create or Configure Core Farm Services, then selected New SSP (Figure 15) and then filled in the configuration information for the new SSP. All of the options on that page are self-explanatory, except that you must select an Index server for the SSP to operate. Backtracking just a bit, you can't have an Index server unless the Search services is started. So, that's why I illustrated starting the search services first, then creating an SSP, then creating a portal.

Figure 14: Configuring the new web application to host the portal

Figure 15: Illustration of the SSP management interface where you can select to create a New SSP. Once the SSP is created and the web application for the portal has been created, you can then create the portal. The way to do this is to navigate to CA and then click Create Site Collection. Be sure the http://portal is selected in the drop down list in the upper right-hand portion of the screen (Figure 16). Note that on this screen, you'll need to ensure that you are creating the site collection at the root by selecting the "Create Site at this URL" where the URL path is "root", not in the Sites managed path. Also, if you scroll down, you'll need to select the Corporate Intranet Site under the Publishing tab. Microsoft has renamed the

Portal to Corporate Intranet Site and placed it under the Publishing tab for web content publishing purposes. BTW, even though I don't illustrate it here, be sure to give the site a title.

Figure 16: Create Site Collection Screen

At this point, you should now have a new portal, ready to aggregate, organize and present content for your enterprise, division or department.