Showing posts with label SharePoint 2010. Show all posts
Showing posts with label SharePoint 2010. Show all posts

Friday, May 10, 2013

April 2013 CU for SharePoint 2010 has been released

The product group released the April 2013 Cumulative Update for the SharePoint 2010 product family.
Be aware that the April Cumulative Update for SharePoint 2010 is a Post-SP1 hotfix. That means that you should ensure that SP1 is installed before the April CU.
The KB articles for April CU will be availabe at the following locations in a couple of days:
  • KB 2794728 - SharePoint Foundation 2010
  • KB 2775353 - SharePoint Server 2010
  • KB 2775426 - SharePoint Server 2010 with Project Server
    As you see there is a separate Full Server Package for SharePoint Server 2010 with Project Server which simplifies patching of this common installation.
The Full Server Packages for April 2013 CU are available through the following links:
Be aware that the SharePoint Server 2010 CU contains the SharePoint Foundation CU. And the SharePoint Server 2010 with Project Server CU contains Project Server CU, SharePoint Server CU and SharePoint Foundation CU.
That means only one package has to be installed for the SharePoint 2010 product family.

Thanks -  Stefan Goßner

Monday, April 29, 2013

Cannot browse to All People in SharePoint 2010

We used to normally visit All people in Sharepoint 2007 to Delete the user from the Site collection :)

Where is it in Sharepoint 2010 ?

The “All People” view is the best way to list out all the users having access to the SharePoint site.

When a admin navigates to the “People and Groups” section in a SharePoint 2007 site,

he sees a link called “All People” in the left hand navigation.

Clicking on this link brings up a view of all the users across all the groups in the site.

But this “All People” view is hidden in SharePoint 2010 and the link is also missing in the “People and Groups” section.

However one can still navigate to this view in a SharePoint 2010 by following the below mentioned steps :
 
  • Navigate to the “People and Groups” section.
  • Click on any of the groups.
  • Locate the “MembershipGroupId” query string parameter from Url in the address bar
  • Replace the value in the “MembershipGroupId” query string parameter with 0.
  • Reload the page and it will populate the “All People” View.

Thursday, April 25, 2013

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:
  • 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

Monday, March 11, 2013

Missing Webparts- One of the crtitical error from HEALTH ANALYZER

Missing server side dependencies- The Umbrella which covers 4 critical issues
Missing features has already been covered under this section:

Remaining ones are missing webparts, missing setup files and missing assemblies.

Let’s concentrate on Missing Webparts section:
[galaxy.SPWP.FSODataParser,
Culture=neutral,
PublicKeyToken=fc9c10bf499fbb4b])
[WSS_Content_SP2010],
in
database
[WSS_Content_SP2010],
farm.
[EasyTabParts,
Culture=neutral,
PublicKeyToken=b15a43dfe3a17723])
[WSS_Content_SP2010],
[MC_Menu,
Culture=neutral,
PublicKeyToken=d088e98baa178219])
[WSS_Content_SP2010],

[Microsoft.Office.Server.Search,
Culture=neutral,
[SharePoint_AdminContent],
[Microsoft.SharePoint.Portal,
Culture=neutral,
[SharePoint_AdminContent],

Some webparts are belongs to SharePoint_AdminContent database. While debugging further on this, we tried to find out the leaf names as well as dir names are a part of which links/URL’s exactly but we didn’t find anything. That’s strange to troubleshoot further.

The GUIDS which are belongs SharePoint_AdminContent Database are as follows:
[baf5274e-a800-8dc3-96d0-0003d9405663]
[9eba9c17-3b89-a2e7-a3cf-0ee3d7c2adb1]
[07f48b68-2e69-c86a-ebe4-16359e03ebc2]
[23091f6c-295d-4493-504c-1714a20d65a2]
[7d319bdd-d90e-7861-b7f0-2f9f4cec3004]
[c744e2b2-158c-c2f8-2f80-54bf046ff644]
[36f2680f-4855-f100-da5b-5dd1d07ae62b]
[b36f9dfe-325a-1b44-e6bb-645dcf79c770]
[0a60f514-1dea-8537-b588-64ee5e224da3]
[9f56656f-6aa3-0d55-a812-711bf65864ea]

Further research on this, we came to a conclusion that this is a known issue regarding this GUIDS belongs to AdminContent DB and we can certainly ignore that. This will gets fixed in the next CU.


Example:

Error Message:
[MissingWebPart] WebPart class [a03a7e7e-aab8-9045-8bf2-54d79ff53595] (class [PowershellWebpart.PowershellWebPart.PowershellWebPart] from assembly [PowershellWebpart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0bf26c041eeaa3b0]) is referenced [1] times in the database [WSS_Content_Sharepoint.SP2010], but is not installed on the current farm. Please install any feature/solution which contains this web part. One or more web parts are referenced in the database [WSS_Content_Sharepoint.SP2010], but are not installed on the current farm. Please install any feature or solution which contains these web parts.

As we can see, the error gives you a “WebPart class” GUID, the name of the content database, and how many times it is referenced in the database but no site collection link.

Following SQL query will be used to find out the site ID, LEAF name and Directory name.
"SELECT * from AllDocs inner join AllWebParts on AllDocs.Id = AllWebParts.tp_PageUrlID where AllWebParts.tp_WebPartTypeID = '4575ceaf-0d5e-4174-a3a1-1a623faa919a'" | select Id, SiteId, DirName, LeafName, WebId, ListId, tp_ZoneID, tp_DisplayName | Format-List

SITE ID: we can easily find out the site collection link based on the fetched site ID details
LEAF name: this will be a page on which that faulty webparts exist
DIR name: this will be a document library in which those pages exist.

Output will be like this:
Id       : 657a472f-e51d-428c-ab98-502358d87612
Name     :
SiteId   : 337c5721-5050-46ce-b112-083ac52f7f26

To find the site collection URL using the information output from the query, type the following command:
$site = Get-SPSite -Limit all | where {$_.Id -eq "337c5721-5050-46ce-b112-083ac52f7f26"}
$site.Url

Once we have the site collection URL, we can use the relative path specified by the DirName property to find the location of the file.

To remove the web part from the page, type the page URL in the browser and add?contents=1 to the end of it.

That’s it. You will see the web part maintenance page on which faulty/corrupted webparts are listed.

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

Friday, February 22, 2013

Cannot Publish Access Database to Sharepoint 2010 Server



Happy Friday to all of you :)

Worked for almost 10 hours to resolve this issue that I am going to explained in detail manner.

Okay, here we go…

Problem Description: We have published an Access 2010 database to SharePoint 2010 site. The publish was successful but received an error
Error Messages:

Message#1:
Exception message: Exception from HRESULT: 0x80131904

Message#2:
The server was unable to process the request due to an internal error. For more information about the error, either turns 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.

Message#3:
I get this error in the event viewer:
Log Name:      Application
Source:        Microsoft-SharePoint Products-Access Services
Date:          22/2/2013 10:03:43 AM
Event ID:      3
Task Category: Data Layer

Message#4:
An error has occurred. Please try again.

If I review the series of error message then it’s not completely clear where its dragging out and in which direction.

Troubleshooting done on this issue:
1.    Manage Services on Server – Access Database Service is started

2.    Manage Services Applications – Review the access Settings

3.    Manage Web Applications – Make sure application is associated with the Access Service

4.    Make sure all the features are activated
o   Central Admin --- System Settings --- Manage Farm Features --- Access Services Farm Feature
o   Central Admin --- Manage Web Applications --- Select Web Application hosting the Access Services Site --- Manage Web Application Features --- SharePoint Server Enterprise Web application features
o   Site Collection --- Site Settings -> SharePoint Server Enterprise Site Collection features
o   Site Collection --- manage Site Settings --- SharePoint Server Enterprise Site features

Microsoft Theory:
If Access Services is activated on an Application Server, then you will also need to turn on the Microsoft SharePoint Foundation Web application Service, thus turning that machine into a WFE/APP server. Problem with this approach is that it could affect your licensing agreement because licensing depends on the number of WFE’s your farm has. Hence, the workaround for this issue is to enable the Microsoft SharePoint Foundation Web Application service on the server running Access Database Services.

As per this, we have made the changes and started the access service on the same server where Microsoft SharePoint Foundation Web application Service is running.

5.    Make the changes in web.config file so that the error should be more clear and accurate one.  Changes includes: callstack=True and customerror=off
6.    Re-provision the access, session state, security token service applications

Resolution:
We have provided access to the account associated with Access Services the dbo permission for the content database in SQL Server for the particular site collection for which I was trying to add a Web Database.

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

Thank you.

Upgrade Best Practices SharePoint Server 2010

I was in a process of giving the details about migration to a organisation from 2007 to 2010 and found this useful article on Technet .

http://technet.microsoft.com/library/cc261992(office.14).aspx

To ensure a smooth upgrade from Microsoft Office SharePoint Server 2007 to Microsoft SharePoint Server 2010, follow these best practices

  • Update your servers to Service Pack 2 (SP2) of Microsoft Office SharePoint Server 2007 or later.
Your environment must be updated to Service Pack 2 of Office SharePoint Server 2007 to run the upgrade process, either for an in-place or database attach upgrade. We recommend that you install the October 2009 Cumulative Update because it includes improvements to the pre-upgrade checker tool. Ensure that the environment is fully functioning before you perform an upgrade.

  •  An upgrade does not solve any problems that might already exist in your environment. Therefore, ensure that the environment is fully functioning before you perform an upgrade. For example, if you have Web applications that are no longer being used, unextend them before you upgrade. If you want to delete a Web application in Internet Information Services (IIS), unextend the Web application before you delete it; otherwise, SharePoint Server 2010 will try to upgrade the Web application even though it does not exist, and the upgrade will fail. If you find and solve problems beforehand, you are more likely to meet the upgrade schedule that you have estimated.

  • Before you try an in-place upgrade, migrate to 64-bit servers. Upgrade your operating system to a 64-bit version of Windows Server 2008 R2 or Windows Server 2008 with Service Pack 2 (SP2). If you are using SQL Server, upgrade or migrate to a 64-bit version of Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3.

  • Do not try to combine these operations with your upgrade process. You cannot perform an in-place upgrade unless your system already runs on a supported operating system and platform.

  • Run the pre-upgrade checker to look for potential issues.

The pre-upgrade checker reports missing customizations and issues with orphaned sites, and more, so that you can address these issues before you perform your upgrade.

 For more information, see Run the pre-upgrade checker (SharePoint Server 2010).
  • Perform a trial upgrade on a test farm first.

Back up the live farm, restore to test servers, and then perform the upgrade. Examine the results to set expectations for what the live upgraded sites will look like, to determine how much post-upgrade customization will have to be done, and to estimate how long the upgrade will take. Try a full search indexing crawl. For more information, see Use a trial upgrade to find potential issues (SharePoint Server 2010).
  • Plan for capacity.
Ensure that you have disk, processor, and memory capacity sufficient to handle upgrade requirements. For more information about system requirements, see Review system requirements for upgrade (SharePoint Server 2010). For more information about how to plan the disk space that is required for upgrade, see Estimate how long the upgrade process will take and the space that you need (SharePoint Server 2010). For more information about how to plan for capacity, see Performance and capacity management (SharePoint Server 2010).
  • Back up your environment.
Perform a full backup of your environment before upgrading. That way, you can recover your environment if you must roll back from an upgrade. For more information, see Back up environment before an in-place upgrade (SharePoint Server 2010).
  • Optimize your environment before upgrade.
A few key limits have changed in SharePoint Server 2010, such as query throttling on large lists and lower limits on the number of site collections allowed per content database (from 5,000 warning and 15,000 limit to 2,000 warning and 5,000 limit). Be sure to optimize your Office SharePoint Server 2007 environment to meet these limits or restrictions before upgrade to mitigate errors during the upgrade process or broken lists or sites after upgrade. For more information about the site collection limit, see SharePoint Server 2010 capacity management: Software boundaries and limits. For more information about large lists and addressing the lower limit on site collections, see Clean up an environment before upgrade (SharePoint Server 2010).
  • (Optional) If you are using the database attach upgrade method, set the original databases to read-only.
If you expect a long outage window while you perform a database attach upgrade, you can set the databases in the original environment to be read-only so that users can continue to access their data without changing it. For more information, see Attach databases and upgrade to SharePoint Server 2010.
  • Do not add any servers to your server farm after you begin the upgrade process.
Running the SharePoint Products Configuration Wizard upgrades the configuration database. The configuration database contains the list of servers in the farm. Servers added to the farm after the configuration wizard has been run are not included in the database. Therefore, servers added after the wizard runs do not appear in the upgraded version topology. If you need to add servers to your farm, do so either before you start the upgrade or after you have completed the upgrade process.
  • After upgrade, review the Upgrade Status page and upgrade logs to determine whether there are issues that must be addressed. Then review the upgraded sites.
The Upgrade Status page reports on the upgrade progress, and the upgrade logs list any errors or warnings that occurred during the upgrade process. You should verify all of the sites and test them before you consider the upgrade complete. For more information, see Verify upgrade and review upgraded sites (SharePoint Server 2010).

Thursday, February 21, 2013

Code blocks are not allowed in this file SharePoint 2010



Hello Everybody,
Today I worked on one critical issue which belongs to our development environment. We have migrated one web application from production environment to development for testing purpose. Migration has been successful but we were facing an exception while browsing the web application.

Error Message:
An error occurred during the processing.
Code blocks are not allowed
Troubleshoot issues with Microsoft SharePoint Foundation.

Server Configuration:
·         2 SharePoint Servers
·         SQL server 2008 R 2
·         Windows Server 2008 R2
·         SharePoint Version: SP2010

Troubleshooting done:
1.    Tried accessing the system pages i.e. settings.aspx, viewlsts.aspx etc. every system was opening fine without any issues. So the issue is with the home page only…
2.    Tried accessing the web part maintenance page, it opened without any issues. We closed the webparts which are present on the home page-just to make sure that there is no problem with the existing webparts. Checked the home page again but same issue.
3.    Tried changing the master page as were able to open the system pages (by appending _layouts/changesitemasterpage.aspx). We changed to different one as we are using custom master page. Checked the results again but same problem.
4.    Opened the site in SharePoint Designer 2010 and checked the status of master page as well as the home page. It was fine and without customization too.

Note: if you see any of these pages in customizable state then I would suggest you to take the backup and try ‘reset to site definition” option.

Obviously, next question will arise- what exactly it will do? Yes, it will reset your page to default state. It means you will lose your customizations. But issue will be resolved and you can customize the page again as per your requirements.

5.    Checked the windows application as well as SP logs (Location: \14\Logs). I would suggest you to analyze these logs before continuing your troubleshooting.

What is my observation\Understanding?
·         Code blocks are only processed for custom pages deployed in the root virtual directory of a site if the code it considered safe.
·         This code is considered safe only if the page is served directly from the file system. As soon as it becomes unghosted for any reason, the code is no longer considered safe and the error shown in the symptom occurs.

Resolution:
As our production web application was working without any issues so I compared the web.config of both the applications. Analyze the code line by line with the production web.config and that’s it. I found the one which was missing in the web.config that belongs to my development web application.

Note: I would suggest you to take a proper backup before making any changes in the web.config file.

What I did? What kind of entries I added in the web.config file?

Here we go:-
In you web.config, you need to search the tag name as “<PageParserPaths>”
Once you find that then make the following  entry:
<PageParserPaths>
    <PageParserPath VirtualPath="/apps/*" CompilationMode="Always"
              AllowServerSideScript="true" IncludeSubFolders="true" />
</PageParserPaths>
After adding this entry then IISRESET is mandatory.

Tried accessing the site and the issue has been resolved.

Happy SharePoint once again…

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

Users cannot see the checked out files in the folder/ library

I Came across a Issue today wherein the user opened a ticket for the below issue Issue : Users cannot see the checked out files in the fo...