Prev
Next
Forums Integration / Customization S3 Customization/Development

Job fails to kick off FTP script - unable to log in user/startstep failed

 12 Replies
 0 Subscribed to this topic
 17 Subscribed to this forum
Sort:
Author
Messages
CindyW
Veteran Member Send Private Message
Posts: 169
Veteran Member
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 Send Private Message
Posts: 169
Veteran Member
4/4/2012 5:57 PM
Still don't have a resolution to this.  Any ideas....anyone?? 
Greg Moeller
Veteran Member Send Private Message
Posts: 1498
Veteran Member
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 Send Private Message
Posts: 93
Veteran Member
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 Send Private Message
Posts: 169
Veteran Member
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 Send Private Message
Posts: 1498
Veteran Member
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 Send Private Message
Posts: 14
Basic Member
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 Send Private Message
Posts: 479
Veteran Member
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 Send Private Message
Posts: 14
Basic Member
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 Send Private Message
Posts: 479
Veteran Member
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 Send Private Message
Posts: 14
Basic Member
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 Send Private Message
Posts: 14
Basic Member
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 Send Private Message
Posts: 14
Basic Member
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.