I get a "500 Internal Server Error" on execution of "context.executequery" when sharepoint is not used for one day or I restart sharepoint front-end application pool. Just once I log in to the sharepoint front-end (with any user) and everything works as before.
I have just checked that all of server services on Central Administration and that all application pools on IIS are running.
The code I execute is this:
...
_context.Credentials = new NetworkCredential(__sharepointUserName, __sharepointPass, __sharepointDomain); ;
Web web = _context.Web;
_context.Load(web.Lists);
_context.ExecuteQuery(); // Here throws an exception
...
Thank you!
I solved the problem warming-up SP with this script (in the page you can find all necessary information on how to install and execute it).
Seems to be a problem generated by IIS that recycles applications pools every night to keep clean memory space. So, When the recycling occurs during mid night (or when you do manual recycling/IISReset), the first user who logged-in to sharepoint "forces" the SP warm-up.
Read more: https://www.sharepointdiary.com/2014/08/sharepoint-2013-warmup-script-powershell.html#ixzz5v4P39RH5
Related
I am facing a problem with logging into TFS. I get the following error:
Exception Message: TF246017: Team Foundation Server could not connect
to the database. Verify that the server that is hosting the database
is operational, and that network problems are not blocking
communication with the server. (type SoapException)SoapException
Details:
Hi the below steps worked for me.
Select Application Tier in the TFS Administration Console.
In the Application Tier Summary which contains the Service Account details.
Click Reapply Account.
I know this is old, but here was my situation:
We have 11 collections on our instance, 2 were failing with this error, showing me it wasn't an access / connection issue. Checking Event Viewer (as #Andy Li-MSFT suggests) showed it was
A timeout occurred while waiting for memory resources to execute the query in resource pool 'default' (2). Rerun the query.
Checking task manager showed the culprit - elastic search was using well over 2GB of memory. I killed the service, the collections applied the patch quickly without issue.
Looks like I need to ask our server admins to give us a bit more memory....
Please check below thing to narrow down the issue:
Make sure you are the member of the Administration Console Users.
Otherwise you cannot access the Admin Console.
Make sure the SQL Server is stated and available, and the network
connectivity is OK.
Check the Service Account, make sure the Service Account has been added in
SQL Server.
You can also refer to the solution in below link to fix the issue:
https://www.ganshani.com/alm/tfs/visual%20studio/solved-tf246017-team-foundation-server-could-not-connect-to-the-database/
If above solution can not resolve the problem, please check the Event log. The Windows Event Log is a good candidate where to look for the potential cause.
For me I've solved the issue by changing the recovery mode Simple -> Full in the database.
Please refer to: https://www.mssqltips.com/sqlservertutorial/3/sql-server-full-recovery-model/
I'm writing an ASP.NET Web API application hosted on IIS7 (no special configuration).
My problem is that for each first request (on a new machine/new browser/after a while...) there is a long delay - even on requests that return constants!
I've read about "warming up" scripts but it's not the issue here. It seems like the web server is trying to create a session and it takes very long time. Any suggestions?
EDIT
I think the delay is caused by worker-process creation for each new session. Now the question is why is it so slow, and why doesn't the web server reuse living worker-processes to serve requests?
I have configured the application pool to limit worker processes to 5 with no timeout (set to 0). This caused the first five sessions to be slow on first requests (which I can live with) and now the worker processes are alive. But surprisingly, from time to time, the request is slow again!
If you are using Windows Server 2008 R2 you could configure the Auto-Start feature on the Application Pool. Also in the properties of the application pool you should disable it from being recycled at regular intervals. Bear in mind though that while this will limit the slowness, the application pool could still be recycled by IIS. With the Auto-Start feature it will be loaded again automatically in memory, but the code in your Application_Start will be executed on the next request. So you could still observe some slowness.
Another cause can be https. Our site can run with and without https. The delay at the first page (5 to 15 seconds) occurs only with using https. This post explains the issue with https and the fix:
https issue by the MCS team
When running in Visual Studio, my mvc3 app does not ask for any authentication. However, when I deployed to test server (Windows Server 2008 and IIS 7) I keep getting a prompt asking for UserName and Password. I supply the admin credentials for the server yet there is a failure. The strange thing is that the page is served but I keep getting the prompt. All the ajax calls however fail with a 401 Unauthorized error.
I tried different types of authentication but the results are the same. Even with anonymous authentication only I get a prompt for user name and password.
I tried changing the pipeline from Managed to Classic but then MVC would not work and I get 404 error. This is my first mvc app and I did not expect such issues in deployment.
Any clues how to get this to work?
==Edit begin===
This is what I suspect might be causing the issue. On the server the site is bound to test.xyz.com. Also, there is Sql Server Reporting Services Installed. My application is tries to query the url test.xyz.com/Reports but I think this is bound to SSRS. When I stop the SSRS service I get a service unavailable 503 error. Otherwise I get a authentication window.
I am trying to find out how can I remove the particular SSRS binding so that test.xyz.com/Reports points to my Reports Controller
==Edit end====
You can also use Reporting Services Configuration Manager to specify the port and url that Reporting Services uses on the server.
By default SQL Server Reporting Services uses the following urls:
http://<server name>/ReportServer // web service url
http://<server name>/reports // reports manager url
http://msdn.microsoft.com/en-us/library/ms159261(v=sql.105).aspx
Things to check:
Does your web application accessing any resources? If so, does the IIs worker process account have permission to those?
Have you set the Web Site Authentication to Enable anonymous access?
Do you by any chance doing impersonation (either in web.config of programmatically? If so, does the end user account have the proper permissions to any eventual back end resources?
I changed my controller from Reports to MyReports and this resolved the conflict.
I'm having a problem with a MVC (1.0) app that I can't figure out at all. There's two versions of the site (live and UAT) hosted on the same server. For each version of the site, the same code is shared by multiple organisations who each have their own database (MSSQL2005) and a separate web site in IIS (7.5) (pointed to the same code).
The UAT site has an update to the code and the database that is waiting to be deployed to the live site.
One of the customers ("customer A") is getting an error "104: Connection reset by peer" when they try to log in to the UAT site. They can see the login page but when they submit their login details the connection seems to be timing out (the requests seem to take ~130s to complete).
Customer A can log in fine to the live site. The other customers don't have a problem logging into the UAT site or the live site. If I try to log in as customer A, using their login details, it all works fine from within our network, and also from outside our network.
Customer A seems to be using squid as a proxy.
I can't think what the problem could be, and I've run out of ideas of things to test. The fact that I can log in as the customer fine and other customers don't have any issues seems to eliminate the code and database as problems.
What other things could I do to try and isolate the problem?
By dumping out the request data I was able to work out that something (I'm guessing the proxy) was removing the form values from the request. This obviously meant the app didn't work properly.
However, it seems whatever was removing the form data was leaving content-length unchanged, which would explain why the client was timing out waiting for more data and the server thought it was finished.
By using https instead of http (which we were going to do anyway), the request tampering seem to have stopped.
I am using System.DirectoryServices.AccountManagement to find the logged-in user's AD entry. It is working great in the VS2008 WebDev server on developers machines.
But when we installed the code on the development server (windows server 2008), we get an access error.
Both the developer's machine and the development server are members of the same domain.
We have Impersonation turned on, so we are connecting to AD with the same user credentials.
What are we missing here? Why is it working on the developer's machine, but not the development server?
The actual exception that we were receiving was "An operations error occurred".
After some research, I found the following link: http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/c314650a-ff5e-49e6-8f53-9a7cca17e806
In it one user describes the solution to the problem:
I have seen this error and it is related to the fact that when using NTLM authentication and impersonation set to true in web.config, IIS cannot use the authenticated token against another server since it is a "secondary token".
The solution to my issue was to wrap my Active Directory code with:
using( HostingEnvironment.Impersonate() )
{
//Active Directory search goes here.
}
This makes the call to AD with the identity of the application pool, and it did the trick in my case.
I was just looking around to fix the error System.DirectoryServices.DirectoryServicesCOMException
after using UserPrincipal.FindByIdentity
and the answer from mlsteeves was what i needed, impersonating the hostenvironnement on the production server!
So good call this was about delegation on server and your solution was perfect thanks alot!