I have a newly configured SharePoint 2013 farm and my application pools continue to crash (stop). I have these accounts added into Local Policies and Domain Policies for "Log on as Batch" and "Log on as Service". The app pools in Windows Logs are coming back with errors about credentials being invalid. I've never changed the app pool account passwords and in AD, they're set to never expire. The accounts are not locked inside AD either. It takes about 30 minutes of inactivity on the servers for an IISReset /noforce to bring them up.
These app pool crashes happen a couple times a day and appear to be desyncing with active directory somehow. Changing the passwords to the unchanged password in IIS and PowerShell does not work because is claims the password is incorrect. Have anyone come across this and have any ideas?
Is it possible you are getting a false error? A common reason for application pool recycles is bad code in optimizations that doesn't clean up after itself.
Related
I have created an Azure VM for the purpose of testing a new installation process for my software. The VM is using Windows 10 Preview.
Yesterday I uploaded an ISO file which contained our software plus installers for SQL Server Express (various editions). (About 1.8 gb)
I ran our custom setup program which installs SQL express, restores a new user database, adds firewall exceptions etc. etc.
This morning I cannot RDP into that VM. The connection is made, but when I attempt to login, I am simply returned to the Windows Security Dialog, with the message "Your credentials did not work..."
I know I am typing the password correctly, I have double checked things like typos in the user name and password, Caps Lock is not on ;-) and so on.
This happened to a VM I had set up last week too, after a similar test and after attempting various options including resetting credentials using Powershell (found here) I accepted that I must have forgotten the password or done something wrong, so I started again.
Now the same things has happened I am wondering if that level of activity (uploading 1.8gb then running a setup which retrieved and installed .Net runtime 3.5) on an Azure VM that runs under an MSDN Premium subscription Azure account, caused the user account to be locked out for a period of time - have I hit some limit of uploads to that machine or activity or some other limit I'm not aware of?
I'm trying to connect the User Profile Service (UPS) to AD using an account with the proper permissions. When I click the Populate button, the AD forrest immediatly appears, but I cannot expand it. If I select the entire forest the process times out.
The error message on screen says it is a client machine time out. There are no entries in ULS or the server app or system logs.
I've tried upping the default 300 to 3600 in the web.config files which didn't help. I have the exact same setup in my test farm, which makes me wonder if the problem lies with the UPS.
Both UPS services are running, both FIMs are running
Problem solved! Turns out there is a local security policy for LDAP that was set to Negotiate and should have been off.
I've created an IIS administration tool designed to create new applications, assign them to a new AppPool, and add required folder ACLs for the identity associated with that AppPool. According to this article, Whenever a new Application Pool is created, the IIS management process creates a security identifier (SID) that represents the name of the Application Pool itself.
But that doesn't appear to be the case on my Windows 8 Pro machine (IIS8). The SID is only being created once an application associated with the AppPool starts. This is making the task of setting folder ACLs quite difficult, the application needs to start before the AppPool identity is created, but the application won't work unless the ACLs are set... chicken and the egg.
What's going on here? Is there a bug on my Win8 machine? Is this Win8 / IIS8 behaviour in general? I'm having no issues on Server 2008 R2 (IIS 7.5), where it does create the AppPool identity SID as soon as the AppPool is created in IIS.
I'm aware there is an indeterminate delay between the time the AppPool is created and the SID is created. This is generally less than a second. In this instance, the delay appears indefinite (several minutes later, the SID still does not exist).
It would seem that the SID is only created once the process is running. I have a related problem where the registry hive under HKEY_USERS completely disappears after a reboot. Tests indicate that the registry hive returns fully intact as soon as my web service starts (i.e. on first request) with the same SID and contents fully restored, so I guess that once you have obtained the SID for the first time you can use it for the same purposes even if it doesn't yet exist after a restart. Getting the security system to believe you havn't made a mistake with naming may still be an issue though.
I'm running Windows 7 SP 1 and have just turned on IIS 7. Just trying to access the default page it creates I get a 503 error, and the application pool stops. I look in the event log and I find the error:
Windows cannot copy file \?\C:\Users\Default\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm to location \?\C:\Users\TEMP.IIS APPPOOL.000\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm. This error may be caused by network problems or insufficient security rights.
DETAIL - Access is denied.
I tried making the TEMP.IIS APPPOOOL.000 folder available to everyone. I tried making Users available to everyone. No luck, it still dies with the same error.
What is happening here, and how can it be fixed?
It sounds like you're having the same problem as details in this IIS.NET forums thread. You didn't mention if you have x64 Windows 7 or not. Suspect that your development machine is misconfigured somehow; sounds like the uninstallation and reinstallation of IIS7 would help/fix.
Suggested courses of action:
Open IIS and its Application Pools. Open "DefaultAppPool" and any other Application Pools in use.
Click Advanced Settings for each of these. Ensure the "Load User Profile" is set to 'False'
Also ensure that the "Set Application Pool Defaults" has the Load User Profile set to False."
I encountered the same problem in my development environment (Windows 8.1). Instead of disabling the load user profile as suggested by P.Campbell, I went ahead and changed the permission of the sqm file to allow modify accesses for IUSR, IIS_IUSRS and Network Service. In my case, the sqm file was not able to show me the file owner in which I taken over with my user account.
Basically, my problem was solved by giving the correct permission for both source and destination files/folders.
Found the answer here - http://forums.iis.net/p/1180636/1992024.aspx
Open IIS Manager
Find the App Pool that is causing the problem
Open Advanced Properties
Change 'Load User Profile' to false
Fixed!
After struggling with all these Application Pool issues in IIs, I found the problem and the solution. This may help you.
Each application pool on each website in Microsoft's Internet Information Server creates its own user account and folder under the "c:\Users" directory when the pool is created and first run. Its actually a virtual user account and should be named for the Application Pool assigned to your web application in IIs. In most development environments, its the default website or "DefaultAppPool". It uses this temporary user account to run the pool. Each website should have a named user pool account. This User folder is used by the pool and ASP.NET for caching and writing of file resources and other things used by IIs, ASP.NET, and this virtual account.
In some setups people are not seeing this folder but a "TEMP" folder (like you have) when the IIs web site is accessed and using the pool.
If you instead see a "TEMP" folder in the Users folder you have a broken application pool account in IIs and in the Registry. The pool is creating the TEMP folder as a backup for this virtual account, which might not have the right security setup. I had this exact scenario.
To fix it go to the registry under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
See if you have a SID user account with the ".bak" extension for a DefaultAppPool user account. If so delete it and restart your PC. Test your website again, making sure its actually setup to use DefaulAppPool. It should now recreate the "DefaultAppPool" folder in Users, recreate the registry entry for DefaulAppPool user, and your error should go away.
You can delete the TEMP user folder at that point under the Users folder. (Keep in mind if your web app has been storing cached information critical to users of the website, some of that might have to be inserted into the new DefaultAppPool user folder. But for most of us, just delete it.)
I also found I had to add this kooky virtual application pool account to my local database so the worker process and app pool accnt could have the rights to grab data from SQL Server: Just go into SQL Server and under logins add "IIs AppPool\DefaultAppPool" and then assign it as a user to your databases.
(btw whomever dreamed up this virtual application pool account system is nuts....its way too complicated and convoluted to sort out)
After I did this, all my stack overflow errors went away in Visual Studio for my web application, all data connections fired perfectly, all write permission to the default User profile stored properly, and all the restarting and crashing of the Application Pool in IIs ended completely. :)
I opened Sharepoint 2010 Central Admin and as per normal, was prompted for my login details. As I did not know the details, I closed after a few guesses/changing the default account.
A few hours later, remembering the password, I try again but get a 503 Service Unavailable.
I check the app pools in IIS7 and see that the SharePoint Central Administration v4 app pool is off. I turn it on, close IIS7, but it turns off again. Its settings look good to me:
Enable 32-bit applications Off
Start Automatically True
Enabled True
However, the application event log tells me that the account I was using to access Central Admin, and used by this app pool, has now expired (it's a local account so I did not know this will happen). This also impacts all other services such as SQL Server etc. How can I change the account of the app pool, but also change all of the other service accounts?
The credentials used for the account [name] expired on 1/9/2010 1:33:39 PM, and need to be updated. If they are not updated, the system may stop working. The account is used by the following:
Farm Account
Microsoft SharePoint Foundation User Code Service
User Profile Synchronization Service
Web Analytics Data Processing Service
Security Token Service Application
Application Discovery and Load Balancer Service Application]
I assume updatefarmcredentials will fix this. I tried the following:
stsadm.exe -o updatefarmcredentials -username sysaccountname -password pwvaluehere -local
This results in a "command line error". What is the proper syntax?
You can also just change the current System Account password in AD or Computer Management, and mark it to not expire.
When it comes to the stsadm command, it is userlogin not username, unless that changed in 2010. (Source)