Sharepoint Interview Questions - 1

Q1. What are the various Sharepoint 2003 and Exchange integration points?
Ans.

Link to Outlook: This is a button on contacts or events lists that lets Outlook 2003 add a pst file named Sharepoint Folders and it links to the data on the site. It’s read-only, but you could make the home page for that PST be the Sharepoint site for easier viewing. The link to outlook feature seems more to be where some can public a calendar, but not want too much collaboration. For example, a holiday schedule, company meeting schedule, etc, can be made available for people to be able to view from Outlook without having to go to a web browser. Another nice thing about OL2K3 is that you can compare these calendars with others side by side.

Searching Public Folders: With SPS you can index Exchange’s public folders with the search engine so that all that precious public folder content is searchable. You’ll want to look at content sources and indexing in Sharepoint administration.

Displaying Public Folders in a web part: Since exchange web-enables public folders, you can create a web part that displays that content. IE, http://exchangeserver/Public/IT/Helpdesk will display the IT/Helpdesk public folder via OWA. So you add the Page Viewer web part to a page and point it at that URL. The key here is to add ?cmd=contents to the end of the url if you don’t want the navigator pane on the left.

Smart web parts: Some of the web parts that come with SPS allow you to add a web part to a page that actually takes the users outlook info (calendar, inbox, contacts, tasks) and put them into the page.

Q2. Can SharePoint compare two document versions?

Ans. "In Word 2003, you can compare documents side by side. Open two documents. Then, from the Window menu of one of them, select the Compare Side By Side command. If you have only two documents open, the command will automatically choose to compare them. If you have three or more documents open, you'll have to select which document to compare with the current file. A floating toolbar with two buttons will open. If the button on the left is selected, Word will scroll both documents at the same time. Press the button on the right side of the toolbar to return to where the cursor was located when you started comparing."

Q3. What are the integration differences between SPS 2003 and the various Office versions?

Ans. SPS webpage can detect you have installed the Office 2003 and run local dll to implement some SPS function, e.g. multi-file upload only works when you have office 2003 installed. Integration with Office XP is gone.

You will get guys telling you that you can integrate with SPSv2 if you install a backwards compatible document library - but that’s really just putting a bit of SPS 2001 on the server. Believe me, check-in, check-out, which are themselves very basic, are not available from inside Office XP, or even from the context menu in Windows Explorer. The ONLY option you have is to use the web interface to check-in or check-out.

Q4. What is SharePoint from a Users Perspective?

Ans. From a Users perspective SharePoint is a way of making documents and folders on the Windows platform accessible over the web. The user visits the SharePoint Portal web page, and from there they can add documents, change documents & delete documents. Through this Portal, these documents are now available for discussion, collaboration, versioning and being managed through a workflow. Hence the name "Share-Point". Details about the document can be saved too, such as: who wrote it, when, for whom, its size, and version, category or target audience. These can then be used to find the document through SharePoint's Search facility. Even documents not "in" SharePoint can be included in the search engine's index so they become part of the portal. All in all, it's a great way to get stuff up on the web for users with average technical skills, and for administrators to manage the content.

Q5. What is SharePoint from an Administration Perspective?

Ans. Administering SharePoint mainly consists of setting it up, which is much easier than you expect, adding the content, which can be just dragging and dropping in whole directory structures and files, and then organizing the files better by giving them categories or other metadata.

This is done either through the Web interface or through the SharePoint Client: a program what means you can access SharePoint as a Web folder and then right-click files to select options like "edit profile". Or add files by dragging them in individually or in bulk.

Setting the security is also important, using NT accounts, either NT4 or Active Directory (or both in mixed mode) you can give users access to files/folders the same way as you do in standard Windows. Users can be grouped and the groups given access privileges to help manage this better.

Also SharePoint has 3 Roles that a User or Group can be given on a particular item. Readers can see the item (i.e. document/file or folder) but not change it, Authors can see and edit items and coordinators can set security privileges for the part of the system they have control over. Thus, you could set 12 different coordinators for 12 different folder trees, and they could manage who can do what within that area only.

Read more...

How to enable Discussions on the New Web Site

To use Web discussions on your SharePoint Portal Server computer from the Internet or extranet, you must modify the registry.

Use Web discussions to discuss a document with other users. Web discussions allow users to add remarks about a document without modifying the document itself. Discussions are threaded — replies to a discussion remark appear directly underneath the original remark. In addition, multiple discussions about the same document can occur at the same time. SharePoint Portal Server consolidates comments in a single location, allowing them to be easily reviewed.

To enable discussions on the new Web site:

1. On the taskbar, click Start, and then click Run.

2. Type regedit, and then click OK.

3. In Registry Editor, navigate to HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Office\9.0\Web Server\1

4. On the Registry menu, click Export Registry File.

5. Save the file as EnableDiscussions on your desktop.

6. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Office\9.0\Web Server\1.

7. Right-click 1 and then click Rename.

8. Type number and then press ENTER. Number is determined from the following procedure:

- On the taskbar, click Start, point to Programs, point to Accessories, and then click Command Prompt.

- Navigate to the directory where adsutil.vbs is located. Typically, this is in the Inetpub\AdminScripts directory on the operating system drive.

- Type cscript adsutil.vbs enum W3SVC/number, where number is 1, 2, etc. Type each number in order until the properties display the name of the new Web site. Typically, W3SVC/1 is the Default Web Site, W3SVC/2 is the Administration Web Site, and W3SVC/3 is the new Web site. If W3SVC/3 is the new Web site, you type 3 as number when renaming the registry key in this step.

9. Click Web Server.

10. On the Registry menu, click Import Registry File.

11. Import EnableDiscussions that you saved to the desktop previously.

12. Click OK.

13. Click 3, right-click Server Root Url in the right pane, and then click Modify.

14. In Value data, type the external FQDN of the server, and then click OK.

15. Close Registry Editor.

16. Restart the server.

Read more...

Create and Use a Data Connection Library

A Data Connection Library (DCL) in Microsoft Office SharePoint Server 2007 is a library that can contain two different types of data connections: an Office Data Connection (ODC) file or a Universal Data Connection (UDC) file. Microsoft Office InfoPath 2007 uses data connections that conform to the Universal Data Connection (UDC) file schema and typically have either a *.udcx or *.xml file extension. Data sources described by these data connections are stored on the server and can be used in standard form templates and browser-enabled form templates.

Procedures: Uploading data connection files to a Data connection library allows InfoPath form templates to use the data sources described by these files to retrieve and submit information.

To Create a SharePoint Data Connection Library:

- Browse to an Office SharePoint Server 2007 or Office Forms Server 2007 site on which you have at least Design rights. If you are on the root site, or portal, go to the Document Center or create a new site before proceeding to the next step.

- Click Create on the Site Actions menu.

- On the Create page, click the Data Connection Library link in the Libraries section.

- On the New page, type a name for the library and click the Create button.

- Copy the URL of the new library.

To Create a New Data Connection File in InfoPath:
- Open Office InfoPath 2007 and click Design a Form Template.

- On the Design a Form Template dialog box, click Blank and click OK.

- On the Tools menu, click Data Connections.

- Click the Add button.

- In the Data Connection Wizard, click Create a new connection to and Receive data.

- Click Next.

- Click the type of data source you are connecting to, such as Database, Web service, or SharePoint library or list.

- Click Next.

- Configure your data connection as needed to retrieve data. Once the Data Connection Wizard is completed, choose this data connection in the Data Connections dialog box.

- Click Convert.

- On the Convert Data Connection dialog box, enter the URL of the data connection library that you previously copied.

- Delete "Forms/AllItems.aspx" in the URL.

- Enter a name for the data connection file at the end.

- Click OK.

- Confirm that the data connection has been converted successfully by examining the Details section of the Data Connections dialog box while the converted data connection is selected.

- Browse to the SharePoint data connection library and, if necessary, Check In and Approve the UDC file created.

To Use a Data Connection File in InfoPath:
- Open Office InfoPath 2007 and click Design a Form Template.

- On the Design a Form Template dialog box, click Blank and click OK.

- On the Tools menu, click Data Connections.

- Click the Add button.

- In the Data Connection Wizard, click Search for connections on a Microsoft Office SharePoint Server and click Next.

- Select the site where you created a data connection file, and select the data connection.

- Click Next.

- Continue configuring the data connection as needed for the type of connection you have selected.

- When finished, add some controls to the form and Preview the form to ensure that data is returned.

To Manage Data Connection Sites:
- Open Office InfoPath 2007 and click Design a Form Template.

- On the Design a Form Template dialog box, click Blank and click OK.

- On the Tools menu, click Data Connections.

- Click the Add button.

- In the Data Connection Wizard, click Search for connections on a Microsoft Office SharePoint Server and click Next.

- Click the Manage Sites button.

- On the Manage Sites dialog box, click the Add button.

- Enter the URL of the site containing one or more data connection files, and enter a friendly Display name for the site, if desired.

- Click OK, then click Close.

- You can now select the site from the Site drop-down box to browse the available data connections located on the site.

Read more...

Data Connections, Authentication, and Alternate Access Mapping

Using data connections in browser-enabled InfoPath form templates introduces some potential manageability and authentication issues that you should consider. These issues can be addressed by using Universal Data Connection (UDC) files to abstract the data connection information from the form template, by using Office Single Sign-On (SSO) services to handle authentication issues in multi-tier architectures, and by using the Web service proxy available with InfoPath Forms Services.

Universal Data Connections: Windows SharePoint Services includes support for a Data Connection Library (DCL), which is a library that can contain two different types of data connections, Office Data Connection files and Universal Data Connection (UDC). Microsoft Office InfoPath 2007 uses data connections that conform to the Universal Data Connection (UDC) file schema and typically have either a *.udcx or *.xml file extension. Different data sources can be described by these UDC files, which are stored on the server and used in standard form templates and browser-enabled form templates.

Using a UDC file located in a data connection library has the following benefits:
- Form designers can configure form template data connections that will work in both the InfoPath client and InfoPath Forms Services.

- Form designers can publish a form template to multiple servers and have different data connection settings for each server without modifying the data connection information in the form template.

- Form designers can publish a domain security form template that can access data sources in a different domain.

- Administrators can redirect data connections without modifying form templates that reference the UDC file.

- Administrators can designate which connections are approved for cross-domain access.

- Administrators can publish data connections on a single server which can be shared across multiple servers.

Form templates are always designed against UDC files in a data connection library, but the connection can be configured to use a centrally-managed version of the UDC file. These centrally-managed UDC files are uploaded by a server administrator. To centrally manage UDC files, browse to the Application Management page of the SharePoint Central Administration site and click the Manage data connection files link in the InfoPath Forms Services section.

When the UDC file is uploaded by the administrator, configure data connections to use the Centrally managed connection library option available by selecting a data connection in the Data Connection Wizard and then clicking the Connection Options button.

Please Note: Both UDC files need to have the same name. The data connection on the local site can be deleted after a link to the centrally-managed data connection is established, but further form template design using the deleted data connection will not be possible using the Data Connection Wizard.

Supported Data Sources: UDC files can describe different data sources because, unlike previous Office Data Connection files, they support a wider variety of data sources. However, while most data sources that can be configured in an InfoPath form template are supported, there are some data connection types, like e-mail submit, that cannot be described in a UDC file.

Allowed data sources include:
- Microsoft SQL Server Database query
- Web service query or submit
- XML file query (XML file located on a remote server)
- SharePoint library submit
- SharePoint list query
- Web server submit (HTTP post)

Please Note: The Data Connection Wizard for creating a UDC file for an HTTP post is accessed through the Submit Options dialog, not the Data Connections dialog box accessed from the Tools menu.

Data Connection Authentication: While forms opened in InfoPath can communicate directly with the data sources configured for the form template, forms opened in the browser communicate directly with the server running InfoPath Forms Services, either a single server or a Web front end. This introduces what is commonly referred to as the double hop problem. The double hop problem, or more precisely the multi-hop delegation problem, represents an authentication issue where credentials that are needed for access to resources on a third computer, or third tier, cannot be used in the request for those resources from the second tier.

Please Note: Each tier for which authentication is necessary is assumed to be a Windows computer on the network, configured for NTLM authentication.

For example, a form in the browser (the first tier) communicates with a server running InfoPath Forms Services (the second tier), which in turn needs to access resources on database server or network share (the third tier). The primary security token that was used between the browser and the server running InfoPath Forms Services cannot be passed to the database server due to delegation restrictions inherent to the NTLM authentication system used by Microsoft Windows between the browser and the InfoPath Forms Services server.

You will see this problem more frequently with forms in the browser because forms in InfoPath can authenticate directly with the data source, passing the primary authentication token to this server as the browser does to the server running InfoPath Forms Services.

The Single Sign-On (SSO) feature of Microsoft Office SharePoint Server 2007 is the preferred method of resolving delegation problems in multi-tier architectures, but there are other options if SSO is not available.

Please Note: SSO is only available with Office SharePoint Server 2007.

MultiTier Delegation Solutions Other Than SSO
Basic/Digest Authentication: This type of authentication is typically used for standard HTML forms, and can be useful for InfoPath forms used in extranet scenarios. A user is presented with a dialog for entering their credentials for access to resources on the third tier Web server, which can be used for one more hop to another Windows computer. If configured for Basic Authentication, the server will send these credentials in clear text, whereas Digest Authentication sends credentials across the network as an MD5 hash or message digest.

Embedded Credentials: Embedding credentials in a Universal Data Connection (UDC) file is possible but should only be used if the security of the username and password for access to the resource is not at risk.

Using an Anonymous/Service Account: If the SharePoint site is configured to allow anonymous access, the server will use an anonymous account to access resources on a third tier.

Kerberos: Kerberos is an authentication protocol designed to support delegation in multi-tier architectures. Using Kerberos, a user authenticates with her username and password to a Key Distribution Center (KDC) server and is issued a Kerberos ticket. The ticket is encrypted and accompanied by a verifier that can only be decrypted by the server. At each tier of the application, the ticket can be independently verified by the KDC without requiring the user’s credentials.

Constrained Delegation: Windows Server 2003 includes two extensions to the Kerberos service called Constrained Delegation (CD) and Protocol Transition. These services allow Windows to obtain a Kerberos ticket on behalf of a user in extranet scenarios where the client cannot use Kerberos or port 88 (the Kerberos port) is blocked. Most Internet servers and corporate firewalls block port 88 by default. CD requires all clients to be Windows XP or later, and all servers to be Windows Server 2003 or later. Additionally, CD must be enabled and configured in Active Directory.

Forms-based Authentication: SharePoint administrators can specify forms-based authentication as the mechanism users use to authenticate to the server. In forms-based authentication, the following occurs:

- The user makes an HTTP request to the Web front-end (WFE).

- The WFE returns an HTTP 302 (redirect) response which points to a Web form.

- The user types credentials into the Web form.

- The credentials are verified by a third-party plug-in authentication provider and are mapped to credentials that the WFE recognizes (like a SharePoint ID).

At the end of the process, the user has a valid SharePoint ID. However, InfoPath Forms Services does not have a valid Windows credential to use to make a connection, and the form has to use SSO or some other method to get credentials to connect to the data source.

Recommended Authentication Methods: SSO and the Web Service Proxy
SSO: Office Single Sign-on is a different method from the methods listed above for providing alternate credentials for making connections to resources on servers beyond the second tier. SSO is a database that maps applications and user credentials to other credentials, and an API that abstracts the SSO functionality so that any SSO provider which includes a provider for this API can be used. The following SSO providers are candidates for use by a form server administrator:

- Enterprise SSO
- Office Server SSO
- Third-party SSO providers that implement the Office pluggable SSO API

Office Server SSO and Enterprise SSO are based on the same codebase but have evolved independently. Enterprise SSO is included with BizTalk Server 2006. Office Server SSO supports a subset of authentication types that Enterprise SSO supports, but configuration is typically easier and Office SSO is included with Office SharePoint Server 2007.

For more information about configuring Office Server SSO, see Single Sign-on Overview in the Office Server SDK.

Multi-tier Web service Authentication using the Proxy: To enable Web service requests across a multi-tier architecture, the InfoPath Forms Services proxy is provided to forward Web service SOAP messages from the browser form.

The option to enable the proxy is located on the Application Management page of the SharePoint Central Administration site. Click the Manage the Web service proxy link in the InfoPath Forms Services section to enable the proxy for administrator-deployed forms and/or user-deployed forms.

Please Note: The UseFormsServiceProxy attribute in the UDC file must be set to true in order for the SOAP message to be forwarded by the proxy.

SharePoint Alternate Access Mapping and Data Connections: Alternate Access Mapping in SharePoint provides a mechanism for server farm administrators to identify the different ways in which users can access portal sites, ensuring that URLs are displayed appropriately for the manner in which users access SharePoint sites.

Alternate Access Mapping does not typically affect how data connections are handled by InfoPath Forms Services. However, if users will be accessing forms from both intranet and extranet locations, the authentication model for data connections should be configured and tested from both locations to ensure proper operation. Connections to a server using a fully-qualified URL, versus a local server name, depend on Alternate Access Mapping to ensure connectivity.

To view Alternate Access Mapping settings in SharePoint Central Administration, browse to the Operations page and click the Alternate access mappings link in the Global Configuration section.

Read more...

Verifying a Batch of Form Templates

For the purposes of this task, the VerifyFormTemplate method of the FormTemplateCollection class is used to verify a form template listed in a text box. This is the same as using the Verify button on the Upload Form Template page of the SharePoint 3.0 Central Administration site.

The form contains the following: a FolderBrowserDialog control; a button which opens the FolderBrowserDialog; a text box that holds the location of the folder containing form templates to be verified; a button which executes the form template verificatio;, and a rich text box to display the form template verified and any converter messages.

Setup The Project:

- Create a new Visual Basic Windows Application project in Microsoft Visual Studio 2005.

- On the Project menu, click Add Reference.

- On the .NET tab of the Add Reference dialog box, select Windows® SharePoint® Services, and click OK.

- On the Project menu, click Add Reference again.

- On the Browse tab of the Add Reference dialog box, browse to the Microsoft.Office.InfoPath.Server.dll assembly, typically located at C:\Program Files\Microsoft Office Servers\12.0\Bin\. Select the assembly and click OK.

Add Controls and Code to the Form:

- Add the following controls to the form. These can be found in the All Windows Forms category of the Visual Studio Toolbox:

1. Two Button controls
2. A TextBox control
3. A RichTextBox control

- Rename the first button to "Pick a Folder" and the second button to "Verify Form Templates" by modifying the Text property of each button in the Properties Window.

- Reposition and resize the form and the controls until all text can be seen on the buttons and the RichTextBox control fills most of the form.

- On the View menu, click Code.

- Paste the code below into the code window, replacing all existing code.

- Click Form1.vb [Design] on the Window menu.

- In the Properties Window, click the drop-down list box and select Button1.

- In the Properties Window, click the Events button, which is typically the fourth button from the left in the row of buttons below the drop-down list box.

- In the Action section, click the drop-down for the Click event and select Button1_Click.

- In the Properties Window, click the drop-down list box and select Button2.

- In the Action section, click the drop-down for the Click event and select Button2_Click.

- On the File menu, click Save All.

- Press F5 to run the application.

Example: Use the procedures above to create a new Visual Basic Windows application that uses this code example to verify form templates in a folder, and to list any converter messages associated with each form template or messages indicating the form template is ready to be uploaded.

 




Imports Microsoft.SharePoint.Administration
Imports Microsoft.Office.InfoPath.Server.Administration

Public Class Form1

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        'Show the folder browser dialog
        If FolderBrowserDialog1.ShowDialog() = Windows.Forms.DialogResult.OK Then
            TextBox1.Text = FolderBrowserDialog1.SelectedPath
        End If
    End Sub

    Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
        Dim Directory As New IO.DirectoryInfo(TextBox1.Text)
        Dim AllFiles As IO.FileInfo() = Directory.GetFiles("*.xsn", IO.SearchOption.TopDirectoryOnly)
        Dim MyFile As IO.FileInfo
        Dim StrLog As String = ""
        Dim LocalFormsService As FormsService
        Dim LocalFarm As SPFarm
        Dim VerifyMessages As New ConverterMessageCollection
        Dim ConverterMsg As ConverterMessage
        Dim IntFileCount As Int16 = 0

        Try
            'Loop through each file
            For Each MyFile In AllFiles
                'Write the filename and path to the string
                StrLog = StrLog + MyFile.FullName.ToString() + Environment.NewLine
                LocalFarm = SPFarm.Local
                LocalFormsService = LocalFarm.Services.GetValue(Of FormsService)(FormsService.ServiceName)
                'Verify the form template
                VerifyMessages = FormTemplateCollection.VerifyFormTemplate(MyFile.FullName.ToString())
                'If there are no messages, display a message that the form template
                'is OK, otherwise loop through the messages and build the string
                If VerifyMessages.Count = 0 Then
                    StrLog = StrLog + "  There are no problems with this form template." + Environment.NewLine
                Else
                    For Each ConverterMsg In VerifyMessages
                        StrLog = StrLog + "  " + ConverterMsg.ShortMessage.ToString() + _
                        ": " + ConverterMsg.DetailedMessage.ToString() + Environment.NewLine
                    Next
                End If
                'Write the string to the rich text box
                RichTextBox1.Text = RichTextBox1.Text + StrLog
                RichTextBox1.Refresh()
                'Reset the string, adding a blank line between files
                StrLog = Environment.NewLine
                'Increment the file count
                IntFileCount = IntFileCount + 1
            Next
            'Show message that the files are done
            MessageBox.Show(IntFileCount.ToString() + " file(s) verified")
        Catch ex As Exception
            MessageBox.Show("An error occurred: " + ex.Message)
        End Try
    End Sub
End Class




 
 

If you need to process every form template in the main folder and any subfolder, change the IO.SearchOption.TopDirectoryOnly parameter to IO.SearchOption.AllDirectories.

If you need to upload form templates after verifying them, use the UploadFormTemplate method.

Read more...

Deploying Form Templates That Contain Form Code

The process of deploying InfoPath form templates that contain form code to a server running InfoPath Forms Services can be divided into three distinct steps:

- Getting the form template ready. This step creates a new .xsn file which contains information about the server it will be deployed to.

- Uploading the form template to the server. This step requires a farm administrator to add the form template to the server and includes the optional step of verifying that the form template can be uploaded.

- Activating it to a site collection. This makes the form template available on a site collection so that it can be filled out in the browser or in InfoPath, depending on whether users have Microsoft Office InfoPath 2007 installed.

Get a Form Template Ready to be Deployed by a Server Administrator:

- Open the Publishing Wizard by clicking the File menu and selecting Publish.

- The first option in this dialog is To a SharePoint server with or without InfoPath Forms Services. Leave this selected and click Next.

- On the second screen of the Publishing Wizard, type the URL of a SharePoint server that you have at least Contribute rights to, meaning that you can add and delete content on the site, then click Next.

- On the third screen of the Publishing Wizard, keep the default settings of Enable this form to be filled out using a browser and Administrator-approved form template (advanced), and click Next.

- On the fourth screen of the Publishing Wizard, type a location and file name for the form template (.xsn) file. This can be on your local hard drive, a network file share, or a Web server. Click Next.

- On the fifth screen of the Publishing Wizard, click the Add button to select fields from the form template that will be shown as columns in the document library and in Outlook. This is optional. After you are done, click Next.

- On the last screen of the Publishing Wizard, click Publish. This saves your form template (.xsn) file to the location you specified. It is now ready to be uploaded to the server.

Uploading Form Template to a Server Running InfoPath Forms Services:

- Open the SharePoint 3.0 Central Administration site. (You must be a member of the Farm Administrators group in order to complete these steps.)

- Click the Application Management link.

- Under InfoPath Forms Services, click the Manage form templates link.

- Click the Upload form template link near the top of the page.

- Click the Browse button to open a dialog box, and enter the path to the published form template.

- Click the Verify button to verify that the form template does not contain any errors. This step is optional.

- Click the Upload button to upload the form template to the site. After this is done, click the OK button.

Activating Form Template to a Site Collection:

- On the Manage Form Templates page, locate the form template you uploaded.

- Click the drop-down and select Activate to a Site Collection.

- In the Activation Location section, click the drop-down and select Change Site Collection.

- On the Select Site Collection dialog box, click the Web Application drop-down and select Change Web Application.

- Click SharePoint - 80. This should be the name of your default SharePoint server. If not, select your default SharePoint server.

- Click the site collection name that you want to activate the form to, and then click OK.

- On the Activate Form Template page, click OK.

Alternatively, activating a published form template can be done from the site collection administration page. Select Site Collection Features, locate the form template, and click the Activate button.

Read more...

Verifying a Form Template Before Deployment

Browser-compatible InfoPath form templates can be verified before they are deployed to a server running InfoPath Forms Services. Verifying a form template ensures that problems with deployment can be addressed before they are deployed. Much like using the Verify on server option on the Design Checker task pane in the InfoPath design UI, verification can be done through the SharePoint 3.0 Central Administration Web site or with code using the VerifyFormTemplate method of the FormTemplateCollection class.

Verifying Form Template using the SharePoint Central Administration Web site:

- Prepare a form template requiring administrator approval for publication using the Publishing Wizard.

- Open the SharePoint 3.0 Central Administration site. (Please Note: You must be a member of the Farm Administrators group in order to complete this and the remaining steps.)

- Click the Application Management link.

- Under InfoPath Forms Services, click the Manage form templates link.

- Click the Upload form template link near the top of the page.

- Click the Browse button to open a dialog box, and type the path to the published form template.

- Click the Verify button to verify that the form template is ready for uploading to the server.

Verifying Form Template Using the VerifyFormTemplate Method of the FormCollection class:

- Prepare a form template requiring administrator approval for publication using the Publishing Wizard.

- Open Microsoft Visual Studio 2005.

- Create a new Console Application in either Visual Basic or C#.

- Right-click the project in the Solution Explorer, and click Add Reference.

- On the .NET tab, select Windows SharePoint Services and click OK.

- Repeat step 3 and in the Add Reference dialog box, click the Browse tab.

- In the Look in box, navigate to the location where Microsoft Office SharePoint Server 2007 or Microsoft Office Forms Server 2007 is installed, typically C:\Program Files\Microsoft Office Servers\12.0\, double-click the Bin folder, then inside this folder, select Microsoft.Office.InfoPath.Server.dll and click OK.

- Copy the code example below, depending on the language you chose in step 2, and paste it into the code window.

- Change the SolutionPath variable to a location where you have published a form template for administrator approval.

- Save the project and press F5 to debug and run the code.

The count of converter messages as well as the messages, if any, will be displayed in a console window.

The code examples use the VerifyFormTemplate method to show converter messages, if any, in a console window. The location of the form template is stored in the SolutionPath variable and should be changed to match the path of the form template that you want to verify.

 




Imports Microsoft.SharePoint.Administration
Imports Microsoft.Office.InfoPath.Server.Administration

Module Module1

    Sub Main()
        Dim LocalFormsService As FormsService
        Dim LocalFarm As SPFarm
        Dim SolutionPath As String = "C:\FormTemplates\FormTemplate.xsn"
        Dim VerifyMessages As New ConverterMessageCollection
        Dim ConverterMsg As ConverterMessage
        Try
            LocalFarm = SPFarm.Local
            LocalFormsService = LocalFarm.Services.GetValue(Of FormsService)(FormsService.ServiceName)
            VerifyMessages = FormTemplateCollection.VerifyFormTemplate(SolutionPath)
            Console.WriteLine("# of messages: " + VerifyMessages.Count.ToString())
            For Each ConverterMsg In VerifyMessages
                Console.WriteLine(ConverterMsg.ShortMessage.ToString() & ": " & ConverterMsg.DetailedMessage.ToString())
            Next
            Console.Write("Press Enter to Continue")
            Console.ReadLine()
        Catch ex As Exception
            Console.WriteLine("Error: " + ex.Message)
            Console.Write("Press Enter to Continue")
            Console.ReadLine()
        End Try

    End Sub

End Module
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint.Administration;
using Microsoft.Office.InfoPath.Server.Administration;

namespace VerifyFormTemplate
{
    class Program
    {
        static void Main(string[] args)
        {
            FormsService localFormsService;
            SPFarm localFarm = SPFarm.Local;
            string solutionPath = "C:\\FormTemplates\\FormTemplate.xsn";
            ConverterMessageCollection verifyMessages;
            try
            {
                localFormsService = localFarm.Services.GetValue(FormsService.ServiceName);
                verifyMessages = FormTemplateCollection.VerifyFormTemplate(solutionPath);
                Console.WriteLine("# of messages: " + verifyMessages.Count.ToString());
                foreach (ConverterMessage convMessage in verifyMessages)
                {
                    Console.WriteLine(convMessage.ShortMessage.ToString() + ": " + convMessage.DetailedMessage.ToString());
                }
                Console.Write("Press Enter to Continue");
                Console.ReadLine();
            }
            catch (Exception ex)
            {
                Console.WriteLine("Error: " + ex.Message);
                Console.Write("Press Enter to Continue");
                Console.ReadLine();
            }
        }
    }
}




 
 

Read more...

Creating a New Web Site in IIS

You must create a new Web site for each security model that you want. For example, if you want to have both Anonymous access and Basic authentication, you must create two Web sites. On one site you would specify Anonymous access, and on the other site you would specify Basic authentication.

Note that you should not modify settings on the Default Web Site. Specifically, SharePoint Portal Server requires the Default Web Site to use port 80 as the TCP port. Do not change the port to an alternative HTTP port (such as 8000 or 8080) after installation. Ensure that port 80 is specified and remains as the primary port for the server.

For creating a new Web site, follow the following steps:

- On the taskbar, click Start, point to Programs, point to Administrative Tools, and then click Internet Services Manager.

- Expand the node for the SharePoint Portal Server computer.

- Right-click the name of the SharePoint Portal Server computer, point to New, and then click Web Site. The Web Site Creation Wizard appears.

- Click Next, and then follow the instructions in the wizard:

1. Type a description of the Web site, and then click Next. The description appears in the tree view of the console. For example, if this Web site is to be used for Anonymous access, you could type AdventureWorksAnon as the description.

2. Select the IP address. Do not select (All Unassigned).

3. Type 80 for the TCP port number.

4. Type the external FQDN as the host header. The host header is of the form external_server_name.external_domain_name.

5. Click Next.

6. Enter the path for your home directory. It is strongly recommended that the home directory be under the Inetpub directory.

7. If you do not want to allow Anonymous access to SharePoint Portal Server, clear the Allow anonymous access to this Web site check box.

8. Click Next.

9. On the Web Site Access Permissions page, click Next. Do not change the default access permissions.

10. Click Finish. The new Web site appears.

- Expand Default Web Site, and then note the following five virtual directories (nodes on the tree): Exchweb, SharePoint Portal Server, Public, MSOffice, and YourWorkspace, where YourWorkspace represents the name of the virtual directory for your workspace. To find the local path, do this for each of the five virtual directories:

1. Right-click the virtual directory, and then click Properties.

2. On the Virtual Directory tab, note (or copy) the path shown in Local Path.

3. Close the Properties page.

- Right-click the new Web site that you created, point to New, and then click Virtual Directory. The Virtual Directory Creation Wizard appears.

- Click Next, and then follow the instructions in the wizard:

1. In Alias, type Exchweb and then click Next.

2. In Directory, type (or paste) the path for Exchweb, and then click Next

3. On the Access Permissions page, click Next. Do not change the default access permissions.

4. Click Finish.

The above two steps, create a virtual directory for SharePoint Portal Server, Public, MSOffice, and for YourWorkspace, where YourWorkspace represents the name of the virtual directory for your workspace.

Note: The names of the new virtual directories must match exactly the names of the original virtual directories under the Default Web Site. Do not rename the virtual directories.

- After creating the virtual directories, for the Public and YourWorkspace virtual directories on the new Web site that you created, do the following:

1. Right-click the virtual directory, and then click Properties.

2. Click the Virtual Directory tab.

3. In Application Protection, select Low (IIS Process).

4. On the Virtual Directory tab, click Configuration.

5. On the App Mappings tab, click Add.

6. In Executable, type the path to the msdmisap.dll file. You can also browse to the msdmisap.dll file. By default, this file is located in the SharePoint Portal Server \Bin directory. For example, if you installed SharePoint Portal Server to Program Files\SharePoint Portal Server, this file is in Program Files\SharePoint Portal Server\Bin.

- For the YourWorkspace virtual directory on the Web site that you created, do the following:

1. Right-click the virtual directory, and then click Properties.

2. On the Virtual Directory tab, select the Write check box.

3. Click the HTTP Headers tab, and then click Add.

4. In Custom Header Name, type MicrosoftTahoeServer

5. In Custom Header Value, type 1.0

6. Click OK.

7. Click OK to close the Properties page.

- For the MSOffice virtual directory on the Web site that you created, do the following:

1. Right-click the virtual directory, and then click Properties.

2. Click the Virtual Directory tab.

3. In Execute Permissions, select Scripts and Executables.

4. Click OK to close the Properties page

Right-click YourVirtualWeb, where YourVirtualWeb is the name of the new Web site you just created, and then click Start. If YourVirtualWeb is already started, omit this step.

Read more...

Configuring the Proxy Setting on the SharePoint Portal Server

The dashboard site uses a special server-side object called ServerXMLHTTP to make Hypertext Transfer Protocol (HTTP) requests. These requests are necessary to return the correct page to the client. The ServerXMLHTTP object has its own proxy settings. If the dashboard site is behind a proxy server, you must configure the ServerXMLHTTP object with the proxy server name to successfully access data located beyond the intranet. The proxy settings are important when the dashboard site needs to access resources on a different server, such as when you use the Content management page to import new Web Parts.

During the SharePoint Portal Server installation, the setup process automatically configures the proxy settings for ServerXMLHTTP by using the proxy settings specified for the server. If you need to change these proxy settings at some time after installation, or if you want to use SharePoint Portal Server on the Internet without a proxy server, perform the procedure that follows.

To configure the proxy settings, follow the following steps:

A. On the taskbar, click Start, point to Programs, point to Accessories, and then click Command Prompt.

B. Change to the SharePoint Portal Server \Bin directory. For example, if you installed SharePoint Portal Server in the Installation directory on drive E, change to E:\Installation\Bin. If you installed SharePoint Portal Server on drive D under Program Files\SharePoint Portal Server, change to D:\Program Files\SharePoint Portal Server\Bin.

C. Type proxycfg to see the current proxy settings.

D. To configure the proxy appropriately, type proxycfg –d –p proxy_name:port_number “root_domain_name;”

You can separate multiple bypass addresses with a semicolon. A bypass address is an address for which you do not want to use the specified proxy server. In the line above, root_domain_name is the bypass address. The bypass address is in the form *domain, such as *adventure-works.com.

For example, if your proxy server name is Proxy1, the port number is 80, and you want to bypass the proxy server for the SharePoint Portal Server computer in the domain adventure-works.com, type proxycfg –d –p Proxy1:80 “*adventure-works.com;”

Please Note, SharePoint Portal Server is not configured to run with direct Internet connectivity out-of–the-box. SharePoint Portal Server is initially configured for use with a proxy server.

The proxy server and bypass list must be set if the virtual directory for the workspace has NTLM enabled. The ServerXMLHTTP object attempts NTLM authentication against the virtual directory for the workspace.

If you are not using a proxy server, run one of the following:

- proxycfg –d –p fake_proxy_name:80 “”
This enables NTLM on the computer and on the subnet mask.
You cannot download Web Parts from any site, including the Microsoft Web Part Gallery.
Security issues: This setting has no known security issues since all traffic is local.

- proxycfg –d –p fake_proxy_name:80 “*microsoft.com;”
This enables NTLM on the computer and on the subnet mask.
You can download Web Parts from the Microsoft Web Part Gallery. You cannot download Web Parts from any other site.
Security issues: This setting may increase the security vulnerability because traffic going to www.microsoft.com may send NTLM packets. This depends on the Internet Service Provider (ISP) configuration and whether ports are enabled to allow NTLM packets to be sent and received.

- proxycfg –d –p fake_proxy_name:80 “*;”
This enables NTLM on the computer and on the subnet mask.
You can download Web Parts from any Web site.
Security issues: NTLM traffic may be sent to any site on the Internet. This depends on the ISP configuration and whether ports are enabled to allow NTLM packets to be sent and received.

- proxycfg –d
This enables NTLM only on the computer. It does not enable NTLM on the subnet mask.
Some SharePoint Portal Server functionality may be disabled.
You must create a new Web site in IIS that uses Basic authentication. NTLM remains enabled on the Default Web Site in IIS. See “Create a New Web Site in IIS” in this paper.
You cannot download Web Parts from any Web site.
Security issues: Running a computer directly on the Internet with no proxy server has inherent security vulnerabilities and is not recommended. However, using Basic authentication with SSL enabled on the new Web site in IIS is the most secure SharePoint Portal Server configuration available when directly on the Internet.

E. Restart the computer.

Read more...

Creating the Workflow Association Form

The association form allows users to specify key information when a workflow is first associated with a list. In this exercise, you will specify information about the manager who will be performing the performance reviews. The assumption here is that you will create separate lists for each manager that will use the workflow.

Follow these steps to create the association form:

1. Start Microsoft InfoPath.

2. In the Getting Started dialog, click the link titled Design a Form Template.

3. In the Design a Form Template dialog, select a Blank template and click the OK button to start with a blank form.

4. When the blank form opens, click the Data Source link in the Design Tasks pane.

5. Right-click the myFields node and select Properties from the context menu.

6. Rename the node flowFields in the Name text box and click the OK button.

7. Right-click the flowFields node and select Add.

8. In the Add Field or Group dialog, type managerUsername in the Name field and click the OK button.

9. Right-click the flowFields node and select Add.

10. In the Add Field or Group dialog, type managerFullname in the Name field and click the OK button.

11. Right-click the flowFields node and select Add.

12. In the Add Field or Group dialog, type reviewType in the Name field and click the OK button.

13. Right-click the flowFields node and select Add.

14. In the Add Field or Group dialog, type reviewComments in the Name field and click the OK button.

15. Click on the Design Tasks link at the top of the Data Source pane.

16. Click the Layout link in the Design Tasks pane.

17. Drag the Custom Table layout onto the blank form.

18. In the Insert table dialog, enter 1 in the Columns field and 3 in the Rows field, and click the OK button.

19. Click the Design Tasks link at the top of the Layout pane.

20. Click the Controls link in the Design Tasks pane.

21. Uncheck the box labeled Automatically Create Data Source.

22. Drag a text box from the Controls pane and drop it in the top cell of the table.

23. In the Text Box Binding dialog, select the managerUsername field and click the OK button.

24. Drag a text box from the Controls pane and drop it in the middle cell of the table.

25. In the Text Box Binding dialog, select the managerFullname field and click the OK button.

26. Drag a button from the Controls pane and drop it in the bottom cell of the table.

27. Right-click the button and select Button Properties from the context menu.

28. Enter Done in the Label field.

29. Click the Rules button.

30. In the Rules dialog, click the Add button.

31. In the Rules dialog, click the Add Action button.

32. In the Action dialog, select Submit Using a Data Connection from the drop-down list.

33. Click the Add button.

34. In the data connection wizard, select to Create a New Connection to Submit Data and click the Next button.

35. On the next screen select the option to submit the data to The Hosting Environment. This will ensure that the contents of the formare submitted back to the SharePoint workflow process.

36. Click the Next button.

37. On the next screen, name the connection Association and click the Finish button.

38. In the Action dialog, click the OK button.

39. In the Rules dialog, click the Add Action button.

40. Select Close the Form from the drop-down list.

41. Uncheck the box labeled If Changes Have Not Been Saved, Prompt the User to Save.

42. Click the OK button.

43. In the Rule dialog, click the OK button.

44. In the Rules dialog, click the OK button.

45. In the Button Properties dialog, click the OK button.

46. Save the form to an appropriate place for safekeeping such as AssocForm.xsn. You’ll move the form later, so you just need a temporary location for now.

Read more...

Creating a Public Internet Site

While many content management capabilities are certainly useful in team sites, the most likely scenario for content management involves the enterprise. Therefore, I will assume for the rest of the chapter that you are using MOSS. To support the discussion, I’ll use an Internet web site created on the VSMOSS server.

Follow these steps to create an Internet site:

1. Log in to VSMOSS as a SharePoint administrator.

2. Select Start --> Administrative Tools --> SharePoint 3.0 Central Administration.

3. On the Application Management tab, under the SharePoint Web Application Management section, click the link titled Create or Extend a Web Application.

4. On the Create or Extend a Web Application page, click the link titled Create a New Web Application.

5. On the Create a New Web Application page, select the option to Create a New IIS Web Site.

6. In the Description field, type Internet.

7. In the Application Pool section, select Create a New Application Pool.

8. Enter Internet_Pool as the pool name.

9. Select the Configurable option for the application pool security account.

10. In the User Name field, enter DOMAIN\SPContentPool.

11. In the Password field, enter the account password.

12. In the Reset Internet Information Services section, select the option to Restart IIS Automatically.

13. Click the OK button.

14. On the Application Created page, click the link titled Create a New Site Collection.

15. On the Create Site Collection page, enter APress in the Title field.

16. Under the Template Selection section, click the Publishing tab, and then select the Publishing Portal template.

17. Under the Primary Site Collection Administrator section, enter DOMAIN \ Administrator in the User Name field.

18. Click the OK button to create the new site collection. When the site collection is created, open it in a separate copy of the browser.

When creating a public Internet site, you may want to set it up so that you can author content on it from inside the firewall. One way to do this is to configure it so that it is accessible from two different zones. Typically the Default zone is accessible through Windows authentication while the Internet zone is accessible anonymously.With this configuration, you can use the Default zone for managing content and the Internet zone for presenting it. This is not the only possible authoring configuration; I discuss a more formal content deployment scenario in the section titled “Using Content Deployment.”

Follow these steps to extend the web application into the Internet zone:

1. In the Central Administration site, click the Application Management tab.

2. Under the SharePoint Web Application Management section, click the link titled Create or Extend Web Application.

3. On the Create or Extend Web Application page, click the link titled Extend an Existing Web Application.

4. On the Extend Web Application to Another IIS Web Site page, drop down the Web Application selection list and click Change Web Application.

5. In the Select Web Application page, click the link for the Internet Web Application that you created.

6. Under the IIS Web Site section, choose to Create a New IIS Web Site.

7. In the Description field type Public Internet, but leave the port number in parentheses as part of the name.

8. Under the Load Balanced URL section, select Internet from the Zone drop-down list.

9. Make note of the URL for the extended web application so you can access it later.

10. Click the OK button.

Once the web application is extended, you will want to enable anonymous access to the
new site collection. Enabling anonymous access requires that you first allow it for the site collection using Central Administration and then designate what portions of the Internet site will support anonymous access. In this way, you can create an Internet site that has both public and private areas.

Follow these steps to enable anonymous access:

1. Click the Application Management tab in the Central Administration web site.

2. Under the Application Security section, click the Authentication Providers link.

3. On the Authentication Providers page, make sure that your new web application is shown in the drop-down. If not, use the drop-down to change the selection.

4. Click the Windows link for the Internet zone of your web application.

5. On the Edit Authentication page, check the box labeled Enable Anonymous Access and click the Save button.

6. Click the Application Management tab in the Central Administration web site.

7. Under the Application Security section, click the link titled Policy for Web Application.

8. On the Policy for Web Application page, make sure that your new web application is shown in the drop-down. If not, use the drop-down to change the selection.

9. Click the Add Users link.

10. On the Add Users page, make sure All Zones is selected and click the Next button.

11. Enter DOMAIN\Administrator in the Users box and check the Full Control permission to grant the administrator access to both the Default and Internet zones.

12. Click the Finish button.

13. Now open the home page of the public Internet site you extended on the Internet zone and click the link titled Enable Anonymous Access.

14. On the Change Anonymous Access Settings page, select the option labeled Entire Web Site and click the OK button.

Once you have completed the previous steps you will be able to author content on the Default zone and access it anonymously on the Internet zone. While these steps are good for investigating MOSS, you will probably want to ensure the Internet zone is on port 80 in a production environment. Usually, I create the Default zone on a different port (e.g., 8080) and then extend the web application into port 80 as the Internet zone.

Another real-world consideration is the fact that Internet sites are often isolated in the DMZ and may not be accessible from the Windows domain. In this case, I make use of the content deployment capabilities of MOSS to push content from a staging server to production.

Read more...

Deployment Architectures for Sharepoint

SharePoint may be deployed in several different architectural configurations from a single server utilizing SQL Server Express to a multiserver farm with an active-passive SQL cluster. The exact deployment architecture will be based on the number of users, storage requirements, and availability requirements. Small team-based installations may be able to use a single server while large Internet presence sites will need a farm. Table 2-3 lists the various configurations and their specifications based on an average corporate user with an average amount of activity.

Single-Server Configuration: A single-server deployment of WSS or MOSS can be created on a server that has a 2.8 GHz processor with 2GB of RAM and a 100GB hard drive. In this scenario, you would utilize SQL Server Express to create the required databases directly on the server without the need for a separate installation of SQL Server 2005. This deployment is remarkably easy to set up by simply running the WSS or MOSS installation and following the steps. However, this is the least reliable configuration because everything obviously relies on the availability of a single machine.

Small Farm Configuration: System performance can be improved by moving the database off of the single server and onto its own server. This requires a separate installation of SQL Server, but improves performance significantly because all database operations can happen on the separate server. However, this configuration is really no more reliable than the single-server configuration because it is still vulnerable to a single failure.

Medium Farm Configuration: True enterprise reliability begins with the medium farm configuration. In this configuration, the web front-end servers, application server, and database servers are separate. A typical configuration would have two front-end web servers, a single application server, and an activepassive SQL Server cluster. Generally, these servers are dual-processor machines with at least 4GB of RAM and upward of 200GB hard drives. Performance and reliability in this configuration are greatly enhanced by separating the required functions across machines.

Large Farm Configuration: The large farm configuration is a scaled-out version of the medium farm configuration. In the large farm, upward of four front-end web servers are used to handle hundreds of thousands of users. An application server and active-passive SQL Server cluster are employed in the same way as the medium farm configuration. This configuration is typical for a large Internet presence site.

Read more...

Shared Services and Moss Versions

Shared Services

Many of the advanced capabilities of MOSS are configured and delivered through a Shared Services Provider (SSP). The SSP allows you to configure things such as Enterprise Search, Excel Services, and the BDC one time and then use them across many different MOSS and WSS sites. Because you can configure multiple SSPs in the same farm, this architecture gives you the flexibility to expose specially configured services where you want them. For example, you may configure an SSP with a public search for use on the Internet, and another SSP with a private search for use on the corporate intranet.

MOSS Versions

While WSS is a free component, MOSS must be licensed separately. MOSS comes in several different versions that target different deployment scenarios and have different licensing requirements. Regardless of your scenario, however, every organization using MOSS must purchase the base MOSS 2007 server license. Along with the server license, you must also purchase the appropriate client access licenses (CAL) to meet your needs.

Read more...

Enterprise Content Management and Business Intelligence

Enterprise Content Management

Enterprise Content Management (ECM) is a broad term that refers to managing the entire document life cycle from ideation through archival. This includes not only the same workflow capabilities I described earlier for WSS sites, but also the ability to archive these records and apply retention policies to them. Additionally, ECM encompasses web content management (WCM) to support the creation, approval, and deployment of web sites.

MOSS supports several different templates that allow organizations to create both public and private sites. One of those templates allows you to create a records repository that you can use to archive documents according to a document retention policy. Documents may be added to the records repository either manually from within a SharePoint document library, or automatically by associating a workflow with a retention policy. In the latter case, a document could, for example, be routed through a review process and then sent to the repository after it has reached a certain age. It might also be good to mention at this point that both WSS and MOSS have a recycle bin that works similarly to the Windows Recycle Bin and allows a single document to be recovered if it is inadvertently deleted.

Along with documents, MOSS also manages web content. Prior to the release of MOSS, the Microsoft Content Management Server (MCMS) was the primary way that organizations created, approved, and published web content. With the release of MOSS, MCMS is being retired. The major capabilities formerly in MCMS have been moved to MOSS. This includes creating page templates with content placeholders, implementing approval processes, and deploying pages in bulk from separate development environments to production environments.


Business Intelligence

Business intelligence represents a key area where MOSS brings many new capabilities that were unknown in previous versions of SharePoint. One of the MOSS templates available out of the box is a Report Center template designed to act as a hub for business intelligence data. While business intelligence capabilities can be utilized anywhere within MOSS, the Report Center template is specially designed to support report distribution and the creation of key performance indicator (KPI) dashboards. Reports can be delivered either by creating Excel spreadsheets or by designing reports in Microsoft Reporting Services. KPI dashboards can be created either by hand or by connecting them to a spreadsheet or an analysis cube built in SQL Server 2005.

Along with these features, MOSS also supports two new server-based versions of Office products: Excel Services and Office Forms Server. With these servers, you can distribute Excel spreadsheets and InfoPath forms to end users even when they do not have Excel or InfoPath installed. This means that spreadsheet-based reports and dashboards can be delivered over the web without exposing critical data or calculation formulas to users. It’s also now possible to expose InfoPath forms over the web to traveling personnel, customers, and partners who might need to fill out a formbut do not have the InfoPath client available.

Rounding out the business intelligence feature set is the Business Data Catalog (BDC). The BDC is a new no-code mechanism for exposing line-of-business data within MOSS. Using the BDC, you can define the data structure in back-end systems such as your customer relationship management (CRM) system or human resources database. This data may then be mapped into web parts for easy searching, displaying, and filtering.

Read more...

Microsoft Office SharePoint Server

The Microsoft Office SharePoint Server (MOSS) is a significant new product with broad and deep capabilities designed to support a wide variety of enterprise functions to manage content, present business intelligence data, automate workflow processes, manage records, and build both public and private web sites. Although MOSS can be thought of as the next version of SharePoint Portal Server 2003 (SPS), it is really a completely new product. Its organizational structure and customization patterns are much different than those of SPS.

MOSS is based entirely on WSS technology and is a true superset of WSS functionality. Every enhancement you create in WSS will function identically in MOSS. This also means that the end user experience is consistent between MOSS and WSS. Navigation elements, styles, and site organization are the same whether you are in MOSS or WSS. This is a far cry from SPS, which often seems to have no relationship at all to WSS. For those who experienced SPS, you will find that the old Topic and Area structure has been eliminated in favor of a more flexible interface that can easily be changed.

Portal Features

Many of the portal features of MOSS will be familiar to anyone who has worked previously with SPS. Although the look and feel of MOSS more closely resembles the current version of WSS than the previous version of SPS, familiar capabilities of SPS such as Audiences, Profiles, My Site, and Single Sign-On (SSO) have been retained. These features differentiate a true organizational portal from a simple team collaboration site and should be thought of as one of the primary differences between MOSS and WSS.

Audiences in MOSS are used to target content at portal users. Within MOSS, you may define an audience based on user attributes such as membership in an Active Directory group. Then you may use that audience definition to show or hide content when a page is viewed.

MOSS user profiles allow you to define, search, and present metadata about portal users. Profiles draw information from Active Directory to provide basic information such as first name and last name, but you may also extend the metadata to include custom fields such as languages spoken or areas of expertise. Additionally, these custom fields can even be derived from other systems, for example like PeopleSoft. Once defined, profiles can be a search scope that allows users to locate people within the organization.

Along with their profile, every MOSS user can also be given their own personal site—
called My Site. My Site functions as a personal workspace for MOSS users and allows them to organize their own documents and information. Through My Site, users may connect to colleagues, manage their profiles, and be alerted when key information changes somewhere in MOSS.

Although SSO services were available in SPS, my experience is that they were rarely used. In MOSS, however, SSO takes on new meaning, because it is used to facilitate access to several new features such as data in line-of-business systems. SSO allows you to specify a set of credentials for accessing a secondary system and then give those credentials an application name that may be invoked later by either a MOSS feature or your own custom code.

Read more...

Project and Design Documents

SharePoint products and technologies are best thought of as a solution platform. This means, however, that it is impossible to define exactly what constitutes a SharePoint solution and therefore what design deliverables are required. I have seen many SharePoint projects that are nothing more than installing WSS and turning a departmental team loose.

While this approach may violate several planning and change principles, it certainly is not a project that requires layers of design documents. On the other hand, I have also been part of unique projects that utilize forms, documents, search, and workflow to implement specific processes. In these projects, good documentation—specifically use cases—is invaluable. Furthermore, SharePoint solutions are iterative by nature; as users become more familiar with the environment, you end up fine-tuning your solution.

As a result, you must decide for each project how much documentation is needed. The danger here, however, is that it’s just so easy to start customizing in SharePoint. While this is not necessarily a bad approach for small projects, it can also lead to a maintenance nightmare if entire departmental or enterprise solutions are approached in this way. Instead of customizing many sites individually, for example, creating a single site template that can be used over and over will be much more efficient.

Read more...