I have sql agent jobs which call certain Stored Procedures based on some condition. The logic was implemented in powershell. Recently all the powershell jobs in sql agent started failing with error message:
The step did not generate any output. Process exit code -2146232576. Anyone have insight on this issue?
Edit:
Around the time the jobs started failing following entries are registered in Windows evenlog setup:
Initiating changes to turn off update MicrosoftWindowsPowerShellV2 of package PowerShell-V2-ServerCore. Client id: DISM Package Manager Provider.
Selectable update MicrosoftWindowsPowerShellV2 of package PowerShell-V2-ServerCore was successfully turned off.
I'm not familair with Operating system level changes.Could anyone interpret what's going on?
The answer is that the SQL Agent is using the PS v2 Engine to execute your scripts and your server admins have disabled PS v2 using DISM. Yes your scripts will work fine in ISE because they almost always are backwards compatible with newer versions of PS 3,4,5,6 etc. The SQL Agent job is running a command before your scripts telling Powershell to use the v2 engine, which the feature is no longer installed.
Related
I have an SSIS package that uses the Execute Process Task to run an application. Running on my local visual studio has no issues. Running it on the server as a job, from the logs, I can see that it just hangs on the EPT step. It never errors or stops.
The old version of the application runs from the same directory as part of a job on a server with no issue. I'm simply just running a new version of the application. It does pass arguments slightly different though.
I log into the server as the SQL Agent service account and run the executable commands from CMD the same as the SSIS package runs it, and it runs fine.
The task is configured with default configurations except for the window is hidden, the same as the old version that works.
I've seen many people have this issue and have tried everything..
I'm assuming that it's prompting me something when it runs on the server. Is there any way to see what it's prompting if I am logged into the server running the job?
I have created a duplicate of the package in our Dev Environment and for that I checked the "Use Proxy" because it would not work with out it. Now the original package in our Production environment is failing with the that error. The original Package is working when ran from our server but when ran as a Job it fails with that error. The new package in the Dev Environment is working. No idea what is going on. I removed the proxy setting for the Dev package and am now waiting to see if it is fixed. Any ideas on what is going on?
This type issue is occurs because when you are running your package at Dev environment then you have all the access but when you run your package through job at Production server then you don't have sufficient access to run the job by your logins.
So better you have to call DBA and ask him to change the job owner for that particular job.
Same issue occurred with me so I have take the help of DBA and change the job owner,Actually when you create job at Dev environment then it's by your logins but at product you don't have access to run or modified a job.
We have a task where we need to automatically convert an excel file to a csv to prep it for loading into a SQL database. The developers built this process into a SSIS package. For the conversion, they initially tried to have a task in the SSIS package execute a VBscript to convert the file. When they were running this on there local machines, this worked correctly. When they ran the package manually through VS on the server, it ran correctly. When they ran the package manually via the Integration Catalog it ran correctly. We did this both as our accounts and as the service account and got the same results. However, when we scheduled it as a job it would hang on the part of the process that executed the VBScript. No errors, it would just hang until you killed the job.
The job was executing as the service account which has full admin access on the server, explicit full access to the share where the files are stored and converted (which is on the same server) and full admin access to SQL. The job owner is set to sa which uses the service account. And all the job does is execute the package from the integration catalog which works if you run it independently of a job. When we compared the ssisdb execution report for the manual run in the integration catalog using the service account to the job run they looked the same except the job hung on the conversion task and the other did not.
After spending some time trying to figure this out, the developers tried a different solution. They changed the conversion script from using VBScript to using C#. They ran the package from there local machine and once again the package worked. This time when they ran it manually on the server it failed. When we ran it from the integration catalog it failed and when we ran it from a job it failed.
The error we keep getting is "Create CSV file: Error: Exception has been thrown by the target of an invocation" After spending several hours looking into this error nothing suggested seems to be working.
We also tried these same solutions on a newly built server to make sure we weren't dealing with an odd configuration setting that could have been changed (It is a Dev server) and it still failed there.
At this point, we are pretty lost at what is happening. The first solution worked, but for some reason would never work as a job. The 2nd solution works everywhere except when ran on the server.
We are looking at some other solutions to try to get around this. The next thing may be trying to using powershell to convert the file, but not sure if that will bring us back to the same issue. Any suggestion you guys have will be greatly appreciated
Also, we are using SQL Server 2012 dev edition, VS 2012 pro, Windows Server 2012 R2
This might be because of a bug that Excel has when trying to run jobs (that use Excel) and no user is logged on a specific machine. This might affect also the excel library. The solution is to create the following 2 folders:
C:\Windows\SysWOW64\config\systemprofile\Desktop
C:\Windows\System32\config\systemprofile\Desktop
and then restart the machine. :)
(Edited to show that a restart is needed. thanks for Dustin for checking this)
I'm working on a domino server version 8.5.3 and I am calling a java agent A that makes another java agent B run on the server. Java agent B references a Java Script Library where most of the code is.
I've chamged the code in the Script Library, saved the script library and the agent separately. There are no compilation errors that I can see.
When I run the code (either directly agent B on the notes cliet or agent A on the server), the old version is running (I know because of a cunning system.out.println()).
It's driving me mad for two hours now. I've tried closing down client and designer, restarting the server, shutting agent manager off and then on, all to no avail.
Is there some magical cache which I could clear?
I solved the problem by starting both the script library and the agent from scratch, renaming everything in the process. What a pain.
We have multiple SSIS packages deployed on a production box. All the scheduled jobs that call these packages run fine.
Whenever I create a new package and try to deploy, I can see the folder structure and deploy fine.
Here is the problem I am facing:
When I log into integration services from SSMS, none of the deployed packages are visible. The tree structure under "Stored Packages" does not expand.
The setup is a 64 bit cluster running SQL 2005 9.0.4226
Any help would be greatly appreciated.
Thanks,
Raj
Just a couple of troubleshooting questions:
Is this problem specific to your machine?
Can you duplicate the problem from another machine?
If you log into the server itself and use its version of SSMS, does it also have the problem?
Have you tried reinstalling SQL Server 2008 on the server?
Are you able to the see File System and MSDB folders under Stored Packages or does it just never expand Stored Packages at all as you implied in your post?
If you run the following queries, do they return any values? The first query should display the list of folders including a Maintenance Plans folder and a blank folder. The second query should show all of your deployed packages if you are relying on server storage.
select *
from msdb.dbo.sysssispackagefolders
select *
from msdb.dbo.sysssispackages