Don't forget that the biggest cost in a client is not necessarily the purchasing of the hardware (which is obviously the most visibile cost). Various studies (Gartner, IDC, ...) indicate that a PC that is purchased for $500 (one-time cost) in fact costs somewhere between $1500 and $4500 per year (!) to manage. These hidden costs are mainly into the backend infrastructure supporting these PC's in corporate environments, people managing them, deploying software on them, ... Google for desktop TCO and you'll find plenty of information. Sure, you might disagree with the exact numbers provided by a Gartner /IDC /Forrester but at least it gives an indication.

For thin clients (and desktop virtualization for that matter), this is also where the cost savings are. No serious VDI vendor will tell you that the CapEx (investment in hardware, licenses,...) is cheaper with thin clients and virtual desktops: you need to buy additional licenses, you're going to run desktops on server hardware (ok, 100 at a time on the same box) and then I still didn't start about the licensing galore (Microsoft VECD, Citrix XenDesktop or VMware View or...). The real cost savings are in the fact that it's much easier to manage, and being able to let your very expensive system administators do something else than troubleshooting a desktop (which costs you twice for the end-user downtime and the sysadmin troubleshooting it).

The same goes for thin clients: the up-front investment is larger, but they are very easy to manage (plug into the network and the thing autoconfigures itself, pointing you to your virtual desktop -- which means fewer expensive sysadmin interventions on-site for replacing hardware!), they live longer compared to traditional desktops (these used to have three-year lifecycles whereas thin clients typically have a five-year lifecycle -- roughly speaking you'll need to buy two traditional desktops for one thin client in a 5-year desktop lifespan; I'll concur to the fact that with the economic situation, you'll see prolongued lifetimes for both thin clients & desktops but the idea remains the same, numbers might differ today).

So is the thin client cheaper? In most situations and looking at the total picture, sure it is. Even despite a higher up-front investment. The real problem is not really the price of a thin client but whether your applications and IT environment support thin clients/server based computing (TS/Citrix/VDI).

Sidenote: I work for a consulting firm where I work a lot with VDI & Server Based Computing in general; we strive to be independent as possible (trying to nuance the vendor claims as much as possible for our clients) but that might mean I am a bit biased towards using SBC if it works ;)

Notice that you are not forced to use the XP Mode, in fact, the early reports mention that you have to explicitly install it as an add-on. This means that companies have the CHOICE to either go for a full Windows 7 compatibility track (yes, they should) OR they can choose to support two operating systems until a legacy application fades out.

This is just Microsoft trying to convince IT admins not to have application compatibility as an argument against Win7 migrations, and not requiring to implement dreaded MED-V like, Terminal Services, Remote Desktop XP, VDI solutions just to keep that darn ol' app running. That also requires maintenance of multiple operating systems, and in fact, just as many as there are instances of non-compatible apps.

Yes, and then most of us grow up, leave high school and/or university and see that there is a real world out there ;).

Samba 4 is not really production ready yet. That is why it is labeled as an alpha version.

I acknowledge your point on Samba 4 not being production ready. I was merely using the example as an indication of "core functionality" that appeared to be missing.

I have seen countless problems restoring AD after a DC failure. I created a mock scenario with a Samba 4 DC wherein the entire database was wiped. I simply used Samba's own LDB toolset and had it up and running again in seconds.

Glad to see that they are providing a toolset to do this. I do wonder how FSMO role recovery, global catalog recovery and GPO recovery will be done. I hope with the same easy and especially in a fully Microsoft supported manner.

However... the most tricky part of an AD disaster recovery (as you know as you speak with experience), is not getting the database back running, but verifying its integrity. Again, I wonder if tools similar to NTDSUTIL will be ported to a Samba equivalent.

You're missing the point. It isn't about cost at all. The point of having an open source replacement for AD is to make it easier for software developers to take advantage of the largely undocumented protocols. This is designed to facilitate interoperability. Even Microsoft, from the light of the anti-trust lawsuit it lost, extended an olive branch to the Samba team to assist in providing documentation. Plus, the work that Samba does stands to benefit Microsoft as well because they might be able to see where the Samba team has had some really good ideas and legally incorporate them into mainstream AD.

+1 Karma score for being the first to provide a good answer to the reason of Samba 4's existence ;). Yet, I do wonder where there was a lack in documentation? Direct interfacing with AD is done through LDAP... which is documented as a standard, or through ADSI, which is IMHO (from a limited developer experience in the past) is also decently documented on MSDN/Technet. Microsoft documents their own extensions to LDAP in a whitepaper. On top of that, messing around with replication, sites, FSMO master roles or other low-level Directory Services parameters in the Configuration naming context of a forest is something I wouldn't recommend anyway.

I do agree that it can be a good trigger for Microsoft to be forced to document some parts of AD that are scarcely documented (garbage collection, tombstone processing, ...). And, before you express such confidence, I would try using Samba 4 myself. Some parts of the code are very mature and work well.
I have used Samba 3 in the past and was very pleased with its stability. It is a very decent product and I believe that Samba 3 has an added value to provide (a limited form of) Windows Domain services.

For me, the step up to an Active Directory environment is merely an academic exercise in order to study the Microsoft closed source internals in more detail. Interesting, yet of little practical value in a commercial or educational environment (given the low costs... which brings us back to that).

I was not talking about the stability of Samba. I have used version 3 for quite some time and I was very happy with its stability. I am simply questioning the motives of attempting to duplicate a product where the original is cheaper to implement, directly has the original manufacturer's support and has 9 years of development maturity backing it.

BTW: Then who are the Samba team targetting as a user? I cannot imagine many home users would require an Active Directory environment, so naturally they would be targetting at small businesses, where Microsoft also has a competitive offer with SBS & EBS.

Ever had a look at this?

http://www.quest.com/Authentication-Services/

A very nice product that offers integration of Unix/Linux machines into AD!

Yes, so I read that they tried blank machine account passwords where Microsoft (indeed) uses a random password only known to the computer (and the hash in AD)...

For more information (just some google hits):

http://blogs.technet.com/asiasupp/archive/2007/01/18/typical-symptoms-when-secure-channel-is-broken.aspx
http://technet.microsoft.com/en-us/library/cc785826.aspx

I worked as an architect for Microsoft products, I can assure you that I did price & worked on implementing AD, Exchange, OCS, SCCM, SCOM, ... implementations on customers ranging from 15 to 225.000 clients. The acquisition costs are usually neglegible (capex), the operational costs are what drive decision makers towards a solution (unless you are talking Oracle databases that charge insanely high rates for licensing, but let's not go into that).

Besides, when you have an agreement with Microsoft, they practically give you away the OS licenses & CAL's for free (academic agreements & volume agreements - depending on the skills of the negotiators at your purchasing department). And even if you don't, the list price for W2K8 Standard Edition is 600 euros (that would be about $750). Heck, that's what any consultant charges for a single day of work & what it will cost you just to have a single meeting on the Samba 4 subject with any knowledgeable person. So no, the license cost is not an issue in any environment that has more than 50 PC's.

It is not very comforting to read the following statement:

"My Russian connection has had Samba 4 running in production since last June and has discovered a few missing features. They also discovered that machines would stop working after 28 days which was something to do with password expiry."

"Something to do with...". This is in every AD 101 book (machine accounts, password renewal, ... thing). I would at least expect that the Samba developers have experience in installing, running and maintaining a "realistic" Active Directory environment (read: more than 1000 client machines) before delving into the real messy details. I am not sure I even want to know how they are going to handle disaster recovery (one of the fun parts of AD, rest assured).

Honestly, I cannot imagine why anyone would want to run a FOSS equivalent Active Directory. After having spent months in setting up a full mixed Windows/Linux environment (OpenLDAP, Kerberos, Samba, the works), I can say that setting up AD is a breeze: for me, it is a prime example where Microsoft took existing technologies (LDAP, DNS, Kerberos) and actually turned it into something useful without the typically associated configuration nightmares. And it works very stable indeed.

And please, cost is not a reason for not going with Active Directory. The cost of a single Windows Server license is absolutely peanuts compared to what *you* cost your employer. The operational costs are what matter in long term and I am pretty confident that Microsoft's AD will do much better than that for the years to come.

Let me jump in and add something to that: three years ago, I went through the entire process of setting up a 80 desktop environment using Linux. I set up an LDAP server, Samba, home folders on a centralized share, print servers using CUPS, mail server using Dovecot/EXIM, a centralized configuration system and a minimal level of failover redunancy... in short: the works. The system worked nice and stable, but it took me 2 months to get everything up and running (granted, at the time, I was new to LDAP and it took some time to set up the master/slave replication, integrate PAM & Samba into it and write my own scripts to keep Linux and Windows passwords synchronized). A year later, I configured a similar set-up using Windows Active Directory (which in the end is just a pimped LDAP server). This takes a day to setup a similar environment. Of course, you do not have the same granularity of configuration options, but it works quite nicely out of the box. This led me to the impression that even though Linux is very nice, stable, configurable and using all the OSS servers, it was in fact Microsoft who took these open technologies and turned them into an all-integrated environment. Note: I am aware of the similar attempts like SuSe Enterprise and several Ubuntu-based distributions that provide similar out of the box functionality. However, that was 2006/2007, Microsoft did that trick in 2000 and is currently 8 year ahead in development.