Saving me from myself…

So I just had an e-mail come through from twitter telling me that I had a new follower – unfortunately, it appears to be a twitter bot (you know, the personal picture of a scantily-clad blonde, who is following 1300 people, but has zero tweets & zero followers?).  So I decided to log on to twitter’s website and clean up my followers since I was pretty sure there were one or two others that had started following me this week.  As I was waiting for the page to load, I received an interesting pop-up:

image

I’m running Trend Micro’s Worry-Free Business Security 6.0 on my SBS 2008 network, and it blocked my access.  I found this rather interesting, because I know that I only have Trend doing basic web-filtering (e.g. only blocking known malicious sites).  I moved the pop-up window out of the way so I could see the page in the browser – which also showed the content was blocked:

image

However, the Page Blocked message in the browser helped me realize what happened – what I didn’t pick up from the pop-up window.  I had completely fat-fingered the URL and misspelled the domain name, only including 1 “t” in twitter instead of 2.  And obviously, this site must have some malicious content.  So a big kudos to Trend’s WFBS for protecting yet another user from themselves  smile_regular

External Links in Companyweb E-mail Alerts

A while back, someone in the SBS 2008 newsgroup had a good question.  Short story is that they are making extensive use of their companyweb, including content approval in some document libraries.  They have configured email alerts on these libraries, so approvers are notified when new documents are added and waiting approval.  However, a few of these approvers travelled regularly, and were often out of the office.  When they received new email alerts from their companyweb, the embedded links all pointed to http://companyweb/…  The obvious problem was that if they were working from their laptop with Outlook RPC over HTTPS at say an airport, Starbucks, or wherever then the links in the alert email wouldn’t work (since http://companyweb is only resolvable on the LAN).  The poster in the newsgroup asked where SharePoint stored the URL so he could edit it.

The beauty with this question is just how simple the solution is.  SharePoint 3.0 supports a single web application being accessible via different URLs, with the different URLs being in different security zones.  This is evidenced by your companyweb in SBS 2008 being accessible via both http://companyweb (intranet zone) and https://remote.yourcompany.com:987 (default zone).  When a user is creating alerts on a SharePoint site, SharePoint is smart enough to take note of which URL the user is using to access the SharePoint web application when they create the alert.  As a result, links in alert emails will include the base URL that was used to access the SharePoint site when the alert was created.  SO – if you browse to http://companyweb and create an alert on a list library, all emails you receive for that alert will have links that point back to http://companyweb.  On the other hand, if you browse out to https://remote.yourcompany.com:987 and create an alert on a different list or library, all emails you receive for this alert will have links that point back to https://remote.yourcompany.com:987

SO – if you have users who are regularly out of the office, rely on alerts from your SharePoint site and want to be able to use the links in the alert emails, make sure those users browse to the public URL for your companyweb when they create their alerts.