InfoPath: The SOAP message cannot be parsed.

A client wanted to use SSL across their SharePoint 2010 platform internally.  As part of that work, all of the InfoPath forms need to be updated.  There were three environments – Development, Test and Production.

The Production environment worked fine, but whenever I updated the data connections in Development or Test, I received the message:  “Unable to connect to the SharePoint site.  The SOAP message cannot be parsed.”

InfoPath_SOAP1

I struggled with this for awhile, and couldn’t work out what the problem was.  Whenever I reverted to non-SSL, I did not have any problems.  I initially thought that InfoPath did not like the self-signed certificates on Dev or Test, and I even tried domain trusted certificates similar to the Production environment, but to no avail.

I turned up full diagnostic logging on SharePoint, and it stood out that for some reason it was making requests to the non-SSL URL.  Whenever I tried it directly (eg http://xxtest01.xxx.internal/_vti_bin/Webs.asmx) I was redirected to HTTPS and received a valid response.

InfoPath_SOAP2

Finally, I took a look at the alternate access mappings, and discovered the problem – the public URL was not set to use HTTPS on Dev or Test, but was set to use HTTPS on Production.

InfoPath_SOAP3

As soon as I changed the public URL to https://xxtest01.xxx.internal, my problems in InfoPath disappeared and I was able to setup the data connections with SSL.

Converting SharePoint 2007 document library templates for SharePoint 2010

Following my previous article on Converting SharePoint 2007 list templates for SharePoint 2010, I received a comment last week on how to achieve this with document libraries, and more improtantly, how to do this with content.  It just so happens, I came across this very same scenrio a few months ago!
 
Essentially, the major difference is that instead of there being a single file involved to convert a list template, there are lots of files that need to be packaged back up – ie the binary files.
 
Now be warned, there is a 10 MB limit for exporting a document library with content, so do not reply on this as part of a migration strategy!
 
Here is the PowerShell script:
#Script:  UpgradeSharePointDocLibs
#Author:  Peter Heydon (www.heyweb.net)
#Date:	  03 June2011
#Purpose: This script will convert a SharePoint 2007 document library template with content to be SharePoint 2010 compatible.
#
#	WARNING: There is a 10MB limit on creating document library templates
#
#Credit for defining the conversion process:  http://tom-dw.blogspot.com/2010/06/importing-sharepoint-2007-list.html
#Credit for calling 7-Zip from Powershell: http://mats.gardstad.se/matscodemix/2009/02/05/calling-7-zip-from-powershell/
#Everything else cobbled together from Microsoft TechNet
#
#Requirements:
#	Three folders:	input		(SharePoint 2007 list templates)
#			output		(SharePoint 2010 compatible list templates)
#			processed	(SharePoint 2007 list templates that have been processed)
#	7z.exe (from 7-Zip installation: http://www.7-zip.org/)
#	makecab.exe (should be in your WINDOWS installation folder)
#
#WARNINGS:  There is zero error handling, so don't expect the script to be gracefull.  The script is supplied
#		'as is' and should be tested thoroughly before using in a production environment.  
 
### DEFINITIONS
$RootDir = "C:\temp\ps\"	#Ensure it has a trailing backslash ('\')
Set-Alias sz ("C:\Program Files\7-Zip\7z.exe")
Set-Alias mcab ("C:\windows\system32\makecab.exe")
 
#  Get list of all STP files
$InputDir = get-childitem ($RootDir + "input") 
 
foreach ($item in $InputDir | where {$_.extension -eq ".stp"})
{
	$targetFile = ($RootDir + "input\" +$item.name)
	$extractPath = $targetFile.substring(0,$targetFile.length-4)
 
	"Processing: " + $targetFile  
 
	#Create directory
	New-Item $extractPath -type directory
 
	#Expand STP File
	$extractPathOption = ("-o" + $extractPath)
	sz x $extractPathOption $targetFile
 
	#Start-Sleep -s 5
 
	#Replace files
	$manifestFileIn = $extractPath + "\manifest.xml"
	$manifestFileOut = $extractPath + "\manifestOut.xml"
 
	(Get-Content $manifestFileIn | ForEach-Object {$_ -Replace "<ProductVersion>3","<ProductVersion>4"} | Set-Content $manifestFileOut)
 
	#Cleanup files
	Remove-Item $manifestFileIn
	Rename-Item $manifestFileOut $manifestFileIn
 
	#Recompress (MakeCab)
	$cabFolder = $extractPath
	$filesToCab = get-childitem ($cabFolder)
	$itemNoExtension = $item.name.substring(0,$item.name.length-4)
	$NewSTPFileName =  ($RootDir + "output\" + $itemNoExtension  + ".stp")
	$ddfFile = New-Item ($cabFolder + "\~makecab.ddf") -type file
 
	Add-Content $ddfFile ".OPTION EXPLICIT"
	Add-Content $ddfFile (".Set CabinetNameTemplate=" + $itemNoExtension + ".stp")
	Add-Content $ddfFile ".Set Cabinet=on"
	Add-Content $ddfFile ".Set CompressionType=MSZIP"
	Add-Content $ddfFile (".Set DiskDirectory1=" + $cabFolder)
	Add-Content $ddfFile ".Set DiskDirectoryTemplate=CDROM"
 
	foreach ($item in $filesToCab)
	{
		Add-Content $ddfFile ("`"" + $cabFolder + "\" + $item.name + "`"")
	}
 
	mcab /f $ddfFile
 
	#Rename cab, and move to output folder
	Move-Item ($cabFolder + "\" + $itemNoExtension + ".stp" ) ($RootDir + 'output')
 
	foreach ($item in $filesToCab)
	{
		Remove-Item ($cabFolder + "\" + $item.name)
	}
	Remove-Item $ddfFile
	Remove-Item $extractPath
 
	#Move original file to processed folder
	Move-Item $targetFile ($RootDir + 'processed')
 
}

I haven’t tested this since I wrote it in February, and I don’t have a SharePoint 2007 environment handy at the point of this blog post.  Please leave a comment if it works or not. 

The SharePoint Pro’s Delivery Toolkit

I’ve been thinking about the applications I use regulary at work to help support the delivery of SharePoint projects.  I thought it would be a worthwhile exercise and list these out and to share what I use.

You will be surprised to find that this list has little to do with the SharePoint product, and more about the supporting tools that help me get on with my job.  They probably apply to many more cases than specifically a SharePoint Pro.  Here they are in no particular order:

  • Fiddler – a web debugger that is very useful for tracking many issues around SharePoint including authentiation (ie Kerberos), latency and proxy problems.
  • Lightscreen – My number one tool within the PortableApps suite, and just find it very quick and simple to use.  Great for grabbing that nasty error and to fill in documentation.
  • Password Safe – Perfect for keeping all the passwords in an organised fashion readily available.
  • Grindstone – Keeping track of time is a must for my role, and GrindStone makes it simple for me to keep track of my hours against projects.
  • Evernote – I ran my own wiki (Foswiki) for about a year running back to a PC at home, but I kept having problems with network connectivity, and just found the setup too unreliable (Foswiki itself was great for what I needed at the time).  Evernote is like a personal wiki on steroids, and great mobility options.
  • Putty – So what does an SSH client have to do with delivering SharePoint?  I can use it in the absence of telnet on a locked-down workstation or server for some rudimentary network tests, and I can in some cases use it to bypass proxy restrictions.

There are probably a few other, non-Microsoft tools that I use fairly regularly, but these are probably the main stable.  In all cases, these tools are also free to use, an added bonus.

What tools do you use?

SharePoint 2010: Exception has been thrown by the target of an invocation

Tried adding a new SharePoint 2010 server to an existing farm, and got this perplexing, and un-googleable message while running the product configuration wizard:

03/29/2011 16:02:21  11  ERR                                              Task services has failed with an unknown exception
03/29/2011 16:02:21  1  INF                                              Not running in high contrast, so we will paint the background with our trademarked image
03/29/2011 16:02:21  11  ERR                                              Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---&gt; System.ArgumentException: The directory name you entered is invalid.  Please enter a new name.
 at Microsoft.SharePoint.Administration.SPDiagnosticsService.set_LogLocation(String value)
 at Microsoft.SharePoint.Administration.SPDiagnosticsService.InitSPDiagnosticsServiceFromRegistry(SPDiagnosticsService service)
 --- End of inner exception stack trace ---
 at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct&amp; signature, IntPtr declaringType)
 at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
 at Microsoft.SharePoint.PostSetupConfiguration.ReflectionHelper.InvokeConstructor(String assemblyQualifiedName, Type[] constructorSignature, Object[] constructorParameters)
 at Microsoft.SharePoint.PostSetupConfiguration.TaskCommon.ReflectionHelperInvokeConstructor(String assemblyQualifiedName, Type[] constructorSignature, Object[] constructorParameters, TaskBase task)
 at Microsoft.SharePoint.PostSetupConfiguration.ServicesTask.InvokeServiceConstructor(String serviceRegistryKeyName, String solutionIdRegistryName, String serviceNameRegistryName, Type[] constructorSignature, Object[] constructorParameters)
 at Microsoft.SharePoint.PostSetupConfiguration.ServicesTask.InstallServiceInConfigDB(Boolean provisionTheServiceToo, String serviceRegistryKeyName)
 at Microsoft.SharePoint.PostSetupConfiguration.ServicesTask.InstallServices(Boolean provisionTheServicesToo)
 at Microsoft.SharePoint.PostSetupConfiguration.ServicesTask.Run()
 at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

The clue was the line: The directory name you entered is invalid.  I noticed on the existing servers that there was a SharePoint log directory on the D: drive, and suspected this to be the issue.

At first attempt, I changed the location of the diagnostic and usage logging, to no avail.  I ended up requesting an additional disk for my new server, creating the log directory on the D: drive and re-running the wizard.  This worked.

Issues with SharePoint Content Deployment

SharePoint’s content deployment feature is a great way to manage content changes, and very appropriate for public facing websites.  However I do have three quick comments on the functionality:

  1. Binary changes – I’m aware these are not covered under the scope of content deployment, but I’ve had a lot of problems where people have deployed code to the authoring farm and not to production.  Very frustrating when you’re trying to publish a change at 5PM on a Friday afternoon.  I would like to see the practicality of having the ability to have these binary changes included with content deployment.  Better release management would also probably help.
  2. Needs a farm admin to publish – I’d like to be able to delegate this to a business representative to run the publishing job (ad-hoc).
  3. Random publish failures – Sometimes, the publishing job just doesn’t work.  Try again and all is well.  If it is a timeout, it’d be great to see this automatically reattempt.