On Fri, 2009-04-03 at 13:28 +0200, Julien Kerihuel wrote: > Mapiproxy uses a unique binding string for all exchange services and for > all auth mechanisms it supplies (specified/delegated/machine account) - > or should supply properly. That is obviously technically wrong when we > deal with clustered Exchange environments. > > Let's take a real clustered Exchange use case: > - Server A: main Exchange server > - Server B: second Exchange server where a mailbox has been > moved > - Server C: third Exchange server with a replication of NSPI > server > - mapiproxy points on server A
Following discussion with Sam on IRC + some thoughts: - I have a working RFR/NSPI hack that makes mapiproxy work when NSPI server is different from the one defined in the binding string. Next step is to rewrite the patch so it is generic. Presumably using either a local database or on-memory. - Regarding the Logon redirect response buffer, I'll implement a small module in mapiproxy which send a fake redirect response to Outlook. If Outlook tries to contact the other server, then I'll know this custom response is correct. This first step requires some modifications in the IDL and in ndr_mapi.c but I think I've figured out how to implement this. Next step is to setup another mapiproxy instance which will be chained to the mapiproxy with the redirect response buffer module and ensures it handles the response properly. Final step, return the Logon reply to Outlook. Maybe Outlook blindly uses the server address filled in the redirect buffer response. In such case, we could just set mapiproxy address there. Otherwise we'll need to implement some mechanism which closes the existing connection, binds on the real server holding the mailbox and only returns data to Outlook once it has the real logon reply. --- Julien Kerihuel j.kerih...@openchange.org OpenChange Project Manager GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list devel@lists.openchange.org http://mailman.openchange.org/listinfo/devel
