The user community likes fast resolution, instant search ability and interaction with experts and other users. Because of that, Likewise Software today launches Likewise Forum. Now, users and customers can quickly find technical information and support for Likewise Open and Likewise Enterprise by means of a user-friendly search feature. In addition, the Forum has a variety of sections for Likewise Software users such as Likewise Open Installation, Likewise Open Trouble Shooting, Likewise Open User Stories, Likewise Open FAQ, Likewise Enterprise FAQ, and many more. Anyone can read previously written forum posts, but registration to the forum is necessary to create new posts or respond to posts.
We hope our users find this a valuable resource and welcome your feedback.
For more information please visit the Likewise Software forum at http://www.likewisesoftware.com/community/index.php/forums/.

At Likewise, we’ve just recently announced the “Fall Edition” of our software. If you haven’t done so already, you shouldn stop now and read Krishna’s post on the topic.

I know, it’s a long post but, hey, we’ve got a lot to talk about in this release! There’s LWIS (a German pun on “Elvis”), there’s the new event system, the Likewise Administrator’s Console and support for the Mac Workgroup Manager. Each of these warrants its own post, elaborating its features. In this post, however, I’m going to write about something that Krishna mentions only in passing: the new underlying architecture. While LWIS (the new Likewise authentication engine) is the most clear manifestation of this new architecture, it’s impact to the current and future products is much more significant.

Before I get into the details of the new architecture, let me describe the fundamental elements of authentication and why we decided to redesign our product.

Fundamentally, authentication against Active Directory does not seem like a difficult problem. AD supports the Kerberos security protocol. To logon to AD, first you need to “join” the computer to AD and then you need to send some Kerberos packets to get a user “TGT”. This TGT, later, lets you get “service tickets” for other systems allowing single sign-on. After a user is logged on (to a UNIX, Linux or Mac computer), you then need to implement a series of nsswitch library functions to perform name-to-ID mapping. Implementing these functions usually involves performing a series of LDAP transactions in order to look up information in AD.

So far, the problem doesn’t seem very complicated. Indeed, years ago, someone wrote pam_kerberos and a set of nsswitch libraries to do exactly this. Alas, this simple-minded approach turns out to be difficult and inadequate. Joining a computer to AD involves creating a computer account (and Kerberos principal). Doing this “by hand” involves steps on both Windows and non-Windows computers and copying keytabs around. Additionally, AD doesn’t like plain old LDAP calls - it wants them to be secure and encrypted. Doing this with SSL encryption involves certificate distribution and other messy details. Beyond this, there are the issues of “offline-mode”, site affinity, domain controller selection, automatic machine password changes, Kerberos ticket refreshes, dynamic DNS updates and a host of other problems. Oh, there’s Group Policy, too. Hey, if it was easy, Likewise would not be in business.

The authentication engines in Likewise 3.0 through 4.1 were based on Samba source code. Samba has been in the Windows interoperability business for years and has solved many of the problems mentioned above. Likewise employs several Samba developers and has been a major contributor of features and bug fixes for several years.

With 5.0, we decided to rewrite the authentication engine to remove our dependency on Samba. Why? Because we wanted to develop an architecture that would serve our needs for the next 5-10 yeas. Our interests in the Identity Management business go significantly beyond authentication and group policy. We need a flexible, modern, architecture that suited our technical and business purposes. Let’s consider the elements of the new architecture.

First, 5.0 is based on a formal RPC (remote procedure call) architecture. In order to join a computer to Active Directory and to perform a series of other operations efficiently, the Likewise agent performs RPC calls rather than LDAP calls. These RPC calls are described using a formal IDL (interface definition language) and translated by a compiler into a set of stubs that handle marshaling of the RPC calls. In 5.0, we’ve defined an IDL language and an IDL compiler that is Microsoft compatible. We can take IDL files designed for Windows and generate stubs that work on non-Windows systems.

Second, because Windows systems accept RPC calls using TCP or named-pipe protocols, we’ve implemented RPC transport layers that support both of these protocols.

Needless to say, the RPC calls support authentication and signing/sealing with Kerberos protocols. Additionally, however, because we’ve implemented a local provider for LWIS, we also support authenticated, secure, calls between UNIX, Linux and Mac computers (or, for that matter, between non-Windows and Windows systems using local credentials instead of AD credentials).

Only Likewise 5.0 is based on a formal RPC architecture and only Likewise provides this architecture as open source to others who want to build on it.

There’s another reason why we’ve implemented 5.0 in this fashion: it’s how Microsoft does it. Krishna, several of our developers and I are all ex-Microsoft folk. When you’re trying to talk to Microsoft systems, doing ala Microsoft makes a lot of sense to us. Note, too, that LWIS (like lsass, its Windows equivalent) is thread-based. Samba was originally developed at a time when threads were not consistently implemented across UNIXy operating systems and, often, performed poorly or were not reliable. Likewise has developed thread-support libraries to deal with inconsistencies (for example, exception handling) between OS thread packages. The result is that LWIS is highly scalable, easy to understand, and easy to debug.

When we developed the new event log system in 5.0, we also exploited the new RPC architecture. As with most Windows APIs, the event log API is remotable. By calling our API, you can read or write from/to an event log on another computer just as easily as you can to the local computer. The RPC mechanism takes care of the remoting, authentication and securing of the call. It will be trivial for us to write an archiving event log collector without having to worry about clear-text UDP messages or about a custom security mechanism (problems encountered by syslog-based solutions).

Implicit in the previous paragraph, by the way, is that we’ve implemented our RPC mechanism on both the client and server side. Implementing server-side RPC will allow us to implement future functionality that requires centralized management consoles to call managed computers.

There are many other things “in the works” that will build atop our new architecture. Some of these will be appearing soon and some will take a little longer for us to complete. As I like to say, however, “in the startup world, there are only two times: now and six-months from now.” Beyond that, it’s anybody’s guess.

Mac administrators understand their systems far better than Windows administrators. They have a better understanding of the different kinds of MCX settings that can be applied to a OS X desktop.

Enterprises however use Active Directory and Windows Group Policy to deploy standard settings throughout the enterprise network to desktops.

What if you could store MCX settings as Active Directory Group Policy objects? This would allow enterprise administrators to deploy standardized system settings to Macs.

What if you could still use the Mac Workgroup Manager tool on a Mac to design and create the standardize template of MCX settings and upload them to Active Directory as group policy objects? This would allow the subject matter experts (the Mac administrators) to decide what the settings should be, but allow Active Directory’s group policy infrastructure to push out the settings to the individual desktops.

Enter Likewise Enterprise 5.0 - marries the Mac desktop management with Windows group policy technology

Welcome Mac OS X into the large enterprise network!

[Note: this post is long and it’s probably going to go through several edits, but I believe it is worth reading through]

Well, it’s been a while since I’ve blogged. I’ve been heads down on getting the latest release of Likewise out the door. I want to use this post to tell you what we’ve been up to at Likewise

Yesterday, the official press release went out announcing the general availability of Likewise Open Fall Edition. I couldn’t be more excited about this release. This release, I believe, will be the high mark for comparison and differentiation in the open source world for what it means to support Windows interoperability in non-Windows systems

First, an explanation on numbering and editions is probably useful. The latest version of Likewise technology is 5.0. We’re using seasons to identify specific Open editions and Likewise Open Fall Edition is built on Likewise 5.0 technology. In contrast the Enterprise versions of the product continue to keep version numbers. So the forthcoming release of the Enterprise product will be Likewise Enterprise 5.0

Likewise 5.0 is our most ambitious and comprehensive release to date. The range of features and their ramifications are huge. I’ll start by enumerating what Likewise 5.0 will provide.

LWIS (the LikeWise Identity Service) is our next-generation authentication engine has been built from the ground up. Here is a sample of what LWIS offers

LWIS is a single-process, multi-threaded engine that is capable of hosting multiple server-side authentication providers. Today it will ship with two distinct authentication providers:

The Local Authentication Provider is a full local authentication database. It allows the creation and manipulation of local users and group objects. This provider supports functionality similar to the Windows local SAM authentication database present on every Windows client and server operating system.

The Active Directory Authentication Provider provides a full authentication and account management interface to a Microsoft Active Directory forest.

• Multiple uid-gid configuration modes. The AD provider supports three different retrieval mechanisms for returning user uid and group gid information. The first two modes: default and cell mode are retrieval mechanisms predicated on the AD domain being provisioned to store uid and gid information. The third mode: the unprovisioned mode functions without any changes made to the AD domain. The default and cell modes can function with the AD schema being extended to support the RFC 2307 attributes or without the schema being modified.
• Password and Kerberos Keytab Manager. When a machine is joined to an Active Directory domain, the machine’s name, site information, the name of the forest and domain are stored securely. In addition, the machine’s password is securely stored. Associated with the password, machine’s host keytab is derived off of the machine’s password. A clean interface and library of calls is provided to update this information. In addition APIs are provided to determine whether the machine is joined or not and to retrieve the machine’s hosting forest, domain and site information.

• Machine Password Refresh Manager - Active Directory requires that the machine’s password be periodically refreshed. A machine password refresh thread run periodically within the AD provider updating the machine’s password based on a policy configurable interval.

• Time Synchronization Subsystem .The time synchronization subsystem serves as a backup mechanism for misconfigured or absent NTP support on the joined machine. This system ensures that machine’s system time is synchronized to that of the domain controller.

• Site Management and Site Affinity. A full implementation of Active Directory site management and site affinity is provided. The machine will “affinitize” itself to the closest dc within its site. In the absence of the closest dc or the closest dc going down, the site affinity system will “reaffinitize” to the next available dc within the machine’s site. Additionally, site affinity is supported by a separate netlogond daemon which can be programmatically queried by all applications on the system thus ensuring that all applications communicate to the “affinitized” dc.

• Multi-forest support. The following scenarios have been supported.
o Single domain, single domain tree, single forest
o Multiple domains, single domain tree, single forest
o Multiple domains, multiple domain trees, single forest
o Multiple forests, two-way transitive trusts
o Multiple forests, one-way transitive trusts

• Cached credential support. LWIS supports a cached credential login model in the event that no domain controllers are reachable. See the section on site affinity for further details on domain controller reachability.

• Kerberos Ticket Management. The LWIS AD Provider also manages refreshes of kerberos tickets with specific attention to the logged on users’ TGTs.

• Kerberos and NTLM Password Authentication The implementation provides support for NTLM style authentication in addition to standard Kerberos password authentication.

• Integrated Change Password Support LWIS provides the ability to cleanly change AD passwords from Linux/UNIX clients and honors all change password settings i.e. allows users to change passwords at logon, allows users to change their AD passwords at will etc. etc.

• WBL API Integration LWIS is a fully compliant WBL (Winbind Bridge Library) service provider. This allows out-of-the-box integration with the Samba smbd file server and allows LWIS to serve as a clean winbind replacement

• DCE/RPC Framework LWIS provides a full MS RPC compatible DCE/RPC implementation that ships with the product. This allows OEMs and other customers to build their own Windows compatible RPC clients and servers. The DCE/RPC framework comes with a full idl compiler, the dce/rpc runtime, a platform neutral threading library and full support for Windows authentication libraries

• Native NetAPI Implementation for Linux/UNIX. A full native implementation of the Windows NetAPIs is available. The LWIS daemon uses many of these calls for authentication, multi-forest support and changing passwords. A list of the supported APIs will be provided in a further release of this document.

• OpenLDAP with GSS-SPNEGO support The vanilla openldap libraries do not have built-in support for GSS-SPNEGO. As a result, it is near impossible to cleanly access AD directory infrastructure. LWIS ships an enhanced openldap client library set that provides full support for the LDAP_AUTH_NEGOTIATE option and full support for signing and sealing of LDAP traffic

• Native GSS-NTLM support. LWIS ships libraries that provide native GSS-NTLM authentication for both local (peer-to-peer) authentication and pass-thru authentication to an NT4 or greater domain controller.

• Domain join system configuration library. LWIS also ships libraries that auto configure a native Linux/UNIX machines by provisioning and de-provisioning PAM, nsswitch, /etc/hosts, and kerberos configuration files for seamless and error free domain join behavior.

Likewise Event Log Subsystem

The Likewise Event Log Subsystem is an eventlog daemon that runs on a target Linux/UNIX platform. While similar to the Windows eventlog subsystem, it comes with significant enhancements including an embedded Sqlite database that allows rich queries to be executed on the server. The Event Log subsystem’s interface is built on top of our DCE/RPC subsystem which allows authenticated RPC queries to be run from remote clients as well as local clients. At the time of this writing, all of the Likewise subsystems including the authentication subsystem, the group policy subsystem and other UNIX logging systems have their security event log stored in this event log database.

Likewise Administrator’s Console (LAC) is our graphical console. It has the ability to load multiple plug-ins that can provide administrators’ the ability to administer a variety of subsystems. LAC will ship with plug-ins that can remotely manage local users and groups, a full Active Directory management editor, a full remote event viewer. In addition, our Likewise Enterprise release allows you to manage group policy objects as well. LAC’s versatility is derived from the fact that it has been written from the ground up using the .NET framework and can thus run natively on Windows, Linux (all flavors that run a graphical desktop) and all Mac OS X versions.

Licensing Likewise is fully committed to the open source process. Every thing we’ve developed in Likewise Open, the LWIS technology is being released under the LGPLv2.1 and the GPLv2.1. Our model is very simple. We will release all client API libraries under the LGPL and all daemons under the GPL. This means that just like how proprietary software uses glibc, they can use the LGPL libraries of Likewise, and appropriately protect their IP. We’re releasing our IP as open source, but we’re not choosing to mandate what people who call our libraries choose to do. In the case of daemons, we think it’s fair that if you make changes to the authentication daemon or other daemons, you should contribute those changes under the terms of the GPL.

Because we’ve written LWIS from the ground up, Likewise owns the copyright to all the source code. This allows us to license the source code under different licenses if we see fit. We’ve had several OEMs approach us and ask for a different license and we’re able to do this as well.

The Future: Making a Windows-compatible Distributed Systems Fabric available natively on Linux /UNIX/Macs

When I joined Likewise over two years, I thought to myself that I would like to spend my time making non-Windows systems first class citizens in a Windows network. This would mean real, tangible interoperability. This would spur choice among customers to adopt whatever platform they felt was in their best interests. The way to do this was to ensure that we could build the same distributed systems substrate that Windows is built on natively on non-Windows systems. There’s tons of work that needs to be done here, but every release, we’re getting closer to that goal.

Finally, I’ve just got to make a plug for the company. If you’re a system’s administrator or IT architect looking to integrate your systems into Active Directory, you should look no further than Likewise Open and Likewise Enterprise. Likewise Open is FREE and a completely full authentication stack for 118+ platforms. It’s is a pure subset of Likewise Enterprise which seamlessly adds on group policy support. Think about it!

Thanks for reading!

I’ve spent some time recently looking at the Windows Presentation Foundation (WPF). WPF is part of Vista, part of .NET 3.0 and part of Silverlight.

At some level, I’m disappointed with WPF. After hearing so much about it (but ignoring it) during the last few years, I expected it to be a radical new way of writing graphical user interfaces. Instead, it seems like a slightly different way of developing Winforms applications.

With .NET 2.0, you use Visual Studio to design your Windows “forms”. Visual Studio automatically generates code for you that creates all of the visual elements (windows, buttons, list boxes, etc.) at run time. When your form’s constructor is called, it calls “InitializeComponents()” and the generated code does the rest. The Visual Studio forms editor also lets you easily attach code to different events raised by the visual components.

With WPF and .NET 3.0, you use the Expression Blend tool to design your user interface. As with the Visual Studio forms editor, Expression Blend also lets you easily attach code to handle UI events. The output of Expression Blend, however, is not code, it’s XML. When your code’s constructor is called, again, InitializeComponents is called but, this time, the function works by loading the XML and interpreting it (creating forms, buttons, list boxes, etc.) rather than by executing generated code.

At this level, the only advantage/difference of/between WPF and .NET 2.0 Winforms is the use of XML rather than generated code. Mind you, this can be a significant advantage. By managing the UI specification as data separate from code, WPF facilitates the use of skilled graphical designers to develop user interfaces. Designers can use Expression Blend to fine tune UI without worrying about unintended changes to program code.

After looking WPF further, however, I realized how it is more significant than it appears at first blush. The WPF designers have completely reimplemented the basic Windows UI elements (and more) in a much more cohesive, sensible, fashion. The net result (no pun intended) is very cool.

For 20 years now Windows programmers have been suffering the limitations of the original Windows 1.0 design from 1985. Windows 1.0 defined a basic set of UI controls: window, menu, list box, static control, text control, push button, radio button and group box (I think that’s all of them!). These controls were implemented by Windows itself and could be composited by programmers in their own applications. Additionally, programmers could subclass these controls to alter their behavior or to implement their own user-defined controols.

Subsequent versions of Windows introduced new controls. Somewhere along the line, combo boxes, context menus, rich text controls, progress bars and other controls were added. The concept of a small set of built-in controls with narrowly prescribed behavior persisted however. You could do some things like image-based pushbuttons or scrolling lists of images by taking advantage of owner draw features but the amount of customization available with the built-in controls was minimal.

.NET 1.1 and 2.0 added new controls, too, including DataGrid and DataGridView that had no built-in counterparts. These controls, however, resembled the built-in ones in how the could be used and customized.

With WPF, the original Windows UI elements are totally subsumed by the new WPF UI model. It is possible to use WPF to write what looks like a traditional Windows application, but it is also possible to write applications with much more sophisticated user interfaces.

WPF has a very clean notion of containment and transformation. Let me explain what I mean by these. Consider a traditional Windows 1.0 List control. It contains a list of strings and can present these strings in a vertical list, providing scrollbars if they are needed to view all the list contents. In WPF, the ListBox control is a container that will provide a scrolling list of whatever it contains. What can it contain? Anything! Well, any WPF UI element. If you put static text boxes in a WPF list, it’s alot like a Windows 1.0 list. But if you want, you can put editable text boxes or tree views in a WPF ListBox and it will do the right thing with them. There are several container controls in WPF and all of them support this functionality.

Similarly, WPF provides a consistent mechanism for visual transformation. In graphics (and, don’t forget, WPF has full support for 2D and 3D graphics) “transformation” refers to mathematical manipulations to modify the appearance of what is being displayed. There are translation, scaling and rotation transformations that can move, size and rotate graphical data. WPF supports these transformations, too. If you surround a text box with a 90 degree rotation transformation, the text box will appear (and function) vertically instead of horizontally. Transformations can apply to entire graphical elements (for example, our previous ListBox) or to contained elements (we could have one tree view rotated within our list of tree views).

Beyond the generalized concepts of containment and transformation, WPF also adds support for animation including keyframe animation. With keyframe animation, Expression Blend lets you specify the visual characteristics of a UI at two (or more) points in time and the WPF run-time code will take care of gradually transforming the UI for the intervening points. You can, for example, place an image at one (x,y) coordinate to start and at another (x,y) coordinate 10 seconds later. The WPF run-time code will then gradually move the image from the initial to its final location over the course of 10 seconds. Key frame animation can be applied to scaling and rotation transformations as well as to other visual effects (transparency, for example).

So far, I’ve mostly read about WPF. I want to write some non-trivial software to put it through its paces. From the design perspective, I really like it. I also like the relationship between stand-alone WPF applications and Silverlight (browser-based) applications. I’ll post again on the topic when I have more to say.

I had the opportunity to spend a few hours at Oscon yesterday in Portland, Oregon. Oscon is the Open Source Conference held by O’Reilly. I was pleasantly surprised by the size of the conference, the number of exhibitors and the presence of several large companies. Open source software has definitely become mainstream and accepted by industry.

At Likewise, we consider ourselves an open source company. Likewise Open has been very successful and has opened many doors for us (no pun intended). It’s helped us tremendously, even when we end up selling our Enterprise version instead. Nevertheless, I have some observations about open source, not all of them positive.

There are several definite advantages to using open source. It enables you to build a solution without having to reengineer every component. We make use of both MIT Kerberos and OpenLDAP in our products. If we had needed to rewrite these components, it would have taken us much longer to get to market. We’ve also made use of Samba components. Samba has been around a long time, has had “a lot of eyes” on it and has figured out the subleties of talking to Microsoft systems. Again, using open source saved us a lot of time.

There are some disadvantages to open source, too. It can be difficult to get the “owners” of an open source project to do what you think is the right thing. Although open source is “open”, certain projects are led by designated groups of people. Different projects have different guidelines around software submission and how they go about accepting external contributions. Very often, your contributions have to be vetted before they’re accepted in the main code. If your code is not accepted, your only option is to distribute your own modified version of the open source project (your branch). Branching is not a good thing.

Sometimes, code changes are rejected due to style considerations or differences in design approaches. These are objections that can be dealt with relatively easily. More difficult are rejections due to “dogma”. Some open source projects, for example, are irrationally opposed to anything that they perceive as helping Microsoft. Even our intent is to make non-Windows systems work better they still oppose our goal of making these systems work better with Microsoft Active Directory. This, of course, doesn’t apply to the Samba project (who had the goal before we did) but applies to other open source projects/companies/teams with which we’ve had to deal.

There is little we can do in these cases other than to develop our own alternatives.

Another issue which we’ve encountered with some open source software is a certain lack of industrial rigor. I’ve worked a lot with both commercial software developers (I spent 11 years at Microsoft) and with academic programmers (4 years at Microsoft Research). Sometimes, open source software sometimes resembles the latter more than the former.

What do I mean by “academic” programmers? Say that you’re in school, you take a programming course and you’re asked to write a program that converts degrees from Celsius to Fahrenheit. You write something like: 

void main(int c, char **argv)
{
    int degrees = atoi(argv[1]);
    printf(”%d Celsius is %g Farhenheit\n”, degrees, (degrees * 9.0)/5.0 + 32);
}

Your professor would probably give you a passing grade for this. It works. In industry, however, your boss would likely complain about several things:

• Crappy user interface. How is the customer supposed to know that the input should appear on the command line?
• Poor error handling. What happens if you don’t supply a command-line argument? What if you specify a non numeric value?
• Bad spelling
• Lack of localization support
• Lack of comments in code

Open source software is not always industrial quality code. We have found many cases of memory corruption and leakage even in mature open source projects. We have also found and fixed many, many, bugs.

Note that the title of this post does not suggest that proprietary software is immune from similar flaws. Many proprietary software companies (including my ex-employers) are guilty of releasing software that is not ready for prime time. “Good Software” can be either open source or proprietary. Similary, “Bad Software” does not care about its licensing model.

What I will suggest, however, is that companies that have to support their products, keep customers happy and, ultimately, make money are much more motivated to develop Good Software than organizations which develop software but don’t actually have to deal with the consequences of poor code. There is no stronger motivator to write Good Software than an irate customer.

Before I started Likewise Software, I was in the venture capital business. Although my role was more on the “back end”, performing due diligence once we’d decided to invest in a company, I heard many, many pitches from aspiring entrepreneurs. For the great majority of these pitches (probably 95% of them or so), I recommended against investing in them.

It wasn’t that 95% of the proposed ideas were bad but, in most cases, either the idea or the team was weak. Venture capital folk like to say that they don’t “bet on the horse” they “bet on the jockey.” Occasionally, I’d hear weak ideas from good teams. In these cases, I’d try to guide them towards better alternatives. Most often, though, I’d hear reasonably good ideas from weak teams. It’s much harder trying to fix a weak team than a weak idea. Once in a while, a VC will try to do this. For example, they’ll propose funding on condition that a strong CEO be hired. This doesn’t always work. One of the founders might already fashion him/herself as CEO. Even worse, a founder might agree to take on a different role but then obstruct the new CEO once hired.

VCs like to bet on people because it’s been proven to be the most successful strategy. A good team can sell a weak product much better than a weak team can sell a good product. In practice, too, the good team will fixthe weak product while the weak team will find some way to ruin the good one. Think Betamax.

I’ve been a part of a couple of very strong teams during my career in the software business. From 1988 to 1994, I worked in the Developer Tools group at Microsoft. More recently, from 2004 I’ve been at Likewise (nee Centeris). In both cases we dealt with uncertainty and strong competitors and, through persistence and execution, succeeded. Weaker teams would not have fared as well.

In the early 90’s, the Microsoft “compiler group” was in trouble. Borland was kicking our collective behinds. We’d released Microsoft C version 6 to very negative reactions (we were one of the first products to eliminate print documentation in favor of electronic documents). We were mired in obligations to our operating system group and to IBM (for OS/2 support). Meanwhile, Borland had Turbo C and Turbo Pascal both of which were doing very well. Gates would frequently criticize our lack of killer product ideas. Nathan Myhrvold (effectively, the Microsoft CTO, at the time) wanted us to emphasize high-quality printed code listings. We’d gone from 60% market share to 40% (Watcom C was in there, too). Meanwhile, C7, our first C++ compiler, was mired in schedule delays and lack of focus. It was very easy to despair.

At yet, we didn’t. We gave up the IBM business (Borland took it and, I’m sure, regretted it). We basically told Gates and Myhrvold to stuff it. We released Quick C for Windows and Visual C++ 1.0 for NT — products that were received reasonably well. When we released Visual C++ 2.0 (the precursor of Visual Studio), we completely turned the tide. We got back more than our previous market share and never lost it. Within a year, Borland was firing/losing people and we were hiring/finding them.

Looking back, the interesting thing to me is that, at the time, we weren’t aware of any killer idea that we were counting on to succeed. In retrospect, it was “MFC” the Microsoft Foundation Classes and its coupling to our forms editor that turned out to be the killer idea (an idea on which .NET has built a billion dollar business). At the time, however, we were just doing our jobs and executing very well.

Back in the early 90’s, the Tools group was a very mature group for Microsoft. A lot of people wanted to work on operating systems or on cool applications. The only people who worked in the Tools group were nerdy folk who were into code optimization or writing debuggers and class libraries. Once in the Tools group, these people never left. We had old timers who’d been there for a decade. What this meant is that everyone knew their jobs extremely well.

Visual C++ 2.0 shipped on-time, with its full feature set, and with extremely good quality. To this day, I still consider it the most successful project I’ve ever worked on. In the course of 18 months, the Tools group had gone from being failures to being brilliant.

The road to success is rarely clear. To abuse the metaphor, if it’s an eight lane superhighway, it’s going to be jam-packed with competitors. More likely, the road to success is a poorly marked path through dangerous woods. Likely, you will have to bushwack. There’s no guarantee you won’t end up at a dead end or at a cliff. Your best best is to count on a good team, to be persistent and to not despair. Fate tends to favor the strong.

We are heavy users of virtualization at Likewise Software. Since we develop software for over 100 different platforms (multiple flavors of UNIX, Linux and Mac OS X), we have to be able to boot up a Red Hat 2.1 machine one minute and a Open Solaris machine the next. Developers and testers, both, need access to a wide variety of machines on a regular basis. Without virtualization, it would either be very expensive (we’d need hundreds of machines) or very slow (we’d have to re-image machines all the time) in order to do our work.

We also use virtualization outside of development/test. Over time, we’ve tended to collect an assortment of servers running project management tools, bug databases, internal wikis, HR, financial and other applications. A few months ago, our IT folk examined all the servers in our inventory and migrated many of them to virtual machines.

Unquestionably, virtualization can bring about good things — reduced administrative costs, increased flexibility, reduced energy use, etc. Virtualization doesn’t always make sense, however.

Occasionally, I have a conversation with someone who’s basically saying something like “Virtualization is terrible! I moved my database server and my risk management grid onto VMs and now they run at half the speed they used to!”. Yes, I do want to whack them upside the head when they say this.

Obviously, if you have a CPU-intensive, heavily threaded, application running on a physical server it’s going to slow down if you put it on a virtualized server along with other CPU-intensive applications. If you wouldn’t run these two apps on the same physical server, certainly, don’t run them on two VMs on a single physical server. VM hypervisors can run multiple virtualized machines effectively and with little degradation in performance, but only to the extent that the virtualized systems are amenable to this. If the VMs are running applications that are not heavily threaded and do not heavily tax their CPU and I/O systems then the VM hypervisor can exploit multiple cores and spare CPU cycles to provide acceptable performance.

There are some “textbook” examples of applications/systems that are ideal for virtualization. Web farms, for example, can deploy web sites in their own VMs and give you complete control of a virtualized server. You can muck with system configuration to your heart’s content without worrying about other web sites that might be deployed on the same physical server. Web farms can also quickly duplicate VMs allowing them to provide additional load-balanced capacity on an on-demand basis.

Beyond the textbook examples, here are some others to consider.

Infrequently run applications are great candidates for virtualization. Consider financial apps that might only be run at quarter- or year-end.  Rather than dedicating a machine to these applications that sits idle 95% of the time, these applications can be deployed on virtual systems that are suspended until needed. This approach is ideal for sensitive applications such as financial and reporting systems. It is best to not run these applications on shared hardware. If there are other applications on the same computer this increases the likelihood of intential or unintential access to secure data. With virtualization, physical systems don’t have to be “wasted” on infrequently used sensitive applications. Note, too, that by suspending sensitive VMs while they’re not in use that you’re reducing the attack surface for hackers.

Another great use of virtualization is for old, legacy, systems. If you’re running old versions of Windows NT or SUSE Linux or Solaris x86 and don’t want to update them (why fix something that’s not broken?) why not move these systems to VMs? In all likelihood, these systems are running on flaky outdated (perhaps unsupported) hardware. It’s possible that they’ll run faster on VMs than on old metal.

Demo systems are ideal candidates for virtualization. The systems receive a lot of ”wear and tear” - they’re frequently polluted with sample data and often left in weird states. Moving these to VMs allow you to use VM snapshots  to quickly restore them to a recognizable state.

Finally, one of my favorite uses for VMs is as security honeypots. Create a VM (especially a Windows VM) and give it a suggestive name, perhaps, payroll or HR. Create some directories and files in it, again, with suggestive names. Now, turn on all the auditing features available in the OS. Protect this system as you would any other secure server in your network (but don’t use the same admnistrative passwords!). If possible, isolate this VM from your other systems. Put it on its own subnet and disallow routing to other systems, for example. If you have an intrusion detection system, make sure it monitors this VM. There should be no access to this computer (other than by you, to assure its health). If your IDS or audit logs signal that someone is trying to access the system, you know you’re under attack.

Virtualization has been around for 30+ years. I used VM/370 in college in 1977. It offers many benefits that, thanks to VMWare, Xen and others, are now available to any computer user. At the end of the day, however, virtualization is simply multitasking with really, really, good application isolation. Rather than multitasking applications that call a single operating system instance, hypervisors multitask entire operating system instances. The rest of the gory details (how they virtualize hardware, where drivers live, etc.) are just that: details.

A couple of weeks ago, I wrote about usability testing. Mostly, I talked about testing methodology and the value that it brings. We’ve now finished 8 sessions and I thought it would be good to revisit the subject.

Once again, I’m amazed by how much value usability testing can provide. We’ve been testing our Likewise Open evaluation and download process with the goal of increasing the number of people who successfully install the software. This process begins with a user arriving at our web site and ends with that user performing a successful “join” operation to connect his/her non-Windows computer to Microsoft Active Directory. When we first decided to test the process, I thought we’d not learn much. What could be simpler than clicking on a download link and running an installer program? For the 1,498,753rd time in my life, I was wrong.

The first thing that we learned is that our home page is not our Home page.

Although we’ve tried several web analytics packages, we’ve lately becomed enamored with Google Analytics. The free version is relatively capable and sufficient for our current needs.  A few weeks of analysis with the tool told us that more customers are coming to our Likewise Open community page than to our corporate home page. Looking at the analytics report, it was obvious why: our partners are driving traffic to our site and their linking to the Likewise Open page instead of the corporate home page.

This makes sense. When our Linux partners want to reference Likewise, they want to get their customers as close to their final destination as possible. They don’t want to link to a high-level page with a lot of sales-oriented material. By linking to our Likewise Open community page, they are taking users to a page that’s very relevant and only a couple clicks away from a download.

When we realized that our Likewise Open page was our effective home page, we realized we needed to improve it. We knew that it would be a bad idea to make it too sales-oriented but we also knew that it had several shortcomings. This was borne out in usability testing and quickly corrected.

The second thing we learned is that clicking on a link is non-trivial.

Our download page has a big table with many different rows for different operating systems (Linux, Solaris, etc.), different CPUs (i386, SPARC, Itanium, etc.), different CPU modes (32/64 bit) and different packaging forms (RPM, DEB, etc.). The user has to find the right row and click on a download link. Simple no? No.

If you don’t set your mime-types properly on your web page links, Firefox can make a mess of things. We had many complaints of users who would get a screenful of binary stuff instead of a downloaded file.

The next thing we learned is that it’s possible to be too smart.

Linux and UNIX folk are used to painful install processes. They’ll download packages and then have to use some type of package manager (rpm, dpkg, etc.) to install it. We decided to make life easier for customers by giving them a nice, executable, installer program. In the case of Linux, Mac and other operating systems that are likely to have a GUI present, we make use of a Bitrock-based setup program. Download the software, run it. Simple no? No.

When Firefox downloads a program to Linux, it doesn’t retain its executable file mode. Before you can run it, you have to chmod +x it. If users didn’t read our 100 page Installation and Administration Guide they might not realize this. In fact, as usability testing pointed out, they might try to do other weird stuff.

Our setup programs are typically called something like LikewiseOpen-4.1.0.2921-linux-i386-rpm-installer. Long, yes, but it tells you everything you need to know: product name, version, operating system, architecture and packaging format. Note that we include “rpm” (or “deb” or other) in the name. Some Linux folk would fail to realize that the installer was an executable, would see the “rpm” in the name and think, “maybe I’ve got to install this thing with the rpm program.” Wrong.

The last thing that we learned is that nobody reads anything. No documentation, for sure. They don’t spend much time reading screen output, either.

After users install the software, they need to run our domain-join utility afterwards. We tell them this at the very end of the installer program. Alas, as usability testing showed us, many users decide to just ignore that information and hit Enter repeatedly without reading anything. Right after they dismiss the last dialog they realize that they just missed something important.

We’ve made numerous changes to the Likewise Open pages as a result of our testing. Much of it has been simple to accomplish: more prominent links; short, task-specific document; a short video; corrected mime-types. We’ll do a new round of usability testing now to verify the results of our changes. I’m confident that we’ll see improvement but I’m much less confident now that we won’t find a different set of problems to address. The main lesson of usability testing is that your software UI is never as good as you think it is.

After re-reading my last post, I realize that some of you might have no clue what I’m talking about when I mention network attached storage (NAS). To use an oxymoron, this post is a follow-up primer.

The idea with a NAS is to centralize storage across multiple machines in a network. Instead of having to maintain numerous independent disk drives on the individual machines in a network, NAS places all key files in a central location and worries only about managing the NAS.  This concept is frequently used with server computers but can also be used with workstations. Microsoft Active Directory, for example, supports the concept of a roaming profile that allows your personal files to be stored in one consistent place regardless of what computer you login to. UNIX and kin can do something similar with automounts.

There are actually two main mechanisms for implementing centralized storage.

The storage area network (SAN) approach is a different approach than that used by NAS. A SAN storage appliance provides low-level storage “blocks” to the computers connected to it. The SAN device has no concept of a “file” only of an assortment of storage blocks assigned to a particular computer. SANs are frequently accessed by a separate, high-speed, fibre channel network but can also be accessed over Ethernet using iSCSI and other other protocols.

A NAS device, on the other hand, provides file-level operations. The device implements the smb/cifs protocol and/or the NFS protocol in order to provide file-oriented services to Windows or UNIXy computers (respectively).

If you have used a traditional Netware or Windows-based file server you have used a NAS device. There are much cooler devices now, however. Isilon, for example, makes very clever clustered storage NAS devices that allow multiple NAS nodes to replicate data in a fashion that provides redundancy and high-availability at much lower cost than SANs and many other NAS devices.

The Linksys NAS 200 device that I talked about in the last post is a dirt-cheap home NAS device. It is not particularly fast nor does it offer much sophisticated functionality. Its security model, for example, is very crude. I run a Windows domain controller at home but the NAS 200 does not integrate with AD-based security. To avoid authentication hassles, I simply allow the guest (any user) to have read/write access to all the shared folders. Fine for home (where things are protected with a perimeter firewall and with secure wireless access points) but not fine for a more public network.

I installed the Linksys appliance in order to provide a backup destination for the 6 computers that we have strewn throughout the house. Using the appliance means that I don’t have to dedicate a general-purpose computer to this task. Additionally, Linksys has figured out how to set up Raid and how to automatically perform various recovery operations all using a simple Web interface. It would have been much more complicated for me to figure this out myself.

The one last piece of the backup puzzle that I’d like to implement would be to add some form of offsite storage. Ideally, the NAS 200 would, itself, backup files to some Web-based storage provider. Since it doesn’t, I might have to implement this myself with some type of periodic job that detects new files on the NAS and copies them to a service during off hours.