Although I am a great fan of using PowerShell for performing lots of tasks in SharePoint quickly, but there are certain areas where PowerShell may not be the optimum solution.
One of which is Custom Timer Jobs in SharePoint. Although you can schedule a PowerShell script by a task scheduler in windows to run some process on a regular interval but creating a TimerJob will give you long term benefits and manageability. Next, I will try to compare the two approaches, Your comments are most welcome:
| Custom Timer Job | PowerShell | |
| Configuration | Timer Jobs have Property Bags. This will give you power to store configuration data along with specific timer job. To modify the data, a custom application page can be deployed to Central Admin UI as a link. In this way, an Admin can manage the job easily through web interface without the need of going to a Shared Folder. |
PowerShell script will need either input parameters or a custom config file (preferably XML) for configuration. To update the configuration data, admin needs to access the Shared Folder or should upload the updated config file through FTP or some other way, which in my opinion is a cumbersome process |
| User Experience | Having a central admin page allows gives a professional and managed user experience with proper branding. | User Experience is standard console without any branding. |
| Training | By using standard SharePoint theming and controls, It will be easier for any SharePoint user to quickly learn the usage and management of Timer Job. Description below each configuration item will reduce/remove the need of separate help document. | A separate help documentation will be needed to make sure user remembers the usage of parameters. OR Parameter usage will need to be provided with some standard help parameter e.g. /? Or -help |
| Deployment/Installation | A standard WSP solution can be deployed with everything packaged in it without the need of copying multiple dependency files. | No standard built in deployment method for PowerShell scripts so administrator has to come up its own way of deployment management. |
| Retraction/Uninstallation | Standard WSP retraction with guaranteed clean of everything initially deployed with the solution. | Administrator needs to make sure that every dependency has been cleared. |
| Application Context | Timer Job has the context of Web Application which means it can have a logic to behave differently on per application basis, if needed. | By default, PowerShell script can not assume an application context. It needs to create that context, if needed. |
| Security/Execution Account | Timer Jobs always run under specified SharePoint account which gives them specific level of access as per Administrator needs. | PowerShell script can also run under a specific account but you need to specify it in Task Scheduler. This mean another administration task for an administrator. |
| Backup/Restore | Schedule of Timer Job will be backed up and restore in your normal process of SharePoint backup and restore. | Administrator needs to manually manage backup and restore of Schedule Tasks and their PowerShell scripts. |
| Multiple Instances | Custom Timer Jobs provides the power to specify Job LockTypes (i.e. SPJobLockTypes) which guarantees that multiple instances of same job will never execute at the same point in time. | No multiple instance guarantee. Administrator needs to make sure that no two instances are running at the same time. |
| Load Balancing | To reduce the load on SharePoint Servers, administrator can specify to run the job on all servers, in one particular server, or only the front end servers. | Administrator needs to manually schedule a script on some specific server. |
| Execution Time Window | In a farm environment, where a job is setup to run on all server, SharePoint automatically selects the server and a time window of few minutes to start the job as per schedule. It greatly improves the execution reliability. | No execution time window management. |
| Development | Complex, as it needs Visual Studio and C#/VB.Net and development skills | Easy, as no special development tool is needed. A notepad will be enough. |
| Debugging | Complex but more powerful as it needs the knowledge of how to attach the debugger to the running process. | Easy but less powerful as you have to print the messages for debugging. |
