I need to figure out how to schedule refresh of PowerBI model just after SSIS packages (which loads data into underlying database) are completed successfully.
I cannot provide the script with credentials of an account which would refresh the PowerBI model published in workspace.
The SSIS packages are run in the context of Proxy account which credentials are already created in SQL Server instance.
I am wondering if there is a smart way to execute PowerBI refresh from as very last step of SSIS packages?
Other option would be to execute PowerShell script, but if I do it as SQL job step - the context of that script would be SQL Server Agent account (correct me if I am wrong). So I would have to either use the credentials in that PowerShell script (which I cannot do of course) or somehow read them from Proxy account?
Related
For more than a year we have a stable job executed in SQL Server-Agent. The job (designed in SSIS) is basically the following:
Connect to a SSAS DB via Power Query Editor and get some data from a
Cube -> Write it into a SQL Server DB.
When I execute this Job in SSIS, everything works fine. I can connect to SSAS via "Username / PW" Authentification kind. (The other method would be windows, but that does not work).
As I said, this job is executed on Server via Job Agent for more than a year.
However, since last week, we get the following error message and the job cannot be executed anymore:
MYPACKAGE:Error: AnalysisServices: Unable to obtain authentication token using the credentials provided. If your Active Directory tenant administrator has configured Multi-Factor Authentication or if your account is a Microsoft Account, please remove the user name and password from the connection string, and then retry. You should then be prompted to enter your credentials.
I tried a lot of things but it will not work.
I am wondering why it works on SSIS on my local machine but not on the server.
Do you have any idea?
I've been trying to deploy a database via a pipeline from Azure DevOps to an Azure resource group.
I have an ARM template for my database server in my Repo along with my DACPAC file.
In my release pipeline I first deploy the database server with an admin user defined in the ARM template to my resource group.
Then I use the "Azure SQL DacpacTask" to deploy the database schema. Here I give the admin credentials and it works flawlessly.
The issue is that the customer doesn't want it deployed as a DACPAC but rather an SQL script. They've given me a "CREATE TO..."-script from their database, created inside MS SQL Studio, which is also in my Repo.
The "Azure SQL DacpacTask" inside my release pipeline has an option for using an SQL file instead of DACPAC, but it doesn't work for me.
But no matter how I do it, my pipeline fails when running the "Azure SQL DacpacTask" and all I get, even in debug-mode is "Login failed for user '***'".
I can connect to the SQL Server through MSSQL Studio on my local machine using the admin credentials defined in my ARM template.
I've tried by adding the agent's IP before running the SQL script, but with no success.
Can anyone point me in the right direction or maybe tell me what I'm doing wrong? Why is it that it keeps failing to log in?
They want it deployed with little to no human interaction. Is it doable only through the ADO pipeline?
EDIT
Additional info:
I have tried with hardcoded password and user with no luck.
If I manually create a database and then try to deploy one via script and pipeline, it fails because a database already exists, and not because of a failed login.
I've setup Audit in Azure which generates 2 files with little to no info. I'm not sure what I'm looking at.
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.
So I've created a neat SSIS package which essentially reads a SharePoint 2010 list, moves the data into a 'Delete' list, (thus deleting the contents), then populates the list with fresh data pulled from a SQL Database.
It works in Visual Studio just fine, it works if I'm logged into Integration Services and run the package manually fine, but when I place it into a SQL job I get nothing.
At first I thought maybe it was that I didn't install the SharePoint destination connection manager thing on the server, so I did, only quickly then realizing that if that was the cause, running the package manually from SSIS would have failed.
Then I figured it was the account it was being executed under (SSIS Service Account), so I created a proxy (SharePoint Admin) and added the credential, still no go. Then I added my own credentials, just to be sure, and still no go. Just to be super sure, I also added the SQL Agent account as a SharePoint Site Collection Administrator, which means the account now runs the package fine by right clicking on the package from Integration Services, but put it into a SQL Agent Job as a step, no love.
The job doesn't fail either, it just sits there spinning and spinning. I'm stumped. I've tried turning on logging as far as the options allow me under the advanced tab on the job step, but as the job doesn't fail, nothing is logged.
There's no question that the job can be run, using either my account or the SQL Agent account, but place it into a SQL job, nothing! I'm going crazy here. Any ideas?
I've found that that your SQL Agent account MUST be an SA on the server in order for it to be able to run SSIS packages as part of a job step when the 'Bulk Insert' task type is employed by the package...
https://msdn.microsoft.com/en-us/library/ms141239.aspx
N03L
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.