Roll out Samba carefully and proficiently. It is a back-end service and, if implemented properly, the desktop user will never be aware of the change. This is a good thing, because users are very sensitive to change.
FEEDBACK: Is your enterprise moving to Samba 3? If so, in what way?
Send your feedback to the
All of the major features are working fine, and we are not seeing a lot of questions about those. Most questions relate to new features. Of course, people are asking, 'How do I get my LDAP back end to work?' We're addressing several other new-feature issues: some macro-expansion problems, concerns with Samba 3's new multibyte character handling, and some secure channel and digital signature glitches. Over the past few months, we have also been catching up on the bug report backlog also.
If they deploy LDAP as the back end, as the directories before their identity management, they have to do their homework on LDAP. But it is not always necessary to be an LDAP expert, as a fairly large number of Samba deployments could be far more readily and less painfully done using the new TDB back end. That is a very low overhead way to deploy Samba. Of course, there is a propensity for companies to want to deploy Samba with whistles and bells. Either way, you can't escape from the need to do your homework to do it properly. Of course, the Samba Team is thinking of further enhancements. Can you give us a sneak peek?
We are working towards defining what the features of Samba 3.1 will be.
One of the first things that we need to focus on is the new group management infrastructure, which was new to Samba 3. We have listened to the feedback from our users, many of whom want to use this in ways that we didn't anticipate. We believe that we can improve usability of the group handling in the next release. Can you explain how those trends are playing out?
The migrations to Linux very frequently deploy Open LDAP to use an LDAP back end. Those users have been very vocal on the Samba mailing list, seeking to get over their learning curve issues with LDAP.
We are also seeing a very significant migration to Samba 3 on some Solaris platforms. On the mailing list, we've seen that people who try to build Samba on Solaris also have a learning curve on building the Samba binary so that they have LDAP and Kerberos support. I am guessing that two-thirds of the Solaris projects are integrating into Active Directory frameworks. In other words, Samba complements what is already on site by providing interoperability and is not replacing Microsoft products.
About one-third of the Samba migrations are migrating off NT4 to a sole Samba solution. There's a big learning curve here, as people are migrating from NT4 domains to LDAP need to understand its role in the back end.
Overall, Samba 3 has exceeded the Samba Team's expectations, in terms of stability and delivering on all of the features. It's the implementation of Samba that delivers the ability to migrate off Windows NT4 to a Samba domain controller. More importantly for many larger customers, it is the release of Samba that allows them to integrate a non-Windows back end into an Active Directory framework. What trends are you seeing in Samba 3 migrations?
We are seeing a significant uptake of Samba 3. There are three different trends: implementation of Samba 3 on Linux to integrate into Active Directory; implementations on Solaris mostly integrating with Active Directory; and migrations off NT4 to a sole Samba Domain Control solution.