Troubleshooting WCF and JSON serialization under SharePoint 2010 Context

Scenario:
To host a WCF service into SharePoint 2010 and surface its data using JSON serialization. After setting the service up and deploying it to SharePoint I run into a few issues before I could get any joy. This post will show you the problems I run across. 


NOTE: This post won't go into details about how to deploy a WCF service into SharePoint 2010. I'm planing to cover this in further detail in my next post.

Okay so, to start with here's the interface of the WCF method. The implementation of GetMessageJSON() is simply the almighty "Hello World!" hence why it's omitted.  

When I tried to browse the JSON method I got nothing but a blank HTML page. Fiddler helped me to discover there was exception there 400 Bad Request Exception.    


http://YourServer/_vti_bin/JqueryWCFRestSP/CustomerService.svc/GetJOSNMessage


However I could browse to the service WSDL with no problem and I could see its definition which appeared to be fine.


http://YourServer/_vti_bin/JqueryWCFRestSP/CustomerService.svc?wsdl


Strange, could get to the WSDL but can't get to the JSON method? Mmmmm, I knew there was nothing wrong with the WCF method (return "Hello World!" come on!) nor with its interface. So the actual problem was in the web.config this time as I was using basicHttpBinding which does not support JSON. Point taken, changed the binding  to webHttpBinding which does, redeployed the solution and problem gone. Next!


This time the WebRequest when through however I was getting the following response.

Later on I found out this can be due to the following reasons:

• Using different contracts between client and sender.
• Different binding between client and sender.
• The message security settings are not consistent between client and sender.

As Brian McNamara correctly pointed out when web-hosted, the EndpointAddress of the service comes from the IIS base address (host headers).  In this case, it appears to be the "our-server" address.  By default, WCF ensures that the To of each Message matches the intended address.  If the service just has this one endpoint, a quick workaround would be to use 

[ServiceBehavior(AddressFilterMode=AddressFilterMode.Any)]

which turns off the address filter.  Otherwise, ensure the IIS host headers contain the 'public facing base address' that you want clients to connect to, so that messages will be properly addressed to the service. 

Unfortunately, Brian's logical input only fixed part of the problem (Thanks Brian!) So what about the other part? Well, the credit this time goes to Kiyoshi Kusachi.He introduced a  "nested" multi behaviour approach which turned to be the key of success. After updating the web.config accordingly the AddressFilter mismatch at EndPointDispatcher vanished completely.  

Finally, I was able to serialize it successfully to JSON using the snippet (Console App).

WebClient proxy = new WebClient();

byte[] data = proxy.DownloadData("http://YourServer/_vti_bin/JqueryWCFRestSP/                                     CustomerService.svc/GetJOSNMessage");

Stream stream = new MemoryStream(data);DataContractJsonSerializer obj = new DataContractJsonSerializer(typeof(string));string result = obj.ReadObject(stream).ToString();

Console.WriteLine(result.ToString());

Console.ReadKey(true);

Time for lunch now. Happy WCFing!

SharePoint 2010 Error : Invalid assembly public key. (Exception from HRESULT: 0x8013141E)

I was banging my head against the wall while trying to figure out what on earth SharePoint was intending to tell me by "Invalid assembly public Key". 

Well, it turns out, I first created an isolated WCF service and just a few minutes later I decided to run it under the SharePoint Context (by deploying it to ISAPI mapped folder). The keyword attribute 'PublicKey' appeared to be the culprit as it doesn't get parsed correctly, using 'PublicKeyToken' instead will likely fix the problem.

Hope that'll save you some time.  

Migrating on-premise SQL Server Databases to SQL Azure

Migrate your existing on-premise databases to the cloud shouldn't give you many headaches *hopefully*. That's right, just follow the steps below to find out how easy it is.


1. Select the Database | Tasks | Generate Scripts...  

2. Provide the file name and path where the script is going to be saved to. Then, click on Advance.

3. Change the database engine type to script using SQL Azure Database 

Make sure you include the Database content too. By default is set to schema only.

And that's it really, the generated script is now ready to run on the SQL Azure! You can then import that script and run it to SQL Azure environment. In the next post I'll show the step by step how to achieve it. Easy, huh?

Shrinking SharePoint_Config transactional log (when in emergency)

Some SharePoint critical errors thrown frequently and repeatedly might end up in an unexpected titanic growth of the SharePoint_Config transactional log. It can get seriously big, believe me... and the worst of all, it keeps growing and growing *fast*! 


This will lead us to an unstable working environment where nothing actually works as it should, slow, unresponsive and likely to be hit by collateral damage (i.e. Out of disk space just to name one). Well, my client fully suffer it the other day, the actual log hit the 1 TB mark! Woohoo!


So, no panic, before we get to diagnose and fix the cause of issue, let's quickly shrink the transactional log so we can get back to 'healthier' and quicker environment. 


Executing the following SQL script against the  SharePoint_Config database will compress the size of SharePoint_Config_log regardless of its size.

USE SharePoint_Config
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE SharePoint_Config
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (SharePoint_Config_log, 1);  -- here 2 is the file ID for trasaction log file,you can also mention the log file name (dbname_log)
GO
-- Reset the database recovery model.
ALTER DATABASE SharePoint_Config
SET RECOVERY FULL;
GO


From this point, the size of the log should be significally smaller. Hope you can can solve the issue/s now. Good luck!

Return only documents in search results

A few days ago my client came up with this new requirement where the SharePoint search should only display nothing but documents. Everything else will go ignored.

To achieve that I would recommend to create a Search Scope and then apply a set of rules that will basically prevent the unwanted items to show up.

The rules are:

*://*allitems.aspx*  Exclude

*://*webfldr.aspx*   Exclude

*://*mod-view.aspx*  Exclude

*://*my-sub.aspx*    Exclude

*://*/lists/*       Exclude

*://*lists*       Exclude

And here is how it should look once you entered them

    

For us, PowerShell entusiasts, here's how it looks  :)

write-host "Enter the Search Service Application Url where you need to apply the crawling rules:"

[string]$SearchServicerUrl = Read-Host #i.e. Enterprise Search Service Application

New-SPEnterpriseSearchCrawlRule -SearchApplication $SearchServicerUrl -Path "*://*webfldr.aspx*" -CrawlAsHttp 1 -Type ExclusionRule

New-SPEnterpriseSearchCrawlRule -SearchApplication $SearchServicerUrl -Path "*://*mod-view.aspx* " -CrawlAsHttp 1 -Type ExclusionRule

New-SPEnterpriseSearchCrawlRule -SearchApplication $SearchServicerUrl -Path "*://*my-sub.aspx*" -CrawlAsHttp 1 -Type ExclusionRule

New-SPEnterpriseSearchCrawlRule -SearchApplication $SearchServicerUrl -Path "*://*allitems.aspx*" -CrawlAsHttp 1 -Type ExclusionRule

New-SPEnterpriseSearchCrawlRule -SearchApplication $SearchServicerUrl -Path "*://*/lists/*" -CrawlAsHttp 1 -Type ExclusionRule

New-SPEnterpriseSearchCrawlRule -SearchApplication $SearchServicerUrl -Path "*://*all forms.aspx*" -CrawlAsHttp 1 -Type ExclusionRule


Happy Powershelling!

SharePoint 2010: Changing Regional Settings and Locale Settings in Powershell

I just had a client scenario where I have the SharePoint implementation has up to 40 different site collections to maintain. Well, I'm London based and so is my client... what about the default regional settings? Eng-US right? Is my client happy with it? Not really: en-GB, please!.
All right, first of all, let's change the Regional Settings at the level of the Web Application. That's the easy one, as it can be leveraged from SP "Central Admin" site. So simply follow the steps below:

• Go to "Central Admin"
• Click "Application management" from the quick launch.
• Click "manage web applications" under "Web application" heading
• Select web application on which you want to change the regional settings.
• From the ribbon click "General setting" and select "General Settings" from the dropdown.
• Setting modal dialog will appear, you can change the "default time zone" and other settings if you want to change, and click OK.
• IISReset

And you are done! Wait! What about the locale settings? Aha, the mighty Powershell is happy [once more] to come to the rescue! The following script will do the dirty job for you. In a nutshell it iterates through each site collection within a given web application updating its locale settings and verifying right after if that has been changed successfully.


[Reflection.Assembly]::LoadWithPartialName("System.Globalization") | out-null
clear-host
$SiteCols = Get-SPWebApplication "<SiteCol URL>" | Get-SPSite -Limit ALL | Select URL
foreach ($siteCol in $SiteCols)
{
write-host "---- Site Collection: " + $siteCol.url + "----"

 
get-spweb -site $siteCol.url -limit all |% {
$_.Locale = [System.Globalization.CultureInfo]::GetCultureInfo("en-GB");
$_.Update()
}
#check if culture has been updated
get-spweb -site $siteCol.url -limit all |% {
$_.Locale
}
}


By the way, make sure you are running the script under a site collection administrator; otherwise you'll get a nasty Access Denied exception.


Get-SPWeb : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
At line:4 char:12
+ get-spweb <<<< -site "<SiteCol URL>" -limit all |% {
+ CategoryInfo : InvalidData: (Microsoft.Share....SPCmdletGetWeb:SPCmdletGetWeb) [Get-SPWeb], UnauthorizedAccessException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletGetWeb


Make Powershell your buddy when it comes to pre-deploy | post-deploy tasks. It will save a lot time that's for granted, but also it will save you heaps of headaches when deploying SharePoint application between different environments.

Unable to add a lookup field using AddFieldAsXml –Solved!

I recently had a problem when trying to add a new lookup field programmatically. It turns out that Field ID was actually the culprit. You can't use a fixed field ID when using web.Fields.AddFieldAsXml(sColumnDefinitionXml) which is what the XML for a field is supposed to have when it is used as an element file in a feature, but not when you are adding the field using code.
Then:
Wrong XML definition for sColumnDefinitionXml


 
<Field Type=\"Lookup\" DisplayName=\"Chat Waiting Time\" Required=\"FALSE\" List=\"4c00bad4-e57d-417e-ad6e-d29fcad06c3f\" ShowField=\"AdvisorResultText\" Group=\"ChildLine Site Columns\" ID=\"{D4654C7B-7DDD-4c79-9CB1-7130B567C3BC}\" StaticName=\"ChatWaitingTimeLookUp\" Name=\"ChatWaitingTimeLookUp\" xmlns=\"http://schemas.microsoft.com/sharepoint/\" />"        

 
Right XML definition for sColumnDefinitionXml


 
<Field Type=\"Lookup\" DisplayName=\"Chat Waiting Time\" Required=\"FALSE\" List=\"4c00bad4-e57d-417e-ad6e-d29fcad06c3f\" ShowField=\"AdvisorResultText\" Group=\"ChildLine Site Columns\" StaticName=\"ChatWaitingTimeLookUp\" Name=\"ChatWaitingTimeLookUp\" xmlns=\"http://schemas.microsoft.com/sharepoint/\" />"        


Took it off and it worked like a charm. Now all lookup fields can be safely added by my feature receiver J.

SharePoint administration user accounts (MOSS and SP 2010)

Account	Account Name	Scope	Used By	Needed at	Requirements
Install Account	DOMAIN\SVCMossSetup	Farm	Person Installing	Setup	Member of the administrator group on each Web front-end (WFE) server and application server computer in the farm. Member of the following SQL Server groups with SQL Security administrator and database creator rights on SQL servers.
Farm Administrator Account	DOMAIN\SVCMossFarmAdmin	Farm	Central administration site application pool identity	Setup	Member of administrators group on each WFE server and application server computer in the farm with SQL security administrator and database creator rights on SQL Servers. Database Owner (DBO) for all databases and additional permissions on WFE server and application server computers are automatically configured for this account when SharePoint is installed.
SSP Admin Process Account	DOMAIN\SVCMossSSPAdmin	Farm	SSP Timer service; SSP Web services SSP App Pool Identity	SSP Creation	No configuration is necessary. The following permissions are automatically configured for this account when SharePoint is installed: DBO for the Share Service Provider (SSP) content database, read/write permissions for the SSP content database, read/write permissions for content databases for Web applications that are associated with the SSP, read permissions for the configuration database, read permissions for the central administration content database, and additional permissions on WFE server and application server computers.
Crawl / Content Access Account	DOMAIN\SVCMossCrawl	Farm	Windows SharePoint Services 3.0 Search service	SSP Creation	Must be a domain account, but must not be a member of the farm administrators group. Permissions automatically configured for this account when SharePoint is installed include the following: read/write permissions for content databases for Web applications, read permissions for the configuration database, and read/write permissions for the Windows SharePoint Services Search database.
Content Account	DOMAIN\SVCMossContent	App	Web Applications	App Pool Creation	No configuration is necessary. SQL Server privileges that are automatically assigned to this account are member of Database Owners Group for content databases associated with the Web application, read/write access to the associated SSP database only, and read permission for the configuration database. Additional privileges for this account on WFE servers and application servers are automatically configured by SharePoint.

SharePoint PDF iFilter Installation Guide

Windows SharePoint Services 3.0
[Indexing Server]

1. Install the PDF IFilter (see below for a list of available IFilters)
2. Add the .pdf file type to the index list:
   1. Open the Registry Editor (Start > Run > regedit)
      
   2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Applications_<GUID>_\Gather\Search\Extensions\ExtensionList
   3. Add a new String Value
      
      1. Value name: <next value in line>
         
      2. Value data: pdf
3. Change the registry keys pointing to the IFilter's GUID 
   1. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf
   2. Add or change the (Default) key value
      1. Old value:
         {4C904448-74A9-11D0-AF6E-00C04FD8DC02}
      2. (Foxit  x64 PDF IFilter) New value:
         {987F8D1A-26E6-4554-B007-6B20E2680632}
      3. (Adobe  x64 PDF IFilter) New value:
         {E8978DA6-047F-4E3D-9C78-CDBE46041603}
   3. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf
   4. Repeat step (b) above
4. Perform an iisreset
   
5. Perform a Full Update on the Search content indexes
   1. Open a Command Prompt on the Indexing Server
      
   2. net stop spsearch
      
   3. net start spsearch
      
   4. cd "C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\BIN"
      
   5. stsadm.exe -o spsearch -action fullcrawlstop
      
   6. stsadm.exe -o spsearch -action fullcrawlstart
      [Web Front End Server]
      
6. Copy the ICPDF.GIF () file to "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Images"
7. Edit the file C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\Template\Xml\DOCICON.XML
   1. Add an entry for the .pdf extension
      <Mapping Key="pdf" Value="icpdf.gif"/>
      
       

Microsoft Office SharePoint Server 2007
[Indexing Server]

1. Install the PDF IFilter (see below for a list of available IFilters)
2. Add the .pdf file type to the index list:
   1. Go to Central Administration, then to the Shared Services Administration Web of the current SSP, go to Search Settings and next to File Type
      
   2. Add a new file type pdf
      
3. Add the .pdf file type to the index list:
   1. Open the Registry Editor (Start > Run > regedit)
      
   2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Applications_<GUID>_\Gather\Search\Extensions\ExtensionList
   3. Add a new String Value
      
      1. Value name: <next value in line>
         
      2. Value data: pdf# Change the registry keys pointing to the IFilter's GUID 
   4. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf
   5. Add or change the (Default) key value
      1. Old value:
         {4C904448-74A9-11D0-AF6E-00C04FD8DC02}
      2. (Foxit  x64 PDF IFilter) New value:
         {987F8D1A-26E6-4554-B007-6B20E2680632}
      3. (Adobe  x64 PDF IFilter) New value:
         {E8978DA6-047F-4E3D-9C78-CDBE46041603}
   6. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf
   7. Repeat step (e) above
4. Perform an iisreset
   
5. Perform a Full Update on the Search content indexes
   1. Open a Command Prompt on the Indexing Server
      
   2. net stop osearch
      
   3. net start osearch
      
   4. Go to Central Administration, then to the Shared Services Administration Web of the current SSP, go to Search Settings and start a full crawl of all locations containing PDF files
      [Web Front End Server]
      
6. Copy the ICPDF.GIF () file to "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Images"
7. Edit the file C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\Template\Xml\DOCICON.XML
   1. Add an entry for the .pdf extension
      <Mapping Key="pdf" Value="icpdf.gif"/>

Available IFilters
Adobe PDF IFilter 9.0

• free (always good !)
• 32 bit: the IFilter is included with Adobe Reader. You must download and install the whole Adobe Reader package onto the server.
• 64 bit: download the standalone x64 IFilter(64 bit released recently, applies to the [Indexing Server])

Foxit PDF IFilter v1.0

• free for desktops, servers require a license
  
• 32 bit and 64 bit (IA64 currently being tested, applies to the [Indexing Server])