Plan for User Accounts – complete SharePoint installation

We have two different approaches towards SharePoint installation such as Standalone installation and Complete installation. Standalone installation is meant for a single server installation scenario where we install everything on a single machine. While Complete installation here refers to farm level installation of SharePoint by separating out the concerns and accessed remotely in the same network infrastructure.

For a complete installation we should draw clear plan around the approach, here the plan for User accounts stands as a critical one among the various requirements. As we know it is desired to have different user accounts for accessing different resources in a network in an efficient manner. So I thought this is the right time to jot down an introduction to various User accounts as follows

SETUP ACCOUNT:

Setup account is the one which is used to run the SharePoint preparation tool, installation and configuration wizards, to create root file structure, assign rights to different accounts etc. It is preferred to be a Domain Admin or member of the Administrator group with SQL Login, security admin and dbcreator roles.

SERVICE ACCOUNTS:

For a single server environment, the network service/local service accounts will work fine for all SharePoint’s services. But when it comes to Farm level installation, it is preferred to have different accounts for various services. So here we have the following Service accounts to be considered as follows

Farm Account: It is the account used by all SharePoint servers in the farm to access the farm’s configuration database and run SharePoint specific services. This is created during the installation of SharePoint. Also it is the SharePoint Timer Service account and application pool identity for Central Administration.

Search Account: This account act as the owner of the Search database and responsible for managing the SharePoint Search.

Index Account: This is known as another owner of the Search database, content access account, crawler, gatherer, and indexer.

Content Database Account: This account act as the owner of the Content database of a web application.

BDC Account: This is used by SharePoint to pass data back and forth between a user, SharePoint and an external data sources using Business Data Connectivity Service. It supports Claims-based authentication.

Sandboxed Code Service Account: It is used by SharePoint to manage solutions that are deployed in a “sandboxed” fashion, not to whole farm but to a single site collection.

So we summarized about the various User accounts to be considered while doing a Complete Farm level installation of SharePoint.

Working with Macro Parameters – Razor approach

As we know we can supply values for parameters on Macros. When we insert a macro onto a template, we are prompted to supply the values for the parameters. Here I would like to show you that we can also do this in a Razor script as well.

Let’s say we have a Razor script file called “WelcomeMessage.cshtml” created under the Scripting files and we have a corresponding macro called “Welcome Message Macro”. The duty of our Razor script here is to display a Welcome message. Well, we have set a macro parameter called “AttendeeName” which accepts a name when inserted on a template. Now we need to modify our welcome message to display as “Welcome [AttendeeName], have a nice time here!!!”. Here in the given message [AttendeeName] should be replaced by the value assigned as a macro parameter.

This can be easily implemented in Razor script. In order to implement this, we need to make use of the following syntax in Razor scripts as follows

@Parameter.AliasName (please note this is not case sensitive)

So in our scenario, the whole Razor script would be as given below

Welcome @Parameter.AttendeeName, have a nice time here !!!

So guys have fun with Razor :-)

Access Property Data in Umbraco – Razor approach

In my last post I had discussed about Razor in Umbraco. Now let me share more about the implementation part of Razor in Umbraco. As we know Razor can be used in scenarios where we had used XSLT.

Here I would like to use Razor syntax to access document property data in Umbraco. We have a variable called @Model in Razor which is equivalent to the $currentPage in XSLT. Similarly we can use Razor to access all the properties like .Name , .Url ,.Level , .Id etc using @Model. Also we have option to access the custom property associated with a document type.

We can write Razor syntax in two modes i.e. Inline Razor approach or dedicated approach. Inline Razor approach is the style of writing the Razor syntax in line with the HTML snippets inside a template. While dedicated Razor approach refers to the style of writing Razor snippets separately under the scripting files. Then we associate this to a Macro and insert it onto the template.

Let me write a Razor snippet to access the property data in Umbraco, it will display the Name and Url of the page.

Now similarly we can access the Custom properties as well. Let’s have the following code snippet which access a Custom property called “myProperty”

So we have learned a bit on how to access property data using Razor syntax. I believe all C# folks would like this approach as they can do the similar things as fast as it is done in XSLT approach.