Known issues when you install Office 2010 SP1 and SharePoint 2010 SP1

Found this KB should be easily available for all my users .

This article lists the known issues and behavior changes that you may experience when you install Service Pack 1 (SP1) for Microsoft Office 2010, Microsoft SharePoint Server 2010, Microsoft SharePoint Foundation 2010, and Office server products.

Resolution:

The following are issues that you may experience when you install these service packs:

• SharePoint Server 2010 SP1 has an issue that causes workflow tasks to become locked and unrecoverable, as follows. Assume that you have a running out-of-box (OOB) workflow task (for example, an "Approval – SharePoint 2010," "Collect Feedback – SharePoint 2010," or "Publishing Approval" task). When a task assignee edits the workflow task (for example, by approving or rejecting the trial), the task is locked and cannot be recovered. For more information about this issue, click the following article number to view the article in the Microsoft Knowledge Base:
  2737435 "In Progress" Workflow tasks are locked after updating to SharePoint 2010 SP1
  
  To resolve this issue, install the hotfixes that are provided in the following articles in the Microsoft Knowledge Base:
  2687614 Description of the SharePoint Server 2010 hotfix package (Coreservermui-xx-xx.msp): October 30, 2012
  2687557 Description of the SharePoint Foundation 2010 hotfix package (Wss-x-none.msp): October 30, 2012
  Note You must install these hotfixes after you install SharePoint 2010 SP1.
• Before you install the SP1 packages, make sure that you have sufficient disk space. For caching, the packages may require up to four times their file size in remaining disk space during installation.
• You must restart the computer at the end of the installation process.
• If Office Web Apps will be used in a mixed version environment, where Office Web Apps has SP1-or-later applied while SharePoint Server 2010 remains on the RTM version, you must install the following two updates before you install SP1 for Office Web Apps:
  • 2510639 Description of the SharePoint Server 2010 update: April 12, 2011
  • 2510648 Description of the Office Web Apps update: April 12, 2011
• Install the service packs in the following order on every server in the farm:
  1. Service Pack 1 for SharePoint Foundation 2010
  2. Service Pack 1 for SharePoint Foundation 2010 Language Pack (if applicable)
  3. Service Pack 1 for SharePoint Server 2010
  4. Service Pack 1 for SharePoint Server 2010 Language Pack (if applicable)
• After you install Service Pack 1 you must run the SharePoint 2010 Products Configuration Wizard or the psconfig –cmd upgrade –inplace b2b -wait command one time on every server in the farm. This step updates the farm to the latest version and is required in order to have full SharePoint functionality. If you do not run the wizard, the farm will run with reduced capacity. For example, Search will not be able to index content.
• You must restart the User Profile Synchronization service after installing Service Pack 1. For more information about how to start the service, see the "Start the User Profile Synchronization service" section of the following Microsoft website:
  Configure profile synchronization
• After SharePoint Server 2010 SP1 is installed, the Workflow feature is disabled when a new site collection is created. To use the Workflow feature in a new site collection, enable it in the Site Collection Settings page.
• After you install SharePoint Foundation 2010 SP1 and SharePoint Server 2010 SP1, we strongly recommend that you install the install the June 2011 Cumulative Update refresh package. The June Cumulative Update includes several important security and bug fixes that are not included Service Pack 1. For more information about these updates, click the following article numbers to view the articles in the Microsoft Knowledge Base:
  2536601 Description of the SharePoint Foundation 2010 cumulative update package (SharePoint Foundation server-package): June 30, 2011
  
  2536599 Description of the SharePoint Server 2010 cumulative update package (SharePoint server-package): June 30, 2011

  Applies to

  • Microsoft Office Home and Student 2010
  • Microsoft Office Home and Business 2010
  • Microsoft Office Professional 2010
  • Microsoft Office Professional Plus 2010
  • Microsoft Office Standard 2010
  • Microsoft Office Starter 2010
  • Microsoft SharePoint Foundation 2010
  • Microsoft SharePoint Server 2010

  
  Reference : http://support.microsoft.com/kb/2532126

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