Whether you like it or not, there’s no denying that the world runs on Windows. And Windows, just like any other application, evolves over time, introducing or deprecating features and functionalities to better meet the needs of its massive consumer base. These functionalities can have a significant impact on other applications that run on top of Windows. In this series, we’ll look at a few of these impacts as they relate to OL Connect.

To share or to map?

OL Connect generates and distributes a lot of files: PDFs, printer spool files, HTML pages, bitmaps, temporary files… the list goes on and on. These files can be stored locally but in many environments they have to be stored in a shared location so that other applications or users can access them without having to connect directly to the OL Connect server.

At Objectif Lune, we have a slew of shared locations that are used to archive or exchange files. Some of those locations are restricted to a few departments or individuals, while others are open to all employees. As soon as we log on to our corporate PC, we get a T: drive, where we can read and write temporary files. An S: drive contains corporate documents that most of us can read from, but only a few of us can write to. We even used to have our own personal H: drive where we could all store any file that we didn’t want to share with anyone, but that was eliminated when we switched to OneDrive.

The nice thing about those shared drives is that your permissions depend on the credentials you use when you log in to Windows. If one of my colleagues logs in on my machine, using their own credentials, their permissions on the S: and T: drive won’t necessarily be the same as mine.

Shared drives in OL Connect Workflow

OL Connect Workflow is a service that runs under a certain set of user credentials. But contrary to a living, breathing user, it doesn’t actually log on to Windows. It simply runs using the credentials you have assigned to it. Therefore, even if the service runs using my corporate credentials, none of my shared drives will be available because I have not actually logged into the system. So by default, Workflow won’t be able to access anything on the T: drive because it was never mapped as part of a login process.

Fortunately, the solution is simple: you can dynamically map the drive in Workflow’s Startup process, which runs before any other process, thereby ensuring that all processes have access to the drive when they need it. You can use the Run External Program task to do so, but a Script task is just as easy and allows you to map several drives at once:

var net = new ActiveXObject("WScript.Network");
net.MapNetworkDrive("T:", "\\\\OL_SERVER\\Temp", true, USERNAME, PWD);
net.MapNetworkDrive("S:", "\\\\OL_SERVER_2\\Share", true, USERNAME, PWD);

Using that script, all my usual corporate drives are available to Workflow, with the same permissions that I have when I log on to Windows interactively.

NOTE: some of the more seasoned readers may recall that in a distant past, we used to discourage the use of shared drives because Windows’ notification system – on which Workflow relies to be notified of new files coming in – wasn’t as robust for shared drives as it was for local drives. That is no longer true: Windows does a great job of informing Workflow when new files are dropped in a shared folder.

Why not use UNC’s instead?

The UNC path is the actual location of the shared folder. For instance, in the script example above, drive T: is mapped to UNC path \\OL_SERVER\Temp (the doubled-up backslashes in the script are for escaping the \ character, which is reserved in JavaScript). So why use mapped drives, then? Couldn’t we just use the UNC path in any of Workflow’s tasks instead of having to map a drive?

Well yes… and no.

Remember how I already stated that the Workflow service doesn’t actually log on to Windows, it just runs using a set of credentials. Since it isn’t logged on, any time it accesses a shared location it must authenticate its credentials with the server it is trying to access. And while this authentication process is usually relatively fast, it may sometimes introduce a significant delay in Workflow’s operations. Imagine for a second that your Workflow process is splitting a large PDF file into thousands of smaller PDFs that have to be stored on a shared folder. Each split only requires a few milliseconds but if the authentication process requires half a second each time a file is saved, your process that used to run in seconds may take hours to complete, just because of the repeated authentication!

NOTE: Windows does cache authentication information, so it won’t actually incur a delay with every single file. But the cache size is finite, and if you have several processes running simultaneously then there’s no way of knowing if Windows will “remember” the authentication when the next access to the shared location occurs.

ADDITIONAL NOTE: in many instances, authentication of credentials is routed to an Active Directory server, which means that before you can write to a shared folder, you must first contact yet another server to obtain permission. It’s in these types of environments that we’ve sometimes witnessed delays of several seconds before the service is allowed to write its file. In certain extreme cases, we have seen time-out issues occurring because one of the servers failed to respond in a timely fashion.

By contrast, a mapped drive requires a single authentication: at the moment of mapping it (i.e. during the execution of the script above). Which kind of makes sense: if you were able to connect the drive to a shared folder to start with, that means you had the proper credentials. Therefore, Windows will no longer waste time authenticating accesses to the mapped drive because it already knows you are allowed to use it.

Wrap-up

Hopefully, this article has helped you understand the difference between mapped drives and UNC paths, and how each of them can have an impact on your OL Connect Workflow operations. Unless you have a very specific use case that prevents you from using them (would love to hear about that in the comments!), you should always privilege mapped drives over UNC paths.

In our next chapter, we’ll look at how upgrading to a new Windows version can impact your existing OL Connect implementation.