Windows Server 2008 Tip #1: IE without restrictions

This is a very quick tip for Windows Server 2008, but very useful.

Ever had to download some sort of software to a server, but the download page had some sort of asynchronous behaviour with JavaScript? Or maybe the page had something more going on, that would just not work while using it in the server's Internet Explorer?

It happened to me recently, I wanted to download Microsoft's Productivity Hub SP1 and install it in a SharePoint farm. The server has a very good Internet connection and I was logged remotely (in a slow connection), so the best way to do it would always be downloading the files locally in the server (about 2GB).

The problem: I needed to login with my Live account to be able to download the files. Adding those sites to the Trusted Sites (they are all Microsoft sites) actually solved the login issue. But to download these files, I also had to fill in some register information, as these are not directly downloadable. That register page uses some asynchronous code that, even having the site as Trusted, would not run.

The solution is quite simple: go to the Server Manager and disable Internet Explorer Enhanced Security Configuration (IE ESC) for Administrators. Everything will work after disabling that. Some printscreens below.

References: here

SharePoint 2010 Tip #6: Saving Document Templates in Library

If you are saving your Document Templates in a SharePoint library, don't forget to load the appropriate Content Type to that Library, otherwise your Document Template will be attached to the "Document" Content Type, which only has the "Title" metadata field.

If you don't, your Document Template will lose the association with your Content Type. When you create a new document using that Document Type, the Information Panel will not load your Content Type and any QuickPart you have configured will not work well.

The error will only be fixed once the user tries to save the Document to the Library, and only in the case you have mandatory fields in your Content Type, as SharePoint detects there are missing mandatory metadata fields and block you from saving.

Use jQuery in Chrome Console

Since Chrome in gaining momentum (and Firefox losing it) I though I'd start using it in my new laptop and don't even download FF.

I have been quite happy so far, but I just discovered a caveat: if you are using the Console to quickly test some HTML / JavaScript / jQuery / CSS, then be aware that the Chrome Console will replace jQuery's $ function with it's own, that is actually an alias to getDocumentById.

To quickly check it, just use jQuery===$ and see the output. Or if you just enter $, Chrome should have changed that function to the following:

function () {
     return document.getElementById.apply(document, arguments)
}

That means if you select an id it would actually return what you expect, but everything else will fail. So just use jQuery() for your quick test in the Console, and that's it!

EDIT: this bug is already fixed (here), so the problem must be another one. In Twitter, @fbatista answered me with the most probable option: a misplaced $.noConflict()!

Search Requirements Gathering

Just stumbled upon a great presentation about Search Requirements Gathering, from Michal Pisarek (SharePoint MVP). You can see the slides here.

The first thing is to acknowledge the challenge: search is perceived as something that works out of the box and magically presents users with the most amazing results. Little or no time is expected to be spent analysing the quality of results and getting a governance plan together (yes, for search!). Also, in most projects, search requirements are pretty much reduced to knowing which Content Sources need to be in place.

To me, the most important thing is to focus on the value it can deliver. Specific business driven actions that are performed within the organization on a daily basis, that can be improved using SharePoint Search. Attainable goals.

Here are some interesting statistics (Source: Google / IDC):
Each worker currently spends, on average, 9.5 hours per week searching for information. And 3 hours a week recreating content that already exists!
According to the same study, having a high-quality enterprise search implementation will reduce the search time by 50%. That's more than 4 hours a week, or half a day!

How can you achieve these results? You must know what are users searching for and the perceived time they spend doing it. You must understand what is used on a daily basis and on a monthly basis. What is working fine and what is not working at all.
That's the most important step. Then, you have the information you need to build a search configuration focused on their daily needs that can massively improve their searching ability, by filling in the gaps and giving them an integrated system where they can find what they are looking for.

There is also additional value you can push with search. In a successful implementation, users will better understand the importance of metadata, so they may take extra care when categorizing a document. Having the people search box on the right hand side of the search page, can help them realize the value of filling in their "Ask me about" data. And going into someone's profile, may show them the utility of the Organization Browser.

It is definitely a snowball.

Providing a major initial benefit for users working with the SharePoint platform (Search), can help gain buy-in from the users and you can later take advantage in other areas that, by themselves, wouldn't be powerful enough to bring users to the platform.

Another interesting read on this: Using Search Analytics (presentation).