From one PC to another, I intend to export and import the credentials saved in my SSMS.
My SSMS has some SQL Server authentication-based credentials saved for a couple of cloud DBs. Going through all of them and saving their credentials on my new PC will take significant effort and time.
I observed that SSMS credentials are stored in the Windows credential manager. I tried exporting them from the first PC to the second one.
The credentials have been successfully imported to the second PC.
However, still, when I open the SSMS, the credentials are not shown/ loaded.
Related
I am trying to restored a .bak file on an Azure SQL server through SSMS.
The reason why I am doing this is that my company unfortunately blocked any action on the Azure portal itself and therefore I have to find another way around.
I am able to connect successfully to the DB on Azure with my admin account through SSMS.
I first successfully restored the .bak on my local database. And then I am trying:
Again, I am able to connect through the same SSMS to the SQL db.
Moreover, when starting this procedure I get asked to connect first to the DB, which works successfully! What I mean is:
It doesn't give me any error, which is weird because if I try to connect with a wrong password it tells me right away that is wrong. So it kind of accepts it. It's only after when I really start the deployment that it gives me the problem:
Just for now, Azure SQL database doesn't support restore from .bak file.
You work flow should be right, restore the .bak file(database) into a local SQL Server firstly, then deploy the restored database to Azure with "Deploy database to Microsoft Azure SQL database".
Make sure you are using the server admin account of the Azure SQL database. Per my experience, the error is usually caused by the permission limits.
If all of these(SSMS) don't work, please thy other ways. Please try Data Migration Assistant(DMA) migrate the database. If DMA still give the same error, we can ensure that it's not caused by the tools, you need another higher Azure SQL database account permission.
HTH.
Working solution was to use the export data task:
For some reason this worked and the publish to ASQL task from SSMS didn't. I understand this is very based on the restrictions imposed by my company but at least this solution worked.
NOTE: as both Source and Destination use SQL Server Native Client .
Moreover when setting the Destination the refresh of the list of databases might not work (depending on your permissions on Server level) but if you type directly the name of the database it will work. Talking about this:
I have an Azure SQL Server (native, not inside a VM) that I connect to every day via SSMS on my local machine - Windows 10 Pro.
For the first time, I am trying to connect Excel 2016 via Data-> Get Data-> From Database -> From SQL Server Database.
From there I am asked for the Server name, followed by login credentials, which I use the exact username and password I'm using for SSMS. I get an error message that says We couldn't authenticate with the credentials provided. Please try again.
This doesn't make any sense to me. My SSMS work perfectly, and Excel is under the same IP address as SSMS which is whitelisted. Is there something else inside Excel's settings which I'm missing?
FYI, I tried the server name both with and without 1433 after it just to be sure. Same result.
Screenshots below.
I tried using the data, get data, sql server option. It does not understand azure sql database.
If I use the data, new query, azure sql database option, I have the same screens that you have. I am using Excel 2016.
Here is your issue!
There are two tabs on the second screen. You are filling in the window tab. Therefore, it is trying to log into the database with windows (active directory) authentication. Choose the second option on the left pane, database. Use database credentials.
This should work with no issues.
I tested it out on my local machine.
for azure sql you always need to provide the database name, as you do not have rights to list databases on azure. (so this optional is not that optional for azure :)
I could list tables on azure sql from office 2016 on mac, nevertheless the excel query app shows only the tables but does not show any views. Once i made a table the import was hanging while trying to get the data. making a smaller table (just 60K rows) did not help. The SQL server connectivity seems to be broken/very slow on mac excel 2016.
I am running SQL Server 2014
I am trying to set up a scheduled SQL Agent job that runs an SSIS package and I need it to use a SQL Authentication login in order to access all the applications/servers the SSIS package accesses.
I have created a Credential that is mapped to the SQL Authentication login and connected it to a Proxy which the SQL Agent runs as when accessing the SSIS package, however, the job fails with an error message:
Unable to start execution of step 1 (reason: Could not get proxy data for proxy_id = 1). The step failed.
I have confirmed that:
I can access all servers/applications using the SQL Authentication account
The SSIS package connections are configured for SQL Authentication
I can run the SSIS package manually using the SQL Authentication fine
All accessed SQL Server Databases are configured for both Windows AD and SQL authentication login
When I create the SQL Server Agent Job, the step that runs the SSIS package has an option for the SQL Server Authentication login but the option is greyed out and I cannot select it:
I feel like I am missing a very obvious step but it's eluding me, any assistance will be appreciated.
#oscar and #chuck are both correct SQL Agent jobs running SSIS packages cannot run in SQL Authentication mode they have to use Windows Authentication. The user that runs the agent job unless you specify otherwise is the SQL Agent service account. It is that service account and the SQL Service account on the server you are running it on that will need certain permissions. However, you can change which account it executes as per chuck's note. Of course depending on who many different servers you are passing credentials and what is being accessed you can also get into a kerberos double hop problem...... Trust me solving that last part not so fun but still doable.
However the thing is if you must use SQL Authentication you don't need a windows user at all. you can put the SQL Authentication credentials in your connection strings of the connection managers in SSIS package. The SQL Agent service account can handle any file access issues for you and your connection strings can pass the sql credentials. no double hop problem and easy. If you are worried about embedding credentials you should use a less privileged sql account but you can also encrypt them and store them with the package. There are also several ways of dynamically getting them from an encrypted state.
I have one web server & one DB server (running SQL SERVER 2008). Both the servers are in different domains. The web server is allowed to communicate(the communication takes place internally without the intervention of firewall) directly with the DB server, it is given Admin privileges & the DB access through SQL is going on without any problems.But whenever the web server tries to access the Reporting Server & its services, its asking for a separate authentication(Local system account authentication has been configured for SQL Server). I want to know whether is there any way to get rid of this separate authentication for Reporting Services
If you are being prompted for credentials when running a report, then your data source is configured to prompt at run time. You'll need to change the DS to use a SQL login if you don't want this to happen. Your windows credentials cannot be passed from one server to another.
If you are being prompted to log on to the RS site - I've only experienced that on firefox but fixed with a firefox config setting to save the cred for the domain.
I have built an SSIS job in visual studio 2005 that accesses a flat file and updates a table in SQL Server 2005. This works perfectly. I then store a copy on SQL Server by using the server storage option in the protection level property. When I try to run this it cannot locate the flat file. The flat file is located on a server and I use the IP address to access it. I have noticed that if I remove my maping to this server and run the job from visual studio, it cannot find it either. Hoe do I access the file from SQL Server 2005 ? I intend to schedule this job to run automatically on SQL Server.
Many Thanks for any help you can give.
Ronnie Carlin
Just to avoid anything more complex being the issue, check what account the job is being run under (e.g. has a procy and credential) or whether it is using the base SQL Agent account, and then check whether that account has access rights to the folder \ file you are trying to import.
Had that catch us out more than once.
Edited to include the additional information in the main answer.
When SQL Agent runs a job it does not use your account, even if you initiated the job execution - it uses the SQL Agent account. The account the SQl Agent is set up under (by default) or a named account you specidy with a proxy / credential. You might be able to access the folder, but you need to check what account SQL Agent is running under and whether it can access it.
To find out which account the job is running under by default you can access it via
Start -> Program files ->SQL Server -> Configuration Tools -> SQL Server Configuration Manager. In the 2005 Services SQL Server Agent will be listed, right click properties, first tab shows what account the Agent is being run under.
However, if you need a job running under a specific account I would advise you create a proxy / credential and not alter the agent account - since that is the account all the other jobs are using.
Credential and proxy are different objects within SQL, Credentials are stored under the security folder / credentials - that is where you create a credential and place your AD username / pwd.
The proxy then asks you to select a credential from the list of credentials already stored on the system - not your domain\user at that point.