April 8, 2016 at 9:23 am
ttdeveloper (4/8/2016)
Out of curiosity what OS is your server running on?
Windows Server 2012 (I think R2) 64bit.
Thanks for the link. I'll check it out.
April 8, 2016 at 9:25 am
Brandie Tarvin (4/8/2016)
ttdeveloper (4/8/2016)
Out of curiosity what OS is your server running on?Windows Server 2012 (I think R2) 64bit.
Thanks for the link. I'll check it out.
Unfortunately we've already done that, triple checked it, even went in and added the individual users (outside the groups) to try it. We're still getting the error messages.
April 8, 2016 at 9:29 am
Unfortunately we've already done that
And by this you mean the service account that's calling the agent jobs correct?
Wow - if so, then to be honest SQL Server 2012 is sure an interesting one...Ill test it with a proxy ensuring the proxy has access to SSIS package execution. At this stage, its all about ruling out failure causes.
Sorry couldn't help any further
April 8, 2016 at 9:51 am
Brandie Tarvin (4/8/2016)
Manic Star (4/8/2016)
If you are storing your packages in MSDB, you could try exporting them to the file system somewhere local on the server and switching the sql agent job to call them from the file system.I've been mulling that over. We were doing File System on the old servers, but when I updated the jobs, I made sure to get the command line from a faux IS step and copied over the old dtexec.exe command line.
So, yeah. It's the one thing we haven't tried yet.
Have you tried creating a completely new job to call one of the packages stored either on the file system or in the msdb? From scratch so to speak.
I'm thinking maybe your SQL agent jobs are malformed somehow and you're not able to see where the disconnect is.
I would verify that a) you can run sql agent jobs of any sort b) if a checks out, create a brand-new job calling one of the packages you can run manually, schedule it and see if it errors or not. If this works, it may be a problem with your scripting and import process from old to new. I had lots of fun with DTUTIL importing jobs from my old server to my new ones. A few things just didn't work right and had to be recreated.
April 8, 2016 at 11:18 am
ttdeveloper (4/8/2016)
Unfortunately we've already done that
And by this you mean the service account that's calling the agent jobs correct?
And our DBA user account group just for kicks and giggles.
Wow - if so, then to be honest SQL Server 2012 is sure an interesting one...Ill test it with a proxy ensuring the proxy has access to SSIS package execution. At this stage, its all about ruling out failure causes.
Sorry couldn't help any further
Thanks for trying.
Manic Star (4/8/2016)
Have you tried creating a completely new job to call one of the packages stored either on the file system or in the msdb? From scratch so to speak.
I was going to say "no" until I realized I did exactly that so my coworker and I wouldn't butt heads trying to call the same job. We're both getting the exact same failures. On the other hand, I did cut-n-paste the command line from the old job, so maybe I'll drop my job and try again. I don't expect it to change anything, though.
Manic Star (4/8/2016)
I would verify that a) you can run sql agent jobs of any sort b) if a checks out, create a brand-new job calling one of the packages you can run manually, schedule it and see if it errors or not. If this works, it may be a problem with your scripting and import process from old to new. I had lots of fun with DTUTIL importing jobs from my old server to my new ones. A few things just didn't work right and had to be recreated.
We actually have a couple of non-SSIS packages that are already running on a schedule every 15 minutes. They're going fine. None of the SSIS jobs are running, though. And as I said earlier, we can run those packages just fine through the GUI.
When you say you had fun with DTUTIL, could you be more specific? My coworker thinks that's where the issue is.
April 8, 2016 at 11:49 am
Brandie,
A couple of things:
1. How did you deploy the packages to msdb? I haven't used msdb with 2012 as we are using the project deployment model, but I do know if you deploy using the 2014 deployment wizard it upgrades the packages silently.
2. When you copy and pasted the step for the job where did it come from? I've had issues with copy and paste having invalid characters especially when pasting from Word into a job step and you can't see it in the job step, but you can in the query editor in SSMS.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
April 8, 2016 at 11:56 am
Oh for freakin' heaven's sake.
After everything we've done and gone through, including restarting services and rebooting the server twice...
There were a couple of issues I could have prevented. When I scripted the jobs from 2k8, I created them on 2k12 IN 2k8... I think this is a huge part of why it didn't work.
I created a copy of one of the jobs from scratch (as suggested, thank you) and used SSIS steps instead of command steps. It worked perfectly once I stopped referencing the output file with the server name\share and used the drive letter\drive path. So I scripted that job out and followed what it was using for the SSIS steps to fix all the other jobs.
Once I corrected the command line and changed the step to SSIS with a find and replace, then dropped and recreated the job using SSMS 2012 (instead of 2008), the silly thing worked.
Sigh...
Future advice to self and all others, don't use older versions of SSMS to create your jobs... You know, just in case.
April 8, 2016 at 11:58 am
Jack Corbett (4/8/2016)
Brandie,A couple of things:
1. How did you deploy the packages to msdb? I haven't used msdb with 2012 as we are using the project deployment model, but I do know if you deploy using the 2014 deployment wizard it upgrades the packages silently.
2. When you copy and pasted the step for the job where did it come from? I've had issues with copy and paste having invalid characters especially when pasting from Word into a job step and you can't see it in the job step, but you can in the query editor in SSMS.
I uploaded the packages to MSDB manually, by hand because there were old ones we didn't want getting up there.
I copied-n-pasted from the other job step. I know what you mean about Word. I can't use Word for anything anymore. I paste everything that's not going SQL to SQL into Notepad before it goes into SQL.
And I still can't get the command line calls to work, but at this point if I can script out SSIS steps, I'm not caring so much. I don't want to go into every job and make the change manually if I don't have to.
April 8, 2016 at 12:01 pm
Glad you fixed it!
Our main problem with DTUTIL was spaces in our job names, package names etc. It just flaked out on a few of them and i got tired of troubleshooting it and did those few kick-outs manually.
FWIW, I first upgraded all of my 2k8 SSIS packages to 2014 by importing them into a BIDS project for that purpose. I ended up using DTUTIL to import the bulk of them after they were converted. The ones it managed to actually import worked fine.
Looking back on it, i should have just deployed them from BIDS to the new server, but i had a script already built and i was lazy...
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply