Ok, first off, I've run an actual Samba server in a production environment for over a year. I can tell you there will be ups and downs to this process and that it is not as straightforward as it would be under Windows Server. The second thing I can tell you is that, as long as you bring Windows baggage with you (expectations on behavior) it will never work as well as you would like.
My setup was a bit different - RHEL 5.1 - but the principle is the same.
First, you'll find that you will really, really need to understand how Samba handles file permissions in a manner that is consistent with your perception of "File Properties -> Security Tab" because it's just not the same. It's really close, but no cigar. Because you are translating between two semantically different filesystems, you will find such oddities as "the Everyone group can't be deleted" and "root owns all my files", that is if you use root as the primary listing in "Take Possession". This is because there is always a world permission (the Other group) and always a user permission (which roughly corresponds to "Owner"), and in Unix-land these can never go away, and if they can't go away, you can't really delete them now, can you? My department teammates couldn't come to grips with this - they just couldn't abandon the Windows baggage that they were used to. So it was always lots and lots of grief about "why can't I delete these" (because of the reason I just gave) and "But if everyone is listed then there's a security hole" (it isn't, the semantics are different), and so forth, and each time, I would have to re-explain this over and over again. File permissions are tricky when you're translating them. Be sure to settle on a schema that makes sense for your deployment.
Second, Winbind is your weakest link. Seriously. RHEL 5.1 comes bundled with 3.0.25 (3.0.28 if you update) and the out-of-box version will collapse due to a bug. When Winbind goes, the file services go with it, because there isn't anything to authenticate against. Something as simple as pressing and holding the refresh key in an Explorer window (press F5) would result in a collapse of the connection, and if done under enough load, collapse of Winbind itself. Updating to 3.0.28 resolved this issue but it does indicate that there are some sore spots in older versions of the software. Short version: stay up to date with the version you are using. Try to get the newest if possible, as several bugs may be fixed. Distro packagers are notorious for being way behind the bugfix curve when it comes to Samba.
Third, the Samba team is hard at work on adding support that will allow existing Windows administration tools to interface directly with the service. You can, for instance, set up scripts that will start and stop local *nix services using the interface for Windows services, just don't use the same service to stop Samba (because you'll cut your connection). Very handy for doing other services on the server. You can also attach via Computer Management and see open sessions, files open, etc. However, not all of the RPC protocol is implemented and some attempts will result in (non-fatal) errors. So be sure you factor this into your systems management perspective and take advantage of it when possible. If you can harness an existing Windows administrative tool to interface with Samba, and you have other staffers in a "Windows" world that need help with the transition, you can soften the blow by re-using those tools, until they are comfortable with a command line.
Forth, I would look hard at the version of Samba you're deploying. Ubuntu is good for a desktop, so-so for a server. It's an ancient African word that means "I can't install Debian". You're really deploying someone else's remix of Debian, and frankly, if you want stable, why not go with the original?
Debian may have software that seems "stale" but in reality, the security team is prompt about backporting security fixes, and the policy of "we don't rev releases because a behavior could change, leading to breakage" sometimes makes better sense, especially if you're going for a long-term setup with stability. If you lean in the other direction and want new features to constantly show up, then a commercial distro like Red Hat or SuSE might be more to your liking. Each update of the software will rev the package higher, fixing bugs, and sometimes bringing unintended consequences with new features. You picks your distro, you picks your poison.
Hopefully this will provide some additional perspective about what lies ahead of you. I can tell you that when set up properly, it will not only run smoothly, but very quickly. Try running some file-based databases (Access, FoxPro, etc.) on a Samba share sometime, and notice how it just screams, especially if you can get two NICs going. Dual NICs can easily be accommodated without "bonding" or other silliness, the clients don't seem to care and the only thing you need to worry about is making sure your switch supports it (which a good quality switch from the last 5 years will anyways). Just put different addresses on each NIC, but when you specify an address to use in Samba, pick only one. Linux (and the switch) will do the rest.
