Actually we rediscovered it . I had looked at Liferay in August 2008, to establish a community for another company; however they decided, that they could not provide the resources to host an “active” community. Part of providing a community is the nurturing and feeding of the community by providing content on a “regular” basis and responding to comments.

From 100,000 feet, Liferay is essentially an open source version of SharePoint written in Java. Liferay embraces document collaboration, Web 2.0 and social collaboration. A Liferay portal provides one or more organizations with one or more communities. Each community and user has public and private pages. Users can be assigned roles within multiple organizations and communities. Liferay plugins, portlets, can be added to any page by any user based on their “scoped” role. Liferay themes and layouts can be established at the community level or applied to each page.

Liferay provides wiki and blogging editors that can be configured to support either the FCKeditor or TinyMCE. This allows users that are already familiar with other Social media tools to be immediately productive. One of our litmus tests for wiki and blog usability is: can a user “easily” learn to how create an attractive blog or wiki that is media and content rich without having to result to editing raw HTML? This should be possible without formal training. Yeah, I expect the user would read some documentation and view some training videos; however, since more and more users are using social media sites, they are looking for their corporate tools to resemble their other tools. The workflow in these tools should allow the user to work top-down as they are thinking. Although not perfect, we find that Liferay passes this test.

One of the disruptive behaviors of internet-based systems and web 2.0 is that corporate systems and vendor applications lag many internet applications in technological advances. This means that users are often waiting for the applications that they use at work to catch up with the ones they use personally.

Liferay allows the use of existing content or the dynamic upload of content while you are are writing. SharePoint 2007 only supports use of previously stored content while editing.

Okay, I know that you can open another browser window; upload some content; and then switch back to your wiki/blog window to complete the wiki or blog entry. However you cannot imagine how many users do not think of this or understand this. I been around long enough to realize that means that there is likely a disconnect between the user’s desired workflow and the product workflow.

The Liferay wiki and blog editors work equally as well with Internet Explorer,IE, and FireFox. SharePoint 2007 provides a more robust experience to IE users. With SharePoint, in my opinion, wiki and blog editing in FireFox feels like an “unwanted disease”. This is unfortunate. There are standard JavaScript libraries that abstract browser dependencies. There is simply no technical reason that SharePoint can’t provide a first class experience to most browsers. The Liferay content portlet can contain javascript, this allows easy integration with a plethora of other social media and web-based applications. Ironically, I placed my Windows Live status with a button into a Liferay content portlet and it behaves correctly. I could not do this with SharePoint. The SharePoint editors deleted the javascript code. The Liferay Wiki can be configured to support Creole or Camel-case wiki editing.

You know, SharePoint could learn a lot from Liferay.

stsadm -o activatefeature -name feature-name -url websiteurl -force

The synopsis of the code is:

• Start with the sharepoint site object.
• Loop through all of the sub-sites.
  • Get the website url for the sub-site.
  • Call stsadm to activate the feature for the sub-site.

The PowerShell code

## Reference to SharePoint DLL
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
## Probable location of sharepoint STSADM utility program
$stsadm = "$env:programfiles\Common Files\Microsoft Shared\Web Server Extensions\12\BIN\STSADM.EXE" 
 
############################################
# Activate-feature-onSite [-feature  |-url  ]
############################################
function global:Activate-feature-onSite($feature, $url)
{
$spsite=new-object Microsoft.SharePoint.SPSite($url); 
 
for($i=0; $i -lt $spsite.AllWebs.Count;$i++){
   $websiteurl=  $spsite.AllWebs[$i].url;
   $sResult = &stsadm -o activatefeature -name $feature -url $websiteurl -force
   if(!($sResult -like "*Operation completed successfully*")){
      Write-Host -ForegroundColor "red" -BackgroundColor "white" "Activate of feature '$feature' for '$websiteurl' Failed! `n $sResult"
     }
   }
$spsite.Dispose();
} 
 
# to call
Activate-feature-onSite "feature" "http://site"

• This first way, involves placing an HTML file on your site using an Google generated HTML file name.
  This must be placed in the root directory of you site.
• The 2^nd way involves placing a Google generated meta tag in your site’s default webpage.

Based upon my previous experience with SharePoint, I tried the HTML file first. Using Internet Services Manager I determined the physical directory that was mapped to the virtual directory for my SharePoint site. Next, I created an HTML file in that directory using the name that Google provided and “viola”, I figured that I was done. Unfortunately, the way SharePoint sites are registered into IIS, a SharePoint site would not render my HTML file from this location. This results in a 404 error. On to the meta tag option.

My 1^st attempt at the meta tag option was to create a hidden “Content Editor Webpart” on my site’s home page and place the meta code in it. I suspected that this would not work as the meta tag needs to go into the head section of the HTML page before the body section. Sure enough, it did not work.

My next approach was to determine which file that I could modify to place my meta tag in.
I’m sure that there is a SharePoint Designer way to do this. However, if you are using the free version of SharePoint 2007, then I figure you may not want to buy SharePoint Designer.

SharePoint sites open with a default.aspx file that is based on the site type. There is are seperate default.aspx for Team Sites, Blog Sites, etc. Each of these default.aspx files include a default.master. The default master can be overridden on a site by site basis by editing the default.master in your site’s “Master Page Gallery” by accessing “Site Actions” –> “Site Settings” and then selecting the “Master Pages” Link in the “Galleries” section. Rather than change the default.aspx which would affect all sites of a type running on my server, I decided to change the default master for my site.

To change the default.master, you will:

• check it out.
• download a copy
• edit it with notepad (or some other text editor) and place your meta tag
  I chose to place my Google meta tag just below the
  <META HTTP-EQUIV=”Expires” content=”0″>
• upload the update
• check-in the file

You can verify that this is correct by visiting your site’s homepage and then viewing the page source via your Web Browser. If you can see your verify code, you are ready to verify your site with Google and move to publishing your sitemap.

Getting my sitemap into google
In order to get Google to download my sitemap, the sitemap file, sitemap.xml in my case, would need to be anonymously accessible form a url on your site that Google lets you specify. I already knew that I could not simply place the sitemap file into the root directory of my website. My solution was to create a SharePoint document library in my site, provide anonymous read access and upload the sitemap.xml file to that library.
Then I entered the sitemap url into Google.

WSS 3.0 provides a control SPSecurityTrimmedControl that allows the conditional rendering of content based on a users permission. Using this control, I was able to restrict who would be shown People and Groups on my site.  To do this I modified the people.aspx and the groups.aspx files for my site.

A word of caution: I have no doubt that when applying a future service pack, Microsoft will overwrite my changes. Therefore I’m managing my changes externally from the Microsoft SharePoint directory. This will allow me to difference new code from Microsoft and reapply my changes.

people.aspx
The file people.aspx resides in the \Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS folder. It lists the persons in the site. After I made a backup copy, I opened the file in a text editor and located the start of the “PlaceHolderMain” asp:Content section and added the start of my permission change

before

<asp:Content contentplaceholderid="PlaceHolderMain" runat="server">
	<asp:PlaceHolder id="PanelAllPeople" runat="server">
	 <div class="ms-listdescription">

after

<asp:Content contentplaceholderid="PlaceHolderMain" runat="server">
<SharePoint:SPSecurityTrimmedControl runat="server" PermissionsString="ManagePermissions">
	<asp:PlaceHolder id="PanelAllPeople" runat="server">
	 <div class="ms-listdescription">

I located the end of the “PlaceHolderMain” asp:Content section and completed my permission change.

before

	<asp:HyperLink id="LnkCallTo" runat="server"
		Text="<%$SPHtmlEncodedResources:wss,people_callbuttontext%>"
		style="visibility:hidden;display:none"
		NavigateUrl="callto:" />
</asp:Content>

after

	<asp:HyperLink id="LnkCallTo" runat="server"
		Text="<%$SPHtmlEncodedResources:wss,people_callbuttontext%>"
		style="visibility:hidden;display:none"
		NavigateUrl="callto:" />
</SharePoint:SPSecurityTrimmedControl>
</asp:Content>

I also located the modifed the “PlaceHolderLeftNavBar” asp:Content and made the similar changes as above to require the user to have ManagePermissions as well.

groups.aspx
The file group.aspx resides in the \Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS folder. It lists the groups in the site. After I made a backup copy, I opened the file in a text editor and made the same “PlaceHolderMain” asp:Content section changes as I had to people.aspx.

Overview of SPSecurityTrimmedControl

The SPSecurityTrimmedControl conditionally renders the included contents only when the current user has the permissions defined by the PemissionsString.
An example requiring the user to have “ManagePermissions”:

<Sharepoint:SPSecurityTrimmedControl runat="server" PermissionsString="ManagePermissions">
<!--
...
... code being managed ...
...
-->
</SharePoint:SPSecurityTrimmedControl>

Here are some of the values for the PermissionsString

The full list is on msdn.

The 1^st thing that I did was to create and install an SSL certificate for my web site. Afterwards, I went to configure SharePoint.

Most of the published information on this topic has you start with SSL when you Create a Website or Extend a website by publishing the information to a new website within the SharePoint farm. I’d already created the site so I was hoping to avoid this.

After checking through the site settings and then Central Administration settings, I found the Alternate Access Mappings in Central Administration.

• Open up the Central Administration site
• Select Operations
• click Alternate Access Mappings under the Global Configuration section.

The alternate access mappings defines internal URLS, zones and Public URLS that a site will respond to. In my case I wanted my site to be open to port 80 to Office 2007 and IE on the Intranet and use SSL on the internet. After some investigation, I set my mapping as follows:

• Default zone  — https and the FQDN of my website and SSL certificate.
• Intranet zone — http and my webserver’s computername.
• Internet zone — http and the FQDN of my website site.

These seem to be working pretty well, I’ll update this post if I learn anything more.

It appears, that if your webserver server hosts multiple SharePoint sites, then you would need to supply alternative mappings for any additional sites that you want to respond to SSL.