SharePoint Powers SaskEnergy

  • Article

Will Craddock is the president of the Regina IT Professionals group and is part of the IT team at SaskEnergy.  SaskEnergy is Saskatchewan's natural gas distribution company, a provincial Crown corporation with roots of more than half a century in Saskatchewan.  About 8 months ago Will mentioned the SharePoint 2007 deployment they we planning and I got him registered with the IT Pro Momentum program which is a program aimed at supporting early adopters.  Recently I asked Will how the project was going and he said SharePoint had been deployed and agreed to share the experience.

------------------------------

How is SaskEnergy using MOSS 2007?

We are using MOSS as a presentation layer for our internal communications with employees at this time. Our first utilization of the product was to build a proof of concept application to collect employee’s time, attendance, expense, and mileage information for a specific pay period and interact with our ERP (JD Edwards Enterprise One) in the collecting, displaying and posting of this information. This POC was done as part of the Momentum program for early adopters at Microsoft. After successfully building this POC, utilizing custom web services to interact with JDE, we moved on to investigating production solutions that fit the SharePoint development path.

Our intranet is now being redesigned and will be deployed in small pieces over the next couple of years based on MOSS. This allows us to take advantage of the content management, document management and workflows native to MOSS 2007 to enhance the user experience. Our first production solution based on MOSS was deployed in December; it took student applications submitted from our external facing website via a form and through a SharePoint timer process, grabs them and moves them to SharePoint for internal review.

Here is a brief view of what we accomplished:

  • Created an ASP.NET application to accept new student applications.
  • Created a WCF JobApplication service using the Web Services Software Factory that:
    • Accepts new job applications and stores them into a SQLServer 2005 database
    • Returns all job applications that have been submitted as of a certain date/time. The reason for having an intermediate SQLServer is due to a one-way-trust relationship between the web domain and internal corporate domain
  • Created a MOSS job applicant document library within a Human Resources portal complete with custom views so that staffing advisors can quickly discover eligible job applicants, and organize applications by experience level, interest, and diversity candidates.
  • Created custom content type for the job application library.
  • Created a MOSS timer job that requests job application data from the JobApplication service and stores the data in the document library.
  • Created a WCF service proxy used by both the ASP.NET and MOSS timer job further providing reuse between tiers.
  • Used Enterprise Services security and logging code blocks in the WCF service, ASP.NET, and MOSS applications.
  • Created a MOSS solution package to easily deploy the portal, library and timer job to dev, test, and production. This was key, especially during testing when there were a lot of changes taking place.
  • Use MSF4ASD and Visual Studio Team System 2005 and MS Project 2007 as the philosophy and toolsets for running the project.

This was the first time SaskEnergy deployed all of these technologies into production. Elapsed time took about 2 months. I'd guess that if we were to condense all of the development and testing time, we'd be able to say that a team of 3 guys took 3 weeks. Not bad considering we also had to come up with a bunch of our development process and toolsets.

The XML data architecture, service layer, and MOSS pieces will be easily reused as HR expands their need from student job applications to general job applications. The driving approach to the design was trying to keep as much SOA thinking as possible. There's not a way we could have created this solution in that time frame with our 'old' toolsets - not even close.

What was the driving force (technically) for deploying MOSS 2007?

The driving force for us technically is the quickness to delivery SharePoint provides in developing and delivering solutions. In a common and repeatable interface we are able to deliver so many different functional features that allow portals to be delivered any number of initiatives. From a development perspective this is a very big thing for us as we have standardized around building .net applications and this just becomes another tool in the box for us. The great thing from a technical perspective is the ease of implementation. We have put in a farmed solution in separate environments (DEV, UAT, and PRD) all on a virtual platform (VMWare).

What were some challenges you faced before deploying MOSS 2007 and how were they addressed?

In the creation of the DEV environment, we experienced issues around the establishment of the farm. Specifically the issues were around Security, Kerberos, and the certificate server within the SharePoint environment. We worked through many of these issues with the aid of the SharePoint Administrators Guide written by Bill English as we refined out Architecture in an iterative fashion until we were satisfied it was working correctly.

After implementing the certificates and the certificate server, we were not able to pass the tokens back and forth as some of the services would not start or stop. We engaged Microsoft through the Premier Support area to help us resolve this issue. We provided them all the information on the issue, documentation and etc and they provided various product experts as we rebuilt the environment with their input as this error had never been seen given the architecture was following the Microsoft best practices.

During the installation and configuration of the Microsoft Office SharePoint Server 2007 platform at SaskEnergy, a couple major problems arose.  Because SharePoint 2007 is a very new product, there was little or no Microsoft documentation or tools available to troubleshoot the problems we were having.  The Microsoft website had no solutions for the problems and a search of popular SharePoint blogs showed that other people in the world were running into the same issues.  In order to learn more about SharePoint, Jereme Watts (SaskEnergy’s SharePoint Admin onsite through Solvera Solutions) attended a SharePoint conference in Las Vegas.  While there, he learned that our SharePoint architecture at SaskEnergy was considered to be excellent and far more advanced in comparison to many other installations.  Unfortunately, he was not able to determine the reasons for the problems being experienced with SaskEnergy’s multi-server SharePoint environment.

After returning, Vance Petriew (SaskEnergy DEV Network Support and SQL Admin onsite through EDS Canada) and Jereme Watts spent many hours narrowing down the issues and documenting the test procedures.  Progress was made but no solutions were found.  In the mean time, SaskEnergy called upon Microsoft and utilized a Premier Support call to help speed up resolution to our problems. 

Upon being contacted by Microsoft within a day of placing the call, we were asked to provide our server documentation and troubleshooting steps used to arrive at our analysis of the problem.  The Microsoft consultants were very impressed with our thorough documentation and methodical testing procedures.  Because they could easily see that we had done our homework, they did not hesitate to bring in the real Microsoft Engineers who wrote SharePoint, Kerberos and Windows Server to help find us a solution.    During the 20+ hours on the phone with the various Microsoft Engineers, we methodically worked through the different divisions in Microsoft responsible for certain aspects of their products.  We gathered many network traces to analyze how each server request and response was being handled between the different products. 

During the troubleshooting with the Microsoft engineers we learned a few key points that are not written in any book or documentation.  These points were key factors in finding a solution.

When one Service Principal Name is configured to point at two service accounts, Kerberos authentication reverts back to NTLM authentication.
DNS records for SharePoint sites need to be defined at the root of the DNS tree in order to have SharePoint crawl websites properly.  This is due to the way SharePoint handles and truncates DNS entries inside the application.

In addition to the undocumented features listed above, there were a few other very useful results we learned during troubleshooting.

  • The entry point for crawling a site needs to be defined by a wildcard.
  • Reliable Kerberos authentication only works when Kerberos is forced to use TCP communications instead of UDP.
  • Kerberos Service Principal Names are only defined on IIS Application Pool service accounts.

One of the comments we heard from the Microsoft consultant made us smile.  The consultant had tried getting Kerberos authentication to work with his SharePoint installation and couldn’t do it.  His configuration kept reverting back to NTLM authentication.  This confirmed in our mind that configuring SharePoint 2007 to use Kerberos authentication was a very difficult task which is also echoed across the many SharePoint blogs on the web.  SaskEnergy is now one of the few places that have been able to make this work.

Overall, working methodically through this issue with Microsoft was beneficial on both sides.  They were obviously as interested in our problem as we were since they brought in their highest level engineers to find a solution.  During the process, the Microsoft engineers identified a couple items to take back to their teams to improve.  On the SaskEnergy side, we learned that our configuration was very close to being correct and that our architecture design is solid. 

Also of note is how pleasant the Microsoft support team was to work with over the phone.  They were always courteous and answered our questions politely even after 20+ hours of collaboration.  When we finally figured out the last piece to the puzzle (the DNS issue), Microsoft was very generous in their praise towards our team and confirmed that the solution made sense.  The whole experience with the Microsoft premier support was excellent and worthy of very high ratings.   

What were some issues you faced with the actual deployment and how did you address them?

Our deployment to production has been very smooth as we were able to take care of all the issues in the DEV and UAT areas. This speaks to how this methodology works as effectively in the IT Pro world as it does in the Development world.

What is the “killer feature” that you found in MOSS 2007?

We love all the features of SharePoint, consistent information management, template driven, document management, workflow, enterprise search, the speed to deliver a product but what really is the killer feature is the product suite. We can find many products that do one or two of these things well, but none that covered the entire suite well. I admit that other products are stronger at the niche specifics, but dollar for dollar they do not compare when you are looking at the price for an entire solution. So the killer feature in SharePoint is “SharePoint”…it is the plumbing for the house in a box; you just need to add the fixtures for it to work