Blocking access to application pages (_layouts) and Forms Pages

All the pages having _layouts before them are application pages. Pages created automatically for various views are called Form Pages. Most often with SharePoint implementation we allow users to access these pages. However we may further want to cut down access of users from the application pages and the form pages.

SharePoint allows this by enabling the feature “ViewFormPagesLockDown”. This feature is activated at the Site Collection scope. All groups / users not having the “View Application Pages” permission will not be able to navigate to pages like “_layouts/viewlsts.aspx” or “pages/forms/allitems.aspx”.
Below are the steps to block access from application pages:

1. Identify users / group to restrict.
2. Set their permission to "Restricted Read" or remove the "View Application Pages" from existing assigned permission level.
3. Enable "ViewFormPagesLockDown" feature using the command - stsadm -o activatefeature -url "SiteCollectionURL" -filename ViewFormPagesLockDown\feature.xml

The above steps will block all users not having "View Application Pages" permission from accessing the application pages and form pages.

Solution to error "Security Validation for this page is invalid"

Few days back I came across this issue. It popped up whenever the page is posted back to update content to the site. On further digging into it I found this was somewhat related to the action performed within elevated code(i.e. code within SPSecurity.RunWithElevatedPrivileges).

SharePoint keep track of the requests using the token unique to the user and his request. Whenever the code is elevated the context is changed from the user to the system account.


To ensure smooth operation without the Security Validation error we should add SPUtility.ValidateFormDigest() line just before elevating the code. This MSDN article also talks about the same.

Moving the Content DB to new Server

On very rare occasion we may need to change the server in which the content database is located. SharePoint provide a very simple solution to facilitate this requirement.

Word of Warning!
Before getting your hands dirty be sure that you have backed up entire farm or have appropriate disaster management plan in case of any catastrophe.

• Open Central Administration and navigate to the application management tab.
• Under SharePoint Web Application Management Section click on the Content Databases.
• Verify you have selected the correct Web Application from the Menu.
• Click on the database to be relocated.
• Select the checkbox labelled "Remove Content Database" -> Accept the confirmation and press OK.
• Now the selected database is removed from the list of the database .
• Open SQL Server Management Studio and connect to the current database server.
• Select the database -> Task -> Click Detach.
• Select the Drop connection check box and press OK.
• Now copy the MDF and LDF file from the current location and paste it to the new server.
• Open SQL Server Management Studio and connect to the new database server and attach this database
• Make sure that the SharePoint database access account is given appropriate access to the new database.
• Now again Open Central Administration -> Application Management -> Content Database -> Select correct web application.
• Click "Add a content database" link.
• Enter new database server name
• Enter moved database name
• Select appropriate authentication mechanism
• Select Search Server and press OK

Verify the availability of your database in the database list and also verify whether your site is working as required.

STSADM Error: "Object reference not set to an instance of an object"

I wanted to deploy the newly created site definition build into a wsp package on my clients machine. The solution worked fine on my machine. But when I tried to add the solution to my clients server using the command stsadm -o addsolution -filename "<solution name.wsp>" I got an error "Object reference not set to an instance of an object".

I searched the SharePoint log at the location c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS for any additional information.

Following information was logged into the log file related to the issue:

06/15/2010 08:03:11.67     STSADM.EXE (0x1818)                         0x17E4    Windows SharePoint Services       Database                          880i    High        System.Data.SqlClient.SqlException: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.     at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)     at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)     at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)     at System.Data.SqlClient.SqlInternalConnectionTds.CompleteLogin(Boolean enlistOK)     at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObje...   

On reviewing this info I found that I was using the local system admin account to deploy the feature. Only thing I did to resolve the issue was to re-login as domain account having appropriate access and deploy the solution.

Created and Modified Field went missing

I was working on moving documents between document library. I used SharePoint's "Mange Content and Structure" to do the migration. The migration was successful and everything looked fine.

We had created a custom WebPart functionality  to fetch documents based on various metadata. It was also dependent on "Created" date. I found this broken after the move. The error was "Created Field not found" but it was visible in the document library. Only thing was during the API call to SharePoint from our custom code, the created field and its value was not being returned to our code and neither the field was being fetched using the tool "U2U CAML builder".

I found the day saver solution on Microsoft Technet. I just had to open the following page and press OK button.

http://[SiteURL]/_layouts/fldedit.aspx?field=Created.

Bingo! Everything seemed to work as before. The modified fields was also missing. I did the same for modified field. Now the Created and Modified field were also being returned in the datatable of the List Items.

Display Lists in another Site.

I was searching for workaround to display listview of lists in another Site and have come across the fantastic solution for this on "PathToSharePoint" blog.

Here is the link for all those guys searching for it.

http://pathtosharepoint.wordpress.com/2009/01/22/a-simple-method-to-display-a-list-in-another-site/

All the best.