alteryx server Knowledge Base

How To: Update the Time Zone Database for the Alteryx Gallery   In the Alteryx Server 2019.3 release, we introduced the ability for users of the Alteryx Gallery to set the time zone they work out of.  This created the ability for users to schedule their Gallery workflows to execute according to their time zone, rather than the Alteryx Server's.  As countries may decide to update the current time zone they are in, this can cause scheduled workflows to run outside of the time they were set.  The following "How-To" article provides our procedure for updating your Alteryx Server instance with updated time zone data.   Prerequisites   Product - Alteryx Server 2019.3+   Procedure   Stop the AlteryxService Note: If on a multi-node deployment, stop the service on each server in the recommended order: 1. Gallery nodes 2. Worker nodes 3. Controller node Download the latest Data Only Distribution Time Zone Database from https://www.iana.org/time-zones  Extract the downloaded file to a folder on the Desktop Rename the extracted folder from tzdata<version> to tzdata Open a web browser and go to https://github.com/unicode-org/cldr/blob/master/common/supplemental/windowsZones.xml  Right click the Raw button found above and to the right of the actual XML document and click Save link as Save the windowsZones.xml file into the tzdata folder on your Desktop Open a Windows File Browser and navigate to the Alteryx RuntimeData directory. On a default installation this will be found in C:\Program Files\Alteryx\bin\RuntimeData Rename the tzdata folder in this directory to tzdataBackup Copy the extracted tzdata folder from your Desktop into the RuntimeData directory. If you have set up a multi-node deployment repeat steps 2 - 10 on all Alteryx Nodes Restart the AlteryxService Note: If on a multi-node deployment, start the service on each server in the opposite order: 1. Controller node 2. Worker nodes 3. Gallery nodes   Additional Resources   DST changes in Windows for Brazil and Morocco  Alteryx Server 2019.3 Release Notes 

The  Alteryx License Server  is an implementation of our technology partner  Flexera Software ’s  Local License Server , and allows for the deployment of a local license server within an organizations’ internal network. This allows for a smoother and more secure deployment of Alteryx products, especially behind proxies and firewalls.

Troubleshooting: Blank screen when configuring SAML authentication   In some cases you set up SAML configuration on Identity Provider (IDP) side as well as on Alteryx Gallery correctly, yet when you go through Alteryx System Settings the SAML authentication configuration will fail and show a blank logon window instead of redirecting you to the IDP's logon page.    Environment   Alteryx Server Version 2018.2+ SAML Authentication for Gallery Identity Provider (third party app)   Issue   When configuring the System Settings for Gallery Authentication, when you click the Verify button it causes a blank screen to show up:     After clicking out of the pop up window you will see the below message.   Success! Default curator set to: undefined       Cause   The window is being prevented from showing the logon page for the chosen Identity Provider. Certain settings on the server machine can cause this, including but not limited to: Javascript is disabled Internet Explorer Enhanced Security Configuration is enabled The Identity Provider's URL (IDP URL in Alteryx System Settings - Gallery - Authentication) is not trusted (i.e. it has not been added to your Trusted Site List on the Gallery machine)   Solution   The Verify button is used to set the Default Gallery Curator - the user who logs in on this window in will populate this field in System Settings. Since the window is not showing due to one of the above causes, following the below steps as a workaround will manually set the Curator and enable you to continue to go through the System Settings.   Configure the System Settings Gallery > Authentication page. Set the Authentication Type to SAML Authentication and fill in the required fields.  Briefly switch the Authentication Type to Built-in. This will grey out the SAML fields, but keep the values you entered. The Default Gallery Administrator section is now available. Type in the user's email address. Switch the Authentication Type back to SAML authentication Click Next button and continue through the System Settings   Example:     Once you continue through the System Settings, you should be able to log on to your Gallery via your Identity Provider.   As always if you encounter issues, please refer to the articles for setting up SAML below, or reach out to Alteryx Customer Support if you get stuck.   Additional Resources   Configuring SAML on Alteryx Server for Okta Configuring SAML on Alteryx Server for ADFS Configuring SAML on Alteryx Server for PingOne Internet Explorer Enhanced Security Configuration - Microsoft Help Doc page

One of the three database options when setting up the Alteryx Server is to connect into a User-Managed MongoDB instance.  Why would you want to set up your own implementation of MongoDB?  The main benefits are to take advantage of the features of MongoDB that are not included with our embedded instance.

Issue    When publishing a workflow to Gallery with user credentials and you run into the following: Entering credentials has been disabled   When configuring a new Gallery Data Connection the below error comes up when attempting to test or save the connection:   Credential usage is disabled as a result of encryption configuration. Please contact your server administrator.     Environment   Alteryx Designer Alteryx Server   Diagnosis    You can verify this issue in the AlteryxService logs after a service restart. During the startup you will see a message like the following: ERROR,8912,AlteryxService,,,,,,,,"AlteryxService_InitLocalEncryptedStorage_Error: Error importing keys to Microsoft\Crypto\RSA\MachineKeys\ directory in ProgramData: Access is denied. (5)"   Cause   The Alteryx Service account has insufficient permissions to the server's machine key directory (%ProgramData%\Microsoft\Crypto\RSA\MachineKeys) or specifically the Alteryx Machine Key which is used to encrypt/decrypt user credentials and Gallery data connections.    Solution   Check your Service Log On As Account. The user set as the Log On As user (the default is Local System account) will need to have specific permissions.   Run services.msc (CTRL+R, enter services.msc, and click OK) Locate the Alteryx Service and check the Log On As account Per the server help documentation, ensure the Service Account has Full Control over  %ProgramData%\Microsoft\Crypto\RSA\MachineKeys** **If giving permissions to the full directory is not possible due to security reasons you can give it to just the Alteryx Machine key which starts with "3312". Also allowing Full Control over this machine key may fix the issue of the directory access does not. After granting permissions to the service account, restart the Alteryx Service  

Introduction   Does your organization have macros that users have developed to perform common and/or repeatable tasks within Alteryx? Does your organization struggle with how best to share those macros with the Alteryx Designer users and Alteryx Workflows/Apps which have been published to the Alteryx Server? Would you like to streamline the process of updating macros and utilize them through your Alteryx Workflows?  Great, now let’s take a look at how we can easily achieve this within your Alteryx environment(s).   As is common with many organizations, users within the organization have likely developed macros which perform various processes in Alteryx. These macros contain everything from simple to advanced data cleansing operations, core business logic, data manipulation tasks and much more. Once a user has developed a macro, we want to make it easy for them to share that with the rest of their Alteryx community.   When it comes to using macros in Alteryx Workflows and Analytic Applications published to Alteryx Server, many organizations have questions about how to deploy those Workflows that utilize these macros. More importantly, when a change is made, how do they propagate the latest version of the macro to all of the published workflows?   In this article, we will discuss the best practices around sharing macros. Using the methods outlined here, users will be able to make changes to Alteryx macros that are seamlessly propagated to other Alteryx Designer users, as well as Alteryx Workflows and Analytic Applications that have been published to the Alteryx Server.   What are macros?   Before we dive in to sharing macros, let’s define exactly what a macro is. Macros are a series of Alteryx tools built into a single workflow, that are bundled into a single tool that can be easily inserted into another workflow to perform common, repeatable tasks. Think about it as if you were taking an entire workflow and zipping it up into one Alteryx Designer icon, which you can then put into any other workflow.  A perfect example of this would be to create a standard macro out of an analytic process you have to repeatedly create on a regular basis.   Having this process in a macro form, allows you to then re-use that entire process in any number of other workflows without having to recreate the analytic process (or workflow) each time. This not only helps save time, but it also makes the entire process easily repeatable and protects you from forgetting any steps in that process. One key benefit to macros is, down the road, if there is a change to be made to that whole process, you only need to make that change in one workflow (macro), rather than chase down every instance that process was replicated.   Macros are identified by a .yxmc file extension.  There are four main types of macros with Alteryx: Standard Macros, Batch Macros, Iterative Macros, and Location Optimizer Macros.   Standard Macros   These macros, as mentioned above, are designed to package a process in a workflow as a tool that can be inserted into a workflow.   Batch Macros   These macros run multiple times in a single workflow, creating an output after each run. The macro runs once for each record, or selected group of records, in the data. This type of macro requires a Control Parameter tool to be used as an input. For additional information, see Batch Macros.   Iterative Macros   These macros run in the workflow the number of times set in the configuration, or run continuously until a specified condition is met. For additional information, see Iterative Macros.   Location Optimizer Macros   These macros are an iterative macro that can be used in network analysis to identify an optimal location or locations. For additional information, see Location Optimizer Macros.   Sharing Macros   Macros can be shared with users of the Alteryx Designer and Alteryx Server using a network file share. Permissions on who has access to the macros are controlled by permissions you define on the share. You can assign share permissions to users, groups of users, and computers to expose macros to Alteryx Workflows which have been published to the Alteryx Server.   Once you have placed the macro in a network share, you can add a macro repository in Alteryx Designer. After adding a macro repository in Alteryx Designer, the macros will appear in the tool palette, and can be searched by using the search toolbar in Alteryx Designer.   Creating a Network Share   NOTE: The following is an example of how to create a network file share. It is not intended to be used in production environments.   Depending upon the permissions defined on your network, it may be necessary to work with your IT department to have a network share created or permissions granted. Assuming you have the correct permissions to create a network share, proceed as follows to create a network share for macros: Open the Computer Management console on the file server Expand the Shared Folders section Right-click on Shares and select “New Share…” Follow the prompts in the “Create a Shared Folder Wizard” to create a network share NOTE: When creating the network share, you will be prompted to set shared folder permissions. Permissions allow you to control the level of access users, groups of users, and computers have on the network share.   Permission Considerations   Within an Alteryx Server environment, there are various ways workflows can be run. By default, all workflows will be run by a Local System account. However, you can configure Alteryx Server to run all workflows as a specific user in the Alteryx System Settings -> Worker -> Run As settings or you can require users to enter their domain credentials to run workflows. Depending upon the configuration of your Alteryx Server environment, this can dictate how permissions need to be assigned to the network share.   Example 1: If workflows are running under the default system account, in addition to assigning permissions to the share for users of the Alteryx Designer, you will need to assign computer permissions to the share for each server in your Alteryx Server environment.   Example 2: If workflows are running under a service account using the Alteryx System Settings -> Worker -> Run As settings, in addition to assigning permissions to the share for users of the Alteryx Designer, you will need to grant the service account access to the network share.   Example 3: If you require users to enter their credentials to run a workflow in your Alteryx Server environment, in addition to assigning permissions to the share for users of the Alteryx Designer, each user with permission to execute the workflow will need permission to the network share.   User and Group Permissions on Network Shares   NOTE: The following is an example of how to assign user and group permissions on a network share. It is not intended to be used in production environments.   To assign User and Group permissions, ensure the Users and Groups object types is selected in the “Select Users, Computers, Service Accounts, or Groups” dialog window. If either is not shown in the object types, click the Object Types button and select the Users and Groups object types.   Computer Permissions on Network Shares   NOTE: The following is an example of how to assign computer permissions on a network share. It is not intended to be used in production environments.   To assign computer permissions, ensure the Computers object types is selected in the “Select Users, Computers, Service Accounts, or Groups” dialog window. If Computers is not shown in the object types, click the Object Types button and select the Computers object types.     Shared Macros in Alteryx Designer   Now that you have created a network share for your macros, and assigned user/group/computer permissions, it is time to create a macro repository in Alteryx. Once you have added a macro repository to your Alteryx Designer, the macros will appear in the tool palette and be searchable using the search toolbar. To create a macro repository, proceed as follows: Open Alteryx Designer Go to Options >  User Settings  >  Edit User Settings  and click on the Macros tab Click  to add a macro repository In Category Name, type a name. Macros will appear in the tool palette under the Category Name defined here. The default name is Macros Click  to browse to the location where you save macros on your computer or a network or paste the file path to the network share containing the macros Click the OK button on the “Add Search Path for Macros” dialog window Click the OK button on the User Settings dialog window Once you have completed the steps above, the macros will appear in the Alteryx Designer tool palette under the category name specified in step 4.   NOTE: Sub-folders in a search path cannot be added individually if their parent folder already exists in the Macros repository. If you want sub-folders to display in different tool categories, you will need to remove the parent folder and add each sub-folder individually.   Shared Macros in Alteryx Server   To make the macros available to workflows published to your Alteryx Server environment, you will need to create the macro repositories on your Alteryx Server. To ensure the path to macros in workflows match between the Alteryx Designers systems and the Alteryx Server, the macro repositories will need to match those created on your Alteryx Designer users’ systems. To create a macro repository, proceed as follows: Open Alteryx Designer as an Administrator on your Alteryx Server Go to Options >  User Settings  >  Edit User Settings  and click on the Macros tab Click  to add a macro repository In Category Name, type a name. Macros will appear in the tool palette under the Category Name defined here. The default name is Macros Click  to browse to the location where you save macros on your computer or a network or paste the file path to the network share containing the macros Click the OK button on the “Add Search Path for Macros” dialog window Click the OK button on the User Settings dialog window Once you have completed the steps above, the macros will appear in the Alteryx Designer Tool Palette under the category name specified in step 4.   NOTE: In a multi-node server deployment, you will need to create the macro repositories on each node. After creating a macro repository on one server, you can copy and paste the newly created .ini config file (located at C:\ProgramData\Alteryx\DataProducts\AddOnData\Macros) to the same path on each server in your Alteryx Server environment.   Frequently Asked Questions   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.   Q. I’ve made a change to one of my macros. How do I deploy the latest macro to all the published Workflows in my Alteryx Server environment? A. When you save the macro to the network share, it will automatically be updated for every workflow that references the macro in the macro repository you created.   Q. I have multiple environments, dev, staging, and production. I would like to ensure changes to macros are properly vetted before being released to production. Will this work for my needs? A. Yes! For this to work, you can create a file share for each environment and assign the appropriate permissions to each environments file share. When adding the macro repositories to each environment, you can supply the environment specific macro repository path. When users make any changes to macros, they should save the new version to the dev file share. You can then test the updates to validate the changes before moving the updated macro to the staging and then production file shares.   NOTE: To ensure a seamless transition between the Alteryx Server environments, it is important to ensure the folder/file structure matches in each of the environment-specific file shares.   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.

Introduction   This is the second article in a series to explore the Alteryx Server System Settings in depth to gain a deeper knowledge of what these settings are used for, and to provide a bit more context to help you determine the appropriate settings for your environment. The first article in this series is: Alteryx Server System Settings Deep Dive - Engine. In this article we will focus on the Worker. The Alteryx Service Worker is responsible for executing analytic workflows, servicing Insights, and rendering map tiles. There must be at least one machine enabled as a worker to execute workflows through the Service.   We’ll explore the Worker settings in sections matching how they are displayed in the System Settings wizard.   Worker - General       Workspace   The Workspace is where the worker stores temporary or cache files, and unpackaged workflows for use when executing workflows. By default it is the same as the controller folder. This path should point to a location that is safe to store large amounts of files.   The same recommendations from the Engine “Temporary Directory” setting apply here:    Recommendations It is highly recommended to set the Workspace to a different drive than your system boot drive (C:\). If the C:\ drive on Windows fills up, the system can become unresponsive or even unstable.  If an additional drive (D:\) fills up, no harm is done to Windows and the system will remain functional. The Workspace is used for frequent I/O operations to read and write data. Configuring this directory on Flash/SSD storage is a great way to improve performance by minimizing the wait times for those read & write operations to complete.  See the Measuring and Scaling a Private Server blog post for more information.        Allow machine to run scheduled Alteryx workflows   Enabling this machine to run scheduled Alteryx workflows allows it to take requests to run workflows from the Scheduler or from the Gallery. In multi-node deployments, you may want to uncheck this option if you have another machine that will be running workflows, and want this machine to process map requests only.   Note, this setting needs to be enabled for the Worker to process either scheduled jobs, or manual jobs from users submitted through the Gallery.   Recommendations Ensure you have at least 1 Worker configured to run scheduled Alteryx workflows. In most cases all Workers should have this setting enabled. The exception would be if the Worker is to be used for Insights or Map Rendering only, which are covered below.     Workflows allowed to run simultaneously   This is the maximum number of scheduled workflows that are allowed to run simultaneously on this machine. You may want to increase this number to improve the responsiveness of scheduled jobs, but the overall processing time may be increased.   This is a very important setting for the success of an Alteryx Server deployment. The default value is 1. A higher value allows more workflows to run concurrently. However, it could also mean workflows take longer to process due to shared system resources. The blog post Measuring and Scaling a Private Server does a great job at explaining this in detail.   The general recommendation is to set the number of Workflows allowed to run simultaneously to ½ the number of physical cores. Many cloud providers list the number of “vcpus” or virtual cpus associated with instances, which can be misleading. The correct way to identify the true number of physical cores associated with a Windows Server (whether physical or virtual machine) is the following Powershell command:   Get-WmiObject -Class Win32_Processor | Select-Object -Property Name, Number*   Example machine with 4 physical cores and 8 virtual/logical cores   There is no one size fits all recommendation here as the best results will depend on the data sizes, types of tools in the workflow, and underlying hardware.  Below are some general recommendations.    Recommendations A good starting point is ½ the number of physical cores and this should be used in most situations. If jobs are queueing, but overall system utilization (CPU & Memory) is looking good, consider increasing the setting by 1 and observe the effects. If workflow runtimes are impacted or system utilization becomes too high revert to the original setting. If workflows are all In-Database then the Worker can likely handle a higher setting. In rare situations, it may be beneficial to leave the default of 1. An example might be when processing extremely large data sets with Spatial tools. In that scenario allowing the system to dedicate all resources to processing a single workflow may produce faster execution times. This setting should be in balance with the Engine Sort/Join Memory setting documented in the Engine Deep Dive Settings article. Review this configuration with your Alteryx representative to determine an appropriate value.   Maximum sort/join memory usage (MB)   This restricts the amount of memory Alteryx uses when encountering Sort or Join tools in a workflow. A general rule for an appropriate setting is to be ½ the amount of system memory available, divided by the number of simultaneous workflows allowed to run.   Note, this setting was removed in 2019.3 as seen from the screenshot above.     Cancel jobs running longer than (seconds)   If you do not want jobs to run for an extended period of time, use this setting to force jobs to cancel after a certain amount of time has passed. This helps free up system resources that might otherwise be taken up by unintentionally long running jobs. This setting only applies to scheduled jobs and does not affect manual runs from the Gallery.   This setting is disabled by default and should only be enabled to prevent long running scheduled Gallery jobs. Note, the checkbox must be selected and a valued provided to enable this setting. If the timeout is reached an error will be displayed:         Quality of Service (Job Priority)   In an environment where multiple workers are deployed, selecting a priority level can determine which jobs are run by each worker. For normal operation with one machine configured as a worker, set this value to 0.   The Server doc describes the use of this setting well under the “Job Priority” section:   When a job request is handled by a worker, it compares the priority level of the job to the Job Priority value for the worker. Jobs that have a value greater than or equal to the Job Priority for the worker will be handled by that worker. For example, if a worker has a Job Priority of 0 and is available, the worker will handle any request. However, a worker with a Job Priority of 3 will only handle jobs that have a value of 3 or higher. This allows resources to be reserved for higher priority requests.   Recommendations In a single Worker environment, leave the default value of 0. In an environment with a separate Controller, consider enabling the Controller also as a Worker and setting this value to 6. This will allow the Controller machine to process workflow validation requests only. Workflow validations occur when saving a workflow from Designer to the Server. Having the Controller process these jobs allows the Workers to remain focused on processing actual jobs, and ensures the workflow validations complete quickly since they aren’t queued up waiting for a busy Worker to finish processing a job. For more details and recommendations, see the Job Prioritization and Worker Node Assignment article.   Job assignment   A specific worker can be assigned to run a job. First, add a job tag for the worker, and then select that job tag when creating a schedule or running a workflow.   Run unassigned jobs : Select this option to use the worker to run jobs that have not been assigned a job tag. Job tags : Add words that can be used to assign a specific worker to run a job. Separate multiple job tags with a comma. The same job tag can be added to multiple workers.   Recommendations At least one worker should have the "Run unassigned jobs" option checked. Otherwise any jobs that are submitted without a job tag will sit in the job queue indefinitely. If Job tags are used in a multi-Worker environment, consider placing each job tag on at least 2 Workers to eliminate a single point of failure.  For additional details on these settings and Job tags recommendations, see the Job Prioritization and Worker Node Assignment article.       Worker – Run As …       Run as a different user   If a worker machine needs to run workflows that access files or data from a location that requires specific credentials to access it, the machine can be configured to run the workflows as a specified user or account. To have the machine run as a different user, enter the Domain, Username, and Password.   If no specific credentials are provided, then by default workflows will be executed by the Alteryx Engine process using the SYSTEM user. Providing credentials allows the running workflow to access file locations that might be protected by specific permissions. It’s also possible to access databases that use trusted Windows Authentication. Any workflow credentials entered when executing from the Gallery, or default workflow credentials assigned to a workflow or subscription will override what is specified in this setting. The article How Workflow Credentials Work on a Private Gallery explains this setup in great detail.      Worker - Mapping       Allow machine to render tiles for mapping   Enabling this machine to act as a Map Worker will allow it to render map tiles for Map Questions and the Map Input Tool. In multi-node deployments, you may want to uncheck this option if you have another machine that will process map tile requests, and if this one will be dedicated to running scheduled workflows.   When Map Questions or Map Input Tools are processed in the Gallery, the map tiles are built via a Map Render Worker. At least one Worker must be configured as a Map Render Worker for map tiles to be built. The map tiles are cached for faster response times on the Controller machine according to the Controller’s Mapping settings.     Max number of render workers    You can specify the number of processes to be used for map tile rendering. The more processes allowed, the more simultaneous tiles can be rendered, but it will take up more system resources.   For a configured Map Render Worker, you can control the number of processes that can render Map tiles. The default setting is 2, and the maximum is 10. This configures the number of Map Render Worker processes as shown below:     These processes are idle taking up very little resources until map tiles are requested. When map tiles are requested, they can consume a small amount of CPU and memory and then quickly release those resources when the job is complete.   Recommendations Configure at least 1 Worker to act as a Map Render Worker in the event map tiles are requested. Keep the default value of 2 Render Worker processes unless heavy map tile usage is needed. If extensive Map Questions and Map Input Tools will be used, consider configuring a separate Worker just as a Map Render Worker with a large number of Render Worker processes, but not to process Scheduled jobs or Insights. This will allow the machine to dedicate all resources to rendering map tiles and not conflict with running workflows. If map tiles that have been previously loaded are taking a long time to load, consider increasing the Memory Cache and Disk Cache sizes on the Controller Mapping settings.     Worker - Insights       Enable Insight Worker   The machine can be configured to act as an Insight Worker and render insights, which are interactive dashboards created in Alteryx Designer and published in a Gallery.   In order to execute and display Insights, at least one Worker must be configured as an Insight Worker. Unlike Map Rendering where the Worker processes the Map Tiles and the Controller caches them, with Insights the Worker performs both duties. The Worker both loads the Insights and caches them for fast response times on future requests to the same Insight. In the case of a multi-Worker deployment, if an Insight is cached, all future requests for the Insight will be processed by the Worker which has cached that Insight.   Recommendations In a multi-Worker environment, configuring one Worker as an Insight Worker is probably sufficient. If heavy Insight usage is expected, multiple Insight Workers are recommended.   Insights allowed to run simultaneously   The maximum number of insights that can run simultaneously on the machine. The more insights that can be run simultaneously, the more system resources used.   Insights are built and cached via python processes. This setting controls the number of python processes which can run simultaneously. The minimum is 2 and the maximum is 10. Example processes are below:   Note, these python processes are only launched if an Insight is requested. Each Insight process may consume roughly 64 MB of memory.   Recommendations In most situations the default value of 2 should be used. If Insights are going to be used frequently, the total number of Insights allowed to run simultaneously across all Insight Workers should be equal to the number of expected concurrent Insight requests from Gallery users.   Max Cache Size (# of Cache Directories)   The maximum number of insights cached on a worker machine. Each insight consists of a description and data file, so each insight cache is a directory that contains those files.   The default value is 20. This means that up to 20 Insights can be cached on this Worker and then quickly loaded for future requests. The maximum value allowed is 100. If you need to cache more than 100 Insights then multiple Insight Workers are needed.   Recommendations The sum of the Max Cache Size across all configured Insight Workers should be greater than the number of Insights in the Gallery. This ensures that all Insights can be cached for fast response times.   Max Port, Min Port   The range of port numbers designated for use when rendering insights.   Each of the python processes needs a port for passing the Insight to the Gallery. This controls the range of ports to allow. The default range is 100.  However, only up to the number of configured Insights allowed to run simultaneously will ever be used. So for example in a default configuration with 2 Insights allowed to run simultaneously, only ports 8700 and 8701 would be used.     Conclusion   An Alteryx Server Worker has many settings that can impact behavior, user experience, and resource consumption. Understanding how each of these settings are used by the Server, and how some settings even impact others, will allow administrators to configure Alteryx Server optimally for their environment and usage.  It’s important to note that any changes to the System Settings will perform an Alteryx Server restart on the respective machine. So, plan any changes carefully.     References Help: Worker System Settings Job Prioritization and Worker Node Assignment Measuring and Scaling a Private Server How Worfklow Credentials Work on a Private Gallery Alteryx Server System Settings Deep Dive - Engine

How to migrate from MMAPv1 to the WiredTiger Storage Engine   In earlier versions of MongoDB (3.0 and earlier), the default storage engine used was MMAPv1. The WiredTiger storage engine was introduced in MongoDB 3.0 and is the default storage engine in MongoDB 3.2 and later. Two major benefits of the WiredTiger storage engine are:   Document-level concurrency control for write operations which allows multiple documents in a collection to be updated at the same time Native compression which allows for more efficient use of storage space and less disk I/O   Earlier versions of Alteryx Server shipped with MongoDB 2.6 and MongoDB 3.0 which defaults to using the MMAPv1 storage engine. If you installed Alteryx Server prior to the 2018.1 release when Alteryx Server was upgraded to MongoDB 3.4, it is highly likely that your Alteryx Server is running MongoDB using the MMAPv1 storage engine. To take advantage of the performance benefits of the WiredTiger storage engine you can migrate to the WiredTiger storage engine. This article documents the steps required to migrate to the WiredTiger storage engine by performing a backup and restore of the embedded MongoDB database.   NOTE: The steps below only apply when using Embedded MongoDB with Alteryx Server 2018.1 and newer. If you are running Alteryx Server with a user-managed MongoDB, refer to the MongoDB help documentation.   Prerequisites   Product - Alteryx Server 2018.1 or newer with embedded MongoDB   Procedure   The first step is to identify which storage engine you are using. You can easily identify which storage engine is being used by reviewing the file system. Use the following Instructions to verify whether you are using the MMAPv1 or WiredTiger storage engine.   Open the Alteryx System Settings Navigate to the Controller -> Persistence page Copy the "Data Folder" path Open Windows Explorer (File Browser) Paste the "Data Folder" path copied in Step 3 in the Address Bar of Windows Explorer If you see a series of "NS File" and "0 File" file types, as shown below, your Embedded MongoDB is running using the MMAPv1 storage engine If you see a series of "WT File" file types and a file named "WiredTiger", as shown below, your Embedded MongoDB is running using the WiredTiger storage engine and no further action is necessary Create an Embedded MongoDB Backup   The steps below walk you through creating an Embedded MongoDB backup and restoring the backup to a new directory. For additional information on backup and restore best practices, refer to the additional resources at the end of this article.   Log in to the server hosting the Alteryx Server Controller and embedded MongoDB database Open an elevated command prompt (Right-click -> Run as Administrator) Change directories to the Alteryx Server installation directory cmd: cd %ProgramFiles%\Alteryx\bin Alteryx Server installs to %ProgramFiles%\Alteryx\bin by default. If you installed to a non-default directory, update the paths accordingly as shown in the screenshots Stop the AlteryxService cmd: AlteryxService.exe stop The AlteryxService should report it stopped successfully, as shown in the below screenshot Perform a backup of the embedded MongoDB cmd: AlteryxService.exe emongodump=<Path to Backup Location> Proceed to "Restoring an Embedded MongoDB Backup"    Restoring an Embedded MongoDB Backup   Restore the embedded MongoDB backup to a new directory cmd: AlteryxService.exe emongorestore="<Path to MongoDB Backup>","<Path to Restore to>" Update the Data Folder in the Alteryx System Settings Browse to or enter the path MongoDB was restored to in the Data Folder field on the Controller -> Persistence section In the Alteryx System Settings console, click "Next" until reaching the "Finalize Your Configuration" screen Click the "Finish" button on the "Finalize Your Configuration" screen to apply the changes and start the Alteryx Service Verify the Alteryx Service started cmd: sc query AlteryxService Confirm the state returned is "Running" as shown in the screenshot below   Verify MongoDB is running using the WiredTiger Storage Engine   Open Windows Explorer (File Browser) Navigate to the new "Data Folder" path in Windows Explorer You should see a series of "WT File" file types and a file named "WiredTiger," as shown below. If you see "NS File" file types, confirm you completed the steps outlined in the article     Now that you have completed the steps, your Alteryx Server is running embedded MongoDB using the WiredTiger storage engine - YAY! If you experience any issues with this process, please contact the Alteryx Customer Support Team for further assistance.    Additional Resources   For additional information on managing embedded MongoDB, refer to the Alteryx Server Help topic on MongoDB Management For Alteryx Server Backup and Recovery best practices, refer to the following Community articles Alteryx Server Backup & Recovery Part 1: Best Practices Alteryx Server Backup & Recovery Part 2: Procedures For user-managed MongoDB deployments running MongoDB 4.0, refer to the following MongoDB documentation MongoDB Production Notes Change Standalone to WiredTiger Change Replica Set to WiredTiger Change Sharded Cluster to WiredTiger

Troubleshooting: Workflow was not saved Unknown Error XmlException   When trying to save a workflow to Gallery, the below error is observed:   Workflow was not saved Unknown Error XMLException RequestID...     Environment   Alteryx Designer   Diagnosis   Does the file name of the workflow contains an URL restricted character (i.e. an ampersand "&")? If so, see Solution A. Does an Interface tool contain a URL restricted character in it's message section? (i.e. an ampersand "&")? If so, see Solution B.   Solution A   Delete the URL restricted character in the file name and re-upload the workflow. Please note that as a best practice no special characters should be used in workflow file names.   Solution B    Delete the URL restricted character in the message section of the Interface tool in the workflow and re-upload the workflow.        As always if you encounter issues and require further assistance please feel free to reach out to Customer Support.

Issue   As documented in the Server release notes (Server 2019.3), Alteryx Server version 2019.3 includes a new version of the embedded MongoDB (MongoDB functions as the server's  persistence layer ) . If you are upgrading your Alteryx Server from 2018.1 or greater*, your MongoDB will be migrated from Mongo 3.4 to Mongo 4.0 as part of the process.   *If upgrading from pre-2018.1, you will need to upgrade to a version between 2018.1-2019.2 before upgrading to 2019.3. Some users have reported the following error after the migration :   Inconsistencies between the original data and the new data may indicate a migration error. Check the C:\ProgramData\Alteryx\Service\Persistence\MongoDB_4_0\migration.log for any errors and contact Alteryx Customer Support for assistance.   While the server may still run on the MongoDB 3.4, this may cause unexpected behavior in the long term. Should you encounter this error, it is important to troubleshoot it and make sure that your MongoDB is able to successfully migrate.   Environment   Alteryx Server Upgrading from a version  ≥ 2018.1 to version 2019.3   Diagnosis   If this error is encountered, the server itself will upgrade, but fail to start the service.   To determine which troubleshooting steps to take, we first need to check if the migration was actually successful or not :   Confirm there a MongoDB_4_0 folder under the path in the Alteryx System Settings under Controller > Persistence > Data Folder. If there is a MongoDB_4_0 folder, check the migration.log file found under the Data Folder path.   Check to see if it matches the successful migration shown here in the Spoiler:   A "successful" migration should have the following: First, you see the original 3.4 database start with the 3.4 executable. Then, getstats.js is run - it will show a list of collections and a count of items in them.   --Starting: C:\Program Files\Alteryx\bin\mongod3_4.exe --dbpath "C:\ProgramData\Alteryx\Service\Persistence\MongoDB" --port 27018 --Starting: mongo3_4.exe localhost:27018 "C:\ProgramData\Alteryx\Service\Persistence\MongoDB\getstats.js" {"databases": [ {"name": "AlteryxService", "collections": [ {"name": "AS_App_Chunks", "count": 290} , {"name": "AS_App_Chunks.Files", "count": 27} ... Next, Mongo will dump out to the PreUpgrade folder specified in the migration utility. Once the backup completes the MongoDB service is stopped with the shutdown.js. You will see MongoDB is not responding because it was shut down successfully - any errors referencing the server being down, or the connection being forcibly closed is expected. --Starting: mongodump3_4.exe --host localhost --port 27018 --username user --password xxxxxxxxxxxxxxxxxxxxxxxxxxx --out "C:\ProgramData\Alteryx\Service\Persistence\MongoDB_PreUpgrade" 2019-09-04T11:21:45.557+0100 writing admin.system.users to 2019-09-04T11:21:45.559+0100 done dumping admin.system.users (4 documents) 2019-09-04T11:21:45.559+0100 writing admin.system.version to 2019-09-04T11:21:45.560+0100 done dumping admin.system.version (2 documents) ... --Stopping MongoDb --Starting: mongo3_4.exe localhost:27018 "C:\ProgramData\Alteryx\Service\Persistence\MongoDB\shutdown.js" ... 2019-09-04T11:21:48.413+0100 I NETWORK [thread1] Socket recv() An existing connection was forcibly closed by the remote host. 127.0.0.1:27018 2019-09-04T11:21:48.413+0100 I NETWORK [thread1] SocketException: remote: (NONE):0 error: 9001 socket exception [RECV_ERROR] server [127.0.0.1:27018] server should be down... Then Mongo is started again, and restored to the new MongoDB_4_0 directory from the previous backup that was just taken. Again, we should not see any errors in here. Then, the createUsers.js re-creates all the user accounts for each database. The MongoDB is then shut down via the shutdown.js again. Again - any errors referencing the server being down, or the connection being forcibly closed is expected.   --Starting: C:\Program Files\Alteryx\bin\mongod.exe --dbpath "C:\ProgramData\Alteryx\Service\Persistence\MongoDB_4_0" --port 27018 --Starting: mongorestore.exe --host localhost --port 27018 "C:\ProgramData\Alteryx\Service\Persistence\MongoDB_PreUpgrade" ... {restore happens} 2019-09-04T11:21:59.059+0100 done --Starting: mongo.exe localhost:27019 "C:\ProgramData\Alteryx\Service\Persistence\MongoDB_34\createUsers.js" MongoDB shell version v4.0.10 connecting to: mongodb://localhost:27018/test?gssapiServiceName=mongodb Implicit session: session { "id" : UUID("b355d9b1-d9b0-4b6f-816f-158da213dcaa") } MongoDB server version: 4.0.10 Successfully added user: { "user" : "user", "roles" : [ "dbOwner", "hostManager", "dbAdminAnyDatabase", "userAdminAnyDatabase", "backup", "restore" ] } Successfully added user: { "user" : "user", "roles" : [ "readWrite", "userAdmin" ] } Successfully added user: { "user" : "user", "roles" : [ "readWrite", "userAdmin" ] } Successfully added user: { "user" : "user", "roles" : [ "readWrite", "userAdmin" ] } --Stopping MongoDb --Starting: mongo.exe localhost:27019 "C:\ProgramData\Alteryx\Service\Persistence\MongoDB\shutdown.js" ... server should be down... 2019-09-04T11:22:01.726+0100 I NETWORK [js] trying reconnect to localhost:27018 failed 2019-09-04T11:22:02.728+0100 I QUERY [js] Failed to end session { id: UUID("129ef6b5-c6a8-40d0-8801-5987cb980e00") } due to SocketException: socket exception [CONNECT_ERROR] server [couldn't connect to server localhost:27018, connection attempt failed: SocketException: Error connecting to localhost:27018 (127.0.0.1:27018) :: caused by :: No connection could be made because the target machine actively refused it.]   The new MongoDB_4_0 is then started up again with Mongo 4.0, and we run getstats.js again, giving us a list of the collections and the count of the documents, similar to the first step. --Starting: C:\Program Files\Alteryx\bin\mongod.exe --dbpath "C:\ProgramData\Alteryx\Service\Persistence\MongoDB_4_0" --port 27018 --Starting: mongo.exe localhost:27018 "C:\ProgramData\Alteryx\Service\Persistence\MongoDB\getstats.js" If everything looks good up to this point, the migration has likely been successful - continue to check the points below. If not, please see Solution B. Are the Alteryx System Settings under Controller > Persistence > Data Folder pointing to the new MongoDB folder (MongoDB_4_0)? If everything looks good in the logs, but the service didn't start or something happened after this point, we should be able to manually change the persistence directory to point at the new MongoDB_4_0 directory, and in theory, the service should start up fine. See Solution A for steps.   What version of Mongo is running after the attempt? In the persistence directory of the target database, there's an ASMongoDBVersion.bin file that seems to match up with the version of Mongo. If this does not show version 4.0, see Solution B.     Solution A   If the log contains all the information mentioned previously and the migration seems successful, but there’s an error starting the service:   Check that the Data Folder under Controller > Persistence is set to the MongoDB_4_0 folder. If is it not, edit it to point to this new folder. Restart the Alteryx Service.   Solution B   If the migration log doesn’t match the description above, give the migration another attempt:   1. Delete the folders MongoDB_PreUpgrade and MongoDB_4_0 2. Run the MongoDbUpgradeTo30.exe found here: %ALTERYX_INSTALL_DIRECTORY%\bin\MongoDbUpgradeTo30.exe     If the MongoDB_4_0 folder is still empty with the exception of the migration.log, then check the MongoDB_PreUpgrade folder for the ASMongoDBVersion.bin file. If it is not there: Copy the file from your old MongoDB folder and paste it into the MongoDB_PreUpgrade folder. Open the file and change the version number to 4.0.10. Close the file and re-attempt the upgrade.   As always, don't hesitate to contact us over at Customer Support if you run into any trouble.

Issue   The run command from either the event or the tool used to run an external script (VBScript) that contains the code to access the Excel object does not execute successfully on Alteryx Server. The job exits with a timeout error.   Error running Event #1: The external program <EXTERNAL_PROGAM> timed out after <TIME> ms   Configuration Example:   Script example:     Option Explicit Dim objExcel Set objExcel = CreateObject("Excel.Application") .. .. objExcel.Application.Quit Set objExcel = Nothing     Environment   Alteryx Server   Diagnosis    To diagnose the actual cause of the issue, add debugging statements in the script to find where the code may be breaking on the server. Suggested code:     Option Explicit Dim objFileToWrite Set objFileToWrite = CreateObject("Scripting.FileSystemObject").OpenTextFile("C:\temp\debug.txt",2,true) objFileToWrite.WriteLine("Starting log") Dim objExcel Set objExcel = CreateObject("Excel.Application") objFileToWrite.WriteLine("After Object Instantiation") .. ..     Solution   The solution will depend on the cause of the issue.   In general, when a COM object is used, do ensure that the account that runs the workflow on the server has the necessary permission to launch and activate the COM object. If the debug statement does not go past the COM instantiation, it is likely that this is a permission issue. In this case, check the Windows System Event log for the actual error. Please refer to the "Additional Resources" section to enable the COM object on the server.     Additional Resources   To enable COM object on the server 

How to enable the use of COM object on the server   If you have written an external script to use a COM object, for example, Microsoft Excel and the workflow uses this, you will need to ensure that the appropriate permissions have been given to the group of users or specific users in order to run the script successfully on the Alteryx server. Otherwise, an error like below can be seen from the Windows System Logs:     The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {XXX-XXX-XXX} and APPID {XXX-XXX-XXX} to the user <ACCOUNT_USER> SID (XXX-XXX-XXX) from address LocalHost (Using LRPC) running in the application container XXX SID (XXX). This security permission can be modified using the Component Services administrative tool.   This article provides the steps to check and enable Microsoft Excel COM permission on the server. However, the same will apply to the other Microsoft COM objects or any third-party objects.   Prerequisites   Windows Operating System Any versions The administrator of the machine is needed.   Procedure 1. If Office 32-bit is used, please use the following command to bring up the Component Services: mmc comexp.msc /32 For Office 64-bit, use the above command without "/32". 2. Look for "Microsoft Excel Application" in Component Services > Computers > My Computer > DCOM Config.        3. Right-click on the component and select Properties. 4. In the Properties window, select the Security tab. 5. Choose the Customize option and click Edit for Launch and Activation Permission. 6. Select or add the appropriate group/user to access the COM object. Check Local Launch and Local Activation.      Additional Resources   Microsoft - Enabling COM Security Using DCOMCNFG 

Cannot Access Gallery from Server Machine Using FQDN or IP   When attempting to save a workflow to the Gallery or access the Gallery via FQDN (e.g., ayx.domain.com) or IP in the browser, you are continuously prompted for Windows credentials. This article refers to situations where this behavior occurs ONLY on the Server machine itself; but you are able to access Gallery and save workflows from remote machines using the same credentials.     Environment   Alteryx Server Windows Authentication enabled   Diagnosis   To ensure this issue is isolated to the Server machine, verify that you can access the Gallery via FQDN or IP in the browser and save a workflow to the Gallery from other machines (not the Server) with the same credentials.   Additionally, you should be able to access Gallery via the Server machine using "localhost".   Cause   Certain versions of Windows include a security feature called loopback check functionality.    Solution   Follow the instructions from this Microsoft KB article and choose either Method 1 (recommended) or Method 2: Method 1: Create the Local Security Authority host names that can be referenced in an NTLM authentication request Method 2: Disable the authentication loopback check   Additional Resources   Error message when you try to access a server locally by using its FQDN or its CNAME alias

Schedules Disabled - "Logon Failure: the User has not been Granted the Requested Logon Type at this Computer"   A change in Run As credentials or workflow credentials can lead to the user(s) losing access to his/her workflows. When clicking on a workflow the below error appears:   Error: Logon failure: the user has not been granted the requested logon type at this computer. (1385)   Apps appear in state 'Disabled'  When trying to access apps the above error message appears   Environment   Alteryx Server Gallery   Cause   This error occurs when the Run As User credentials or the workflow credentials do not have sufficient permissions on the server. More specifically,   'Allow log on locally' or 'Log on as a batch job' group policy permission are required for the user to log onto the server. If neither is granted to user the above error appears.     Solution   Check that that Run As credentials are set correctly. Refer to Help doc page - Set Required Run As User Permissions. Specifically,  'Allow log on locally' or 'Log on as a batch job' group policy permission are required.     Additional Resources   How Workflow Credentials Work on a Private Gallery Troubleshoot "Invalid Username or Password" Error - Setting Up Workflow Credentials Troubleshooting "Entering credentials has been disabled", "Credential usage is disabled"

Server licensing and scaling is getting an update! In the past, server scaling has been handled by two separate products: the Alteryx Server Additional Node and the Alteryx Server 2 Core Add-On.  Alteryx Server Additional Node allows for horizontal scaling by licensing separate worker nodes which report to a controller, while Alteryx Server 2 Core Add-On allows for vertical scaling by enabling more computing power on the controller machine. These two separate products to scale server can cause friction for our end users, License Administrators, and IT Administrators alike as the scaling needs of the organization change. To better enable scaling, we're cleaning up our products and removing the friction with the Alteryx Server Additional Capacity product. How Does It Work? The new Alteryx Server Additional Capacity license will act as both a 'base' and an 'add-on' license. This means that during the activation process, the Alteryx Server Additional Capacity license will identify if there is already an Alteryx Server license present, if an Alteryx Server license is being activated simultaneously, or if no Alteryx Server licenses are present.  If a Server License Key (Alteryx Server, Alteryx Server Sandbox, or Alteryx Enterprise Server) is activated before or alongside the Alteryx Server Additional Capacity License Key, the Alteryx Server Additional Capacity license will act as an add-on and license two additional cores on the box. If the Alteryx Server Additional Capacity license is being activated alone, the product will act as a 'base', allowing the licensed machine to function as a worker node. How many cores does the Alteryx Server Additional Capacity license? One seat on the Additional Capacity key will license 2 cores. This applies to either scenario, whether the key is acting as a base product or as an add-on. The key will also automatically activate as many seats as needed to completely license the machine during the initial activation. What versions of Alteryx will the Alteryx Server Additional Capacity key work on? The Alteryx Server Additional Capacity key will work for versions 2019.2 or newer of Alteryx. If you are running a version older than 2019.2 and have been provided this product, reach out to the Fulfillment team (fulfillment@alteryx.com) to exchange the license key for the equivalent legacy product(s). Can I apply multiple seats on the same key or multiple unique keys of Alteryx Server Additional Capacity to the same Server? Yes! When activated, the Alteryx Server Additional Capacity product will identify how many cores are on the controller, and apply as many as needed to fully license the machine. If the number of cores available on the Alteryx Server Additional Capacity is unable to match the number of cores on a machine, the Additional Server Capacity license will activate as many seats as are available. For example, if you have an 8 core worker machine and only 2 seats on the Alteryx Server Additional Capacity key, both seats will be activated to license the device for 4 cores. Will the Alteryx Server Additional Capacity key retroactively replacing existing License Keys? We have no plans to replace the Alteryx Server Additional Node or Alteryx Server 2 Core Add-On License Keys from existing orders. However, all future orders that contain a server scaling product will be licensed with the Alteryx Server Additional Capacity product. All previously purchased server scaling products will continue to work on any version past 11.7. If you would like to upgrade to 2019.2, your previously purchased keys will have no trouble migrating. When is this product going to be available? The Alteryx Server Additional Capacity product will be launched and available for order with the release of 2019.2. Got another licensing question? Check out this community article! If your question not answered there, please reach out to the Fulfillment Team (fulfillment@alteryx.com)!

Schedules stop functioning or error shows when disabling schedule This occurs on 2019.3 and only appears if there is a Schedule with a Next Run time between 12-2 AM on 11/3 for the US and on 10/29 for Europe. This is due to the time change, and the Gallery is not able to determine the time zone the Workflow should run in.   Other symptoms which customer may report or describe: scheduled jobs are active/queued but not running.    There are two errors that can appear. The below will show in the Service Log soon after service start-up.   ServiceScheduler_DoWork_StdError: Fatal top-level error The following error will show when attempting to disable an affected Schedule.   Schedules may show a Next Run date and time equal to the Last Run date and time which may be in the past.   Environment   Product - Alteryx Server and Alteryx Designer with Automation Version 2019.3   Cause   This is caused by the Time Zone functionality not being able to recognize what time zone the Schedule is set for since the time it is scheduled for will 'repeat' with the end of Daylight Savings. It is recommended not to schedule anything for this time to avoid this issue.   Solution Now that the time has changed, it should only be necessary to  Restart AlteryxService.   If that does not resolve the issue then: Delete the Schedules between 12 AM and 2 AM on the date of the time change (11/3 for NA and 10/29 for Europe) Restart AlteryxService

Issue    A red exclamation icon is seen along with the following message in the Manage Data Connections window of Designer. This error can also been seen in Gallery.   This data connection is no longer available     Environment   Alteryx Designer Alteryx Server   Diagnosis   One possibility for this error to occur is when all affected data connections are created in Gallery only and the connection has been lost for any reason.   Please attempt solution A first, if no success go to solution B.    Solution A   In Gallery data connections, remove the affected user from the data connection, then re-add the user:   1. Login to Gallery as an Admin (aka Curator). 2. On the left pane, go to Data Connections. 3. Select the "edit" link (pencil icon) for the affected data connection. 4. Go to the Users and Studios tab and remove the affected user(s). 5. In the same tab, re-add the same user by searching for him/her in the search field.   Solution B   1. Successfully perform a re-indexing by using the re-indexing app.  Please reach out to Customer Support to ensure a re-indexing is needed and to follow the proper steps for it. 2. Perform the steps in Solution A.     Additional Resources:    Gallery Data Connections FAQ Troubleshooting "Unable to translate Alias" with Gallery Data Connections How To: Create a Database Connection Share Through Gallery Admin

Issue: Error '"You are attempting to upgrade from an unsupported version" when upgrading to 2019.3'   During the upgrade of Alteryx Server to 2019.3, you may encounter the following error once you attempt the migration of the Mongo database:   You are attempting to upgrade from an unsupported version. Upgrade to Alteryx Server version 2018.1 or later to attempt to upgrade to your desired version, or contact Alteryx Customer Support for assistance. Environment   Alteryx Server 2018.1+ Embedded MongoDB   Diagnosis   If you are running a version pre 2018.1, please upgrade to version 2018.1+ before attempting to upgrade to 2019.3. Do not continue further in this article.   If you are in fact running version 2018.1 or newer, confirm that your database is version 3.4.10 with the following steps:   Check which storage engine you are running:   The first step is to identify which storage engine you are using. You can easily identify which storage engine is being used by reviewing the file system:   Open the Alteryx System Settings Navigate to the Controller > Persistence page Copy the Data Folder path. Open Windows Explorer (File Browser) Paste the Data Folder path copied in Step 3 in the Address Bar of Windows Explorer If you see a series of "NS File" and "0 File" file types, as shown below, MongoDB is running using the MMAP storage engine. If you see a series of "WT File" file types and a file named "WiredTiger", as shown below, MongoDB is running using the wiredTiger storage engine.   MMAP     wiredTiger     Start the Mongo daemon:   1. Open command prompt as an Administrator 2. Change directories to the location of the Alteryx bin folder. The default location is "C:\Program Files\Alteryx\bin" cd "C:\Program Files\Alteryx\bin\" 3. If you are using the wiredTiger storage engine, run the following command, replacing the dbpath location with your Data Folder path: mongod3_4.exe --dbpath "C:\ProgramData\Alteryx\Service\Persistence\MongoDB_34" --port 27018 3b. If you are using the MMAP storage engine, run the following command, replacing the dbpath location with your Data Folder path: mongod3_4.exe --dbpath "C:\ProgramData\Alteryx\Service\Persistence\MongoDB_34" --port 27018 --storageEngine mmapv1 4. You should see a message that says 'waiting for connections on port 27018'. Leave this window open and proceed with the next steps.   Connect to the Mongo shell:   1. Open another command prompt as an Administrator 2. Change directories to the location of the Alteryx bin folder. cd "C:\Program Files\Alteryx\bin\" 3. Get the MongoDB password by running the following:  alteryxservice getemongopassword Copy the Non-Admin password.   4. Run the following to connect to the Mongo shell: - Enter the password from above after -p mongo3_4 -u user -p YOUR_PASSWORD --host localhost:27018 AlteryxService 5. Run the following command to retrieve the version: db.version() If your version says 3.4.10, see Solution below.   Cause   The ASMongoDBVersions.bin file contains the wrong version.   Solution   1. Confirm the AlteryxService is stopped 2. Navigate to the Data Folder path in Windows File Explorer. Locate the ASMongoDBVersions.bin file 3. Replace the content of the file with just the following, and Save: 3.4.10 Example of a corrected ASMongoDBVersions.bin file 3. Re-run the MongoDBUpgradeTo30.exe found in the Alteryx bin folder in the installation directory 4. You should now be presented with the following screen. Continue through the prompts to migrate the database. 5. If you run into issues with the migration, please see the article under Additional Resources below, or contact Alteryx Support     Additional Resources   Troubleshooting a failed MongoDB migration - Server 2019.3

How To : Safely change the Global Workspace of an Alteryx Server   The Global Workspace is a path used as the base for configuration options that determine where temporary files, log files, and database files are stored. Sub-folders for the specific items can be created to use the global workspace or can be customized later to write to a different location. This path should point to a location that is safe to store large amounts of files.   Server admins wanting to change it to to a different location can use this resource to safely perform this change.   Prerequisites   Product - Alteryx Server Infrastructure All permissions on the future Global Workspace   Procedure   Backup your Alteryx Server (procedure outlined here) Alongside the backup of done in the previous step, keep a copy of the below elements: RuntimeSettings.xml (this file can be found in %ProgramData%/Alteryx/) Controller Token (can be copied into a text file from the Alteryx System Settings > General) Stop the Alteryx Service Open the Alteryx System Settings ans navigate to Environment > Workspace Change the Global Workspace to the desired directory : Navigate through each screen of the Alteryx System Settings to confirm that: The paths of the sub-directories include the new Global Workspace's root path The other settings remain unchanged Do not hit hit "Finish" on the last screen of the Alteryx System Settings:   But instead copy the below folders from the previous Global Workspace to the new Global workspace: Engine Gallery Service After the copy, you can hit "Finish" to apply the changes and start the Alteryx Service Log into the Gallery Admin and validate that every elements are available (users, workflows, schedules...) If the validation is confirmed, remove the below folders from the previous Global Workspace: Engine Gallery Service   Additional Resources   Help Pages - Configure Server Help Pages - Environment   As always, don't hesitate to contact us over at Customer Support if you run into any trouble.

Alteryx Server System Settings Deep Dive - Engine     Introduction   This is the first in a series of articles to explore the Alteryx Server System Settings in depth to gain a deeper knowledge of what these settings are used for, and to provide a bit more context to help you determine the appropriate settings for your environment.  Every organization's deployment, use cases, and business requirements are different and thus there is no single configuration to fit all.  Having an understanding of the implications of each setting is vital in setting up your Alteryx Server for success.   We’ll explore the system settings for Alteryx Server as of 2019.2, through a series of articles for each component, starting with the Engine. The Alteryx Engine consumes Alteryx workflows and provides high-speed data processing and analytics functionality. This process can be entirely self-contained in Alteryx Designer, scaled across an organization by the Alteryx Service, or deployed in the cloud by the Alteryx Gallery.     Engine Settings   The Alteryx Server System Settings configuration wizard allows end users to modify the Engine configuration settings:   Engine Configuration   Any changes to the configuration settings in the System Settings wizard are applied to the RuntimeSettings.xml file, found at: %ProgramData%\Alteryx\RuntimeSettings.xml   Note, this file should never be modified through an editor unless specifically requested from Alteryx Customer Support.    A few of these settings are self-explanatory and sufficiently described in the Help.  However, many of these can often be confusing, and some have performance implications that aren’t well understood. The subsequent sections will dive into these settings in more detail.     Temporary Directory   “The Engine Temporary Directory is the place where temporary files used in processed workflows and apps will be placed. This setting should point to a location that is safe to write large amounts of files.”    The Engine Temporary directory is a parent directory in which each workflow executed creates a sub directory for storing data needed during the processing of the workflow.  Below is not an exhaustive list, but includes the most common types of data stored in the Engine temporary directory: Browse Tool Support - Every Browse Tool in the workflow creates a separate Alteryx Database file (.yxdb) that stores the contents of the data you see in the Browse’s Results and Configuration windows. The Browse Tool allows you to view all the data as opposed to a sample, and therefore the created .yxdb files could be quite large if the data sets being processed are large.  Therefore, the number of Browse Tools should not be prolific. NOTE: The temporary .yxdb files are only created when an Alteryx Workflow is run in Designer.  When workflows are executed through the Gallery or a schedule, browse tools are disabled. Browse Everywhere Support – The Browse Everywhere features allows you to click on the output anchor of a given tool and see a sample of the data at that point in the workflow.  All the data viewable in the various output anchors across a workflow is stored in one Alteryx Browse Everywhere file (.yxbe).  The size of this file is determined by how many tools are in the workflow multiplied by the “Memory Limit Per Anchor” size which will be discussed later in this article. NOTE: The temporary .yxbe file is only created when an Alteryx Workflow is run in Designer.  When worfklows are executed through the Gallery or a schedule, Browse Everywhere is disabled.  Tool Specific Support – Some tools create temporary files as part of their processing, for example the Download and Spatial Match tools. Paging / Swap Space – When the Engine's memory processing requirements exceed that of the “Default sort/join memory usage” setting (covered later in the article), temporary files (.tmp) are created to retain data that can be quickly retrieved later. The number and size of these temp files is determined by the size of the data sets being processed, and the types of tools in the workflow.  The Engine 101 Basics blog does a great job of describing how certain “blocking” tools need access to all rows of a dataset to process it.  The presence of these blocking tools will drive up the likelihood that the Engine will need to use temporary files to complete its processing.   Example Engine Temp directory for a running workflow where the files described above are evident. These files are all deleted when the workflow processing is complete.  For a Designer user, this means when the Workflow is closed or upon initiating another execution of the Alteryx Workflow in Designer.  For a Server user, this means upon completion of the workflow execution.  Note, the Engine Temporary Directory is used when running workflows from Alteryx Designer.   When running on an Alteryx Server, the Worker’s “Workspace” directory is used to store these temporary files.   Recommendations It is highly recommended to set the Temporary Directory to a different drive than your system boot drive (C:\). If the C:\ drive on Windows fills up, the system can become unresponsive or even unstable.  If an additional drive (D:\) fills up, no harm is done to Windows and the system will remain functional. The Temporary Directory is used for frequent I/O operations to read and write data. Configuring this directory on Flash/SSD storage is a great way to improve performance by minimizing the wait times for those read & write operations to complete.  See the Measuring and Scaling a Private Server blog post for more information.    When running in Designer, minimize the use of Browse Tools when working with large data sets to reduce workflow processing times and keep the Temp directory from filling up. Understand that temporary directories can grow quite large during processing if working with large data sets and doing lots of sorts, joins, or other blocking operations. As an example, we saw a temporary directory grow over 150GB in size processing a 12GB data set.  Your mileage will certainly vary based on data set sizes and tools used.     Memory Limit Per Anchor “Define the maximum amount of memory to use to consume data for each output anchor for tools in a workflow. The default value typically does not need to be changed.”    This setting applies when running in Designer only as mentioned in the Browse Everywhere section.  The Browse Everywhere feature allows a user to see a sample of the data (up to Memory Limit Per Anchor in size) at the output anchor of every tool.  The default value is 1024 KB (1MB).     This workflow would produce a .yxbe file of approximately 12MB. This is a great way to analyze your data without using the Browse tools which will write the entire dataset contents to disk.     A sample of the data can be seen in the output anchor of each tool. In the event of the Temporary Directory not having enough space to create the .yxbe file, the following will be logged: Warning - Alteryx: Disk space on temp drive running low.  No browse everywhere data created.   Recommendations Keeping the default Memory Limit per Anchor setting makes sense for most scenarios. In situations where you are building a workflow with a very large data set, and the 1 MB sample just isn't enough to give you the information you need, but the full Browse tool is too heavy, it might make sense to increase this value. However, make this change on the local Designer (laptop/desktop) and not the Server which is used by many end users.  This change can be made in Designer under Options -> User Settings -> Edit User Settings: Designer users can override the Memory Limit per Anchor in the Advanced User Settings.     Default sort/join memory usage "This is the minimum amount of memory that the Engine will consume while performing operations such as Sorts and Joins within a workflow or app. Generally, this value should not be changed.”    The Engine "Default sort/join memory usage" setting and the Worker “ Maximum sort/join memory usage ” setting have generated a lot of questions that I hope this section clears up. There are three key points to clarify:   If making changes, the Engine "Default sort/join memory usage" is the setting that should always be specified and what we'll focus on in this article. For Designer users, this value can be specified in the Options --> User Settings --> Edit User Settings wizard: The Default Dedicated Sort/Join Memory Usage setting This setting is both a minimum and a maximum.  It's a minimum in that this amount of memory will be "committed" to each Engine process (running workflow)  regardless of how much memory the Engine actually consumes processing the workflow.  Therefore this amount of memory is reserved for each Engine process and not usable by other applications.  It's a maximum in that the Engine process will not consume more memory than this value. If the Engine needs more resources than the setting specified, it will start utilizing the temp (swap) space as described earlier.  If the workflow launches additional processes, such as from the Run Command tool, or R by the use of Predictive Tools, those processes are NOT controlled by this setting. Other processes are not controlled by the Engine Default Sort/Join Memory Usage setting The setting is not specific to Sorts and Joins.   As described in the Engine 101 Basics blog, “blocking” tools require access to all data for execution.  This drives up memory consumption.  Sort, Join, and Summarize operations are the most commonly used blocking tools but there are many others, easily identifiable with a red border in the Periodic Table of Alteryx Tools .  Any workflow executing these blocking tools with high row count data sets (millions of rows) will consume lots of memory.   If the Sort/Join memory setting requested exceeds the amount of physical RAM available, Alteryx will revert to a lower value that is safe to commit.  In that case a message like the following will be logged in the Alteryx Engine logs: 00:00:0.003 - Alteryx: Allocating requested dedicated sort/join memory would be more than available physical memory.  Reverting to 2912MB of memory.                  Recommendations Only make changes to the Engine "Default sort/join memory usage" setting if necessary.  The default value works well for most scenarios, and we routinely see problems occur when this value is changed without understanding when and how to configure it. The below recommendations are just starting points. It is always recommended to configure and then test with representative workflows and usage patterns.  Then reconfigure and repeat the process until the optimum values are identified. To properly calculate a reasonable Sort/Join Memory value, we must know how many workflows will be configured to run simultaneously. This number should be determined by a server sizing exercise, and for existing customers, also take into account data from the Server Usage Report, such as queue times and job execution times.  For Designer only users the number of simultaneous workflows will be 1. For Alteryx Server machines that act as both a Worker and a Controller with the Embedded MongoDB, a good starting point is: For standalone Workers, more memory can be allocated to running workflows. In that case a good starting point would be: The 4GB reservation ensures the OS and other system services are not starved of memory.  If predictive tools will be frequently used then lower your calculated values from above as additional memory should be reserved for the R processes. The expectation is that the machine will only be used for Alteryx processing and not shared with other applications. If other applications will also be running, then their memory requirements need to be factored into the equations above. Again, the above recommendations are just starting points. It is always recommended to configure and then test with representative workflows and usage patterns.  Then reconfigure and repeat the process until the optimum values are identified.     Default number of processing threads   “Define the number of processing threads tools or operations can use. The default value is the number of available processor cores plus one. Generally, this value should not be changed.”   This setting is determining the number of processing threads that multi-threaded tools can use.  The multi-threaded tools are identifiable in the  Periodic Table of Alteryx Tools .  (Sort and some Spatial tools highlight the list).  Configuring a higher value here may facilitate more parallelism which may result in faster completion times in the execution of these multi-threaded tools, assuming the machine has the capacity to use the specified number of threads.  Specifying a higher than needed thread pool size can lead to an over-committed system in which the CPU is constantly context switching between threads which may produce longer processing times.    In Windows Task Manager, the "Logical processors" metric shows us the maximum number of concurrent processing threads on that server:       Recommendations To reduce workflow run times using multi-threaded tools, set the Default number of processing threads equal to the number of Logical processors. If the server will be executing multiple workflows simultaneously, consider using a lower value to ensure that no workflows are starved of CPU.     Run engine at a lower priority   “Select if you are running other memory intensive applications simultaneously. It is also recommended that this setting be checked for a machine configured to run the Gallery.” The Windows Scheduling Priorities doc is a great resource to understand why this setting is important.  To summarize, Windows assigns time slices of CPU time to processes based on their priority level.  Applications with a higher priority will be given more CPU time than applications with a lower priority.  This ensures higher priority applications get more processor time when the system is heavily utilized.   Most applications default to “Normal” priority.  Some critical Windows processes have a “High” priority, such as the logon and desktop window manager processes.  Alteryx installs all Server components (AlteryxService, Gallery, Designer, etc…) with the “Normal” priority.  By default, this includes the Engine as well.  This could lead to a scenario where resource intensive workflows are running, and the Alteryx Service layer, the Gallery, or even Designer are struggling to get CPU time since they all share the same priority level.  This also could inhibit mouse & keyboard inputs, and background disk flushing.   Running the Engine at a lower priority will allow these components to remain responsive even during periods of heavy workload processing.   Recommendations This setting should be enabled in all Server deployments (Controller, Worker, Gallery) to ensure Windows components, and the Alteryx Server components always get priority over intensive Engine processes.    Conclusion   The Alteryx Engine has many settings that can impact workflow performance and resource consumption.  Understanding how each of these settings are used by the Engine, and how some settings even impact others, will allow administrators to configure Alteryx Server optimally for their environment and usage.      References https://help.alteryx.com/server/current/admin/Configuration/SystemSettings/Engine.htm https://community.alteryx.com/t5/Alteryx-Knowledge-Base/The-Alteryx-Engine-101-The-Basics/ta-p/405649 https://community.alteryx.com/t5/Engine-Works-Blog/The-Periodic-Table-of-Alteryx-tools/ba-p/64120 https://community.alteryx.com/t5/Engine-Works-Blog/Measuring-and-Scaling-a-Private-Server/ba-p/8786