SharePoint - Server error: The URL is invalid, it may refer to a nonexistent file or folder or refer to a valid file that is not in the current Web

Scenario:


SharePoint Designer throws the error "Server error: The URL is invalid, it may refer to a nonexistent file or folder or refer to a valid file that is not in the current Web" when you attempt to open/check-in/check-out/upload a file.

Explanation:

While there could be many reasons for this misleading error to show up, one of the reason is low disk space in the database server.

I noticed that the transaction log file for the SharePoint_Config database, "SharePoint_Config_Log.LDF" (resides in \Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data in our case) has grown enormously to 28 GB which is approximately 70% of the space in that drive.

Solution:

Take a backup of the log file it required.
Just run the below scripts to truncate the log file:

SQL Server 2008:

USE [master]
GO
ALTER DATABASE[SharePoint_Config] SET RECOVERY SIMPLE WITH NO_WAIT
GO
USE [SharePoint_Config]
GO
DBCC SHRINKFILE ('SharePoint_Config_Log')
GO
ALTER DATABASE[SharePoint_Config] SET RECOVERY FULL WITH NO_WAIT
GO
USE [SharePoint_Config]
GO

SQL Server 2005:

BACKUP LOG [Sharepoint_Config] WITH TRUNCATE_ONLY
USE [SharePoint_Config]
GO
DBCC SHRINKFILE (N’SharePoint_Config_log’ , 50)
GO

The file "SharePoint_Config_Log.LDF" is now 504 KB.
The server is happy now and running fine.

SharePoint 2010 - Buggy SPSecurityTrimmedControl and a workaround

Scenario:


The SPSecurityTrimmedControl control in SharePoint is incomplete and buggy.
Information about the bugs in this control are not provided by MSDN either.

In this post, I will try to explain the bug in the SPSecurityTrimmedControl and a solution to get over it.

Explanation:


The SPSecurityTrimmedControl  allows us to display/hide the content using a few different criteria, like authentication (for anonymous/authenticated users only), page mode (page in display or edit mode) or current user’s permissions.

So what's wrong?


The control doesn’t work the way you would expect it.
It does a good job with displaying content based on permissions but fails to conditionally display content based on authentication(anonymous/authenticated users).

That means using this control, you can hide an element from users who do not have the appropriate permissions.
Srini Sistla has a good post explaining all the available permissions here

This control also has the so called ability to show/hide content based on authentication(anonymous/authenticated users).

You would need to use the property "AuthenticationRestrictions" which can take any of these values:

• AllUsers
• AuthenticatedUsersOnly
• AnonymousUsersOnly

For Ex:

<SharePoint:SPSecurityTrimmedControl runat="server" id="stc" AuthenticationRestrictions="AnonymousUsersOnly"> <p>User is not logged in</p></SharePoint:SPSecurityTrimmedControl>

In case if you try to use this control in the above manner, it wont give you the desired results.

Examine the below screenshots and you understand it better.

Test 1: Tried with "AnonymousUsersOnly"

I tried to access the page as an anonymous user and below is the output. So test failed

Test 2: Tried with "AuthenticatedUsersOnly"

I tried to access the page as an authenticated user and below is the output. So test passed

Solution:


The solution is to use the LoginView control if you need to show/hide content based on authentication.
The LoginView control provides the following templats:

• AnonymousTemplate - Controls to show to anonymous users only
• LoggedInTemplate - Controls to show to authenticated users only

Test 3: Tried both AnonymousTemplate & LoggedInTemplate

I tried to access the page as an authenticated user and below is the output. Test passed

I tried to access the page as an anonymous user and below is the output. So test passed

SharePoint 2010 - Access denied for users that have full control on the site

Scenario:

• Users get "Access Denied" over the whole site, despite having Full Control permission
• Site Collection Administrators have no problem logging in

Explanation:

A SharePoint 2010 site that uses claims-based authentication has been extended to Intranet zone that uses AD as well as FBA. The site has number of users in the default owners and members groups.

All the site users always get access denied over the whole site even though they clearly have access to the site through the site groups.

Site Collection Administrators are allowed to access the site and have no problems logging in.

Resolution:

Make sure that all the Master page, CSS files, any other files that are required are published.

If there are files that are required in the master pages and are not published, users will get access denied even if they have full control on the site.

If you are ok with giving all authenticated users atleast road-only access to all files inorder to prevent the access denied problem, then you can try the below.

Add a new "User Policy" for the web application that allows "All Authenticated Users" the permissions "Full Read" on the desired zone.

To add a new User Policy:


Go to Central Administration
Click on Application Management
Click on Manage Web Applications

Choose the desired web application:

Click on "User Policy"

Click on "Add Users" to add a new User Policy:

Select the zone that you want to apply the new policy to. If you are not sure what to choose, leave the defaut value selected (All Zones) and cick next

Choose the permissions that you would like to give to the user(s) in this new user policy. If you do not want to give the user(s) full permission, choose "Full Read". This permission ensures that all the users in this policy can atleast access the site. Then click on "Browse" icon in the "Choose Users" area.

If you would ike to give All Authenticated Users / AD users / FBA users "Full Read" access, then choose the appropriate group(s).
In the next screens, click OK to get out of the wizard.
Your new user policy should be ready now.

Sharepoint 2010 - An exception occurred when trying to issue security token: The server was unable to process the request due to an internal error

Scenario:

You receive the below exception when you try to logon to a site that has been configured to use Claims Based Authentication with a custom membership provider using FBA credentials:

Event ID from Event Log  - 8306

An exception occurred when trying to issue security token: The server was unable to process the request due to an internal error.  For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs..

Explanation:

This error started to appear in our QA environment which does not have Visual Studio installed. I have tried starting the service "Claims to Windows Token Service" but that did not help either.

I have made sure that all configuration changes required for FBA have been made properly in the below web.config files:

• Web Applications
• CA Web Aplication
• \14\WebServices\SecurityToken

This post can get you started with building a custom membership provider and making changes to the required configuration files.

Resolution:

To view more information about the actual error that is preventing the secure token service from being able to issue security token, I added the service debug in the web.config for the web service, under \14\WebServices\SecurityToken:

<serviceDebug includeExceptionDetailInFaults="True" httpHelpPageEnabled="True"/>

After adding the above to SecurityToken's web.config, the event log reported the below:

An exception occurred when trying to issue security token: The configuration section for Logging cannot be found in the configuration source..

I then realized that it is Microsoft.Practices.EnterpriseLibrary.Logging from my custom membership code that is causing the issues and not FBA configuration as I originally thought.

I then went ahead and added the required configuration for Microsoft.Practices.EnterpriseLibrary.Logging

Everything after that worked as desired. 

So I strongly advice everyone not to panic and take such drastic steps as re-installing SharePoint 2010 etc..

When I googled for this error, many people suggested to reinstall SharePoint 2010, change server names, etc..

Remember that these things happen for a reason. It just requires some patience to figure out the exact problem.