Skip to main content
Question

ETM Import - Directory - Source Config

  • April 6, 2023
  • 3 replies
  • 68 views

Can I use a network drive as the source configuration directory for an ETM import rather than a local folder?  I keep getting an error so I was hoping there was a workaround or config setting to allow this.  I need a 3rd party to drop a file in a network folder so ETM can kick off it’s usually processing of an import file.  Is there any other simple solution for this?
Thanks!

T
 

 

3 replies

Forum|alt.badge.img+12
  • Hero (Customer)
  • April 6, 2023

We have used the importtool.ps1 PowerShell script to import from a network location before. Mine ran off a scheduled task which checked for the presence of a file and uploaded as necessary.


Forum|alt.badge.img+10

I know this is an older thread, but I wanted to share an approach that worked for me recently in our on-prem ETM.

I’ve also used PowerShell, but in my case I created a symbolic link from a local ETM drop folder to a network share. For example:

New-Item -ItemType SymbolicLink -path "D:\Local ETM Drop Folder" -target "\\server\ETM Drop Folder"

After creating the link, I had to update the assystIPaaS service’s account in services.msc (Properties → Log On), replacing the default Local System Account with a service user that has been given read/write permissions on the network share.

Once the service was restarted, I was able to configure a channel to point to the local folder (D:\Local ETM Drop Folder), and ETM processed the files located on the network share via the symbolic link.

 

I’m not an expert in this area, so there may be caveats, but using a symbolic link has atleast worked for me in initial feasibility testing. This was on ETM 1.11.1, so I’m not sure whether this behavior has been introduced or improved since the original question was posted.


Forum|alt.badge.img+10

Slight addendum:

It turns out that using a SymbolicLink wasn’t necessary in my initial feasibility testing with ETM 1.11.1. Further testing shows that network locations appear to work in Directory source channels as in earlier versions as well (tested on 1.8.0), as long as the account running the IPaaS service has read/write access to the network share.

In our case, the issue wasn’t ETM itself, but rather that the IPaaS service was running under the Local System account, which didn’t have the required permissions. I’m not sure if this is the same situation you, ​@TMurphyNS, were encountering when you first raised the question, but thought it was worth mentioning.