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.
I had an interesting error come across today when I was working on a new Nintex form list. I have been doing some power user training in my company lately and a few of my users have taken the plunge and started creating their own electronic forms in Nintex.
Which is awesome! It’s a great feeling when you demonstrate something to someone in a training session and then see what they are able to go and create on their own.
In this case, though the user had designed a great looking form, but when they went to submit the form once it was complete it gave the following error:
Which was very odd as I had never seen an error that gave all zeros for a correlation id on and error in SharePoint.
So I started to do some digging online and I noticed this was a common question that has come up before for several users in the past, but no one online I had seen had dealt with this in the context of creating and submitting forms.
After some more research I had a hunch that this was being caused from a required field on the form that was missing data when the form was being submitted. So I checked the form in Nintex form designer, and sure enough!
I saw that the “Title” column was not on the form, but in the list settings was still set to the required option like it is out of the box in SharePoint.
So I went into the list settings and turned off the required setting for this column and then went back to the form and tried submitting it again.
Everything submitted as it was supposed to and now I can move onto more form troubleshooting.
I hope this helps anyone else who runs into this error again and if you have any thoughts or comments, please feel free to add them into the blog.
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.
Happy Friday everyone,
I wanted to let you know of a current issue that we are seeing in our SharePoint Foundations 2013 farms. Right now as far as I can tell this shows up if you have the July, August, or September 2014 CU added to your SharePoint Farm
You can read about it here:
The TL:DR version is the people picker is blank when you go and open an existing item in a list using the edit form. This is kind of a pain because we use this type of field EVERYWHERE in our farms.
I want to get the word out to as many people as possible at this point and my next plan is to open a support ticket with MS support.
Feel free to post more comments below and let me know what your experience is with this. As I have more details and a fix, I will post it here.
Update here is the workaround that I got from MS Support:
- Went to the tasks list “Tasks”
- Selected an existing item >> edit item
- We were not able to edit the form
- Went to site contents >> tasks >> settings
- Went to library settings >> Advanced settings
- Selected “NO” to Launch Forms in a dialog option
- Went to tasks list “BI Tasks”
- Selected an existing item >> edit item
- We were able to edit the form
- Went to site actions >> edit page >> web part >> Web Part Properties -> Activate Server Render option
- Click Apply-> OK -> Stop Editing
- Checked the item by editing it
- We were able to see the name in Assigned to field.
Hope this helps, but would like to see it fixed so we don’t have to correct this all over the place…
When SharePoint Server 2013 was first released, I was curious what new things I could do with it. I saw the new search capabilities, a different look and feel, a similar management interface, and several other BI things that made me happy. I then also realized that I support SharePoint Server and also the free version SharePoint Foundations. In SharePoint Foundations you get SOME of the things that makes SharePoint great (like Search for example), but with Foundations there are usually strings attached to that functionality.
In SharePoint, if you create your farm by clicking on all the defaults and using the wizards your databases look like this:
With SharePoint Foundations 2013, we don’t really have the option to create search by scripting with PowerShell… or do we?
Originally my research pointed me to Gary LaPointe’s blog here.
Which is great because this is in PowerShell and I can understand this, but it still doesn’t give us what we are wanting in the end like this:
Fortunately I found the following post by Jasjit Chopra’s blog here.
Finally!!! What we have been searching for all along! One thing to note at this time is that I have tried this myself on two different farm configurations (a three tier farm and a single box farm) and in both cases the search service and databases were created with the clean names and the service functions just fine.
I’m doing my happy dance now… enjoy!
Hello again SharePointers!
I wanted to get the word out on another bug that seems to have reappeared in Performance Point in SharePoint Server 2013. Originally this issue popped up as a problem with the grid view being cut off towards the top. Example below:
This issue was corrected in the June 2013 CU for SharePoint Server here
But after testing both before SP1 (August 2013 CU) and after SP1 in my farms, I see the following issue pop up when multiple pages exist in the web part. This is referred to pagination I believe and causes a behavior that we see in our farm like the screenshot below:
For us it’s more of an issue about our users not being able to view the proper info they need. I have filed a case with Microsoft support and will keep everyone up to date on how it progresses.
Fortunately as I was typing out this post I got a message from someone that this is an official bug and will be submitted to the product group to be fixed.
So I am glad that it is not just my farms that see this issue… 🙂 But I also hope that this provides some help for those of you seeing this issue as well. As soon as I get word on which CU this new fix will be in, I will let everyone know.
Thanks for visiting!
In my previous two posts I focused on a problem created by the install of the October 2013 CU for SharePoint 2013 Server. It basically disabled the ability of your users to launch dashboard designer (DD) after installing the cumulative update.
In December 2013 another CU was released, but didn’t do anything to address the problem of not being able to launch DD. If anyone of you have a SharePoint 2013 farm and use BI, this is kind of important. It’s kind of like owning a cheese factory and someone comes along and disables all of your cows from giving milk.
Good news though! After checking the MSDN forums I came across the following article:
Originally this article listed 3 files that needed to be replaced in all of your SharePoint farms to correct the CU issue, but initially I tried this and it did not resolve the problem. But after a few days two more files were added to be replaced as well.
The great news is that I confirmed that this does fix the original issue brought on by KB2825647 and now we can launch DD with the October 2013 and December 2013 CU applied to my SharePoint 2013 farm! Oh happy day!!
Maybe this will get integrated into the February 2014 CU, but secretly I hope we get to see SP1 for SharePoint 2013 before that.
We’ll just have to wait and see. Happy SharePointing everyone!
Happy Friday again SharePoint folks! I bring you good tidings of joy in this holiday season, but all of this doesn’t come without a lump of coal from the world of SharePoint 2013.
According to this article put out:
The December 2013 CU for SharePoint 2013 has been released, but unfortunately for those of us looking for this CU to fix the broken Dashboard Designer that was a result from the October 2013 CU for SharePoint 2013, it isn’t going to happen.
I guess we all must still dream of Service Pack 1 coming hopefully next year. I hope this does get fixed eventually because if you are like me and have a Business Intelligence effort going on at your company and you use SharePoint 2013 for it, Dashboard Designer is kind of critical in this effort.
So if you are going to update your farms, feel free to, but be warned that DD is not going to function after you install it.
Everyone have a Merry Christmas and a Happy New Year!
Hello again from SharePoint land!
It’s been a while since we talked about KB2775353 and how it made our SharePoint 2010 servers where I work extremely sad and kept them from correctly displaying our BI dashboards in 2010 (see here).
I was originally told when I found this bug that the fix would be put into a patch around the August 2013 CU timeframe, and sure enough with the newest round of patches released I went and got my grubby little hands on it. It took a few days for us to properly test it here, but I can confirm from our internal testing here that this patch corrects our display issue with our dashboards! Yay!!!!
Just to be clear, this is my personal scenario of how things went, YMMV.
We originally patched our farm to the April 2013 CU for SharePoint Server 2010 due to an incorrectly applied patch that came in from windows update, so we were originally forced to move to the April 2013 CU. For the meantime we have been working around this issue by displaying our dashboard items in a different way. We notified MS support of our issue and verified it was indeed a bug and they went to work on correcting it.
So when the August 2013 CU for SP2010 came out a few days ago, I had a couple of options on how to bring my farm up to the latest patch level. What I ended up doing was patching my farm with SP2 and then after checking to make sure everything applied correctly from this patch, applied the August 2013 CU for 2010.
After this, we had to redeploy our dashboards back to how they were before the April 2013 CU mess and verified that everything looks good and is back to normal.
Now I can put all of this mess behind me and work towards upgrading everything to SharePoint 2013. I hope this helps anyone else who runs across this scenario with their BI setup in SharePoint 2010.
Thanks for all the twitter questions and replies to my previous post everyone! I think with 2013, I will be more conservative in my patching going forward…
I thought I would take this opportunity to let everyone know about a bug that was discovered by our BI team this week with the April 2013 CU for SharePoint 2010.
The bug is mainly affecting PerformancePoint Services in SharePoint 2010 Server.
Background: Our users have a set of KPI’s that are published on a couple of dashboards that contain operational data. Normally when the dashboards load, these graphs, charts, and reports are hidden to improve initial loading performance. When the user clicks on the proper cell for each KPI, the dashboard will create 1-3 graphs, charts, reports or a mash up of the 3 to display further details.
Issue: We noticed earlier this week in our environment that when we would click on a cell for a KPI, none of the charts, graphs, or reports for that KPI would display properly. It was just like they weren’t being displayed when the user clicked on a cell. Our users have many important reports they get to by this process, so this affects us in a big way.
One odd thing to note that we found in our troubleshooting of this issue is that if you edit the page in SharePoint that each dashboard is on, the graphs and charts and reports show up just fine. When you stop editing the page in SharePoint, the dashboards go back to not showing them. Weird, huh!!??
Workaround: For now the only workaround we have for this issue is to display all of our charts and graphs and reports on the dashboards at the same time. This does slow down our performance a bit, but this is better than the users just not being able to see the information they need at all.
As we learn more about this, I will update this post.