I was updating my test and then production servers this week when I did a bit of digging and found the following article on a possible SSRS issue with the August 2013 CU for SharePoint Server 2013. The author of the post is Craig Love
You can find it here:
I however cannot verify that it is causing any issues. We have several reports in our environment that use this type of setup, but after installing the patch in both our test and prod environments this week, I have not seen any side effects from this… yet. 🙂
Anyhow I wanted to get this one out there in case anyone else sees problems related to this.
Recently we created our first set of SharePoint 2013 sites using Host Named Site Collections. To get a quick refresher on this you should really read the following article by Kirk Evans (@kevans) to get a bit up to speed. You can find it here.
We had an interesting after effect for our users once we did this that I thought I would let everyone else know about.
Originally we had our SharePoint 2010 sites setup under path based site collections with the structure of http://webapp/sitecollection. This has been working out great for us so far, but many of our sites that we first created as sub sites in a site collection have grown to a size where we really needed to separate them out onto their own site collection and content database since they showed signs of only getting larger (like bigger than 50GB).
Since this is a bit trickier than simply doing a backup-spsite because since these were subsites, we had to use export-spweb to break them out of the site collection and then use import-spweb to move them into a new Host Named Site Collection (HNSC) named http://sitecollection.webapp.
Once we created our HNSC through PowerShell and finished the import-spweb to bring the sub site into the new site collection, we started getting calls from users about not being able to log into the new site. Once I logged into a user’s machine to see what the issue was I saw what was happening.
When the user went to the new HSNC 2013 site for the first time, they were being prompted to log in with a username like this:
Normally the users were used to seeing:
Once I corrected their login back to domain\username, then the prompt would go away and they could get into the site and they would not see the prompt any longer. Since this new naming was different from our standard domain I had to go into the user’s browser and make sure the new site was under their local intranet settings in their browser so the credentials could be passed properly.
Our long term fix for this was to roll out a group policy object to all the users of the site that added this new url to their local intranet section of their browser so their credentials would pass properly. Since implementing this GPO, we haven’t seen users having issues getting to the new site.
I hope this post helps anyone else who runs into this issue going forward.
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…
Have you ever had a workflow, form, or process in SharePoint Foundations 2010 that needs to reference user account info like email address, job title, or other info that needs to stay up to date?
In our setup we have many electronic forms that our users complete to request things, update things, or to ask to be approved by someone. However, if they get married, or change jobs, or some other life altering event happens, then we need to make sure that AD and SharePoint Foundations are in sync. The very first time they log into SharePoint Foundations it grabs this info and puts it into a user information list that is hidden and referenced. You can read more about this here by Tobias Zimmergren (@zimmergren). He does a great job of explaining where this is located and what it does.
Our problems came about when users changed job titles or email addresses because this info only gets added when the users first logs on and never gets updated again. <Insert sad trombone noise here>
So my buddy JP (@flagship50) took it upon himself to write a tool called the Foundation User Profile Service (or FUPS as I like to call it). It solves our problem quite nicely and keep all the pertinent information that we need for our users synced with what is entered into Active Directory.
Next we created a place for it on CodePlex so the entire world could enjoy it. Give it a once over and see if you like it. It has worked great for us so far and he is working on a 2013 version for those of you who are curious.
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.