On our TFS build server, we're getting the following error most builds (so not ALL builds, sometimes the build runs perfectly!)
"The identity of application pool application_pool_name 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."
Since it runs some builds, we know the identity is in fact not invalid and that it's not a code problem. Does anybody know if there are any other cases where you can get this specific error? We've had this problem for several months now...
EDIT: We've also found out it started after MS updates KB4015547 and KB4015550, but uninstalling them didn't help. Re-entering the user or using another user didn't work either.
The identity of all application pools should be set to the
correspondingservice account that you specified when you installed
Team Foundation Server (TFSService).
Change the identity and then try to stop and restart the application pool. For this, open Internet Information Services (IIS) Manager, expand the local computer and open Application Pools. Open the navigation menu and choose Stop or Start.
Restart the application pool so that Windows Process Activation Service (WAS) can determine the correct state of the protocol.
If above is still not working, you could also try reset the IIS entirely. More ways you could take a look at this thread: An application pool is not configured correctly
Related
I have created the IIS site and pointed it at the deployment folder. I have enabled stdout logging and this is the error:
info: Microsoft.Extensions.DependencyInjection.DataProtectionServices[0]
User profile is available. Using 'C:\Users\No Managed Code\AppData\Local\ASP.NET\DataProtection-Keys' as key repository and Windows DPAPI to encrypt keys at rest.
fail: Microsoft.EntityFrameworkCore.Query.Internal.QueryCompiler[1]
An exception occurred in the database while iterating the results of a query.
System.Data.SqlClient.SqlException: Cannot open database "KeyStoneDb" requested by the login. The login failed.
Login failed for user 'IIS APPPOOL\No Managed Code'.
So, I added the login to SQL with all the necessary rights. Retested in DEV - fine, but when running IIS I still get the issue. The Application Pool being used is 'No Managed Code'.
Why cant the app not connect to the database?
IIS AppPool accounts are virtual accounts, therefore, they don't actually exist as a normal user on the system.
You can not give access to networked resources using that identity. Shared\network resources like file shares and databases that need to communicate with these accounts need to have the 'domain\machinename$' with appropriate permissions.
Give 'domain\machinename$' appropriate permissions on your DB. That should do it.
I am using azure AD authentication to authenticate a user in my MVC
application.And I published my application on azure and it is
working fine.
But, when I run my application locally then it Microsoft's login
page comes up and when I enter credentials and click on SignIn
button then it is giving "Sorry, but we’re having trouble signing
you in.We received a bad request."
But the same application is on azure and if I access it from there then it allow me to login.
To create this apllication I follwed link to add azure AD authentication
If you notice the error message, it clearly indicates that you have not configured https://localhost:44320 as one of the reply addresses.
Please go back to application configuration screen in your Azure AD and add https://localhost:44320 as additional reply address. That should take care of this problem.
Add the below to your Web.config. It must be the same port which you have added at the time of Application registration.
<add key="RedirectUri" value="https://localhost:44320/" />
I hit this, it has cost me a lot of time.
I would check firstly that you have the ability in Azure to access third party applications.
In Azure > Users & Groups > User Settings:
You see the first item (Users can allow apps to access their data) - without this checked I believe it wont work.
As you are running your application locally it is not published to Azure, this means that although it may be within the realms of your organisations network, Azure still views it as a third party application.
Be wary setting this to 'Yes'. I understand that there are ways to then create applications that allow you to behave as an Azure super user....
In case anyone else comes across this, here is what happened to me. I had been switching back and forth between environments within Visual Studio (Project >> Properties >> Debug >> Environment Variables). Well, the last time I switched it, I wrote "Develop" instead of "Development" to switch back. This caused .NET Core to grab the wrong appsettings which connected to the wrong AD which did not have my localhost setup on it. It took me an hour to catch what I had done wrong.
This may not be exactly what has happened to you, but do check to make sure you are picking up the Azure AD settings you are expecting if they are in your appsettings. It could be a good point to start at.
Right, this is driving me insane. This works fine locally with Excel 2013, but when the website is published to a remote server with Excel 2010 it fails. From what I can see the DCOM configuration is the same locally as remote.
After fighting with Excel 2010 and DCOM permissions for over an hour now the best I have got is this exception: System.Runtime.InteropServices.COMException (0x80070BBC): Office has detected a problem with this file. To help protect your computer this file cannot be opened.
This is the result of a web application trying to open a *.xls file from a location it has just uploaded to. The application pool is running under ApplicationPoolIdentity and I have set the permissions for this specific app pool under mmc -32 on Launch and Activation Permissions so there's no problem running Excel. What I think I'm facing here is protected mode issues as the file is definitely not corrupt.
I've gone into Excel and Trust Centre settings and have added the location where the *.xls file is uploaded to (and subsequently opened) as a trusted location. If I open the file on the hosting server (under my domain account) I don't get the protected view block on the file - however, the Identity on the DCOM configuration is set to the launching user. So, what does this mean from the following (or something I haven't listed):
I need to add this location as trusted at a group policy level because the account launching the actual application doesn't have this configuration in its profile?
I need to create an actual account on the server and use this account as the Identity for running the application?
... ?
Just to clarify I've already been down the DCOM Security config route and RIDICULOUS issues with C:\Windows\System32\config\systemprofile\Desktop and C:\Windows\SysWOW64\config\systemprofile\Desktop. The configuration is:
.NET 4.5 (classic pipeline) app pool running under ApplicationPoolIdentity
DCOM Config > Security > Launch and Activation Permissions all set for this specific identity (Access Permissions and Configuration Permissions all set to Use Default)
File is uploaded correctly and appears in destination, opening on the server itself (under my domain account) respects the Trusted Location and doesn't give protected mode warning
Process to parse fails with the above exception.
Here is a screenshot of the Interop assembly I'm using if this is pertinent.
Ok... for anyone stumbling on this issue I have bitten the bullet and had to do the following:
Create a local account (AutomatedOffice in my instance) and set DCOM config to run Excel under this account
Log in as above account and change Excel settings to add folder in application root to trusted location and disable protected mode messages
Allow "Network Service" to invoke DCOM processes locally (through server DCOM config and not CLSID config)
Add NTFS permissions for this account on C:\Windows[System32|SYSWOW64]\config\systemprofile\Desktop paths
What was weird, after creating the account I was getting the following exception Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. which was resolved by adding HOST\Users and HOST\NetworkServices group to DCOM security (local only!!!) settings.
You need to add in trust center, security locations the folder where your website is published, for examplo if your website reads a file from c:\temporal\ you must put on excel, security locations that folder name
I developed an application in Delphi 2010 that reads XML data from a transactional queue. It works fine if the queue is local or remote and I don't have to set permissions in both cases.
Now I have to convert that application into a Windows Service. I copied and pasted the same application into the service code, but when I try to read the queue I get the "Access denied" error. I'm doing the tests on my local machine.
Some people say that it's a matter of permissions. I found here in Stack Overflow some posts to the same problem but I didn't find the solution.
Any ideas? I'm using Windows 7 as well.
If you are running the application locally, you are running it under your Windows logon credentials. Services by default are launched under a different user account which may not have the same rights as your account does.
Bring up the service manager (start->services.msc), find your service in the list, right click it and select Properties. Then select the Log On tab and change it to a specific account name/password. (Use your account name / password.) You'll then be executing the code using the same credentials so your Access Denied error should go away.
Experienced a very strange problem today on our TFS2010 build server. Suddenly the build service failed for no apparent reason. We´re been trouble shooting it all day, but still haven´t found the reason yet.
One of the problems is that the build service is (or should!) running under an AD user called tfs2010build. However when I try to start the service, i get the following error
Service cannot be started. Microsoft.TeamFoundation.TeamFoundationServerUnauthorizedException: TF30063: You are not authorized to access http://tfs2010:8080/tfs/default. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.
When I look in the event log on the TFS2010 server, I see that the failed authentication is registered for a user called TFS2010Install, which was used to install everything. I´ve tripple checked and the service is specified as to be running under TFS2010Build.
Log from TFS2010 server:
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: TFS2010INSTALL
Account Domain: LC
So my question is how is this possible. COuld the user TFS2010Build some how be impersonated by TFS2010Install? I
ve tried to install an additional build server and here there´s no problem starting the service under the user TFS2010Build - hence it is not a problem with AD or TFS user rights.
Hope you guys can help out!
/Jasper
!! Updated with some screen shots. Build server is TFS2010BIULD and the TFS server is TFS2010
Link to full size
Screen shot of non working build server TFS2010Build
Screen shot of working build server TFS2010Build1
!!New Update
I've managed to get the Build service to run under the TFS2010Build user account (which was actually the initial state, when the problem started). When I queue builds to this controller and agent, i get the follwing in the build log:
TF215097: An error occurred while initializing a build for build definition \PlanteIT_MarkOnline_Scrum\CI_Main_FieldOnlineClient: TF215106: Access denied. LC\TFS2010INSTALL needs Update build information permissions for build definition CI_Main_FieldOnlineClient in team project PlanteIT_MarkOnline_Scrum to perform the action. For more information, contact the Team Foundation Server administrator.
It still insist that TFS2010Install user account is running the service, despite that TFS2010Build is used for the build service. Any ideas?
This is a stab in the dark, can you try clear the TFS client cache and your internet cache on your troubled build machine under the Tfs2010Build account? I've never seen this issue before but maybe some stale cached TfsProjectCollection object with TFS2010Install authentication stayed around and caused problems.
Have you also tried reconfigure your build machine?
To unconfigure:
tfsconfig.exe setup /uninstall:TeamBuild
and reconfigure through the wizard.
I will try once more ..., step by step :-)
FACT: When you register your build controller to a TFS project collection, being logged-in as TFS2010Build, an authentication dialog pops-up. This means that the TFS server does not accept TFS2010Build as an account that can be used to connect to your default collection on the TFS server.
FACT: When you register your build controller to a TFS project collection, being logged-in as TFS2010Install, no authentication dialog pops-up. This means that the TFS server does accept TFS2010Install as an account that can be used to connect to your default collection on the TFS server.
Apparently, because in both 1 and 2 your build controller is registered using the TFS2010Install account to the TFS server, either the controller or the server remembers these credentials and uses them to connect to the TFS server collection when the build controller is started, despite the fact that the service itself is running under the TFS2010Build account. This is a plausible situation and impersonation happens often this way for services. Maybe some TFS techie can either confirm or deny this behavior.
The question that remains for me: Why does the the default collection on the TFS server not accept the TFS2010Build account as a valid administrator?
Potential causes:
Read Jim Lamb's answer.
Something is wrong with the domain registration of the system or user used to connect the controller to the collection on the TFS server.
Fastest way to rid of the problem: Continue to install the secondary server that does not seem to have the problem, potentially experiment with using the TFS2010Build from this secondary server to see if the problem also occurs there.
A long aswer, but hopefully it gives you a big push in the right direction.
Sorry to hear that you're having problems getting this to work. Here are a couple of things you can check/try:
Make sure that the TFS2010Build user account is a member of the "Build Services" group in the TFS project collection you've associated it with.
If you install and configure the build service while logged in as a user who is a member of the Project Collection Administrators group on the associated project collection and is also a member of the local Administrators group on the build machine, all of the requisite permissions and other configuration will generally be set for you.
So, to summarize, the user configuring the build machine should be a member of the project collection administrators group and a member of the local administrators group. And, the user account the build machine is running as should be a member of the project collection's "build services" group.