I'm trying to deploy a SharePoint 2010 solution to our production environment, after starting the deployment process the deployment status keeps saying "Deploying".
At first I thought that the Timer jobs cache was clogging up, but after cleaning the cache and resetting the jobs counter the deployment still won't finish. I also double checked if the SharePoint Timer and Administration were down, but this wasn't the case.
I also reviewed the ULS logs but they don't seem to be holding any serious errors or problems.
Does anyone have a suggestion that might come in handy?
Do you have a different servers on WHich you are deploying your wsp ?
If yes, then check the timezone of that server.
Have a look at this link it may help you
ANother this you can try is :
Did you try the steps described above?
1) Run stsadm -o execadmsvcjobs on your CA server.
2) Run stsadm -o execadmsvcjobs on all the farm members that have stsadm.
4)Restart the Timer Service on all farm members.
5)If still not resolved, then try deleting the timer job that is causing the problem.
Related
I'm helpless... Since couple of weeks looking for a solution.
Some TimerJobs (system jobs and custom) in my migrated SharePoint farm won't be executed. Migrated from 2010, over 2013 to 2016.
Last run time is: N/A or via powershell 01.01.0001 00:00:00
I spend a lot of time to look for a solution, and already did the following:
Restarted timer service
Restarted all servers
iis reset
Cleared SharePoint configuration cache
Tried "Start-SPAdminJob -verbose", but it fails (also when I do "net stop SPAdminV4 / net start SPAdminV4")
Started SharePoint Configuration Wizard
Redployed the wsp and reactivated (for a custom timer job)
Checked service accounts
I'm also wondering about that some of them have also no web application associated. Is this normal?
Web application: N/A
Is there someone with an idea?
Thanks for any help.
try shell
$server=Get-SPServer -Identity "name"
$ts = $server.ServiceInstances | ? { $_.GetType().Name -like "*sptimerservice*" } | Select -First 1
$ts.AllowContentDatabaseJobs = $true
$ts.AllowServiceJobs = $true
$ts.Update()
About the custom jobs it may be related to missing deployment steps, like WSPs installation (ex. Compatibility Level or something else) or even feature activation to 'attach' it to a web application, service instance or server. Remembering that we have a sort of 'scopes' that must be checked during time job development. This is not new, but an excellent material:
https://www.red-gate.com/simple-talk/dotnet/.net-tools/a-complete-guide-to-writing-timer-jobs-in-sharepoint-2010/
About the system (native) jobs, I recommend you to give us an example, so we may check the SharePoint 2016 TimerJobs reference list:
https://learn.microsoft.com/en-us/sharepoint/technical-reference/timer-job-reference-for-sharepoint-server-2016
After checking those requirements, you have a way to start some stucked jobs (or force them to run immediately), using the following commands on your SharePoint shell:
net stop spadminv4
stsadm -o execadmsvcjobs
net start spadminv4
Reference: https://technet.microsoft.com/pt-br/library/cc262783(v=office.12).aspx
And one last shot - check if you have pending administrative changes, like running PSConfig. Central Admin Health Analyzer is your best friend ;)
Bonus: about custom timer jobs, please always be sure that some features may require the Microsoft SharePoint Foundation Web Application service started on CA Server, to make custom timer jobs available under Central Admin:
https://learn.microsoft.com/en-us/SharePoint/administration/service-deployment-planning
"This service provides web server functionality. It is started by default on web servers. Custom features scoped to web applications may not display in Central Administration as intended if this service is not started on the server running Central Administration and if the feature cannot be deployed globally."
I have developed a custom timer job for SharePoint 2013 in visual studio 2012 which sends email notifications. The issue is that it works fine on development server.
I have followed the following steps to debug it on the development server 1.) Deploy the timer job on respective site. 2.) Restart the timer service in services.msc 3.) Then is do attach to process OWSTIMER in visual studio. 4.) And finally Go to SharePoint 2013 Central administration->Monitoring->Review Job Definition and click on the respective timer job and say run now.
After doing this the breakpoint is hit in visual studio at the Execute() method. So in the development server it is running.
Now on the production server I cannot debug using visual studio so I have deployed the packaged solution(.wsp).
I can see the feature is activated in Site Collection Administration-> Site Collection Features.
Now on the production server I follow the following steps 1.)Restart the timer service in services.msc 2.)And finally Go to SharePoint 2013 Central administration->Monitoring->Review Job
Further to test whether the timer job is working on production server or not I had used PortalLog.LogString("Flow test1"); at the start of the Execute() method. Now this runs on the development server and I see the message in the SharePoint logs but on the production server I can't see "Flow Test1" in the logs after I click Run Now in central admin.
Can anyone suggest what is the issue and a possible solution?
It seems to me that there are two issues:
You should use other way for logging LoggingService should be preferred way. Use WriteEvent to write to EventLog or WriteTrace to write to ULS log.
Running job. Be sure that Owstimer.exe service on all web servers are restarted (can be done by this powershell script). I expect that you have correctly scheduled your job either in your powershell script or in your feature receiver.
Here are a few things to try:
Go to Central Administration and run the timer job from there. Then go to the job history page and check whether it finished successfully or not. If there was an error, you should see the error message from there. That will give you a clue on whats happening.
As Mazin said, restart the timer service in all servers. After deployment, the DLLs are cached by the process and you don't see your changes reflected.
Browse the SharePoint logs and search for an exception or error. You can narrow your search by selecting the timeframe on which your job ran. You can use the following PS script:
Get-SPLogEvent -StartTime "02/02/2014 11:00" -EndTime "02/02/2014 13:00" | Out-GridView
As stated here it seems your job assembly is not deployed in the GAC. Verify that the assembly is present there.
I've got a WF feature which I've been deploying into my development/test environment fairly frequently, and as such have run into an issue where the assembly seems to be cached by the SharePoint Timer service (SPTimerV3), and then an out-of-date version is used after the workflow rehydrates following a Delay Activity.
To fix this, I've tried adding a "NET STOP SPTimerV3" and "NET START SPTimerV3" to my batch file after the STSADM commands to install the .WSP . It works to restart the timer service, and I no longer have the caching problem, however restarting the timer this way seems to kill my SP App Pools in IIS fairly regularly.
Has anyone found a good way to restart the timer in a WSP deployment batch file without adverse affects? Do I need to restart another dependent service, or restart the App Pools each time as well?
you need to restart IIS as well. IISRESET /noforce should do the trick.
I'm using a website which interacts with SQL Server Agent in order to schedule the automatic processing and emailing of reports. I recently noticed that when the AppPool recyles, that i'm not getting reports afterwards - until someone logs into the website again. It's possible for the website not to get hit for hours/days, during which all the scheduled tasks are lost.
I'd like to set up a windows task to either run periodically or trigger off the AppPool recycle event. But I'm not sure what the task should be. I had one suggestion to set up a Windows task to exercise a .js script that would hit the website, but this only works with Windows Authentication (which isn't being used):
var xmlhttp = new ActiveXObject("MSXML2.XMLHTTP");
xmlhttp.open("POST", "http://localhost/website/default.aspx", false);
xmlhttp.send();
Looking for some suggestions on how to "wake up" a website after an IIS AppPool recycle.
Thanks.
ab.
Why not run gnu wget from a scheduled task:
wget -O - http://mysite.com/default.aspx
I ran across this today which seems like it might help you out. It's the IIS Warm-up module. Depends on whether you can convince the your customer to install it, although it is an official IIS module, so hopefully it's no problem.
Deploying to sharepoint using the object model or STSADM commands sometimes results in one or more packages being in the "error" state in the web control, a redeploy instantly fixes this, usually, even stranger, if i create two apps one which adds and one which deploys then i get no problems, but putting a delay between a single program does not have a similar effect.
If i run the deploy twice for programs which did not deploy successfully it works fine, as long as I do not try to do it programatically in which case it makes no difference.
It is different files and sometimes is none.
I do use stsadm -execadmsvcjobs between add and deploy and even between two of the deploy bunches.
(i'm deploying around 10 wsp files programatically)
Does anyone have any ideas on why this happens? or how to solve it, as when i get to implementations it causes problems.
The problem lies in the fact that sharepoint will perform app pool recycles and / or full iisresets, as well restarts of the SharePoint Timer Service (altough not completely sure about that though). When you try to actually deploy the just installed package sharepoint is still busy getting up and running again, the timer job created to install / deploy is basically waiting for the central admin app pool to be fully running again.
The same thing happens (somewhat reproducably) while retracting a solution. Hit F5 a lot of times on the solution management page while the retract process is underway and if you refreshed fast enough it will hang and display "error" in red.
My solution was to create a WebRequest to at least the central admin (or just do a SPSite = new SPSite("centraladminurl")) in your deployment app or in powershell. Do this after every deploy action as well.
This SHOULD fix the timing issue (basically a kind of "race condition").