For a client solution I would use the Search REST API. The grouping has to be done on the client, it depends on how you configure your Managed Properties. The trick with People is to pass the correct Result Source ID in the query:
If fetching of item["ID"] instead of 'Title' works AND If you are using the SPQuery object. Then, include the columns that you want to fetch in the ViewFields property of SPQuery. This will resolve your issue.
I like Arsalan's answer, however MS is pushing people to avoid server side development, which includes Timer Jobs. As timer jobs run on the SharePoint server, a poorly written timer job can have a negative impact on the farm. Also, if a customer ever moves to Office 365, any custom timer jobs will have to be re-written.
An app run by the windows task ...
Here are few more differences between Timer Job and Windows Task schedulers:
Timer jobs require downtime to deploy.
Control via Central Admin.
Schedule of Timer Job will be backed up and restore in your normal process of SharePoint backup and restore.
Can be deployed using standard WSP solution.
Custom Timer Jobs provides the power to specify ...
Your scope of timer job is already at Web Application.
So what you have to do is, just make sure the feature should not be auto activated. You just disable the setting Automatically Activate.
So, just activate the feature on the Web Application you need to use.
A job does not have a thing such as a "scope". They have a lock (Job, Database and None) but that's something else.
So you're actually talking about the scope of the feature that deploys (through a feature event receiver).
Several things have to be noted:
Web application-scoped features are (by default) automatically activated when the WSP is deployed. ...
In order to execute RunNow method Farm Administrator rights are required. When you use RunWithElevatedPrivileges method, the code runs in the context of application pool account, which usually does not have farm admin rights (and it should not have it according to best practices)
So the solution is to run the code in context of some user that does have farm ...
Schedule a PowerShell script task schedule which goes through all the user profiles and writes to SharePoint List. You can also use PowerShell to perform ordering and sorting on the objects returned.
Note: the script below loops through all the user profiles, you can complete it by writing it your SharePoint List + Scheduling it as a Task.
One thing to remember when you are using site-scoped or site collection–scoped Features to install the timer jobs: The account that does the scheduling must have write permissions to the configuration database of the server farm. Usually, the identity of the application pool that is hosting the SharePoint site does not have permissions on the configuration ...
Benefits of Sharepoint Timer jobs over Windows Task Scheduler are :
Single point of failure : Windows Task Scheduler need to be configured on all the web servers. If you configure to run the job on 1 server only, and this server crashes, job will not work at all.
Status Reporting : Windows Task Scheduler doesn't have any reporting on when was the last time ...
Our operations team says when you have a task that is really related to SharePoint, maybe list items iteration, logging etc etc. you should use Timer Job..
But if you have tasks not related to SharePoint at all or directly.. Than use Task Scheduler..
we had an External Content Type made from SQL Server Database and the
user wanted to iterate ...
Considering Folder is at one level, and not folders inside folders. This code will work.
Also make sure, in list setting -> Advance Settings -> Make "New Folder" command available? is set to Yes.
public SPFolder GetOrCreateFolder(ref SPWeb web, SPList sourceList, string listName, string folderName)
SPFolder folder = null;
No, no timer jobs in SPO due to being FTC. That said, in certain scenarios there are alternatives, such as Azure Web Jobs, Webhooks, and so forth. Here's an older example of building an Azure Web Job as a replacement for a timer job.
SharePoint Timer Jobs running as Windows Azure Web Jobs
Others might have newer examples that are more relevant to today's ...
I think you have only deployed the solution (wsp) file of the timer job. You will also need to activate the feature for your timer job.
Go to the Site collection features of your Web-application and Activate your timer job feature from there.
This should start showing your timer job in the list of Job Definitions in the Central Administration.
I hope this ...
Could you debug the timer job locally in your dev enviornment. Remember to restart the timer service in your dev enviornment before you attach to the owstimer service from Visual Studio.
If you can successfully attach and debug locally ensure the url to the site and list are the same in your UAT/PROD enviornment.
Hope this helps
I have been developing timer job for quiet a while now and always created myself a Event log specially for timer job to log when it started or stopped and also if there is any error came up while execution.
I use this code to write messages to event log you can also add code to send an email to a specific user in case of error if you would like to,
You could try stroring the site url in timerjob properties collection and retrieve it in the Execute method of timerjob
In the feature activated event store the siteUrl
string key = "mySiteUrl";
string value = web.Url;
TimerJob tmrJob = new TimerJob(webApp);
//remove the key if already exists
bool isKeyExists = tmrJob.Properties.ContainsKey(key);
You should get site url as below.
string siteUrl = this.Properties["SiteURL"].ToString();
and use below code to get current web in timerjob.
using (SPSite site = new SPSite(siteUrl))
using (SPWeb CurrentWeb = site.OpenWeb())
// Write code here
This post have details. The info extract from the Post
Notice how the schedule is set for the timer job. The
SPMinuteSchedule.BeginSecond property and the
SPMinuteSchedule.EndSecond property specify a start window of
execution. The SharePoint Timer service starts the timer job at a
random time between the BeginSecond property and the EndSecond
Yes you should be able to deploy the timer job using the old WSP and it should work properly for sites in SP 2010 mode. However, as is expected if you need it in SP 2013 sites then you will have to update the WSP to be in conformance with SP 2013.
For every web application you can do the following:
Get your timer job definition (SPJobDefinition) from SPWebApplication.JobDefinitions
Get the guid:
string jobDefID = SPJobDefinition.Id.ToString();
Add the guid in the query string
As a TimerJob has to be associated with either a WebApplication or Service, the most scope of the feature would be common would be either WebApplication or Farm.
But as always with scoping features the main concern should be at what scope does it make sense for be able to enable/disable this functionality from a business perspective. This might mean that ...
You can create a "remote event receiver", where O365 calls your service that is hosted on your machine when an event occurs. So, if an announcement is added to a list, for example, O365 would call a WCF service that you registered for that event. That WCF service could be running on an IIS box in your own data center. The only difficulty with this is that MS ...
As far as I know you cannot schedule it to run every two weeks. You do have however, (at least) two alternatives:
When the timer job runs check the week number of the current date and run only on even/odd weeks, skip and do nothing otherwise
Add two instances of the timer job with a monthly schedule, one of which would run the 1st and one the 14th of the ...
Make sure the following:
Provide the Feature Guid rather than its name from feature.xml file
You have provided the correct URL.
Don't surround the feature with double quotation " as shown below
Enable-SPFeature –Identity f9ce720e-6473-47c2-142k-9d94582369e –url $Url
I suggest you to use google...
Basically make a TimerJob in Visualstudio, write your code there and let this job run once a day.
check if an item hasn't been modified since 365 days.
move to other list
When a timer job instance is created, it is persisted to the farm configuration database. Accessing this database for write purposes is a privileged operation; as a rule of thumb, only the farm service account (that is, the account under which OWSTIMER.EXE executes) or accounts that explicitly have the rights. So application pool account wouldn't work, as ...