In an isolated dev environment set up to enable Kerberos in SharePoint 2007 and SQL Server 2005, a single VM Server for the DC, one for the SQL Server and one for the SharePoint Web Front End, developers were unable to create custom databases in the SQL Server instance and use SQL Server local logins to connect to those databases with ODBC.
Tests with generic UDL shortcuts (ODBC) failed with the error “Login failed for user “<username>”. The user is not associated with a trusted SQL Server connection.” upon clicking “Test Connection” button.
Carried out the following tests:
Made sure we had the right password for the testing account. If needed, can change passwords this way.
Made sure that SQL @@servername was correct (select @@servername executed as a query helps with this. Google can help provide more details).
Checked SQL Logs for more information (found Error 18452 after each connection failure)
The term “trusted connection” suggested that the issue might be with Kerberos even though we were using local accounts, so I also checked for the “Integrated Security” connection string value per discussion here.
Finally went through the UDL shortcut configuration again, and found an interesting phenomenon. If you click the “Test Connection” button you get the generic trusted connection error. But, if you click the drop-down list for selecting the database you want to connect to, you get a very applicable error message.
The fix for this problem is to go back into the SQL Server Management Studio, edit the properties for the local user and first enable “Enforce Password Policy” for the user, THEN uncheck all of the options including “Enforce password expiration” AND “User must change password at next login”.
Recently we had cause to do a whole lot of research ourselves and end up calling Microsoft to get our implementation vetted and troubleshot (it was not working – all or almost all connections that should have been Kerberos connections were degrading back to NTLM).
Here are the salient notes and facts about troubleshooting and achieving the ultimate goal (having Kerberos working with our systems).
I don’t like to do exactly the same blog entry that someone else did, but the other blog entry was from 2007 and I just encountered the problem myself. Thank g-d for Google.
Anyhow, if you have a web application with no site at the root managed path, adding a best bet to a site collection on some other managed path will pop up a window that says,
The search service is currently offline. Visit the Services on Server page in SharePoint Central Administration to verify whether the service is enabled. This might also be because an indexer move is in progress.
The way to fix it is to create a site collection at the root managed path. Or probably upgrade to SP1.
Yes, I know the error is completely unhelpful. I found it so as well.
Had a user who accidentally (I assume, since he seems to think it’s because ofÂ an operation I did well before that that was unrelated – see previous post) deleted the automatically created List View Web Part in the AllItems.aspx page.
Now he wants the full toolbar and the View Selector drop-down.
If the list is small and customizations relatively few, note the URL of the list and any customizations, save off content. Delete list. Start over, re-upload the content after the recreation. Don’t forget to create initially with whatever end of the URL you want for the list, then rename after the list is created at that URL.
So before I enabled the Publishing Infrastructure feature, the top nav bar tabs showed the leftmost tab reading “Home”. After enabling it and later disabling it, the leftmost tab read as the site title (as set in the site settings). Great but all my functional tests are written to search for the tab reading “Home”. So I tried to edit that Global Navigation header in the Navigation settings in Site settings and the Edit… option is not available for that heading.
We set our upload size limit to 40,000 megabytes on our Virtual Server settings.
You access this setting in Windows SharePoint Services Central Administration -> Configure Virtual Server Settings -> [Select Virtual Server] -> Virtual server general settings -> the setting is in Maximum Upload Size. (default is 50 megabytes)
This was very bad. Apparently if the setting is set too high, it’s essentially interpreted to be zero by the application.
Once this happened, not only did we get the upload size error, “The form submission could not be processed because it exceeded the maximum length allowed by the Web administrator.” for any size file, but also, we got the Explorer View error, “Explorer View requires Internet Explorer 5.0 or greater and Web Folders.”
A better really huge setting that ended up working for us was 10,000 megabytes.
If you are playing with Approval workflows, and you find that your workflows are erroring out even when you think it should have completed successfully, make sure you aren’t in a situation where you’re updating the approval status without having the approval functionality of your document or workflow library enabled.
It’s all built-in, but it doesn’t all automatically enable itself on need.
I ultimately found my answer on SharePoint Blogs, but my discovery route was circuitous.
First, the Unknown Error statuses on my workflow status page for the workflow. These workflows would error out and require termination from the workflow status page so they’d stop contributing to my active workflow counts. Searching around, I found out (look at Eilene Hao’s response to Misha) that you can get more info about these by going to where your Diagnostic Logs are kept. Find out where those logs are kept by going to SharePoint Central Administration, Operations page/tab, then under the Logging and Reporting section, click the link to Diagnostic Logging. On the next page, you’ll find out where those logs are under Trace Log.
Go to that directory in your front end web server(s) and use a decent directory search/grep (I used Textpad I have installed in portable mode on a USB key) to find log files with the word “workflow”. Upon doing that, I found the string/error, “System.ArgumentNullException: Value cannot be null. Parameter name: name”. Googling eventually led me back to the SharePoint Blogs post above.
So the fix is that if you’re going to use an ootb (out of the box) builtin workflow that updates the approval status of an item, you should also enable the “Require content approval for submitted items?” option in Versioning Settings for the list settings. This will do a lot of things automatically for you:
When a list item is changed, the approval status for the item gets automatically changed back to “Pending”.
When a person with the permission level to approve items looks at the list, they get a special view option called “Approve/reject Items”. (So they can bypass the approval workflow)
The workflow that updates approval status stops erroring out.
It’s all pretty cool, but you have to know how it all hooks together.