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.
Recently I was working on a migration of a couple of big sites moving them to their own content databases and it didn’t exactly turn out as I planned.
So more than anything, I wanted to use this post to describe what happened and mention some tips and other things that may help others out in the future if you ever run into trouble when trying to break out sites into their own databases.
Here are the major events that happened in the migration process:
- Created DB under central admin
- Used Move-SPSite to move one site from another content database
- Content stuck on Move-SPSite, never finished
- Restarted all servers
- When came back up, new destination database was in recovery
- Recovery process used all SQL resources, major slow down of farm (sad time)
- Looked into SQL logs to check status of recovery thinking new destination database would come back up
- Actually after recovery finished, I still had no access to content created in new content database
- Checked and under central admin checked site locks and quotas
- Turns out entire site still on old source DB
- Hadn’t been copied over, even though SQL showed a populated database
- Site lock had been switched on all the way to no access
- Users going to site would get a 403 forbidden message when trying to access
- Went under site locks and cleared the lock
- Once this was done, content access returned to normal
- Original content and under Central admin still said content was on source DB
- New destination content DB under still showed also that it contained no content
So in the end, the big lesson learned here was that even though I could check SQL and see that the new DB contained information, SharePoint hadn’t moved the site over to the new content database.
I did some research and there are timer jobs that run gradual site deletions, but I don’t think they applied here. Either that or I switched back to the original database before anything else was allowed to happen.
In the future, I may just use Backup-SPSite along with Restore-SPSite because that command also has the ability to specify a new database to put the site into when the backup is restored.
I hope these tips save you some time and headaches in the future.