As an FYI, I’ve ended my Microsoft-Centric, SharePoint-Centric work/job as of Spring 2015.
I’m also moving posts about technical and other geekery to my new Geek Blog. If you’ve found my geeky advice helpful in the past, you may find it helpful in the future. Give it a read if you’re curious!
I’ll keep this blog up and available as a public service in case anything is useful or helpful for folks going forward.
In case it becomes relevant, probably most of my posts here (if any) will be scoped to that.
This will be in a full SDLC deployment and migration of most of our 2010 team sites. Project schedule has us down for a March 2015 completion date. It seems rather… aggressive.
Struggled a little with this combination of products:
Getting VMware View 3.1 running on Windows 7 SP1 in Parallels 6 on OSX Lion.
I was able to install the VMware View 3.1 client by connecting to the SSL View host at work, but when connecting to my desktops (after providing credentials), I got this error:
The View Connection Server authentication failed. The SSL initialization while connecting to server ‘https://(elided):443’ failed.
I noodled around with the usual suspects for network, SSL and tunneling settings:
- Firewall settings.
- Network settings.
- Antivirus settings.
- Parallels general settings (esp. Network and security)
Finally I tried to change the Parallels Tools and set the Network mode from Shared Network to Bridged Network -> Ethernet.
Here’s a relevant Parallels KB article (yes, the version is out of date).
Worked like a charm.
I have been keeping this blog updated and so on, but not quickly enough – a script kiddie hacked this blog as well as my personal one. I’ve written extensively about the hack and my recovery of my blogs from it:
- Details of Hack focuses on the actual details of the hack, including some e-mails exchanged with the hacker in question and some initial steps at remediation (both on my personal blog and this one).
- Rebuilding covers the majority of the work I did to rebuild, recover and secure both of these blogs post-hack.
- Recovered is just a sum-up. The fact that I added more stuff to Rebuilding, above, after posting Recovered should be of little consequence. Pay no attention to the man behind the curtain.
Only time will tell whether I have enough utz to keep updating this blog too as work provides me more information/insights/knowledge.
- 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 the Database instance was set to support both SQL Server and Windows Integrated Authentication (this is what the majority of Google hits for this problem suggested).
- Checked some Registry settings:
- 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”.
The picture is not entirely complete here, but I made a lot of progress with this as an open (now closed) troubleshooting ticket with Microsoft.
The short summary is that using a Microsoft whitepaper (linked to below), I could get Windows XP SP2 workstations to work properly opening an Explorer View to a SharePoint 2007 farm’s document library, I had a bunch of other problems to surmount when trying to get a Windows Server 2003 SP2 system to do the same. The rest of this post is about other methods for troubleshooting and fixing the situation.
Continue reading Getting WebDAV to work for Windows Network Providers against SharePoint 2007
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.
Well and good, but how?
I see two possible approaches.
- 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.
- If the list is larger or customizations greater, do some fiddling with SharePoint Designer 2007, Datasheet View and XSLT.
- There is no third thing.
I don’t see any good ways of doing this in the UI only without just recreating the list entirely.
Anyone else have any good ideas?