Wednesday, 30 April 2014

OWA intermittently not returning office documents in Office Web Apps 2013

Problem: Intermittent requests are not returning the pdf/word documents. Most requests are working and occasionally 1 request doesn't work. Every 4th request tries to get the pdf to display on Office Web Apps for a few minutes without any error message and then stops trying and displays the message "Sorry, Word Web App can't open this ... document because the service is busy."

I have 4 OWA/WCA servers on a stretched farm being used by SP2013 etc.

Initial Hypothesis: Originally I thought it was only happening to pdfs but it is happening to word and pdf documents (I don't have excel docs in my system). My monitoring software SolarWinds is badly configured on my OWA servers as the monitor is showing green, drilling down into the servers monitoring; the 2 application monitors are both failing. The server should go amber if either of the 2 applications monitoring fails and in turn red after 5 minutes. At this point I notice that I can't log onto my 4 OWA/WCA server. Web request are not being returned. I look at my KEMP load balancer and it says all 4 WCA servers are working, I notice the configuration is not on web requests but on ping (not right) and the NLB/KEMP is merely redirecting every 4th request to the broken server.

  1. Reboot the broken server, once it comes up I can make http requests directly to url on the rebooted server.
  2. SolarWinds monitoring is lousy - need to fixed the monitoring.
  3. Kemp hardware load balancing needs to be changed from checking the machine is "ON" to rather checking each machine using a web request.
SolarWinds Monitoring is not configured correctly


Sunday, 20 April 2014

Backup and Restore Site Collection in SP2013

Overview:  I have seen several customers us Backup and restore to help speed up the development process and have the ability to deploy between DTAP environments.  So the basic premise is create the site collection on dev/a and use backup and restore to promote the site collection including customisations and code in the next environment.

SharePoint 2010:  In SP2010 this worked assuming the env you are going to has a higher patch level than the source environment.  So if you went from SP2010 + cu to SP2010 + SP1 in production backing up and restoring the site collection works.  The trick was to package all assets into the site collection and to ensure all environments were on the same edition/patch level (or at least the destination farm was patched to a higher level than the source farm).

SP2013:  You can use PS backup and restore to move site collections but it is further restricted.  The source and destination environment need to be the same edition.  My issue is I can't move a troublesome production environment back to UAT as my UAT has been patched and is a later/newer version of SP2013 on prem.

I learnt this when restoring the site collection from 15.0.4481.1005 (SP2013 + Mar CU) on the source and trying to go to 15.0.4569.1000 (SP203 + SP1) y destination farm.

Restore-SPSite : 0x80070003
At C:\Users\SP_install\AppData\Local\Temp\5ae5fd1c-86ac-4032-8975-c739f39b6f36.ps1:3 char:1
+ Restore-SPSite –Identity "" –path "C:\Software\Deplo ...
+ CategoryInfo : InvalidData: (Microsoft.Share...dletRestoreSite:SPCmdletRestoreSite) [Restore-SPSite], DirectoryNotFoundException + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRestoreSite  

Conclusion:  To move Site collection between farms or to different content databases, the SP farms need to be using the exact same version of SP.

Sunday, 6 April 2014

Writing SharePoint PowerShell Modules or snap-ins

A module is a self-contained set of code that once loaded can be called/used.  I use modules to keep similar SharePoint functionality that I want to reuse.  There are 2 basic types of modules:
1.> Script modules, this is the easiest and most common type of module.  Take you .ps1 file and rename it .psm1
2.> Code/Binary modules are compiled dll's that can be loaded and used.  You can also create a snap-in with binary code.
3> Snap-ins, are compiled code dll's.  The snap-ins can be loaded and used within your PS console.

Snap-ins are not code modules.  I prefer to keep my files as ps1 files and load them in a controlling .ps1 files before using them or if I need to write code that uses the CSOM I would use C# and create a snap-in that I can port and consume.

More Info: