Why you should disable Nintex Automatic Database Mapping

There are a few things that after I learn them, make me want to immediately share with as many people as possible. This is definitely one of those moments.

After starting a migration project where I work involving some cleanup with Nintex workflow content databases, I’ve run into something that everyone should check in their SharePoint environments right away.

It’s a setting under Central Administration for Nintex and the setting I want to warm everyone about is Automatic Database Mapping.

When you set up Nintex as a solution in SharePoint the install is pretty straight forward and not all that difficult in getting set up and going quickly.

One part of getting Nintex going after you install it is creating a config and content database to start using it to store information about the workflow history and config of the service itself in SQL.

Its at this point when you start that I recommend that you go in and turn OFF automatic database mapping.

Why am I urging you to do this so intently?

Well let’s just say I am working on a migration now with an environment that’s been using Nintex for about 3 years now, with a big config database (around 100GB or so) and multiple Nintex content databases with automatic database mapping enabled… oh and in this farm, there are about 30-40 site collections using Nintex actively.

Now at this point my main goal with this migration is to consolidate the larger Nintex sites into their own content databases.

But with automatic mapping enabled, this is going to make my job a lot harder to sort out.

Now I hope you see why this is important to do when starting at the beginning of a setup. 🙂

Here are the steps to make this change in your SharePoint setup.

Open Central Admin, and go to the Nintex section and look into the Database Management section:

Once in this section, go to the Manage area of databases down at the bottom of this section:

From here you should see the following option where you can make the change to disable automatic mapping here:

Here’s the spot!

Once this is done and you click okay, then you will next need to map your existing SharePoint content databases to your existing (or even better newly created and segregated) Nintex content databases.

Just make sure that as you do this to make sure there is no active work going on for the sites you are working with. Also it wouldn’t be a bad idea to do an IISRESET as well to make sure the settings you changed take effect right away.

Trust me, doing this when you start will save you alot more time and effort than having to take a bunch of big existing databases and map them to newly created blank databases to logically separate the content out.

I hope this helps with anyone starting out with a new Nintex install or if you have to go down the cleanup road like I am as well.

Thanks! -BJ

Advertisements

Migrating Nintex Workflow Content to Another DB

Here lately I’ve been looking into doing some cleanup for Nintex related databases in a SharePoint farm, so I thought I would share a short write up I did for a few other folks on the process of moving content in the context of dealing with Nintex content databases.

Taken from : https://community.nintex.com/docs/DOC-1092

First take backups of Nintex and content databases involved

Go to central admin under the Nintex workflow section and pick the databases option.

From here scroll down and check your DB mappings to make sure you know which DB’s will be involved in these changes

Next go back to the Nintex Databases section and create a new blank Nintex DB to use for migration (name ie. Nintex_Content_SiteName)

If you are moving SharePoint content as well, go into Central admin under Manage Content Databases and create a new one there, or you can use PowerShell to create the new SharePoint Content DB and attach it to the farm.

The SharePoint content can be migrated by normal backup-spsite and restore-spsite methods specifying the new Content DB created to make sure the SharePoint info goes to the new DB.

Or this can be done using the Move-SPSite command through PowerShell as well with an IIS RESET as the last step.

Now to migrate the Nintex Workflow info you will need to do a few more steps:

  1. Stop the web app that contains the Nintex info being moved
  2. Also stop the SharePoint Timer Service on ALL SharePoint servers in the farm so no actions take place in the background during the move.
  3. Run the nwadmin -o movedata command to migrate the content to the new Nintex DB
    1. Example like: nwadmin -o moveData -Url http://webapplication.caresource.corp/sites/sitename
  4. Once this command executes you may see errors or other info about the moved workflows. If there are failures you may want to choose the option to roll back the changes.
  5. Once the command finishes successfully, restart the SharePoint Timer Service and the web application in IIS in order to get everything working correctly again.
  6. Recheck database mappings in central admin to make sure the items are in the newly created database
  7. May also want to run NWAdmin.exe -o CleanTaskRedirects [-test]
  8. Specify the old nintex DB to see if there are any leftover workflows for lazy approvals.
  9. If not, then remove [-test] from the previous command and it should remove any other info to clear out the old Nintex DB

Again, check your mappings in Central Admin to make sure everything is now separated as it should be and good to go

I hope this helps for anyone that has to go through this process in the future. I’m still learning alot about it myself, so once I’ve had plenty of practice, I may post an updated article as well.

Thanks everyone! -BJ

Nintex item permissions error

Recently I ran across a really tough issue that I had with one of my workflows that kept failing right before the approval step of the workflow was being sent.

Below is an example of the workflow I had with the listing of the error I was getting:

I tried going over this many times and even went and created a whole new list for this and imported the workflow into this new list with a newly build form to make sure I could minimize any other variables in the error.

Well the bad news was even in the new list I created and imported the workflow into, I still got the same error. So, I started digging in with some help, and was ultimately able to find the source of the issue on the step of the set item permissions in the workflow.

It turns out that when this workflow was originally created the set item permissions had several users explicitly defined in it to grant permissions to the item on before an approval would take place.

What I didn’t realize until I looked deeper into who all was being given access to this item was that one user who was specifically designated in the action was no longer with the company.

So, when the workflow would go out and try to match this person with a valid AD account, it would error out and not allow the workflow to go any further.

The location of the error was in the ULS of SharePoint, but only when verbose logging was turned on, of course…

So in the future I will always from now on, check to make sure that all users being granted access to items in workflows have valid accounts.

If you ever run across something like this I hope this tip will save you sometime and allow you to get right to the solution.

Enjoy!

Nintex workflows not running from adding new server

This past week I had an issue of some of my Nintex workflows just not running for some reason. They would get to a certain point and just decide not to complete the next step.
Recently i added a new application server into my farm and I did not realize that in order for these workflows to run correctly they needed to have the Microsoft SharePoint Foundation Workflow Timer Service only running on the web front ends (web servers), since that is where the Nintex service actually runs.

 

So if you are running Nintex Workflow in your farm and you have a multi-tier farm for your SharePoint setup, go to central admin and check your service settings like below:

BlogPicTo be clear once more, this Should be running on your web servers if you have Nintex workflow, but should not be running on your application servers.

 

I found this out the hard way after having to contact Nintex support one day.

 

Hope this helps others,

BJ