Changing hardware specs causes interal 500 errors, any ideas?
We signed up for a trial with the SharePoint 2013 farm. The idea is that we can use it for customer demos, conference presentations, and generally playing around with. It works just fine when created out of the box, but it's a bit slow due to the 8GB limit. Because the trial comes with an additional 8GB, we tried changing the SQL Server to 4GB and the SharePoint Server to 11GB but that causes any site collections to break and display an internal error 500 when trying to view the page.
Has anyone run into this before? Any idea what might be causing it, and how to fix it?
Comments
5 comments
I fixed this so if anyone comes across something similar can give it a try (I work with Frode and was able to recreate the problem on another environment I created). For some reason if you modify the the RAM settings for the SharePoint RTM template it breaks the SecurityTokenService. I found the problem to be with the Application Pool itself. To correct the issue, I modified the Identity of the application pool so that it pointed to AD2012.loc\Administrator and re-entered the password. The problem we had occurring was due to a corruption of the connection or something like that, so all connections to the site were rejected because the security token was not available to SharePoint.
Hope this helps others.
Dave
Just as a side note, this problem does not occur if you use the single server SharePoint 2013 environment. The 3 server (AD, SQL, SP) environment is where we were having the issues.
David, this is an awesome find, thanks for posting it! We put a fix in place on that Showcase environment and this should stick now.
Unfortunately, this problem still happens with the fixed environment, and can be triggered by simply running Sharepoint Products Configuration Wizard without making any changes. There is a 500 error on any request and the SecurityTokenServiceApplicationPool stops. To fix it, re-enter the password of the AD2012\Administrator Managed Account in Central Admin and restart that application pool.
Hey Martin thanks for the info. Yep - there are some random problems with that environment that date back to it's creation - all centered around the admin accounts. I'm afraid they're more difficult to fix and are related to how Windows actually handles those accounts and the associated services.
What we've seen do the trick is setting changing the password for the domain SPFarm account and setting it as the login for those services. Making sure the new password is set for those services as well should keep the fix in place.
Please sign in to leave a comment.