MODE 1 - uses a single GW mailbox account that uses a Shared Personal Address Book that is Shared to ALL existing GW user's to represent all the Exchange users to the GW users. Each GW user has to accept this Shared Address Book and ALSO add this Shared Address book to their Name Completion Search Order. Its a big burden to put on your GW end users just to get this solution in place. Then when the Shared Address Book ACL is modified (new or removed GW users), all current GW users with the Shared Address Book has to be updated. This could be thousands of transactions which puts a big load on the GW system each time. Its a mess.
MODE 2 - This mode does not use a Shared Address Book approach, but adds the Exchange users to the GW System Address book (GAL) via an External Domain with an External PO. Much nicer approach where the GW end users just see the Exchange users show up in the GW System Address Book. This mode uses a GW v4 API gateway under a v7 GW Domain on a NetWare 6.5.8 server with a "proxy" v4.X GWIA which also needs a "real" GWIA v7.0.1. The Quest CMG application then copies from the "proxy" v4.X GWIA 1 thru 7 queues to the "real" v7.0.1 GWIA's 1 thru 7 queues. The 0 queue of the "proxy" GWIA is a Free/Busy request which is then copied to the GW v4.X API gateway to crack open the encrypted file so the Quest CMG can figure out what Free/Busy Search is originating from a GW user to an Exchange user. You also have to do some Link Configuration for the External Domain that holds the Exchange users to make sure its routed to the "proxy" GWIA. Also, you need to use the GW Gateway Alias utility at www.novell.com/.../13520.html to define a Gateway Alias behind each Exchange user that is represented in the External PO in GW.
BUT for the BEST co-existence, Novell's new GW 2012 SP2 solution blows away the Quest CMG solution by a long shot