CA Clarity SharePoint Connector

Installing SPConnector on SharePoint for accessing Clarity PPM data was an interesting learning experience. I ran into several issues with the installation and was finally able to resolve it with some manual steps.

Although the installation document is decent with the instructions, it does not cover the installation for a multi-server MOSS farm clearly. For a single server WSS implementations the documented steps may work fine.

When I ran the installation on the Central Admin Server, I got the following error (the installation log can be found in the local %temp% directory)

The EXECUTE permission was denied on the object ‘proc_getNewObjects’, database ‘SharePoint_Config’, schema ‘dbo’.

To resolve this error I had to –

On the DB server, Open the SQL Management Studio

Browse to the database in question, in our case “‘SharePoint_Config“

Open the database and then Security > Roles > Database Roles

In the right part of the window, right click the WSS_Content_Application_Pools role and click Properties

Select the menu option “Securables”

Click “Add”

Select “Specific objects” and click “OK”

Click “Object Types”, select “Stored Procedures” and click “OK”

Add the following stored procedures: proc_getNewObjects

Click “OK” to add these stored procedures

Select the added stored procedures and select “Execute” in the “Grant” column.

Upon running the installation again, I got the same error for proc_putObject. Repeated the above steps for the proc_putObject stored procedure and upon re-install, I was able to get the solution installed successfully on the Central Admin Server.

The Next step is to deploy the solution on SharePoint web-applications. I targeted the solution to specific web-apps that will be using the CA PPM web-parts.

Once the solution is deployed, the CA PPM web-parts are ready to use. To help maximize the web-parts effectively, CA has also provided a sample SharePoint site template (stp file). This file can be uploaded into the site collections “Site Templates” gallery for end user use.

SharePoint – BI Publisher Integration

I’ve expanded the Jim Glazar’s / Pablo Bryan’s article and have provided some additional information.

BI Publisher provides a mechanism to publish documents to a remote server using WebDAV (Web based distributed authoring and versioning) protocol. WebDAV is basically an extension of HTTP.

SharePoint provides native support for WebDAV. This means Document Libraries in SharePoint can be accessed directly via a network share or it can be mapped to be Drive letter or mounted as a partition as long as the client operating system natively supports WebDAV or there is WebDAV client installed on the client OS.

To enable the integration between SharePoint and BI Publisher, the following settings must be performed on the SharePoint front –

SharePoint Configurations

1. Open IIS Manager and right Click on the web application (virtual directory) that hosts the site under which the destination document library exits.



2. Click on the Directory Security Tab and Click on “Edit” button under “Authentication and Access Control”



3. Under Authenticated Access section, you have to enable both Digest and Basic Authentication. Please note that Basic Authentication will send passwords over the wire in clear text. BI Publisher supports Digest Authentication. For some reason, SharePoint 2007 requires both of them enabled for the integration to work. If you enable only Digest and not basic, you’ll receive an Authentication error on publisher when attempting to publish a document.



I’m sure there must be a way to get the integration working without enabling Basic authentication on SharePoint. This could be a bug in SharePoint 2007. However, I don’t think there will be security implication as BI Publisher will use Digest Authentication to authenticate users with SharePoint. All passwords will be sent over the wire using MD5 message digest algorithm.

4. Click OK and run “IISreset” command for the changes to take effect.

Note: If there are multiple Web Front Ends (WFE) in the farm, then the updates to Authentication must be performed on all the participating WFEs.

BI Publisher Configurations

1. Set-up the delivery options for WebDAV –

   

   Configuration Details –

   1. Provide the Server Name – This is just any name to identify the WebDAV configuration. This is NOT the server name for the BI Publisher or SharePoint / WebDAV server.
   2. Host – It is very important to understand the value for the Host. Depending upon the implementation of SharePoint, the host value can be one of the following –
      • <servername> of SharePoint server. If the web-application not running on port 80, then you must provide the Port number in the “Prot” text box.
      • If you are using Host Headers, provide the host header value in the Host text box. Do not use http:// in-front of the host header when providing the URL.
   3. Select the “Authentication Type”. In this case select “Digest” as we have enabled Digest Authentication on the IIS server of SharePoint.
   4. If you have implemented Proxy server and SharePoint is behind the proxy, then provide the proxy server information.
   5. Click in Apply to save the changes.
   6. Navigate to Report Schedule options and follow the steps below –
      • Navigate to Delivery section and select “Web Folder” option that is displayed.

      

      • Select the WebDAV configuration name (the “Server name” that we gave in the WebDAV configuration) from the dropdown

      

      • Provide the username as password that has access to the Document Library. Since we are using Digest authentication here, you must specify the username as Domain\username.
      • In the “Remote Filename” specify the path along with the file name to the document library. Note that this text box should only contain the path after the domain name. Do not include http://servername before the path. You will get all sorts of permission errors if you do that.

      Click on Submit the schedule the report (if you are testing, ensure that you have selected “run immediately” in the “Time” section).

Navigate to History and ensure that the job ran successfully. Navigate to SharePoint library to ensure that the document has been published.

OBIEE Sharepoint Integration

I was trying to integrate OBIEE to SharePoint (to publish OBIEE reports to Sharepoint) and was running into several issues. There are no resources out in internet that talks about this internet and all of them point to documentations that really does not explain how to integrate them.

Jim Glazar of Kerdock Consulting was kind enough to post an article with screen shots on how to perform this integration. Here is the article.

Thank you Jim for you kind help and sharing your expertise.

HTTP 404 on sites created on newly created managed paths

I ran into very interesting issue today in SharePoint 2007 where in a web application if a new managed path was defined and a new site (site collection) was created under that managed path, the site would work only on the server where the Central Admin was running and not on the other WFE. The URL with the new managed path would work perfectly fine on the Central Admin box but We were getting HTTP 404 for the same URL on the other WFEs.

The existing managed path and sites were working fine.

After couple of hours for debugging, googling and binging with no answer in sight, I decided to re-run the configuration wizard on the WFEs hoping that this would resynchronize the servers with the config database and all web applications. Viola ! once the configuration wizard completed its process, the sites were showing up just fine.

Something (I still wonder what or who the culprit that) caused the WFE’s to get out of sync with the config DB and simply was not refreshing any new managed paths that were created in the system.

If someone faced a similar issue, please be kind to leave a comment on what might be the cause of this issue.

SharePoint Alternate Access Mapping Configuration

There are tons of resources on the web that provide information on Alternate Access Mapping. Some of them are good and some of them confuses an already confused soul. I’ll try to provide my take on AAM for configuring vanity URLs for an internal (Intranet) installation and also try to summarize the links that I found very informative during my attempts to get it configured right. There are several sites that talk about configuring sharepoint for extranet access and to me they all seem to be an interpretation of the AAM Trilogy (Links provided below) by Sharepoint development team. In this post, I’m trying to focus on internal implementations and using AAM for vanity URLs in internal implementation.

As I see it, AAM is just a mapping table. A mapping table of Incoming URLs and Outgoing URLs. SharePoint does not store its web data (pages and othter stuff) with the domain name prefixed in it. It uses AAM to understand the incoming URL and provides the requested information based on the value set for the public URL (outgoing URL). AAM does not perform port redirection or Load Balancing.. We have to rely on external load balancing devices such as F5 or Microsoft NLB. However, there is type of incorrect comfiguration that might lead you to believe that AAM might perform this magic of port redirection. This mistake is explained here very nicely.

For an internal (Intranet) installation, the concept of Extending Web Applications to different zones does not make much sense. There will be duplicate sites on IIS that would be difficult to manage. Simply put we can implement multiple web applications in one of two ways:

1. Use a different port for each web application and then rely on an outside port redirection device such as F5 or application so that users can browse to http://sitename.company.com and access the web application at http://:
2. Create the web applications on port 80 with host headers and rely on a load-balanced set of web front end servers to share the load on port 80.

In the first case, you must add entries to the AAMs so that vanity URLs will be recognized by SharePoint for the web application to which the vanity URL has been assigned. This means for each web application, AAM must contain entries for the vanity URL and entries for each WFE that is participating in the load balanced farm.

Example – For a web application called “http://myserver:8080&#8221;, the AAM entries should be –

http://sharepoint.company.com······Default············http://sharepoint.company.com
http://server 1:8080···························Intranet···········http://sharepoint.company.com
http://server 2:8080···························Intranet···········http://sharepoint.company.com

In the second case, the vanity URL is already assigned to the site via the IIS Virtual Servers host header and is automatically entered into the list of AAMs when web application is created. There is no need to add the additional WFEs to the AAM as all sites are running on Port 80 using host headers the load balancer will send the traffic to a WFE and Sharepoint would know which site to return based on the host header.

Here are some addtional web-sites that I found useful in my quest to understand AAM –

1. The AAM Trilogy by Microsoft SharePoint development team.

What every Sharepoint administrator needs to know about AAM – Part 1.
What every Sharepoint administrator needs to know about AAM – Part 2.
What every Sharepoint administrator needs to know about AAM – Part 3

2. Understaing the concept Virtual hosting is very important to understand AAM. It helps us debunk a lot of assumptions that we make or take for granted.

For Extranet access, I found this post to be very useful for companies that uses F5 BIG-IP for network load balancing.

Access Denied error when adding Wed Front End (WFE) to SharePoint Farm

When installing a SharePoint server to used as a WFE in a farm, ensure that the new server is at the same patch (service pack) level as that of the Farm. Otherwise, you will encounter a “Access Denied” error during the configuration process using the config tool.

The error message looks like this –

Task configdb has failed with an unknown exception
ERR Exception: System.Security.SecurityException: Access denied.
at Microsoft.SharePoint.Administration.SPPersistedObject.Update()
at Microsoft.SharePoint.Administration.SPServer.Update()
at Microsoft.SharePoint.Administration.SPFarm.Join()
at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb()
at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Run()
at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()
The Zone of the assembly that failed was:
MyComputer

The way to resolve this issue is to install SharePoint –> Then install the service pack for WSS. The service pack will launch the config tool as part of the patching process. Once completed, run the MOSS service pack installation to complete the process.

SharePoint Sizing tools

SharePoint sizing can be a daunting exercise depending upon the deployment. There are several companies that involuntary choose to deploy multiple small farms (management headache) and other’s who like to follow a structured single farm deployment using multiple servers.

In either case, we need tools to help us with the capacity planning. In my search, I found, Microsoft and HP provide sizing tools that is not only comprehensive but also details realistic recommendations.

SharePoint 2007 Sizing tool from Microsoft –

This tool is an extension of the Microsoft System capacity planner tool and is part of the “Solution Acclerators” package. The installation requires system capacity planning tool to be installed as base.

SharePoint 2007 sizing tool from HP –

This tool being from HP provides recommendations on using HP servers and other solutions.

Intro to InfoPath 2007

I started looking into using InfoPath Services in SharePoint for the past couple of days. We have a SharePoint 2007 deployment but we are definitely not leveraging the InfoPath services that it provides. I’m trying to develop some useful forms for my organization. Lets see how far I’m able to with it.

To start off, here is great article by Joris Poelmans and here is another one from BizSupportOnline that explains how to publish InfoPath forms in ‘browser-enables’ format to a SharePoint Library. I also another very helpful article on TechNet Blogs that discusses in a good detail how InfoPath Forms can be used to store data directly into a database. This is a well written three part series. Here are the links directly to the article.

Designing a browser-enabled InfoPath form that can store data in a database – Part1

Designing a browser-enabled InfoPath form that can store data in a database – Part2

Designing a browser-enabled InfoPath form that can store data in a database – Part3

I’ll post more information on my adventures with Infopath…. untill then….have a good life.

MOSS 2007 Load Balanced Architecture.

Given below excerpt from Microsoft Technet website on Planning SharePoint redundancy. I’m attempting to install Four servers architecture. I was informed in the past that network traffic cannot be load balanced between web-servers using any hardware load balancers but to let Sharepoint Portal server manage the traffic. So far I’ve found no materials (articles or any bit of information) that indicates MOSS manages Load Balancing out of the box. There are couple of good articles / links on Serve’s Blog that talks about using Software load balancing technique’s such as NLB (network load balancer) with MOSS.

My next step is to experiment installing the architecture below as recommended in the guide and configure F5 BIG-IP using the Deployment Guide for SharePoint from F5

Four-server farm

The smallest server farm that builds in redundancy consists of four servers:

Servers 1 and 2: Web servers and query role installed on both computers. Additional application server roles, such as Excel Calculation Services, can be installed on one or both servers.

Servers 3 and 4: clustered or mirrored database server.

With a four-server farm, you must carefully choose where to deploy the index server role. The query role cannot be deployed to both the index server and another server in the farm to achieve redundancy. This is because, when the index role is installed on the same server computer as the query role, the index role no longer propagates content indexes to other query servers. Consequently, if you install the index server role to one of the Web servers, you lose the ability to host the query role on both Web servers. You can install the index role on the database server, achieving redundancy of the query role on the Web servers. However, the performance of the database server will be affected, particularly when content is being crawled.

Additional application server roles, such as Excel Calculation Services, can be installed on one or both Web servers, depending on performance and availability requirements. In the previous diagram, additional application roles are deployed to only one of the servers in both Option A and Option B. In Option A, performance is optimized if the Web server that is not hosting the combined index and query roles hosts the other application roles. In Option B, the topology is optimized for user requests and queries. Performance of the other Web server can be managed by scheduling indexing jobs during off-peak hours, enabling greater performance of the other application server roles during peak business hours.

The article goes on to say ….

Most organizations require redundancy at the Web tier. There are a small number of scenarios in which a three-server farm with one server running the Web server role makes sense.

The next step is to plan which load balancing technology to implement. Office SharePoint Server 2007 supports two methods of load balancing:

• Software, such as Network Load Balancing (NLB) services in the Microsoft Windows Server 2003 operating system. NLB runs on the front-end Web servers, and uses TCP/IP to route requests. Because NLB (and other software load balancing solutions) runs on the front-end Web servers, it uses the front-end Web system resources, and thereby reduces the resources you can use for serving Web pages. However, the impact on system resources is not great, and a software solution can handle up to 32 front-end Web servers.
• Hardware, such as a router or a switch box. Load balancing hardware uses the network to direct Web site traffic between the front-end Web servers. Load balancing hardware is more expensive to set up than software, but it does not affect resources on the front-end Web server resources. Office SharePoint Server 2007 can be used with any load balancing hardware.

Although not recommended, there is a third method of load balancing, round-robin load balancing with Domain Name System (DNS). Round-robin DNS load balancing can use significant resources on the front-end Web servers, is slower than either load balancing software or hardware, and is not recommended for use with Office SharePoint Server 2007. Also, round-robin DNS load balancing does not take session load into account when routing a user to a server, which can lead to a server being overloaded.

The Office SharePoint Server 2007 deployment guide includes instructions for configuring NLB in Windows Server 2003. If you choose to implement a different technology for load balancing, factor this into the planning and deployment process.

Disclaimer – A part of this article presented above is from SharePoint Planning and Architecture Guide at Microsoft Technet site. This is for my information and my trial purposses only. If posting this is in violation on any copyright, please reach me at prseshan <at> yahoo <dot> com to have the quoted part removed.