Feature dependency error repeating in ULS logs

Repeating error, reported by lots of clients:

Failed on try1 to load XML document at path 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\Template\Features\RecordPoint.Deployment.CentralAdmin\feature.xml': System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\Template\Features\RecordPoint.Deployment.CentralAdmin\feature.xml'. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) at System.IO.FileStream..ctor(String path, FileM... 238ed69c-ae25-d006-9536-1202447d7696


General findings:

  • SharePoint determines whether a solution package is global or not based on what’s in the solution package manifest. This is done automatically and can’t be overridden by the developer. So if we wanted the RecordPoint.Deployment.CentralAdmin feature deployed on all servers, we’d have to re-structure the solution packages to split out elements that necessitate a web app scope (I think this would just be caused by the <SafeControls> section in the manifest of RecordPoint.Deployment.CentralAdmin). So for us to fix this, we would set up something where one WSP deploys stuff to the GAC and sets the SafeControls for the CA web app, and another one deploys all the contents of 12\TEMPLATE\FEATURES. Personally I think this is kinda overkill/a lot of dev overhead for something that has no real impact on the operation of the environment, although we can raise it with the product team to see if they want to bother re-architecting the way solutions get packaged.
  • Based on the info in the logs from the RP35-TEST environment, one thing that triggers the error (for the RecordPoint.Queue feature & other features also) is the execution of the microsoft.sharepoint.administration.health.serverisnotrunning-on-demand-health-analysis-job timer job, which relates to the Health Analyzer’s “One or more servers is not responding” rule.
  • Temporarily provisioning the web application/central admin services on the app server will not work. The features will be removed again when you unprovision/stop these services. So the server will need to permanently run Central Admin in order for the files to be there.


Specific workaround options:


  • Manual copy of the feature files into 15\TEMPLATE\FEATURES from the app server where CA is located to the web front ends


  • Disable the health analyzer “One or more servers is not responding” rule and use other means to monitor whether the servers are up. This won’t remove the error completely, but will reduce a large chunk of its appearance.


At the end of the day, I would say this is genuinely a SharePoint issue & not a RecordPoint issue. The solution & features haven’t been built “incorrectly” – it’s just a side effect of the way the OOTB deployment model works. I’d encourage Treasury to raise a MS support case for it.

Have more questions? Submit a request


Article is closed for comments.
Powered by Zendesk