The other week I was in the process of migrating a SharePoint farm from one farm to a new farm. However, I found that there were a number of undocumented solutions installed that I needed to move as well… The WSP’s had been misplaced. We knew we could do this in code. But figured PowerShell would be a better idea. Here is that code:
[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)`
| Out-Null
[Microsoft.SharePoint.Administration.SPFarm]$farm`
= [Microsoft.SharePoint.Administration.SPFarm]::Local
[Microsoft.SharePoint.Administration.SPSolutionCollection] $solutions`
= $farm.Solutions
[string] $path = Get-Location
foreach($solution in $solutions)
{
Write-Host “Solution Name: $($solution.Name)”
$solution.SolutionFile.SaveAs((Join-Path $path $solution.Name));
}
I came across an issue when installing and trying to activate Nintex Reporting 2008 Workgroup Edition version 1.3.0.5 to a SharePoint Site.
Upon activating the “Nintex Reporting 2008 Team Site Reporting” feature, I received the error “A Web Part or Web Form Control on this Page cannot be displayed or imported. The type is not registered as safe.” http://connect.nintex.com/forums/thread/14467.aspx.
After checking my application pool account was a member of the nintex reporting role, I checked the safe controls section of each zone for the web application and found that they were indeed missing entries, however, the entries described on the forum as incorrect. These should be:
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ApplicationPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ApplicationPages.ServerControls” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ApplicationPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ApplicationPages.TeamSiteReporting” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ApplicationPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ApplicationPages.TeamSiteReporting.SitePages” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ApplicationPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.ApplicationPages” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ApplicationPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ApplicationPages.Properties” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ServerControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ServerControls” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ServerControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ServerControls.WebParts.Contracts” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ServerControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ServerControls.WebParts” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ServerControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ServerControls.ColumnDisplayType” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ServerControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ServerControls.Pdf” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ServerControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ServerControls.Properties” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ServerControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”Nintex.Reporting.UI.WSS.ServerControls.Contracts” TypeName=”*” Safe=”True” />
<SafeControl Assembly=”Nintex.Reporting.UI.WSS.ServerControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=df8bc1a8465564d9″ Namespace=”" TypeName=”*” Safe=”True” />
……..And must exist in the web.config files of each site for each zone of the web application.
So, I’ve had a rough week. Automating a whole bunch of stuff for several client deployments.
Back Story
This function library I have been working started it’s testing phase on Friday… The functions had been created post farm provisioning and all worked sweet. So we decided to do the full monty and build the farm completely (post-binary install). So we kicked off the script (on a single server farm) and waited, everything ran (including Enterprise search) up until Excel services went to install. Bam, lots of red and the error message the boiled down to
cmdlet ‘Get-SPExcelServiceApplication’ not recognized
So, we’re baffled. We knew this had previously worked. Why not now? To confirm this, we execute the function on it’s own in a separate PowerShell instance. Boom it worked… Ok, so it does work I thought.. We rolled back our VM and tried it again, however this time I commented out the function executing before the excel function. Ran the script, again same error “cmdlet ‘Get-SPExcelServiceApplication’ not recognized”… A little frustrated I commented out the excel function, rolled back the VM and started again, again.. This time we got past the function with no problem, managed to install Word Automation Services, Performance Point Service, and just when I thought we were out of the woods; “cmdlet ‘Get-SPVisioServiceApplication’ not recognized”.. AHHHHhGHHG. Running the function in a separate window proved that it worked fine. So, after storming around having a couple drinks and taking some time out, I embarked on the mission of stepping through the script. Long story short, I got the Excel services and everything worked sweet. I then ran Get-Help Get-SPExcelServiceApplication in the PowerShell console of PowerGUI script editor and funnily enough, the command was not recognized. I opened a PowerShell instance, loaded the cmdlets and executed the same command, and funnily enough it found it. “A-HA”, I exclaimed. I know what it is. I went back and edited my Farm Provisioning function to re-add the PowerShell cmdlets, rolled back the VM, uncommented anything and ran the script. BOOOOM, it worked. Issue It seems that something like 95% of cmdlets seem to be available and recognized pre-farm creation. However, if you do not re-load your cmdlets after farm creation not all cmdlets are recognized. So far I have found this to be an issue with:
- Excel Services
- Visio Services
Resolution
After you create/join your farm. Reload your SharePoint cmdlets. This will save you lots of time/pain/heartache
… So if you’ve previously loaded your cmdlets the following code should be sufficient (add this to your own function or whatever):
Remove-PSSnapinMicrosoft.SharePoint.PowerShell`
-ErrorAction SilentlyContinueAdd-PSSnapin Microsoft.SharePoint.PowerShell`
-ErrorAction SilentlyContinue
So…. my old blog got hacked or spam attacked… And after fighting to save it, I gave up and deleted it… So now, I introduce, Andy’s Blog 2.0… I’ve saved my blog posts and will update them as soon as I can…
