SharePoint 2013 Usage reports empty

I have been working to get our out of the box usage reports working in our SharePoint 2013 environment.  Despite having everything configured, and the audit tracking turned on, the report was coming back blank.  As it turned out, the receivers were missing from my analytic and page usage definitions.  The data was being collected in the data base, just not pushed to the report.  In order to fix this I ran the following PowerShell Scripts.

I found my answer here http://geekswithblogs.net/bjackett/archive/2013/08/26/powershell-script-to-workaround-no-data-in-sharepoint-2013-usage.aspx.

Below are the jobs I ran and steps to fix it.

Add-PSSnapin - this cmdlet added registered Windows PowerShell snap-ins to the current session so you can use the cmdlets  and providers in the current session.  Without this your scripts will get and error when they are run.

 

Check to see if the analytic usage definition receivers are empty.

Check to see if the page requests usage definition receivers are empty.

Create the receivers.

Recycle the timer jobs.

SharePoint Index Partition Degradation

It's been YEARS since I've posted.  I'm still doing the SharePoint thing, but I have a slightly differently role now, and I thought this would be the best place for me to document different issues and resolutions I come across.  I have crossed over into the SharePoint Administrator role.  I'm excited about this and I'm learning a ton.

My first post in this new role is going to discuss SharePoint Index Partition Degradation.  I'm currently trying to get usage reports fully functioning in SharePoint 2013 (look for an additional post on that).  In our test environment I got the ever helpful "Something went wrong" error.  Thanks, Microsoft? :-)  After much research, I determined my error was due to a Search issue.  Search has quit function in our test environment.  I remembered hearing rumblings about that recently and how they kept having to re-index.  Upon further investigation, we have index partition degradation again.  How did I discover this...

First I went to Central Administration/System Settings/Manage Services on Server and located my Search Service.  I noticed it was still running so I clicked on it and then went to the Search Service the Index Partition was showing "0" with a warning triangle.

Then I ran the following PowerShell script:

$ssa = Get-SPEnterpriseSearchServiceApplication

Get-SPEnterpriseSearchStatus -SearchApplication $ssa –Text

My results: 

Confirmation that the partition is Degraded.

There are a couple of solutions to fix the index partition, but I had to know WHY it kept happening.  I stumbled across this https://social.technet.microsoft.com/Forums/sharepoint/en-US/084c736e-75de-4538-8927-7d83362c0b8f/indexing-component-status-is-degraded-sharepoint-2013?forum=sharepointadmin....  SPACE!  A space issue.  My test server is showing this:

We can continue to re-index and run the search manually, periodically, or we could remove the bad partition and create a new using the following script: (found on this site:  http://sharepoint.stackexchange.com/questions/88697/how-do-i-fix-a-degraded-sharepoint-2013-index-partition-when-there-is-only-one-o )

The issue is, re-indexing or creating a new partition is not fixing the root cause of the problem.  I suspect, the only way to fix this is to increase the space on the server.  Our team is planning to rebuild our test environment as part of a separate initiative next week, so for now, we let this sit.  Our environment will be closely monitored for space after the rebuild and if this problem resurfaces, we will go do the path of acquiring more space....stay tuned.

Creating submit forms in SharePoint

Yes, I know the title of this site is "SharePoint for the Non-Developer". That implies, to me, that this is for someone that does not code. Well, I had to enter the "developer" world.

A little background information...our "old" intranet had several submit forms where a user would complete the information, hit the "submit" or "send" button and the information on the form would be sent to an e-mail address. Until recently, we've been using InfoPath for these things. We have run into a few issues though. The biggest issue is our company does not have the Enterprise SharePoint license. If we did, we could have web enabled the InfoPath forms and we probably wouldn't have encountered the following issues.

Not only did we not have the Enterprise license, we also don't have a consistent image across the board. Some people have Office 2003, some receive the Office Suite via Softricity. InfoPath requires a local install, and the forms are really happier if they are InfoPath 2007. Oh, and some do not have InfoPath at all, and there is no plan for that to change.

All of this means InfoPath is not a good solution for our company when it comes to simple submit forms that do not require a workflow, but are simply meant for some form of feedback.

What now? Well, after much research I finally found a solution on http://www.codeproject.com/KB/sharepoint/SharePointContactForm.aspx

This is where I learned how to create a new WEB PART, yes web part, that is a submit form. this is written in C# and deployed with a .wsp just like any other web part.

If customized solutions that require code scare you, give this a try. Try it on a development box. Give yourself about two - three days if you have no Visual Studio experience just to fumble around. I had a little experience and it took me about a day - day and a half.

Happy SharePointing :)

Missing Content Editor and Summary Links web parts for our editors

Another day, another puzzle to solve. Today, our editors realized they didn't have the Content Editor web part and the Summary Links web part in their list of web parts that they can use. I'm sure there were others missing as well. These two just happen to be the only ones they know how to use. Same permissions as discussed in my previous post. Very similar resolution.

Read rights needed to be applied for all users to the Web Part Gallery. This is located under >Site Actions > Site Settings > Modify All Site Settings. Then under the Gallery section you will see "Web Part Gallery".

As with everything else I wanted to know WHY this had happened. Permissions had been tweaked as part of a clean up effort, but nothing was done directly to these specific lists. The only thing that I can come up with that makes sense is that when the permissions were tweaked, some rights were removed. SharePoint must have removed the rights from these lists as well. Now, we ended up needing to add those rights back because we took too much control away from our editors, but when that happened SharePoint didn't put the rights back on to these lists because at this point inheritance had been broken.

Is your head spinning yet? Mine is. It's all good and I really like digging in and solving these puzzles but WOW! Thing happen that you just can't anticipate.

Manage Heirarchy permissions and unable to create a page

Recently came across an issue where the "editors" of our intranet site were unable to create a page. The permissions they had were Manage Heirarchy, Approve and Edit. I had recently modified some permissions as part of a clean up effort and somehow all of the rights got removed from the Master Pages Gallery. Everyone needs READ access to this. Access is assigned at the top level. >Site Actions >Site Settings >Modify All Site Settings >. Under the "Galleries" section , select "Master Pages and Page Layouts".

This is one of the stranger things I've come across. I talked to a few others that have been doing SharePoint longer than I have and they hadn't come across this yet.

SharePoint redirector webpart based on Active Directory accounts

Our company intranet site has two audiences; home office and agents. The home office has different new content than the agent side. It's viewed as two separate intranets really, even though it's all in one site collection. Because of this we rely heavily on target audiences and redirects.

We hired an outside consultant to develop some custom webparts for us. One of those being a redirector webpart that would take Active Directory groups that we specified and redirect from one page to another. When it came time to implement this webpart it didn't work. I put it on the page and configured it but it simply didn't do anything. It was like the web part wasn't even on the page. After a 90 minute conference call with the consultant, and no progress I decided to take matters into my own hands.

There are several redirector webparts out there that make great promises. Some of them are code where you can cut and paste into Visual Studio, others are for purchase. I saw one for $500. I don't hold the purse strings where I work and since we'd already paid for a consultant to custom develop a web part I knew asking to purchase a different one wasn't going to happen. Then I stumbled upon this. (when you click, make sure you do a right click to open in new window, or you will navigate off of this page). It's a little piece of heaven.

This webpart uses the SharePoint people picker. This means, this is much easier for both myself and my end-users to use. No more remembering what the AD group names are and having to key them in just perfect. This searches and lets you select either the group or one user AD account you want.

The install is easy. Simply copy the .wsp file to the location you want to run it from, set up your stsadm commands in a batch file and run. Once you've done this, go to the site level and activate the feature. Now you are ready to add the web part to the appropriate page and configure it.

People Search - Modifying the display results - Part 1

This will be a two-part post. I'm nearing the end of my day and want to document this before I sign off for the day.

I've spent a great deal of time trying to modify my People Search display. I kept getting the following error:
System.ArgumentException: An item with the same key has already been added. at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add) at Microsoft.Office.Server.Search.WebControls.PeopleCoreResultsWebPart.SetSortedRefinementDataOnHiddenObject() at Microsoft.Office.Server.Search.WebControls.PeopleCoreResultsWebPart.SortResultsIntoArrayLists(XmlNodeList resultsList, Hashtable colleagues, Hashtable colleaguesWCollOfColl, UserProfile currentUserProfile) at Microsoft.Office.Server.Search.WebControls.PeopleCoreResultsWebPart

After spending entirely too much time on this I Googled it. And found my answer here. While it's somewhat nice to hear that this is a normal error and that the changes are there all you need to do is publish the page, it's also very scary. You better make sure you have a backup copy of your XSL. I was able to "Check-In" my results in draft form before publishing for the world to see, so this was better than having to completely "Publish" without testing at all.

Check back tomorrow for Part-2 as I continue my quest to modify my People Search results.