This article is targeting SharePoint full trust developers who have (will) developed a custom service (SPService) for SharePoint.
Indeed, if you are building a product for SharePoint like we’re doing at Negotium (www.oceanik.com www.theattributesolution.com ) you probably built a custom service application within your solution.
If that’s the case your custom service application probably relies on a dedicated custom SharePoint service to run its code (it can be a service within IIS or a windows service).
Then comes a moment (feature activation, installation…) where you want to provision the service (at least for one of the machines).
If you call MyCustomSPServiceInstance.Provision() on the local server, no problem. But if you do the same for a remote server, you get a weird exception.
This is because the service instance doesn’t “want” to provision itself from a distant server by default.
If you take the time to think about it, it kind of makes sense, to startup a service you need to be local administrator and have a privileged execution context on the machine. This is not the case when the code executes remotely.
Instead of calling the provision method from the remote server, it’s better to start a timerjob to do it on the local machine. And you don’t even need to develop it, it already exists!
You only have to instantiate SPServiceInstanceJobDefinition give the spserviceinstance in parameter and a Boolean to provision or un-provision it.
Then just give it a schedule (one time) and update it.
This should save you some investigation time on that matter as it’s not very well documented on MSDN.
I’d like to thank Jordan from my team who spent most of the time investigating this issue and who allowed me to publish this post.