SharePoint Musings

Synopsis I recently ran into this issue while deploying SharePoint Server 2013.  Everything seemed to go according to plan, before SharePoint Gods decided to throw yet another lightning bolt my way. Shortly after getting the software prerequisites successfully installed (accompanied by a couple of reboots of course), it was time to install the SharePoint Server software bits.  About a minute after executing the bootstrap (setup.exe) this error message comes up: "Setup is unable to proceed due to the following error(s): This product requires Microsoft .Net Framework 4.5" Here is an exact screenshot: Unless I was loosing my mind, I was pretty confident the software prerequisites installation completed successfully, which performs all the necessary checks and balances on the system, including the installation of .Net Framework 4.5. The Problem After running around and attempting to re-install .Net Framework 4.5, which by the way didn't resolve the

Yesterday Microsoft announced general availability of SharePoint 2016 along with a slew of new features coming our way in the near future.  This marks a very exciting time for those operating in the SharePoint ecosystem.  If you haven't had a chance to attend Microsoft's virtual live event, and have a couple of yours to burn, you can still register and view the recording here: Future of SharePoint . If you just care about the cliff notes, here is a quick summary of whats being made available as of yesterday and some exciting new features we'll get to leverage down the road.  This applies to both Office 365 SharePoint Online and SharePoint Server 2016 on-premises counterpart. Available this quarter - Q2 2016 Modern document library experience (in flight to First Release tenants) SharePoint library UI is getting a makeover.  New simplified UI (much like OneDrive) allows for adding columns on the fly as well as slicing and dicing how data is presented by applying views

Synopsis I'll go out on a limb here and say that updates and patching is no ones favorite thing to do.  But nonetheless it is a crucial piece of the puzzle in keeping applications/platforms/systems at an optimal level and more importantly - supported! The scary reality of applying Windows Updates (not CUs or SPs) to servers hosting our SharePoint environment is that you are at the mercy of the changes that are about to be applied.  They frequently go without a hitch, and sometimes they DO NOT.  When that happens you typically spend countless hours scouring the event logs and ULS because those end-user error messages are just sooo helpful, like this one: "We're sorry. We ran into a problem completing your request. Please try that again in a few minutes" The Problem A client of mine was performing some routine scheduled maintenance on their SharePoint 2013 farm, and by routine maintenance I mean installing queued up Windows Updates.  Smooth sailing, right?

Synopsis Before we start talking about the problem let's understand the setup here.  We have a SharePoint 2013 intranet site that is also configured for access outside of the corporate network.  Employees use the same URL to visit the site both internally and externally via standard ports (80 and 443). Internal URL: http://sharepoint.domain.com Public URL: https://sharepoint.domain.com The site URL has been added to the Local Intranet zone in Internet Explorer for passing domain credentials. Alternate Access Mappings have been configured in such a way that if a user requests the site over HTTP they are automatically re-directed to HTTPS. Internal URL Zone Public URL for Zone https://sharepoint.domain.com Default https://sharepoint.domain.com http://sharepoint.domain.com Default https://sharepoint.domain.com Web application has been configured to use Kerberos protocol for authenticating incoming c

In recent travels I've encountered what seems to be either a product limitation or a bug. After digging around some it appeared that I wasn't the only one facing this challenge, and unfortunately there wasn't a concrete enough solution or workaround out there. Hence the blog post hoping to save some of you the unnecessary hair-pulling which I had to endure. My task was fairly simple; "Start a Site Workflow using a Custom Action button". The first part, creating a Custom Action, is trivial. This can be done in Visual Studio or SharePoint Designer. For the sake of simplicity I used SharePoint Designer. Create a Custom Action button Start up SharePoint Designer 2013 and connect to the desired site. From the left navigation select Lists and Libraries. I'm using a simple list called "List One". Boring name, but easy to follow. :) Click on the list name to manage list settings. From the ribbon select Custom Action button then click View Ribb

Introduction At some point you probably thought about incorporating glossary functionality as a part of a larger solution, or perhaps you were simply looking for providing a more intuitive way of filtering hundreds of items within a List or Library. Now there are countless web parts out there that you can either purchase or download from the SharePoint Store free of charge, and they all come with their own set of bells and whistles.  However, if you are looking at building one yourself, well look no further. To accomplish this we will need three major ingredients: SharePoint Page (either Wiki or Publishing will work) SharePoint List/Library with some content (Files/Items) HTML Form Web Part Let's Implement In this post I’m using a simple Wiki page, but you can also use a Publishing page as well.  We just need a canvas to display our glossary. I presume you already have a list or library that contains some content which is applicable to this concept.  I’m