Brad's profileSharePoint BlogPhotosBlogLists Tools Help

Blog


    October 29

    And a web site that people publish and categorise tools on...

    Another treat for today - this site has a list of some great tools (including the SharePoint Skinner tool) grouped by category. I know a similar thing exists on WSSDemo, but it's tough to navigate. This one's clean and friendly - http://www.sharepoint-tools.de/ (luckily, not in dutch, but english).

    Themeing for SharePoint - Using Deployment packages

    Came across a great tool today from the guys at Elumenotion called SharePoint skinner. Essentially it's an easy way of creating a new theme and packaging it up with the assets as a WSP to deploy to one or more farms. http://www.elumenotion.com/Blog/Lists/Posts/Post.aspx?ID=94 - Not bad guys, not bad at all!
     
    B
    October 28

    When Security becomes annoying - Saving a .docx file from a web site automagically saves as a zip

    I hate it when things don't go right on my computer. One of the things I've been annoyed with lately is how on some sites, when I click on a .docx file to open it or save it, it always reads the file "header" (the first part of the file) and thinks that it's a ZIP file (which it kind of is - except I don't want it to open in WinZip, I want to open it in Word).
     
    I finally got jack of it tonight. Tools down, I was going to fix this problem come hell or high water. First thing I did was Google the problem - Heaps of hits on it. Great! this will be a cinch! The sites I opened though had other ideas on what they thought was a "helpful" solution.
    • Change the filename during the save dialog (Duh! Been there - I want a fix, not a workaround).
    • Rename it once you save it (these mental giants were having a laugh at me)
    • Use Firefox (I almost expected to find this on a Firefox site once I read it - I live in the Microsoft world)
    • Add the site to your trusted sites (again, not a solution but a workaround every time I saw the problem)
    • Change the MIME types on the web server... now this was interesting... okay, apparently a .NET framework update came out with a new set of MIME types that indicated what application should open up what file - this was controlled by the Web site administrator though, so out of my reach
    • Disable IE's habit of "sniffing" the file header and working it out based on what it saw <-- BINGO!

    What was happening - in web servers that had not been recently updated, the docx and pptx and xlsx file types were not registered properly on the web server. As a result, IE downloads the start of the file, looks at the first few bytes and assesses what it thinks is the correct application to open it with. This prevents someone from "disguising one file as another type, just by changing the extension (eg renaming .exe to .txt). It's a security feature - Firefox does not have it (which is why the Firefox solution works).
    As some would know, the docx format is a renamed zip (cab?) file with lots of XML data in it. In fact, you can rename any docx file to .zip and have a look at its innards. This is why it picked .ZIP as the extension.

    The other solution is to disable this IE security feature in the Registry. Navigate to:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_MIME_HANDLING and
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_MIME_SNIFFING

    Change iexplore.exe's DWORD value from 1 to 0 - this allows the OS to take over and use the native application. Security lowered, problem solved... Well, kind of.

    Brad

    Listener Channel Failures, Process Activation errors, Licence Acquisition failure. It's all happening today...

    Just had an interesting error crop up at a client site. One of the team (Hi Daniel!) was building a SharePoint server and was halfway through configuring it, when it suddenly stopped working. 503 errors on all web sites on the server, and some very strange errors in the event log:
     

     
    Event ID: 8200
    Source: Security-Licensing-SLC
    Log: Application
    Level: Error
    Details: License acquisition failure details. hr=0x8004FE33
     
    Event ID: 5139
    Source: WAS
    Log: System
    Level: Warning
    Details:
    A listener channel for protocol 'http' in worker process # serving application pool 'SharePoint Central Administration v3' reported a listener channel failure. The data field contains the error number.
     
    Event ID: 5002
    Source: WAS
    Log: System
    Level: Error
    Details:
    Application pool 'SharePoint Central Administration v3' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
     

     
    WAS is the Windows Process Activation Service (you'll need to know that shortly). I'm not sure what the root cause of this error is, but someone somewhere in Microsoft does. Essentially, if you are using IPv6 and have nominated a Dedicated Crawl Server, the SharePoint application writes some bogus entries to the Windows Host file, causing WAS to fail.
     
    The solution is to either:
    • Set up the SharePoint crawl service so it uses all WFE servers to crawl content (as Central Admin is FUBAR'd, you'd need to use STSADM to change this property), or
    • Remove IPv6 from the Server NIC's and restart the Windows process Activation service.

    This then writes nice entries to the Hosts file and the problems evapourate like morning dew on a hot day. This is the site that we found the solution on - http://blogs.msdn.com/jmacleod/archive/2008/06/25/iis7-sharepoint-2007-fails-with-503-service-unavailable-errors.aspx (we used Workaround 2).

    Cheers!
    Brad

    October 07

    KRB_ERR_RESPONSE_TOO_BIG - Forcing TCP/IP over UDP

    I thought I had this error on my blog somewhere, but when I went looking for it, I could not find it...
     
    When you are working in an environment that uses machines running earlier versions of Windows than 2008 Server or Windows Vista, you may encounter an authentication problem when trying to pass through authentication using Kerberos tickets.
     
    Essentially, the UDP Protocol cannot handle the larger size packets required to capture a Kerberos ticket for someone who has a large collection of groups associated with their login. This scenario has a list of dependencies required to trigger it which are outlined in KB Article 244474, but the fix is to set the following registry key on the web server to 1:
     
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
    MaxPacketSize=1 (Decimal)
     
    The Parameters key may not exist, if it does not, then create it.  The KB Article http://support.microsoft.com/kb/326985 has a lot of useful links to Kerberos articles and descriptions which I have used in the past, so you may also find that helpful.
     
    B