I have created a SSIS job to run a script Task that opens an access db, runs 2 macros, then closes the database.
The access database is creating a report that the users want emailed at 2 a.m. Currently the access db is writing the report to a directory so SSIS can email the report.
At some point, the this access database will be converted fully over into SQL server either as a full SSIS job or SSRS report. Unfortunately due to other projects this will not happen for at least a year.
The job run fines from visual studio on my desktop.
I have deployed the job to the SSISDB. I have created credentials and proxy to run the SSIS package as a scheduled job. The scheduled job will run if the proxy is logged onto the server. The job will not run if the proxy is not logged into the server. The job returns an error: "i" macro cannot run in disabled mode.
Everything googled says to make sure the database is a trusted location. In the Access database we have gone into the trust center and added the "\\servername\filepath" to the trusted location and enabled macros.
This does not fix the issue. The proxy user has to be logged into the server for the job to run.
We have tried to do this as a .bat file with task scheduler and end up with the same result. Only runs when the user is logged into the sever
What needs to be done so the job can run in the middle of the night without the proxy user logged into the server?
Office 365 Access
Windows Server 2019
Visual Studio 2019
SSIS package deployed as 2017
Related
I have a OLEDB task that connects to ms-access database on local file system and dumps data into sql database.
Access db connection string is: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.16.0;
The SSIS package runs OK in visual studio. Access 2016 32-bit runtime is installed on this computer.
After deployment to SSIS catalog, right click and execute works OK. Access 2016 64-bit runtime is installed on this computer.
When this package is scheduled to run via SQL Agent job, using proxy/credential [domain user - example: domainname\user1] (having read permission on the access db file), then the job fails. The SSIS execution report shows error as: Unexpected Termination. There is no further information.
Suppose if I add the proxy credential (domainname\user1) to the local administrators group (in computer management) then the SQL Job runs OK. What could be the solution to this so I can give only the minimum required permissions?
The error is very difficult to debug as it doesn't occur when running via visual studio. Even when deployed to the SQL server and run from the SSIS catalog, the execution works OK. The error occurs only when the package is run via SQL server agent job (via credential/proxy) - the SSIS execution report doesn't show any helpful messages; and surprisingly the error gets resolved when the credential is added as local administrator on the computer - which is a bad practice.
The solution is analyse what kind of ms access file you are using and appropriately use the correct access runtime version (2013 vs 2016) and the correct provider value in the connection string.
Access runtime:
In my case, I uninstalled Access 2016 64-bit runtime and installed Access 2013 64-bit runtime.
Provider version:
I changed the provider version from 16.0 to 15.0, as shown below-
Before: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.16.0;
After: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.15.0;
Note:
There is no need to add the user to the local administrator group.
There is no need to login to the computer using that account.
Only read permission (under windows folder security) is sufficient assuming the SSIS packge will only read the ms access database.
It's hard to debug this only with the information provided, but in general:
The user running the job requires at least write and delete access on the underlying folder in which the Access database resides. This is required to generate a lockfile for the database.
If this is undesirable because the job may be modified by a malicious user, I've seen deployments where a copy is made in a temporary folder with write access and a size quota, and that temporary folder is removed as soon as the job finishes, regardless of if the job succeeded.
I am migrating reporting guff to a new 2016 sql server.
One integration package which I have upgraded, deployed and created a job for runs and then terminates unexpectedly. The only messages are that validation starts then it terminates.
The event viewer just shows a warning saying the job failed.
The package is run by a proxy account that also has access to a file share with excel documents on it. If I run Management studio with that account and manually execute the package I get the exact same messages. So I don't think it has anything to do with the account or permissions etc. If I run the package in visual studio it works fine.
Any suggestions on next trouble shooting steps?? Or how I can view better logs/ error files??
Thanks in advance
Kirsty
I developed an SSIS package on my database server (ServerDB) to execute SSRS reports on another server (ServerRPT).
When I run the SSIS package using MS VS 2008 on ServerDB, the reports can be generated.
Then, I try to schedule the package on my database using SQL Server Agent, the package failed to produce the reports. File name has been created on the server but zero file size. So, the package execution is fine and problem potentially lies on the Reporting Server access.
Reporting Server (ServerRpt) has a Windows Service Account.
Database Server (ServerDB) jobs executed using SQL Server Agent Account.
Is there anything I miss out or accounts that need to be created ?
Suspect it could be permission issue on ServerRpt.
Hope you can shed some lights.
Thanks ....
I've got this error when I tried to deploy SSRS report in Visual Studio.
(DAX 2012 kernel 6.0.1108.6510 app 6.0.1108.670 solution 6.1.1108.670)
Error 1 A call to the Microsoft Dynamics AX SRSFrameworkService service failed. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.43.6.57:8201. C:\Program Files (x86)\MSBuild\Microsoft\DynamicsTools\Microsoft.Dynamics.Framework.Design.Reporting.Modeling.targets 466
10.43.6.57:8201 is old address new should be 10.43.6.91:8201
Where I can change it?
In AX form SSRSServerFarm address is new:(NLDDAXDBS02TR, http://NLDDAXDBS02TR/Reports, 01#NLDDAXDBS02TR)
I run Visual Studio like this "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" /AxConfig "c:\Users\Username\Desktop\DEV.axc" with correct config file
in axc file I don't have 10.43.6.57 or old dns NLDDAXDBS01T
I scanned and replaced values in registry on client and server machine, checked all files on client and server machine, checked all values in database.
Also restarted AOSes, SSRS service, and client RDP session.
Microsoft Dynamics AX 2012 Configuration and perform a Refresh Configuration didn't help
Full CIL Compilation, Deactivate BIServices, Activate BIServices also didn't help
Running Visual Studio as Admin - same result
nslookup says: NLDDAXDBS01T - 10.43.6.57 NLDDAXDBS02TR - 10.43.6.91
System Administration > Setup > Business intelligence > Report Servers is correct because i tried to deploy from another rdp server and it works fine
Are you certain the default report server is setup correctly in Ax?
Found under:
System Administration > Setup > Business intelligence > Report
Servers
Check your business connector configuration to make sure it's connecting to the right environment, see https://technet.microsoft.com/en-us/library/aa569654.aspx
I think Visual Studio deploys to AX based on that business connector AXC, so if that's pointed to an incorrect environment that has the "old" SSRS setup, it would explain your issue.
I got this problem one time due to multiple AOS and SSRS instance, or you might stop AOS service while user still using.
First, you need to make sure Report servers configuration point correctly to SSRS instance.
Then, stop all AOS service, go to reporting service login with correct instance and check everything again.
Then, perform full compilation using AXbuild.exe , Full CIL.
Start AOS service and check.
Let us know result.
I am troubleshooting an SSIS package, permission issues around external files.
It only fails when running via the SQLAgent obviously using the SQL Agent unattended account.
This is fixed now however in order to test I needed to create a SQLAgent job and then a step within that job to test.
Obviously when a package is run locally via Visual studio it uses your own credentials. When you log into SSIS server via Management studio and use the Execute package utility does this use your own credentials or the SQL Agent credentials?
Is there any quick way of executing a package with the Agent without going through the fuss of creating an Agent job?