Seems straight forward; you have some DAG nodes in one site and you bring up another site for some purpose...maybe DR. Most likely you will have a seperate subnet. Exchange does a great job of masking all of the crap you would have to go through when adding those nodes if you were using traditional Windows Failover Clustering. Since that is the case...let's focus on the few commands, and the order (or most ideal order) for running them.
Let's assume that your DAG is named...DAG, and that you have two networks (a mapi network and a replication network) named DAGNet1 and DAGNet2. If you looked in Cluster Manager you'd probably see that the networks were defined and that they had the proper subnets, but we are adding a subnet since we're across some type of network boundary. So to prep the networks for this new network we need to run:
Set-DatabaseAvailabilityGroupNetwork -Identity "DAG\DAGNet1" -Subnets "192.168.1.0/24","172.16.1.0/24"
In this example one of these subnets already existed and I'm adding a secondary. Trick is, you need to define both of them again otherwise you'll be replacing the subnet.
Repeat the same command for DAG\DAGNet2 as to include the new replication network.
Next you need to add your new mailbox server, a.k.a. DAG member. That's easy:
add-databaseavailabilitygroupserver DAG -MailboxServer dag-mbx-02
Here we added the server dag-mbx-02. This command will go and install the cluster role to the server, remotely and get it added to the cluster.
Lastly, the DAG will need an IP to use if it ever fails over to the other site, or if active manager chooses to go for a ride across the WAN. This can be static or DHCP. For this example, it's static:
Set-DatabaseAvailabilityGroup DAG -DatabaseAvailabilityGroupIpAddresses 192.168.1.10,172.16.1.10
That's pretty much it for adding the nodes. Next comes seeding. Oh, that's a fun one and I have a great, real world example, of how to make it hard on yourself.
-enjoy
