Install RODC(Read Only Domain Controller) on Server 2008

Read-Only Domain Controller (RODC) is almost same like installing a regular domain controller.
However, there is one important factor to keep in mind. A RODC can only be installed into an existing Active Directory Domain with at least one full (non-read-only) Windows 2008 Server Domain Controller.
RODC is a new feature to Windows 2008 and it needs at least one DC to function properly.

you can install RODC on Core Server installation and Full server installation.

There is only one way to install RODC role on a Core Server installation. The dcpromo.exe command runs on the GUI-less version of Windows Server 2008.
Using an answer file for the command makes the process much easier than trying to get all the switches just right in the command line.

Although there are many settings available depending upon your particular infrastructure, just basic information is required to complete the command:

• an account with permissions to do what you are trying to do
• the name of the Site
• the database and log paths
• and whether or not to install DNS.

and on Full Server you have to run "dcpromo" like normal domain controller, and select "Read Only Domain Controller RODC"
Under “Additional Options” .

Another thing you have to careful about that you must have to create a normal user account or group whose member can manage the RODC, and you have to mention that account during installation of "RODC" other wise if you enter administrator account as management account for RODC. the administrator account also have read permission on RODC.

after installation test the installation by logging as domain normal user account, you will miss the option creating "NEW" user account, group or folder.
while if you log in as domain administrator all option are available and RODC behave like normal DC. 

2 Node Multi Site Cluster in Windows 2008R2

2 Node Multi Site Cluster in Windows 2008R2

Multi site cluster involves failover feature between sites.There are generally two things that will have to be travel between nodes: data traffic and cluster heartbeats. One thing more you have to be consider client connectivity and cluster management activity.Your replication traffic will most likely require the great
amount of bandwidth; you will need to work with your replication vendor to determine how much bandwidth is required. The last thing you need to consider is Quorum model.For a 2-node multi-site cluster configuration, the Microsoft recommended configuration is a Node and File
Share Majority quorum.

The most common cause of confusion with the Node and File Share Majority quorum is the placement of the
File Share Witness. Where should I put the server that is hosting the file share? Let’s look at the options.

Option 1 – place the file share in the primary site.

This is certainly a valid option for disaster recovery, but not so much for high availability. If the entire site fails
(including the Primary node and the file share witness) the Secondary node in the secondary site will not come into service automatically, you will need to force the quorum online manually. This is because it will be the only remaining vote in the cluster. One out of three does not make a majority! Now if you can live with a manual step being involved for recovery in the event of a disaster, then this configuration may be OK for you.

Option 2 – place the file share in the secondary site.
 

This is not such a good idea. Although it solves the problem of automatic recovery in the event of a complete
site loss, it exposes you to the risk of a false failover. Consider this…what happens if your secondary site goes down? In this case, your primary server (Node1) will go also go offline as it is now only a single node in the primary site and will no longer have a node majority. I can see no good reason to implement this configuration as there is too much risk involved.

Option 3 – place the file share witness in a 3rd geographic location

This is the preferred configuration as it allows for automatic failover in the event of a complete site loss and
eliminates any the possibility of a failure of the secondary site causing the primary node to go offline. By
having a 3rd  site host the file share witness you have eliminated any one site as a single point of failure, so now the cluster will act as you expect and automatic failover in the event of a site loss is possible. Identifying a 3rd geographic location can be challenging for some companies, but with the advent of cloud based utility
computing like Amazon EC2 and GoGrid, it is well within the reach of all companies to put a file share witness in the clouds and have the resiliency required for effective multi-site clusters. In fact, you may consider the cloud itself as your secondary data center and just failover to the cloud in the event of a disaster. I think the possibilities of cloud based computing and disaster recovery configurations are extremely enticing and in fact I plan on doing a whole blog post on a just that in the near future.