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!
Happy Friday everyone! Even if it’s Friday the 13th…
I wanted to post this update about an issue that is related to the October 2013 CU for SharePoint Server 2013.
You can find the summary of this issue from Todd Klindt’s patch list here.
The frustrating thing about this issue is that I have confirmed that I have this same issue after applying the patch in one of my farms and that the “fix” that is suggested from this article does not work to bring Dashboard Designer back up for me.
So I hope that in the next few days we see this fixed with the December 2013 CU, but somehow I think that if it doesn’t make it here, we may see it in SP1 which I hope comes out before the next CU.
You can read more about SP1 for SharePoint 2013 here as well.
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.