I have the c:\Program Files\Myexe.exe on the Server1
I run BIDS package on MyPC1 and can't start it.
On the server in the task manager I see the process started, but it hangs, possibly because of the security warning.
Thank you,
Nikolz
If you see the program start, then you have successfully started it!
You now need to find out why it hangs. What security warning are you referring to?
Does the program have a UI? If so, it won't work very well if started remotely - which user do you want it to talk to?
Related
I have an Access DB app that exports a table (to XLS) then FTPs to our FTP server over our VPN. This routine has been working for several years, until ~yesterday. I am not sure what could have changed to break this function.
This is not really an Access DB issue as I see the same "Closed Connection" when manually attempting to FTP PUT at the Windows command line. Other users of the Access app (VPN and local) are not seeing this same issue.
I did receive a Win10 Security update this week - possible this affected my firewall settings?
Any suggestions where to begin? Googling suggests to portforward Port 20/21, but this seems to have no effect either.
Thank You!
Note 1: I do use WinSCP for passive transfers for another specific task to FTP to a 3rd party who requires passive transfers. Some of our users in India are unable to use this tool reliably, so I am hesitant to convert this basic function in my Access app as it works everywhere but my local machine.
Note 2: I attempted to add "QUOTE PASV" before a command line transfer with no effect. As I am reading, Windows FTP utility does not support Passive transfers
Note 3: FileZilla can see and transfer to the FTP server using "Plain FTP" mode. Interesting, but I really need this to work via command line without requiring a 3rd part app installation.
Note 4: I uninstalled the Win10 Security Update - No effect
I'm trying to set up SQL Server 2008 Web synchronisation between 2 servers, and am following the instructions step by step on MSDN, here: http://technet.microsoft.com/en-us/library/ff714039.aspx
All has gone fine, until I get to the section "Testing the Connection to replisapi.dll
" - when I go to https://my-server-name/sqlreplication/replisapi.dll?diag, I get a user name and password prompt, which is fine, and a 'There is a problem with this website's security certificate', which I expect, as I'm using a self-signed certificate during development.
Next though, I expect to see a diagnostics page, but instead, I get the browser's generic 'Do you want to open or save replisapi' message, forcing me to either open or save it.
Does anyone know what I'm missing here?
Many thanks in advance.
The .dll file is getting downloaded?
This happened to me before. I had to repair my IIS mappings using the Aspnet_regiis.exe utility. After running this utility I was able to view the diagnostics page.
http://www.idautomation.com/kb/aspx_error.html
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q306005&GSSNB=1
Hope this helps.
Issue: 32 bit applications are disabled in your App pool.
Solution: To resolve the issue click on Application pools, right click on your Application Pool and select Advance Settings. Set "Enable 32 bit Applications" to be "True". Lastly "Stop" and "Start" Application Pool Tasks.
I am using an SSIS package to get a text file from a secure Unix server. One of the steps in the package ftp's the file to a Windows file share using a Flat File Connection. I have specified the connection using the full path name: \\servername\foldername\filename.
The package runs fine on my development machine; however, I am experiencing a problem when the package runs as a service under SQL Server Agent. This is how it will have to run in Test and Production. The service has been given rights to the server and the folder, but since the folder is a hidden folder it has been appended with a $.
So the actual connection string for the Flat File Connection is: \\servername\foldername$\filename.
Could the dollar sign be causing the problem for SQL Server Agent?
I am running out of ideas and I have almost exhausted my search on the Internet. Stack Overflow is always my last resort. I hope someone can help.
This problem has been resolved. There is no issue.
The job had insufficient permissions. The network administrators told us they had taken care of it, but after we had ruled everything else out, they checked again.
I have a page on the server and i tried to run it like this article:
http://www.eggheadcafe.com/articles/20010328.asp
then I get an error:
Executed as user: NT AUTHORITY\NETWORK SERVICE. The step did not
generate any output. The step failed.
When I try to edit the script I get another error:
Creating an instance of the COM component with CLSID
{AA40D1D6-CAEF-4A56-B9BB-D0D3DC976BA2} from the IClassFactory failed
due to the following error: c001f011.
(Microsoft.SqlServer.ManagedDTS)
When I run the asp page manually it works fine! do you know what can be wrong?
I would apply the most recent service pack for SQL Server both to your server and to the workstation(s) where you use Management Studio. The error you mentioned has been fixed: http://connect.microsoft.com/SQLServer/feedback/details/557402/ssms-can-no-longer-create-or-edit-job-steps
This will fix the problem when you edit the job step in Management Studio. There are some other workarounds (e.g. re-register some DLL, or restart Management Studio), but those are only temporary. You can also disable UAC, but you may have that feature enabled for a reason. The real fix is to apply service packs / cumulative updates to fix the underlying code.
As for the error message from the job, there could be a number of things going on. Who is the owner of the job? Who is the user executing the VBScript? What exactly is the job doing?
I've deployed a SSIS package to my SQL server.
I can run the package fine by connecting to Integration Services in SSMS and right clicking on it and choosing "Run Package"
However, if I schedule the package, it fails.
It tells me to check the logs for information on why, but there is nothing in there...
Any ideas?
(this is my first SSIS package by the way)
I would guess your package is doing something the SQl Server agent deosn't have the rights to do. Often it turns out that the location of file to be imported or the location where the file exported are in directories that are not open to the account that runs the SQL Server Agent.
I also agree woth Raj who said you really need to implement logging. You can;t expect to know why something fails six months down the road if you aren't recording the details of waht is happening with the package. SSIS pacakages can be hard to debug anyway, so you need those logs to know where to start looking.
You have to implement logging to get the details of the error.
In SQL Server Agent, create a new job, configure it to execute the package and under the logging tab, start logging.
Then run the package and you can read the log in the job history.
When you said you have scheduled a job, I assume you used SQL agent. In that case you can right click job and click View History and you can see the error related to job not to the package. For detail error you need to configure logging.