Windows Virtualization Team Blog

Using SMB shares with Hyper-V Replica

2013-06-14T12:48:00Z

SMB is getting a lot of attention with Windows Server 2012, and we’ve had questions from a few customers regarding the inter-play between SMB shares and Hyper-V Replica. In this post we’ll share our experience around setting up and using various configurations involving SMB shares and Hyper-V Replica. The issue we were expecting to run into is the apparent lack of authorization to use the SMB share, when using remote management.

In all the scenarios that are investigated, we will start from a remote management node (mgmtnode.contoso.com). We will try to set up the scenario from this management node, and work through the errors encountered. In order to visualize what this means, all the scenarios will look roughly like this:

Scenario #1: Single Replica server with SMB share

The building blocks

A single Hyper-V server (aashish-server.contoso.com) on the Replica site
A single server (aashish-server3.contoso.com) hosting an SMB share \\aashish-server3\Replica-Site that will be used to store the Replica VMs.
A single remote management server (mgmtnode.contoso.com)

Setting up the infrastructure

To start with, we will try using the Hyper-V Manager UI. On the management node (mgmtnode.contoso.com), open the Hyper-V Manager UI and add the server aashish-server on the left-side pane using “Connect to Server…”. Now enable aashish-server as a Replica server using the Hyper-V Settings on the right-side pane. As expected, we run into an error:

The error encountered is “Failed to add authorization entry. Unable to open specified location to store Replica files ‘\\aashish-server3\Replica-Site\’. Error: 0x80070005 (General access denied error).”, and it is not a very helpful error message. Hopefully this blog can help alleviate that situation.

Fixing the error

While the standard answer to fixing this error will be to setup constrained delegation, this is not something that is always optimal. Yes, the core issue is around delegation of credentials when there is an additional hop (mgmtnode –> aashish-server –> aashish-server3). However, depending on your setup and how often you plan to change the Replica server settings, there are simpler solutions.

Remote into aashish-server directly as set up the Replica server – this eliminate the hop that causes problems. With just one server to configure, this will be the simplest solution for your needs.
Use CredSSP and PowerShell to delegate credentials and set up the Replica server, and we will be exploring this later in the blog post. This is an excellent option for users where:

No domain controller access is possible.
No Remote access is possible.
The Windows Server UI is not present on any node other than the management node.

Set up constrained delegation in your domain controller. This option has been explored extensively by others and there is ample material on this available online.

Scenario #2: Multiple Replica servers (unclustered) with SMB share

For all practical purposes this is like the single Replica server scenario discussed above, except that you will have to remote into each server and setup replication. At even 5 servers, this is a painful exercise. Constrained Delegation starts to look like an increasingly attractive option. Yet, without access to the domain controller perhaps the realistic route is that of CredSSP and PowerShell – and that will be something we will cover in detail in this post.

Scenario #3: Replica cluster with SMB share

The building blocks

A failover cluster (AAR-130612) on the Replica site having the .contoso.com domain. This consists of two servers (aashish-s1, aashish-s2), and a Replica Broker (AARBrk-130612). The broker can be present on either node, but in this example we will assume that it resides on aashish-s2.
A single server (aashish-server3.contoso.com) hosting an SMB share \\aashish-server3\Replica-Site that will be used to store the Replica VMs.
A single remote management server (mgmtnode.contoso.com)

Setting up the infrastructure

As with the non-clustered scenarios, you will run into the General access denied error when you use the Failover Cluster UI to change the replication settings.

Trying this through PowerShell will give you a similar error:

Set-VMReplicationServer : Failed to add authorization entry. Unable to open specified location to store Replica files '\\aashish-server3\Replica-Site'. Error: 0x80070005 (General access denied error). You do not have permission to perform the operation. Contact your administrator if you believe you should have permission to perform this operation.
At line:1 char:1
+ Set-VMReplicationServer -ComputerName AARBrk-130612 -AllowedAuthenticationType ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (Microsoft.HyperV.PowerShell.VMTask:VMTask) [Set-VMReplicationServer], VirtualizationOperationFailedException
+ FullyQualifiedErrorId : AccessDenied,Microsoft.HyperV.PowerShell.Commands.SetReplicationServerCommand

Fixing the error

Although the cluster has multiple nodes, the scenario is similar to that of a single Replica server. When using clusters, it is sufficient to make the changes to the Hyper-V Replica Broker (AARBrk-130612 in this case), and the replication settings will be propagated to the rest of the cluster nodes. So depending on your setup and how often you plan to change the Replica Broker settings, there are a few options to consider:

Remote into the server on which the Replica Broker is running (aashish-s2 in this case), use the Failover Cluster UI and directly set up the Replica – eliminate the hop that is causing problems. In most cases, the replication configuration is a one-time operation, so this could be the simplest solution for your needs.
Remote into any server in the cluster and use the PowerShell command-let Set-VMReplicationServer. There is no need to use –ComputerName in the parameters as the command-let itself is cluster-aware.
Use CredSSP and PowerShell to delegate credentials and set this up if options 1 and 2 are not for you.
Set up constrained delegation in your domain controller.

Using CredSSP and PowerShell

This option is interesting from many angles. The big attraction is PowerShell; with administrators increasingly moving to PowerShell to automate and manage their infrastructure, getting things done through PowerShell is sometimes more important than through a UI. Just as important is the fact that remoting into a Replica server is not always feasible or advisable – and hence the management node from where all actions are performed. The CredSSP-based solution fits neatly into such a scenario.

For enabling the delegation of credentials, run the following commands on the management node:

Enable-WSManCredSSP –Role Client –DelegateComputer aashish-s1.contoso.com
Invoke-Command –ComputerName aashish-s1.contoso.com –ScriptBlock { Enable-WSManCredSSP –Role Server }

Once this is done, you follow-up with Set-VMReplicationServer but run on the cluster host that you have just delegated to:

Invoke-Command –ComputerName aashish-s1.contoso.com –Authentication Credssp –Credential DOMAIN1\user1 –ScriptBlock { Set-VMReplicationServer …}

where DOMAIN1 and user1 are authenticated on aashish-s1.contoso.com. Note that you do not need to use –ComputerName with the Set-VMReplicationServer command because it is cluster aware!

Adding a node to this cluster

So what happens if you add a new node to this Replica cluster? No worries! The replication settings are propagated to this node also with no additional steps on your part. If you need to change the replication settings, you can use the same steps outlined without worrying about the new server.

Concluding note

Hopefully this will set you back on track with Hyper-V Replica and SMB shares. Give this a go and share your experience with us – we would love to hear your feedback!

MMS 2013 Labs: Powered by Microsoft/HP Private Cloud...

2013-05-29T13:54:00Z

MMS 2013 Hands On Labs

Virtualization Nation,

A few weeks ago we held the annual 2013 Microsoft Management Summit in Las Vegas. As in years past, the event sold out quickly and it was a very busy week. To everyone that attended, our sincere thanks.

As usual, the hands-on labs and instructor-led labs continue to be some of the most popular offerings at MMS. MMS Labs offer folks the opportunity to kick the tires on a wide array of Microsoft technologies and products. As usual the lines started early. For the fourth year in a row, all of the MMS Labs were 100% virtualized using Windows Server Hyper-V and managed via System Center by our partners at Xtreme Consulting Group and using HP servers and storage. Of course, this year we upgraded to the latest version so everything was running on a Microsoft Cloud powered by Windows Server 2012 Hyper-V and System Center 2012 SP1.

(BTW, I’ve blogged about this topic in the past years, if you’re interested the links are here and here.) Before I jump into the Microsoft Private Cloud, let me provide some context about the labs themselves.

What is a MMS Hand On Lab?

One of the reasons the MMS Hands on Labs are so popular is because it’s a firsthand opportunity to evaluate and work with Windows Server and System Center in a variety of scenarios at your own pace. Here’s a picture of some of the lab stations…

With the hands on labs, we’ve done all the work to create these scenarios based on your areas of interest. So, what does one of these labs look like on the backend? Let’s be clear, none of these labs are a single VM. That’s easy. Been there, done that. When you sit down and request a specific lab, the cloud infrastructure provisions the lab on highly available infrastructure and deploys services that can be anywhere from 4 – 12 virtual machines in your lab in seconds. There are over 650 different lab stations and we have to account for all types of deployment scenarios. For example,

In the first scenario, all users sit down at 8 am and provision exactly the same lab. Or,
In the second scenario, all users sit down at 8 am and provision unique, different labs. Or,
In the third scenario, all users sit down at 8 am and provision a mix of everything

The lab then starts each lab in a few seconds. Let’s take a closer look at what some of the labs look like in terms of VM deployment.

MMS Lab Examples

Let’s start off with a relatively simple lab. This first lab is a Service Delivery and Automation lab. This lab uses:

Four virtual machines
16 virtual processors
15 GB of memory total
280 GB of storage
2 virtual networks

…and here’s what each virtual machine is running…

Interested in creating virtualizing applications to deploy to your desktops, tablets, Remote Desktop Sessions? This next lab is a Microsoft Application Virtualization (App-V) 5.0 Overview lab. This lab uses:

Seven virtual machines
14 virtual processors
16 GB of memory total
192 GB of storage
2 virtual networks

How about configuring a web farm for multi-tenant applications? Here’s the lab which uses:

Six virtual machines
24 virtual processors
16 GB of memory total
190 GB of storage
2 virtual networks

Ever wanted to enable secure remote access with RemoteApp, DirectAccess and Dynamic Access Control? Here’s the lab you’re looking for. This lab uses:

Seven virtual machines
28 virtual processors
18 GB of memory total
190 GB of storage
2 virtual networks

Again, these are just a few of the dozens of labs ready for you at the hands on labs.

MMS 2013 Private Cloud: The Hardware

BTW, before I get to the specifics, let me point out that this Microsoft/HP Private Cloud Solution is an orderable solution available today...

Compute. Like last year, we used two HP BladeSystem c7000s for compute for the cloud infrastructure. Each c7000 had 16 nodes and this year we to upgraded to the latest BL460c Generation 8 Blades. All 32 blades were then clustered to create a 32 node Hyper-V cluster. Each blade was configured with:

Two sockets with 8 cores per socket and thus 16 cores. Symmetric Multi-Threading was enabled and thus we had a total of 32 logical processors per blade.
256 GB of memory per blade with Hyper-V Dynamic Memory enabled
2 local disks 300 GB SAS mirrored for OS Boot per blade
HP I/O Accelerator cards (either 768 GB or 1.2 TB) per blade

Storage. This year we wanted to have a storage backend that could take advantage of the latest storage advancements in Windows Server 2012 (such as Offloaded Data Transfer and SMI-S) so we decided to go with a 3Par StoreServ P10800 storage solution. The storage was configured as a 4 node, scale-out solution using 8 Gb fibre channel and configured with Multi-Path IO and two 16 port FC switches for redundancy. There was a total of 153.6 TB of storage configured with:

64 x 200 GB SSD disks
128 x 600 GB 15k FC disks
32 x 2 TB 7200k RPM SAS

As you can see, the 3Par includes SSD, 15k and 7200k disks. This is so the 3Par can provide automated storage tiering with HP’s Adaptive Optimization. With storage tiering, this ensures the most frequently used storage (the hot blocks) reside in the fastest possible storage tier whether that’s RAM, SSD, 15k or 7200k disks respectively. With storage tiering you can mix and match storage types to find the right balance of capacity and IOPs for you. In short, storage tiering rocks with Hyper-V. From a storage provisioning perspective, both SCVMM and the 3Par storage both support standards based storage management through SMI-S so the provisioning of the 3Par storage was done through System Center Virtual Machine Manager. Very cool.

Networking. From a networking perspective, the solution used VirtualConnect FlexFabric 10Gb/E and everything was teamed using Windows Server 2012 NIC Teaming. Once the network traffic was aggregated in software via teaming, that capacity was carved up in software.

Time for the Pictures…

Here’s a picture of the racks powering all of the MMS 2013 Labs. The two racks on the left with the yellow signs are the 3Par storage while the two racks on the right contain all of the compute nodes (32 blades) and management nodes (a two node System Center 2012 SP1 cluster). What you don’t see are the crowds gathered around pointing, snapping pictures, and gazing longingly…

MMS 2013: Management with System Center. Naturally, the MMS team used System Center to manage all the labs, specifically Operations Manager, Virtual Machine Manager, Orchestrator, Configuration Manager, and Service Manager. System Center 2012 SP1 was completely virtualized running on Hyper-V and was running on a small two node cluster using DL360 Generation 8 rackmount servers.

Operations Manager was used to monitor the health and performance of all the Hyper-V labs running Windows and Linux. Yes, I said Linux. Linux runs great on Hyper-V (it has for many years now) and System Center manages Linux very well… J To monitor health proactively, we used the ProLiant and BladeSystem Management Packs for System Center Operations Manager. The HP Management Packs expose the native management capabilities through Operations Manager such as:

Monitor, view, and get alerts for HP servers and blade enclosures
Directly launch iLO Advanced or SMH for remote management
Graphical View of all of the nodes via Operations Manager

In addition, 3Par has management packs that plug right into System Center, so Operations Manager was used to manage the 3Par storage as well…

…having System Center integration with the 3Par storage came in handy when one of the drives died and Operations Manager was able to pinpoint exactly what disk failed and in what chassis…

Of course, everything in this Private Cloud solution is fully redundant so we didn’t even notice the disk failure for some time…

In terms of managing the overall solution, here’s a view of some of the real time monitoring we were displaying and where many folks just sat and watched.

Virtual Machine Manager was used to provision and manage the entire virtualized lab delivery infrastructure and monitor and report on all the virtual machines in the system. In addition, HP has written a Virtual Machine Manager plug-in so you can view the HP Fabric from within System Center Virtual Machine Manager. Check this out:

It should go without saying that to support a lab of this scale and with only a few minutes between the end of one lab and the beginning of the next, automation is a key precept. The Hands on Lab team was positively gushing about PowerShell. “In the past, when we needed to provide additional integration it was a challenge. WMI was there, but the learning curve for WMI is steep and we’re system administrators. With PowerShell built-into WS2012, we EASILY created solutions and plugged into Orchestrator. It was a huge time saver.”

MMS 2013: Pushing the limit…

As you may know, Windows Server 2012 Hyper-V supports up to 64 nodes and 8,000 virtual machines in a cluster. Well, we have a history for pushing the envelope with this gear and this year was no different. At the very end of the show, the team fired up as many virtual machines to see how high we could go. (These were all lightly loaded as we didn’t have the time to do much more…) On Friday, the team fired up 8,312 virtual machines (~260 VMs per blade) running on a 32 node cluster. Each blade has 256 GB of memory each and we kept turning on VMs until all the memory was consumed.

MMS 2013: More data…

Over the course of the week, over 48,000 virtual machines were provisioned. This is ~8,000 more than last year. Here’s a quick chart. Please note that Friday is just a half day…

Average CPU Utilization across the entire pool of servers during labs hovered around 15%. Peaks were recorded a few times at ~20%. In short, even with thousands of Hyper-V VMs running on a 32 node cluster, we were barely taxing this well architected and balanced system.
While each blade was populated with 256 GB, they weren’t maxed. Each blade can take up to 384 GB.
Storage Admins: Disk queues for each of the hosts largely remained at 1.0 (1.0 is nirvana). When 3200 VMs were deployed simultaneously, the disk queue peaked at 1.3. Read that again. Show your storage admins. (No, those aren’t typos.)
The HP I/O Accelerators used were the 768 GB version and 1.2 TB versions. The only reason we used a mix of different sizes because that’s what we had available.
All I/O was configured for HA and redundancy.

Network adapters were teamed with Windows Server 2012 NIC Teaming
Storage was fibre channel and was configured with Active-Active Windows Server Multi-Path I/O (MPIO). None of it was needed, but it was all configured, tested and working perfectly.

During one of the busiest days at MMS 2013 with over 3500 VMs running simultaneously, this configuration wasn’t even breathing hard. It’s truly a sight to behold and a testament to how well this Microsoft/HP Private Cloud Solution delivers.

From a management perspective, System Center was the heart of the system providing health monitoring, ensuring consistent hardware configuration and providing the automation that makes a lab this complex successful. At its peak, with over 3500 virtual machines running, you simply can’t work at this scale without pervasive automation.

From a hardware standpoint, the HP BladeSystem and 3Par storage are simply exceptional. Even at peak load running 3500+ virtual machines, we weren’t taxing the system. Not even close. Furthermore, the fact that the HP BladeSystem and 3Par storage integrate with Operations Manager, Configuration Manager and Virtual Machine Manager provides incredible cohesion between systems management and hardware. When a disk unexpectedly died, we were notified and knew exactly where to look. From a performance perspective, the solution provides a comprehensive way to view the entire stack. From System Center we can monitor compute, storage, virtualization and most importantly the workloads running within the VMs. This is probably a good time for a reminder…

If you’re creating a virtualization or cloud infrastructure, the best platform for Microsoft Dynamics, Microsoft Exchange, Microsoft Lync, Microsoft SharePoint and Microsoft SQL Server is Microsoft Windows Server with Microsoft Hyper-V managed by Microsoft System Center. This is the best tested, best performing, most scalable solution and is supported end to end by Microsoft.

One More Thing...

Finally, I’ve been talking about Windows Server and System Center as part of our Microsoft Private Cloud Solution. I’d also like to point out that Windows Server 2012 Hyper-V is the same rock-solid, high performing and scalable hypervisor we use to power Windows Azure too.

Read that again.

That’s right. Windows Azure is powered by Windows Server 2012 Hyper-V. See you at TechEd.

Jeff Woolsey
Windows Server & Cloud

P.S. Hope to see you at the Hands on Lab at TechEd!

More pictures below…

Here’s a close up of one of the racks. This rack has one of the c7000 chassis with 16 nodes for Hyper-V. It also includes the two managements heads clustered used for System Center. At the bottom of the rack are the Uninterruptible Power Supplies.

…and here’s the back of one of the racks that held a c7000…

HP knew there was going to be a lot of interest, so they created full size cardboard replicas diagraming the hardware in use.

…and here’s one more…

XenDesktop 7 Supports Windows Server 2012

2013-05-23T16:00:00Z

We are excited to see the release of XenDesktop 7 and support our partner Citrix. XenDesktop 7 brings together both XenApp and XenDesktop functionality into a common release and now brings support for Windows Server 2012. XenDesktop can easily be deployed on Hyper-V and take full advantage of Windows Server 2012 to increase agility, reduce cost, and provide a scalable and robust platform for desktop virtualization.

Hyper-V Replica Capacity Planner

2013-05-23T05:06:35Z

Customers have frequently asked us for capacity planning guidance before deploying Hyper-V Replica – e.g.: “How much network bandwidth is required between the primary and replica site”, “How much storage is required on the primary and replica site”, “What is the storage impact by enabling multiple recovery points” etc.

The answer to the above and many other capacity planning questions is “It depends” – it depends on the workload, it depends on the IOPS headroom, it depends on the available storage etc. While one can monitor every single perfmon counter to make an informed decision, it is sometimes easier to have a readymade tool.

The Capacity Planner for Hyper-V Replica which was released on 5/22, allows you to plan your Hyper-V Replica deployment based on the workload, storage, network and server characteristics. The guidance is based on results gathered through our internal testing across different workloads.

You can download the tool and it’s documentation from here - http://www.microsoft.com/en-us/download/details.aspx?id=39057

Instructions:

1) Download the tool (exe) and documentation

2) Read the documentation first and then try out the tool. You should familiarize yourself with some nuances listed in the documentation before using the tool.

So go ahead, use the tool in your virtual infrastructure and share your feedback and questions through this blog post or in the community forum. We would love to hear your comments!

Resynchronization of virtual machines in Hyper-V Replica

2013-05-10T14:27:00Z

What is resynchronization and why is it needed?

Hyper-V Replica provides protection to VMs by tracking and replicating changes to the virtual hard disks (VHDs) of the VM. Hyper-V Replica runs 24 hours, 365 days in a year; for any VM that has been enabled for replication it ensures that the data on the primary site and the Replica site are kept as closely in sync as supported.

To begin with, Hyper-V Replica (HVR) requires that the data on the virtual hard disks (VHDs) of the primary and replica VMs be the same. This is achieved through the process of initial replication, and establishes a baseline on which replicated changes can be applied. However, due to factors beyond the control of the administrator – such as faulty hardware and OS bugchecks – it is possible that the primary and Replica VMs are not in sync.

Thus in a rainy day scenario (details in following section), when HVR determines that the replica VM can no longer be kept in sync with the primary by applying the replicated changes then resynchronization is required. Resynchronization (or Resync) is the process of re-establishing the baseline – by ensuring that the primary and replica VHDs have exactly the same data stored.

(NOTE: In this post we will use a VM named “RESYNC VM” in all examples and screenshots.)

When does resynchronization happen?

It would become quite obvious after going through this table below that Resync is not expected to occur regularly. In fact, in the normal course of replication this is quite a rare event. The VM enters the “Resynchronization Required” state when any one of the conditions are encountered:

Site	Condition	Scenario example
Primary	Modify VHD when VM is turned off	Mount/modify VHD outside the VM, Edit disk, Offline patching
Primary	Size of tracking log files > 50% of total VHD size for a VM	Network outage causes logs to accumulate
Primary	Write failure to tracking log file	VHD and logs are on SMB and connectivity to the SMB storage is flaky.
Primary	Tracking log file is not closed gracefully	Host crash with primary VM running. Applicable to VMs in a cluster also.
Primary	Reverting the volume to an older point in time Reverting the VM to an older snapshot	Volume/snapshot backup and restore
Secondary	Out-of-sequence or Invalid log file is applied	Restoring a backed-up copy of the Replica VM Importing an older VM copy, when migration by using export-import Reverting volume to an older point in time using Volume backup and restore. Reverting the VM to an older snapshot

When the VM enters the “Resynchronization Required” state, the replication health becomes “Critical” and the VM is scheduled for resynchronization. At the same time, HVR stops tracking the guest writes for the VM and nothing is replicated.

The replication health will also show this message:

Initiating and scheduling resynchronization

Depending on the VM setting, the user might have to trigger the resynchronization operation explicitly. When that is required, follow the instructions as given in the replication health screen:

Right-click on the VM for the options
Under Replication, select the Resume Replication option

You will be presented with the screen to schedule the resynchronization operation:

To start the resync operation from PowerShell, use the Resume-VMReplication commandlet:

     Resume-VMReplication –VMName “RESYNC VM” -Resynchronize –ResynchronizeStartTime “04/15/2013 12:00:00”

User-initiated resynchronization is also possible, but unless absolutely necessary it should be avoided. In order to explicitly force resynchronization on a VM that is not in the “Resynchronization Required” state, first suspend the replication and then initiate resync:

    Suspend-VMReplication -VMName "RESYNC VM"

    Resume-VMReplication -VMName "RESYNC VM" -Resynchronize

The scheduling of the resynchronization operation can be configured for each VM:

On the primary site, open the Hyper-V Manager
Right-click on the desired VM, and select the Settings… option
In the left hand pane under Replication, select the Resynchronization option

The default option is to schedule the resynchronization operation during off-peak hours. The resource intensive nature of the operation makes such scheduling useful, and aims to reduce the impact on running VMs.

The same can be configured in PowerShell using the Set-VMReplication commandlet:

    # Manual resync

    Set-VMReplication -VMName "RESYNC VM" -AutoResynchronizeEnabled 0

    # Automatic resync

    Set-VMReplication –VMName "RESYNC VM" -AutoResynchronizeEnabled 1 -AutoResynchronizeIntervalStart 00:00:00 -AutoResynchronizeIntervalEnd 23:59:59

    # Scheduled resync

    Set-VMReplication –VMName "RESYNC VM" -AutoResynchronizeEnabled 1 -AutoResynchronizeIntervalStart 00:00:00 -AutoResynchronizeIntervalEnd 06:00:00

To see the resynchronization settings in PowerShell, use the Get-VMReplication commandlet and look for the AutoResynchronizeEnabled, AutoResynchronizeIntervalStart, and AutoResynchronizeIntervalEnd fields:

    Get-VMReplication -VMname "RESYNC VM" | fl *

The process of resynchronization

When the resync operation is triggered – either automatically or by the user – the following high-level sub-operations are executed in sequence:

Check the VHD characteristics of primary and replica VMs: before resync can be done, these have to match. Hyper-V Replica checks the geometry and size of the disk before starting resync. Top on the list of exceptions to watch out for are size mismatches – caused by resizing either a primary or replica VHD without appropriately resizing the other one.
Start tracking the VHDs:

The guest writes are tracked into the log file, but these changes are not replicated until resync is completed.
It is important to note that if resync takes too long then you might hit the “50% of total VHD size for a VM” condition and end up sending the VM into the “Resynchronization Required” state again.
Event number 29242 is logged that specifies the VM, VHDs, start block, and end block.

Create a diff disks for the replica VHDs: this allows the resync operation to be cancelled without leaving the underlying VHD in an inconsistent state. The diff disk with all the resync-ed changes is then merged back into the VHD at the end of the resync operation.
Compare and sync the VHDs: the comparison of the VHDs is done block-by-block and only the blocks that differ are sent across the network. This can reduce the data sent over the network, depending on how different the two VHDs are. While this operation is going on:

Pause Replication will stop the current resync operation. Doing Resume Replication later will continue the resync comparisons from where it left off.
Planned failover or Test failover will not be possible.
At any point the user can always do Unplanned Failover, but this will cancel the resync operation.
Resync can be cancelled at any point. This will keep the VM in the “Resynchronization Required” state, and the next time replication is resumed, it will start from the beginning.

Completion of compare and sync: HVR logs event number 29244 once the compare and sync operation is done, and it specifies the VHD, VM, blocks sent, time taken, and result of the operation.
Merge the resync changes to the VHD: after this operation completes, the resync operation cannot be cancelled or undone.
Delete the recovery points: this is a significant side-effect of resync. The recovery points are built upon the VHD as a baseline. However, resync effectively changes that baseline and makes the data stored in those recovery points invalid. After resync completes, the recovery points are built again over a period of time.

Resynchronization performance

Resynchronization performance was tested and compared against the performance of Online Initial Replication (IR). The setup consisted of a standalone server with 4 running VMs – 2 File Servers and 2 SQL servers running typical workloads. Two VMs were replicated to a standalone Replica server. The network bandwidth was varied to see the impact. Data size that was replicated during Online IR was approximately 80GB.

	Network speed	Online IR size	Online IR time	Resync size	Resync time
Resync – offline scheduling	1 Gbps	~80 GB	~1.5 hrs	~5.5 GB	~2 hrs
Resync – immediate	1 Gbps	~80 GB	~1 hr	~100 MB	~1 hr

Resync – offline scheduling	1.5 Mbps	~80 GB	4 days	~10 GB	~1 day
Resync – immediate	1.5 Mbps	~80 GB	4 days	~ 78 MB	~1 hour

The tests indicate that resync is preferable to Online IR in low speed networks. When the two sites are connected by a high speed network, resync works well for low churn workloads.

There is also a perfmon counter for measuring the resynchronized bytes: \Hyper-V Replica VM\Resynchronized Bytes.

Conclusion

The disks going out of sync is a rainy-day event in Hyper-V Replica. However with the Resynchronization operation, this is handled gracefully within the product to optimize the administrative overhead and the resources used in bringing the disks back into sync.

How to install integration services when the virtual machine is not running

2013-04-19T00:34:00Z

We’ve been talking to a lot of people about deploying integration services (integration components) lately. As it turns out, they’re pretty easy to patch offline with existing Hyper-V tools.

First, why would you update integration services on a not-running (offline) VM?

Offline VM servicing is valuable for VM templates places that create new VMs frequently since it allows you to keep VM templates up-to-date. While this post targets exclusively integration service updates, the same update approach applies to many updates as well as any configurations specific to the environment. Keeping the VM images fully up to date and configured before they are deployed saves significant setup time and support every time a new VM is created.

Here is a detailed write-up about deploying and updating integration services on an offline VM – both VHD/VHDX – using out of box PowerShell tools and a cab (cabinet) file that comes bundled with Server 2008 or later Hyper-V hosts.

Before you start, open a PowerShell console as administrator. Make sure Hyper-V is installed and you’re working from the management (host) OS. The management OS must be Server 2008R2 or newer and more recent than the VM OS you’re patching. I tested this script with a Server 2012 host.

For default Hyper-V installs, the CAB containing the up-to-date integration components will be located in [HostDrive]:\windows\vmguest\support. From there, choose your architecture; for my machine, I choose amd64. X86 people, you’re files are there too. This file contains all of the components built into the VM Guest ISO. To update integration components offline, we’re only interested in the two cab files highlighted below.

There will be two files:

Windows6.x-HyperVIntegrationServices-x64.cab corresponds with Windows 7 and earlier guests. Tested: Server 2008 R2, Windows 7 (enterprise and enterprise sp1).
Windows6.2-HyperVIntegrationServices-x64.cab corresponds with windows 8 and Server 2012 guests. Tested: Server 2012, Windows 8.

Note: this process only works for Windows 2008R2 / Windows 7 and later operating systems. It works with both vhd and vhdx files.

You will need the path to this file. From here on out I’ll refer to it as $integrationServicesCabPath. If you pick the wrong one it will fail a version check without harming the guest.

$integrationServicesCabPath="C:\Windows\vmguest\support\amd64\Windows6.2-HyperVIntegrationServices-x64.cab"

The next step is to apply the cab to the offline VM.

First, you’ll need the path to your VM image, I’m going to refer to this as $virtualHardDiskToUpdate.

$virtualHardDiskToUpdate="D:\client_professional_en-us_vl.vhd"

Next, mount the image as a pass-through disk (unprotected data and direct I/O) and keep track of the disk number returned.

$diskNo=(Mount-VHD -Path $ virtualHardDiskToUpdate –Passthru).DiskNumber

Check to make sure the operational status is online and find the drive letter so we know which drive to patch.

(Get-Disk $diskNo).OperationalStatus

$driveLetter=(Get-Disk $diskNo | Get-Partition | Get-Volume).DriveLetter

In my case this returned “online” and “E” (stored in $driveLetter). If you mounted a VM with Windows fully installed, the chances are good it’ll mount more than one drive depending on the VMs particular setup. If this is the case, find the drive with all of the Windows OS files – apply the integration service update to that one. If the status returns not online prepare the image by running:

Set-Disk $diskNo -IsOffline:$false -IsReadOnly:$false

Now the mounted VHD is ready to be patched.

Add-WindowsPackage -PackagePath $integrationServicesCabPath -Path ($driveLetter+":\")

You should see a blue progress bar at the top of PowerShell. Enjoy watching the little yellow o’s fill your screen. If the cab couldn’t apply, make sure you’re using the right version for your guest OS and the right drive. If the VM is running, it will not patch.

Finally, dismount the VHD. Notice you dismount using the image path and not the mounted drive letter.

Dismount-VHD -Path $virtualHardDiskToUpdate

Here’s a more reasonable, consolidated, PowerShell Script:

$virtualHardDiskToUpdate="D:\client_professional_en-us_vl.vhd"
$integrationServicesCabPath="C:\Windows\vmguest\support\amd64\Windows6.2-HyperVIntegrationServices-x64.cab"

#Mount the VHD
$diskNo=(Mount-VHD -Path $virtualHardDiskToUpdate –Passthru).DiskNumber

#Get the driver letter associated with the mounted VHD, note this assumes it only has one partition if there are more use the one with OS bits
$driveLetter=(Get-Disk $diskNo | Get-Partition).DriveLetter

#Check to see if the disk is online if it is not online it
if ((Get-Disk $diskNo).OperationalStatus -ne 'Online')
{Set-Disk $MountedVHD.Number -IsOffline:$false -IsReadOnly:$false}

#Install the patch
Add-WindowsPackage-PackagePath $integrationServicesCabPath -Path ($driveLetter + ":\")

#Dismount the VHD
Dismount-VHD-Path $virtualHardDiskToUpdate

Thank you to Taylor Brown (http://blogs.msdn.com/b/taylorb), for the script!

Cheers,
Sarah Cooley

Updates for Hyper-V

2013-04-16T07:20:00Z

A new article has appeared on the TechNet Wiki that provides a complete list of updates for Hyper-V on Windows Server 2012:

http://social.technet.microsoft.com/wiki/contents/articles/15576.hyper-v-update-list-for-windows-server-2012.aspx

I am really happy to see this online, as we have received lots of positive feedback about how useful the existing documentation is for updates that are available for Hyper-V on Windows Server 2008 R2 and on Windows Server 2008. Hopefully this will help everyone in planning and managing their Hyper-V deployments.

Cheers,
Ben

Hyper-V Replica Certificate Based Authentication - makecert

2013-04-13T10:01:38Z

We have had a number of queries on how to enable replication using certificates created from makecert. Though the Understanding and Troubleshooting guide for Hyper-V Replica discusses this aspect, I am posting a separate article on this. The below steps are applicable for a simple lab deployment consisting of two standalone servers – PrimaryServer.domain.com and ReplicaServer.domain.com. This can be easily extended to clustered deployments with the Hyper-V Replica Broker.

Makecert is a certificate creation tool which generates certificates for testing purpose. Information on makecert is available here - http://msdn.microsoft.com/en-us/library/bfsktky3.aspx.

1. Copy the makecert.exe tool to your primary server

2. Run the following command from an elevated command prompt, on the primary server. This command creates a self-signed root authority certificate. The command also installs a test certificate in the root store of the local machine and is saved as a file locally

     makecert -pe -n "CN=MyTestRootCA" -ss root -sr LocalMachine -sky signature -r "MyTestRootCA.cer" 

3. Run the following command couple of times, from an elevated command prompt to create new certificate(s) signed by the test root authority certificate

    makecert -pe -n "CN=<FQDN>" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "MyTestRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 <MachineName>.cer 

Each time:

Replace <FQDN> with FQDN of primary and replica servers

Replace <MachineName>.cer with any name

The command installs a test certificate in the Personal store of the local machine and is saved as a file locally. The certificate can be used for both Client and Server authentication

4. The certificates can be viewed by mmc->File->Add/Remove Snap in…->Certificates->Add->”Computer Account”->Next->Finish->Ok

You will find the Personal certificate (with the machine names) and the Root certificate (MyTestRootCA) in the highlighted folders:

5. Export the replica server certificate with the private key.

6. Copy MyTestRootCA.cer and the above exported certificate (RecoveryServer.pfx) to the Replica server.

7. Run the following command from an elevated prompt in ReplicaServer.domain.com

    certutil -addstore -f Root "MyTestRootCA.cer" 

8. Open the certificate mmc in ReplicaServer.domain.com and import the certificate (RecoveryServer.pfx) in the Personal store of the server. Provide the pfx file and password as input:

9. By default, a certificate revocation check is mandatory and Self-Signed Certificates don’t support Revocation checks. To work around it, modify the following registry key on Primary, Replica Servers

    reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

Hyper-V Replica - Name Resolution of Internationalized Server/Domain names

2013-04-08T06:05:00Z

In a mixed language environment where the server name or domain name contains international characters, you might encounter an error at the time of enabling replication. The event viewer messages will tell you that “Hyper-V failed to enable replication for virtual machine” and “The server name or address could not be resolved (0x00002EE7)”. The problem could seem a little perplexing because pinging the same FQDN might work just fine. The problem occurs because of Hyper-V Replica’s dependency on HTTP.

To work around the issue, an exception rule needs to be added to the primary server’s name resolution policies. Follow these steps to create the rule:

Open the Local Group Policy Editor (Gpedit.msc).
Under Local Computer Policy, expand Computer Configuration, Windows Settings, and then click Name Resolution Policy.
In the Create Rules area, click FQDN, and then enter the Replica server FQDN that was failing.
On the Encoding tab, select the Enable Encoding check box, and make sure that UTF-8 with Mapping is selected.
Click Create.

The rule appears in the Name Resolution Policy Table.
Click Apply, and then close the Local Group Policy Editor.
From an elevated command prompt, run the command gpupdate to update the policy.

Multi-tenant disaster recover solution using Windows Server 2012

2013-04-01T19:54:00Z

Windows Server 2012 introduces fundamental improvements that make it a cloud-ready operating system. The capabilities provide a flexible and scalable solution which opens up a wide range of opportunities for hosting providers to build new cloud services.

This blog post is co-authored by Uma Mahesh, Senior Program Manager and Yigal Edery, Principal Program Manager in the Windows Server division. The blog article is based on Yigal’s TechEd talk on “Building Hosted Public and Private Clouds Using Windows Server 2012”

In this post, Contoso.com, a Washington DC based fictitious company, replicates its business critical VMs to a hosting provider offering DR as a cloud service. This article describes integration between different Windows Server 2012 features to enable a complete end to end service which hosting providers (or ‘hoster’) can offer. It uses Hyper-V Replica, Network Virtualization and Remote Access (including both site-to-site (S2S) VPN & DirectAccess), which enables a hoster to build a complete, multi-tenant disaster recover (DR) service, using Windows Server 2012.

The technology building blocks are:

Hyper-V Replica: Hyper-V Replica in Windows Server 2012 allows you to replicate multiple VMs from different tenants on single physical host.
Hyper-V Network Virtualization: Hyper-V Network Virtualization allows a multiple tenant virtual networks with overlapping IP address space to be created on the same hoster physical network yet providing isolation between tenant network. A replicated VM of a tenant can be brought live in a dedicated virtual network for the tenant in the hosting provider’s physical network.
Site-to-Site VPN support: Using the S2S VPN solution which is available in Windows Server 2012 (which includes support for S2S VPN over IPsec), tenants can connect to their respective virtual network in the hoster premises.
DirectAccess with multi-pathing: Multi-Pathing enables employees of each tenants to connect to the on-premises DA under normal operations. If the replicated VMs are brought up in the hosting provider premises (say, due to a disaster in the tenant’s site), employees smoothly failover to the hoster DA server and through it to the replicated VMs in their respective virtual network with the hoster.

In this article, we will demonstrate the steps required to set up a deployment to replicate a mission critical app (which is hosted in a VM) from the customers premise to a hoster. When a disaster strikes the customer premises, the administrator fails over to the replicated VM (on the hosting provider premises) which comes up with the same IP address. Clients using DA can seamlessly be routed to the service that’s currently up and running in the hosting provider premises.

The topology is as follows:

Contoso.com’s Washington site consists of an:

Edge Gateway (EDGE1) is a Windows Server 2012 VM in which Remote Access is configured. EDGE1 connects to Internet via a NIC (131.107.0.2) which connects to the Internet Router (131.107.0.1). It also connects to rest of Contoso’s corporate network (10.0.0.0/24) via another NIC (10.0.0.2, 2001:db8:dc::1)
Domain controller DC1 (10.0.0.1, 2001:db8:dc::1)
Applications server APP1 ((10.0.0.1, 2001:db8:dc::1) run as VMs on another WS2012 Hyper-v Server (ContosoP1 – also referred to as the “Primary Server”). Hyper-V Replica is enabled on this (APP1) VM and the VM is replicated to a Windows Server 2012 Hyper-V server on the hosting provide premises (HosterR1 – also referred to as the “Replica Server”) .

Client:

Client1 is a client VM of Contoso that is connected to Internet (131.107.0.200)
DA is configured on Client1 which ensures that it can connect to Contoso’s corporate network and access applications like APP1. Client1 is not concerned whether APP1 is physically present in Washington site or in hoster network as it accesses the application by it’s name app1.corp.contoso.com using DireactAccess. Furthermore, it can connect to DA server in the enterprise viz, EDGE1 or connect to DA server of Contoso at the hoster premises 3-DAS1. If connectivity to any DA server is lost, the DA connection automatically reconnects to other active DA server.

Hosting Provider:

HosterGW, which is running on Windows Server 2012, is connected to “Internet” (131.107.0.101). The hoster’s internal network is 192.168.1.101.
NAT is enabled on HosterGW so that applications/services (like Hyper-V Replica ) on hoster internal network (eg:HosterR1 ,192.168.1.101) are available over Internet. HosterR1 can host VMs directly created on it or replicated to it using Hyper-v Replica.
HosterGW machine hosts GW VMs per tenant so that the hoster can provide connectivity between the tenant’s virtual network and tenant’s on-prem network. In this topology, ContosoCloudGW VM is the S2S VPN GW for Contoso. This VM connects the contoso virtual network at hoster to the contoso corporate network. Hyper-V Network Virtualization is used to create the Contoso’s virtual network of 10.0.0.0/24, 10.6.0.0/24, 2001:db8:dc::/48 and 2001:db8:dc::/48 (collectively called the Customer Address space or CA) over the hoster’s address space 192.168.1.0/24 (called Provider Address space or PA).

Building the above deployment

Step 1: Building Contoso’s environment

This step is similar to creating the base environment for DA. The test lab guide which demonstrates Direct Access single server setup has detailed steps on creating the environment. Once the steps are completed, you will have a setup where Client1 from Internet (directly connected or behind NAT) can access APP1 over Direct Access as shown in the below diagram.

Step 2: Building Hosters’s environment

The objectives of the hosting provider are:

Allow Contoso.com to bring VMs with an IP of their choice
Connect Contoso VMs back to their on-prem network.
Allow customers to replicate their on-prem VMs to the hosting provider

2a) Steps required to “bring your own IP address”

Hyper-V Network Virtualization (HNV) allows Contoso to bring VMs with an IP address to the hoster. The following cmdlets demonstrate how HNV can be deployed on two hosts viz., HosterGW & HosterR1.

In this example, HosterGW has two NICs one connected to “Internet” (131.107.0.101) and once connected to hoster internal network (192.168.1.101). HosterR1 has one NIC connected to hoster internal network(192.168.1.111). The following PS cmdlets need to be run on both HosterGW and HosterR1 to configure HNV.

# Rename the NIC connected to internal network  as  “WnvNIC” and run the following cmdlets

$WnvNIC   = "WnvNIC"

$WnvDRV   = "ms_netwnv"

Disable-NetAdapterBinding $WnvNIC -ComponentID $WnvDRV

Enable-NetAdapterBinding  $WnvNIC -ComponentID $WnvDRV

# Run the following cmdlets to enable Contoso virtual network

# ContosoCloudGW 10.6.0.2

New-NetVirtualizationLookupRecord -CustomerAddress "10.6.0.2"        -ProviderAddress "192.168.1.101" -VirtualSubnetID "5001" -MACAddress "00155d05df03" -Rule "TranslationMethodEncap" -VMName "ContosoCloudGW-v4"

New-NetVirtualizationLookupRecord -CustomerAddress "0.0.0.0"         -ProviderAddress "192.168.1.101" -VirtualSubnetID "5001" -MACAddress "00155d05df03" -Rule "TranslationMethodEncap" -VMName "wildcard v4"

New-NetVirtualizationLookupRecord -CustomerAddress "2001:db8:ba::2"  -ProviderAddress "192.168.1.101" -VirtualSubnetID "5001" -MACAddress "00155d05df03" -Rule "TranslationMethodEncap" -VMName "ContosoCloudGW-v6"

New-NetVirtualizationLookupRecord -CustomerAddress "::"              -ProviderAddress "192.168.1.101" -VirtualSubnetID "5001" -MACAddress "00155d05df03" -Rule "TranslationMethodEncap" -VMName "wildcard v6"

#ContosoCloudDAServer

New-NetVirtualizationLookupRecord -CustomerAddress "10.6.0.6"        -ProviderAddress "192.168.1.111" -VirtualSubnetID "5001" -MACAddress "00155d059701" -Rule "TranslationMethodEncap" -VMName "ContosoCloudDAServer-v4"

New-NetVirtualizationLookupRecord -CustomerAddress "0.0.0.0"         -ProviderAddress "192.168.1.111" -VirtualSubnetID "5001" -MACAddress "00155d059701" -Rule "TranslationMethodEncap" -VMName "wildcard v4"

New-NetVirtualizationLookupRecord -CustomerAddress "2001:db8:ba::6"  -ProviderAddress "192.168.1.111" -VirtualSubnetID "5001" -MACAddress "00155d059701" -Rule "TranslationMethodEncap" -VMName "ContosoCloudDAServer-v6"

New-NetVirtualizationLookupRecord -CustomerAddress "::"              -ProviderAddress "192.168.1.111" -VirtualSubnetID "5001" -MACAddress "00155d059701" -Rule "TranslationMethodEncap" -VMName "wildcard v6"

#ContosoCloudDC

New-NetVirtualizationLookupRecord -CustomerAddress "10.6.0.3"        -ProviderAddress "192.168.1.111" -VirtualSubnetID "5001" -MACAddress "00155d059700" -Rule "TranslationMethodEncap" -VMName "ContosoCloudDC-v4"

New-NetVirtualizationLookupRecord -CustomerAddress "2001:db8:ba::3"  -ProviderAddress "192.168.1.111" -VirtualSubnetID "5001" -MACAddress "00155d059700" -Rule "TranslationMethodEncap" -VMName "ContosoCloudDC-v6"

#Customer Routes for VSID 5001

New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000005001}" -VirtualSubnetID "5001" -DestinationPrefix "10.6.0.0/24" -NextHop "0.0.0.0"  -Metric 255 

New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000005001}" -VirtualSubnetID "5001" -DestinationPrefix "0.0.0.0/0"   -NextHop "10.6.0.2" -Metric 255 

#New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000005001}" -VirtualSubnetID "5001" -DestinationPrefix "10.0.0.0/24" -NextHop "10.6.0.2" -Metric 255 

#New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000005001}" -VirtualSubnetID "5001" -DestinationPrefix "10.2.0.0/24" -NextHop "10.6.0.2" -Metric 255 

New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000005001}" -VirtualSubnetID "5001" -DestinationPrefix "2001:db8:ba::/48" -NextHop "::"  -Metric 255 

New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000005001}" -VirtualSubnetID "5001" -DestinationPrefix "2001:db8:dc::/48" -NextHop "2001:db8:ba::2" -Metric 255 

New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000005001}" -VirtualSubnetID "5001" -DestinationPrefix "2001:db8:fa::/48" -NextHop "2001:db8:ba::2" -Metric 255 

New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000005001}" -VirtualSubnetID "5001" -DestinationPrefix "2001:db8:ba:1000::/64" -NextHop "2001:db8:ba::6"  -Metric 255 

#App1

New-NetVirtualizationLookupRecord -CustomerAddress "10.0.0.80"       -ProviderAddress "192.168.1.111" -VirtualSubnetID "5002" -MACAddress "00155db1c505" -Rule "TranslationMethodEncap" -VMName "APP1-v4"

New-NetVirtualizationLookupRecord -CustomerAddress "2001:db8:dc::80" -ProviderAddress "192.168.1.111" -VirtualSubnetID "5002" -MACAddress "00155db1c505" -Rule "TranslationMethodEncap" -VMName "APP1-v6"  

*Replace the MAC addrersses  if required

On the HosterGW, run the following cmdlets:

$iface = Get-NetAdapter $WnvNIC

New-NetVirtualizationProviderAddress -InterfaceIndex $iface.InterfaceIndex -ProviderAddress "192.168.1.101" -PrefixLength 24 

# Make sure the adapter name is correct  Rename-VMNetworkAdapter -vmname ContosoCloudGW -Name "Network Adapter" -NewName "Wnv-CA-NIC"

Set-VMNetworkAdapter "ContosoCloudGW"   -Name "Wnv-CA-NIC" -VirtualSubnetID 5001;

Get-VMNetworkAdapter "ContosoCloudGW" | where {$_.MacAddress -eq "808080808002"} | Set-VMNetworkAdapter -VirtualSubnetID 5002

On HosterR1, run the following cmdlets:

$iface = Get-NetAdapter $WnvNIC 

New-NetVirtualizationProviderAddress -InterfaceIndex $iface.InterfaceIndex -ProviderAddress "192.168.1.111" -PrefixLength 24 

New-NetVirtualizationProviderRoute -InterfaceIndex $iface.ifIndex -DestinationPrefix "0.0.0.0/0" -NextHop "192.168.1.101"

# Make sure the adapter name is correct 

Rename-VMNetworkAdapter -vmname ContosoCloudDAServer -Name "Network Adapter" -NewName "Wnv-CA-NIC"

Set-VMNetworkAdapter "ContosoCloudDAServer" -Name "Wnv-CA-NIC" -VirtualSubnetID 5001;

# Make sure the adapter name is correct 

Rename-VMNetworkAdapter -vmname 3-APP1 -Name "WnvNic" -NewName "Wnv-CA-NIC"

Get-VMNetworkAdapter "ContosoCloudDC" | where {$_.MacAddress -eq "00155d059700"} | Set-VMNetworkAdapter -VirtualSubnetID 5001

Set-VMNetworkAdapter App1 -Name "Private Corpnet" -VirtualSubnetID 5002 –Passthru

Step 2b: Connect Contoso VMs back to their on-prem network.

While the above steps create the necessary network infrastructure to create Contoso virtual network the following steps are required to create the VMs and ensure that the VMs are able to connect to Contoso on-prem network.

On HosterGW:

Create a Windows Server 2012 VM ContosoCloudGW with 2 VM NICs
Connect one VM NIC to the V-Switch connecting to Internet NIC (131.107.0.101) and another VM NIC to V-switch connecting to Internal NIC.
Configure MAC address of internal VM NIC as 00155d05df03
Configure the following IP address scheme:

Assign IPv4 address 10.6.0.2/24 &2001:db8:6::2/64 to NIC connected to internal NI

Create site-to-site VPN connections between ContosoCloudGw & EDGE1 using the following cmdlets

ipmo servermanger 

add-windowsFeature -name routing -IncludeManagementTools 

ipmo remoteaccess 

install-remoteaccess -vpntype vpns2s –IPv6Prefix 2001:db8:6:200::/64 -IPAddressRange ("10.6.0.200","10.6.0.210") 

Add-VpnS2SInterface EDGE1 131.107.0.2 -Protocol IKEv2  -AuthenticationMethod PSKOnly -SharedSecret abc -IPv4Subnet10.2.0.0/24:100 –IPv6Subnet2001:db8:2::/48:100 

##On EDGE1  : 

Add-VpnS2SInterface 3-EDGE1 131.107.0.30 -Protocol IKEv2  -AuthenticationMethod PSKOnly -SharedSecret abc -IPv4Subnet 

10.6.0.0/24:100 –IPv6Subnet 2001:db8:6::/48:100

The above steps ensure that VMs of Contoso hosted @ the hoster are accessible from Contoso Washington site and Internet Via DirectAccesss from EDGE1.

Step 2c: Configure Hyper-V Replica

This replica server is ‘published’ using the hoster’s GW via regular HTTPS (customers use cert-based authentication to replicate).

The following links illustrate on how to achieve this:

Create certificates using makecert – Appendix C of the Understanding and Troubleshooting guide for Hyper-V Replica
(or) Create certificates from a standalone CA
(or) Create certificates from an Enterprise CA
Setup replication for the virtual machine using the certificate based authentication.

Since EDGE1 is acting as DA server it will not allow any non-IPsec traffic thru it. In general customer deployment there would be an IPS device in front of EDGE1. In the above topology to allow HTTPS HVR traffic thru EDGE1, we need to disable IPsec dosp with the following cmdlet

netsh ipsecdosprotection set miscellaneous defaultblock=disable

As Hyper-V Replica takes on the end-server name (not IP address) as input, you could resolve the server name by making an entry in the host file of ContosP1. To achieve this, add an entry in %systemdrive%\drivers\etc\hosts

131.107.0.101 HosterR1

Similarly on HosterR1, add the following entry in hosts file

131.107.0.101 ContosP1

Step 3: Configuring Cloud DA site on top of Hyper-v Network Virtualization:

Now that we have ensured the the VMs are replicated to the hoster we need to provide and option to Contoso employees to connect to their replicated VMs from Internet even if Washington DA server is not available. This is done by deploying a DA server in Contoso cloud. Since DA in WS 2012 supports multiple DA sites, all that’s required here is to enable a new Cloud DA entry point. Following diagram describes the topology.

Here are the steps to configure DA cloud site:

Configure NAT on 3-EDG1

Open rrasmgmt.msc
Right click on IPv4 general node

3. Click new Routing Protocol…

4. Select NAT

5. Right click on NAT node.

6. Select New Interface.

7. Select the interface connected to Internet.

8. In NAT tab, select Public Interface connected to private network and check “Enable NAT on this interface” option.

9. Select services and ports tab, select “Secure web server (HTTPS) option

Enter the IP address of 3-DAS1, 10.6.0.6 in Private address.

Configure 3-DAS1

Configure IP address 10.6.0.6/24 (default route 10.6.0.2) & 2001:db8:2::/64 (default route 2001:db8:6::/64) with DNS server as 10.0.0.1/24, 10.2.0.1/24 & 2001:db8:1::1/64, 2001:db8:2::1/64 respectively.

1. In the Server Manager console, click Local Server, and then in the Properties area, next to Avez-CA-NIC , click the link.

2. Right-click Avez-CA-NIC, and then click Properties.

3. Click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.

4. Click Use the following IP address. In IP address, type 10.6.0.6, in Subnet mask, type 255.255.255.0.

5. Click Use the following DNS server addresses. In Preferred DNS server, type 10.0.0.1, and in Alternate DNS server, type 10.2.0.1.

6. Click Advanced, and then click the DNS tab.

7. In DNS suffix for this connection, type corp.contoso.com, and then click OK twice.

8. Click Internet Protocol Version 6 (TCP/IPv6), and then click Properties.

9. Click Use the following IPv6 address. In IPv6 address, type 2001:db8:6::6, in Subnet prefix length, type 64. Click Use the following DNS server addresses, and in Preferred DNS server, type 2001:db8:1::1, in Alternate DNS server, type 2001:db8:2::1

10. Click Advanced, and then click the DNS tab.

12. In DNS suffix for this connection, type corp.contoso.com, and then click OK twice.

13. On the 2-Corpnet Properties dialog box, click Close.

Join 3-DAS1 to corp.contoso.com.. Configure 3-DAS1 as 3^rd entry point (similar to step 12).

Obtain certificates on 3-DAS1

1. Click Start, type mmc, and then press ENTER.

2. In the MMC console, on the File menu, click Add/Remove Snap-in.

3. On the Add or Remove Snap-ins dialog box, click Certificates, click Add, click Computer account, click Next, click Local computer, click Finish, and then click OK.

4. In the console tree of the Certificates snap-in, open Certificates (Local Computer)\Personal.

5. Right-click Personal, point to All Tasks, and then click Request New Certificate.

6. Click Next twice.

7. On the Request Certificates page, select the Client-Server Authentication and the Web Server 2008 check boxes, and then click More information is required to enroll for this certificate.

8. On the Certificate Properties dialog box, on the Subject tab, in the Subject name area, in Type, select Common name.

9. In Value, type 3-DAS1.contoso.com, and then click Add.

10. In the Alternative name area, in Type, select DNS.

11. In Value, enter 3-DAS1.contoso.com, and then click Add.

12. On the General tab, in Friendly name, type IP-HTTPS Certificate.

13. Click OK, click Enroll, and then click Finish.

14. In the details pane of the Certificates snap-in, verify that new certificates with the names 3-DAS1.contoso.com and nls.corp.contoso.com were enrolled with Intended Purposes of Server Authentication, and a new certificate with the name 3-DAS1.corp2.corp.contoso.com was enrolled with Intended Purposes of Client Authentication and Server Authentication.

15. Close the console window. If you are prompted to save settings, click No.

Install the Remote Access role on 3-DAS1

1. Click Start, click Server Manager, and in the Dashboard, click add roles.

2. Click Next three times to get to the server role selection screen.

3. On the Select Server Roles dialog, select Remote Access, click Add Required Features, and then click Next.

4. On the Select features dialog, expand Remote Server Administration Tools, expand Role Administration Tools, and then select Remote Access Management Tools, and then click Next.

5. Click Next four times.

6. On the Confirm installation selections dialog, click Install.

7. On the Installation progress dialog, verify that the installation was successful, and then click Close.

To add 3-DAS1 as third entry-point

1. In the Remote Access Management Console of Edge-1, in the Tasks pane, click Add an Entry Point.

2. In the Add an Entry Point Wizard, on the Entry Point Details page, in Remote Access server, type 3-DAS1.corp.contoso.com, in Entry point name, type 3-Edge1-Site, and then click Next.

3. On the Network Topology page, click Behind NAT, and then click Next.

4. On the Network Name/IP Address page, in Type the public name or IP address to which remote access clients connect, type 3-Das1.contoso.com, and then click Next.

5. On the Network Adapters page, make sure that the External adapter is Internet, and the Internal adapter is 2-Corpnet, and then click Next.

6. On the Prefix Configuration page, in IPv6 prefix assigned to client computers, type 2001:db8:2:2000::/64, and then click Next.

7. On the Client Support page, click Allow client computers running Windows 7 to access this entry point, and click Add.

8. On the Select Groups dialog box, in Enter the object names to select, type Win7_Clients_Site2, click OK, and then click Next.

9. On the Client GPO Settings page, click Next.

10. On the Server GPO Settings page, click Next.

11. On the Network Location Server page, click Browse. On the Windows Security dialog box, click the nls.corp.contoso.com certificate, click OK, and then click Next.

12. On the Summary page click Commit.

13. On the Applying Server Configuration dialog box, click Close and then on the Add an Entry Point Wizard, click Close.

14. Manually Add subnet 20.6.0/24 & 2001:db8:6::/48 in AD site on DC1.

Open Active Directory sites and serices UI from Server Manger on DC1:

Configure 3-DC1:

Deploy 3-DC1 as replica DC VM . Configure IP address 10.6.0.3/24 & 2001:db8:6::3/64 with DNS server as 10.0.0.1/24 & 2001:db8:1::1/64 respectively. Join 3-DC1 to corp.contoso.com.

Now employees of Contoso could connect to either EDGE1 or 3-DAS1 via DirectAccess and access VMs in Washington site or VMs hosted in Contoso virtual network @ hoster.

In case of a disaster at Washington site, managed machines (laptops) of Contoso connect to 3-DAS1, DirectAccess Server hosted in Contoso virtual network @ hoster and access application VMs like APP1 that are recovered using Hyper-V Replica.

Step 5: Validating Disaster Recover as a service

The Hoster infrastructure in place to replicate the apps. In our case, Hyper-V server is also running a per-customer DA server and domain controller.

Now that everything is setup lets simulate failover of Washington site and see how it works:

Bring down Contoso Washington site by shutting down EDGE1 & ContosoP1 hosts
Use Hyper-V Replica to failover the VM on Hoster
VM APP1 now comes up with same IP address as it had @ Washington site
Clients of Contoso are now redirected automatically to 3-DAS1 by DA configuration.
Clients can now access APP1 VMs.
Validate that clients can continue to work with minimal service interruption.

The convergence of these platform technologies in Windows Server 2012 provides a big & seamless opportunity for hosters to build powerful services such as Disaster Recovery. Try it out and let us know your experience!

Windows Virtualization Team Blog

Using SMB shares with Hyper-V Replica

Scenario #1: Single Replica server with SMB share

The building blocks

Setting up the infrastructure

Fixing the error

Scenario #2: Multiple Replica servers (unclustered) with SMB share

Scenario #3: Replica cluster with SMB share

The building blocks

Setting up the infrastructure

Fixing the error

Using CredSSP and PowerShell

Adding a node to this cluster

Concluding note

MMS 2013 Labs: Powered by Microsoft/HP Private Cloud...

MMS 2013 Hands On Labs

XenDesktop 7 Supports Windows Server 2012

Hyper-V Replica Capacity Planner

Resynchronization of virtual machines in Hyper-V Replica

What is resynchronization and why is it needed?

When does resynchronization happen?

Site

Condition

Scenario example

Initiating and scheduling resynchronization

The process of resynchronization

Resynchronization performance

Conclusion

How to install integration services when the virtual machine is not running

Updates for Hyper-V

Hyper-V Replica Certificate Based Authentication - makecert

Hyper-V Replica - Name Resolution of Internationalized Server/Domain names

Multi-tenant disaster recover solution using Windows Server 2012

Step 1: Building Contoso’s environment

Step 3: Configuring Cloud DA site on top of Hyper-v Network Virtualization:

Here are the steps to configure DA cloud site:

Step 5: Validating Disaster Recover as a service