This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
This article includes details on using OpenSSL to create a Certificate Signing Request (CSR) to send to a Certificate Authority (CA), generating a self-signed certificate, installing the certificate, and configuring Alteryx Server to use the certificate.
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.
If a Server is freezing with jobs stuck in an initializing state, there may be resource contention occurring due to the configuration of System Settings. This article provides best practice formulas to ensure the optimal settings for resource utilization.
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.
Product - Alteryx Server
All permissions on the future Global Workspace
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:
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:
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.
The Visualytics Insight tool was first introduced with Alteryx 2018.3. Insights allow users to create visual, interactive dashboards to gain deeper insights into your data and can be shared through an Alteryx Private Gallery. In order to have Insights load successfully on your Gallery, there are a few changes you need to make to your Server System Settings.
Configuring SAML on Alteryx Server for Active Directory Federation Services (ADFS)
Alteryx Server has the ability to use most identity providers that support the SAML 2.0 standard, and from my testing, ADFS is no exception! The following information will assist with configuring Alteryx Server to be functional with ADFS.
Please note the following information is based on third-party software and processes may be slightly different on older or newer versions of the software. The following was created against ADFS v4.0 running on Windows Server 2016 and Alteryx Server 2019.2.
AD FS Server
Account with access to perform administration tasks
All users that will login must have an email address attribute
Alteryx Server >= 2018.2
Account with access to perform administration tasks
SSL/TLS Certificate Installed on Alteryx Server (Self-Signed certificate is not recommended)
Verify that your Alteryx Server's Gallery function has been configured with SSL/TLS enabled on each Gallery node in the environment and that a proper SSL certificate is installed. Instructions are provided in the link above.
This and following steps will require an ADFS administrator. Open the AD FD Management utility (Start > Windows Administrative Tools > AD FS Management)
Click Relying Party Trusts from the console, then click Add Relying Party Trust...
Click Enter data about the relying party manually and click Next.
Type a Display name for the trust. I placed "Alteryx Server" here, but you can use a name that best identifies the connection for you, such as a server name or other easily identifiable name. Then click Next.
Click Next on the Configure Certificate page.
Check the box for Enable support for the SAML 2.0 WebSSO protocol. Type the URL of the Alteryx Server's SAML endpoint in the Relying party SAML 2.0 SSO service URL box, which typically will be the base URL of Alteryx Gallery with the addition of "/aas/Saml2". Once you have added the proper URL, click Next. Note: this endpoint may be case sensitive depending on settings in your environment. I would recommend entering it with the capitalization as shown in the screenshot and example below. Example: Gallery URL: https://trn-srv-07.cs.alteryx.com/gallery SAML Endpoint: https://trn-srv-07.cs.alteryx.com/aas/Saml2
In the Relying party trust identifier, type the same SAML endpoint as the previous step and click Add to add the URL to the list below. Click Next.
Select Permit everyone from the Access Control Policy and click Next. Note: You may wish to configure this option differently depending on the environment and whom you wish to be able to authenticate with Alteryx Gallery, or you may wish to setup Multi-Factor Authentication (MFA). Specific access permissions and these types of setup are outside the scope of this article.
Click Next on the Ready to Add Trust page.
Check the box next to Configure claims issuance policy for this application and click Close.
Within the new Claim Issuance Policy window, click Add Rule...
Verify the Claim rule template is set to Send LDAP Attributes as Claims and click Next.
Type a desired name for the rule within the Claim rule name box. From the Attribute store drop-down, choose Active Directory.
Using the following table, set the appropriate options within the Mapping of LDAP attributes to outgoing claim types box. Click Finish. Note: The following outgoing values are case sensitive and will need to be typed except for "SAM-Account-Name".
Outgoing Claim Type
On the Claim Issuance Policy window, click Apply to apply the settings, then click OK.
You will now need an administrator with access to the Alteryx Server machine(s) running the Gallery for your environment. Connect to the machine remotely via Remote Desktop.
Open the Alteryx System Settings application, then click Next until you are at the Gallery > Authentication page.
From the Authentication Type box, click the radio button next to SAML authentication. In the Select an option for obtaining metadata required by the IDP, click the radio button next to IDP Metadata URL. !Warning!: It is not recommended to change the authentication type once you have established the persistence layer (e.g. MongoDB) and started using a particular authentication method in your environment. Differences in user account structure will be likely to result in errors in the Gallery if the authentication method is changed in an established environment. If you are changing authentication methods, it is recommended to create a new persistence database!
From the SAML IDP Configuration box, set the ACS Base URL to the root of the Gallery URL plus "/aas". Example: Gallery URL: https://trn-srv-07.cs.alteryx.com/gallery ACS Base URL: https://trn-srv-07.cs.alteryx.com/aas
Set the IDP URL (also known as Entity ID) to the Federation Service identifier value from ADFS. Example: https://sts1.cs.alteryx.com/adfs/services/trust Note: If you are not positive on the value for this, ask your ADFS administrator or download the metadata XML with the link you are using in the next step and look for the "entityID".
Set the IDP Metadata URL to the location of the Federation Metadata xml file provided by the ADFS server. Example: https://sts1.cs.alteryx.com/FederationMetadata/2007-06/FederationMetadata.xml Note: If you are not positive on the value for this, ask your ADFS administrator.
Click Verify IDP. If all goes well, you should receive a message similar to the following: Note: See the Common Issues section below for tips on troubleshooting!
Click Next through the remainder of the System Settings dialogs, then click Finish.
(Optional) Return to Step 17 if you have additional Gallery node(s) to configure.
Once all Gallery node(s) are configured, attempt to access your private Alteryx Gallery and log in with your fresh new SAML configuration!
AlteryxAuthorizationService.exe has stopped working or there is a failure to set the Default Gallery Administrator -Turn off IE Enhanced Security Configuration on the Alteryx Server if you have crash errors while verifying the IDP information. This feature can be turned back on once you have the configuration in a functional state. https://www.limestonenetworks.com/support/knowledge-center/17/70/how_do_i_disable_internet_explorer_enhanced_security.html -Verify that the values in the SAML IDP Configuration are correct for your ADFS server. -Verify that the ADFS server was configured with the correct claim attributes. -Check the AlteryxAuthorizatonService.exe logging directory (%PROGRAMDATA%\Alteryx\Logs) for any clues. -Open Event Viewer within Windows and look for errors that may be of use in the Application log. -If still stuck, reach out to our Support team. I'd suggest providing the following: 1. Values set in the Alteryx System Settings application for SAML 2. AAS log files (found in %PROGRAMDATA%\Alteryx\Logs\) 3. Configuration screenshots for ADFS
Alteryx Server System Settings Deep Dive - Engine
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.
The Alteryx Server System Settings configuration wizard allows end users to modify the Engine configuration settings:
Any changes to the configuration settings in the System Settings wizard are applied to the RuntimeSettings.xml file, found at:
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.
“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.
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.
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.
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:
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.
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.
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.