Why the State Department Doesn't Use Firefox

At a recent town hall meeting, a State Department employee asked Hillary Clinton why employees were not allowed to use Firefox. When it was suggested by Pat Kennedy that the reason was likely cost, it was humorously pointed out that Firefox is free! Har har! Yeeeah daaawg! Hand slap!

In a rare moment for government, Kennedy actually went on to explain what he meant by cost, which may have nothing to do with the actual cost of licensing the software itself. Maybe he just got lucky, but he's absolutely correct.

I've been crybabying about Firefox's complete lack of enterprise support for many, many years. We all know just how entrenched Internet Explorer remains in the corporate world, and this is responsible for much of the market share it still clings to. If Mozilla would just start offering services for business users, I think it would dominate the market in short order.

What do I mean by "support" and "services?" I'm not talking about contracts or paid subscriptions or anything icky. Maybe I can shed some light on the issue by describing what it's like to manage Internet Explorer on corporate desktops.

1) Even the most basic Windows Server can run, at no additional "cost", a service called WSUS, or "Windows Server Update Service" or something goofy like that. Using WSUS with group policies, even the most inexperienced IT professional can gain complete control over updating and patching just about all Microsoft products, including Internet Explorer, on all of the machines he's responsible for.

When a security vulnerability is patched in Interenet Explorer, which happens every 2.74 minutes, I can push the update out to all of the machines in my domain. It doesn't matter that the user who uses the machine has no administrative rights, and the user has no control over whether the update is applied. Thus using WSUS I can easily see exactly what's up with every installation of Internet Explorer on my network. To my end users it's completely transparent.

2) When using Internet Explorer in a Windows domain, it is trivial via group policy to completely control the behavior of Internet Explorer for all users and / or machines. I can lock down security settings, configure default home pages, and all sorts of fun stuff. Mozilla does not directly support this for Firefox.

3) If machines in a business environment are running Windows, then it's very likely that any local browser-based services are using some form of Windows authentication. With Internet Explorer this is of course supported by default. When a user logs on to a machine and uses IE to hit the corporate intranet, he is automatically logged in to the site using his domain credentials. The user has absolutely no idea that he's logging in, it just works.

With Firefox NTLM authentication does exist and actually works. In fact, I can configure Firefox and actually use it to browse a local Sharepoint site, and from an authentication standpoint it works just the same as IE. However, I cannot easily push these settings out to Firefox installations using group policy.

Ok, so what does Mozilla need to do in order to get the enterprise online with Firefox?

1) Offer a simple way to control updates. We cannot simply hope that users update when prompted, and updates won't even work for locked down users, which is about 99% of them. Requiring that IT build and deploy an .MSI every time Firefox is updated is unreasonable and costly.

There are projects out there like FrontMotion that offer a Firefox package that takes away much of the burden, but this makes us rely on FrontMotion for timely updates. This is not something I want to leave to some independent third party. This is exactly what I want *from Mozilla* itself.

2) Offer administrative templates so that Firefox can be configured via group policy, including the ever-important NTLM authentication settings. Again, this has to come directly from Mozilla or it's probably just not going to fly.

That's it.

How much work would this be for Mozilla? I dunno, but gauging by what FrontMotion does, I don't think it's an insurmountable task. (I think FrontMotion might just be one person!) Considering the market share that Firefox would gain, I'm absolutely dumbfounded as to why they haven't even tried this yet. It's not like it hasn't been requested by users for years and years!

"Ok, well if it's really not that hard, then why not just do this yourself in-house?"

Because that would *cost something*. Just sticking with Internet Explorer doesn't cost anything more than what I'm already spending. Yes, it's an inferior browser, but it works and users are familiar with it. Its security shortcomings are mitigated by making sure that all users have restricted accounts. (It's not like Firefox doesn't have security problems from time to time)

Since Firefox is a better browser in many ways which we don't even need to get into, and a lot of people are now using it at home, I can matter-of-factly state: if Mozilla was able to give me what I want, I would immediately offer the option of Firefox on all desktops and over time switch all default browsers to it. Everybody wins, right? What's the holdup?

Vista Multiple Monitors Bug with Terminal Services

If you're running multiple monitors on a Vista machine, and then login to that machine remotely, your remote view will only show the contents of the primary monitor (resized appropriately).

This isn't such a big deal, but if you do this regularly you'll certainly have run across a bug in which the secondary monitor will be reset to its lowest resolution when you log on to the dual monitor Vista machine locally. I think I've blogged about this problem before, but now I have a fix:

When the secondary monitor is stuck at its lowest resolution, do the following:

1) Right click on the desktop and choose Personalize.

2) Click on Display Settings.

3) Adjust the secondary monitor to maximum resolution and click apply.

4) Curse loudly because the monitor resets again to low resolution.

5) Adjust the secondary monitor to maximum resolution and click apply.

6) Goddammit.

7) Disable the secondary monitor and click apply.

8) Adjust the secondary monitor to maximum resolution and enable it.

9) Whatthehellisgoingon?

10) Adjust the secondary monitor to some value between its lowest resolution and maximum and click apply.

11) Eh? For some reason this resolution will stick.

12) Adjust the secondary monitor to its maximum resolution and click apply.

13) Goldarnitall! It'll be back to its lowest resolution.

14) Adjust the secondary monitor to its maximum resolution and click apply.

15) Repeat step 14 until the secondary monitor finally adjusts to maximum resolution.

16) Write blog post.

As you can see, this is a relatively simply procedure. I decompiled the Vista code for setting display resolution, and think I've found the bug (I prettied it up a bit for readability):

if ((userLastLoggedInFrom() == TERMINAL_SERVICES) {
 if ((attemptsToChangeResolution() < 35)     
    && (rand(100) == 42)) {
   setDisplayResultion(requestedValue);
 } else {
   setDisplayResolution(
     (requestedValue < MAXIMUM_RESOLUTION)   
     ? requestedValue : LOWEST_RESOLUTION);
 }
}

As you can see, the magic value "35" should probably be something more reasonable, like "23". Perhaps there is a registry hack.

Oh well, this isn't quite as bad as keeping dual monitors working correctly on Ubuntu, for which the only proven solution consists of copying random xorg.conf files from Google searches until you find one that works.

Server Fault Answers Your IT Questions!

The guys who gave us Stack Overflow have recently begun the private beta of their new site: Server Fault. If you've got an account on Stack Overflow with a reputation above 100 points, then you're eligible to try it out.

For those not in the know, Stack Overflow is a place for asking and answering computer programming questions. Unlike traditional web forums, the Stack Overflow community enforces a strict question and answer policy that allows very little room for back and forth discussion. Along with a very game-like reputation system and wiki-ethic, this results in fairly solid questions with very firm answers.

What makes Stack Overflow so special is that it's fun. Because it's fun, questions get answered fast. Very fast. Really, it's changed the way I think about interacting online when trying to solve a problem. In a traditional forum one might expect an answer to question in a few hours, maybe a few days, and maybe not at all. On Stack Overflow I'm typically seeing my questions answered within 15 minutes. If the question is particularly obscure, maybe an hour or two. The quality of the answers is excellent because your "thread" doesn't die out with people asking questions about your question or taking guesses at the solution.

Anyhow, the Stack Overflow people are bringing this resource to the IT community and man do we need it. The IT community is scattered all over the web with only a few horrible sites like Experts Exchange trying to serve as a catch-all. Hopefully Server Fault will become the one-stop resource that we so badly need.

New Carreer Path: Snopes Consultant

By now, every single person working in any business that uses email is familiar with Snopes.com. They all know about Snopes because every time one of them forwards a chain letter, an annoying twerp like me sends back a link to Snopes. This annoying twerp makes sure to hit the reply-to-all button so that everyone in the whole freaking company can bask in the forwarder's gullability.

What's odd about this whole notion is that it even exists -- the problem, I mean. The problem of forwarding stupid chain letters with fake health warnings, fake George Carlin quotes, fake pictures of the IT guy picking his nose, etc. No matter how many times a person has been "snoped", they will continue to forward every piece of misinformation that hits their inbox. After a while they'll even preface their messages with something like, "I'm not sure if this is on Snopes or not, but..."

That last bit got me thinking. Perhaps I should start a Snopes Consulting Service through which people could call in and ask if what they're about to forward to five hundred people is true or not. While a phone service doesn't exaclty jive with our new Web 2.0 world, I think that it's the appropriate technological medium for this class of people.

Me: "Hello, Snopes Dopes, Inc."

Them: "Yeah I got this email and..."

Me: "What's the title?"

Them: "Um.. FW: Giant snake served in military with George Ca..."

Me: "Fake! This bit of sanity brought to you by download.com, your number one source of downloading from dot com."

See, there's even a monetization strategy!

Things You Should Know About Liferay in the Enterprise

A few days ago I wrote a goofy post about the current state of open source Java-based portal software in which I half-concluded that Liferay is the only choice worth considering, and that unfortunately Liferay will drive a person completely insane.

I stand by my claims, but after the comments I received I think that I need to let people know where I'm coming from. What I want from a portal is an out-of-the-box collaborative experience to synergize my enterprise. But seriously, what I want is an application that can satisfy two basic requirements:

1) The application should provide all of the basic collaborative features that one would expect to use here in 2009. What does that mean? It means wikis, blogs, forums, chat, file sharing, etc. These are not things that I want to spend time implementing.

2) The application should be extensible. This is the whole point of a portal, and all portal applications meet this requirement.

Given these requirements and then considering the sorry state of open source portlets, the only choice worth considering is Liferay. The whole point of Liferay is that BAM, your Intranet portal is up and running and usable, and you can get on with implementing the important bits that are specific to your business.

When you first install Liferay, it's a very "WOW!" experience. It actually starts up and works and looks slick. Drag & drop, tons of portlets, etc. For a good week or so you can have a lot of fun setting it up and showing it off; your friends and collegues will be amazed! But when you actually start to get in to the nitty gritty of your Liferay implementation, things start to fall apart.

I spent a fair bit of time trying to decide if I should write this post or not. On one hand I'm really starting to like the Liferay community, and the developers seem like good people. On the other hand, there's not a lot of information out there about Liferay and I feel like the whole point of the "blogosphere" is to share our experiences for the betterment of all. Everything I'm writing here is based on my own personal experience with Liferay, and unfortunately, just about everything I write from here on is going to be negative.

Advice about Liferay in the Enterprise (or just your Business):

1) Liferay security is extremely poor.

I know that this might be a little controversial as I've read other blogs praising Liferay's permissions system... but really, just because something is really hard to understand doesn't mean that it's good, or even working.

If you're setting up Liferay in your business, then it's imperative that you test and re-test the restrictions in place on every single bit of data that you're exposing through your portal. One of the biggest problems I've had with Liferay is little pieces of confidential information showing up here and there for people who should not have access to it.

For example, the search portlet *will* comprimise security by showing search results, complete with abstracts, to users that should not have access to them. If you have a wiki hiding somewhere in a closed community, and have the tightest permissions on that thing you can possibly set, the search portlet is still going to show results from that wiki to every knucklehead on the site. The reason for this is that Liferay's opensearch implementation doesn't yet do "Liferay permissions." There's no big warning anywhere about this, so hopefully you found out about it by reading this instead of the hard way. My advice: do not use the search portlet.

Another example is the fine-grained permissions for each portlet. Often times they simply do not work correctly. Take the message board: if you create a restricted category (e.g. "forum"), then the posts in that category do not inherit its permissions, and are viewable by anyone with a link. Then, even if you lock down the security of each post in the restricted category, the post title and abstract will still appear to anyone who clicks the "Recent Posts" tab! This problem isn't isolated to the message board; I've found similar behavior in the document library and blog portlets. My advice: do not use fine-grained permissions in Liferay. I should also note that the activities portlet doesn't respect fine-grained portlet permissions at all.

If the above aren't enough to make you uneasy, then there is also a report of an NTLM bug in which any non-domain user can login as any user with a blank or random password. This is a big one, and one that should have been nailed immediately. That it existed in 5.1 and still exists in 5.2.1 is inexcusable. My advice: do not expose your Intranet portal to the outside world.

2) Liferay is very buggy.

It seems like everytime I try to set something up, whether it be a wiki or a blog or whatever, I run into some maddening bug. For instance when editing a wiki page or forum post, all of the new line characters disappear! This makes the entire wiki virtually unusable or at least a significant pain in the rear. A bug report was filed for this one and a fix has been committed, but the problem exists in the default 5.2.1 package that you're going to download. Heck, it even exists on the Liferay community site itself.

Aside from that I've seen 3rd party portlet javascript completely break Liferay's javascript, bugs in the new scoping feature, portlets that simply don't install or work, and a variety of other flaws. Without going into detail about every annoying little thing that I've run across, I'll just leave you with this: be prepared to download the Liferay source and do a bit of patching yourself.

There are hundreds of bugs in the Liferay JIRA, and something like 75+ critical bugs. They don't seem to get patched up very quickly. I know the developers are doing the best they can.

3) Documentation is hit or miss.

The Liferay Administrator's Guide is fantastic. Unfortunately, it's for 5.1 and some important bits aren't going to work for 5.2. Things like database configuration. The Liferay wiki is ok, but I really have a hard time using it. For whatever reason, it's very hard to drill down to topics that are relative...everything's in this search view that returns way too many results. I hate wikis for technical support anyhow because the information is almost always incomplete or out of date.

4) Community is hit or miss.

The community can be really great, and it can also be really bad. What I've found is that a single user who really gets on the ball in the forums can start a chain reaction and forum usage goes up. All too often, however, the forums seem to wither and a lot of posts with good questions go unanswered.

If you're going to use Liferay, then I recommend getting active in the community, and don't let your questions go unanswered. Bump away. The traffic on the forums isn't very high so nobody is going to get too upset.

5) The permissions system is whack.

There's a hilarious diagram in the Liferay Administrator's Guide that is intended to make the permissions system easy to understand. On the contrary, it just demonstrates the complexity. Maybe I'm "old school" or something, but users and groups are just fine. Want to throw in roles? Fine. But I don't need communities and organizations and locations and public and private pages and everything else all mixed up with users and groups and roles.

Here's what I recommend: assuming that you're going to want to bring your users in from LDAP or some external source, don't bother using Liferay organizations. The idea behind organizations is interesting, but the benefits of using them are very few and I've run into more bugs due to the added complexity. Instead, just use Liferay communities. Unlike organizations, user groups can be associated with communites, which allows you to grant access to a particular community to a user group that you've imported via LDAP. This way you can manage your users in a more centralized way, which is sorta the whole point of LDAP.

Another recommendation: use public pages sparingly. From what I can tell, public pages in Liferay are groups of pages with Guest access hard wired to "on". I can't think of many good reasons for this in a corporate environment, especially if you occasionally have guests on your network.

6) Liferay releases are... odd.

Be very careful before deciding to upgrade to the latest release of Liferay. With 5.2 we saw changes to database setup that were sort of hard to find, a bunch of example data that had to be physically removed, and a whole bunch of portlets and themes that took a month or so to be released.

7) Performance is pretty poor.

Now maybe I'm being too harsh, but the requirements for running Liferay are pretty high. Be prepared to dedicate a server instance to Liferay with a couple gigs of memory and a decent CPU.


Ok, so I think I've covered everything that's bothered me about Liferay thus far. Reviewing my list, it almost seems like Liferay could use some real business-grade suit-and-tie management to make sure that priorities are set and that the project as a whole moves in some well-defined direction. With things like Social Office taking up developers time, I really don't see the overall quality of Liferay improving much. Given that, it's important to take it for what it is and work around its problems and limitations because it is a good product. It's miles ahead of the other portals out there in terms of end user experience, administration, and simply getting a full-featured portal up and running in short order.

Microsoft Small Business Server 2008 - Great Value?

I've used Small Business Server and for the most part have found it to be a pretty good product at a pretty good price. I was surprised recently to learn that they've removed ISA Server from SBS 2008, and decided to go see exactly what you still get in the latest version SBS.

From Microsoft's own SBS feature list:

1) Windows Server 2008 Standard. Ok, that's sort of expected.

2) Exchange Server 2007 Standard. Ok good, this is necessary in the age of Outlook.

3) Windows Sharepoint Services 3.0. Um...this is a "free" product.

4) Forefront Security for Exchange. 120 day TRIAL VERSION? Odd...

5) Windows Server Update Services 3.0. Hm, this is another "free" product.

6) Windows Live OneCare. Another 120 trial version! Wha??

7) Microsoft Office Live Small Business. Yet another trial!!

8) 900 Free Minutes of America Online! Just kidding.

9) SQL Server 2008 Standard for Small Business. Ok, whew. It's something anyhow.

So let's see what we've got here. It looks like 3 major server products, two free products, and three trial products.

Ok, so for the three products you actually get (note, only the Premium version gets you SQL Server), the price is still pretty good. However, I wouldn't recommend running SQL Server in a small business. It's just not worth the lock-in. Free database servers like MySQL are powerful enough for just about any small business need, and you aren't restricted to how many instances you can install and on which machines, etc.

So really with SBS 2008, it looks like the real benefit is that you get Windows Server and Exchange at about half price. It's not a bad deal, but you are trading some flexibility.

ISA Server will be missed. Although it was a bloated pain in the ass product, it does offer one feature that most external firewalls don't: management of rules and policies and even reporting for specific active directory groups and users. The integration is what sold it. Oh well.

How to Select an Open-Source Java Portal for your Enterprise

As usual, I'm spending a lot of time trying to select the appropriate open-source java-based portal for my enterprise (e.g. "company"). I say "as usual", because I've been doing this for a couple of years now. With this vast experience under my belt, I thought it appropriate to share my strategy and process with you all.

1. Determine Your Requirements

This is the best part of portal research! You should write down every cool idea you can think of. Dare to dream big!

Ok, now start crossing stuff off until you're left with the following:

Requirement #1: Portal must work.
Requirement #2: Portal must include Amazing Google Maps Mashup portlet, RSS Reader portlet, and Analog Clock portlet.

There, now you've chosen some realistic requirements.

2. Observe the Desolate Playing Field.

Ok, there are really only a few choices here, so let's not complicate things too much.

Contender #1: Liferay.
Contender #2: Jboss.
Contender #3: eXo.
Contender #4: GridSphere.
Contender #5: StringBeans.
Contender #6: Jetspeed and the like.

3. Choose Liferay

It's just the obvious choice. It looks good. It's easy to create layouts. It has an analog clock portlet. Oops, analog clock isn't available on the latest version. Oh well, it still has Google Maps and an RSS reader, which are both critical to business operations.

But seriously, it has a crapload of portlets and is fairly easy to get running.

4. Fall Out of Love with Liferay

Ok, you know that one feature that you left in your requirements even though I told you to cross it off? You know how you're all excited about Liferay having a sweet portlet that satisfies that requirement? Well, that feature is probably broken.

5. Hate Liferay

This is a big step in our process. It takes a little while to get to this point, and it's important to simply confront the fact that you hate Liferay. Listen, it's ok. Don't feel bad for the way you feel. We've all asked questions in the Liferay forums, and we've all experienced that 90% of them go unanswered. We've all been trapped by a bug fix over here that breaks something over there. Yes, my friend, that portlet really did disappear after you upgraded, and it might not be coming back for several months. No, the code comments aren't just hiding somewhere.

6. Visit JBoss Website

Jboss Portal is it. This is a big company sponsored project. We all know about it. Hell, we have unopened email somewhere deep in our inbox from a RedHat salesman trying to sell us this amazing free software. Look at this site, it's so awesomely corporate.

7. View JBoss Portal Demo on JBoss website.

8. Download eXo Portal.... and stuff

So you've heard a lot about eXo, and holy crap the featureset is huge. This one product can do everything you need, and everything you didn't know you needed. Except it's not just one product, it's a half dozen different products. Oh, but there's an "all-in-one" product, cool. Wait a minute... how the hell does this thing work... let's look at the documentation...

9. Visit Gridsphere Website.

Quick, find a screenshot. I'll wait.

10. Check out StringBeans.

Wha?

11. Look at JetSpeed, uPortal, and All the Other Products That Would Appeal to those Guys Who Use vi and Brag About It.

12. Go Back to Liferay

By this time you've forgotten all the bad times, and Liferay is starting to look pretty hot again. Maybe this time it'll work out. Maybe it was just you. Maybe Liferay has really changed this time.

13. Repeat this Process ad nauseam.

Meanwhile, you're still using Sharepoint.