Job fails to kick off FTP script

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3291
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1372
Roger French	1315
mark.cook	1244

CindyW

Veteran Member

Posts: 169

3/27/2012 5:03 PM

We moved to a new server this summer, at the time that we upgraded to our current versions.

Apps -ver 9.0.1 MSP#3
Env - 9.0.1.8.221
SQL server 2008

We have a process that we created, which kicks off a script that FTPs our payroll distribution files to another sytem, outside of our firewall. We've used this process for years, and the only issues we had were when the user changed her Lawson account password, we would have to have her come up and change the identity password in Lawson Security, otherwise she would get an error and the job would not complete. The error was the  "unable to log in xxxxxx startstep failed" variety. This is from the log file (with the domain\account name changed).

ftpva600 Started . . . .: Tue Mar 27 12:03:54 2012
Token Command. . . . . .: cmd.exe /c "%GENDIR%/scripts/ftpVA600.bat"
   execjob(laStartProcess): Unable to log in domain\useraccountname
   StartStep failed: The operation completed successfully."

So, before we upgraded, that is how we handled it, and that worked fine.   However, since we upgraded, our former solution no longer does the trick. The user(s) have to notify us to kick off the job for them. The weird thing is....that the development team CAN run the job just fine....no errors.
We've tried everything we can think of...changed security every which way, added full rights to the server folder, everything. And still, the users get the error, and we (dev team) do not.

Anyone have any ideas as to where else we should look? We're stumped.

CindyW

Veteran Member

Posts: 169

4/4/2012 5:57 PM

Still don't have a resolution to this. Any ideas....anyone??

Greg Moeller

Veteran Member

Posts: 1498

4/19/2012 3:26 PM

Does the job work with Lawson Security off for the normal users? If so, it would point to a security issue.

This_Guy

Veteran Member

Posts: 93

4/12/2013 1:49 PM

We're having a very similar issue - with some very basic KSH importdb scripts failing to run on our new Windows 2008 64bit servers:
BEGIN: Job Submitted: Fri Apr 12 07:43:26 2013

Step 1: epicglimp Started. . . .: Fri Apr 12 07:43:26 2013
Token Command. . . . . .: S:\lawprod\gen\bin\zzepicglimp
execjob(laStartProcess): CreateChild failed S:\lawprod\gen\bin\zzepicglimp Executable Command . . .: S:\law
Process ID . . . . . . .: -1
Program Messages:
StartStep failed: The operation completed successfully.

Any help would be greatly appreciated! Running this every morning from a command prompt is a PAIN IN THE BUTT!

CindyW

Veteran Member

Posts: 169

4/29/2013 4:18 PM

Since this thread just sort of got "reactivated", I just noticed your reply to me from 2012, Greg. Since this is our production environment, and the FTP batchs always need to be sent during the day by the payroll staff, there is just no way that we could try turning security off. But nothing has changed, security-wise, in our setup. It was just moving to the new server when the problem appeared.

Greg Moeller

Veteran Member

Posts: 1498

4/30/2013 8:03 PM

Are you able to run the script (bat file) in compatibility mode? Select bat file | right-click | properties | Compatibility tab Check box for 'Run this program...' | Select the server that you were running before, or maybe another choice. and optionally 'Change settings for all users' ?

cpaine216

Basic Member

Posts: 14

9/12/2014 12:53 PM

We are on Lawson 9.0.1.11 on windows 2008 with Lawson Security 9 and we are having issues with individuals running jobs that call ftp scripts like below. They are getting the message: execjob(laStartProcess): Unable to log in

Kwane McNeal

Veteran Member

Posts: 479

9/12/2014 1:41 PM

cpaine216,
Mostly likely either one of the following three issues has occurred:
1) The BatchUser (see lajs.cfg) has been locked out, disabled, or the password expired.
2) The OU for said user has possible changed, or the user has been deleted in AD (or other enterprise directory).
3) The NTID has possible changed (user sAMAccountName changed is one way)

...in every case, you'll need to look into your enterprise directory (usually AD for Windows clients) for some triggering change event.

Kwane
505-433-7744

cpaine216

Basic Member

Posts: 14

9/12/2014 7:48 PM

We have verified this and even put our batch user in all the group policy spots it would need to be in for running batch jobs. Our batch privileged ID is lawbatprd - we can log into portal with that ID and run CU201 no problem

Kwane McNeal

Veteran Member

Posts: 479

9/12/2014 10:28 PM

cpaine216,
Without a fair bit of info about your FTP script, it's hard to say exactly what is going on.

Kwane

cpaine216

Basic Member

Posts: 14

9/13/2014 12:01 AM

Our script is a script that on the operating system and it goes out to a third-party vendor gets a file brings it back it's a korn shell script run in MKS Toolkit

cpaine216

Basic Member

Posts: 14

9/13/2014 12:04 AM

Myself and another guy that are administrators does can run it fine we have the batch ID configured in the identities properly we can login with that ID and run jobs but anyone running batch jobs can't run the FTP script and everyone is using LSF nine security

cpaine216

Basic Member

Posts: 14

9/15/2014 1:28 PM

Another note is this job uses a tokendef to determine the kornshell to run and we have given the people access to that tokendef in LSF 9 security.