In The Mix

As a SharePoint architect I have the business behind me and the Developers and IT Pro on my shoulders.

SharePoint Hosting vs Owning July 27, 2008

Filed under: SharePoint — fmuntean @ 3:45 pm

Now that the SharePoint have matured we see and get asked about Hosting of SharePoint outside of the company.

This post is to show some of the differences between having your SharePoint hosted outside the company using a third party provider and having it installed inside your company.

Hosted

Owned

PRO:

  • No hardware required.
  • No worries about licenses.

Con:

  • Monthly payment
  • Usually only the WSS level
  • No integration with external systems as AD, Exchange, File Shares, LOB applications
  • Poor integration with Office Client applications.
  • No access to Central Admin.
  • Only one Site collection.
  • No alerts or email integration
  • No possibility to install custom code or web parts.
  • Use only of the available site templates.
  • WebDav access restricted
  • Limited users access
  • Limited Public access
  • Limited storage

PRO:

  • Inside the Firewall
  • Any level of SharePoint
  • Integration with your AD.
  • Full integration with internal LOB Applications.
  • based on business need
  • Receive alerts and send e-mails to lists.
  • WebDav access.
  • Enterprise Search
  • Multiple Web Application and site collections
  • Can install any custom code, Web Part, and site template.
  • Full integration with Office 2007 client applications.
  • Can scale up to meet you needs.

CON:

  • Need hardware.
  • Install and Maintenance resources needed.
  • License

 

I would recommend the use of Hosted SharePoint to get the taste for it but for real needs I recommend owning it.

As a note both Microsoft Search Express 2008 and WSS 3.0 licenses are included with Windows 2003. So if you already have Windows 2003 you are just one step away from owning it.

I see only one good use for SharePoint hosting and this is when you are using SharePoint Farm publishing for Internet sites. For more info on this drop me a comment.

If after reading this you still want to check and see if hosting SharePoint meets your needs check this link: http://www.microsoft.com/serviceproviders/directory/wssv3.mspx

 

Authentication in SharePoint July 10, 2008

Filed under: SharePoint — fmuntean @ 3:00 pm

Authentication is the process of determining whether someone or something is, in fact, who or what it is declared to be. In private and public computer networks (including the Internet), authentication is commonly done through the use of logon passwords. Knowledge of the password is assumed to guarantee that the user is authentic. Each user registers initially (or is registered by someone else), using an assigned or self-declared password. On each subsequent use, the user must know and use the previously declared password. The weakness in this system for transactions that are significant (such as the exchange of money) is that passwords can often be stolen, accidentally revealed, or forgotten.

Logically, authentication precedes authorization (although they may often seem to be combined).

For SharePoint there are two major types of authentication:

a. NTLM

One of the most common and used type of authentication for an Intranet is NTLM or Windows Authentication. The user information is stored into an Active Directory inside the company and a dialog is presented to the user for password validation. By using this authentication mechanism the user needs to know the domain name and most of the times he/she does not have an easy SharePoint access to change the password, however there are third party web part that facilitates the process of resetting the user password.

This method offers the best integration between the client applications and SharePoint.

b. FBA (Form Based Authentication)

Starting with WSS 3.0 / MOSS 2007 a second type of authentication is possible. This is named Form Based Authentication (FBA) as it provides the user with an ASPX page containing a form to fill out with user name and password. This is possible because now SharePoint sits on top of ASP.NET 2.0 Framework.

The FBA from ASP.NET 2.0 is a pluggable mechanism that allows for easy customization of the user authentication mechanism for any web site.

There is already code written for storage of the user credentials on SQL server, Active Directory using ADAM, and SharePoint Lists. The system can be extended to any other storage by writing code in a form of Membership Providers, for storage of the user information, and optionally Role Providers, for storage of the groups.

The most used ones are the AspNetSQLMembershipProvider, and AspNetSQLRoleProvider available out of the box with ASP.NET 2.0 that provide easy configuration of Form Based Authentication using SQL server as a back end storage of the user information.

c. DELEGATED AUTHENTICATION

Why do I show you now a third option when I previously said about only two options for authentication? Because this is the last authentication method that I want to describe and is based on FBA authentication.

Delegated Authentication is nothing else than a custom FBA authentication where you can use a trusted third party outside the company to store and authenticate the users.

One of the authentication providers is Microsoft with its Windows Live ID API that offers Delegated authentication for ASP.NET 2.0 web sites thus giving us the possibility of using it for SharePoint too.

By using a trusted external provider for authentication you are not responsible for storing and maintenance of the user password inside your system, however you will still need to present the user with a way to input the necessary information as user display name, email address, phone number and other information that you see fit.

 

Authorization in SharePoint July 9, 2008

Filed under: SharePoint — fmuntean @ 3:00 pm

No matter which authentication mechanism you are using for validating the users into your system you will be still responsible for giving them access to the necessary areas inside SharePoint using SharePoint administration pages.

Because of the type of collaboration between the enterprise and external stake holders a closed attention needs to be taken when assigning rights into the system.

Site collections offer a way of segregating the user rights and information access inside SharePoint.

A single site collection is a simple way to give users rights into the SharePoint and offers but when it comes to areas of the site where user should not have access the administration became harder as permission inheritance needs to be broken. Personally I would not recommend to break the security inheritance more than once on any web navigation tree and the security break should be made so that the sub-webs are more restrictive and not the opposite.

For an external collaboration this means that for each site the security needs to be broken to achieve a level of protection between collaborator from different projects or companies.

By using multiple sites collections ease the permission administration as they are separate entities all together. Another benefit from using site collection if the ease of separate backup, restore and archival of projects sites using out of the box commands.

However the sharing of data between site collections is harder and custom code is needed to achieve that.

Usually for an Intranet site a single site collection will suffice, but for external collaboration where security is more restrictive Multiple Site Collection might be the right approach.

 

SharePoint does support .NET Framework 3.5 July 7, 2008

Filed under: SharePoint — fmuntean @ 8:21 am

This post is for people who were wondering if SharePoint 2007 supports .NET 3.5, and the response is YES.

Paul Andrew , Microsoft Technical Product Manager for the SharePoint Developer Platform, backed by TechNet posted about this on April 2008.

Read his post here:

http://blogs.msdn.com/pandrew/archive/2008/04/18/sharepoint-does-support-net-framework-3-5.aspx

  This is good news for Developers as now you can use the latest .NET features when developing using SharePoint API so now take some courses and become an expert in the latest technology.

  Good Luck!

 

Creating Custom MySites July 1, 2008

Filed under: SharePoint — fmuntean @ 4:24 pm

Recently I was asked to create custom MySites, so I start looking how the MySites get currently created in MOSS 2007.

By using SharePoint Designer 2007 I have easily found that the Mysite link is on the Master page as expected sitting inside of a <SharePoint:DelegateControl> with ControlID=”GlobalSiteLink1″.

This is great news: we can change the control by using features without directly changing the master page. If you want to read more about this special SharePoint control follow the link to “The SharePoint DelegateControl Uncovered” on Patrik’s Blog.

For now let’s continue explaining the current implementation done by Microsoft.

The current control is “~/_controltemplates/mysitelink.ascx” with a sequence of 100 and points on the My Site Web App to a system page named “/_layouts/MySite.aspx”.

The “~/_controltemplates/mysitelink.ascx” control  inherits the Microsoft.SharePoint.Portal.WebControls.MySiteLinkUserControl class inside the Microsoft.SharePoint.Portal.dll assembly.

The next step was to take the Reflector and look inside that class.

The “/_layouts/MySite.aspx” page is hard coded (bad bad practice) inside the SetControl() method.

The MySite.aspx system page inherits the Microsoft.SharePoint.Portal.WebControls.CreatePersonalPage class inside the Microsoft.SharePoint.Portal.dll assembly.

On the FormLoad() method there is code to look for the userProfile.PersonalSite that is the equivalent of userProfile[PropertyConstants.PersonalSpace] and if empty create a new site by calling userProfile.CreatePersonalSite() public method.

Moving forward I found that inside that method the site template is hard coded (bad bad practice) to SPSPERS#0.

Now armed with all this information we can decide how to create a custom one.

There are few approaches:

1) Just modify the SPSPERS#0 site template on the file system.

2) Modify the MySite.aspx to derive from another page that you created and on FormLoad() create the site from another template. Make sure that you create the site during the POST because it does not work if trying to create it during GET.

3) Create a new MySiteLink control with a sequence lower than 100  that will replace the default one for MySite and point to a different system page of your own. That page will create the personal site or redirect to one if another already exists.

The preferred approach would be 3) as it offers the maximum flexibility and has the minimal impact on the farm if Microsoft decides later on to change the mechanism. Plus this option offers the possibility to safely deploy the custom MySites as a solution that later on will not be affected by HotFixes or Service Packs.