With the introduction of 'Task Sequences' in SMS (SCCM 2007) a chaining of MSI installations with reboots was made possible. A lot of people try to use task sequences beyond OS-deployments to work around the deficiencies of standard software distribution. In fact, the task sequences engine has a lot in common with the PackageShell service. But the capabilities of PackageShell are far beyond what you get from task sequences:

Control of user logon
Excellent support for installations while the user is logged off
  • Users can be logged off before installations
  • Users are kept from logging on before execution is completed
  • Progress of execution is made visible to end user
  • All windows of the native installation are visible
Use your favorite editor for development
The task sequence editor is a GUI that is more suited to the occasional browsing than for professional development of package routines. PackageShell scripts can be easily created and modified with any text editor.
No dependency on SCCM infrastructure
Packages using PackageShell offer a greater flexibility because
  • They can be easily created and tested off-site, without access to a live SCCM site. They can actually be tested without an SCCM client present.
  • They can be imported into SCCM on the fly by using the standard import function. This is ideal for the case where your packages are developed externally (outsourcing).
Flexible handling of reboots
A task sequence will reboot whenever it receives an exit code of 3010. PackageShell can fine tune this behavior.
Nesting
A PackageShell script can be nested and called by another PackageShell package. This is especially useful during operating system installations: The OSD task-sequence is able to 'call' other PackageShell scripts.