I am having some difficulty setting the permissions for the AppPoolIdentity correctly.
The error shown in the Failed Request Logs is:
ModuleName="IIS Web Core", Notification="BEGIN_REQUEST", HttpStatus="500", HttpReason="Internal Server Error", HttpSubStatus="0", ErrorCode="The I/O operation has been aborted because of either a thread exit or an application request.
(0x800703e3)", ConfigExceptionInfo=""
I believe this is a permissions issue because changing the AppPoolIdentity to LocalSystem for the Application Pool makes everything in the website work. When the AppPoolIdentity is set to ApplicationPoolIdentity the error shown above is what I receive. I have named the application pool identity using the following syntax:
IIS APPPOOL\<app_pool_name>
I have confirmed that:
I am using the correct app_pool_name when setting permissions. (Using check names when setting the permission works which means that Windows is finding the user.)
The wwwroot and the oracle client directory have permissions which allow the Application Pool identity to read and execute files.
Anonymous Authentication is enabled in IIS and is set to use the Application Pool Identity.
Do permissions need to be granted other directories that I have missed? Or is it some other problem that I am completely missing?
For some extra background I am using Windows Server 2008 R2 with IIS 7.5.
Thanks in advance!
EDIT:
I have done some tracing, thanks to the advice that Peter gave and found that I was missing some permissions. The permissions I was missing were:
Full Control to HKLM\SOFTWARE\Microsoft\SystemCertificates\
Full Control to
HKU{GUID}\Software\Policies\Microsoft\SystemCertificates\
Full Control to HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\
Read to HKLM\System\CurrentControlSet\services\eventlog\Security\
Full Control to C:\Windows\SysWOW64\config\systemprofile\AppData\
After modifying these permissions my application is now logging to the Windows Event Log with custom application errors. (Basically the custom application error is telling me that it was not able to establish a connection to the database.). Keep in mind if I run as LocalSystem and not the AppPoolIdentity user in IIS everything works. Using the Process Monitor again I found that the Oracle Client was logging to a sqlnet.log file. In this file it is showing:
Fatal NI connect error 12631, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=[DB IP ADDRESS])(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=[SERVICE NAME])(CID=(PROGRAM=C:\Windows\SysWOW64\inetsrv\w3wp.exe)(HOST=[WEB APPLICATION SERVER NAME])(USER=[APP POOL IDENTITY USER]))))
VERSION INFORMATION:
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
Windows NT TCP/IP NT Protocol Adapter for 32-bit Windows: Version 11.2.0.1.0 - Production
Time: 21-JUL-2015 16:28:00
Tracing not turned on.
Tns error struct:
ns main err code: 12631
TNS-12631: Username retrieval failed
ns secondary err code: 0
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
Any idea on why it is using the AppPoolIdentity as the user it is trying to connect with?
I have finally solved this issue.
In the EDIT made above I added the necessary permissions which solved issue number one.
In order to get this working I modified my SQLNET.ora file to look as the following:
# sqlnet.ora Network Configuration File: E:\Oracle_client\product\11.2.0.1\client_x32\network\admin\sqlnet.ora
# Generated by Oracle configuration tools.
#SQLNET.AUTHENTICATION_SERVICES= (NONE, NTS)
SQLNET.AUTHENTICATION_SERVICES= (NONE)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
Note that the original SQLNET.AUTHENTICATION_SERVICES is now set to NONE only.
(I believe this change did not take affect immediately, but after a couple of minutes it did. Restarting the machine might be overkill, but sufficient).
I had also switched the AppPoolIdentity to LocalService and then back to AppPoolIdentity. After doing this it worked, but I don't think switching the AppPoolIdentity back-and-forth had any influence on getting it to work.
Related
I have spent several days trying to get a "managed service account" set up on Windows Server 2012 for a .NET web app. Let's start with the error and work backwards.
I get the following events ever time I try to access a page on the web site where * is the name of my app pool:
Warning 5021 - The identity of application pool * is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request. If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.
Warning 5057 - Application pool * has been disabled. Windows Process Activation Service (WAS) did not create a worker process to serve the application pool because the application pool identity is invalid.
Error 5059 - Application pool * has been disabled. Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.
~~~
While standing up a new server, I came across what appears to be an awesome feature which I had not used before:
http://technet.microsoft.com/en-us/library/dd548356%28v=ws.10%29.aspx
Since I am standing up a new app with a new database, this seemed like the perfect opportunity to take this for a drive!
I eventually figured out how to create the managed service account with the following power shell commands on a domain controller:
import-module activedirectory
new-ADServiceAccount -SAMACCOUNTname "SERVICE_ACCT$"
add-adComputerServiceAccount -Identity SERVER_NAME SERVICE_ACCT$
In the same powershell window, I can list services accounts for a given server with this powershell command:
get-ADComputerServiceAccount SERVER_NAME
And my managed service account is there! All good so far ...
I then had to modify our central group policy to include my service account for "Log on as batch job" and "Log on as service". These were under Polices\Windows Settings\Security Settings\Local Policies\User Rights Assignment on our domain controller (these were not editable on the local server as these were being pushed down).
After the changes and a coffee break, the rights show up on my server!
So now I have (1) created a managed service account which has (2) been granted access to a specific server and on that specific server (3) the service account has log on as batch job/service rights. I also (4) gave both the app pool and service account modify access to the web site folder.
I verified the site works with the default AppPoolIdentity account.
And ... I still get the errors above (which I have had during this whole process). I have to be missing something, but I just can find anything else to try!
Regards,
Cooter
I had to put this on the shelf for a while, but was eventually able to get this working. The most helpful resource I found was the following YouTube on MSAs.
http://www.youtube.com/watch?v=VNCGSQPhLuM
To summarize, there are quite a few requirements and steps
Domain Requirements:
Domain Function Level - Windows Server 2008R2+
Run ADPrep/ForestPrep
Client Requirements:
Windows Server 2008R2+
.Net Framework 3.5
Active Directory Module for Windows PowerShell (this gets installed with AD DS, but I was able to excluded all but the module during the process)
Supported Software:
IIS - yes (app pools)
SQL Server - no
On server where MSA is to be used, navigate to Server Manager - Features - Add features
Confirm 3.5 Framework installed
Confirm Active Directory Module for Windows PowerShell installed
On any server with AD administration tools, Via PowerShell: NOTE: My MSA is WorkProdDnnIIS and my host is WorkProd2012.
C:> import-module activedirectory
C:> New-ADServiceAccount -name WorkProdDnnIIS -enable $true
C:> Add-AdComputerServiceAccount -Identity WorkProd2012 -ServiceAccount WorkProdDnnIIS
On any server with AD administration tools, via AD Users and Computers
the new MSA should be listed under "Managed Service Accounts"
On server on which MSA is to be used, via PowerShell
C:> import-module activedirectory
C:> Install-AdServiceAccount -Identity WorkProdDnnIIS
On server on which MSA is to be used, via IIS Manager
Change App Pool identity (e.g. POWER\WorkProdDnnIIS$ - Dollar sign required on end, leave password blank)
Lastly, the local policy settings to allow "Log on as batch job" and "Log on on as service" are required for the MSA for IIS app pools. I would suspect that the Install-ADServiceAccount would do this, however these changes could not be made locally. I manually edited the group policy on a domain controller to achieve the same end result.
Regards,
Cooter
When I start the application pool, and request a page in an application in that pool, I get a "HTTP Error 503. The service is unavailable."
If I look at the application pools in IIS, I can see that it has now stopped. Going to the event viewer I find this error message:
'The identity of application pool Badge.Web is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request. If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.'
I'm very sure the credentials I'm using is correct. Something else is causing the app pool to stop.
I had similar problem today when an application pool using Windows user identity X stopped working after password change for that user.
Apparently, some information linked to old credentials was stored in the system, and I solved the problem by:
switching app pool identity to NetworkService
switching it back to X using the new password
So far it's working fine.
I found an article saying
The fix is to ensure that the Service/AppPool accounts have the ‘Log on as a batch job’ and ‘Log on as a service’ user rights on the server. This right can be found in Local Security Policy > Computer Configuration > Windows Settings > Local Policies > User Rights Assignment. Either remove the conflicting Group Policy and fix the Local Policy or add the rights to the Group Policy.
http://waveformation.com/2009/06/08/event-5021-the-identity-of-application-pool-lsgroupexpapppool-is-invalid/
While there may be several reasons why this may occur, in this specific case, the 503 error was occurring because the Application pool failed to start. This was because the password was changed recently for the Identity under which the application pool was trying to run. Fix was to go to the IIS Manager-> Application Pool -> Advanced Settings -> Process Model -> Identity and set the password to the new one.
It would also help to check the Event Viewer Logs(Event Viewer (Local) -> Windows Logs -> Application to look for specific causes of failure before proceeding to troubleshoot any further.
My problem was solved by changing Application Pool Identity to NetworkService, going to Advanced Settings > Process Model > Identity > NetworkService with the desired Application Pool selected.
I had the same issue and my solution was: Manager -> Application Pool -> "Select the pool" -> Advanced Settings -> Process Model -> Identity -> NetworkService
I am setting up Tridion R 5.3 content Manger server on Win 2003 Server. My Windows server is not having Active directory service enabled. The Impersonation user that I have set in Tridion Configuration Manager is
WORKGROUP\mtsuser
since the 2003 server is not under any Domain. Now whenever I try accessing console on //localhost/ and enter my credentials for mts user. The following error is shown with Mesaage on Console reading as "You dont have permission to access R 5.3 contact Administrator."
Event Type: Warning
Event Source: Kernel
Event Category: Security
Event ID: 200
Date: 2/15/2013
Time: 2:11:23 PM
User: WORKGROUP\mtsuser
Computer: WORKGROUP
Description:
Unable to Initialize TDSE object.
Access is denied for the user WORKGROUP\mtsuser.
Error Code:
0x80040302 (-2147220734)
Call stack:
SystemBLST.GetUserContext
SystemBLST.IBLSecurityST_GetUserContext
TDSE.Initialize
Please help In dire need of a solution....
If your machine is not under domain then where does WORKGROUP\mtsuser come from? Who is managing its credentials? I think you should use local machine name\mtsuser and manage credentials locally. Besides you are not supposed to be able to access CME with MTSUser. This user is system user and is only to be used by the system. Also, as you are on 5.3 version, you should check documentation and make sure you've granted all the necessary rights and permissions to this user.
And you should really consider one of the supported versions of Tridion
MTSUser should not be set as an impersonation user, this is your SYSTEM account
"Access is denied" means literally that the user doesn't have permissions for a given action. Maybe it's not an allowed Tridion user, since you don't have access to Tridion I'd recommend looking at the TRUSTEES table, and finding the MTSUser account there. If it doesn't match, then it certainly will not work. Add a record to the TRUSTEES table with the correct information.
As user978511 states, 5.3 is pretty old (early 2008), and not officially supported anymore, but I doubt you can do anything about that.
The impersonation account should be the same account that runs the application pool in IIS - by default this is Network Service
Our site is currently having this problem. Basically it only happen when we click some particular links where it will pop-up a new window.
This is the error message we receive :
Unable to make the session state request to the session state server.
Please ensure that the ASP.NET State service is started and that
the client and server ports are the same. If the server is on a
remote machine, please ensure that it accepts remote requests by
checking the value of
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection.
If the server is on the local machine, and if the before
mentioned registry value does not exist or is set to 0, then the state
server connection string must use either 'localhost' or '127.0.0.1' as
the server name. target site : Void
MakeRequest(StateProtocolVerb, System.String, StateProtocolExclusive,
Int32, Int32, Int32, Byte[], Int32, Int32, SessionNDMakeRequestResults
ByRef)
this is the webconfig that contain sessionstate tag :
<sessionState mode="StateServer" timeout="45" />
I have check the ASP.NET State Service, and it is currently started and set to automatic
I have set the registry stated in the error message to 1, but still not working.
Start–> Administrative Tools –> Services
Right-click on the ASP.NET State Service and click “start”
Additionally you could set the service to automatic so that it will work after a reboot
If you need to change HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection to 1, remember to restart the ASP.net state service after you change the parameter.
Check that:
stateConnectionString="tcpip=server:port"
is correct. Also please check that default port (42424) is available and your system does not have a firewall that is blocking the port on your system
Type Services.msc in run panel of windows run window. It will list all the windows services in our system. Now we need to start Asp .net State service as show in the image.
Your issue will get resolved.
One of my clients was facing the same issue. Following steps are taken to fix this.
(1) Open Run.
(2) Type Services.msc
(3) Select ASP.NET State Service
(4) Right Click and Start it.
Another thing to check is whether you have Windows Firewall enabled, since that might be blocking port 42424.
I've had the same issue when some ASP.NET installation was corrupted. In that case they suggest running aspnet_regiis -i -enable
I've found that some developers will for some reason define the server's private IP outside of IIS in an unexpected location, like a nonstandard config file (i.e. not web.config) or a text file. This can cause internal operation to fail even when the service is started, ports aren't being blocked, reg keys are correct, etc.
Kaseya, in particular, places a file called serveripinternal.txt in the root IIS directory of the VSA server. I've seen the text of your error when somebody running their own Kaseya instance changed the server's internal IP. The server will be reachable, IIS will respond, and the login page will come up - but login will fail with the cited message.
Not the best answer, but it's an option anyway:
Comment the given line in the web.config.
I recently ran into this issue and none of the solutions proposed fixed it. The issue turned out to be an excessive use of datasets stored in the session. There was a flaw in the code that results in the session size to increase 10x.
There is an article on the msdn blog that also talks about this.
http://blogs.msdn.com/b/johan/archive/2006/11/20/sessionstate-performance.aspx
I used a function to write custom trace messages to measure the size of the session data on the live site.
I'm having a major issue trying to configure a new install of BizTalk Server 2006 (not R2). The server had BizTalk installed on it before, and it was working fine. I've uninstalled BizTalk, removed the databases and jobs from the SQL server, which is a separate machine, and re-installed BizTalk. The install was successful, with no errors during the install, and nothing in the install logs.
I'm configuring the BizTalk server to be the SSO master secret server, along with creating a new BizTalk group and registering the BizTalk runtime. The process always errors out on creating the SSO database on the SQL server. In the ConfigLog, there are a couple of warnings that the MSSQLServerOLAPService does not exist, then it shows errors on creating the SSO database. There are 4 in a row. In order, they are:
Error ConfigHelper] [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
Error ConfigHelper] SQL error: 08001 Native error code: 17
Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\sqlhelper.cpp(1176): FAILED hr = 80004005
Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\sqlhelper.cpp(918): FAILED hr = 80004005
It then has similar errors trying to create each of the BizTalk databases.
On the SQL server, there are corresponding errors in the SQL Server Logs - 2 for each attempt
Login failed for user '[USERNAME]'.[CLIENT: [IP ADDRESS]]
Error: 18456, Severity: 14, State: 16
The first error from the SQL logs also shows up as a failure audit in the SQL server's application event log.
The biggest issue I am having with this is that the user I am logged on to the BizTalk server is a local admin on both the BizTalk server and the SQL server, and is in the SQL sysadmin group. The user that I am configuring the BizTalk services to run under is also a local admin on both servers and in the sysadmin group on the SQL server. I've checked the MSDTC settings on both machines and made sure they are set as the BizTalk documentation recommends. SQL Browser is running on the SQL machine, and I've verified that network access is allowed using the SQL Surface Area Configuration tool.
Can anyone help me find something that I might have missed?
Re: Igal:
Yes, all of the servers and users are on the same domain. I've run across that posting on SQL protocols in researching this, but I tried to select a count from one of the tables in the default database of the logged in user while connected to another database. I had no problems at all running that query.
Re: Yossi:
I'm installing BizTalk on Windows Server 2003 R2 SP1. Yes, I have removed the SSODB (Wouldn't out it past myself to miss something like that though!). I will make sure I am providing the usernames correctly and check out the sources you linked and get back to you.
A few of pointers:
Check out the two points at the end of the Configuring Enterprise SSO Using the Configuration Manager page on MSDN:
When configuring the SSO Windows
accounts using local accounts, you
must specify the account name without
the computer name.
When using a local SQL Server named
instance as data store, you must use
LocalMachineName\InstanceName instead
of LocalMachineName\InstanceName,
PortNumber.
Check out the relevant installation guide (don't worry about the fact that it relates to R2, they seems to have hidden the 'R1' documentation, but they are the same), and specifically the section around "Windows Groups and Service Accounts"
also - just to be sure - when you have uninstalled BizTalk and removed the databases - you have removed the SSODB as well, right?! :-)
The log files are very confusing - especially when deciding which error is the acutal problem - have you tried looking up any other errors you've had? (check out this blog entry, for example)
I had everything set up properly. Unfortunately for me, the answer was the standard "Windows" answer - reboot and try again. As soon as I rebooted the SQL server, I was able to configure BizTalk just fine.
I am going to set Yossi's answer as accepted, however, since that would be the most relevant for anyone else who may be reading this question.
Just remember to reboot after all setting changes!
Make sure the BizTalkMgmtDb and BizTalkMsgBoxDb have your local admin account as DB OWNER.
Right click on the databases --> Properties --> Files --> Owner: