We’ve extended Inspire Early Bird Pricing until March 1. Register now and enjoy 20% off conference passes and 10% off training passes. P.S. Don’t forget to bring friends! When you sign up for five or more tickets, you get an extra 20% discount on conference passes. Learn more now.

Alteryx Server Discussions

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

Alteryx server scheduler failing to run on virtual machine server

8 - Asteroid

Hi all, I know there are a few similar threads on this topic but I feel like I've tried most of them without a successful resolution. Hoping a refresh on this question may yield better results.


Situation: I have a workflow sitting on a virtual machine that I log on to via remote desktop. This VM hosts our Alteryx Server where I have a scheduler set up. When I am logged on to the VM, my scheduled workflow runs successfully (either through the Designer, through manual trigger on the Alteryx Gallery, or through a scheduled trigger). When I close my computer, the scheduler fails, giving me the error: Error code: 1: The system could not find the environment option that was entered. (203). Only when I log back into the VM will the scheduler work.


See below:


Example 4.PNG

When I log in to the machine and re-run the scheduled workflow on an external computer (or on the VM Alteryx Gallery browser window), it works fine.


Example 5.PNG


My workflow runs two activities: a macro and and a create .bat file action. My input is a directory to a Sharepoint via One Drive. See below:Example 1.PNG


As you can see below, the .bat file is very simple and simply outputs a CMD command line for where to move the file.


Example 2.PNG





To be clear, the cmd file contents themselves seem fine. When I am running the schedule or manually run the command in cmd.exe, it works.


Perhaps it's an issue with OneDrive/SharePoint or Run As?

ACE Emeritus
ACE Emeritus

What do you have your run as account setup as? 



Joshua Burkhow - Alteryx Ace | Global Alteryx Architect @PwC | Blogger @ AlterTricks
8 - Asteroid

Originally, I had it set up as system default. Yesterday I changed it to Run-As me. I used the domain and login credentials that I used to log on to the VM through Remote Desktop Connection. Didn't work though. See below (I replaced company-sensitive information with different values but the format is the same):


Example 1.png

Example 2.png



All the files are on my VM server desktop except the incoming files, which is located on the company Sharepoint.


When I change the incoming file to a test file on my server desktop, the scheduled workflows runs no problem.


I'm pretty sure at this point this issue is with connecting Alteryx Server on the remote desktop to the Sharepoint which holds my incoming files. Currently, I am connecting via OneDrive.

8 - Asteroid

In absence of a response, I'm just going to assume this solution to a similar problem still stands today in 2020:







@vc at this time we only support connections to SharePoint via the SharePoint List Input and SharePoint List Output connectors included with Designer. As such connections to SharePoint Document Libraries (files and folders) are not supported. This limited support is due to authentication issues that are outside of our control when accessing files resources hosted on SharePoint. These authentication issues typically do not effect manually run workflows, but will cause workflows run from Scheduler or Gallery to fail with an authentication, file/folder not found, or file/folder not accessible error. The root cause of the issue is due to SharePoint incorrectly prompting for credentials even though credentials are provided when accessing the UNC path for the file/folder. To clarify further Scheduler/Gallery runs the workflow as part of the service in session 0 which is a non-interactive session. As such when SharePoint requests credentials in this manner the authentication automatically fails because the credential prompt can't be rendered to the screen or responded to. Based on the information you provided this is the exact issue you are encountering, and the only supported solution to this issue is to store the files you are attempting to access on a standard Windows file share instead of using SharePoint to host the files.