Thursday 28 November 2013

PowerShell cmdlets for SharePoint ::: Check DB that must be upgraded

Hi all,

Today, I’ll write down the PowerShell cmdlets used to diagnostic and solve the error “Database is in compatibility range and upgrade is recommended”.

The reason of this error is simple: I ran the SharePoint Feb 2013 Cumulative Update on my production Farm, and I got errors.
Thus, some DB’s are upgraded, other are not.

Now, I want to list them, and check in my test environment if I can upgrade each DB one by one without having my entire Farm down.
If my farm is down during the process, I must prepare a technical activity and work on it during the night.

I found a post from academicjargon giving the cmdlets to use. 

List DB that need to be upgraded:
Get-SPDatabase | ?{$_.NeedsUpgrade –eq $true} | Select Name

List DB that need to be upgraded and upgrade them:
Get-SPContentDatabase | ?{$_.NeedsUpgrade –eq $true} | Upgrade-SPContentDatabase

And this cmdlet if you want to upgrade one specific content DB:
                Get-SPContentDatabase –Identity SP2010_MySiteContentDB | Upgrade-SPContentDatabase





Job’s done.

Thursday 1 August 2013

Error 404 with Calendar Overlay across 2 Web Applications (part 2)

Hi all,

This is the reply that I’ve received this morning from our Vendor concerning the Calendar Overlay issues between multiple Web Applications: “it’s by design”.
So, no fix can be expected for this at the moment.

Therefore, I recommend educating the end user to open the item in the correct Web Application when needed.


You can find hereunder the complete explanation:


--------------------------------------------------------------- 
Hello Marc

As I also could repro the issue, MSFT did further research and found that this behavior is ‘by design’.
The issue has been addressed by the product group earlier and this was their answer :


It turns out it is by design:
=====================

We have conducted a thorough investigation into this matter and have determined the issue is Design Change Request in a feature area of substantial complexity. This complexity precludes making changes in this area outside of a major release.

The SharePoint calendar aggregation feature was designed to aggregate calendars within a single web application.
The calendar can aggregate across alternate access mappings, but not across apps. The alternate access mapping support did, however, make it appear that calendars could be aggregated across multiple web apps, but that is not a supported scenario. Adding support for cross web application calendar aggregation would involve significant feature work and as such, is not possible in a QFE.

Microsoft carefully reviews all Hotfix requests, as each code change must maintain or improve both quality and stability of the product.
In this instance, the risks to product quality and potential for destabilization are too high to permit changes in this area outside of a major release.

We thank you for bringing this issue to our attention and continuing to work with us on improving our products for customers worldwide.


The response is actually coming from the product group and they have no ETA on this nor if it will be fixed or not in future releases.
--------------------------------------------------------------- 



Voilà.


Wednesday 31 July 2013

Error 404 with Calendar Overlay across 2 Web Applications (part 1)

Hi all,

Last week, I received a mail asking me if there was an issue with SharePoint.
The reported problem was that the client got an “Error 404” page when opening an item in her Overlay Calendar.

So, first thing first, is to reproduce the issue;

The client is using a calendar in her SharePoint Site (let’s call it TT2013MMA from the shpTeamCalendar Web Application).
Then she added the calendar of another site (let’s call it WW2013MMA from the shpWorkCalendar Web Application).

All is working like a charm, as the items of both calendars are correctly added, named in the TT2013MMA Calendar.

The problem start when you click on one of the items.
If the item is from the same calendar (the TT2013MMA), the details of this item is opened and can be reviewed/modified.
If the item is from the calendar located on the other Web Application (WW2013MMA), we got a nice looking 404-Error page not found.

I made some research, and I notice that doing calendar overlay across multiple Web Application gave the same problem.




So, at the request of Microsoft, I’ve reproduce with success the issue in my Test Farm with 2 brand new Web Applications.


Server name : test.domain\TestServerName

Tests were done with in both sites: test.domain\MyLogin (Mathot Marc)

Calendar of the second Web App : http://shpTeamCalendar-test.domain/sites/TT2013MMA


And the item added from this calendar are in green.

The overlayed calendar (from the second Web Application), is on this site : http://shpTeamCalendar-test.domain/sites/TT2013MMA
The items from the TT2013MMA calendar are in yellow.


Calendar using the Overlay in the shpWorkCalendar Web Application:



 Calendar from the second Web Application : shpTeamCalendar






Now, let’s check the URL pointing to the different items in the shpWorkCalendar:
                The URL is correct :
-          Web Application of the Calendar : shpWorkCalendar
-          Site (WW2013MMA) is created on the shpWorkCalendar Web Application



The URL of the item is incorrect:
-          Web Application of the calendar is shpWorkCalendar
-          Site (TT2013MMA) is created on shpTeamCalendar and NOT on shpWorkCalendar.
SharePoint is pointing to the source Web Application (shpWorkCalendar) instead of the correct URL where the item was created.





Same fort his second item :
                The correct URL must be : http://shpTeamCalendar-test.domain/sites/TT2013MMA/Lists/Calendar/DispForm.aspx?ID=2








And also for the last one:



  
Result on clicking on the NOK item, is a Error-404 page.


My vendor already made testing, and had the same results as mine.
Now, waiting for the Microsoft specialist to make the same tests, and give his feedback.



So, as far as from now, I have no solution, nor workaround.


... to be continued...

Unable to enter the Enterprise Licence on SharePoint Server 2010

Hi all,

This time, I was asked to install the Enterprise Licence into our Standard SharePoint 2010 Server test Farms.

We have 3 Farms in Test environment:
-          Collaboration Farm (4 VM)
-          Application Farm (1VM)
-          Service Farm (2 VM)

So, I tried to add the Licence Key via the Central Admin GUI, and I always got an error : “An error occurred”.

After close work with Microsoft, I set the logs into Verbose mode and reproduce the issue, and then finished by running the Microsoft Diagnostic tool for SharePoint.
Then, I got an explanation of my problem.
This issue happens when the Farm does not have enough resources or the load is too high or a combination of both (VM servers, in a test environment – less CPU and less RAM than in production), the upgrade process wants to upgrade all services (new ones for instance) and so on, on all servers.
It’ll try this 3 times, afterwards it gives a time-out as being impossible because the Farm was too busy.

Then, I’ve executed with success the proposed action, explained hereunder:

Action plan:
========

Please take all necessary measures before executing the action plan in order to be able to restore your Farm from backups.


1. Create a simple console application (code) that does nothing, just returns a success code, call it psconfig.exe (see details below)
2. Backup the original psconfig.exe and replace it with the previously created app.
3. Perform the operation (Enable Enterprise features)
4. Restore the original psconfig.exe
5. Run psconfigui.exe on all servers in the farm

Details:

If you don’t have visual studio installed you can use the compiler to create the exe file. 
Steps:  

1. Create new text file and write this piece of code:
Code sample: 

namespace customapp 
  class Program 
    { 
      static void Main(string[] args) 
        { 
          System.Environment.ExitCode = 0; 
        } 
    } 
}
2. Save the file as psconfig.cs
3. Open a command prompt by choosing “Run as administrator” 
4. Put the created file in c:\<location>
5. Navigate to C:\Windows\Microsoft.NET\Framework64\v2.0.50727 folder 
6. Run the csc command giving as parameter the source file (c:\psconfig.cs) 
• e.g. C:\Windows\Microsoft.NET\Framework64\v2.0.50727>csc c:\psconfig.cs
7. The file psconfig.exe will be created on path C:\Windows\Microsoft.NET\Framework64\v2.0.50727>csc c:\psconfig.cs

==========================================


And that’s it!

Now, I have to plan a technical activity to add the Enterprise Licence into my production Farm.
According to Microsoft specialist, I’ll not facing the same issue as my production Farm has enough CPU/RAM.

But in case of, I have this procedure, tested and approved.


Job’s done.

Tuesday 18 June 2013

Event ID: 7362: The super user account utilized by the cache is not configured

Event ID: 7362: The super user account utilized by the cache is not configured


Hi all,

Today, I’ll explain how I solve the Event ID 7362 concerning the Publishing Cache.
I made a copy/paste of the used explanation from Stephan Albert Bren blogspot.
On his page, there is the stsadm version that I didn’t used, because I prefer to use PowerShell version.
Also, check the references at the bottom of his post, referring to Microsoft TechNet and other blogs.

Big thanks to Stephan for his clear explanation of the root cause of this event ID.




Problem

The following error appears in the Windows Application event log:

 

















Solution

On new installations, the SharePoint super user account is configured to run under the machine's local System account.  However, this causes complications and thus the warning.  This should be addressed during setup, but isn't included in the setup wizard. 



Step 1: Create Super User and Super Reader Domain Accounts

Create super user and super reader domain accounts



Step 2: SQL Database access rights

Make sure these accounts have similar access to all SharePoint databases.

Script to use for each Content Database:

SQL Script 1 for adding the Super User account as db_owner:


 










SQL Script 2 for adding the Super Reader account as db_reader:




 Step3: Configure Accounts in SharePoint Central Administration

Go to your SharePoint CA GUI:
Central Admin -> Manage Web Application -> User Policy

Add DOMAIN\super_user           – Full Control
Add DOMAIN\super_reader        – Full Read



Step 3: Using SharePoint Management Shell

Open a SharePoint PowerShell

Execute the following commands:

$w = Get-SPWebApplication -Identity
http://[webappurl/]
$w.Properties["portalsuperuseraccount"] = “DOMAIN\super_user”
$w.Properties["portalsuperreaderaccount"] = “DOMAIN\super_reader”
$w.Update()

Close the shell

 





Step 4: Reset IIS

Step 5: Verification

Open a SharePoint PowerShell

Execute the following:

 


 Output should read:
 




Important Note :
Please do the mentioned steps when adding a new Web Application in Application and/or Collaboration Farm.




Job’s done.

Thursday 16 May 2013

How to restore the "default.aspx" in SharePoint Designer 2010

Hi all,

Today, I got a ticket concerning the fact that the “default.aspx” was deleted in a Site Collection.


My first question was “How did they achieve this?”, because they cannot delete system files, as SharePoint Designer 2010 access is limited at the Web Application level:



So, I had to open the Site Collection in SharePoint Designer 2010 with full access to be able to view all files.

To do this, I’ve allowed the Web Application option : “Allow Site Collection Administrators to see the URL Structure of their Web Site”
Then, I’ve opened the Site Collection in SharePoint Designer 2010, and set back the options in “SharePoint Designer Settings” as our default settings. (this, to avoid other clients to open their site in SharePoint Designer 2010 and letting them braking their site)

In SPD2010 (SharePoint Designer 2010), the “default.aspx” was missing.
But, I saw the file “Organogram.pptx” with the blue icon.
Checking it’s properties gave me the satisfaction that the “default.aspx” was overwritten by the .pptx, but was still known by SharePoint as the “default.aspx” file.





So, I decided to do a “Reset to Site Definition” of this file :



The .pptx file was “cleaned” (check it’s size), and the original faulty .pptx is now set as a copy, and not simply deleted:



Thus, I’ve renamed the “clean” .pptx into “default.aspx



A page refresh, and the client site is now up’n running again:



Job's done.

Wednesday 15 May 2013

How to Restore a Deleted Site Collection in SharePoint 2010

Hi all,

Today, I was asked to restore deleted files from a deleted Site Collection in our production farm.

As usual, when I receive this kind of request (recover deleted files) , the procedure is:

-          - Ask SQL Team to restore the DB from the day before deletion
-          - Mount the DB in a  specific Web Application
-          - Set the restored DB as “Offline” in Central Administration
-          - Go to the site and export the deleted files to the client’s SharePoint Site
-          - Remove the restored DB from the Web Application
-          - Delete the DB from SQL


The SQL Corporate rules concerning the backup retention time is 14 days.

But this time, the site was deleted for 16 days, so out of the backup retention time…
No restore available.


Then, I remember that the production DB are keeping the deleted Site Collections for 30 days !!!
Thus I will be able to restore the deleted Site Collection, and my client will be happy to recover all missing files.

Steps to follow are:

-          Get-SPDeletedSite : this will give the list of all deleted Sites Collection in the Farm


In the red box, I can find the Path and the Deletion Time, that match with the info given by the client.

-          I will then restore the Site Collection with the following cmd :
Restore-SPDeletedSite –Identity “/Sites/CD10000059”
               
                /!\ A Site Collection must not already exist at the URL location to perform a restore /!\


Voilà, the site is now restored from the DB’s recycle bin.


That’s all folks


Monday 6 May 2013

How to Delete a corrupt file entry in SQL DB

Hi All,

Today, I’ll explain the way I found to clear a file issue in one of the SharePoint 2010 site.
File is visible in the AllDocs list, but not available even when opening the Library with the “Open with Explorer”  ribbon option.

The faulty file the file name mentioned in the red box hereunder, and it’s extension is .xmind (event if the icon is a pdf).

So, all the site is working like a charm, without any error.



When trying to open the file, or making any change to it via the drop-down menu of the file, I got the http 500 error :




First, I made a –databaserepair to find the corruption, and try to fix it with the –deletecorruption parameter : didn’t help.

PS C:\Users\sharepoint_install> stsadm.exe -o databaserepair -url http://<siteURL>/Sites/SiteName -databasename Sharepoint_Content_shpDBName_RestoreFromProductionForTest

<OrphanedObjects Count="2">
  <Orphan Type="SecurityScope" SiteId="{69446A31-82A4-481E-9889-4661A810AD16}" Name="Sites/SiteName/Lists/ProjectDocuments /P131070_SmartMonitoring_WBS.xmind" InRecycleBin="No" />
  <Orphan Type="SecurityScope" SiteId="{96A99C51-C636-4593-BF9C-ED610ACA4743}" Name="Sites/SiteName/Lists/ProjectDocuments /P131063_Project_Definition_One Number_draft v0.1.docm" InRecycleBin="No" />
</OrphanedObjects>

PS C:\Users\ sharepoint_install> stsadm.exe -o databaserepair -url http://<siteURL>/Sites/ SiteName -databasename Sharepoint_Content_shpDBName_RestoreFromProductionForTest

Violation of PRIMARY KEY constraint 'Perms_PK'. Cannot insert duplicate key in object 'dbo.Perms'. The duplicate key value is (96a99c51-c636
-4593-bf9c-ed610aca4743, 0x, Sites/SiteName/Lists/ProjectDocuments/P131063_Project_Definition_One Number_draft v0.1.docm).
The statement has been terminated.



Then, I decide to open SQL, and start finding the document entries.
Of course, there is no clear post/site/info showing all the tables to check.

I found 2 tables :
-          AllDocs
-          AllDocStreams


First things first :

1.       Find the file in the AllDocs table and grab the Id entry

/****** Script for SelectTopNRows command from SSMS  ******/
SELECT *
  FROM [Sharepoint_Content_shpDBName_RestoreFromProductionForTest].[dbo].[AllDocs]
  WHERE [DirName] like 'Sites/SiteName/Lists/ProjectDocuments'
/**********************************************************/


The result is :


So, I have the unique Id, and looking at the column named “DocLib RowId” let me do a double-check that the file is the correct item to delete (check the ID row in the List from the first screen).


2.       Find the same Id entry in the AllDocStreams table

/****** Script for SelectTopNRows command from SSMS  ******/
SELECT [Id]
      ,[SiteId]
      ,[Content]
      ,[RbsId]
      ,[InternalVersion]
FROM [Sharepoint_Content_shpDBName_RestoreFromProductionForTest].[dbo].[AllDocStreams]
WHERE [Id]='DEF629C6-3A40-473A-BDD5-BB295E9E1AB1'
/**********************************************************/




3.       Delete both entries in the SQL DB :

/****** Script for SelectTopNRows command from SSMS  ******/
DELETE
  FROM [Sharepoint_Content_shpDBName_RestoreFromProductionForTest].[dbo].[AllDocStreams]
  WHERE [Id]='DEF629C6-3A40-473A-BDD5-BB295E9E1AB1'
/**********************************************************/

Result : (1 row(s) affected)



/****** Script for SelectTopNRows command from SSMS  ******/
DELETE
FROM [Sharepoint_Content_shpDBName_RestoreFromProductionForTest].[dbo].[AllDocs]
where [Id]='DEF629C6-3A40-473A-BDD5-BB295E9E1AB1'
/**********************************************************/

Result : (1 row(s) affected)


4.       Test that the file is no more listed in the Site:

Voilà, my test in the UAT farm is successful, I’ll do the changes into the Production environment.


That’s all Folks.


nb: change done with success in production.


Tuesday 15 January 2013

Issue with SharePoint 2010 Farm Update

Hi all,

Today, I’m taking the time to solve my “Upgrade Available” issue in my production farm.

Last time, I’ve noticed that, after successfully upgraded my production farm, the status went back to “Upgrade Available” after being successful.
So, the binaries are 14.0.6117.5002


The status is now as on this screen below :

I know that I have 2 sites that gave me errors when upgrading my farm, but I used a workaround to be able to apply the Feb 2012 CU :
Backup/Delete/Restore of both faulty sites.

Step 1: let’s list the DB where are located those 2 sites

Central Administration => Upgrade and Patch Management => Review database status:



I google about this status “Database is up to date, but some sites are not completely upgraded”, and fount this link where I found 2 powershell lines to execute:

$DB = Get-SPContentDatabase -Identity DB_NAME
Upgrade-SPContentDatabase -id $DB

This must be done for each DB after having fixed the error.

To be honest, I used this Upgrade-SPContentDatabase command to check the resulting error log, and find the site, and the error type.

Step 2 : let’s check the error log and find the direction to look



Opening the “Upgrade-20130115-094410-390.log, then finding the first [ERROR] entry show this :


[powershell] [V2VRecordCenterUpgradeSiteAction (13.0.2.0)] [ERROR] [15/01/2013 09:44:14]: Failed to run V2VRecordCenterUpgradeSiteAction.Upgrade for SPWeb (http://shpteam.xxxxxxxx/sites/TTeamSite/backoffice), the following error occured:The specified name is already in use.

Please try again with a new name. at:   at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx)
   at Microsoft.SharePoint.Library.SPRequest.AddGroup(String bstrUrl, String bstrName, String bstrDescription, Int32 lOwnerID, Boolean bOwnerIsUser, UInt64 iPermMask, Int32 lUserId, Boolean bUseExisting, Boolean bSelfOwner)
   at Microsoft.SharePoint.SPGroupCollection.AddInternal(String name, SPMember owner, SPUser defaultUser, String description)
   at Microsoft.SharePoint.SPGroupCollection.Add(String name, SPMember owner, SPUser defaultUser, String description)
   at Microsoft.SharePoint.Utilities.SPUtilityInternal.CreateDefaultSharePointGroups(SPWeb web, String strUserLogin, String strUserLogin2, String strGroupNameSeed)
   at Microsoft.Office.RecordsManagement.Internal.DocumentRoutingFeatureReceiver.<>c__DisplayClass2.<FeatureActivated>b__0()
   at Microsoft.Office.Server.Utilities.CultureUtility.RunWithCultureScope(CodeToRunWithCultureScope code)
   at Microsoft.Office.RecordsManagement.Internal.DocumentRoutingFeatureReceiver.FeatureActivated(SPFeatureReceiverProperties properties)
   at Microsoft.SharePoint.SPFeature.DoActivationCallout(Boolean fActivate, Boolean fForce)
   at Microsoft.SharePoint.SPFeature.Activate(SPSite siteParent, SPWeb webParent, SPFeaturePropertyCollection props, Boolean fForce)
   at Microsoft.SharePoint.SPFeatureCollection.AddInternal(SPFeatureDefinition featdef, Version version, SPFeaturePropertyCollection properties, Boolean force, Boolean fMarkOnly)
   at Microsoft.SharePoint.SPFeatureCollection.AddInternalWithName(Guid featureId, String featureName, Version version, SPFeaturePropertyCollection properties, Boolean force, Boolean fMarkOnly, SPFeatureDefinitionScope featdefScope)
   at Microsoft.SharePoint.SPFeatureCollection.Add(Guid featureId)
   at Microsoft.Office.Server.Upgrade.SiteAction.ActivateFeature(SPFeatureCollection features, Guid featureGuid, String featureScope, Boolean force)
   at Microsoft.Office.Server.Upgrade.SiteAction.ActivateFeatures(SPFeatureCollection features, Guid[] featureGuids, String featureScope)
   at Microsoft.Office.Server.DLC.Upgrade.V2VRecordCenterUpgradeSiteAction.UpgradeWeb(SPWeb web)


So, I had to go to the site, and I was not able to find the name that was already in use….

I google again , and find a post of Gayan Peiris with this little explanation :


In my case, the duplicate name was “Back Office”.

But, I was able to find only 1 “Back Office” site, the site mentioned into the error log.

Then, I decide to go to the root URL of this site “http://shpTeam.xxxxxxx/sites/TTeamSite”
I found then, that the mentioned “Back Office” name was a sub site of TTeamSite.

And, another “Back Office” site was already created, but with the “bo” name instead of “Back Office”.

Both sub sites had the same name, and this was the root cause of the issue.

I deleted the “Back Office” sub site, and got this situation:
  "Back Office" name is now used once.

Then, I’ve executed again the Upgrade-SPContentDatabase command, I my DB was successfully upgraded.

Now, here is the situation :

Step 3 : do the same steps as beginning, and solve the issue following the given error message in the log.

This is the error lines found on the log :
[powershell] [SPSiteWssSequence2] [ERROR] [15/01/2013 10:46:03]: Feature upgrade incomplete for Feature 'PublishingWeb' (Id: '94c94ca6-b32f-4da9-a9e3-1f3d343d7ecb') in Web 'http://shpworkgroup.xxxxxx/sites/WWorkgroup'. Exception: Provisioning did not succeed. Details: Failed to provision role definitions. OriginalException: Value does not fall within the expected range.  (Inner Exception: Value does not fall within the expected range.)
[powershell] [SPSiteWssSequence2] [ERROR] [15/01/2013 10:46:03]: Feature upgrade incomplete for Feature 'PublishingWeb' (Id: '94c94ca6-b32f-4da9-a9e3-1f3d343d7ecb') in Web 'http://shpworkgroup.xxxxxx/sites/WWorkgroup'. Exception: Dependency feature 'PublishingSite' (id: f6924d36-2fa8-4f0b-b16d-06b7250180fa) for feature 'PublishingWeb' (id: 94c94ca6-b32f-4da9-a9e3-1f3d343d7ecb) is not activated at this scope.

So, I activate the features for this site :

stsadm -o activatefeature -filename publishingSite\feature.xml -url http://shpworkgroup.xxxxxx/sites/WWorkgroup -force
stsadm -o activatefeature -filename publishingWeb\feature.xml -url http://shpworkgroup.xxxxxx/sites/WWorkgroup -force



Then, let’s upgrade again the DB :

$DB = Get-SPContentDatabase -Identity DB_NAME
Upgrade-SPContentDatabase -id $DB

Looks nicer :





But, unfortunately, the status is still the same :



Checking the upgrade status via the stsadm command :
stsadm.exe -o localupgradestatus


So, all seems ok, except the CADM page.

Let’s recycle IIS :

Check the CADM page :

Voilà !

I can now plan the next step : run the SharePoint Products Configuration Wizard.


Job’s done.