“No valid proxy can be found” when publishing content type in SharePoint 2010

I found a number of posts with possible fixes for this problem, many of them relating to the Content Type hub URL in the Managed Metadata Service    e.g.

http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/d9efe46c-7d55-4f51-9e09-c41ff4d40bda

http://charliedigital.com/2010/01/06/sharepoint-2010-content-type-publishing-setup/

However, I received this error and the Content Type Hub url in the Managed Metadata Service appeared to be fine. It turned out that a new host header for the content type hub site had been created in IIS and an alternate access mapping added in SharePoint. If I accessed the content type hub site using the original host header (this was the one specified as the Content Type Hub in the managed Metadata Service) and tried to publish a content type everything worked fine. But doing the same thing using the newer host header resulted in the “No valid proxy can be found” message.

So if you get the”No valid proxy can be found” message and the Content Type Hub url in the Managed Metadata Service looks OK, take a look at your host headers in IIS and alternate access mappings in SharePoint.

Ian Docking – Senior Technical Consultant

LdapMembershipProvider not available in SharePoint 2010 Foundation

Despite there being a number of TechNet articles covering how to configure forms-based authentication using the LdapMembershipProvider for a claims-based web application in SharePoint Foundation 2010, it turns out that the LDAP provider isn’t part of Foundation. The only way round it (and it’s not really a way round it as such) is to right your own LDAP provider.

If you closely follow all the config instructions on TechNet (e.g. http://technet.microsoft.com/en-us/library/ee806882.aspx) you’ll still end up with errors in the event log like this…..

Event id: 1310

Exception information:

Exception type: ConfigurationErrorsException

Exception message: Could not load type ‘Microsoft.Office.Server.Security.LdapRoleProvider’ from assembly ‘Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’. (C:\inetpub\wwwroot\wss\VirtualDirectories\…………..\web.config line 334)

Microsoft tell me that a documentation bug has been raised on the TechNet site.

Ian Docking – Senior Technical Consultant

Access denied, HTTP 401 error crawling a SharePoint site on another farm

I had two SharePoint 2010 farms (both on the same domain), one running Enterprise Edition and the other SharePoint Foundation. When trying to crawl a site on the Foundation farm from the Enterprise farm all I got was a single error in the crawl log along the lines of ‘Access denied’ and ‘HTTP 401 Unauthorized’.

I confirmed that the content access account had all the rights it needed to crawl the site, so that wasn’t the problem.

It turned out to be related to the entry for the site’s host header in the hosts file on the Foundation server. It had been added using the local host IP of 127.0.0.1.   Changing it to use the actual IP address of the server sorted things out and the Enterprise server was able to crawl the site on the Foundation server successfully.

Ian Docking – Senior Technical Consultant

Search Administration – Could not connect to server

If you have the query server and index server roles on different servers in the farm and you get the following error showing in the ‘Server Status’ area of the Search Administration page….

Could not connect to server yourservernamehere for application ‘yourSSPnamehere’. This error might occur if the server is not responding to client requests, the firewall or proxy configuration is preventing the server from being contacted, or the search administration Web service is not running on the server.

….it could be because .Net 3.5 SP1 was installed prior to installing SharePoint 2007 SP2.

We encountered this a little while ago at a client site (SharePoint 2007 – including October 2009 cumulative updates – installed on servers running Windows Server 2003) and it turned out to be caused by corruption of the self-issued certificate used by the Office Server Web Services. .
 
Following the steps in this Microsoft support article to create a new self-issued certificate fixed it for us: http://support.microsoft.com/kb/962928
 
The symptoms we were experiencing weren’t exactly as mentioned in the support article however. We could get to the Search Settings page without any problem and while error event ID 6482 was being logged, it certainly wasn’t every minute. And the event description was more along the lines of ‘object not found’ rather than ‘application server administration job failed’. Search results were also being returned successfully. In fact, apart from the error msg on the Search Admin page there was no obvious indication that there was any problem at all.

If you prefer, before jumping in and creating a new certificate you can check to see if the self-issued SSL is working OK by opening a browser on the app/index server and type in the following addresses:
 
http://yourwfename:56737/yourSSPname/Search/SearchAdmin.asmx
https://yourwfename:56738/yourSSPname/Search/SearchAdmin.asmx
 
..substituting in your WFE server name(s) and SSP name as appropriate.
 
Then do the same on the WFE(s) substituting in the app/index server name.
 
If you get to the SearchApplicationWebService page in each case, the servers are talking to each other OK. Otherwise you may have a problem.
 
At the client mentioned above, browsing to both addresses from the app/index server to the WFE worked fine, but the https address didn’t work trying to get from the WFE to the app/index server.

Ian Docking – Senior Technical Consultant

Windows Server 2008 firewall ports on a multi-server SharePoint farm

I ran into this problem a few weeks ago when installing & configuring a customer’s Sharepoint 2007 farm comprising an application/index server and a single web front-end on Windows Server 2008.

I was unable to view or configure the services (Office Sharepoint Search in my case) on the web front-end. Trying to do so via ‘Services on Server’ in Central Admin (Operations tab) resulted in the following error message:

An unhandled exception occurred in the user interface.Exception Information: Could not connect to server xxxxxxxx. This error might occur if the firewall or proxy configuration is preventing the server from being contacted.

A technet article on configuring Windows Firewall with Advanced Security mentioned that all ports used by web applications, including Central Admin, needed to be opened. After finding all of the port numbers as per the article (from the list of web apps in Central Admin) and making sure they were open on both server firewalls we still got the same error message.

We fixed the problem by opening ports 56737 and 56738. These ports are used by Office Server Web Services. You can see this site and its port numbers in IIS Manager but there’s no sign of it in the list of web apps in Central Admin of course.

A lot of posts about Windows firewall configuration mention opening the ports for ‘all of the web apps’ but don’t mention the Office Server Web Services.

Ian Docking – Senior Technical Consultant