As much as anything, this is a reminder for me. We had a customer who were trying to run a PowerShell script that, ultimately, relied on an assembly that was contained in a WSP we’d written. The script wouldn’t work, however, and it transpired that the WSP had not been deployed to the server that they were running the script on.

That server was an application server supporting Central Admin, and because it was central admin they’d turned off the “SharePoint Foundation Web Application“. It wasn’t a web front end, so it should need it. The solution was only deployed to a single, non central admin, web app. Therefore, SharePoint hadn’t replicated the WSP to the server they were using. Easy when you’ve figured it out, but not obvious otherwise.

Why did the PowerShell script need the assembly? Well, that’s trickier. I think it’s because it was causing an event handler to fire by adding items to the list. The event handler’s code was in our assembly, and I think that the thread running the PowerShell script was what was trying to run that event handler (not the application pool on a web front end). As the assembly wasn’t in the GAC, well, it couldn’t run it.

Solutions?

Deploy the WSP to the Central Admin App Pool. The guys I was with didn’t think their infrastructure team would appreciate that.

Run the PowerShell script on the Web Front End instead. The easiest solution – but the guys I was with didn’t have access to the WFEs.

Start the SharePoint Foundation Web Application service on the Central Admin server. This would cause the WSP to be copied onto the server. However, this can take some time, and we had problems with the service sticking on ‘Starting’. We left it overnight, but it was still stuck. In the end we used STSADM to start the service:

stsadm -o provisionservice -action start -servicetype spwebservice

Once started, the PowerShell script ran just fine.