Sharepoint solutions – stuck on retracting or deploying

I’m adding this here in the hope it may save someone a few hours of pain and hair-pulling. (i.e., what I’ve just been through.)

If you use solution management in Central Administration in SharePoint – you’ll be fairly used to the whole add-spsolution / install-spsolution / uninstall-spsolution / remove-spsolution stuff that you either run from Powershell or the GUI.

You will also be familiar with the fact that solution management depends on both the SharePoint Timer Service (SPTimerV4) but also the SharePoint Administration service. If either of those services are not running, you will not be able to deploy or retract any solutions. In normal operation, solutions will go in and out like a greased piglet, but, from time to time, things mysteriously stop working. (This is SharePoint after all.)

In the case where solutions will not retract – Central Administration may be report something like ‘Retracting (scheduled at xxx)’ – but then it just sits there. Forever. You can cancel the deployment job… but the little swine just will not move.

There is a fair bit of stuff out there on possible workarounds to this.

Most involve some or all of the following:

  1. Check the Admin service is running. (Duh.)
  2. Restart the Timer Service. (You could even consider clearing the timer cache.)
  3. Use stsadm -o enumdeployments to view what deployment jobs exist
  4. Use stsadm -o execadmsvcjobs to force the application jobs to go through (with some or no success)
  5. You could force remove and force install solutions (Remove-SPSolution and Install-SPSolution with -Force flag

And whilst these dodgy brute force methods may help (maybe your solution is just broken and this is required) it feels a little too filthy. Especially if, as in my case, you had more than one solution that would not retract. That’s not a broken solution, that’s a broken timer service or admin service.

Fortunately though, I recalled something I encountered recently which is where a SharePoint upgrade (e.g., service pack) can break the timer service. Well, not break it, so much, but leave it offline. The kicker with this issue is that actually the timer service for all intents and purposes appears to be online and working. But it’s not.

Anyway, point is, after checking the status of the timer service – and yes, it was offline – by bringing it back using the script – boom, deployment jobs started magically working again.

$farm = Get-SPFarm
$disabledTimers = $farm.TimerService.Instances | where {$_.Status -ne "Online"}
if ($disabledTimers -ne $null)
{
foreach ($timer in $disabledTimers)
{
Write-Host "Timer service instance on server " $timer.Server.Name " is not Online. Current status:" $timer.Status
Write-Host "Attempting to set the status of the service instance to online"
$timer.Status = [Microsoft.SharePoint.Administration.SPObjectStatus]::Online
$timer.Update()
}
}
else
{
Write-Host "All Timer Service Instances in the farm are online! No problems found"
}

Good luck!

1 Comment

  1. May You live 100 years ! That offline status that you told to Be checked was the solution for me after 2 days of tries !

Leave a Reply

Your email address will not be published.


*