Re: Visage.drs

On Jul 5, 5:22 am, "Jeff Caspari" <mu...@xxxxxxx> wrote:

Have you looked at http://www.stamina.com.au/Visage/visageDRS.htm ?

Assuming a simple replication scenario with a single windows
replication server located at the primary location, you simply
nominate the accounts that you want to protect on the primary server.
Visage.DRS works at the ACCOUNT level, and will replicate/protect all
files physically "resident" in the account, even though individual
files may be updated from other accounts. If entire files are created
or deleted, this will be reflected on the replicated environments.

At some stage after you have "protected" an account, you would do an
account save & restore this onto the replicated D3 server (doesn't
matter if system is being used whilst the backup is being done)

Finally you would configure the windows replication server to pickup
"delta transactions" (changes) from the primary server, and transfer
these to the replicated environment. This should be DIFFERENT windows
machine to the one that is being used to run D3/NT to minimize impact
on the live/primary system. A windows XP box is AOK, as DRS just runs
as a background service - the machine just needs to be left ON

The replication server also needs to have a connection capability
between the 2 systems - I would assume it would be local to the
primary, and have a VPN connection to the remote location (could have
a second windows replication server - depends on topology you
want .... likewise you might want to have a local & remote replicated
D3 server

That is pretty well it --> replicated servers can be used for things
like reporting (offload processing to reduce live impact), extending
backup windows window (if you still want/need to do a traditional
backup you can stop delta transaction log processing, perform a
"clean" backup, then restart delta processing).

Replication servers will self-heal if there is an interconnect outage,
they maintain secondary logs of delta transactions in/out for playback/
isolation if necesary.

In the event of primary failure, wait for delta transaction log to be
cleared/fully processed, reconfigure IP's as necessary & you are
"away"

Replicated D3 servers need to have 1 "real" D3 licence for every
account being replicated - and should have the base OS environment
established already (eg: printers with same name, same directory
structure if you use OS level files for anything, windows/*nix based
services pre-configured/duplicated

HTH

HTH
.

Relevant Pages

  • Re: Defining logon domain controller during unatteded setup
    ... Testing a Domain User Account ... Windows XP - Shell/User ... But infrequently, a domain controller from a remote location ... All domain controllers within the LAN have a normal replication. ...
    (microsoft.public.windowsxp.setup_deployment)
  • Re: ADAM service account problem
    ... > testing of ADAM replication, and here's how we have it set up. ... Add the account to Configuration ... > it's not in the local Administrators group for example). ... > replication server username as ...
    (microsoft.public.windows.server.active_directory)
  • RE: 2 DC
    ... >> Replication occurs every 15 minutes. ... When an account is ... >> Windows Server MVP ...
    (microsoft.public.win2000.active_directory)
  • Startup Service Account
    ... I've been deploying/working with replication on a Windows Workgroup. ... created an account with administrative rights. ...
    (microsoft.public.sqlserver.replication)
  • RE: DCpromo issue. Health check on AD and group policy.
    ... Enterprise Admins group, or at the least a domain admin account of the domain ... Try running MS Sonar to check you SYSVOL replication status: ... Use sonar to check if the sysvols (File Replication Service) is replicating. ...
    (microsoft.public.windows.server.active_directory)