SharePoint 2013 InfoPath Form: Object doesn’t support this property or method ‘addeventlistener’ in IE 11

During an upgrade project we noticed that one of the pages that displays an InfoPath Form was throwing the error:

Object doesn’t support property or method ‘addEventLister’

InfoPath Error

This error wasn’t appearing anywhere else, so it was isolated to this specific page and also it worked in Chrome (The user was on IE 11). This led me to believe it was an IE 11 issue. I found the following post:

https://social.technet.microsoft.com/Forums/sharepoint/en-US/8a6ca7f7-3e4d-4210-a5a6-caa2e1c06cc3/infopath-form-page-object-doesnt-support-this-property-or-method-addeventlistener-in-ie-11

Adding the site to compatibility mode for IE 11 users fixed the issue..

-AJB

SharePoint 2010/Server 2012 R2: Config Wizard Fails with Error “Value Does Not Fall Within The Expected Range”

Ran into an interesting installation error – SharePoint was failing to create the Configuration Database..or so it appeared. Running New-SPConfigurationDatabase and running the SharePoint Products Configuration Wizard were both failing with the error “Value does not fall within expected range.” We were able to track down this issue in the ULS Logs and noticed all sorts of IIS-related errors:

Creating new application pool ‘SecurityTokenServiceApplicationPool’.

Adding DOMAIN\spfarmacct to local group IIS_WPG.

Adding DOMAIN\spfarmacct to local group WSS_WPG.

Adding DOMAIN\spfarmacct to local group PerformanceMonitorUsers.

Attempting to give SE_ASSIGNPRIMARYTOKEN_NAME privilege to application pool user DOMAIN\spfarmacct

Attempting to give SE_INCREASE_QUOTA_NAME privilege to application pool user DOMAIN\spfarmacct

An exception occurred while committing IIS configuration changes: Value does not fall within the expected range.

Unable to unprovision metabase object IIS://localhost/w3svc/AppPools/SharePoint Central Administration v4: System.Runtime.InteropServices.COMException (0x80070003): The system cannot find the path specified.

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)

at System.DirectoryServices.DirectoryEntry.Bind()

at System.DirectoryServices.DirectoryEntry.get_AdsObject()

at System.DirectoryServices.DirectoryEntry.DeleteTree()

at Microsoft.SharePoint.Administration.SPMetabaseObject.Unprovision()

Removing the Web Server (IIS) Role Service and letting the prerequisite installer configure IIS was the ticket to get “past” the SharePoint Products Configuration Wizard. It looked like something was up with the client’s Windows Server 2012 R2 image which caused IIS to get a little out of whack. Some other items to watch out for in this configuration (SP10/Svr 2012 R2):

image

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 – 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!

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 – 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

SharePoint 2013/SSRS 2014 – HTTPException Request Timed Out

Here’s the scenario – SharePoint 2013 with SSRS 2014. This is a small 3 tier farm – 1 App (Running SSRS), 1 Web, and 1 SQL server. This farm had been running smoothly for quite some time and started sporadically receiving HTTPException Request Timed Out errors. This seemed to only be affecting 1 specific report (Largest/Most used report in the farm) as I was able to run other reports when the 1 report was acting up.

The end users would just see the typical SSRS loading screen until the 110 second timeout kicks into effect and then the use is presented with a “Request Timed Out” error with a correlation ID. In the eventvwr application log I could see this:

Process information:

   Process ID: XXX

   Process name: w3wp.exe

   Account name: Domain\App Pool Account

Exception information:

   Exception type: HttpException

   Exception message: Request timed out.

After some digging I noticed that the page file on the system had been modified to a static size of 4GB. After changing this to system managed everything started working perfectly (Note: You could also use the Microsoft recommendation of 150% RAM on the system – http://blogs.msdn.com/b/chaun/archive/2014/07/09/recommendations-for-page-files-on-sharepoint-servers.aspx). Recently, I have also seen where search crawls stop working (Running continuously for 10+ days) due to switching the page file to a very low value. Moral of the story – make sure you’re page file is large enough!

-AJB

SharePoint 2013 – Another FIPS 140-2 Adventure “The encryption type requested is not supported by the KDC”

Oh Federal Information Processing Standard (FIPS) 140-2 AKA FIPS 140-2…You got me again! See the original post here:

http://www.andrewjbillings.com/fips-compliance-keep-away-from-sharepoint/

As stated in several Official Microsoft documents, SharePoint uses several Windows encryption algorithms for computing hash values that do not comply with FIPS 140-2..therefore you CANNOT enable the FIPSAlgorithmPolicy registry key. Here’s some info:

So in this situation we found that the group policy was applied so we retracted that and SharePoint was “back up.” At this time sites were loading, but I was seeing a bunch of errors related to search and distributed cache in the eventvwr/ULS Logs:

System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed, see inner exception. —> System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. —> System.ComponentModel.Win32Exception: The encryption type requested is not supported by the KDC

This led me to the following blog post: http://blogs.msdn.com/b/openspecification/archive/2011/05/31/windows-configurations-for-kerberos-supported-encryption-type.aspx

In this scenario 3 things still needed to happen:

First, IIS Crypto was ran and set to FIPS 140-2 mode. This needed to be reverted as this blocks MD5 hashes.

Then, the AD attribute msDS-SupportedEncryptionTypes needed to be changed from 24 to 28 on all SharePoint 2013 servers. The value of 24 does NOT include MD5 hashes..which SharePoint desperately needs.

msDS-SupportedEncryptionTypes

After this was set Local Security Policy needed some tweaking (“Network Security: Configure Encryption types allowed for Kerberos”)

This was set to the following (Blocking MD5):

secpolMD5Issue

Once checking ALL boxes containing MD5 we were back up and running..Search was working and distributed cache was happy..SharePoint was happy..we were all pretty happy in fact 🙂

-AJB

 

“The trial period for this product has expired”…But really it didn’t

The other day users were getting some strange errors on a page containing an InfoPath form. Users were seeing an error that read “The Trial Period For This Product Has Expired.” I knew this was not the case so I decided to looks at the ULS logs.

Here is the error I was seeing in logs (Seems to be misleading since the error the user sees is “The trial has expired”)

Getting Error Message for Exception System.TypeInitializationException: The type initializer for ‘Microsoft.Office.InfoPath.Server.Util.UrlManager’ threw an exception. —> System.Security.SecurityException: Requested registry access is not allowed.     at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)     at Microsoft.Win32.Registry.GetValue(String keyName, String valueName, Object defaultValue)     at Microsoft.Office.InfoPath.Server.Util.UrlManager.<>c__DisplayClass1.<OpenFileNameMap>b__0()   

It looked to be an issue accessing the registry on the servers. I fired up perfmon and low and behold some access denied errors to SharePoint-related registry keys. Instead of changing these manually I ran the following command to reset the SharePoint security for the file system and registry:

Psconfig –cmd secureresources

Or you can use the PowerShell equivalent: Initialize-SPResourceSecurity 

After that I rebooted the servers for the changes to take into effect and that page started loading up.

Reference: https://technet.microsoft.com/en-us/library/ee513047(v=office.14).aspx

 

SharePoint 2013 – Missing Patches Error

While working on a SharePoint test environment the other day I tried to take a backup of a site collection and got an error. After digging further I noticed that all databases were in compatibility mode. This lead me to Windows Update and I noticed that SharePoint security patches had been pushed to all servers in the farm and the SharePoint Products Configuration Wizard had NOT been run. This is a big no-no…please, if you push patches to your servers monthly and they include SharePoint-related patches make sure to run the grey wizard after. After applying patches to the servers in the farm I tried to run the grey wizard and got the following error:

“Error: Some farm products and patches were not detected on this or other servers. If products or patches are missing locally, you must quit this program and install the required products and patches on this server before starting this wizard. If products or patches are missing on your servers, you must install the required products and patches on the specific servers, and you may then click the Refresh button to perform the status check again.”

After running the following command on each server everything started working:

Get-SPProduct –local