Switch to Claims Based Authentication and Nintex

If you're making the switch to Claims-based authentication in SharePoint, be prepared for lots of manual clean-up especially with Nintex (about 20 hours total for one web application with several workflows).  Here are a few things I found:

• Authenticated Users (if used for access) needs to be re-setup
• Nintex Workflows need to be republished
• Some Workflows need to be restarted
• This was about as messy as upgrading from 2007 to 2010.

Be sure to run this in test prior to production... If you're not 100% comfortable with the procedure below, I suggest going through the trouble of making a copy of your production environment... I know that can be a lot of work, but may be worth it since switching back from claims-based is not supported.

To make the switch to claims based authentication I used the steps provided by the MDSN library.  I used the steps listed in Tip 2 from the article... here is the process I used for a single web server:

1. Log on to the SharePoint server with the Farm Admin account.
2. In SharePoint Management Shell, run "get-SPWebApplication" and note the one to switch.
3. Run the PowerShell script in the MSDN article and then after the $wa.MigrateUsers($true), run $wa.ProvisionGlobally().
4. Once I was then able to log on with an admin account I starting verifying/updating "Authenticated Users" on the site and subsites, Search, and MySites.  In Claims based, Authenticated Users is now, "All Authenticated Users".
5. Once things settle down, check all of your Alternate URLs... you might want to do this with a clean profile so any cached credentials aren't showing false problems... or delete them using Credendial Manager in control panel.
6. Also check any outlook connections or mapped drives (drive mapped to a document library).
7. Check the application event log for errors.
8. Use the ULS logs for any errors you see with Correlation IDs.
9. For Nintex I had several errors... but basically the same thing multiple times, "Object reference not set to an instance of an object" for scheduled workflows, as well as opening workflows for editing.  To resolve I opened the workflow, exported the entire workflow to a file, created a new workflow, imported the file, then published the new workflow replacing the old one.  Any stored credentials will need to be verified.  In several cases I then had to restart workflows that were running at the time of the switch to Claims.  I ended up rebuilding one older workflow because it was faster than troubleshooting each step... and it needed it anyway.