Friday, August 22, 2014

Web application creation does not create IIS site

Quick post today based on an experience with newly created web applications not displaying. I had created a new web application/root site collection on a Sharepoint 2010 Farm server (2 WFE, 2 App servers) and noticed that the web application successfully got created but on going to the web app URL nothing was being displayed (404). I checked the IIS and noticed that the IIS website was not created.
Here are the steps I used to troubleshoot:
1.    Checked ULS logs: No issues found or recorded
2.    Checked the Timer service: Timer Service was up and running on all servers, restarted anyway to be on safe side.
3.    When that did not help, restarted IIS on all servers. That also did not help.
4.    Started checking all services in CA --> Manage Services on the server.
Checked and found that “Microsoft Sharepoint Foundation Web Application” service was stopped on the app server.
Restarted the service and VOILA! Web application and IIS website started getting created.

Friday, August 8, 2014

Client Side Scripting: Get Sharepoint User Profile properties using jQuery

In Sharepoint 2010 environment, I recently had a request to fetch the UserProfile object using client side scripting on a Sharepoint page. Immediately, I started looking for any methods exposed within the jQuery library to do so. A jQuery script library called SPServices is available which abstracts SharePoint's Web Services and makes them easier to use.

SPServices: http://spservices.codeplex.com/


Specifically they have examples on how to retrieve UserProfile properties using SPServices library function GetUserProfileByName.


http://spservices.codeplex.com/wikipage?title=GetUserProfileByName


For my own implementation, I modularized the code for fetching the user profile object into a separate javascript file as below:



function returnUserProfile()
{
var user = {};
$().SPServices({
operation: "GetUserProfileByName",
async: false,
AccountName: $().SPServices.SPGetCurrentUser(),
completefunc: function (xData, Status) {
$(xData.responseText).SPFilterNode("PropertyData").each(function() {
              user[$(this).find("Name").text()] = $(this).find("Value").text();
           });        
    }
    });
return user;
}


I can quickly surface the function call in any CEWP/HTML form web part and read the user profile property.

Example: (Redirect based on Users Office location)

var user = {};
var url = document.url + "/sites/region/";
user = returnUserProfile();
window.location.replace(url+user.Office); 


A complete list of all properties available under UserProfile is below:

http://technet.microsoft.com/en-us/library/hh147510%28v=office.15%29.aspx


Hope this helps!

Friday, August 1, 2014

Developers vs. Operations



I recently came across an interesting article (“Revisitingwhat is DevOps” by Carlos Sanchez) on role of DevOps and the constant balance between the developers and operations team within the project to make it successful. Throughout the article I could perfectly relate to what the essence of the article was i.e. the need to have a balance between both teams to achieve the best that the software/platform has to offer.

From my own personal experiences working on multiple projects, I have always felt the need to address as part of any project, setting up channels of communication and constant interaction between the developers/architects and the operations team. On too many occasions, the development team will come up with innovative and challenging approaches to only find out that the limitation to get it implemented is the hesitation/apprehension of the operations in setting up the infrastructure or service required to facilitate the approach. After many discussions and arguments, this would finally boil down to a stalemate with teams not making any ground and having to revert back to existing solution or platform to resolve the problem.

I am not saying that the problem here lies with the Operations. They have their own reservations (and rightly so) when implementing changes which could possibly hamper or disrupt services and make their lives a living hell just so that the development team can rejoice in their two minutes of fame. There are plenty of other constraints as well that the Operations team has to look at like lifecycle management and financial limitations when reviewing the changes.

However, that being said it is ultimately a working relationship between the two which can ultimately make or break a project.

For further reading and looking at Sharepoint Governance, I recommend Steve Goodyear’s books on Practical Sharepoint Governance and Sharepoint Enterprise Content Management.