Kerberos configuration known issues (SharePoint Server 2010)

Kerberos authentication and non-default ports

There is a known issue where some Kerberos clients (.NET Framework, Internet Explorer 7 and 8 included) do not correctly form service principal names when attempting to authenticate with Kerberos enabled web applications that are configured on non-default ports (ports other than 80 and 443). The root of the problem is the client does not properly form the SPN in the TGS request by specifying it without the port number (as seen in the Sname of the TGS request).
Example:
If the web application is running at http://intranet.contoso.com:1234, the client will request a ticket for a service with a SPN equal to http/intranet.contoso.com instead of http/intranet.contoso.com:1234.
Details regarding the issue can be found in the following articles:

• Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port in Windows XP and in Windows Server 2003 (http://support.microsoft.com/kb/908209/en-us)
• Configure Kerberos authentication (Office SharePoint Server 2007) (http://go.microsoft.com/fwlink/p/?LinkId=196987)

To work around this issue, register SPNs with and without port number. Example:

• http://intranet.contoso.com:12345

• http/intranet
• http/intranet.contoso.com
• http/intranet:12345
• http/intranet.contoso.com:12345

We recommend that you register the non-default port to ensure that if the issue is resolved in some future service pack or hot fix, the applications using the workaround will still continue to function.
Note that this workaround will not work if the following conditions are true:

• There is more than one web application running on a non-default port
• The web applications either bind to the host name of the server or bind to the same host header (on different ports)
• The web application IIS application pools use different service accounts

• http://server.contoso.com:5000 AppPool Id: contoso\svcA
• http://server.contoso.com:5001 AppPool Id: contoso\svcB

If these conditions are true, following the recommendation in this workaround will yield duplicate SPNs registered to different service accounts which will break Kerberos authentication.
If you have multiple web sites sharing a common host name running on multiple ports, and you use different IIS application pool identities for the web applications, then you cannot use Kerberos authentication on all web sites. (One application can use Kerberos, the rest will require another authentication protocol.) To use Kerberos on all applications in this scenario, you would need to either:

1. Run all web applications under 1 shared service account
2. Run each site with its own host header
   
   
   Reference : http://technet.microsoft.com/en-us/library/gg502606%28v=office.14%29.aspx

SharePoint 2010 - Browser Compatibility

This article explains known limitations of some browsers with SharePoint 2010.

For most interactions with SharePoint an internet browser is required and the choice of browser will affect the experience. Most functionality is available in all browsers, however there are exceptions where certain features require Active X technology which is only available in Internet Explorer and means that some of SharePoint's functionality is lost when using non-IE browsers.

Browser support for SharePoint Server 2010 can be divided into three different levels, as follows:

• Supported - A supported Web browser is a Web browser that is supported to work with SharePoint Server 2010, and all features and functionality work.
• Supported with known limitations - These are non-Internet Explorer browsers such as FireFox, Safari and Chrome. They are supported for use with SharePoint but some functionality is missing in these browsers such as opening documents directly in Office applications (although viewing and editing office documents within the browser is fully supported, as is downloading and editing). Documentation on how to resolve these issues is readily available from Microsoft.
• Not tested - A Web browser that is not tested means that its compatibility with SharePoint Server 2010 is untested, and there may be issues with using the particular Web browser. SharePoint Server 2010 works best with up-to-date, standards-based Web browsers.

 

Courtesy : https://answers.uchicago.edu/page.php?id=24860

Thanks Brent for sharing this

URL path length restrictions in SharePoint 2010

There must always be a series of questions –

Is there any solution for URL maximum length restriction?

I am unable to create consecutive subfolders due to URL length exceeding 260 characters

Is there any proper fix to solve this issue?

Can I increase maximum allowed URL length that SharePoint can work with?

How exactly does that affect opening a nested-folder-document in say Word or Excel?

Is the limit also there for the explorer view? 255 chars isn't a whole lot for a directory and filename structure, so if it also affects the explorer view; is there a way around it?

Reason is pretty much simple: SharePoint limits URL length because all relative URL links are stored in the clear forms on the SharePoint content DB and often this links are used as primary keys to link one table with another. Fields which are used to store these links (for instance tp_DirName from the AllUserData table) allow storing only 256 characters.

Reference: http://technet.microsoft.com/en-us/library/ff919564(v=office.14).aspx

If you have any questions/queries regarding the mentioned information then please let me know, Thank you.

Unable to process the request. Wait a few minutes and try performing this operation again.

Issue: Most of our clients were having issue while opening the Excel files from their SharePoint sites using Excel web access webpart after an upgrade from MOSS 2007 to SharePoint 2010.

Error: Unable to process the request. Wait a few minutes and try performing this operation again

 

Troubleshooting done:

- Adding the URL in trusted file location.

- Change the settings to open the document with client application form document library. .

Resolution:

After some investigation we found this Blog from the technet , which talks about the same problem:

- Rebooting the server will remedy this, but that is not realistic.

- You can run IISReset /noforce that too should remedy the issue.

- To avoid a complete IISReset, you can manually recycle the Application Pool Running Excel Services. (Please check the blog for additional info)

http://blogs.technet.com/b/excel_services__powerpivot_for_sharepoint_support_blog/archive/2013/01/24/excel-services-2010-quot-unable-to-process-the-request-quot-maximum-private-bytes-size-exceeded-unable-to-complete-the-operation.aspx

How to overwrite or disable the List View Threshold value for particular list in SharePoint 2010 Using PowerShell

If you want to overwrite or disable the threshold limit of List View items for particular list then execute the following cmdlets in Powershell.

$WebApplication = Get-SPWeb http://<SiteCollectionName>

$List = $WebApplication.Lists["List Name"]

$List.EnableThrottling = $false

$List.Update()

There is one property of SPList called "Enable Throttling" which has to be set to false to overwrite the threshold limit set on Web Application for all the lists.

I hope this is helpful and If you have any questions then please let me know, Thank you.

Applies to SharePoint Server 2010.