IPA File Access

I'm not sure if anyone has the answer to this but I would appreciate any help in resolving it.

I am attempting to access a file on our Windows share that the Lawson network account does not have access to. I am able to login to IPD as another user that does have access and am able to see the file exists via file access. I even performed the flow on the Landmark server (logged in as Lawson) in IPD (logged in as the user with access). However, once I schedule the flow or trigger it from rich client using either the Lawson account or the other account it fails saying the file is not there.

Are scheduled/triggered flows run using the Lawson user credentials? Is there some place I can set/change this? Is there another means of accessing the file? I am not using FTP currently as I believe it is locked down on our network (that's a separate issue).

Any help regarding understanding of this is appreciated.

Thanks,

Kyle

Find more posts tagged with

Comments

Legacy Contributor

Many factors, however start with what is the actual account being used. Use a blank System Command configuration. My Main configuration does not have entries on the File Access and System Command. Then on your ipa, add syscommand whoami and/or whoami > whoami_out.txt. Run in the server and see what account is being used. The whoami > whoami_out.txt in my landmark server is saved to C:WindowsSystem32whoami_out.txt

russel-cornelson

"I am attempting to access a file on our Windows share that the Lawson network account does not have access to"

----That is the problem that you will need to resolve.

Is the file/share on a non-Infor Lawson server? Not LSF, Not Landmark?

Legacy Contributor

Thank you - It looks like both in the designer and when run via rich client the Lawson user is the one running the process, which is what I was thinking.

I'm just unsure why the process will find the file in the designer then but not when 'scheduled'.

Legacy Contributor

The file is on a non-Infor Lawson server. I have no issues accessing files on LSF and Landmark. There are directories on the share that Lawson has access to that I am able to get working. There is one that Lawson does not have access to that I cannot get working outside of the designer.

russel-cornelson

- When running from the designer, the java process trying to access the share = the user you are logged into the PC as.

- When running on the server, the java process trying to access the share = the user that owns runs the grid process.

From the Landmark server, goto windows services (start > run > services.msc); find the Windows Service for Grid and right-click it, choose properties and see which user is configured to "Log on As"

v10 Windows service = GridAgent

v11 Windows service = InforIONGrid

Chances are it is running as the "local" lawson user that is created during Landmark installation. You can change this to run as a domain/lawson user which probably has network share access (check with network admin). If you pursue that change it would be:

1. Login to landmark server as domainlawson user; ensure the domain account is an administrator and that administrators have full access to the file system.

2. Run the following from command prompt:

wmic useraccount where name='lawson' get domain,name,sid

**can take a few minutes for this to run, be patient

3. From landmark command prompt:

secadm provision os -Coa

4. Open Rich Client, goto GEN dataarea, and open the "IdentityActor" business class by searching for it in top right corner. Filter this page on the SERVICE=<LandmarkServerName>

5. There should be two identities tied to the lawson actor for this service, delete the one that contains the SID from the local lawson account (see results from step 2) and leave the domain account here.

6. From Landmark Command Prompt

stoplaw

adminlaw

startlaw

stop/start WebSphere Application server.

Your system would now be running as a DOMAIN account, which can be granted Network Share access to any server on your network.

russel-cornelson

NOTE: If that's true someone with NTFS security might just need to grant the lawson user access to that server share.

Legacy Contributor

I think that may be the case as the Grid service is being run by the domain account. However, both SIDs are in GEN (this was causing an issue where the Lawson account cannot schedule flows and I wasn't sure which SID was the correct one to keep, so thank you).

It looks like in the designer and the scheduled flow that the domain Lawson account is the one running things.

If this is the case then the Lawson account will always need access to things? I'd been guessing that there's no way to change what 'user' is running the processes and this seems to confirm that.

I have a bit of Lawson experience but basically no Windows experience so this helped a great deal.

Thank you.

JD Miller

One Option that hasn't been discussed yet is that you can setup a shared drive using any network user you want the system to use. We have a IPA network user.

You need to run a syscmd node using the run cmd.exe execution mode. the command is:

net use <!DriveLetter>: \<!SharedDriveLocation> /user:<!Domain><!User> <!Password>

The downside to this is you'll have a password listed on a file (the .lpd file) or in a batch file if you choose to put the above command in a batch file and run the batch file from the syscmd node.

Another issue you'll run into, is any time the Landmark server restarts, the shared drive is gone. The shared drive is also not available for use outside of Landmark, even if the same user is logged onto the Landmark server.

Legacy Contributor

Thanks! This also helps. I thought this might be possible, but was unsure of the syntax. I think I'll attempt to get Lawson access and use this option as a backup.

russel-cornelson

If you opt to leverage "net use" I highly recommend actually using IPA's system command to execute a powershell script. That way you can save the user/password for the network share in an encrypted file which the powershell script uses to establish the connection.

I. Creating an encrypted file via powershell script

param([string]$myPass)

try

{

$SecureString = ConvertTo-SecureString $myPass -AsPlainText -Force

$EncryptedPass = ConvertFrom-SecureString -SecureString $SecureString

Set-Content -Path C:Userslawson.sshmypassword.key -Value $EncryptedPass

}

catch

{

return 10

}

return -1

II. Decrypting the file via powershell

function Decrypt([string]$passwordfile)

{

$securedstring = ConvertTo-SecureString $passwordfile

$helper = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $securedstring

$global:password = $helper.GetNetworkCredential().Password

}

III. Mapping the Drive via powershell

try {

Log-Message "Establish Network Drive Connection..."

net use $sharePath $global:password /USER:$username

if ($LASTEXITCODE -eq 0) {

Log-Message ("Network Drive Connection Established to " + $printSharePath)

} else {

throw $error[0].Exception

}

}

catch [Exception]{

Log-Message ("Failed to establish network drive to " + $printSharePath)

Log-Message ("Error:" + $error[0].Exception.GetType().FullName)

Log-Message ("Exception:" + $_.Exception.Message)

Log-Message "-------PRINT FAILED Error 001-------"

exit 1

}

IV. Disconnecting the drive via powershell

try {

Log-Message "Disconnect Network Drive..."

net use $printSharePath /DELETE

if ($LASTEXITCODE -eq 0) {

Log-Message "Network Drive Disconnected."

}

}

catch [Exception]{

Log-Message "Failed to disconnect network drive."

Log-Message ("Error:" + $error[0].Exception.GetType().FullName)

Log-Message ("Exception:" + $_.Exception.Message)

Log-Message "-------PRINT FAILED Error 003-------"

exit 3

}

NOTE: If you purse this option; please ensure the following:

1. That you CATCH and handle all exceptions that occur during the execution so the decrypted password can't be written during an error.

2. You save the password in encrypted file so it's not readable by anyone else on the server

I've also successfully leveraged reason codes and reason comments to create a flow that allows you to update the encrypted password for when the network password changes. This is a more elegant option because your network password isn't exposed in plain text in any files.

I would ONLY recommend this strategy as a last resort. NOTE: if you have a network printer with a share than can handle PDF files this can also be leveraged to send landmark print reports to a printer.

Copyright © 2025 Infor. All rights reserved.