Microsoft Sharepoint Certification – Benefits for Employer and Employee

Microsoft has always been a proponent of technology certification through its MCP (Microsoft Certified Professional) program and MSDN Learning portals with guidance to plan and prepare for their certifications based on technology of your choice.

However, employers and employees alike are often at crossroads of whether the Microsoft certifications are actually beneficial for either of them. Here are some points in favor of both parties:

For employer’s, the perks lie in achieving certain competencies within the organization (yes, since 2010 Microsoft made key changes to the partner program that Gold or Microsoft Certified Partner labels did not apply to the whole company per say but to specific competencies within the organization) and demonstrating that they are dedicated towards maintain those competencies. The requirements to demonstrate these competencies among others are to show that your workforce meets the requirements for number of certified individuals with those competencies.

                                   

Specific to Sharepoint, Microsoft has consolidated the process of becoming a Microsoft Sharepoint Partner. They are divided into 2 groups namely System Integrators and Independent Software vendors.

System Integrators – Helping customers realize full business value of their Sharepoint investment including social; Enterprise Search and surfacing LOB (line of business) data in Sharepoint.

Independent System Validators – providing solutions leveraging cloud based platform for business intelligence, advanced visualization, project portfolio and business process management.

The new Collaboration and Content competency merges the previous competencies: Portals and Collaboration, Content Management and Search. Further reading on the competencies and how to achieve partner status here.

For employee’s, the perks are in achieving certification and Microsoft accreditation which can help them gain better visibility within the organization as well as the industry. Nowadays, it has relatively harder for companies to screen and assess competencies which are ever changing and rapidly progressing (compare MOSS to 2013). This gives certifications more weightage when assessing talent and required skill set based on requirements.

Below is the certification plan for MCSD (Sharepoint Developer) in 2013:

(Images and content copyright of Microsoft, the views expressed here are mine)

Detecting Google Chrome in ASP.NET code behind

We recently got a requirement to detect the browser type and browser version in our cross browser compatible application. Now, immediately we had two choices. Either we can do this from the Javascript or through code behind. We opted for the later due to the ease of implementation.

There are 2 ways (of which I am familiar) by which we can achieve this:

Using System.Web.HttpBrowserCapabilities Class which includes a Browser property through which
we can get Browser, MajorVersion and MinorVersion. (MSDN Article)

(Or)

Using Request.UserAgent Property through which we can get the raw user agent string of the client browser.

(MSDN Article)

We went for the former approach and quickly found out that since Google Chrome and Apple Safari are both based on the WebKit layout engine, Browser.browser returns “AppleMAC-Safari” for both browsers!

When we try to get the user agent string, it however makes more sense, see below:

For Safari:

"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.17"

For Chrome:

"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.30 Safari/525.13"

So in order to distinguish between Safari and Chrome, we added one more step to the process i.e. We check the UserAgent String to see if it contains Chrome keyword.

if (Request.UserAgent.ToLower().Contains("chrome"))

{

strBrowserType = "Chrome";

}

That seemed to solve the issue of browser recognition!

Issue with MOSS 2007 Central Administration

Out of the blue, the Central Administration (CA) in the development server started acting up today (Unknown Error on accessing the CA). Although, except for a new custom web part that I hosted today, there were not any changes to either IIS or web.config.

So I went about the usual steps taken for working around any issues with MOSS listed here:

i. Switched Custom Errors off and enabled Call Stack (more info here)

ii. Received the following error on accessing CA again:

The DataSourceID of 'QuickLaunchMenu' must be the ID of a control of type IHierarchicalDataSource. A control with ID 'QuickLaunchSiteMap' could not be found.

Finally, after a lot of tinkering around, I found the following in the section of the web.config:

This made no sense as I had not done any recent changes to navigation options especially around the CA.

iii. So I focused my attention on the recently deployed custom web part, and went about retracting and uninstalling the web part. Still no luck!

iv. So I went back to the web.config and compared it with an older copy of the same, still I could find no new changes!

<providers>

<add name="AdministrationQuickLaunchProvider" 
description="QuickLaunch navigation provider for the central administration site" 
type="Microsoft.Office.Server.Web.AdministrationQuickLaunchProvider, 
Microsoft.Office.Server.UI, Version=12.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c" />
</providers>

So after pondering over it a lot thought of changing the trust level from Custom to Full. This seems to do the trick! The CA is back up!


But still a lot of questions left unanswered. What caused the issue in the first place? And what got changed which was not addressed by the custom trust? Leave your opinions or recommendations in the comments below!