Infrastructure snapshots

Windows 7 breaks Amazon UK pre-order volume record, ousts Harry Potter

2009-10-22T08:17:00Z

From http://www.engadget.com/2009/10/21/windows-7-breaks-amazon-uk-pre-order-volume-record-ousts-harry/

This is really amazing... Windows 7 rocks:)))

Demystifying Exchange 2010 database availability group (DAG)

2009-07-27T18:40:00Z

What is a DAG?

A database availability group (DAG) is the base component of the high availability and site resilience framework that is built into Exchange 2010. A DAG is a group of up to 16 Mailbox servers that host a set of databases and provide automatic database-level recovery from failures that affect individual servers or databases. Exchange 2010 uses the same continuous replication technology found in Exchange 2007. Exchange 2010 combines on-site data replication (CCR) and off-site data replication (SCR) into a single framework which is the DAG. Once servers have been added to a DAG, administrators can add replicated database copies incrementally, and Exchange 2010 switches between these copies automatically, as needed, to maintain availability.

When can I create a DAG?

After you've deployed Exchange 2010, you can create a DAG, add Mailbox servers to the DAG, and then replicate mailbox databases between the DAG members. A DAG can be created using the New Database Availability Group wizard in the Exchange Management Console, or by running the New-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. When creating a DAG, you provide a name for the DAG, and optional witness server and witness directory settings. In addition, one or more IP addresses are assigned to the DAG, either by using static IP addresses or by allowing the DAG to be automatically assigned the necessary IP addresses using Dynamic Host Configuration Protocol (DHCP).

Do I need to setup windows cluster for the DAG to work?

No, there is nothing called a standalone or clustered Exchange 2010 installation. After you install a normal Exchange 2010 mailbox server, you need to run the New-DatabaseAvailabilityGroup cmdlet to create a DAG, once the DAG has been created, mailbox servers can be added to the DAG. When the first server is added to the DAG, a cluster is formed for use by the DAG. DAGs make limited use of Windows Failover Clustering technology, namely the cluster heartbeat, cluster networks, and the cluster database (for storing data that changes or can change quickly, such as database state changes from active to passive or vice versa, or from mounted to dismounted and vice versa). As each subsequent server is added to the DAG, it is joined to the underlying cluster (and the cluster's quorum model is automatically adjusted by the system, as needed), and the server is added to the DAG object in Active Directory. And because DAGs rely on Windows Failover Clustering, they can only be created on Exchange 2010 Mailbox servers that are running Windows Server 2008 Enterprise Edition or Windows Server 2008 R2 Enterprise Edition. In addition, each Mailbox server in the DAG must have at least two network interface cards in order to be supported

What's happening when I create a DAG or join a server to an existing DAG?

When the first Mailbox server is added to a DAG, the following occurs:

- The Windows Failover Clustering component is installed, if it is not already installed.

- A failover cluster is created using the name of the DAG.

- A cluster network object (CNO) is created in default computers container.

- The name and IP address of the DAG is registered as a Host (A) record in DNS.

- The server is added to DAG object in Active Directory.

- The cluster database is updated with information on the databases that are mounted on the added server.

When the second and subsequent servers are added to the DAG, the following occurs:

- The server is joined to Windows Failover Cluster for the DAG.

- The quorum model is automatically adjusted:

- A Node Majority quorum model is used for DAGs with an odd number of members.

- A Node and File Share Majority quorum is used for DAGs with an even number of members.

- The witness directory and share are automatically created by Exchange when needed.

- The server is added to DAG object in Active Directory.

- The cluster database is updated with info on mounted databases

Can I have DAG members from different subnets?

Yes, during the cluster creation, the Add-DatabaseAvailabilityGroupServer task retrieves the IP address(es) configured while you are creating the DAG, takes whatever appropriate IP and ignores the ones don't match any of the subnets found on the server. This gives you the flexibility to have a DAG with members on the same or different subnets "in case you will have a DAG node in another datacenter".

Can I use a 3rd party replication tool to replicate the databases in the DAG?

By default, a DAG is designed to use the built-in continuous replication feature to replicate mailbox databases between servers in the DAG. If you are using third-party data replication that supports the Third Party Replication API in Exchange 2010, you must create the DAG in third party replication mode by using the New-DatabaseAvailabilityGroup cmdlet with the ThirdPartyReplication parameter, but note that Once this mode is enabled, it cannot be disabled.

Can I encrypt the DAG network traffic?

DAGs support the use of encryption by leveraging the encryption capabilities of the Windows Server operating system. DAGs use Kerberos authentication between Exchange servers. Microsoft Kerberos SSP’s EncryptMessage/DecryptMessage APIs handle encryption of DAG network traffic. Microsoft Kerberos SSP supports multiple encryption algorithms. The Kerberos authentication handshake picks the strongest encryption protocol supported in the list: typically AES 256-bit, potentially with a SHA Hash Message Authentication Code (HMAC) to maintain integrity of the data

Can I compress the DAG network communication?

DAGs also support built-in compression. When compression is enabled, DAG network communication uses XPRESS, which is Microsoft’s implementation of the LZ77 algorithm. This is the same type of compression used in many Microsoft protocols, in particular, MAPI RPC compression between Outlook and Exchange

What is the minimum network interfaces required for a DAG?

As indicated above, each Mailbox server in the DAG must have at least two network interface cards in order to be supported. In Exchange 2010, DAGs primarily have two types of networks: MAPI networks, which are used by other Exchange 2010 servers to communicate with the Mailbox server in the DAG, and Replication networks, which are used for log shipping and seeding within the DAG. So the reason to have at least two NICs is that this configuration enables you to configure one MAPI network and one Replication network.

What will happen if one of my DAG networks encountered a failure?

In the event of a failure affecting the MAPI network, a server failover will occur (assuming there are healthy mailbox database copies that can be activated). In the event of a failure affecting the Replication network, if the MAPI network is unaffected by the failure, log shipping and seeding operations will revert to use the MAPI network. When the failed Replication network is restored, log shipping and seeding operations will revert back to the Replication network. To increase the high availability on your DAG, additional MAPI and/or Replication networks can be added, as needed. Also you can prevent an individual network from being a single point of failure by using network adapter teaming or similar technology.

Can I host other roles on a mailbox server that is member of a DAG?

Unlike Exchange 2007, where clustered mailbox servers required dedicated hardware, Mailbox servers in a DAG can host other Exchange roles (Client Access, Hub Transport, Unified Messaging), providing full redundancy of Exchange services and data with just two servers. This can be an excellent option for small and medium organizations where the number of mailboxes and email traffic doesn't require a dedicated hardware for each role.

Facts about Exchange 2007 SP2…

2009-07-26T18:26:00Z

Exchange 2007 SP2 is coming very soon and I thought of highlighting some important facts about it:

Installations of Exchange 2007 SP2 will require Windows Installer 4.5
Exchange 2007 SP2 will Include Exchange 2010 schema. This will not eliminate the need however to run PrepareSchema when you deploy Exchange 2010 as we still have some checks we want to run and preps we need to do for 2010. However you need to plan for a schema preparation before deploying SP2.
New blocking setup prerequisites to address: http://msexchangeteam.com/archive/2008/09/05/449764.aspx
Exchange Volume Snapshot Backup Functionality - A new backup plug-in has been added to the product that will enable customers to create Exchange backups when a backup is invoked through the Windows Server 2008 Backup tool. Exchange Server 2007 didn't have this capability on Windows Server 2008 and additional solutions were required to perform this task.

Update Rollup 9 for Exchange Server 2007 Service Pack 1 has been released

2009-07-26T16:45:00Z

We have released Update Rollup 9 for Exchange Server 2007 Service Pack 1 (KB 970162) to the download center. The release of the rollup via Microsoft Update will happen on July 28. Read the details at http://msexchangeteam.com/archive/2009/07/17/451835.aspx also KB 970162 has more details about this release and a complete list of all fixes included in this rollup.

Note this important point in the article “Support for Windows Server 2008 R2 Domain Controllers in the environment (Note: Exchange Server 2007 itself is not supported to be installed on a Windows Server 2008 R2 system”

Large Message Processing in Exchange, Part 1: Prevention and Planning

2009-07-26T16:38:00Z

An Excellent article that you should read at http://msexchangeteam.com/archive/2009/07/07/451737.aspx

Thanks Scott Landry, Mohammad Nadeem and Bill Long for this great blog,

Exchange 2010 Archiving... Why to Archive???

2009-07-25T00:25:00Z

From few weeks I was reading about Exchange 2010 archiving and I thought of blogging about it to summarize what we can do with Exchange 2010 Archiving and what is the advantage from using it.

Why Archive E-Mail:

As data volume grows inside the mailboxes, outlook performance starts to decrease
Archiving helps in eliminating PSTs. Let’s not forget that PSTs also add to further performance/management issues and adds lot of challenges to compliance and discovery
Manual retrieval cost for old data can be huge (backup tapes, PSTs, etc...)
PSTs are accessible on local machine only
PSTs can be easily corrupted “can be a big issue without a backup”
Lost laptop results in exposure of PSTs content

Exchange 2010 Archiving features:

Secondary Personal Archive. It acts as a secondary mailbox node. The archiving mailbox must be in the same database hosting the primary mailbox
Controlled Retention Policies. It provides integrated retention policies on the folder/item level
Multi Mailbox Search. Delegated non-IT compliance officers, HR, legal, etc... Can do a legal multi-mailbox search using a role-based GUI. Search can be filtered using multi criteria such as sender, receiver, expiry policy, message size, IRM protected items, etc...
Legal Hold. Suspected mailbox can be put on legal hold to be included in a multi-mailbox search. Users can be notified in their outlook that their mailbox is under legal hold.
Ease of Access. Appears alongside a user's primary mailbox in outlook or outlook web access
Easy PST Migration. Supported drag & drop for PSTs to the personal archive for easy migration of existing PSTs
Controlled Quota. Archive quota can be set separately from primary mailbox
Retention Policies Integration. Mail in primary mailbox can be moved to the archive through integrated retention policies.

Advantage of Archive:

Compliance & Discovery. PSTs are difficult to be discovered by IT administrators. With Archiving it's possible for data discovery and legal hold for all mailbox content
Data Protection. With PSTs it is very complex to protect the data inside the PSTs by the company backup system. With Archiving all mailbox content can be protected by the backup system.
Quota Management. Previously users were forced to keep track on their quota and move data to their PSTs. Archiving allow for large mailboxes and for automatic archiving to the old data to the archive mailbox.
Reduced Cost. No additional licenses required, it's a part of the Exchange 2010 ECAL
Multi Storage Options. With Exchange 2010 & archiving you can host your data on DAS-SATA storage architecture to reduce storage costs

So looking to the above, I can say that for most of the organizations who will be looking for getting rid of PSTs and giving large mailboxes for their users, Exchange 2010 Archiving will be your arm to do that.

Common Unsupported Exchange 2007 Configurations

2009-06-17T12:15:00Z

This is an interesting section in the Exchange 2007 help file that i wanted to share and recommend you to read it,

http://technet.microsoft.com/en-us/library/dd577077.aspx

Exchange Server 2007 Service Pack 2 available in Q3 2009

2009-05-18T18:17:00Z

Key new features of Exchange Server 2007 SP2 unveiled today include:

Enhanced Auditing - New Exchange auditing events and audit log repository enable Exchange administrators to more easily audit the activities occurring on their Exchange servers. It allows the right balance of granularity, performance, and easy access to audited events via a dedicated audit log repository. This simplifies the auditing process and makes review of audited events easier by segregating audited events in a dedicated location.
Exchange Volume Snapshot Backup Functionality - A new backup plug-in has been added to the product that will enable customers to create Exchange backups when a backup is invoked through the Windows Server 2008 Backup tool. Exchange Server 2007 didn't have this capability on Windows Server 2008 and additional solutions were required to perform this task.
Dynamic Active Directory Schema Update and Validation - The dynamic AD schema update and validation feature allows for future schema updates to be dynamic deployed as well as proactively preventing conflicts whenever a new property is added to the AD schema. Once this capability is deployed it will enable easier management of future schema updates and will prevent support issues when adding properties that don't exist in the AD schema.
Public Folder Quota Management - SP2 enables a consistent way to manage quotas by improving the current PowerShell cmdlets to perform quota management tasks.
Centralized Organizational Settings - SP2 introduces new PowerShell option that enable centralized management of many of the Exchange organization settings.
Named Properties cmdlets - SP2 enables Exchange administrators to monitor their named property usage per database.
New User Interface for Managing Diagnostic Logging- SP2 enables Exchange administrators to easily configure and manage diagnostic logging from within the Exchange Management Console.

Read the full article at http://msexchangeteam.com/archive/2009/05/11/451281.aspx

Exchange 2010 setup wizard

2009-05-01T22:47:00Z

In this article I’ll give you a tour for the Exchange 2010 setup wizard, if you deployed Exchange 2007 before you will be familiar of the Exchange 2010 setup wizard, if not then here is how it looks:

Finally here is the Exchange 2010 EMC.

Exchange 2010 setup prerequisites http://technet.microsoft.com/en-us/library/bb691354(EXCHG.140).aspx

XP is going to Extended Support

2009-04-16T11:32:00Z

As of 19th of April 2009; Windows XP will go from the mainstream support to the extended support phase. What

What kind of support will customers receive during the Extended Support phase?

During the Extended Support phase, Microsoft will continue to provide security patches at no additional charge, automatically delivered monthly via Windows Update
Customers who purchased Windows XP pre-installed on their machines will continue to receive support from their Original Equipment Manufacturer (OEM)
Microsoft will accept no-charge calls from customers with Windows installation issues only. However, all customers can also obtain paid incident support

What is changing on April 14, 2009?

On April 14, 2009, Windows XP will transition from the Mainstream Support phase to the Extended Support phase, as planned and previously announced. Extended Support for Windows XP will be available until April 8, 2014.
During the Extended support phase, Microsoft will provide paid support (example: per-incident telephone/web support, Premier and Essential support, etc.) for all customers.
During the Extended Support phase, non-security hotfixes will be available to Premier customers for a fee via the Extended Hotfix Support (EHS) program.

Please note: As per the Microsoft Support Lifecycle policy, Mainstream and Extended Support require that the supported service packs be installed in order to continue receiving any support, including security updates. Therefore, to receive Extended Support for Windows XP, customers must have the latest, supported service pack installed.

These dates are in line with the Microsoft Support Lifecycle policy, which provides transparent, predictable information about the support lifecycle of Microsoft products. More information is available on the MSL Web site at http://support.microsoft.com/lifecycle

Important links:

MSL External Web site: http://support.microsoft.com/lifecycle/

MSL FAQs: http://support.microsoft.com/gp/lifepolicy

Product Support Dates Search: http://support.microsoft.com/lifecycle/search/

Exchange 2010 beta is online

2009-04-15T15:23:00Z

Wanted to test and play with Exchange 2010, go and get the beta from here http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=1898ed2c-2f88-48ac-824e-d3d20fad77d7 also you can find the beta documentation at http://technet.microsoft.com/en-us/library/bb124558(EXCHG.140).aspx

Enjoy,

SCVMM P2V... Feel the heat!!!

2008-12-05T13:49:00Z

This week I was working with a colleague in bringing up a staging environment as a replica from the production one and off course we used Hyper-V to host the virtual machines and System Center Virtual Machine Manager “SCVMM” to do the Physical to Virtual “P2V” operation. The installation of the SCVMM was extremely easy with no glitches, after that we decided to start the P2V operation and here we started to feel the heatJ. The experience was amazing and I can summarize the bit falls as following:

1. If you are doing an offline P2V operation for a server such as a domain controller, make sure that you download the Vista 32-bit driver for the server network adapter and extract the driver package under the SCVMM\Drivers\Import folder. This is to allow for the network communication with the server when it boots to the WinPE phase. I failed to find the vista 32-but driver for my server NIC so I was forced not to use the P2V and promoting an additional DC and cleaning it up from the production environment after isolating it in the staging environment.

2. Before you start the P2V operation make sure that you allocate not less than 2 logical processors (I’d recommend 4) and not less than 2 GB of memory to the guest. This is to allow for the installation of the Integration services to succeed. This is because the first time the virtualized windows will start as part of the P2V process to install the integration services the guest processor will be 100% and if you didn’t allocate enough processing power to the guest machine it will timeout before It can manage to install it

3. If the installation of the integration services insisted to fail during the P2V process make sure that you allocate around 4 logical processors cores to the guest and use the SCVMM to force the installation of the integration services. Once the machine boots and you see the logon screen insert the integration services disk through the Hyper-V console menu, I’m not sure that this is necessary but my colleague advised me to do that and it succeeded so we didn’t change the process for the rest of the serversJ

4. After you successfully finish the integration services installation and manage to logon to the guest uninstall all of the hardware vendor tools and monitoring software. In case of clustered servers uninstall the vendor multipath software. Also uninstall any monitoring or backup agents if you are not bringing its servers to the virtual environment.

5. In case of doing virtualization for cluster nodes, don’t forget to prepare the iSCSI target software that you will use to present the SAN disks to the cluster nodes so you can bring up the cluster and fix whatever necessary.

After all, the SCVMM P2V rocks!!!

Who wants to be a Certified Master???

2008-06-14T13:46:08Z

And finally the Microsoft Certified Master program is live. I was monitoring the progress of this amazing program while it was still in development and I really liked the idea and all I can say is that if you want to be recognized & to be different go and check http://www.microsoft.com/learning/mcp/master/default.mspx

It really deserve the effort...

Exchange 2000/2003 to Exchange 2007 migration guidelines

2008-06-04T14:37:00Z

I've worked on many projects involving migrating Exchange 2000/2003 to Exchange 2007 and from these migration planning i can list the common guidelines that can help in doing your migration planning. The transition process from Exchange 2003 to Exchange 2007 is a relatively straightforward process and involves the following high level tasks:

1. Prepare the Active Directory directory service, you can extend the Active Directory schema and create the Active Directory objects and universal security groups to support Exchange 2007 before you install the server roles. Run setup.com /PrepareAD from the command line on the domain controller that is the schema master at the forest root. When you run setup.com /PrepareAD, the task setup.com /PrepareLegacyExchangePermissions also runs to create the universal security group that is granted permissions to send e-mail to Exchange 2007 Hub Transport servers

2. Supress minor link state updates on all Exchange 2003 front end servers

3. Deploy Exchange 2007 CAS/HUB servers in the same organization/forest as the existing Exchange 2003 servers and choose FE_SERVERNAME as the routing group connector destination

Note: Using an Exchange Server 2003 front-end server together with an Exchange 2007 Mailbox server is not supported.

4. Configure the routing group connector to use all Hubs servers

5. Deploy the Edge servers

6. Configure the external firewall to allow for outbound SMTP traffic from the Edge servers

7. Configure Edge Sync subscription and rest of the Edge settings

8. Configure the external firewall 1:1 NAT for both Edge servers to allow for incoming SMTP traffic

9. Delete the old SMTP connectors

10. Deploy Exchange 2007 mailbox servers

11. Configure Public folder replication

12. Configure the CAS web services virtual directories by following the below steps:

a. Configure CAS OWA virtual directories to support integrated authentication and to set the the external URL

b. Configure Outlook Anywhere internal/external URLs with Integrated authentication and set the External/Internal URLs

c. Configure ActiveSync external URL

d. On the Exchange 2003 backend clusters; configure the ActiveSync virtual directory to use Integrated Authentication

e. Configure OAB URLs using the Exchange Management Console and configure it to use HTTPS instead of HTTP

13. Configure rest of the CAS settings

14. Publish the ActiveSync through ISA 2006

15. Test co-existence between both servers:

a. GAL co-existence is automatically achieved since all servers share the same Active Directory information. This means the GAL will appear the same for both Exchange 2007 and 2003 users

b. Email connectivity between Exchange 2003 to Exchange 2007 servers will automatically be enabled because of the Routing Group Connector created by the installation of the Hub server role

16. Move sample mailboxes using the Exchange 2007 move mailbox wizard or cmdlet as a test for the migration

Note: You do not need to move your existing contacts or distribution groups. They will be available in Active Directory even if you remove your Exchange 2003 or Exchange 2000 servers

17. On an Exchange 2007 server, for each offline address book (OAB), move the generation process to an Exchange 2007 server. For detailed steps, see How to Move the Offline Address Book Generation Process to Another Server.

18. Upgrade the email address policies

19. Upgrade the address lists

Note: Use the LDAP to OPATH converter tool

20. Change the routing group connectors to use the Exchange 2003 backend server

21. Decommission Exchange 2003 Front End servers

22. Move rest of the mailboxes to the Exchange 2007 mailbox cluster

Note: If you have any Exchange 2003 or Exchange 2000 recipient policies that have not been applied, moving the mailboxes to an Exchange 2007 server will force the recipient policies to be re-evaluated and applied. Before you move mailboxes, make sure that you want to apply all of the existing recipient policies. If you have an existing recipient policy that you do not want to apply, clear the automatically update e-mail address based on e-mail address policy check box in Active Directory Users and Computers. For more information, see the Exchange Server Team Blog article Yes, Exchange 2007 really enforces Email Address Policies.

Note: The old Exchange 2003 backend will be running for at least 1 week in order to allow Outlook clients to automatically update their profile to point to the new Exchange 2007 mailbox cluster, otherwise, if the cluster is decommissioned immediately, clients will not be able to access their mailboxes until their profiles are modified to use the new Exchange mailbox server. KOC must ensure that all Outlook clients will logon at least once during this week for their profiles to be updated. Clients that do not logon before the old cluster is decommissioned must be updated manually. Exprofile can be configured to run as a logon script for the MAPI users to automatically configure their Outlook profiles to use the new mailbox server.

23. Remove the Exchange 2003 backend servers. The decommissioning of the Backend servers should be conducted after making sure that all clients are redirected to the Exchange 2007 servers

24. Remove the last Exchange 2003 server from the organization. For detailed steps, see http://technet.microsoft.com/en-us/library/bb288905(EXCHG.80).aspx

Note that these are just a guidelines to help in your migration planning, i'm not covering all of the scenarios and situations which will vary according to the environment design & setup.

Microsoft.com Operations Virtualizes MSDN and TechNet on Hyper-V

2008-05-24T18:12:17Z

If you were at MMS 2008 and heard Bob Muglia’s Keynote, you already know that MSDN.microsoft.com (MSDN) and TechNet.microsoft.com (TechNet) have been successfully running on Hyper-V. Specifically, we migrated MSDN March 31 2008, and then followed up with TechNet April 18 2008.

Hyper-V Beta Deployment

Our production testing began in early February 2008, when we installed the Hyper-V role on two physical servers, with each hosting three VMs running MSDN. Production load on these six VMs progressed from a cautious 1 percent to 20 percent very quickly and smoothly. During the next six weeks, we tested various amounts of load and VM combinations to better understand the performance characteristics and scalability of the product and the site. MSDN was also deployed directly onto matching physical servers to compare VMs against physical performance, scale, and stability with the same load characteristics.

In an effort to push the site and Hyper-V to their performance limits, we replayed production IIS logs by using the Web Capacity Analysis Tool (WCAT) to understand the upper range performance and scale characteristics.

We tested and compared one, two, and finally three VMs per physical server. The data gathered is in line with those discussed in the "MSDN and TechNet Virtualization Results" section later in this article. The performance and stability of MSDN on the Hyper-V Beta release were so encouraging that, with RC0 nearing release, we began making preparations to move to the next phase of implementation.

Hyper-V RC0 Deployment

With the release of RC0, we moved forward with the full virtualization of the MSDN front-end Web servers. Testing to date provided the physical and virtualized server capacity targets for peak load and data center redundancy. Although testing indicated two VMs per physical server were optimal for MSDN on these particular physical servers, we maintained the three VM per server architecture. This allowed us to continue evaluating CPU and disk oversubscription.

The deployment is described in Table 1:

Component	Description
Hardware	Dual socket Quad-Core Intel processors 32GB RAM 4x146GB disk drives
Virtual Machines	4 Virtual processors 10GB RAM 250GB dynamic VHD
Operating system – Parent	Windows Server 2008 Hyper-V RC0 Reserved 2GB RAM from 32GB total
Operating system – VMs	Windows Server 2008 Internet Information Services (IIS) 7.0

We placed the first two servers built on Hyper-V RC0 into production to validate that the stability and performance was still in line with that of the beta release. We performed the same load and performance testing for RC0 as we did for the beta deployment while we built out the remaining VMs required for the full deployment.

The VMs in each data center were configured behind a hardware load balancing (HLB) cluster along with the existing physical servers. This allowed us to transfer traffic to the VMs while having the physical servers in place in the event that something unexpected occurred.

Deployment Items of Note

The MSDN VMs were deployed as dynamic virtual hard disks (VHDs), mainly because we were unsure whether we would ultimately deploy two or three VMs on the available physical drive space. Although dynamic disks do not perform quite as well as fixed or physical disk options, this allowed us flexibility at a time when we were deploying VMs manually. In the next stage of our Hyper-V adoption, we plan to implement a storage area network (SAN) infrastructure with the storage resources available to allow testing of all disk options.

We deployed TechNet on the MSDN VMs after our testing proved the VMs were stable and performed well. This is in line with our MSDN and TechNet build and deployment processes, and therefore, dovetails nicely into our future automation goals.

Virtualization Environment for MSDN and TechNet

Figure 1 provides a high-level view of the physical and virtual architecture MSDN and TechNet. It illustrates how Hyper-V fits into the MSDN and TechNet architecture, with each physical server hosting three virtual machines with full data center redundancy.

MSDN and TechNet Virtualization Results

The results of our implementation MSDN and TechNet on Hyper-V RC0 are summarized in the following sections: Stability, Performance, and Lessons Learned.

Stability

Hyper-V has been exceptionally stable, proving capable of delivering the end-to-end availability of MSDN and TechNet compared to the previous physical platform during both beta and RC0 usage. In fact, for the deployment so far, MSCOM Ops has not encountered a single production-impacting bug. This is definitely quite an accomplishment for the Hyper-V development team.
Log Parser analysis of the IIS logs showed that the error rates were comparable between the virtual and physical instances.

Performance

Hyper-V CPU overhead (as measured by the parent partition utilization) was 5 to 6 percent with linear progression as the number of requests increased. This is illustrated in Figure 2.
CPU oversubscription (three four-processor VMs on an eight-processor physical server) resulted in 3 percent lower overall performance per physical server based on overall requests per second per 1 percent CPU.
Requests per second per 1 percent CPU performance of MSDN over the previous physical server platform improved. This demonstrates to us the viability of efficient consolidation from dedicated older physical servers to shared virtualized platforms.
Physical MSDN handled 21 percent more requests per second per 1 percent CPU than virtualized MSDN. Figure 3 illustrates physical compared to virtual scale up for MSDN under peak production load on matching hardware.

Note: Requests per 1 percent CPU was a primary performance benchmark for our MSDN deployment because it distilled Hyper-V's effects down to a simple, but meaningful, number for these Web sites.

Figure 2 illustrates a detailed breakout of virtual machine, Hyper-V, and guest CPU utilization.

Figure 2. 5-6% CPU Hyper-V Cost on Physical Blade with Reasonably Linear Progression as Number of Requests Increase

Figure 3 illustrates how we used two blade servers to compare high utilization physical to virtual scalability. Lower CPU utilization is better.

Figure 3. Reasonably Linear CPU Utilization Progression Using MSDN Production Load

Lessons Learned

Based on our results with Hyper-V, and a review of current hardware utilization across our environment, we expect to realize significant benefits by consolidating diverse applications on a virtualized platform. Mixing high and low scale systems on the same physical server resources should enable us achieve improved overall hardware utilization and a reduced physical footprint.
Although we reduced our hardware supporting MSDN and TechNet by migrating from older physical servers to a smaller deployment of new, more powerful physical servers, there is some minimal overhead associated with virtualization. From our perspective, Hyper-V has clearly delivered enough performance, stability, and scale to drive widespread adoption in our production environment. The flexibility and management gains expected from coupling System Center Virtual Machine Manager (SCVMM) v2 with Hyper-V should justify the measured overhead.
If the three percent or less in additional overhead from oversubscribing resources is consistent with additional application workloads tested, oversubscription with Hyper-V should provide MSCOM Ops significant flexibility and reasonable performance for application consolidation.
The results we achieved are based on the application characteristics of MSDN and TechNet on Hyper-V RC0. We are working to build a model based on this data that we hope will allow us to predict physical and VM requirements based on common performance characteristics of a Web site. The model will likely include the current requests per second per 1 percent CPU metric with additional memory and I/O performance characteristics as we virtualize other Web applications and gather more test and production data.