Introduction

I had a requirement to migrate an existing native boot Windows Server 2008 R2 machine that was booting from an attached VHD on a physical machine to be a virtual machine in Hyper-V. The problem is that this machine had multiple boots and so the booting record was on the physical drive and the VHD image really did not have any booting information. Also because of the fact that it is booting in a physical machine it was using SATA AHCI of that machine and had the drivers to use that which is completely different form the Hyper-V implementation of the feature so I had to switch to Native IDE storage controller instead.

Resolution

What I did was first I created a differencing VHD disk from that virtual machine as I wanted to make sure I am not changing anything in the source VHD in case I decided to switch back to native boot. Then I created the virtual machine and used IDE controller for the HDD pointing to the differencing VHD file. Now because the VHD did not have any booting information I had to build it and I had to add the boot manager to that machine. So here are the steps.

1-      Mounted the VHD using the host storage disk management.

2-      Copied the files “bootmgr” and all contents of the folder “Boot” from a similar OS machine (Windows 2008 R2) to the root of the VHD.

3-      Made sure that the copied files still have the system attribute set correctly.

4-      Un-mounted the VHD from the host.

5-      Attached a Windows 2008 R2 setup DVD to the DVD drive of the virtual machine.

6-      Started the Virtual machine and booted from the setup DVD.

7-      Clicked next on the setup screen with default options.

8-      Clicked repair my computer and opened command prompt.

9-      Since the virtual drive did not have the partition set as active I changed that as per the command lines below:

10-   Now I need to fix the boot sector information so I typed the following commands:

11-   If you had hypervisor enabled on the physical machine then you also need to disable that using the command

12-   I have now the booting information in-place and ready to boot but when I booted it hit BSOD and I remembered that I need to correct the use of storage driver to be IDE since that machine was using SATA. So I switched back to the command prompt from the Windows setup DVD.

13-   Started Regedit.

14-   Selected HKEY_LOCAL_MACHINE and clicked File then “Load Hive”

15-   Browsed to the file “C:\Windows\System32\Config\System”

16-   I entered a name for the key to be “OfflineSys”

17-   I browsed to the key “HKLM/OfflineSys/System/CurrentControlSet001/Services/” and then under the following keys I changed the “Start” values according to the following table.

18-   I selected back to the key “HKEY_LOCAL_MACHINE\OfflineSys”

19-   Then clicked “File” then “Unload Hive”

20-   Now restarted the machine and it worked like a charm and started installation of new device drivers and everything.

Conclusion

Although moving a machine from the physical boot to be a virtual machine is possible it is very risky I advise you to do with the great care. It is also highly advisable to use Physical-to-virtual conversion tools such as the Virtual Machine Manager that comes with the System Center suite.

Introduction

I was developing a WCF based solution that required services to be authenticated using ADFS 2.0. The requirement was that the clients will be using client based certificates to authenticate to services. If you have a complete AD CS solution implemented that wouldn’t have been that difficult since the platform already takes care of most of the stuff already mentioned here but I wanted to test this scenario with my own testing certificates that are generated using command line tool “makecert.exe” and not a CA.

The Solution

The steps that you need to follow are:

·        Step 1: Create a claims aware WCF service using WIF.

·        Step 2: Add ADFS as an STS to the WCF service.

·        Step 3: Add this as a relying party in ADFS using the generated metadata.

·        Step 4: Build a client application and add a service reference.

·        Step 5: Change the issuer address to make sure it is using the ADFS certificate endpoint.

·        Step 6: Create a Certificate to Act as Your Client Root Certificate Authority.

·        Step 7: Create a Certificate Revocation List File from the Root Certificate.

·        Step 8: Install Your Client Root Certificate Authority on the Client and Server Machines

·        Step 9: Install the Certificate Revocation List File on the Server and Client Machines

·        Step 10: Add the Client Root Certificate Authority to the NTAuth store

·        Step 11: Create and Install Your Temporary Client Certificate

·        Step 12: Configure Active Directory Mapping.

So let’s get into the detail shall we.

I am not going over the first four steps since you can find more details on how to perform them in many places such as here or here. So I will start explaining starting of step 5.

Step 5: Change the issuer address to make sure it is using the ADFS certificate endpoint

ADFS 2.0 supports multiple methods to issue tokens, these are called endpoints. As you can see in the below image it supports many and you can even enable or disable them as required.

So we need to make sure that the Certificate Mixed endpoint is first enabled in ADFS. Now if you did not add an issuer address to your WCF service or added any endpoint address other than the certificate mixed one you need to change that in your client configuration. You can simply do this by opening the app.config file and look within the imported service binding for the issuer or the issuermetadata tag. It should eventually be configured similar to the below.

Step 6: Create a Certificate to Act as Your Client Root Certificate Authority

In this step, you use the makecert tool to create a root CA that will be used to sign your certificate. This certificate will be self-signed and will only have the public key that will be used to perform chain trust validation, when authenticating clients with the certificate. The self-signed certificate will act as a root CA itself, instead of pointing to a Root authority in a chain of trust.

1.       Open a Visual Studio command prompt and browse to the location where you want to save the certificate files.

2.       Run the following command to create the root CA:

In this command:

·        -n specifies the subject name for the root CA. The convention is to prefix the subject name with "CN = " for "Common Name".

·        -r specifies that the certificate will be self-signed. This means that certificates created with this switch will act as a root certificate.

·        -sv specifies the file that will contain the private key of the certificate. The file is always created, if it does not already exist. This will allow creation of certificates using the private key file for signing and key generation.

·        RootCaClientTest.cer specifies the name of the file containing the public key of the certificate. The RootCATes.cer file will not have the private key. This is the certificate that will be installed in the store for chain trust validation on the client and server machines.

3.       In the Create Private Key Password dialog box, enter a password, confirm the password, and then click OK.

Optionally, you can click None without entering the password, but this is not recommended for security reasons.

4.       In the Enter Private Key Password dialog box, enter the password again and then click OK.

This is the password needed to access the private key file RootCaClientTest.pvk in order to generate the file RootCaClientTest.cer containing the public key.

This step creates a certificate named RootCaClientTest.cer and a private key file named RootCaClientTest.pvk.

Step 7: Create a Certificate Revocation List File from the Root Certificate

In this step, you create a CRL file that will be imported into the correct certificate stores of the client and service machines. You create a CRL for the temporary root certificate; the CRL is necessary because WCF clients check for the CRL when validating certificates.

1.       Open a Visual Studio command prompt and browse to the location where you want to save the CRL file for the root certificate.

2.       Run the following command to create the CRL file:

In this command:

·        -crl specifies that you want to generate the CRL file for the root certificate.

·        -n specifies the subject name for the CRL. The convention is to prefix the subject name with "CN = " for "Common Name". You can give it the same name as the root CA.

·        -r specifies that the CRL file will be self-signed. This means that CRL files created with this switch will act as CRL files for the root CA.

·        -sv specifies the file that will contain the private key for CRL file generation. The file is not created because it already exists. This allows creation of CRL files using the private key file for signing.

·        RootCaClientTest.crl is the CRL file created with the command.

Step 8: Install Your Client Root Certificate Authority on the Client and Server Machines

In this step, you install the client root CA in the Trusted Root Certification Authorities location on both the server and client machines. All certificates that are signed with this certificate will be trusted by the client machine.

Repeat the following steps on both the client and server machines:

1. Copy the RootCaClientTest.cer file to the client and server machines.
2. Click Start and then click Run.
3. In the command line, type MMC and then click OK.
4. In the Microsoft Management Console, on the File menu, click Add/Remove Snap-in.
5. In the Add Remove Snap-in dialog box, click Add.
6. In the Add Standalone Snap-in dialog box, select Certificates and then click Add.
7. In the Certificates snap-in dialog box, select the Computer account radio button (because the certificate needs to be made available to all users), and then click Next.
8. In the Select Computer dialog box, leave the default Local computer: (the computer this console is running on) selected and then click Finish.
9. In the Add Standalone Snap-in dialog box, click Close.
10. In the Add/Remove Snap-in dialog box, click OK.
11. In the left pane, expand the Certificates (Local Computer) node, and then expand the Trusted Root Certification Authorities folder.
12. Under Trusted Root Certification Authorities, right-click the Certificates subfolder, click All Tasks, and then click Import.
13. On the Certificate Import Wizard welcome screen, click Next.
14. On the File to Import screen, click Browse.
15. Browse to the location of the signed root CA RootCaClientTest.cer file copied in Step 1, select the file, and then click Open.
16. On the File to Import screen, click Next.
17. On the Certificate Store screen, accept the default choice and then click Next.
18. On the Completing the Certificate Import Wizard screen, click Finish.

The signed root CA certificate is now installed in the Trusted Root Certification Authorities store. You can expand the Certificates subfolder under Trusted Root Certification Authorities to see the RootCaClientTest certificate installed properly.

Step 9: Install the Certificate Revocation List File on the Server and Client Machines

In this step, you install the CRL from the file in the Trusted Root Certification Authorities location on both the server and client machines. The CRL is checked during the certificate validation process.

Repeat the following steps on both the client and server machines:

1. Copy the RootCaClientTest.crl file to the client and server machines.
2. Click Start and then click Run.
3. In the command line, type MMC and then click OK.
4. In the Microsoft Management Console, on the File menu, click Add/Remove Snap-in.
5. In the Add Remove Snap-in dialog box, click Add.
6. In the Add Standalone Snap-in dialog box, select Certificates and then click Add.
7. In the Certificates snap-in dialog box, select the Computer account radio button (because the certificate needs to be made available to all users), and then click Next.
8. In the Select Computer dialog box, leave the default Local computer: (the computer this console is running on) selected and then click Finish.
9. In the Add Standalone Snap-in dialog box, click Close.
10. In the Add/Remove Snap-in dialog box, click OK.
11. In the left pane, expand the Certificates (Local Computer) node, and then expand the Trusted Root Certification Authorities folder.
12. Under Trusted Root Certification Authorities, right-click the Certificates subfolder, select All Tasks, and then click Import.
13. On the Certificate Import Wizard welcome screen, click Next.
14. On the File to Import screen, click Browse.
15. On the Files of Type screen, select Certificate Revocation List.
16. Browse to the location of the signed root CA RootCaClientTest.crl file copied in Step 1, select the file, and then click Open.
17. On the File to Import screen, click Next.
18. On the Certificate Store screen, accept the default choice and then click Next.
19. On the Completing the Certificate Import Wizard screen, click Finish.

The CRL for the root CA certificate is now installed in the Trusted Root Certification Authorities store. You can click the Trusted Root Certification Authorities folder and then press F5 to display the subfolder named Certificate Revocation List. You can expand this folder to see the RootCaClientTest certificate revocation list installed properly.

Step 10: Add the Client Root Certificate Authority to the NTAuth store

This is a critical step for this procedure since the root certificate was not issued by an enterprise CA. if you issue the certificate by an enterprise CA then this is already done automatically during the configuration of the ADFS server.

1.       Open a Visual Studio command prompt and browse to the location where the root CA certificate and private key file you created are stored.

2.       Run the following command for adding the Client Root Certificate Authority to the NTAuth store:

Step 11: Create and Install Your Temporary Client Certificate

In this step, you create the temporary certificate from the signed root CA created in the previous step and install it on the server machine.

3.       Open a Visual Studio command prompt and browse to the location where the root CA certificate and private key file you created are stored.

4.       Run the following command for creating a certificate signed by the root CA certificate:

In this command:

·        -sk specifies the key container name for the certificate. This needs to be unique for each certificate you create.

·        -iv specifies the private key file from which the temporary certificate will be created. You need to specify the root certificate private key file name that was created in the previous step and make sure that it is available in the current directory. This will be used for signing the certificate and for key generation.

·        -n specifies the key subject name for the temporary certificate. The convention is to prefix the subject name with "CN = " for "Common Name".

·        -ic specifies the file containing the root CA certificate file generated in the previous step.

·        -sr specifies the store location where the certificate will be installed. The default location is currentuser. For certificate authentication, this is the default location that Microsoft Internet Explorer uses for when browsing Web sites that require a client certificate.

·        -ss specifies the store name for the certificate. My is the personal store location of the certificate.

·        -sky specifies the key type, which could be either signature or exchange. Using signature makes the certificate capable of signing and enables certificate authentication.

·        -pe specifies that the private key is generated in the certificate and installed with it in the certificate store. When you double-click the certificate on the General tab, you should see the message “You have a private key that corresponds to this certificate” displayed at the bottom. This is a requirement for certificate authentication. If the certificate does not have the corresponding private key, it cannot be used for certificate authentication.

5.       In the Enter Private Key Password dialog box, enter the password for the root CA private key file specified in Step 2, and then click OK.

Step 12: Configure Active Directory Mapping

1.       To open Active Directory Users and Computers, click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers.

2.       To open Active Directory Users and Computers in Windows Server® 2012, click Start, type dsa.msc.

3.       On the View menu, select Advanced Features.

4.       In the console tree, click Users.

Where?

Active Directory Users and Computers/domain node/Users

Or, click the folder that contains the user account.

5.       In the details pane, right-click the user to which you want to map a certificate, and then click Name Mappings.

6.       In the Security Identity Mapping dialog box, on the X.509 Certificates tab, click Add.

7.       Type the name and path of the .cer file that contains the certificate that you want to map to this user account, and then click Open.

8.       Do one of the following:

To map the certificate to one account (one-to-one mapping), confirm that both the Use Issuer for alternate security identity check box and the Use Subject for alternate security identity check box are selected.

To map any certificate that has the same subject to the user account, regardless of the issuer of the certificate (many-to-one mapping), clear the Use Issuer for alternate security identity check box, and confirm that the Use Subject for alternate security identity check box is selected.

To map any certificate that has the same issuer to the user account, regardless of the subject of the certificate (many-to-one mapping), clear the Use Subject for alternate security identity check box, and confirm that the Use Issuer for alternate security identity check box is selected.

That’s basically what you need to do to authorize the user using a client certificate.

One final note, if you get an error such as below:

This probably means that you forgot step number 10.

In this post series I started here with a release date announced in Windows Server Blog (by the way it was announced yesterday (1st of August) that Windows Server 2012 is RTM today), then I start highlighting the main areas of enhancements that I will focus on in this series starting from Virtualization Enhancements started from scalability & flexibility and shown how to host Virtual Machine on Windows Server 2010 file server here.

Today I am going to move to different area which is Hyper-V Mobility, and will cover one of my favorite features in Windows Server 2012 which is Hyper-V Replica, Hyper-V Replica is new functionality added to the Hyper-V Role in Windows Server 2012 that allow virtual machines running on a host or cluster in a primary site to be replicated to a server or cluster in secondary site using available network bandwidth. Hyper-V Replica replication is efficient, periodic, and asynchronous over IP-based networks and allows a system administrator, in the event of a failure at a primary site (e.g. disaster, server failure, etc.), to execute a failover of production workloads to replica servers at a secondary location within a very short time, let me show you how to configure Hyper-V Replica.

Consider that you have a very simple Hyper-V environment consists of consists of one Domain Controller “DC” and two Hyper-V Hosts “HV1” & “HV2” in the same Active Directory Domain “contoso.com”, and the high level steps to configure and test Hyper-V Replica are as follows:

1. Configure the Firewall to allow Hyper-V Replication.
2. Create Virtual Network and a Virtual Machine to Replicate.
3. Configure Hyper-V Replication Settings on the two Hosts HV1 & HV2.
4. Configure Guest IP Injection.
5. Test Failover (Planned and Unplanned).
6. View Replication Status Health.

Let us start showing you how it is easy to configure and test this amazing feature .

Configure the Firewall to Allow Hyper-V Replication

• On HV1 login as Domain Administrator and click Server Manager.
• From Tools menu click Windows Firewall with Advanced Security.

• In the Console Tree pane, click Inbound Rules.
• Right-click the Hyper-V replica HTTP listener (TCP-In) rule, and the click Enable Rule, and close the Windows Firewall with Advanced Security console.

• Switch to HV2, and repeat the same above steps.

Create Virtual Network and a Virtual Machine to Replicate

• On DC login as Domain Administrator and click Server Manager.
• On the Tools menu, click Hyper-V Manager.
• In the Console Tree pane, right-click Hyper-V Manager, and then click Connect to Server, and in Another computer, type HV1, and then click Virtual Switch Manager.
• Ensure External is selected, and then click Create Virtual Switch.
• In Name, Type TestNet, and then click Ok, and in Apply Networking Changes dialog box, click Yes.

• Repeat steps above using HV2 as target server to create a virtual network on HV2.
• Then from Hyper-V Manager create new virtual machine and name it TestVM.

Configure Hyper-V Replication Settings on the two Hosts HV1 & HV2:

• On DC, in the Hyper-V Management console, in the console tree pane, click HV1.
• Right-click TestVM, and click Enable Replication, and click Next.

• On the Specify Replica page, type HV2.contoso.com, and then click Next, and you should expect error stating that the specified Replica server is not configured to receive replication from this server.

• Click Configure Server to configure HV2 as replica server.
• On the Hyper-V Settings for HV2 page, check the Enable this computer as a Replica server check box.
• In the Authentication and Ports section, check the Use Kerberos (HTTP) check box, and then ensure the port is 80.
• In the Authentication and storage section, click Allow replication from any authenticated server, and click Ok.

• On the Specify Server page, ensure hv2.contoso.com is in the Replica server field, and click Next.
• On the Connection Parameters page, ensure the replica server is hv2.contoso.com, the Replica server port is 80, and Use Kerberos authentication (HTTP) is selected, and also ensure that the Compress the data that is transmitted over the network check box is checked, and click Next.

• On the Choose Replication VHDs page, ensure that C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\TestVM.vhdx check box is checked, and click Next, and then click Next on the Configure Recovery History page.
• On the Choose Initial Replication Method page, select to Send initial copy over the network and Start replication immediately, then click Finish.
• Now from Hyper-V console right-click HV1, and then click Hyper-V Settings.
• In the Hyper-V Settings for HV1 windows, click Replication Configuration.
• Check the Enable this computer as a Replica server check box.
• In Authentication and Ports section, check the User Kerberos (HTTP) check box, and ensure that the port is 80.
• In the Authentication and storage section, click Allow replication from any authenticated server, and then click Ok.

Configure Guest IP Injection:

Let me explain more why we need guest IP Injection, when a virtual machine is replicated from a primary server to a replica server, all the machine properties, including its IP address, are replicated. Hyper-V allows an administrator to place a new IP address on the replica of the virtual machine so that when it starts, it is configured with an IP address suitable to the network where the replica server is located.

• On DC login as Domain Administrator, and in the Hyper-V Manager console, in the Console Tree pane, click HV2.
• In the Details pane, right-click TestVM, and then click Settings.
• Click Network Adapter, and the expand it.
• Click Failover TCP/IP, and in IPV4 settings area, check the User the following IPv4 address schema for the virtual machine check box.
• Configure the address from IP range same as Replica Server HV2 range, and click Apply.

• Under the Network Adapter, click Test Failover.
• In the Virtual Switch drop-down menu, click TestNet, and click Ok.

Test Failover (Planned and Unplanned):

Hyper-V allows an administrator to test whether or not a virtual machine is successfully replicating by starting it on the replica server. The test is done by starting the virtual machine on a replica server and ensuring a successful start. In the test, the virtual machine does not connect to the network; therefore it will not interfere with the original virtual machine running on the primary server. In addition, replication from the primary server to the replica server is not interrupted.

• On DC login as Domain Administrator.
• In the Hyper-V Manager console, in the Console Tree pane, click HV2.
• In the details pane, right-click TestVM, click Replication, and then click Test Failover.

• In the Test Failover dialog box, click Test Failover.

• Notice that in the Hyper-V details window, a new virtual machine named TestVM-Test is displayed.

• In the Hyper-V Manager console, right-click TestVM, click Replication, click Stop Test Failover, and then in the Stop Test Failover dialog box, click Stop Test Failover.

And to execute a planned failover such as during hardware upgrades or during a planned disaster recover test follow the below steps:

• On DC, in Hyper-V Manager console, in the Console Tree pane, click HV1.
• In the Details pane, right-click TestVM, click Replication, and then click Planned Failover, and click Failover.

• Wait for the Planned Failover dialog box to appear indicating a failover.

• In the Planned Failover dialog box, click Close.
• In Hyper-V Manager console, in the Console Tree pane, click HV2, and note that HV2 is now the primary server and HV1 is now the replica server for the TestVM.

And now let us simulate unplanned failover, something that can happened if primary datacenter failed.

• On DC, in the Hyper-V Manager console, in the Console Tree pane, click HV2.
• In the details pane, right-click TestVM, and click Shut Down., and wait until the virtual machine completely shuts down.
• In the Hyper-V Manager console, in the Console Tree pane, click HV1.
• In the Details pane, right-click TestVM, click Replication, and then click Failover.

• In the Failover dialog box, click Fail Over, and you should note that HV2.contoso.com become the current Primary Server for TestVM.

• In the Hyper-V Manager console, right-click TestVM, click Replication, and then click Reverse Replication.

• In the Reverse Replication Wizard for TestVM, click Next.
• On the Specify Replica page, ensure that the replica server failed contains HV2.contoso.com.
• Click Next four times, accepting the default values on each page in the wizard, and then click Finish.
• In the Reverse Replication Wizard for TestVM, click Close, and note that now HV1 is the primary server and HV2 is replica server for the TestVM.

View Status Replication Health:

Hyper-V Replication provides information as to the status and health of the replicated virtual machines, in this step we will determine the replication health of a virtual machine, and then we will determine the primary and replica servers for a virtual machine.

Determine the replication health of a virtual machine:

• In Hyper-V Manager console, in the Console Tree pane, click HV1.
• In the Details pane, in the Virtual Machine pane, right-click any of the column headers, for example, Name, State, CPU Usage, etc., and then click Add/Remove Column.
• In the Available Columns list, click Replication Health, and then click Add, and click Ok.
• Adjust the column sizes so as to view the Replication Health column in the window.
• In the Details pane, right-click TestVM, click Replication, and then click View Replication Health.

• Review the information found in the Replication Health window, and then click Close.

I did not decide yet about what I am going to cover in the next post, but almost I will keep digging into Virtualization Enhancements specially Mobility area that has a lot of new good features and capabilities that put Microsoft Hyper-V Virtualization Platform on top of Virtualization technologies, stay tuned, get ready, get excited.

Related Posts:

• Windows Server 2012 – Part1: Release Date can be found here http://blogs.technet.com/b/meamcs/archive/2012/07/10/windows-server-2012-part1-release-date.aspx
• Windows Server 2012 – Part2: Virtualization Enhancements “Scalability & Flexibility” shows how to host Virtual Machine on Windows Server 2010 file server can be found here http://blogs.technet.com/b/meamcs/archive/2012/07/19/windows-server-2012-part2-virtualization-enhancements-scalability-amp-flexibility.aspx
• Windows Server 2012 – Part3: Virtualization Enhancements “Mobility” - Hyper-V Replica can be found here http://blogs.technet.com/b/meamcs/archive/2012/08/03/windows-server-2012-part3-virtualization-enhancements-mobility-hyper-v-replica.aspx