Deployment scenarios which are not possible by using SharePoint Solution mechanism

Question

I am a big fan of SharePoint Solution deployment mechanism but I was once asked is there any scenario which can not be deployed by just using SharePoint solution deployment mechanism or is only possible by manual deployment(copying files manually etc.)?

Can any body share his experience where he needs to do manual deployment (fully or partially)?

Note: I am not talking about deploying SharePoint itself.

Answer 1

Changes to FAST for SharePoint, many of which have to be executed through Powershell ON the fast server. Its possible there's an API for them, but that seems a whole lot more work and would require permissions for the SharePoint account to make changes to the FAST server configuration which I think is a big no no.

Answer 2

This is a great question Namwar. There are a lot of things I think. Some things I can think of:

• AuthorizedType Web.config entries (used to allow custom workflow actions)
• Entry for SPThemes.xml for a custom WSS 3.0 theme (unless you replace the entire file)
• Basically anything in the SSP..
  • Custom metadata properties for Search
  • Custom PWA properties/settings

Answer 3

Limitations are few as in the end you can trigger your own code using a FeatureReceiver. This code can then do whatever you like. However, take the following into account:

1. You may need to schedule your custom code on every server in the farm. This is perfectly possible using timer jobs, but.... (see option 2)
2. Timer jobs are executed by the SharePoint Timer Service, which does not necessarily have local administrator access, which may prevent your custom code from carrying out certain tasks.

If you are doing this in an environment you control then this is not necessarily a problem, but if you develop a commercial product for deployment on other people's servers then this is a major limitation.