Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!

Alteryx Server Discussions

Find answers, ask questions, and share expertise about Alteryx Server.
SOLVED

Mapped Network Drives for Input, Output, and Macro Repository

wottel
8 - Asteroid

So here is our scenario. We have a VM that our team uses to develop Alteryx workflows. The primary drive on this VM for all inputs, outputs, & our macro repository is the E: drive. (i.e. E:\datateam\macros)

 

We've recently added an Alteryx Server on a separate VM and based on this article https://community.alteryx.com/t5/Alteryx-Server-Knowledge-Base/Sharing-Macros-in-Alteryx-Designer-an... we have mapped the Developer VM Edrive to our Server VM E Drive so that all paths on both machines will be identical. 

 

However, when trying to publish a workflow to our server, the macros & outputs are not recognized. 

 

From the Server VM:

-We are using a service account in our "Run as User" and I've logged in under this account to map the E drive.

-While logged in as the service account, I'm able to navigate to the E Drive and see the folders & macro repository.

-I've mapped the macro repository to this user in designer.

-I can open the workflow that I'm trying to publish and it runs without any errors.

 

So at least in Designer, there appears to be no issues with the mapped drive being recognized. What am I missing? How do I use a mapped drive so that we don't have to redesign our workflows to use full UNC mapping?

5 REPLIES 5
DavidP
17 - Castor
17 - Castor

The answer to your question is in your last sentence - you have to use the UNC path.

 

However, I'm not sure your Alteryx Account Manager will be too happy to hear that you're using Alteryx Designer as a shared resource on a VM - it's against to Alteryx Licence Agreement. A designer licence should be linked to a named user account. One licence, one user.

wottel
8 - Asteroid

Thanks @DavidP , 

So first, let me address the ethical issue you raised. I did confirm we pay for a licenses for all of our users (14 designer licenses) . I don't know the arrangement that was made as this was in place before I came to the company. 

 

But back to the original issue.. and this may not be worded correctly but is the Server Service not programmed to recognize Mapped Drives? 

I just trying to understand the difference between running Designer on the Server VM vs. the Server running a workflow on the Server VM. It would seem that these would work the same way, but there are obviously some differences.  

 

 

DavidP
17 - Castor
17 - Castor

I think the last question in the FAQ of the post you mentioned (Sharing macros in Alteryx Designer and Server) addresses your question:

 

Q. Can I use a mapped network drive to share my organizations macros with Alteryx Designer users and Alteryx Server?

A. As mapped network drives are mapped on a per user basis and do not appear to batch processes, using a mapped network drive will not work for sharing macros with Alteryx Server. It will, however, work if you are only sharing macros between Alteryx Designer users within your organization.

 

Batch processes is the key phrase here. When published apps are run (or scheduled) on server, they are executed as a batch process, which doesn't recognize the mapped drive.

 

I don't think you have to change all your workflows. If you create a network share (\\fileserver\shared folder\) and copy all you macros in there, then set up the relative path in OptionsUser Settings > Edit User Settings and click on the Macros tab on the Designer instance that resides on the Alteryx Server as well as your Alteryx Desktop Designer instances, the macros should be recognized in the workflows you've already built.

 

Another key pint to note from the article is in the 1st question in the FAQ (see underlined bit)

 

Q. When I publish a Workflow to my Alteryx Server environment, do I need to do anything else?

A. No. When you create a macro repository, Alteryx Designer sees macros contained within the directory as a “native macro” and references the macro using relative paths. When you publish the Workflow to Alteryx Server, the macro will continue to be referenced using a relative path based off the repository path defined in your Alteryx Server environment. You can verify that the macro is not being packaged with the workflow by checking the Workflow Options -> Manage Workflow Assets in the Save As dialog window.

 

Hope this helps.

wottel
8 - Asteroid

Thanks so much @DavidP . appreciate your help with this.. 

thedr9wningman
8 - Asteroid

Hi @DavidP :

I have a very similar problem with networked drives and network locations. My main issue is I don't know how to 'force' Alteryx's macro repository to use the network (UNC/\\fileserver\shared folder\) versus the networked location. I've been fighting this for months, especially when employing subdirectories. 

 

Is it the subdirectory that is my problem?

 

Production versus development macro locations: UNC vs Mapped drivesProduction versus development macro locations: UNC vs Mapped drivesAs you can see from the top/highlighted item, I have the path set to a UNC path.

But when I invoke the macro, and then look at its path by opening it up, it sometimes maps to the mapped network drive version of this location (the T:\ drive seen in the second row), and sometimes maps to the UNC. 

 

I'm finding this extraordinarily frustrating and I don't know how to control it. I try re-saving the macro and using the UNC nomenclature, but I will still often get issues. I can't employ these on Gallery until this is fixed. Can someone please help to explain how I can steadfastly get the macro to map to the UNC path?

SIDENOTE: My macros often get 'lost' in the tool palette: I can't find them half the time. They just don't show up. I have monkeyed with the meta info to marginal success on some of these in the past, but the macro I am currently working on does not show up in the tool palette for the life of me. I may have to ask about this issue separately, but if you have an answer off hand... I would be ever so grateful. 

 

Thanks, 

Çædric