> You  are  correct,  Double  Take does not replicate the registry. It
> will only replicate the file structure as you direct.

Actually,  Double-Take  can  quite happily replicate the HKLM\Software
part  of  the  Registry,  which  is where IMail's more user-accessible
dynamic data is stored, such as users and domains (there is some other
service-specific  data  under each service's entry in HKLM\System, but
this  should  change very, very rarely and would always be under local
Administrator control).

NSI  does not officially support this configuration, since it requires
stricter  control  of  application-level  changes to both sides -- you
must essentially relinquish control of all Registry-based app settings
on the target server, as they will be overwritten and identical to the
source,  so all app installation paths, etc. must be the same (though,
IMO,  this  is the best way to manage replicated pairs, anyway). DT is
principally  designed  for  data-level  replication,  to  some  degree
independent  of  apps,  so they don't want to open this can of support
worms.  Note  that  even  I,  with  a fondness for tweaking, would not
attempt  replication  of the \System hive, as it will definitely *not*
work.

Even  aside  from block-level replication of the \Software hive, there
are  other  ways  to use Double-Take to mirror IMail servers. You can,
for  example, make a periodic live export of the IMail registry subkey
to  a  file, and make that file part of your replication set. Then, in
the  target  server's  failover  script,  make  one  of  the steps the
importing  of  that .REG file. Done. Even IMail installs with 1000s of
domains take negligible time to merge.

We've  of  late  become quite expert in using Double-Take to replicate
mail  environments,  in  fact  having  contributed  to their developer
knowledge base regarding Exchange clustering over a WAN (we use client
failover  techniques that they were not aware were possible). Once you
have  a  handle  on how basic DT replication works, there are lots and
lots  of  fun  things you can do in your failover scripts to make your
cluster "application-aware." There's one area in which I do agree with
NSI's  "no-touch"  policy:  Active  Directory,  which  should  use its
built-in replication. Almost anything else can be made to work.

--Sandy


P.S.  Also  note  that Microsoft native clusters _do_ support registry
replication, if you wanted to go that route.

P.P.S.  If  you have adequate control over the creation of new domains
to  make  it  possible to replicate domain info manually, but you just
don't have control of user adds/changes/deletes, you could use IMail's
ODBC option and replicate whatever ODBC database using Double-Take.


------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]

SpamAssassin plugs into Declude!
  http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/

Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases!
  
http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/
  
http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/


To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/

Reply via email to