Ok, it's getting much clearer now.

So, I assume if it's all done like that and business tier is deployed on a server, clients can connect to it as to remote .Net objects which are still running as Serviced Components on a server and take advantage of COM+ declarative Transactions? Then i only need to make sure the ORM layer doesn't interfere with that and all Business Objects are derived from EnterpriseServices.ServiedComponent. (Doesn't look like they changed this requirement, but that's not a big deal i think).
Then for the Security to work I only need to somehow pass the Identity of the client's process to this layer, right? I mean I don't think that
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
will work in case of remote clients each connecting to the same AppDomain, I would assume, but all having different Identities... Or how does it work?

And since it's COM+ serviced I don't have to worry about scalability issues, right? At least in theory? Just make sure I correctly specify which objects are stateless (or what's the word in .Net? "Well known"?) - server decides when to create and delete the instance and it doesn't matter which instance serves which client; and objects that are not stateless - client decides when to instantiate it and when to delete.

And then if it all runs on Windows 2003 Advanced Server(s), I even get failover, right?