On our farm, we have multiple URLS, multiple site collections etc.
One of them has a social add in called newsgator social sites.
I kept seeing errors in the ULS logs of other sites saying things like:
Failed to create a custom control from assembly ‘NewsGator.NewsManager.Web’ .. The type is not registered as safe.
I know from experience that this means the control isn’t listed in the web.config for the given site, nor should it be – I don’t have, nor want newsgator to have anything to do with the site in question.
I also know that the errors aren’t really hurting anything, but if nothing else they are making the ULS logs a little bigger and honestly, I don’t want a farm that has known errors in it.
So I set out to understand where they were coming from and how to safely get rid of them.
Finding these in the ULS logs
They are all over our ULS logs, but it’s nice to have a quick way to validate if they are still there so I did a search with the windows Findstr command:
findstr /C:"is not allowed for web" *.log
The first thing I wanted to do was see if there was an obvious, easy fix – ie from site settings, site features, or site collection features, is there a newsgator feature that’s enabled that I can just turn off?
I tried this and no, there wasn’t
The solution turned out to be painfully simple.
In the ULS logs, there were entries like this:
Failed to create a custom control 'CustomMenu_NewsStreamAdmin', feature 'NewsGator.NewsManager_Actions' (id:16c89384-881d-44aa-a6f5-f66301596851) using attributes (ControlSrc='', ControlAssembly='NewsGator.NewsManager.Web, Version=184.108.40.206, Culture=neutral, PublicKeyToken=a1b9791f4e4509c7', ControlClass='NewsGator.NewsManager.Web.NewsStreamAdminActions': System.ArgumentException: The control with assembly name 'NewsGator.NewsManager.Web, Version=220.127.116.11, Culture=neutral, PublicKeyToken=a1b9791f4e4509c7' class name 'NewsGator.NewsManager.Web.NewsStreamAdminActions' is not allowed for web at URL 'https://nonnewsgatorsite.mydomain.com'. The type is not registered as safe.
The error above is always paired with another less descriptive error – but the error above turns out to have all the information we need – the id. (In this case id 16c89384-881d-44aa-a6f5-f66301596851)
In powershell, Get-SPFeature will list all the features on the farm – in my case it showed the above ID.
Now, given that newsgator is legitimately installed on our farm and on ONE web application (URL) I didn’t want to remove it from the farm!
What was helpful was the command:
get-spfeature -webapplication https://myurl.mydomain.com
This showed that the feature was associated with that web application and it also showed that it was webapplication scoped.
So next I used the command
Disable-SPFeature -Identity 16c89384-881d-44aa-a6f5-f66301596851 -URL https://myurl.mydomain.com
I had to do this for a few different features – pulling the ID from the ULS logs and running the disable command- While I’m sure it potentially could be automated, I preferred handling it “Hands On” doing them one at a time and confirming my SharePoint sites still worked as expected.
After that, the errors in the ULS log stopped for that site, and get-spfeature -webapplication https://myurl.mydomain.com no longer showed that feature.
It was a great feeling to get these nagging recurring ULS entries to stop!
Update: This post from Phil Childs’ excellent Get-SPScripts site has a more robust script for finding a feature in a farm and removing it everywhere if that is needed. (note that is a different use case than the one above so be sure to understand what the script does before running it!)