Showing posts with label Powershell. Show all posts
Showing posts with label Powershell. Show all posts

Sunday, 20 January 2013

Configure Anonymous Access for SharePoint 2013 site with Javascript Client Object Model

Recently I came across a requirement to enable anonymous access for SharePoint 2013 site. Now, this seems to be a very simple requirement but the twist here was that anonymous access should work with ECMASCRIPT. Had it been server side code, we could have simply executed our code within run with elevated privilleges and thats it. But with javascript, this is not possible. In this blog post I will explain how this can be achieved.

First of all, for anonymous access to work , we need to enable anonymous access at both web application level as well as site collection level.

In central admin, when we are creating a new web application, we get an option to make the web application  available anonymously.



Next thing required is that we need to set up the anonymous access at the site collection level. To do this , we need to go to Site Settings -> Site Permissions. There we find an option for Anonymous Access. Clicking on that will provide us a popup where we can enable anonymous access for the site collection.


The above two steps would have been enough for server side code. But if you are working with Javascript Client Object Model, there are additional things that needs to be done before being able to access a site anonymously.
With JavaScript Client Object Model (JSCOM), the anonymous user gets Microsoft.SharePoint.Client.ApiBlockedException. As a result when user tries to access a site anonymously where something is being fetched based on JSCOM, he will get Access Denied Exception because of the blocked API. The solution for this problem lies hidden in the ClientCallableSettings of the SPWebApplication object. This property controls which API are prohibited in the Client OM. With the help of powershell we can remove these blocked API's from the web application.


If you look at the above powershell script, you will see SPList in AnonymousRestrictedTypes. In Client Object Model, the following API's are restricted in ClientCallableSettings


  • SPSite.GetChanges()
  • SPWeb.GetChanges()
  • SPWeb.GetSubwebsForCurrentUser()
  • SPList.GetChanges()
  • SPList.GetItems()
It is the restriction on GetItems() that prevents the anonymous users from fetching listitems using JSCOM.
Therefore we need to remove this restriction in order to enable anonymous access. Following powershell command will remove this restriction on web application level


By running the above command we can get away with the API restriction on GetItems() in case of Client Object Model.

Now, the next thing that needs to be done is to go to central admin. There go to Application Management  and select Manage Web Applications. Select your web application and click on the Authentication Providers in the ribbon.It will open a dialog box as shown below.



Click on Default link. It will open another dialog box. There you will find an option saying Require Remote Interfaces Permission. Uncheck this checkbox and save.


Now, your site is configured to support anonymous access with Javascript Client Object Model with anonymous users having View Item permission on the list. In case you want to allow anonymous users to perform some POST action as well, like Add an Item to the list , you need to break permission inheritance and give Add Items permission as well to anonymous users.




And this is it. Now anonymous users can GET and POST data to sharepoint site using JSCOM.

Hope this helps !!

Cheers,
Geetanjali


Saturday, 19 January 2013

Configuring Failover Database in SharePoint 2010


Amongst the various new features introduced in SharePoint 2010, Fail over database is a one. SharePoint 2010 is mirroring aware. This means that their is high availability of database if you have done the database mirroring at SQL level and have set the failover instance for your database at SharePoint level.

In simple terms, it means that if the connection to the primary database fails then it will automatically try to connect to the failover database instance and thereby ensuring high availability and minimal downtime.

You will have to configure the database mirroring first before proceeding with the failover database configuration. Once you have configured database mirroring at SQL level, there are two ways in which you can configure the fail over database , using Central Administration or by Powershell. But the powershell approach is more efficient as it gives you the ability to create a failover instance for config DB as well.

I will be discussing with both the approaches here.

Powershell Approach

$database = Get-SPDatabase | where { $_.Name -eq "SharePointDBName" }
$database.AddFailoverServiceInstance("FailoverSQLServerName")
$database.Update();



The Get-SPDatabase​ returns all the databases and by applying where { $_.Name -eq "SharePointDBName" }​ , you can specify which database you want to retrieve.



Once you have retrieved the database instance, you add the Failover server instance to the database and update it. This will add the failover database to your sharepoint content database.


Central Admin 

In central admin, in your manage content databases settings as well there is an option to provide the fail over database. But powershell is a recommended approach as it gives you more flexibility.


In this way you can configure a failover database in SharePoint 2010. :)



Happy Reading !

Geetanjali