Is there any way to redo MSI configuration on an App Service?
I deleted the service principal in AD not realising it was for MSI so of course when I try to use MSI it cannot find it. If I disable/re-enable MSI it says it is registering in AD but does nothing. I have even tried deleting the MSI environment variables before disable/re-enable - the environment variables are regenerated (with a new SECRET value) but it still looks for the original service principal.
Related
We have 2 dev machines (dev1 and dev2) and we are trying to change the way we deploy. Until now we used to deploy to the local biztalk admin console, then create an MSI and instal that to the live server.
Now, we want to directly deploy to a test server (bztest-03) and once testing is done, create an msi on that machine. This works for the dev2 mavhine, but the dev1 machine gives the below error. the machine gives this error even when the same user as on dev2 is logged on and the rights on the database look the same (and on user roles)
What could cause these errors? The analytics_PortTrackingInfo isn't something we made and i find little hits on google about it and biztalk.
Severity Code Description Project File Line Suppression State
Error Deployment cannot initialize the connection to the database
"BizTalkMgmtDb" on server "BZTEST-03\DTA". Verify that you have the
required security permissions and that communication between
Distributed Transaction Coordinator services on the machines involved
is not prevented by current DTC security, firewall or authentication
settings. Invalid object name 'analytics_PortTrackingInfo'. 0
That error notwithstanding, you can't Deploy to a remote machine from Visual Studio. That has always been the case.
If you're looking to improve your Deploy process, the 'correct' way would be to add BTDF to your Solutions.
Deployment Framework for BizTalk
I have a number of tests in my project which are run as part of the build. Some of those tests are integration tests which need a username/password set of credentials in order to run the tests.
I want to keep these credentials out of the source code so on my local machine I have set them up as user secrets and on the server they are environment variables. The deployments are working just fine with this arrangement.
My problem is running the tests as part of the build. The tests are not being fed with any login credentials and therefore are failing with authentication issues. How do I supply these values without adding them to the appsettings.json files?
I am running a dotnet core project and have a standard Azure DevOps build template.
Thanks!
Non-secret variables declared in the build are automatically turned into environment variables on the build agent.
Secret variables are intentionally not turned into environment variables, but you can add a Command Line or Script task that's appropriate for your platform (Bash, Powershell, whatever) and set an environment variable by passing your secret in as a parameter to the script.
Deploying an asp.net project on local IIS server as a release version. Getting 401 unauthorized error on API call (allow anonymous enabled). Server runs with administrator user principal. This principal has all the permissions. And the project declared as application with correct .net library. The only thing I can't change is read only flag on the project directory. Anyone can help? Nothing in google resources worked...
Update: After a lot of searching and digging, I found a solution:
IIS Application basic settings - The default settings is to run application with Application pool user, which is usually limited with it's files access permissions. So the idea is to run application with administrator user.
Run as - enter administrator user name and password
Application pool type - The default application pool type is 2 and sometimes new .NET libraries are not accessible. So you have to add all the missing ASP.NET types to IIS.
Usually ASP.Net version suppose to be classic, in this case application works fast. Otherwise application refresh time may take long period.
Local folder permission - add local administrator, that you defined on IIS settings, and grand him all permissions to the folder recursively
SQL Server Management- the default server authentication is Windows Authentication, make it SQL Server and Windows Authentication mode
Add new user to the server and grand him all the permission to the database
Add this user to database Users and change the SQL connection string at the project accordingly. This way you prevent application pull trying to connect with database with it's user
Just posting this here as I went around in circles trying to diagnose an intermittent 401 error.
I had a virtual sub directory within the web application that referenced an external folder which was out of the directory tree so had different folder permissions.
Any scripts that referenced this folder failed - while others ran completely fine.
I am having trouble getting the desired result from my CI/CD pipeline when deploying a .Net Core 2.0 web app to Azure.
As it stands everything is working when I deploy to my test environment. I have added a setting - ConnectionString:Main - to link to the correct database in the AppSettings section for the development app in the Azure portal.
I now want to deploy to my production environment. The issue is that there are two production databases, only one of which is "live" any any one time. What I would like to do is create two release definitions, one for each database and then have the ability to deploy using either one.
Is it possible to simply add a release variable that will override the local connection string in AppSettings.json as it was with previous .Net versions or is a more complex solution required?
You can use JSON variable substitution feature of Azure App Service Deploy task, for example, replace the value of ConnectionString in the sample below, you can define a release/environment variable as Data.DefaultConnection.ConnectionString in release definition.
{
"Data": {
"DefaultConnection": {
"ConnectionString": "Server=(localdb)\SQLEXPRESS;Database=MyDB;Trusted_Connection=True"
}
}
}
When using ASP.NET Core apps on Azure, the recommended way to store secrets is by using Azure Key Vault. This makes sure that no credentials are stored in version control or in VSTS.
If you really want to update a configuration value during deployment, you can tokenize your parameters and replace them during deployment. You can use this marketplace task for that. Managing Config for .NET Core Web App Deployments with Tokenizer and ReplaceTokens Tasks describes how to use these tasks.
You should be able to accomplish this by creating the deployment via ARM template and creating different parameters files for each environment. Using the template the relevant app settings can be replaced, which will inject them into the Azure portal Application Settings. These settings will override what is checked into your config file in the repo.
I'm using biztalk 2009 and trying to deploy via vs.net 2008.
My project is just an empty BizTalk application with an empty orchestration. I've created a strong name key file and selected it in the Project properties under "Signing". I've also specified an application name.
When I deploy I get the error:
Error 1 Failed while Updating the Application 'BizTalk.System'. Permission denied. The current user does not have privilege to complete the operation. 0 0
Any ideas on what this means and what I'm doing wrong? From what I know it's not supposed to be updating BizTalk.System at all.
The BizTalk.System application is read-only so it can't be updated, but I doubt that you would be trying to update it without knowing it, especially with such a simple sounding project. Your new application should be referencing BizTalk.System though... maybe there is a problem creating this dependency?
These are some of the initial steps I would take to troubleshoot:
Check the BizTalkMgmtDb database to make sure you have the appropriate permissions
Check the EventViewer logs for more details about the Access Denied error
Try creating an empty application manually in the BizTalk Admin Console, see if you get the same error
If you can create the application manually, try deploying the project via VS 2008 to the empty application and see if you get the same error
Hopefully one of these will help pinpoint what the problem is (or even better, hopefully you've alreadty resolved the issue :) )
I agree that you shouldn't be deploying to the BizTalk.System application.
To check that you are deploying to the correct place, open your BizTalk project properties and click on the 'Deployment' tab (I'm making the assumption above that you are deploying locally, in which case the BizTalk Group Server and Configuration Database should already be set).
Under BizTalk Group, set Application Name to 'Test Application' (this can be changed later to something more meaningful); ensure all of the other boolean properties on the Deployment tab are set to true, with the exception of the Enable Unit Testing property.
When you now deploy the project from Visual Studio (by right clicking the project name and selecting 'Deploy', the new BizTalk Application will be created and the project deployed as a resource to that Application. Watch the VS Output window to check that they deployment is successful.
Once the deployment has completed, open the BizTalk Server Administration Console and expand the Applications node, you should now see a new application called 'Test Application'. If you expand the new app and take a look in Resources, you will see your recently deployed project.