You only require DTC if you will be using distributed transactions.

MSDTC is separate because no matter how many instances of SQL you install on the cluster node the one MSDTC...

If (and only IF) you are not concerned with dirty reads in your reports you could use nolock (equivalent to the read uncommitted isolation level).

SQL 2005 also introduced optimistic isolation...

not quite sure what you mean by options available to you in this set up.

As you are replicating the user databases only you would treat this like logshipping or database...

Yes. for SQL authenticated IDs it changes the password to a random value for security reasons, which makes it pointless in my view. Its good for windows authenticated IDS though.

google sp_help_revlogin, that does what you want by script.

there is a transfer logins task in SSIS, but only use that if all your ids are windows authenticated.

note: edit the resultant script to remove the logins that already exist (builtiun\admins, the SQL2005 local accounts)

you cannot add it to the backup file.

use your plan B and output the results to a file then run that into SSMS on the DR server.

SELECT d.name, d.database_id, m.mirroring_role_desc,

m.mirroring_state_desc, m.mirroring_safety_level_desc,

m.mirroring_partner_name, m.mirroring_partner_instance,

m.mirroring_witness_name, m.mirroring_witness_state_desc

FROM ...

google sp_help_revlogin, you need to bring across the login which is held in the master database, not the application database.

this is a different problem. repost this to the corruption forum you will get a better response. If you don't have a backup your options will be limited.

find out...

If you can make sure the directory structures in dev and prod are identical and you don't change the logical file names you can restore with only the replace clause.

You say you want to keep A as intact as possible. Any tables you replicate with transactional replication will need a primary key.

How up to date does B need to be? also sounds like you need to make some changes on B?

If latency is not an issue you could use full backup...

If you have existing jobs and packages in the destination database they would be overwritten, so if you want to keep them restore is out.

so for jobs keep to what...

What is the purpose of the copy. for DR?

As this is SQL 2000 you can get away with backing up the source msdb database, restoring it over the target msdb...