This is what I did when trying to setup my first domain controller on Windows Azure:

• I created one VM from gallery. It worked fine.
• I logged into VM and found the IP address is assigned by DHCP. It is not good, right? I manually changed the IP address to static. With a few minutes freezing, the connection came back.
• I promoted the VM to domain controller. It worked perfectly.
• VM is restarted to complete the configuration. Oops, I am not able to connect to the VM!!
• Force shut it down from the portal and restart. It comes back, but the IP address changes to DHCP, again!

Besides of this problem, I noticed another one is that when I create multiple VMs, their assigned IP addresses are distributed in different subnets randomly, and they are not able to talk with each other! This is not what I want. I just need a quick, simple test environment. I must have missed something, so always study first, then go.

After researching, I indeed missed the key information: Windows Azure virtual machine does NOT support static IP address!

Here is the article you must read if you want to setup your Active Directory on Windows Azure, either for isolated testing environment, or inter-connected with your on-premise infrastructure.

Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines

https://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx

To be simple, the correct steps are:

1. Create one Virtual Network. Assign the "internal" IP scope for your virtual machines.

2. Create your virtual machine and deploy it into your "virtual network". Then it will receive one IP address falling into the scope you assigned.

3. Go ahead to promote your VM to domain controller, with the dynamic IP address "because the dynamic IP addresses of Windows Azure virtual machines that are attached to a Windows Azure Virtual Network persist for the lifetime of the virtual machine, the Windows Server Active Directory requirements for IP addressing are met (as are those for DNS if co-located with the DC)" and "when you use a dynamic address on Windows Azure, you are in effect using a static IP address because it is routable for the period of the lease, and the period of the lease is equal to the lifetime of the cloud service. The IP address will persist even through the Windows Azure service healing process".

4. Create more member servers and deploy to the same virtual network. Change the NIC configuration to set DNS server to your domain controller.

5. Now you can go ahead to join the member server to domain. All rest things are same as tradition operations.

One of the best things to build your test environment on Windows Azure is that it is automatically enabling you with Internet name resolution, and it is very important to build some real internet facing capabilities, like Email service. I will talk about tips about how to enable your test email service the ability to IN/OUT on Internet.

Enjoy it.

This is the quick check-list I personally consolidated in past projects, just try it.

**Only proved on migration from Exchange Server 2003 to 2010**

The traditional and standard HA structure for Exchange Server 2010 requires minimum of four exchange servers, as the DAG and NLB cannot run together.

While for most small to medium customers or medium site deployment, such as less than 1000 deployment and no robust virtualization platform, the investment of four HW/SW suites is not practical but they do want the high availability to support business continuity.

Then my goal is: To provide the basic high availability features for Exchange Server 2010 with the minimum of only two physical Exchange servers.

Target Scenario:

In Small to Medium size of exchange deployment, in which one Client Access Server is enough for handling client access.

Solution:

* Through Exchange Server 2010 DAG to provide high availability features for mailbox databases.

* Through "Microsoft Fail-over Cluster" to provide high availability feature for Client Access Server role. Give up the load-balancing feature provided by NLB as we confirm one server is power enough to handle client accesses.

* Hub Transport Server role provides built-in high availability feature.

Benefits:

Less hardware & software cost with almost full HA features.

Steps to make it:

Test Environment:

1. Complete Exchange 2010 DAG deployment following usual steps.

2. Open Windows Failover Cluster Manager, you can see the "PrimaryDAG" object with a blank "Services and Applications" list.

3. Now let's start creating the cluster resource for Client Access Server Array, by right clicking the "Services and applications" and choose "Configure a Service or Application".

4. Follow the prompted screen to go forward.

5. In the "Select Service or Application" section, locate the "Other Server" type and click Next.

6. Give the new cluster resource name of "CASArray" and assign it a valid IP address, and here is "192.168.0.110". Go Next.

7. Wait for the validation to complete.

8. Leave the shared storage part as it, as we do not have shared storage configured here.

9. Click Next in the confirmation page.

10. Wait for the configuration to complete.

11. Until you see below success page, click "View Report" to confirm all steps are completed successfully.

12. Go back to the "Failover Cluster Manager", and you now can see a new cluster resource appear with the name of "CASArray". The cluster resource is running in the active node and you can configure the properties as you like as the usual cluster resources.

13. Go to the DNS panel and you now see an entry for the "CASArray" appears automatically.

14. The above steps only complete the cluster resource object for "CASArray". Now we are going to actually enable this array object for Exchange Client Access Servers.

15. Open Exchange Management Shell, check and confirm there is no any CAS array in place by now.

16. Create a new CAS array for the default AD site, and assign the name to "CASArray.<your domain name>". Make sure the successful result is returned.

17. Now we need to set all mailbox databases to use this new "CASArray" for client access.

18. After completion, now we can access mail through the "CASArray" instead of specific CAS server.

19. Now let's force a CASArray fail-over and check if the OWA access keeps alive.

20. Once the resource is switched over, we need refresh the page and re-log on OWA because backend node changes, while the URL and user experience keep consistent.

21. Now let's test the Outlook MAPI connection activities against the CAS array.

22. Following the usual steps to check if Auto-discover work.

23. By now, we can confirm the Outlook auto-discover works properly under the newly created CAS array. By checking the connection status, we can see now the client connects to server through the CAS array instead of any specific server.

24. Send/receive test messages to double confirm email flow functions.

25. We have completed the configuration, now we are going to test if the Outlook can really recognize CAS array and complete auto-failover when one backend server is down.

26. Firstly, let's checking the current service and database status on server:

• User account: administrator@rogertech.com
• Mailbox database: VIP
• Active database copy: EX01
• Cluster resource "CASArray" is running on node: EX01

27. Now I will disable all the NICs on EX01 to force a service down action.

28. As expected, the cluster automatically switched the "CAS Array" to EX02. And the database copy on EX02 take over and act as "Active" through the DAG function.

29. How about client? I kept the Outlook open and tried to send a message during server switching. I can see the "Trying to connect exchange server" for a few seconds. This message stands for "CASArray" switching. The database copy switching is invisible.

30. After all the resources switched over, outlook is performing without any problem, and the pending message is sent out successfully. In my virtual test environment, all the switching-overs complete within 20 seconds.

Enjoy it.

To sync multiple blogs here need configure "Cross-Post".

1. Log into your blog home page, locate the blog dashboard and enter it.

2. In the dashboard management panel, go to Configure -> Advanced Configuration -> Misc.

1) Change the "Post this entry on my other blogs (cross-posting)" to "Yes"

2) Click the "Setup a new blog" to complete the settings.

3. Follow below configuration:

1) "Blog API" web address is: https://blogs.technet.com/metablog.ashx

2) "Blog ID" is your blog name. For example, if your blog url is https://blogs.technet.com/b/example, Blog ID here should be "example".

3) "Username" and "Password" can be found from your account setting page. The password you see here is only for posting, it will NOT change your LiveID password.

4) "Message to the readers" is the optional text telling readers where the original post is or any other text you want to show.

4. Click "Save" several times to complete the configuration.

5. Now when you post on the primary blog, the post will also be cross-posted to the blog you set here.

6. The comments seem to will NOT be cross updated.

Enjoy it.