I am having issues with accessing mapped drives when I want or to open existing template or datamapper or to start new datamaper and choose files.
I have several mapped drives but it shows me only one.
What could be the problem and how to solve it?
I have installed latest version of Connect Designer on a new computer yesterday so everything is up to date.
I would appreciate any help. Following pic shows compared options when I open dialogue box in connect (to the left) and windows explorer (to the right )
I think this behavior is dictated by Windows itself. The “Open File…” dialog box in OL Connect is requesting infos from Windows, and that’s what gets displayed.
I have a feeling that the missing drives are drives that have been declared but not accessed yet during your Windows session. To test that out, try the following:
Exit from OL Connect Designer
Open Windows File Explorer and click on one or two of those drives to have Windows fetch the list of files from the remote servers.
Open OL Connect Designer again and see if those drives that you just accessed now show up.
@Ivan Network drives are a major pain in Connect. Don’t let OL support tell you it’s a “Windows problem”, that cannot be the case. PlanetPress Suite 7 was able to work with mapped network drives for 15 years without any problem whatsoever in our use case and since we switched to Connect this suddenly is a problem. This does not look like a Windows problem to me, it definitely looks like … “questionable implementation” in Connect.
Since UNCs are not an option we had to jump through unnecessary hoops like moving data from a network drive to a local drive, which of course is only a (very bad) workaround.
It is regardless if the drives were mapped using the same user context Connect is running on, it still does not work. We even create the mapped network drives in Workflow every time the servers starts to make sure they are in the same user context as Connect, but still there are problems. This is a problem that Objectif Lune failed to address for years.
@Xanathon Thank you for your reply.
I was doing a lot of research and tried different things and finnaly I have found a solution, at least for my issue. You can try it, but I do not will it work for you.
Follow instructions on this link and method 1 worked for me. Fix Windows 10 Mapped Drives Not Showing in Programs – TechCult
Thanks for the link, @Ivan, but we fiddled with this for a very long time and ruled out a lot of those solutions already or they do not apply to our work environment.
The user creating the networked drives has admin rights. The networked drives show up and work in all other applications just fine, the only problematic software is Connect, so I do not believe this is a Windows problem in our case. If that were so, other software would be affected.
Also one of the local supporters already admitted that Connect has problems with networked drives mapped to a Windows drive.
But do you have the same problems @Ivan has (not all mapped drives are shown in Connect)? Or do you have problems while using the client-server print process in Connect?
These are two different problems and technically the second one is a Windows problem, because Windows prevents services from using mapped drives (in simple words). In the client-server environment the Connect template will be send from client to server and if you use mapped drives in your template the Connect service cannot reach that mapped drive.
There are planty of articles from Microsoft and others to that problem.
PS: Microsoft themself recommend using UNC paths. We also struggled with that Connect limitation in the first place, but it is easy to change the internal workflow (how the users work). Just configure the network access correct and than users could pin the most used network paths as quick access (“Schnellzugriff” in german). In that case users have the same easy way to select folders/files, because in Connect the quick access folders will also be shown.
As I said: We researched and tried a lot of things regarding this problem and it definitely is not a Windows problem in our case. It also is not a user rights problem (the services run under the correct user context). PlanetPress is used in a complex environment where not only Connect uses these mapped drives but also other applications. If we change this to UNC in Connect we would have to also change that in quite some other applications that work perfectly fine with networked drives, and that would be A LOT of work (we are not talking a vendor’s tray scope here, the company ships thousands of packages every day). This is not a Windows problem and this is also not a user rights problem, we ruled that out a long time ago. As I said: Not a single application has problems using mapped drives, only Objectiv Lune Connect. Even Workflow works with mapped drives, just Datamapper/Designer and the corresponding Workflow steps have problems with it.
One problem example is that you cannot import image resources on the fly in Designer from a mapped drive.
This all is fully automated (or should be) so “the users” also are not a problem.
We have already started to migrate non-document workflows to NodeRED due to the limitations of the 32-bit Workflow application. That also works flawlessly with mapped drives.
