Configure BLOB cache for SharePoint 2010 web applications

SharePoint 2010 supports disk-based BLOB Cache that controls the caching for binary large objects. If you configure BLOB for frequently used images, audio files, video files, java script files, css files etc., the performance will be improved. BLOB cache needs to be enabled in the front end web server and once configured; the configured files will be retrieved from the database and stored in a directory under Front end web server. This reduces the network traffic/load on the database server. 
You need to carefully decide whether or not to use the BLOB cache. You need to carefully decide what files need to be placed under BLOB cache. For e.g. placing documents under BLOB cache in a collaboration portal will give you negative effect as the documents will be authored by users frequently. 
Consider the following points for configuring the BLOB cache.
For a publishing site for which most of the visitors are anonymous or where most of the files are static content, enable the BLOB cache for as many file types as possible.
For other sites that contain lots of media assets that are read-only, or where only a small percentage of the media assets are updated, enable the BLOB cache for media files only.
Be noted that you can have only one BLOB cache per web application. Each web front end server will have its own copy of BLOB cache. In load balancing scenarios, each web server will have its own copies and the files will be added to the blob cache individually by the front end server when it serve the file for the first time.
The BLOB cache needs to specify in the web.config for each web application. By default, the BLOB caching is disabled. Open the web.config for the web application that you need to configure the BLOB cache. Normally you find the following line in the web.config of the web application.
<BlobCache location="<location>" path="<files to be cached>" maxSize="10" enabled="true" />
Modify the following attributes
location – the path to the directory where the blob files stores in the disk. 
path – specifies the condition for file names that will be included in the cache. By default SharePoint will include a regular expression that matches certain extensions. In most of the cases you just need to add/remove some extentions to the list. 
maxSize – the maximum size for the cache expressed in GB, 10 GB is the default
enabled - specifies whether blob cache is enabled or not. True indicates enabled
e.g. 
<BlobCache location="C:\BlobCache\14" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="true" />
Flush output cache
In some situations, you need to flush the output cache. You can do this by using the following PowerShell commands
$webApp = Get-SPWebApplication "<http://your web application url>"
[Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)

How to redirect form one site to distination site using java Script, Content editor webpart

How to redirect form one site to distination site using java Script, Content editor webpart

Write below code on Content Editor Webpart
<script language="javascript">
location.replace("http://servname:9999/sites/abc/123");
</script>

SharePoint 2013 - Creating and Configuring MySite

SharePoint 2013 - Creating and Configuring MySite

Creating MySite is not just creating a web application and site collection within it. It has more steps and more concepts revolve around it. This article explains how to setup MySite for SharePoint 2013.

SharePoint 2013 has many new social media features where people can interact, discuss, search etc etc etc with each other. Creating MySite is not just creating a web application and site collection within it. It has more steps and more concepts revolve around it. In this post I will explain how to create and configure the MySite in SharePoint 2013.

Create Web Application

It is always recommended to have a separate Web Application for MySite. Go to Central Administration and selectManage web Applications.

Select New and create a new web application.

I have created web application http://goazrapp19:2000/.

Create Site Collection

Now create a new site collection under the new Web Application by selecting experience version as 2013 andtemplate as My Site Host.

Configure Web Application that will host MySite

Select the Manage Path button for the MySite's hosting web application

Add new managed path with wild card inclusion and my as path.

Select the Service Connections button

Make sure User Profile Service Application, Managed Metadata Service, and Search Service Application are running.

Select the Self Service Site Creation button for the web application

Select On for Site Collections and Prompt users to create a team site under: for Start a Site. Also provide the managed path created earlier.

Select the Permission Policy button for the web application that will host MySite to grant permissions to the users to create their own MySite

 Select Add Permission Policy Level

Provide the name MySite Creation and under Site Permissions select Create Subsites

Now add users to the newly created policy by selecting the User Policy button for the web application.

Select Add Users

Setup MySites for the Search Center

From Central Admin select Application Management ->  Manage Service Applications (under Service Applications) -> User Profile Service Application

Then select Setup My Sites

Here you specify the Search Center. If you don't have the search center then you can skip this step. I am setting up MySites on a single server farm and am not using Search Center.

Enable the User Profile Service Application - Activity Feed Job

Go to Central Administration -> Monitoring -> Timer Job -> Review job definitions

Look for User Profile Service Application.

Note: If the Service list does not display User Profile Service, in Service drop down (on right top), click No selection, then click Change Service. On the Select Service Webpage Dialog, use the arrows in the upper-right corner to locateUser Profile Service, and then click it.

Select the interval according to your requirement and click Run Now. I will leave it as Minutes.

Access your MySite now...

SharePoint: Create a new site-collection in a new content database.

Create a new site-collection in new database.

Create a new site-collection in new database.

In the command prompt, enter the following command.
stsadm.exe -o createsiteinnewdb -url <New_Site_Collection_URL> -databasename <New_Database_Name> -ownerlogin <Site_Collection_Owner> -owneremail <Email_Of_Site_Collection_Owner>

SharePoint 2010 - Service Accounts Passwords Change Guide

SharePoint 2010 - Service Accounts Passwords Change Guide

Service accounts password change in SharePoint 2010 is a pain.  Especially, if you follow the recommended best practices to have dedicated accounts for different services.  I have gone through several rounds of the service account password change and have found the steps that work for me.  First, you have to understand that not all service account password can be managed from the SharePoint 2010 "Configure managed accounts" page.   There are some accounts that you have to perform extra steps after you change the password in AD.
Managed Accounts

These are the accounts that you can just use the "Configure managed accounts" page in SharePoint 2010 Central Administration to change the password and be done.  I normally don't even need to know the passwords of these accounts.  I also set automatic password change for these accounts.  Please note that I am purposely excluding the Farm Account from this group.

The accounts in this group are:

Web application pool service account(s)

SharePoint search service account(s) (but not the content access account(s))

SharePoint foundation search service account (but not the content access account)

User profile service account (but not the user profile synchronization connection or the user profile synchronization service accounts)

Managed metadata service account

Web analytic service account

Secure store service account

BDC service account

Excel services account (but not the Excel unattended execution account)

PerformancePoint service account (but not the PerformancePoint unattended execution account)

Visio service account (but not the Visio unattended execution account)

PowerPoint service account

Word viewing service account

Excel PowerPivot service account

These accounts will be in the list of your managed accounts in Central Admin.  Again, you can just set the passwords of these accounts directly from Central Admin and be done.

Unmanaged Accounts

These are the accounts that you must perform extra steps after you have changed their password in Active Directory.   The service accounts in this list are:

User Profile Synchronization Service account

User Profile Synchronization Connection account

SharePoint Server Search default content access account and Content Access accounts defined in the crawl rules.

SharePoint Foundation Search default content access account

Unattended execution accounts (Excel, Visio, PerformancePoint)

Object cache super user and object cache reader accounts

Perform the steps below to change the passwords of these accounts.

1. Change the passwords of these accounts in AD.  You will need to note down the passwords of these account because you will need to enter them into various places in SharePoint.

2. User Profile Synchronization Service account

2.1. Please skip to the Farm Account section (below) if you are using the Farm Account as the User Profile Synchronization Service credentials.

2.2. Bring up Central Admin.

2.3. Click "Manage services on server" under "System Settings."

2.4. Find the server that you have previously configured to run UPS.  Switch to that server via the dropdown at the top of the page.

2.5. The User Profile Synchronization Service (and FIM) will be stopped as the password of the service account was changed.

2.6. Click "Start" to start the UPSS. 

2.7. Enter in the new password for the service account.  Click "OK."

2.8. Wait to see whether the service is started.  Keep your fingers crossed. :)

3. User Profile Synchronization Connection account. 

3.1. Bring up the User Profile Service in Central Admin.

3.2. Click "Configure Synchronization Connections."   Please note that the connection list will be empty if the User Profile Synchronization Service is currently stopped.

3.3. Click the dropdown next to the sync connection name.  Click "Edit."

3.4. Enter the new password in the "Connection Settings" section.

3.5. Click "Populate" to check whether the new password works.   It should bring up the AD tree if it works.

3.6. Click "OK."

4. SharePoint Server Search Content Access Account(s)

4.1. Bring up the Search Service application in Central Admin.

4.2. Click the Default Content Access Account in the "System Status" section.

4.3. Change the password of the account in the popup.

4.4. Please note that you need to do these steps even if your content access account is the same as your search service account.

4.5. Change the passwords of content access accounts that you may have defined in the Crawl Rules.

5. SharePoint Foundation Search Content Access Account

5.1. Bring up Central Admin.  Click "System Settings"

5.2. Click "Manage Services on Servers."

5.3. Find the server(s) where the SharePoint Foundation Search Service is running.

5.4. Click "SharePoint Foundation Search Service"

5.5. Change the password of the service account in the "Content Access Account" section.  Click "OK."

5.6. Repeat these steps if you have Foundation Search service running on more than one server. 

6. Unattended Execution Accounts (Excel Unattended and Visio Unattended)

6.1. These accounts are stored in the Secure Store (and/or should have been previously configured there).

6.2. Bring up the Secure Store Service application in Central Admin.

6.3. Click the dropdown next to the secure store application name.  Click "Set Credentials."

6.4. Enter in the service account name and password.

6.5. Repeat the steps for the other unattended execution account.

7. PerformancePoint Unattended Service Account

7.1. On the SharePoint Central Administration Web site, in the Application Management section, click Manage Service Applications, and then click the PerformancePoint Services service application.

7.2. On the Manage PerformancePoint Services page, click PerformancePoint Service Settings.

7.3. In the Unattended Service Account section, enter the new password for the account.

7.4. Click OK.

8. Object Cache Super User and Object Cache Reader accounts

8.1. You don't need to do anything in SharePoint after the passwords of these accounts are changed in AD. 

Farm Account

I listed the Farm Account in a separate section although it is a SharePoint managed account.   I found that using stsadm command in PowerShell works a whole lot better for the Farm Account.   Also, most people use the Farm Account as the User Profile Synchronization Service credential.  And the UPSS account is an unmanaged account.  To change the Farm Account password;

1. Change the Farm Account password in AD.  Note down the new password.

2. Logon to the SharePoint server that hosts the Central Administration site.

3. Launch SharePoint Management Shell as admin.  Note that you also have to be a farm administrator.

4. Run the following command

stsadm -o updatefarmcredentials -userlogin DomainName\UserName -password NewPassword

5.  Repeat steps 2 to 4 on all other SharePoint servers.

6.  Update the User Profile Synchronization service account if you use the Farm Account as UPS account.

6.1. Bring up Central Admin.

6.2. Click "Manage services on server" under "System Settings."

6.3.  Find the server that you have previously configured to run UPS.  Switch to that server via the dropdown at the top of the page.

6.4.  The User Profile Synchronization Service (and FIM) will be stopped as the password of the service account was changed.

6.5.  Click "Start" to start the UPSS. 

6.6. Enter in the new password for the service account. 

6.7 Click "OK" and monitor that the service start successfully.

SQL Server Reporting Services account

1. Change the SSRS service account via the Reporting Services Configuration Manager utility. 

2. Logon to the server(s) that run SSRS for your SharePoint farm.

3. Launch Reporting Services Configuration Manager utility.

4. Connect to the SSRS instance.

5. Click "Service Account" on the left pane.

6. Change the service account password in the popup.

7. Click "Apply.

Reference Links:

http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=301

http://blogs.msdn.com/b/charliechirapuntu/archive/2013/01/16/sharepoint-2010-comprehensive-steps-to-change-passwords-of-all-service-accounts.aspx

http://blogs.technet.com/b/seanearp/archive/2011/01/25/updating-passwords-on-sharepoint-2010.aspx

Claims based Authentication – Refreshing User Claims

As a scenario for claims based authorization, imagine an organization that allows executives Full control, project managers contribute access and all employees read access to a site.

In a site hosted under a claims aware web application, instead of selecting users or security groups to add to site Owners, Members or visitors group, you could select ‘Executive’, ‘Manager’ or ‘Employee’ claim from People picker.  Any user coming into the site with a corresponding claim in their token would then be granted respective access.

You could implement a Custom Claims Provider that will allow you to augment the User claims token with such additional claims. Down the line, these claims can be used to grant permissions and secure objects in SharePoint. Shown below, a kickass custom CCP allows people picker to show claims based on designation :)

You can then select all users who are Managers and add them to a group or an item with specific permissions

Obviously you need a place to store this kind of mapping to determine the users claim before injecting it into the token. I just use SQL Server, with BCS providing an easy interface for an admin guy to add or remove claims.

So to the problem now:

Once the CCP evaluates who you are based on SQL mapping, it augments your security token with the correct claim (‘Employee’, ‘Manager’ or ‘Executive’). If the mapping is changed in the backend SQL (if you are changed from a Manager to an Executive for instance), the claim still seems to stick to the old value forever and never gets refreshed. This is true even if the user logs out and logs in again.

I was able to leave the machine running for 4 hours, came back and logged into the site and it was still showing my old claim (I use a wee webpart to show the current users claims on the site for quick debugging). I found that short of recycling the STS Application pool or recycling IIS, nothing refreshed claims.

There are a few options to get the token refreshed quicker than a whole nap time.

You could hook into global.asax and use the event raised by SystemAuthenticationModule and get the token refreshed as shown here. This could be done in every request or when user clicks a particular link.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

SessionAuthenticationModule sam = sender as SessionAuthenticationModule;   var logonWindow = SPSecurityTokenServiceManager.Local.LogonTokenCacheExpirationWindow;   DateTime newValidTo = DateTime.UtcNow.Add(logonWindow);   e.SessionToken = sam.CreateSessionSecurityToken(   e.SessionToken.ClaimsPrincipal,   e.SessionToken.Context,   e.SessionToken.ValidFrom,   newValidTo,   e.SessionToken.IsPersistent);   e.ReissueCookie = true;

While this approach worked, it did not work consistently for me. The event was not raised for every request by SAM, even with a custom link being opened in a new browser window. Effectively, if a user’s claims are changed, this should relate to their privileges on site being either reduced or increased. Relying on SAM events would effectively allow the user to maintain current privileges as long as they keep their current session on, which would be undesirable.

I ended up modifying the SecurityTokenConfigService properties to reduce the lifespan of the token to 1 minute. This gets the token refreshed at least every minute. Not sure how much of a performance hit this carries, but at the moment I cannot find another approach that ensures that the logged in user has correct permissions on the site based on his claims.

Open SharePoint PowerShell (Start -> Programs -> Microsoft SharePoint 2010 Products -> SharePoint 2010 Management Shell) and run the following commands

1 2 3 4 5 6 7 8 9 10 11 12 13

$sts = Get-SPSecurityTokenServiceConfig   $sts.UseSessionCookies = $true   $sts.WindowsTokenLifetime = (New-TimeSpan -Minutes 2)   $sts.ServiceTokenLifetime = (New-TimeSpan -Minutes 2)   $sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -Minutes 1)   $sts.ServiceTokenCacheExpirationWindow = (New-TimeSpan -Minutes 1)   $sts.Update()

This is how my configuration ends up looking after the changes.