Tidal job with UNC path configuration

[mahendirann1@michigan.gov]

Hello,

We have created an exe that combine multiple files to one single file. The file-combine exe is using a config file that has the source path of the files to be combined and the destination path of where the combined file needs to be created.

The file-combine exe is executed using a tidal job on the tidal apps server which has the tidal agent. The file-combine exe's  source path and the destination path are on  remote server. so UNC path is specified in the config file. The job to execute the exe is configured to use a runtime user and the user is given full permission on the remote source path and the destination path.

When we run the job we keep getting logon failure error.

Unhandled Exception: System.IO.IOException: Logon failure: unknown user name or bad password.

When we execute the exe manually using the runtime user account that is confgured, it works. When we give the source and destination folder as local path also it works. Do know why the tidal scheduler is failing for UNC path.

Any help on this is truly appreciated.

[Cale Montgomery]

Has that Runtime User ever worked with any other Tidal job?  Remember that passwords are case sensitive, and I believe that the user name itself might be as well.  My first suggestion would be to verify that the Runtime User is configured correctly in Tidal -- just to eliminate that as a possibility if nothing else.

[mahendirann1@michigan.gov]

Thank you for your response. We did try to run other job using the same runtime user and it works. It's just this exe execution on files over UNC path creates the issue.

[Cale Montgomery]

What's the nature of your .EXE?  Can you add tracing/logging to denote before and after the execution of each step?  I'd like to know if Tidal is failing just trying to run the .EXE, if it fails when it hits the first UNC, or if there's a specific UNC that it doesn't like.

May I ask a few additional questions to learn how you've ran this so far...?

It sounds like you can log onto the server which contains the .EXE, using the same RT_User as in Tidal, and run fine with the UNCs.  What's your positioning when you run the .EXE?  Any particular location on the same server?  Have you tried a manual execution from a neighboring server using the same RT_User?

It also sounds like Tidal works just fine if you replace the UNCs with local paths (which I read to mean network drive mappings...)  That certainly would strike me as Tidal having difficulty resolving UNCs, at least across servers.

Have you tried setting your Tidal job to use a Working Directory that mimics how you were able to successfully run the .EXE by hand?

And, out of desperation, is the Agent for this misbehaving job set up properly?

[mahendirann1@michigan.gov · Accepted solution]

Hello,

Truly appreciate your interest in helping me out. I solved the issue yesterday evening. It looks like the Tidal though we specify a runtime user to execute the exe in the job configuration, it does not execute the exe as that user. It executes only as the agent user account. In my case the, the agent user was configured as local user and that's the reason it could not access the UNC path. When I changed the agent user to a windows AD account, it worked.



It's weird that the job configuration has the ability to specify a runtime user but still it runs under the agent user account. I think Cisco needs to fix this issue.



Thank you for your time!

[Cale Montgomery]

Partial credit for my final depsperation query!

That is weird.  We don't have users associated with any of our Windows agents.  I wonder if leaving that field blank forces Tidal to pull all permissions from the job's RT?

[mahendirann1@michigan.gov]

That's interesting. So if there was no account specified in the Tidal Agent, were you able to run the Exe on UNC path by just specifying the run time user in the job configuration?

[Cale Montgomery]

I couldn't swear that we can on an .EXE like yours, but we do have a very similar .VBS which pulls UNCs from a configuration file.  That job uses a Windows Agent without an associated user and works just fine.  All permissions seem to be coming from the job's RT, and the script itself is also located through the passing of a UNC in a parm to cscript.exe

The developer seems to have made sloppy use of pipes which tend to fail a great deal, but that doesn't seem to be related to the lack of local pathing.

I am having problems getting File Dependencies to work without resorting to local paths, however.  'Not entirely sure what's up with that.

[mahendirann1@michigan.gov]

Hello,

I tried configuring a tidal agent that is running on local system account and was able to access the UNC path. But it was trying to access through the machine's network account <machinename>$. So the finding was the runtime user is not considered by tidal and it always uses only the tidal agent's account.