Powershell – Install-SPSolution : This solution contains no resources scoped for a Web appli cation and cannot be deployed to a particular Web application

Kevin,

If I'm properly understanding your order of operations, I have one big question: are you restoring content databases but leaving the farm configuration database (and other databases, like SSP databases) intact during your restore? If the answer is "yes," then I suspect that SharePoint is throwing a fit because your configuration database still maintains a reference to v2 of your workflow. Here's what I suspect might be happening.

When you install a Feature to your SharePoint farm, the SPFarm.FeatureDefinitions collection (which is maintained in the farm configuration database) is updated to reflect what you added. This includes all the standard information you'd expect your Feature to contain: name, scope, ID, version, etc. It also maintains FeatureReceiver assembly information and a RootDirectory value, amongst other things. The RootDirectory property points to the folder in the 12-hive where the Feature manifest is located for the Feature.

When you add your v2 workflow Feature to the farm and activate it, the configuration database is updated. Even if you restore a pre-v2 workflow version of your content database, the farm is still going to be looking for v2 of your workflow because of the Feature association that is maintained at the configuration database level. If the v2 Feature folder still exists in the 12-hive and its manifest points to the v2 assembly in the GAC, it's easy to see where problems might arise.

At the same time, if your workflow Feature leverages a FeatureReceiver, that information is also stored (in the configuration database) in the ReceiverAssembly property of the FeatureDefinitions collection when the Feature has been installed.

If I'm mistaken and you're actually restoring your entire farm in-place (including configuration database), then what I've written doesn't apply. In that case, I would be left scratching my head a bit, too. :-)

I hope this helps!

I have seen very similar things happen when the ASP .NET impersonation settings are incorrect or have changed. The same scenario of "unless we run it on the server itself" points me to believe this may be the issue. Have you check the impersonation settings?