Powershell, why did the development team decide to only support async executions?

Question

I've been getting into power shell recently. I am beyond impressed with it, and I think its perhaps the most exciting SharePoint tool yet. It is extremely versatile and it really does live up to its name. I was amazed to see it supports c# and CAML too.

Obviously it goes without saying that a lot of love, energy and time went into developing the new power shell. I'm sure anyone who works with SharePoint considerably knows the value of this tool.

I was surprised to learn that our old friend, Stsadm is now considered redundant. For many years I've been using Stsadm, and although it is a simple tool it does one thing very well. It knows how to wait.

When you tell Stsadm to execute a command, it knows instinctively that it should wait for the command to complete before returning control. In other words it executes synchronously.

Powershell, in all its glory, does not wait for commands to complete, as a result you need to take an estimation and add sleep commands where applicable.

Now I am sure the developers did not code it that way in error, but a part of me thinks this could be a bit of a blunder, so my question is why would they code power shell so that it executes commands async only?

Answer 1

Since you mention STSADM my guess is you have problems with solution provisioning. Eg. that Remove-SPSolution waits until Uninstall-SPSolution has fully retracted the job.

Check my answer to an earlier similar question here

Answer 2

Very few PowerShell commands, none AFAIK, are async. What you're experiencing is probably all related to PowerShell kicking off timer jobs, and most likely related to solution provisining as Anders says.

Answer 3

Install-SPSolution and Uninstall-SPSolution trigger administrative timer jobs using the SPAdminV4 service.

This service may not be running on all systems and the jobs need to be run manually.

From TechNet Start-SPAdminJob

Use the Start-SPAdminJob cmdlet to execute all administrative timer jobs immediately rather than waiting for the timer job to run.

When the service account for the SharePoint 2010 Administration service (SPAdminV4)) is disabled (necessary in some installations for security reasons), the Start-SPAdminJob cmdlet must be run on all computers to perform administrative task like provisioning.

In these situations the Uninstall-SPSolution and Install-SPSolution would either wait forever and hope that an admin remembers to run Start-SPAdminJob on the machines in the farm or exit immediately.

Rather than wait forever the Cmdlets exit immediately (and issue a warning that Start-SPAdminJob needs to be executed)

This gives any powershell script the opportunity to either run Start-SPAdminJob inline or choose to wait.

Also by moving the wait to the powershell script the script can select its own timeout. Of course this could have been achieved with a timeout parameter to the Cmdlet but what would the timeout mean if SPAdminV4 is not running?

In short it can be seen as more consistent to force the powershell script to take responsibilty for the timeouts/running of Start-SPAdminJob.