August 2011 - Posts
A lot of companies out there are terrified by things like Facebook, Twitter, and even free web mail accounts. They end up running out and buying the first web security product they can find such as Websense. Out of the box, these products do an ok job at blocking most user requests to those “bad websites”. However, one day I noticed something about these products. They are easy to get around. Ridiculously easy to get around. One day I brought my laptop to the client site. I was working on it the previous night and I left the browser open with a few tabs open to Facebook and my Gmail account. I was used to these sites being blocked at the client, however, I noticed that the content wasn’t blocked this time. I was freely able to update my Facebook status and check my e-mail. I thought this was odd, so I tried the sites on another machine and I got the standard block message, like the one below.
It took me a second, but then I finally noticed the difference. On the other machine, I had just typed in twitter.com and it was blocked. I went back and looked at my laptop and noticed it was point to https://www.twitter.com. I then tried several other sites. As soon as I used https instead of http, sure enough, the request when right through. Now, this only works on web sites that have SSL certificates, but a lot of the sites that are blocked usually support SSL. If you are interested in twitter specifically, I have often found that the web site is blocked, but using the API is not. That means you can run TweetDeck or your favorite Twitter client and it will probably work.
It’s as simple as that. Now, what you are doing is basically knowingly violating your company’s network security policy. So don’t go blaming me if they catch you and fire you for going somewhere that you shouldn’t. If you do get caught, I suppose you can always play dumb, and say “It wasn’t blocked so I thought it was ok now.”
Now, I’m not a network administrator by any means. I’ve configured a firewall and router or two, but that’s definitely not my expertise. I asked a buddy who was a network architect, why do so many companies let https traffic go through if they are concerned about content filtering. There were a few possible answers he gave. The first being that the companies don’t know that https traffic goes right through the web security product. The second answer was that they did know and they were just being lazy. After all they claim the average user wouldn’t know to try https. Whatever the reason, I have yet to find a company with a web security product where this did not work. Admittedly, that’s not a a lot of companies in the scheme of things, but it is worth giving a try.
Now for all of you conservative CIOs out there that happened to have stumbled on this article and are sounding the alarms to your network admins, maybe you need to ask yourself why you are blocking these sites. If the answer is because you are afraid of lost productivity, someone probably needs to relieve you of your job. If your employees want to find ways to not be productive, they are going to regardless of what sites you block. When a user gets a site blocked error message like the one above, what are they going to do? Ten years ago, they would have waited until they got home to go visit that web site. Today, that employee is going to reach for his or her smart phone and post their latest status update there. In effect, you have actually caused your employee to be even less productive. Instead of typing in that status update from the keyboard, he or she now had to tap it in on a tiny virtual keyboard with the auto-correct messing up every other word. Think about that.
One of the coolest features unique to SharePoint Online is the ability to share sites with external users. I’ve noticed the functionality was there throughout the beta but I believe I hadn’t actually been able to get it to work until GA. Even then, it took checking a number of settings before I could actually get it to work. You can share content with external users by using the new Share Site menu item in the Site Actions menu. When you start with a new out-of-the-cloud site collection, you will get a screen that looks like this.
Notice the key text on the screen:
Invitations to users outside your organization are currently disabled.
To enable this, there are a few things to check. First go to Tenant administration. Your URL is usually something like https://mydomain-admin.sharepoint.com. Go to the Manage Site Collections page and click Settings –> Manage External Users. Make sure you don’t have any site collections selected otherwise Settings will be disabled. Make sure the Allow radio button is selected. It is more than likely set to this by default.
Once you have confirmed this setting, go back to the root site of your site collection and go to Site Settings and then Site Collection Features. Here you will want to enable the feature External User Invitations.
Now, if you go back to the Share Site menu in Site Actions, you will now be able to enter E-mail addresses and the window will no longer have the warning about invitations being disabled.
I noticed it usually takes a few minutes for the E-mail to show up so be patient. When the E-mail arrives, you will see something like this giving the user a link to click on to join.
Clicking on the link takes the user to a page prompting them to login. They must use a Windows Live or Microsoft Online Services ID to login.
One thing to note is that the E-mail address associated with the Windows Live Id does not have to be the same as the E-mail you sent the user.
Don’t bother E-mailing me at that address, I never check it. 
As an administrator, you can now also manage this user in the Site Permissions page like any other user.
At this point, it seems like the user can do whatever they need to on the site with the users you provided. I’m not really sure how the licensing works in this scenario. These users don’t show up in the licensing page so I guess you don’t have to license them. Maybe an SPO licensing expert will chime in. :) There may also be additional limitations that I have yet to discover. If you find some be sure and share them with us.
I have to admit, the Document Id Service is really only exciting to a small handful of us. I show it to customers and people in my ECM talks and the response I get is, “meh”. However, the hardcore ECM people I know really like it and they are always looking for ways to utilize it in their solutions using code or search. Today, I thought I would show a quick tip on how you can use it in search results. Now you can always pass the Document Id to DocIdRedir.aspx, but you may want to display it on a search results screen. If you have defined your own document id prefix, you may even have power users that work with these ids regularly and may want to see them when they search.
To begin working with Document Ids in Enterprise Search, you first need to know which managed property to work with. The property DocId is the one you need to know. If you have read my article on naming conventions, you know I think it should have probably been named DocumentId, but oh well. :) If you are familiar with the keyword query syntax or my handy keywords blog post, you know that we can query this pretty easily. Here is the syntax.
DocId:"DocumentIdNumber"
As a reminder, you can view a Document Id on an existing document on the View Properties page of a document.
Taking that Id, I can now use it in search with the following query.
DocId:"YY7PPZHWQVY7-5-3"
Which will give you search results that look something like this.
Again, I know that might not be that exciting because you can use DocIdRedir.aspx. However, when you start thinking about custom applications and issuing custom queries using the Search web services, you might find it useful.
Let’s take it a step further and add the Document Id to the search results page. We’re going to do this in pretty much the same way, I added social ratings to the search results a while back. However, this time I am just going to edit the columns and XSLT in the CoreResultsWebPart instead of editing the federated location. Go to the results.aspx page of your search center and edit it. You then want to go down to the CoreResultsWebPart and edit it as well. Open Display Properties and uncheck the Use Location Visualization checkbox.
We first need to add the DocId managed property to the result set. We do this by editing Fetched Properties which contains a Column XML element for each property returned. There used to be an “editor” for this field in 2007, but they removed it. You may want to cut and paste it into Notepad to edit the XML first. Go to the end before the </Columns> line and add the following.
<Column Name="DocId" />
Word of warning. If you mess up the syntax of this XML or reference a managed property that does not exist, you will break search and get an error that says something like the following:
Property doesn't exist or is used in a manner inconsistent with schema settings.
You might want to keep a backup copy of the XML somewhere while you are working with it in case you have an issue. A lot of times I create another Search Center to try out my changes first instead of breaking the one everyone else is using. You can also uncheck the Use Location Visualization checkbox to revert back to the default XML. Once you do make your changes, I usually click OK and save the changes to my page to verify that I have not broken the Search results page. You won’t see any visual difference on the page yet, but if you get search results you know everything is working right.
Assuming that change was successful, we can now edit the XSL using the XSL Editor button to actually add the Document Id to the search results page. Finding the right spot can be somewhat tricky, but it’s not too difficult. A good spot for the Document Id is in the srch-Metadata2 div. This is where it already displays things like author, file size, and tags. Simply add the following right before the blank.gif reference and after the DisplaySize call-template.
Once the change is complete, click Save and then save the page as well. Perform your query again and you should now see the Document Id display along with your search results.
Of course, not every item has a Document Id assigned to it (i.e.: pages, folders, list items, etc). You may want to add a conditional to your XSLT to only display the Document Id when one exists. Just update your XSL with the following.
<xsl:if test="string-length(docid) > 0">
Document Id: <xsl:value-of select="docid"/>
</xsl:if>
This will only display the Document Id when one exists. If you haven’t checked out my post on handy keywords in search, go take a look. It has a lot of useful keywords that are out-of-the-box that you can build interesting queries with. I’ve also updated it to include information on DocId as well.