Alteryx Server Knowledge Base

Definitive answers from Server experts.
Note: Alteryx Community may experience brief downtime during 12a-4a PT hours. We apologize for any inconvenience.
How to connect to Alteryx Server MongoDB using the command line
View full article
How To: Server Cases Attach Logs
View full article
If your mongo database seems to take up a lot of disk space, you're not alone. You do need to allocate sufficient space for it. But you can take some steps to compact it as well. Read on for more information on how to proceed.
View full article
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.
View full article
This error typically occurs when using an unsupported MongoDB version for instance MongoDB 4.2+.or using a Server Usage Report version not compatible with the Server version.
View full article
One of the three database options when setting up the Alteryx Server is to connect into a User-Managed
View full article
This KB outlines how to enable MongoDB logs for troubleshooting purposes
View full article
After having used MongoDB logging for troubleshooting purposes, you can now safely turn it off.
View full article
Alteryx Service throws corrupt record error when a MongoDB backup script is in progress
View full article
There are occasions where it is necessary to identify the ID of a Workflow or Schedule. These are easy to find in the URL.
View full article
How to determine which User deleted a Gallery application
View full article
This KB gives you fundamental understanding on how to extract a list of users and their permissions on the Gallery. Only relevant for versions 2020.1+ with Windows Authentication.
View full article
This KB provides you with steps on connecting to a User-Managed MongoDB using Robo 3T
View full article
When migrating a MongoDB to a new machine all the relevant steps in https://help.alteryx.com/20201/server/server-host-recovery-guide (use document for your Server version) should be followed. Skipping steps can cause issue occurring later.
View full article
Alteryx Service Fails to Start when Mongo Fails with Error - “Input string was not in a correct format”    When trying to start the Alteryx Service, the following error can be seen in the Alteryx Service Logs:   FATAL,1,,RegisterClasses,,,,Axx-xxxxx100,,,,,,Input string was not in a correct format.,   Environment   Alteryx Server Windows Operating System   Diagnosis   This error message is coming directly from MongoDB and while very generic, it is telling us that the driver is unable to handle the data that is being sent to MongoDB. The Alteryx Service will fail to start and you will most likely get some sort of popup error when trying to start the service from the Windows Services menu.   Is FIPS enabled on your machine? If so, See Solution A.   Are you in a multi-node environment? If you are unable to start the Alteryx Service on a node that is not the Controller, see Solution B.   Cause A   FIPS is enabled on the Machine   Solution A   This error occurs because the encryption Alteryx Server uses for inter-service communication won't happen if FIPS is enabled because .NET will block the requests.   Per this article : “FIPS Compliance Encryption Issues In the .NET framework, three different versions of the SHA256 hashing algorithm, each having different security levels and speed are available. The fastest one among them has not yet been submitted for validation. However, it is believed that it is as secure. Enabling FIPS mode in systems with Microsoft OS will break the .NET applications as they probably use latest cryptography algorithms that are more efficient. And, if the .NET applications must necessarily work then a slower, much less efficient cryptography algorithm must be used.”   The Alteryx Gallery uses .NET completely for communication with MongoDB, there is not another option for communication.   Resolutions\Workarounds: There is currently no workaround to get the Alteryx Service to start with FIPS enabled. FIPS must be disabled completely on the server machine to get the Alteryx Gallery to communicate with Mongo correctly and get the service running. The impacted policy is named System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.   To get to this setting:   1. Open the Local Security Policy window from the Windows Start menu 2. Navigate to Local Policies > Security Options 3. Select the correct policy   Make sure that group policy does not enforce FIPS after reboot. To verify that FIPS has been disabled, make sure that the “Enabled” registry key located here HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy is set to “0”:     Cause B   Generic failed Connection to MongoDB (Not FIPS).   Solution B   The error states that for whatever reason, MongoDB is not able to understand the information that is being sent. A failed connection to MongoDB can also cause this error, though it can be difficult to pinpoint the root cause. There are a few things that you will want to check to see if they are causing the issue:   1. If you have a multi-node environment and are configuring the Gallery, confirm the following in the Alteryx System Settings under Gallery > Persistence. 1. Confirm the password is correct. This password should be the user (not-admin) password from the System Settings on the Controller. 2. Confirm you have the port appended to the hostname (default port for embedded MongoDB is 27018) hostname:port   2. Enable Mongo logging and see if MongoDB gives more details on why the error is occurring  3. Test connecting to MongoDB through another source (such as Robo 3t) and see if this gives more detail on why the error is occurring.          
View full article
If you are upgrading your Alteryx Server from an older version to 2018.1 or greater, your MongoDB will be migrated from Mongo 3.0 to Mongo 3.4 as part of the process. This article details how to troubleshoot a potentially failed migration. 
View full article
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.
View full article