Monthly Archives: September 2015

SharePoint 2013 – 404 Error When Connecting to ACS or ADFS /_trust/default.aspx

Ran into an interesting error this morning that I thought I’d share. Recently, I worked on a project utilizing Azure ACS with Google Accounts. This was working on multiple servers, but one was displaying a Page Cannot Be Displayed message when clicking the Google Sign-In button. Looking at a network trace it was getting a 404 error for the following page:

http://webappurl/_trust/default.aspx?trust=Google%20Account&ReturnUrl=/_layouts/15/Authenticate.aspx?Source%3d%252F&Source=/

Doing a little bit of research this page is used when utilizing ADFS/ACS. Interesting part about this is it worked on 2 out of the 3 servers and the server affected worked with Windows Integrated login. I checked a network trace on a working server and saw that after it hits the /_trust/default.aspx it redirects to the ACS URL (https://acsname.accesscontrol.windows.net) and then redirects to https://accounts.google.com/ServiceLogin. I was able to hit both of these URL’s individually on the non-working server.

I popped open IIS on the problematic server and noticed something interesting. The _trust IIS Virtual Directory was missing!

TrustsFolderMissingInIIS

Big surprise, the other 2 (working) servers had this Virtual Directory. Running the provision PowerShell method fixed the issue..I’m really digging this command lately.

Thanks Jasper for the tip!

http://blog.repsaj.nl/index.php/2014/07/sp2013-sharepoint-adfs-and-404-on-_trustdefault-aspx/

SharePoint – Web Application Creation Timeout Annoyance

When trying to create a web application using Central Admin sometimes it will just timeout. This can usually be remedied by either adding more resources on the SharePoint server hosting Central Admin or increasing the Shutdown timeout limit for the Central Admin IIS Application Pool (Usually 300-400 does the trick. See this post: http://www.andrewjbillings.com/sharepoint-2013-web-applications-not-creating-successfully-not-deploying-all-files-to-the-virtual-directory/).

There’s got to be a better way right? Yes, instead of mucking around with timeouts and adding resources for a task you rarely do (Though if this is happening and things are slow..You might want to look at Microsoft’s hardware recommendations and if you are abiding by them).

Any who…PowerShell wins again. There is a ProvisionGlobally() Method for SPWebApplication. This will push all of the items missed at the time of provisioning out to ALL servers running the SharePoint Web Service. Only want to do it to one server? Log on to the local server and run Provision()

More about this lovely time-saver: https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.provisionglobally.aspx

Example:

-AJB

SharePoint 2013 – Search Index Component Stuck in Degraded (Yellow) State

I read many posts about this, but none had my solution so let’s get into it. Oh the infamous yellow triangle! One of my Index Components was in a degraded state. First off, I logged into the server to make sure disk space wasn’t the issue. There was loads of disk space. I then tried the following:

  • Restarted SharePoint Server Search 15 Service
  • Cleared Config Cache
  • Reset the Index and ran a full crawl of all content

Some sources day a server reboot would fix the issue, but that’s no fun. I did some digging and found that restarting the SharePoint Search Host Controller Service fixed the issue in this case.

-AJB

Duplicate List DisplayName causing ListData.svc 500 error

This is a fun one I haven’t seen in a while so I figured I’d blog. Support issue today where user was trying to access listdata.svc

http://webappurl/sites/sitecollection/subsite/_vti_bin/listdata.svc

This worked at the web app URL root, the site collection root, but was giving a 500 error at a specific subsite. There was a subsite underneath the affected site and that one loaded up just fine as well..seemed to be isolated to one site.

This issue is caused by a couple of things (specifically if it’s isolated to a single site or list):

  1. Invalid characters in list (Either displayname of list or column names): https://support.microsoft.com/en-us/kb/905231
  2. List view threshold/list lookup threshold
  3. Anonymous user tries to access ListData.svc
  4. svc does not work with Discussion Lists
  5. A few others:
    1. http://allthatjs.com/2012/07/20/limitations-of-sharepoint-listdata-svc/
    2. http://blogs.technet.com/b/victorbutuza/archive/2014/06/30/why-would-listdata-svc-return-an-error.aspx

It was none of these..pretty small site with nothing too crazy for naming or anything like that. Turns out the user created a list and gave it the same displayname as another list on the site (URL’s different..sharing the same displayname). This caused the entire site to throw a 500 error when accessing it with listdata.svc. Even when explicitly going to a list on the site that wasn’t affected. Once the user switched one of the lists to <listname> (old) everything started working.

-AJB

SharePoint 2013/SSRS 2014 Trace Logs (and SSRS 2012 too)

ReportServer trace logs (Described here: https://technet.microsoft.com/en-US/library/ms156500(v=sql.120).aspx) can get quite huge during an upgrade. This might be a good candidate to get to a secondary drive along with IIS Logs, ULS Logs, etc.

These logs are stored in the following location (And according to a friend at Microsoft this is the only place you can find the build version of SSRS your SharePoint environment is running): C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\WebServices\LogFiles

Note: They are in this location for SharePoint 2010 (In 14 Hive) and SharePoint 2013 w/ either SSRS 2012 or 2014 running in SharePoint Integrated mode. If this is a native SSRS instance and you somehow found my blog everything still applies. Just look here for the trace logs instead:

C:\Program Files\Microsoft SQL Server\MSRS12.MSSQLSERVER\Reporting Services\LogFiles

The default max logfile size is 32MB and the default retention is 14 days. These can be tweaked at the following location:

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\WebServices\Reporting\rsreportserver.config

You could potentially add a custom property called Directory and set it to your secondary drive. Here are those default values I talked about:
<RStrace>
<add name=”FileName” value=”ReportServerService” />
<add name=”FileSizeLimitMb” value=”32″ />
<add name=”KeepFilesForDays” value=”14″ />

SharePoint 2013/SSRS 2014 – Error Activating Reporting Services Integration Feature

I was contacted about a BI site without SSRS content types the other day. I sent them this document and we went through everything on it: https://msdn.microsoft.com/en-us/library/bb326289(v=sql.120).aspx

When trying to deactivate and reactivate the Reporting Services Integration Feature we got the following error..Bwomp

The content type with Id 0x010100C3676CDFA2F24E1D949A8BF2B06F6B8B defined in feature {e8389ec7-70fd-4179-a1c4-6fcb4342d7a0} was found in the current site collection or in a subsite.

First, we tried using brute force with some PowerShell magic:

This successfully activated the feature, but still no content types.

I then went on a PowerShell-ing magical journey to see if I could find if SharePoint was lying to me. It was…

*This script searches the entire web app to see if it can find a content type with ID 0x010100C3676CDFA2F24E1D949A8BF2B06F6B8B. The first line looks to see if the Reporting Services Integration feature is enabled anywhere else.

Since this returned nothing (And I did a few manual checks to make sure PowerShell wasn’t lying to me too. Trust issues..I know) I did some searching online and found some recommended fixes:

  • Most blogs state to use the -Force command like I states above. Even though it does successfully activate the feature…still no content types
  • Tried clearing the SharePoint Config Cache
  • Tried repairing the Reporting Services Add-In on ALL servers
  • Did a SharePoint rain dance..just kidding..maybe

Then I found this awesome official Microsoft article on the Reporting Services Add-In Installation: https://msdn.microsoft.com/en-us/library/aa905871.aspx

There is an area of this article that talks about using a two-step install to troubleshooting issues. This was the Golden Ticket…A normal repair didn’t work, but this two-step install/repair did the trick. I only needed to do the following steps on the SharePoint server running SSRS (This specific farm had 2 servers and these commands did not need to be run on the other server).

I fired up the command prompt (As Admin) and changed directories to the rsSharePoint.msi file (SSRS Add-In install file..You can get this right out of the SQL installation files or go here and grab the appropriate one: https://msdn.microsoft.com/en-us/library/gg426282.aspx#bkmk_sql11sp1)

Msiexec.exe /i rsSharePoint.msi SKIPCA=1

This popped up the Reporting Services add-in installation wizard. I clicked repair as I did before and it completed successfully. The SKIPCA=1 parameter skips installing the Reporting Services Custom Actions and puts another Install file in the %TEMP% location or C:\Users\<your name>\AppData\Local\Temp

With the same command prompt window opened I changed directories to this location and ran the following command:

.\rsCustomAction.exe /i

This is what it should look like on your end..

PowerShellforRS

After that I checked out the BI site’s site content types and look at those sexy beasts:

Content Types