Tuesday 26 October 2010

Updating the web.config

Problem: Updating the web.config by hand means you need to implement the change on each web servers web.config, so in a load balanced environment you need to do the change several times which leaves is open to mistakes and in the event of a rebuild or adding a new server, each web.config needs to be updated.

Hypothesis: You can either use a declarative approach or a programmatic approach.  Approaches on MSDN

Declarative approach is show on MSDN as the supplemental .config file You can implement the change using the ststadm cmd copyappbincontent or use a feature receiver
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
var webApp = (SPWebApplication)properties.Feature.Parent;
webApp.WebService.ApplyApplicationContentToLocalServer();
}
Note: The feature must be scoped at "Farm" or "WebApplication" level otherwise you will get a Security exception, which makes sense.  RunWithElavatedPrivileges won't stop the error.

Resolution:  The declarative approach adds whatever is in the supplemenal config to the web.config, it does not check if it's already there so it is an option for a 1 off hidden feature however a better approach is to use an xml file that has a feature receiver that activates and deactivates the changes for maximum control.

More Info:
Additional information on using the declaritive approach.
Joel Jeffery's blog has a post on modifying your web.config programatically
Update 13 Dec 2010 - http://www.spdavid.com/category/SharePoint-2010.aspx

Monday 25 October 2010

Using SPGridView and Linq to display filterable lists

Problem: Display a SharePoint list and make it filterable. 

Initial Hypothesis: Create new page add the new Xslt List View Web Part (XLVWP) to the page. Customise the Xslt using SharePoint Designer (SPD).  The web part can now be exported if required.  Add filter web parts to filter the data for end users.

Resolution:  This gives a comprehensive solution for internal users but clients needing a specific design or advanced querying will need a different solution.  You can customise the xslt for the list and paging and sorting are built in.  However in my instance I needed drop down lists that could query against multi select choice columns. 

Problem Redefined: Using the SPGridView control display user's data based on selection criteria.

Hypothesis:
  1. Create a list that contains a choice column, the column should allow multiple choices.
  2. Ensure your generate a Linq to SharePoint proxy
  3. Create a Visual Web Part project that uses a visual web part to display the list results and the results are filtered by a drop down lists that works against the SharePoint list.
Resolution:
Filter the SPDataGrip using LINQ to SharePoint as shown below:
Step 1: Create the "Customers" list.
Stet 2 : Add the new column based on a multiple choice field type.

Shown above is my custom list "Customer", it has two columns namely: "Title" of type string and "Industry" of type choice (multi)
Step 3: Add a few random records.
Step 4: Create a new Visual Studio project, I chose a "Visual Web Part Project".
Step 5: Add the generate SPMetal code to your new project.  I used the SPMetal template provided by CKSDev but as long as you have added the SPMetal for the new list it will work.
Step 6:  Open the user control ascx and add a SPGridfiew and a drop down list.
Step 7:  In the code behind add the Linq query to retrieve the Customers list.
Different approach for using LINQ to SharePoint for this step is:

Step 8: Deploy you code and ensure it is working.

Friday 22 October 2010

Extranet user access options - Farm architecture design considerations

Problem: What is the best approach for an extranet?

Hypothesis:
You are implement SharePoint 2010 and you need users to have remote access, the 2 key technology impact areas are:
• Authentication to SharePoint 2010; and
• Remote access mechanism (External users).
I will deal with each question separately for simplicity.

Authentication
SharePoint 2010 has 2 mechanisms for authentication: classic (MOSS approach) and claims based. I would almost always recommend using Claims based authentication as this allows you to hook into any credential provider such as LDAP, AD, SQL or a custom provider. For example a recent project involved authentication from Active Directory & an IBM LDAP provider, this was relatively easy to do using claims based authentication.  If you have a custom Single Sign-On (SSO) solution you can write your own claims provider.
Remote Access
The answer for where to deploy SharePoint is … “It depends on what you have currently, your licencing and security requirements.”

Option 1
You can put SharePoint in your DMZ (public area) and use a reverse proxy and allow users access to you SharePoint farm. You will probably want to use SSL between the external end users and the reverse proxy.  The traffic between the SharePoint Farm the proxy won’t be under SSL. This approach is good for easy access, high performance and easy setup. This approach is not as secure as getting users to login to your network using VPN access. The advantage is you merely need SSL setup (my preference is firewall SSL termination i.e BlueCoat, most hardware firewalls offer this including F5’s Big-IP, you can also use the latest ISA/UMG proxy software to do SSL termination. Microsoft’s ISA 2006 has SSL termination built and is a pretty good solution. I believe UMG is the update to ISA.  SharePoint requires sticky sessions so if you are using a hardware or software based load balanced, you must have sticky sessions enabled.

Option 2
Another option is to use SSL NIC’s or my least favourite but most commonly used option is SSL on the server. You can still have your firewall in place but you don’t use a reverse proxy. I would definitely go for a reverse proxy with external access over SSL but this options is available on smaller SharePoint farms.  You can also load balance using NLB.  SSL adds about a 35% overhead to CPU resources on the server and SSL NIC cards can drastically improve CPU utilisation, however I would prefer to terminate at the firewall if possible.

Option 3
VPN solutions – Either IPSec or SSL-VPN’s are a good option but it depends on your infrastructure as setting up a VPN is a program in itself. Remote offices are already on VPN or some tunnelling technology but this doesn’t work for home users or 3rd parties as you need to give them remote access which generally involves RSA token or some sort of security token. This is the most secure option and once a user is on the network they will access your private SharePoint farm over http.

Resolution:  The general answer as always in SharePoint is "It depends ...".
I would recommend profiling all type of possible users something like

Role: Head Office User
Description: Http access from the LAN authenticating using AD.


Role: Satellite Office User
Description: Remote office has a VPN tunnel/MPLS to the head office, employees are authenticated using AD and will use http to access the SharePoint farm.

Role: Employee at home
Description: http (SSL-VPN) AD Employees have SSL-VPN access and once connected used http to view the SharePoint farm.  Authenticated using AD.


Role: 3rd Party users https SQL database or AD
Description: Suppliers need to with SharePoint, they will access 2 SharePoint load balanced servers in the DMZ using https.  The firewall is an ISA server 2006 which offers SSL termination and host header redirection.....

You can also surface the same site using different urls, so have an internal site and then a site in the DMZ.

When doing your farm architecture other points to bear in mind are redundancy, performance & licencing.  This coupled with your existing technology status and your SharePoint will provide a accessible, stable, scalable, preformant, secure SharePoint farm.   Designing your farm will reduce you licencing costs dramatically while providing the best solution to the business.

Thursday 21 October 2010

Feature is always activated for features targeted at a web site (web)

Finding: Feature scoped at "web" is always activated when deploying using Visual Studio 2010.  Regardless of the "Activate on default" setting, - thanks Matthew.

Tuesday 12 October 2010

CKSDev tool issue - The custom tool SPMetalGenerator failed

Problem: When adding a SPMetal Definition (CKSDev) item in visual studio, the SPMetal proxy generation fails with the error message: The custom tool 'SPMetalGenerator' failed.  Object reference not set to an instance of an object.

Hypothesis: CKSDev item template is failing, next I tried SPMetal from the command line and received the "Invalid File Name" error.  I had previously fixed this issue and here is the link.

I check the issue using the browser:

Resolution: Delete the list showing the Invalid file name error.  I could not do it from the UI so I used PowerShell.

More Info:
http://sp2010uk.blogspot.com/2010/08/issues-with-site-columns-content-types.html

NullReferenceExcepetion when viewing/editing an existing list item after the list instance has been deployed

Problem: When viewing or editing and item in a list, I receive an application error (NullReferenceException).  This happens when I redeploy a list, my list is defined using site columns, content type and the list definition is based on the content type.

My ULS logs contained the following information:
Failed to cache field with id
Unable to open Lookup list 'Lists/xxxList'.[Error was 0x8007....]
System.NullReferenceException: Object reference not set to an instance of an object.   at Microsoft.SharePoint.Publishing.FieldCache.TryGetValue

Initial Hypothesis:  ULS logs show me that a lookup list is not being found.  By examining the columns on the list instance I can see they are not being created correctly.  My initial thought was my xml was wrong, once it was reviewed and I found it to be correct I realised it was a caching issue.

Resolution:  Clear the Visual Studio Cache
  1. Right click on "Project" in Solution Explorer and click "Retract";
  2. Close Visual Studio 2010; and
  3. Open the "Project" in Visual Studio 2010 and "Deploy" the solution.