I am trying to schedule an on-premises copy job that contains a SQL Server.
However I am getting a different kind of error when trying to enter the sql server credentials.
Type=Microsoft.Data.Mashup.InternalMashupException.Message..sorry,en
error occurred during
evaluation.,Source=Microsoft.Data.Mashup"Type=Microsoft.Mas..data
protection operation was unsuccessful. This may have been caused by
not having the user profile loaded for the current thread's user
context which may be the case when the thread is
impersonanting.Sources, "Type=Microsoft.Mashup.Evaluation.Inter...
I have provisioned the gateway onto the server where the sql server is hosted but getting this error.
Also I am using the Copy Preview feature to get this working.
I may be wrong here, but it looks like an authentication issue. Have you tried connecting to the server from the gateway? Open the Microsoft Integration Runtime Configuration Manager, go to Diagnostics and fill every field, then click test. If everything is correct, a green check should appear. You are trying to impersonate a user, so choose Windows instead of Basic.
Try with it until you get the green check, then make sure that the linked service you are using has the same info you used and it should work.
You can also try creating a database user and give it permissions to make the query you want, then changing the linked service to use the database user instead of the windows user.
Related
I just recently started to use Azure Data Studio to replace SSMS and VS Code. So far it is working great. I do have one "issue" I was wondering if anyone else encounters. I run the application with my Azure AD Admin. Under Connections I see all of my subscriptions and the underlying databases:
When I try to expand a server, I get an error that it is trying to connect with a SQL account:
It then brings up the connection details where it is set to use SQL Authentication:
If I change the Authentication type to Azure Active Directory - Universal with MFA support, and click connect it does without issue.
My question is, is there a way to change what the server connection uses as a default so I don't have to try to expand, fail, change auth type, and then connect? It is nice not having to manually create all of the connections to all of our subscriptions and sql servers and just have them load there and open them.
I searched all the settings of Azure data studio, but did not find the option to change the default authentication type of login Azure SQL.
User and workspace setttings of Azure data studio, you can refrence this document.
You can click the power plug icon in the right and then choose Authentication type to login to the server.
Trying to edit provisioning mode in an Azure Enterprise App through SCIM but keep getting the error below:
Funny enough I created another app to test the same credentials and the credentials work. I am wondering what could be the issue with this current app. Below you can see I am not even able to change the provisioning to manual, it's stuck on automatic:
Anyone familiar with this in Azure deployment?
List item
That error shows when you've customized your mappings / schema and set something invalid such as including Id as a target attribute or you have decided to primary keys in the advanced settings.
Select the check box for restore default attribute mappings and clear state and restart and save.
Got it. That design needs to be improved. You can use graph to delete the job. Sign into graph explorer as a global admin to delete the job and you will be able to authorize access again and get the default configuration on the old app. https://learn.microsoft.com/en-us/graph/api/synchronization-synchronizationjob-delete?view=graph-rest-beta&tabs=http
After I installed Automation Anywhere 11 with SQL Server 2017 on windows server 2012, I could not launch the control room getting bad gateway message.
Could anyone help identifying the problem??
There are several possible reasons for this to happen, the one most easy to miss is your SQL login not having permissions to access your DB.
Open your SQL Management Studio and check that your have login logging enabled (Server Properties -> Security -> Login auditing). It is set to Failed only by default, you can change it to Both successful and failed if you wish.
Then attempt to login to Control Room and then check the logs.
You are most likely going to see an account trying and failing to connect to the DB. Give that account sufficient privileges and try again.
I was experiencing something similar after I restarted my Automation Anywhere Control Room Service from services.msc as adviced in AA forum for getting this error.
grid is invalid state...contact administrator
But, after I restarted the Automation Anywhere Enterprise Auto Login Service V11 service the control room worked fine.
Here's the error message that is stumping me:
My Web App seems to have the correct connection string. This is exactly what Azure provides me when I click Show Connection String:
Server=tcp:myservertest.database.windows.net,1433;Initial Catalog=MyDatabaseTest;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Here's the connection string that I put in the Visual Studio Publish Settings Default Connection setting:
Server=tcp:myservertest.database.windows.net,1433;Initial Catalog=MyDatabaseTest;Persist Security Info=False;User ID=*****;Password=***********;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
I have confirmed the username and password are correct...I used the same ones to connect via Microsoft SQL Server Management Studio.
I tried setting up the Diagnostic settings as follows, but I'm not exactly sure where I can find the resulting logs. I don't see them in Kudo services, but I believe they'd be accessed elsewhere.
Does anyone know where they're stored?
Also, what other ways could this Login failed for user error message be debugged?
The error looks like you are able to connect to the server but the server rejects the login. Debugging in the server logs would help, so you are looking at the right place.
You can enable Azure SQL Database Auditing & Threat Detection. You can enable it on SQL Server instance level by opening your SQL Server resource and selecting Security / Auditing & Threat Detection. Select a storage account to store logs in Storage details (see picture below). For more information, see https://learn.microsoft.com/en-us/azure/sql-database/sql-database-auditing.
After enabling auditing try to login to your database. After that you can find the logs in the specified Azure Storage Account in blob container named sqldbauditlogs. The logs are in folder /servername/databasename/SqlDbAuditing_ServerAudit_NoRetention/yyyy-mm-dd/ in files with xel extension. You can download and open the .xel -file in SSMS (File / Open / File…). The xel file contains events and you can see login attempts there.
Event field succeeded tells if the login failed or not, and field server_principal_name contains the username in both cases.
From text in field additional_information you can find error_code (in the xml). Error code 40615 is blocked by firewall and code 18456 is wrong username or password. (error codes from https://learn.microsoft.com/en-us/azure/sql-database/sql-database-develop-error-messages)
You can also find some information in the database system tables for analysing the connections, e.g. sys.event_log (see: https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-event-log-azure-sql-database?view=azuresqldb-current).
More information on troubleshooting the Azure SQL Database connectivity can be found here: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-troubleshoot-common-connection-issues.
I hope this helps you forward with debugging the connection.
You've verified that Allow access to Azure services is ON. This is generally where we get tripped up. If it was coming from an outside place, we'd want to check the IP list here. Knowing that's not it, let's dig deeper.
You've gotten into the Kudu console to verify all the things. From that console, install mssql-cli. Run pip install mssql-cli from the Kudu console. If that doesn't work, look for direct urls curl or download to your PC and use the Kudu Console to upload the file into your app service.
Once you have the mssql-cli installed, try connecting with the credentials you've set in place in appSettings.json. (See https://github.com/dbcli/mssql-cli/blob/master/doc/usage_guide.md#options for command line options.) Most probably, it'll spit out a nice error message about why it can't connect, giving you more clues.
If mssql-cli connects successfully, there's something overriding your app's settings. Did you set the connection string in the Azure Portal's App Settings tab? Temporarily, you might alter your app to write portions of the connection string to an obscure page. And as soon as you get the info, DELETE THE PAGE and then change the password.
Another thing to try: grab all the details from the exception -- including Data and recursively through inner exceptions. It probably has a clue buried in there. You can remotely debug the app on Azure. Before you can debug, you'll need to ensure you've turned on remote debugging and selected the correct version of Visual Studio from the App Settings blade in your App Service.
Continue from comment - Where in Kudu would that be found? Justin in the general file explorer?
Go to Debug console > CMD - site > wwwroot - click Edit icon
Also ensure that Allow access to Azure services is ON.
Sometimes you need to check the connection string on azure application in azure. Maybe the connection string is different from the one in your web.config
I created a new Azure Mobile App and set up my Sql Server database with it. I use an email address as the username, and then assigned a password.
Once the Mobile App and the Sql Server db setup completed, I was able to get my iOS app to target it and use the Azure authentication services without any issue. I then inserted some data in to a table in the iOS app, without any errors.
Now, I want to open the database and verify the data. Anytime I try to connect to the server using SSMS or Visual Studio 2015, I am told that the login failed.
I use an email address like Johnathon#MyCompany.com. When the sign-in fails, it says:
Login failed for user 'Johnathon'.
Is it the email address for a login causing issues? My ISP blocks port 1433, so I thought that maybe that was the issue initially. So instead of using VS or SSMS, I moved to the web-designer on the Azure portal. When I sign in there, I receive the same error. This has occured across three different App Services setups. I tried using the older Mobile Services, and had this issue. I then moved to the newly released Mobile App Service but have the same issue. Each time I deleted the database and recreated it and the server.
I have also added my client IP to the azure sql server firewall.
I'm at a loss at this point.
Update
I have managed to sign in to the server within the Azure portal designer by omitting the database name. However, when I select the Design option, and then click the Design button on the database, I receive a Failed to create context error. I assume this is related to why I can't connect to the server when I specify a database name in the Azure portal.
As a note, having the # symbol in the SQL Azure login tends to cause a number of headaches and it is not recommended to have it in there. What you will notice is that SSMS and other applications try to use it as part of the server name which then causes context and other failures.
The easiest fix for this is to roll up another SQL Azure server with a login name that doesn't use the # symbol, you will have a better experience overall.