Import job fails with UNC path
We have IM Manager 8.4.13 (build number 8.4.1362) installed with the database installed on another server. Everything works except for the Import Jobs. If "Directory with Import Files" is configured with UNC path, the jobs fails with "The import directory \\servername\directory does not exist or could not be opened correctly." IM Manager service account, account running scheduled tasks, IM Manager server account, and SQL server account all have full access to the directory both locally and through file share access. The job will only start if a local path is configured for "Directory with Import Files", but will fail at step 34 when it tries to load the text file from the temp directory with "Operating system error code 3(The system cannot find the path specified." File and directory exists. I followed http://service1.symantec.com/SUPPORT/ent-gate.nsf/... to configure the job to use UNC path, but of course it doesn't work. UNC path is fine with the "Directory for Files Successfully Imported" and "Directory for Files not Successfully Imported". The XML file is moved into the "Failed" directory so, it can definitely access the path through UNC. The event log entry confirms the file move to the UNC path. Any help would be greatly appreciated.
OS: 2008 R2 (x64) (UAC disabled - not desired, but it is disabled)
SQL: 2008 SP1
Comments
Sounds like you got most of the things right.
I can't tell from the description what else might be going wrong. If you can post or attach the full details of the import history (which you can find in the Administration console) in the export history I may be able to tell more.
When I configure the
When I configure the "Directory with Import Files" with a UNC path, the job doesn't actually start, so there is no job history. In the Application event log, this is being logged:
[IMTrader] [10] 2010:07:06 12:37:19(GMT) [CFileSys:PrepareDirectory] The import directory \\IMPROXY\IMTrader does not exist or could not be opened correctly.
When "Directory with Import Files" is configured for local drive
Here's the results.
It may be that the SQL Server
It may be that the SQL Server does not have access to the UNC path where the import files are located.
The SQL Server database will attempt to upload into iteslf a flat-file of the imported data that goes into the IM Manager tables.
If the account trying to access the import data file doesn't ahve access to the path then you could see these errors. This can happen if the SQL server is using a local service account (and therefore can't access remote locations) to upload datafiles.
A way around this would be to place the import files on the SQL server and make the UNC path from the folder on the SQL Server. A lot of the time that is easy for people to do, as the database server typically has lots of drive space anyway and storing datafiles there isn't an issue.
This type of issue is discussed in this KB:
http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2007587691068698
Another way around this (as talked about in the KB) is to figure out what account the SQL Server is using to try and upload the data with and then make sure that account can resolve that UNC path and has access to the files there.
Not Permission Issue
Like I stated before, if I configure "Directory with Import Files" with a local drive, the task will fail and move the file to the "Directory for Files not Successfully Imported" configured UNC path, which is just a subfolder of the "Directory with Import Files" folder. So, share permissions/folder security is not the issue.
Anyway, I figured it out. I came across something similar with the Blackberry Enterprise Server. The programmers over there in their infinite wisdom does not check their definitive paths and require in the GUI to configure a backslash at the end of the path for the logging folder. The GUI drops the backslash after configuration and shows the same path whether you have the backslash configured or not, and the installation does not check or append a backslash that it needs. So, the workaround is to hack the registry. It's a known problem with their last MR. Bad coding.
As for the latest revision of IM Manager, the problem is that when "Directory with Import Files" is configured with a UNC path, it can NOT be the root of the share. So, in a local SQL installation, a config of D:\Folder would work fine. When in a remote SQL environment where a UNC path is required for the import tasks, merely sharing D:\Folder as \\server\folder is not adequate. You'd have to create a subfolder within the share and configure "Directory with Import Files" with the UNC path to the subfolder: \\server\folder\subfolder. This wasn't stated in any documentation nor does it make sense that the application can not use the root of the share. It is what it is. Hopefully, this will be fixed in future software releases or the documentation updated to reflect this. It would have saved me a LOT of time.
Would you like to reply?
Login or Register to post your comment.