I have a Visual Studio Team Services Build Definition to deploy an Asp.Net MVC application to Azure Web Site. I used the wizards to create my build definition so it is pretty vanilla implementation.
Most of the build goes well. The 'Get Source', 'Build Solution', 'Test Assemblies' tasks all pass. But the task for the 'Azure Deployment' is failing and it looks to me as though it is having problems with the PowerShell credentials.
The error stats :
AADSTS50034: To sign into this application the account must be added to the mydomain.org directory.
Since this is running in the cloud, I don't know what account it is trying to use so I am looking for some ideas how to get past this step.
Here is the output of the Azure Deployment task.
******************************************************************************
Starting task: Azure Deployment: http://superpoolsquares.azurewebsites.net
******************************************************************************
Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\AzureWebPowerShellDeployment\1.0.23\Publish-AzureWebDeployment.ps1
Importing Azure Powershell module.
Importing AzureRM Powershell module.
AzurePSCmdletsVersion= 1.0.0
Get-ServiceEndpoint -Name edb1710a-25b3-4037-93b0-58c00f83c038 -Context Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.TaskContext
Username= ********
azureSubscriptionId= b4d2fa61-92ff-494a-9ff1-d1362895fc78
azureSubscriptionName= Visual Studio Professional with MSDN
Add-AzureAccount -Credential $psCredential
AADSTS50034: To sign into this application the account must be added to the mydomain.org directory.
Trace ID: 2cb051b9-6e76-4789-8a5d-e95a9486b731
Correlation ID: 22162659-23fa-4858-b957-9ccbf120654d
Timestamp: 2016-02-10 00:19:27Z: The remote server returned an error: (400) Bad Request.
Add-AzureRMAccount -Credential $psCredential
AADSTS50034: To sign into this application the account must be added to the mydomain.org directory.
Trace ID: ed10284e-87b6-4d45-8bd3-9ed1b25f4498
Correlation ID: 88960dea-0434-4eba-9f17-e4d6ceba1a41
Timestamp: 2016-02-10 00:20:21Z: The remote server returned an error: (400) Bad Request.
There was an error with the Azure credentials used for deployment.
It uses the account you configured on Service Endpoints dialog as following:
According to the error message, the account you use isn't been added to the mydomain.org directory which is the trusted AD by the subscription. So you need to add your account into that directory from Azure Portal and then try the deployment.
If you don't want make any change on Azure. You can use "Certificate Based" authentication when configure the connection.
Related
I have turned on Application Insights on my app service. Everytime I try to run the app or login using the app it gives an error:
An error has occurred. Please call support or your account manager if this error persists
When i looked in the Application errors under Logging,I get the following:
System.ApplicationException: The trace listener AzureBlobTraceListener is disabled.
---> System.InvalidOperationException: The SAS URL for the cloud storage account is not
specified. Use the environment variable
'DIAGNOSTICS_AZUREBLOBCONTAINERSASURL' to define it.
Im assuming I need to add the following in the Configuration of the App Service:
{
"name": "DIAGNOSTICS_AZUREBLOBCONTAINERSASURL",
"value": <URL>,
"slotSetting": true
},
But what is the and where can i find it ? Or is there a different error causing the app to crash once application insights is enabled, has anyone experienced this ?
I can see you have configured DIAGNOSTICS_AZUREBLOBCONTAINERSASURL without providing the value.
Get the Blob service SAS URL value from the Storage Account.
In Azure Portal => Create a Storage Account.
Initially the option to generate SAS is disabled for me.
Navigate to your Storage Account => Shared access signature = > select Container and Object checkboxes.
An option to Generate SAS and connection string will be enabled.
Copy the Blob service SAS URL and provide the value in either local Configuration settings or in Azure App Service => Configuration => Application Settings.
In Azure App Service Settings
Save the settings and access the URL.
My question before is that once i generate Generate SAS and Conection string and copy to clip board.
Even if you generate the SAS again, the value will be same till here - https://yourSA.blob.core.windows.net/?sv=2021-06-08&ss=*****=co&sp=******&se=2022-12-05T14:.
Even we can add the SAS token in App settings automatically. Follow the below steps.
In Azure App Service => App Service logs = >set Application logging (Blob) to On and continue the steps to add the Storage Account. If you don't have create a new Storage Account.
"Unable to find mscorlib assembly reference:.
Make sure you are using the latest package references.
Update the framework version 4.7.2 to 4.8 in VS. Rebuild and Re-deploy the App.
After deploying to a newly created Azure App Service, I get this error:
HTTP Error 500.0 - ANCM In-Process Handler Load Failure
eventlog.xml shows these two lines:
<Data>Failed to start application '/LM/W3SVC/1773510456/ROOT', ErrorCode '0x800700c1'.</Data>
And
<Data>Could not find inprocess request handler. Captured output from invoking hostfxr: </Data>
I am deploying a 64 bit Web Api (<RuntimeIdentifier>win-x64</RuntimeIdentifier> inside the csproj).
Googling the errors reveals that it's related to a 64bit/32bit mismatch. Azure App Service is set to 32 bit, this needs to be changed. Copied and modified from AspNetCore.Docs Issue 13013 :
Azure App Service does have both the 32- and 64-bit runtimes available
since .NET Core 2.2 was released. To set the Platform to 64
Bit, go to the App Service > Configuration > General settings > Platform settings > Platform > 64 bit. Note that you need to have a Basic or higher service app plan.
This seems to be a common question, however I haven't found a solution out there and many related questions are quite vague. Anyways, I am deploying an ASP.NET MVC 5 application to AWS using the AWS toolkit for Visual Studio Pro 2013. I have successfully published the app to Elastic Beanstalk with the exception of my database file which exists as a localDB database (.mdf). In trying to migrate this (very small) database I have created an RDS DB instance for SQL Server Express. My issue is that I cannot create a SQL Server DB which appears to be a common issue for VS users: I right click on the DB instance, select "Create SQL Server Database", VS is busy for a few moments and then nothing happens.
What I have done thus far:
I have an RDS instance created on a VPC with a security group that has an Inbound rule set to allow all traffic from my IP
I have an IAM user account with the following policies: PowerUserAccess, AmazonS3FullAccess, AmazonVPCFullAccess (I imagine some of this is redundant-I added additional policies to see if it was a permission issue)
So to succinctly state my questions, why is Visual Studio failing to create the SQL Server DB within the database instance? Or alternatively, is there a simpler method of migrating my database to AWS?
Just FYI, these are the references I have been using to deploy my application:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_NET.quickstart.html
https://aws.amazon.com/blogs/aws/net-support-for-aws-elastic-beanstalk-amazon-rds-for-sql-server-/
I'm brand new at AWS so let me know if clarification is needed.
Update: I checked the logs for my instance and I'm getting error logs
2014-12-12 18:16:02.72 Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/AMAZONA-E3AJMJI ] for the SQL Server service. Windows return code: 0xffffffff, state: 53. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.
And
2014-12-12 18:47:23.72 Logon Error: 17806, Severity: 20, State: 14.
2014-12-12 18:47:23.72 Logon SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed [CLIENT: 113.108.150.211]
2014-12-12 18:47:23.73 Logon Error: 18452, Severity: 14, State: 1.
2014-12-12 18:47:23.73 Logon Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 113.108.150.211]
UPDATE: Issue solved. We use a proxy server in my office which seemed to cause authentication with the RDS instance to fail, not allowing me to connect from my machine. I accepted Ossman's answer as I think it solves a lot of similar questions I've come across trying to solve this.
This is a AWS explorer for Visual Studio 2013 bug and actually occurs because you're using the "default security group" by default when you're creating your DB instance in RDS.
Access the EC2 Service in AWS Management Console.
Click on "Security Groups", and then on "Create Security Group"
Give it a Name, Description and use "vpc-0846aa61" as VPC.
And then add following rule for both "Inbound" and "OutBound" rules
Type: "All traffic"
Source (for Inbound): "Anywhere"
Destination (for Outbound): "Anywhere"
Then Create the Security Group
Go back to your DB Instance and then change the "default" security group to the one you just created. This is done by clicking "Instance Actions" and then "Modify".
Then you should be able to see following window when you right click on your instance in Visual Studio and clicking on "Create SQL Server Database":
My DB Instance:
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
I have an msbuild script that tries to create and deploy a BizTalk application to a remote server. I use the following task:
<MSBuild.ExtensionPack.BizTalk.BizTalkApplication TaskAction="Create" MachineName="$(BizTalkServer)" Applications="$(BizTalkApplicationName)" />
When trying to deploy on a remote server, I get the following error
error : COMException: Application registration failed because the
application already exists.
But that is not true, the application does not exist.
Searching on the net results in the following link, suggesting setting the MSDTC properties: http://social.msdn.microsoft.com/Forums/sa/biztalkediandas2/thread/251250c1-3f95-4457-8fbc-0274c722c7b0
But the DTC has been setup like this on both the local and remote server:
It is also worhty of note that I run two other tasks against the remote BizTalk server to check the existence of the application, and the existence of the WCF-SQL adapter. These both succeed.
<MSBuild.ExtensionPack.BizTalk.BizTalkApplication TaskAction="CheckExists" MachineName="$(BizTalkServer)" Application="$(BizTalkApplicationName)">
<Output TaskParameter="Exists"
PropertyName="ApplicationExists" />
</MSBuild.ExtensionPack.BizTalk.BizTalkApplication>
<MSBuild.ExtensionPack.BizTalk.BizTalkAdaptor TaskAction="CheckExists" MachineName="$(BizTalkServer)" AdaptorName="WCF-SQL">
<Output TaskParameter="Exists" PropertyName="AdaptorExists" />
</MSBuild.ExtensionPack.BizTalk.BizTalkAdaptor>
Update:
I inspected the event log. Don't know why I didn't think of that to begin with. I get the following 3 events:
1st event, Level=Information, Source=Sql server
Attempting to initialize Microsoft Distributed Transaction Coordinator
(MS DTC). This is an informational message only. No user action is
required.
2nd event, Level=Information, Source=Sql server
The Microsoft Distributed Transaction Coordinator (MS DTC) service
could not be contacted. If you would like distributed transaction
functionality, please start this service.
3rd event, Level=Error, Source=BizTalk
Unable to communicate with MessageBox BizTalkMsgBoxDb on SQL Instance
.. Error Code: 0x8004d01c. Possible reasons include:
1) The MessageBox is unavailable.
2) The network link from this machine to the MessageBox is down.
3) The DTC Configuration on either this local machine or the machine hosting this MessageBox is incorrect.
I discovered that although there is no BizTalk application on the remote server, the one I'm attempting to deploy to, with that name, there was a BizTalk application on the local server, the one I'm attempting to deploy from, with the specified name.
That shouldn't prevent me from deploying the application to a remote server but it does.
This behavior is present both when I use the MSBuild extension pack BizTalk tasks, and when I try to use btstask.exe to create a remote application.