Thursday, 22 January 2015

Can't Connect to SharePoint Designer OR can't query GetUserProfileByName Web Service

We were getting an issue on one of our Test Server WFE's where we were having two issues:

- If you were trying to load an InfoPath form that contained a connection to the GetUserProfileByName Web Service, it would fail.
- If you tried to connect to the site via SharePoint Designer, it would error out.

SO!  If you get any of the following issues:

In SP Designer:
"The server could not complete your request.  For more specific information, click the Details button."

"An error occurred while trying to fetch data from your SharePoint site.  Unexpected response from the server.  The content type of the response is "", The status code is "OK"."

On an InfoPath Form:
"There has been an error while processing the form.  An error occurred while trying to connect to a Web service"

In SharePoint Logs:
"The following query failed: GetUserProfileByName (User: xx\username, Form Name: Template, IP: , Connection Target: , Request: http://root/site/Lists/ListName/AllItems.aspx, Form ID: urn:schemas-microsoft-com:office:infopath:list:-AutoGen-2014-11-13T05:55:39:175Z Type: DataAdapterException, Exception Message: The remote server returned an error: (401) Unauthorized. The remote server returned an error: (401) Unauthorized.)"

Here's how we solved the problem:
Navigate to the server in question
Open IIS Manager > Navigate to the site that is causing the problems
Click on Authentication > Windows Authentication > Providers...

Our Enabled Providers had been changed, and was set to Negotiate: Kerberos (wasn't the same on the prod servers...).  So I changed the Enabled Providers back to 'Negotiate' & 'NTLM'.

After an IISRESET, good as gold.

Thursday, 15 January 2015

InfoPath, Content Types, Site Columns & The Future

Just a quick one after some deep thought.

Thoughts on the Future: If you have to create an InfoPath Form, you should be creating it as a List Form (if possible), not a Form Library.  The reason for this is ease of upgrade now that InfoPath will not be upgraded/supported by Microsoft.

If you have to create a Form Library (because you form requires repeating tables/sections):

I’ve decided that InfoPath forms should NOT be published as Content Types.  The only time it would be considered OK is if the form is very generic and is being used on multiple sites.  E.g. a Help Form which could be used by multiple departments without any modification.

The main issue when publishing as a Content Type is that every field you promote to be visible in SharePoint has to be created as a Site Column. This means that even for a small form, for instance, a Personnel Access Form, you’d have to create Site Columns for fields like: Room Number or Access Hours, which would only ever be used for this form and nothing else.

Site Columns (and Content Types!) should only be created when you are planning to re-use them across multiple sites. They shouldn’t really be created to be used on one specific thing.

With that said, It’s still worth creating a few Site Columns for fields you know will be in the majority of your forms, and connecting each forms promoted fields to them. Connecting these fields to Site Columns is useful if you ever want to do some Search Customisation & Filtering on the columns.
TL;DR: Creating full InfoPath forms is a bad Idea.  But if you have to go for it.  you may just have to rebuild the form in 10 years.  If you ARE publishing a full InfoPath form, don't publish as a Content Type.  Instead for search purposes you should create 10 or so commonly used Site Columns and publish forms as Form Libraries, linking up the fields from your form with the Site Columns.

Monday, 12 January 2015

AvePoint DocAve 6 Manager - Admin Account Disabled

Today I tried to log into our DocAve 6 Suite on our SharePoint 2010 environment and came across this error message:
Sorry, the account has been disabled. Please contact the administrator
My guess was that due to inactivity (hadn't logged in for a few months) the accounts had been disabled.  The problem was that every Administrator account had been disabled so I couldn't get in!

After a quick call to AvePoint, the techies solved the issue quick smart.  Here's how you can save yourself a call and Enable a user accounts status again:
  • Log onto the SQL Server that stores the AvePoint Databases.
  • Navigate to AvePoint's ControlDB
  • Right-Click > Select TOP 1000 rows for the table dbo.AccountMapping
  • In the results, you should see all your accounts, and a Status column which states whether the account is disabled or not (1 = disabled, 0 = enabled)
  • Right click the dbo.AccountMapping table and Edit TOP 200 Rows, and modify the Status from 1 to 0 for the account in question.
  • You should now be able to log in with that account.
To stop this issue happening again, log into DocAve and navigate to this area to change the length of time accounts can remain Inactive for: Control Panel > Security Settings > Inactive Period