Monthly Archives: October 2015

SharePoint Open With Explorer Not Working – Check those managed paths

Try searching the internet for “SharePoint Open With Explorer Issues” and you will be busy for hours searching through all of the different forums, blogs, etc. Some of the most common recurring issues I found in my searching:

  • No “Root” site collection
  • Web Client service not started/not configured correctly on the client PC
  • Hot fixes need to be applied
  • The SharePoint site URL’s are not added to Trusted Sites/Local Intranet Zone

There are many more out there, but these were the most common I found..Now on to this SharePoint troubleshooting tale:

The client just went through a SharePoint 2010 to 2013 upgrade and Explorer View was working for some site collections and not others. This was reproducible on a Windows 7 Client with IE 10 or IE 11. We also did a test on Windows 10 and everything seemed to work there (Web Client must act different in the new OS). The open with explorer would work for 1-2 times after restarting the Web Client service. Then it would start prompting to add the site to Trusted Sites. Then after restarting Web Client this process would start all over again.

After some investigating I noticed something interesting in the Fiddler Traces..

Working Site Collection:

PROPFIND http://sitesp13ent01.ajb.loc/
207 MULTI-STATUS (text/xml)

PROPFIND http://sitesp13ent01.ajb.loc/sites
207 MULTI-STATUS (text/xml)

Non-Working Site Collection (It will give the error “We’re having a problem opening this location in File Explorer. Add this web site to your Trusted Sites list and try again”):

clip_image001
PROPFIND http://sitesp13ent01.ajb.loc/
207 MULTI-STATUS (text/xml)

PROPFIND http://sitesp13ent01.ajb.loc/depts
404 NOT FOUND ()

PROPFIND http://sitesp13ent01.ajb.loc/depts/it/Shared%20Documents
207 MULTI-STATUS (text/xml)

Notice anything weird?? There is a 404 Not Found for the /depts path. Let’s take a look at SharePoint Central Admin for the managed paths config for this web app:

image

Any site collection under the /sites/ wildcard managed path was working correctly and any of the depts site collections were not. WebDav is smart enough to honor wildcard managed paths, but does not work with “nested” explicit inclusions as it tries to hit each level of the URL..

Fixing the issue:

  1. Option A – Create an explicit managed path at depts and create site collection at depts URL
  2. Option B
    • Add depts as managed path (wildcard inclusion)
    • Deleted all depts/* explicit inclusions
    • If there is a site collection at depts this will need to be deleted
    • Note: Only tested 1 level deep (For example: depts/it). Did not test a scenario where there is more than 1 level (For example: depts/it/projects)

-AJB

SharePoint 2013/2016 Cloud Hybrid Search Service Application

I ran through the setup of the new SharePoint 2013/2016 Cloud Hybrid Search Service Application and wrote about it on the Skyline blog! Definitely an exciting new service and the best hybrid search experience to date..

http://www.skylinetechnologies.com/Insights/Skyline-Blog/October-2015/SharePoint-Cloud-Hybrid-Search-Service-Application

SSRS Migration – Permissions Issues Causing “Object Reference Not Set to an Instance of an Object” Errors

SSRS SharePoint Integrated mode has changed throughout the years. In the “olden days” you would manage SSRS (In SharePoint Integrated Mode) through the Reporting Services Configuration Manager tool (There were a few small hooks in Central Admin, but most of the config was in the RSConfig Manager tool). Starting with SharePoint 2010/SQL 2012 this service had a major overhaul. SSRS is now a service application..reports load up way faster..Mostly good things. Mostly..

With this new setup SharePoint requires some additional security. Check these out:

The important thing to note here is you need Edit Items added to read permission level. I actually found this information false. I did NOT need to add the Edit Items permission to the read permission level/create a custom permission level. Users were still able to run reports. Without edit items they could not create a new subscription. BUT with edit items they could find/edit data sources..not so good.

The next thing to note is that many reporting services environment have complex security models. As a SharePoint admin I usually cringe when thinking about folder/file-level permissions, but reporting environments sometimes are the exception. This specific upgrade has a DEEP folder structure. Each level had unique permissions all the way up the tree. The folder above each report dictated who had read access to the reports within it. This is great and worked perfect in SP2007/SSRS 2008 R2, but one IMPORTANT thing to note is that you need at least read access from the top down. Meaning if you have read access to Report A, you need read access to every folder above Report A or else you will get my favorite error ever: “Object Reference Not Set to an Instance of an Object.”

SharePoint 2013 – Publishing Sites Loading W/ Unexpected Error

Ran into a unique issue today so I figured I’d blog about it!

This was only affecting site collections with the SharePoint Publishing Infrastructure Feature enabled. I created a new site collection with Team Site template and that loaded fine until the Publishing Feature was activated and then it started to load w/ errors.

There was a line in the logs that stuck out:

DelegateControl: Exception thrown while adding control ‘Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapDataSource’: System.InvalidOperationException: Operation is not valid due to the current state of the object.   

 at Microsoft.SharePoint.SPUserToken.GetClaimsUserLoginName()   

 at Microsoft.SharePoint.SPSite.CopyUserToken(SPUserToken userToken)   

 at Microsoft.SharePoint.SPSite.SPSiteConstructor(SPFarm farm, Guid applicationId, Guid contentDatabaseId, Guid siteId, Guid siteSubscriptionId, SPUrlZone zone, Uri requestUri, String serverRelativeUrl, Boolean hostHeaderIsSiteName, SPUserToken userToken, Boolean appWebRequest, String appHostHeaderRedirectDomain, String appSiteDomainPrefix, String subscriptionName, String appSiteDomainId, Uri primaryUri)   

 at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, Boolean swapSchemeForPathBasedSites, SPUserToken userToken)   

 at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, SPUserToken userToken)   

 at Microsoft.SharePoint.SPSite..ctor(String requestUrl, SPUserToken userToken)   

 at Microsoft.SharePoint.Publishing.CachedObjectFactory.get_SuperUserSite()   

 at Microsoft.SharePoint.Publishing.CachedObjectFactory.OpenWebFromSuperUserSite(Guid webId)   

 at Microsoft.SharePoint.Publishing.CacheManager..ctor(SPSite site)   

 at Microsoft.SharePoint.Publishing.CacheManager.GetManager(SPSite site, Boolean useContextSite, Boolean allowContextSiteOptimization, Boolean refreshIfNoContext)   

 at Microsoft.SharePoint.Publishing.CachedAreaLookup.EnsureLookup(Boolean errorsAsExceptions)   

 at Microsoft.SharePoint.Publishing.CachedAreaLookup.GetCachedAreaOrException()

I double checked the Object Cache settings for all web apps and everything looked good.

Removing the Object Cache Accounts using this PowerShell command made the sites with Publishing Infrastructure enabled load up without errors:

After that I ran the commands to re-add the Object Cache (SuperUser/SuperReader) accounts and everything was still working. A few days earlier the application pool account for this web app expired and was reset to the original password, which may have had something to do with this. Looks like it just needed a little reset of the Object Cache accounts and everything was back up and running!

SSRS Migration – Subscriptions don’t work if owner no longer exists

After an SSRS Integrated mode migration (From SharePoint 2007/SSRS 2008 R2 to SharePoint 2013/SSRS 2014) there was an issue with some subscriptions not working. In the past (Back in the day when Reporting Services was not a SharePoint Service Application) you were able to create a subscription as the sharepoint\system account and the subscription would run as that user. In SharePoint 2013 this will NOT work…just like workflows can’t be published using the system account..either can SSRS subscriptions. This is actually a known “issue” with SharePoint-Integrated SSRS in general. If the owner of a subscription is disabled/removed from AD..or no longer has permissions to the report/site/etc. the subscription will no longer work. There is a PowerShell script that updates the ReportServer catalog to change the owner from sharepoint\system to someone else..maybe a sweet new service account..hint hint: http://kitmenke.com/blog/2014/11/25/powershell-script-to-change-ssrs-subscription-owner/

You could accomplish the same using a query against the ReportServer database. I strongly prefer the PowerShell route, but figured we’d cover all our bases. I haven’t found any “official documentation” stating if this is supported or not.

 

Remove-SPWebApplicationAppDomain..You’re Killing Me

After March 2013 PU was released for SharePoint 2013, new PowerShell cmdlets were brought into this world for setting up the SharePoint App Store. I’m a fan, but noticed something that I’d like to share. Read more about these cmdlets here: https://technet.microsoft.com/en-us/library/Dn144963.aspx

Now take a look at the screenshot and let me know what’s wrong:

RemoveSPWebAppAppDomain

OK, here’s what is up. The cmdlet New-SPWebApplicationAppDomain created a new binding for Port 80 for the WebApplication specified. This is because of the way SharePoint Apps work..they don’t play well with host headers..so instead of setting up a new web app listening on Port 80 you can have SharePoint add this binding for you. There may be a circumstance down the road where you decide you want to have a site on port 80 and decide to remove the App Domain using Remove-SPWebApplicationAppDomain. You take a look in IIS..no more Port 80 binding. BUUUUT when you go to create the new web app you get thrown an error message saying “The IIS Web Site you have selected is in use by SharePoint. You must select another port or hostname.” BWOMP

I can run remove/add-spwebapplicationappdomain commands all day and it’ll create and delete the binding in IIS but running the PowerShell commands above you can see that even though IIS is cleaned up, the config database still sees that binding.

At this time I haven’t found a great fix..but here’s what I got (I have tested this on multiple SharePoint 2013 servers..the latest being one with September 2014 CU):

Change the port using PowerShell.

Example:

Since this is affecting the Default zone only you could extend the web app to a temp URL, delete the Default Zone, and extend the original URL back to the default zone, and delete the temp URL zone. I go through this procedure because of custom solutions deployed to the farm. If you delete all zones, things just don’t seem to work right.

SharePoint in Azure – SendGrid Configuration

Recently setup outbound SMTP in an Azure SharePoint farm. There is great documentation (https://azure.microsoft.com/en-us/documentation/articles/sendgrid-dotnet-how-to-send-email/) out there already, but figured I’d share my experiences with it.

Included in Azure is a cloud-based email service called SendGrid. You get 25,000 email credits free a month. Here’s the rest of the pricing: https://sendgrid.com/windowsazure.html

Once this service is created in your environment (Click the first link to get the walkthrough) you will be assigned a username/password for SMTP relay. Make note of this since you’ll be using it later on.

After the SendGrid service is spun up you still need a way for SharePoint to use this. Pointing the outbound email configuration at smtp.sendgrid.com will not work because SendGrid requires a username/password. Good thing SendGrid has some good documentation too: https://sendgrid.com/docs/Integrate/Mail_Servers/iis75.html

After configuring the SMTP Server feature on the SharePoint server (You could use a separate server for relay, but this was dev so I was playing) I tested first with Telnet (Using the example in the SendGrid documentation) and then with PowerShell to verify everything was working in SharePoint.

The documentation is good so follow that, but I did run into 2 items that weren’t discussed:

  1. Add your domain as an alias domain in SMTP
  2. The IP Address of 127.0.0.1 does not work
    • In SMTP > Right Click the SMTP Virtual Server # 1> Properties > Access > Relay Restrictions
    • Click the Relay button and note that 127.0.0.1 is added (Per SendGrid instructions). This needs to be switched to the IP Address of the Azure server

Here’s the PowerShell example: