Windows 2012 NAP (NPS) with DHCP

After my last article on DHCP I decided to flesh out the Microsoft offerings and expand into Network Policy Server. NPS is actually a set of different features from Microsoft including RADIUS and what the rest of the industry knows as NAC, (Network Access Control) which Microsoft calls NAP (Network Access Protection). This allows you to grant or deny network access to clients based on criteria such as:

• Domain/Group Membership
• Client source network
• Time of day
• Client health (as determined by an SHV, see below for more)

3 out of 4 Doctors are very serious about Microsoft NAP.

These rules must be introduced to the clients at an insertion point (think of it as an entry gate). The supported insertion points include:

• IPSec
• 802.1X
• VPN
• DHCP
• RDGateway

I'll be covering integration with DHCP since it is by far the most cost effective method considering the required role of Microsoft based services in the environment. For information on the others, see Technet: NAP Enforcement Points.First, let's set up NAP:

Assumptions

• At least one Windows 2012 server ready to go. Note that NPS is not supported on server core. Most of these instructions are applicable to 2008/r2 as well.
• DHCP installed and ready to go.
• Sufficient Privileges (Domain Admin generally)
• I assume you'll be installing NAP on the DHCP server itself. You can have these roles on separate servers should you desire, but you'll need to install the NAP piece on the DHCP server as a RADIUS proxy. I won't be covering that piece here. For more on that, see this Technet article.

Installing NAP

1. Using server manager, select "Manage"->"Add Roles or Features"
2. Navigate through the Add Roles and Features Wizard, selecting the target server and "Network Policy and Access Services".





3. When prompted to select role services, you need keep only the default "Network Policy Server" selected and continue through the wizard.

Repeat this step for the DHCP server as well if it's a different server than the one you installed NAP on.

Configuring NAP

The NAC portion of NAP is actually a collection of several different elements. The following elements make up a NAP policy that can be used by DHCP; numbers in front represent the default number of that item for one overall policy:

• Connection Request Policy (Created by Wizard)
• (3) Network Policies (Created by Wizard)
• (2) Health Policies (Created by Wizard)
• Windows Security Health Validator
• At least one Remediation Server Group

There is a (seemingly hidden) wizard to guide you through the process of creating most of these elements, but we're going to create the unguided ones first and then circle back and use the Wizard since we'll want to point to those during the Wizard portion. For all these sections save the DHCP and client sections we'll be working in the Network Policy Server management tool.

Windows Security Health Validator

The Security Health Validator is the policy for defining what a healthy windows client is. The built-in Windows SHV gives the NAP server the capability to interact with the Network Access Protection Agent service on Windows clients (XP SP3 and newer) to determine the health status of that given client. The Security Health Validator determines what criteria the client must pass for the client to be considered healthy. There is a default configuration that can be utilized but for the sake of experience we'll configure the Windows SHV. To do so:

1. First, open the NAP management tool by selecting "Tools"->"Network Policy Server" from Server Manager.
2. Expand "Network Access Protection"->"System Health Validators"->"Windows Security Health Validator"->"Settings"
3. Right click "Settings"->"New"
4. Give the SHV a name; make it something meaningful to describe the target client base, i.e. "Standard Client Set"
5. Set your settings as desired; they're split into settings for Windows XP and Vista or higher. The settings are quite straightforward though it should be noted that if you would like to utilize WSUS to update out of compliance clients (assuming you select being out of date makes for a failed check) you'll need to check the box on the very bottom of the options dialog. Click "OK" when complete.





6. Click on the "Error Codes" under "Settings" and take note of the Error Code Configurations. Generally the default state of "Noncompliant" for each setting is desirable, but depending on your clients and equipment there may be situations where you would want to change some of these SHV check failures to compliant.

Note that third parties can also create SHVs to plugin to the NAP architecture for use with other products. (Old list of some others here)

Remediation Server Groups

The remediation server groups are the servers that will be made accessible to non-compliant clients if you choose to do so. These servers can be used to patch clients to a compliant status. Note that any services needed to contact the remediation services (WSUS, Antivir FTP, etc.) need to be available for the clients to update properly. (DNS, etc.) Under the DHCP enforcement model, these servers are made available via static routes. Also note that you can provide a help URL to a website instructing access-limited clients on how to repair their machines. The server that hosts this URL and all resources required to resolve it must be part of the remediation server group as well. For more information about RSGs, see Technet: Planning the Placement of a NAP Remediation Server. Assuming you have determined which servers need be part of the remediation group, let's set them up:

1. Expand "Network Access Protection"->"Remediation Server Groups"
2. Right Click->"New" (Note that these can be stored as templates for use elsewhere as well)
3. Give the group a meaningful name; note that each health policy can use only one group, so everything for that client base will need be in that group. Something like "Sitename Remediation Group"
4. Click the "Add" button to add a server.
5. Enter a friendly name for this server, i.e. "Minneapolis WSUS 01" or just the server name and then enter the DNS name and click "Resolve". Hit "OK" when complete.
6. Repeat steps 4 and 5 for each server in this group. Then hit "OK" on the "New Remediation Server Group" page.

Setup Remaining Items with The Whiz

1. Click "NPS" on the top of the Network Policy Server management tool.
2. Click "Configure NAP" to launch the secret hidden Wizard.





3. Select "Dynamic Host Configuration Protocol (DHCP)" under "Network Connection Method". Note this is where you would select a different option should you want to use a different insertion point. If you wish to enable this policy on only specific scopes then give the policy a name, I.E. "Minneapolis NAP DHCP".  If you wish this policy to be effective on all scopes do not change it from the default name. Click "Next".
4. On the next screen, click add if the DHCP server is not on the same server as the main NAP server. If that is the case, enter a Friendly Name, Address, and Shared Secret and click "OK". If not, no action is necessary. After this is complete, click "Next".
5. On the next screen, "Specify DHCP Scopes", we need only add scopes if we want this policy to apply to a specific set of scopes. If we do not specify any scopes it will apply to all NAP enabled scopes. Either add the name of all specific scopes to which this policy will apply or just click "Next" with the scopes empty to have it apply to all.





6. The "Configure Machine Groups" screen, like the previous DHCP Scopes screen, is only for limiting access to a set of computers. Should you choose, specify the group(s) of computers you would like to receive IP addresses. In most cases you should leave this blank, but in the event you would restrict via group click "Add" and enter the groups you would like to have access. Click "Next" when you are done with this screen.





7. On the next "Specify a NAP Remediation Server Group and URL" screen select the server remediation group we created earlier. If you would like the clients to have access to a web site describing how to re-mediate their machines enter that under "Troubleshooting URL". Note you must setup this site, it is not included with NAP since the instructions will be different depending on your software selection. After entering the required information, click "Next".





8.  "Define NAP Health Policy" is the final screen. You should see the "Windows Security Health Validator" selected and you can go ahead and enable auto-remediation of client computers with the applicable check box. I'll address this a bit more in closing.
9. As for "Network access restrictions for NAP-ineligible client computers", select whichever you prefer. In most cases if you've bothered to come this far you'll be selecting to deny full network access since that's usually the point. Click "Next".





10. You will be presented with a summary screen; review the information and click "Finish".

Configure Clients

We need to configure two important elements to make the clients functional: Enable the service and configure it to enforce via DHCP. To accomplish that, we'll use group policy. You will need to ensure your group policy objects are targeted appropriately via something like OU linking or security filtering. If you need more information on how to target group policy objects, see this link. Also note that according to some Microsoft documentation, the Wired and/or Wireless Autoconfig services need to be set to automatic, but in my testing they worked when set to manual. Keep that in mind if you have issues.

1. Edit the group policy object you plan to use for NAP client enforcement using the Group Policy Management tool.
2. Navigate to Computer Configuration->Policies->Windows Settings->Security Settings->System Services
3. Double click "Network Access Protection Agent" and check "Define this policy setting" and select "Automatic". Click "OK" to save the setting.





4. Navigate to Computer Configuration->Policies->Windows Settings->Security Settings->Network Access Protection->NAP Client Configuration->Enforcement Clients
5. Double click "DHCP Quarantine Enforcement Client", check "Enable this enforcement client" and click "OK" to save the setting.





6. Provided you're ready, take any steps necessary to apply the GPO to the desired clients. (Link, etc.)

Enable in DHCP

You can either enable globally or on a per-scope basis. I will give the instructions on how to enable globally. If you want to enable on a per-scope basis substitute right-clicking on the "IPv4" below with the scope(s) you desire instead. In that case, you'll need to specify the custom name of the policy you created in step 3 above.

1. Open the DHCP Manager and point it at the server in question.
2. Right click "IPv4" and click "Properties"
3. Click "Network Access Protection"
4. Select what you would like to happen should the NAP server become unavailable, then click "Enable on all scopes".





5. You will be notified that your NAP settings will be overridden on all scopes. Assuming this is what you would like to do, click "Yes".
6. Click "OK".

If you're using a 2012 failover/loadbalance configuration the NAP settings will replicate for each scope, but make sure communication to the NAP server is configured correctly for each DHCP server. That connection information is not replicated. Here is additional info should you need it: Technet: Configure a DHCP Server for NAP. No restart of anything is needed; you should be using NAP now!

Usage Notes/Troubleshooting

• If using a custom profile name for a specific scope, you'll need to provide the custom profile name. This name is the name of the connection request policy you would like to use. For more info see: Configuring Custom NPS Policies Per DHCP scope





• The event log location relevant to NPS authentication is in the security log with the task category of "Network Policy Server". A filtered view of this can be found under "Custom Views->Server Roles->Network Policy and Access Server".
• Know that this solution won't keep out anyone trying to infiltrate your network; anyone with a moderate amount of savvy can take steps to determine what IP to assign themselves should they have physical access to your network.
• What references what?
• * Compliant and * Non-Compliant Network Policies reference Health Policies
• Health Policies reference Security Health Validators
• DHCP scopes reference Connection Request Policies
• You can add several other types of criteria to your policy should you desire. Take a look at your policies under NPS->Policies->Network Policies for more options.
  





• If you enabled auto-remediation, clients will try to repair themselves for simple issues. For example: if a client's firewall is off and the policy requires it, the client will re-enable the firewall and attempt to pass the health check again. Should this fail manual intervention will be necessary. For more information on how to troubleshoot the client, see "Configure NAP Tracing" on Technet.
• Make sure you monitor the load on your NPS servers; the last thing you want is for them to get overwhelmed and prevent proper servicing of DHCP requests. There are some performance counters that can help you with this task; for more info see Technet: Load Balancing with NPS Proxy. Also, be sure to read up on Technet: Best Practices for NPS which covers performance as well as other important info.
• For some information regarding how to use Powershell to configure/manipulate NPS, see my post here.

Prologue

Obviously we're just scratching the surface here; there is quite a bit more that we could dig into but I'm going to stop here in the interest of time. NAC solutions aren't particularly popular right now in a regular office scenario, but as issues continue to arise with malware, etc. more companies may determine these sorts of solutions are necessary. If you already have a Microsoft based infrastructure you probably have nearly everything you need to implement this solution. If you have questions/concerns/comments please feel free to comment. Thanks!

References

Network Policy Server

Network Policy and Access Services Overview

Network Access Protection in NPS

Checklist: Implementing a DHCP Enforcement Design

Networking and Access Technologies: Network Policy and Access Services

Planning the Placement of a NAP Health Requirement Server

NAP Client and Server-side Component Communication

Windows Server 2012 SuperFeature: DHCP App-Level Failover/Loadbalance

Foreward

One of my favorite additions to Windows Server for the 2012 version is application level load balancing and fail-over. This all new implementation does away with the previous solutions: "scope-splitting" and Windows clustering, neither of which I have ever felt comfortable recommending to a client. Splitting scopes doesn't do enough to prevent outages, and clustering is too complex to be a DHCP solution.

Fortunately, Microsoft recognized this gap in their product and released this new app level failover solution that aims to be as simple and straightforward as possible. I've deployed this a couple of times now and I'm blown away. Here's a high level overview of the implementation:

• A single implementation can have two servers, no more. 
• Servers can be configured in load-balancing or hot standby mode. 
• Servers can reside across routing boundaries. (Enables unified management as well!)
• Failover/Loadbalance Limited to IPv4
• DHCP supported on server core
• (Optional) Replication encryption 
• Limit of one replication relationship type between two partners

And best of all,

• Easy to set up and maintain.  (With a couple caveats I'll list below)

Hot Standby vs. Load Balancing

The hot standby option utilizes one DHCP server to service requests while the other waits to step in should the primary fail. A percentage (generally single digit) of the scope in question needs to be dedicated to the passive standby server for slack address space to allocate in a failover event where the backup hasn't yet asserted primary status. Microsoft states that hot standby is useful for multiple multi-site deployments wherein the primary would be onsite and a secondary would be located offsite should the primary fail. Here are a couple scenarios well suited to hot standby:

Multi-Site, Single Backup

Two sites backing each other up

The load balancing strategy splits client servicing based off of a MAC address hashing algorithm and will still respond to client requests that the other member in the pair should service in a situation where the client has gone unanswered. Provided you're using a datacenter licensing model and virtualization, most folks will want to utilize load balancing with two DHCP servers per site, generally on different hosts connected to different switches. If needed, load distribution mechanisms like F5s will work with this tech.

Two Sites Each Independently Load Balanced

Now let's set up DHCP failover or load balancing:

Assumptions

• Basic knowledge re: Windows server 2012 and DHCP
• Two 2012 servers ready to go and fully patched

Since we need to set up at least two servers, we'll do this twice, once with the GUI and once with Powershell.

DHCP Server Setup (GUI)

1. Install the DHCP server role by using server manager and selecting Manage->Add Roles and Features





2. After bypassing the intro screen, select "Role Based or Feature Based Installation" and select your server.





3. Select the "DHCP Server" role. Admin tools will be auto-selected as needed. 





4. Click "Next" through the rest of the Wizard. Once it completes, you'll be notified that DHCP configuration needs to be completed.





5. Launch the DHCP Post-Install configuration wizard and complete the DHCP setup by authorizing the DHCP server. 

 

DHCP Server Setup (Powershell)

Where (Servername) is the FQDN of the server you wish to install, execute the following on a domain connected computer with proper rights on the target machine:

1. Load the servermanager module:

   Import-Module Servermanager

2. Install DHCP:

   install-windowsfeature -ComputerName servername.domain.lan -name dhcp -IncludeManagementTools

3. When complete, authorize in AD:

   Add-DhcpServerInDC -DnsName servername.domainname.lan

Note that in step #3 you must specify the -ipaddress parameter (i.e. -ipaddress 10.0.0.10) if your server has either multiple NICs or has messed up registration in DNS. See here for more info.

Prep for Server Pairing

After authorization, the DHCP services need be restarted due to group add/creates. Do that or reboot the servers in question, whichever is easier. Set up your DHCP scopes as you normally would on one of the two servers. (More info, ignore the 80/20 part) 

Configure DHCP Server Pair (GUI)

1. Open up the DHCP management GUI and right click on the scope you would like to load balance and select "Configure Failover..."





2. On the "Introduction to DHCP Failover" screen, select all scopes you would like to configure (or "Select all" for all) and click "Next".





3. On the "Specify the partner server to use for failover" screen select the other DHCP server. This can be looked up provided the server has been registered in Active Directory. 





4. On the "Create a new failover relationship" page configure the following:
1. Relationship name: Configure a name for this partnership; you may want to manipulate this via Powershell so take that into account when considering a very complex name. 
2. Maximum Client Lead Time: This determines two three things: A) The lease time for a new client request if the server responsible for that client is down and the other answers the request and B) The amount of time one server will wait for a dead partner server before it takes control of the entire IP address block. C) (added 8/5/13) The amount of time one server that had been down must be available to the other before "Partner Down" status will automatically be changed to "Normal" status. (See comments for an example of this) The default of 1 hour is generally good but you may want to tweak depending on your setup. 
3. Mode= Load Balance / Load Balance Percentage: This determines how much of the total load each server will take. 
4. Mode= Hot Standby / Role of Partner Server/Addresses reserved for standby server: This determines if the partner sever is the primary or the standby and how much of each scope is reserved for distribution should the primary go down. Be careful that you have enough reserved here so that you won't run out of IP addresses prior to switching to "Partner Down" mode while also ensuring you won't run out of IPs on the primary server due to reserved addresses on the standby.
5. State Switchover Interval: Selecting this enables either server to enter "Partner Down" state should communication be interrupted for the number of minutes specified after the option (default 60) resulting in the remaining server taking full responsibility for the scope(s). If this is not selected, an admin must manually choose to put the server into partner down state.
6. Enable Message Authentication and Shared Secret: I highly recommend checking this box and specifying a long (14+ character) shared secret. This will encrypt messages between the two servers by using SHA-256. Should you wish to change the crypto, navigate to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters\" in the registry and add/change "FailoverCryptoAlgorithm".





5. You'll then be met with a failover summary screen. Verify the info and click "Finish". 





6. You will be shown the failover setup process. 

Configure DHCP Server Pair (Powershell) 

This time around you don't need to do configuration twice, so this section would be in lieu of the previous. Refer to the section above for full descriptions, I'll just do mappings here:

Load Balanced

Add-DhcpServerv4Failover [-Name] (String) [-ScopeId] (IPAddress[]) [-PartnerServer] (String) [-AutoStateTransition (Boolean)] [-ComputerName (String)] [-LoadBalancePercent (UInt32)] [-MaxClientLeadTime (TimeSpan)] [-SharedSecret (String)] [-StateSwitchInterval (TimeSpan)]

Where:

-Name = Name above
-ScopeID = The IP of the scope to be partnered
-PartnerServer = DHCP Server 2
-AutoStateTransition = "State Switchover Interval" above. Note that if the "StateSwitchInterval" argument is used in the powershell command then this value is assumed TRUE, otherwise the default is FALSE
-ComputerName = DHCP Server 1
-Load Balance Percent = The % to be serviced by DHCP Server 1
-Max Client Lead Time = Same as outlined in the GUI section
-SharedSecret = Same as outlined in the GUI section
-StateSwitchInterval = Int; specifies how long to wait until auto transition to Partner Down. Makes AutoStateTransition assumed to be true.

Failover

Add-DhcpServerv4Failover [-Name] (String) [-ScopeId] (IPAddress[]) [-PartnerServer] (String) [-AutoStateTransition (Boolean)] [-ComputerName (String)] [-MaxClientLeadTime (TimeSpan)] [-ReservePercent (UInt32)] [-ServerRole (String)] [-SharedSecret (String)] [-StateSwitchInterval (TimeSpan)]

Where:
-ReservePercent = Same as outlined in the GUI section
-ServerRole = Active or Standby

Important Usage Notes!

• Server Options are NOT replicated! Take this into account when setting up replication; you may want to specify options at a scope level so that if they are changed you don't need to manually do it on each server. 





• There have been some reports of replication breaking custom options. See here for more info. 
• How do "Communication Interrupted" and "Partner Down" states get initiated and what effect do they have? Refer to this handy flowchart I whipped up for reference:  

References: 

MSFT DHCP Team Blog: Hot-Standby
MSFT DHCP Team Blog: Failover Load Balance
Technet: Step by Step Configure DHCP for Failover
MSFT Doco: Understand and Troubleshoot DHCP Failover in Win8 Beta (Still Relevant)

Closing

Thanks for taking the time to read; should you have any questions leave them in the comments!

OpenVPN on CentOS Running on Hyper-V Using Windows PKI

I have a knack for titles eh? (Just smile and nod) I've been very impressed by the scalability demonstrated by OpenVPN in applications such as proXPN. Because of this I decided to implement OpenVPN on my favorite Hyper-V friendly distro, CentOS (6.4) and utilize a Windows PKI infrastructure for issuing certificates. Wanna do that? Let's:

Assumptions

• You're familiar with the basics of PKI and how to process certificate requests. For more information on how to setup Windows PKI, see my article here.
• You're familiar with the basics of Linux administration including editing config files, etc. 
• You'll use sudo where applicable. I don't put it on command references to keep them cleaner. 

VM Creation

Create a VM with the following minimal virtual hardware: 

• 384MB RAM
• 1 Virtual Proc
• 10GB HD
• 2 NICs, (native) one either public/DMZ and one on your internal network (or inside the same DMZ if you desire)

It's possible to setup OpenVPN with 1 NIC, but in most configurations it's less secure and I won't be covering it here.

CentOS Setup

1. Download from here; minimal is all you'll need.
2. Insert the ISO to the virtual optical drive on the VM and start it up.
3. Install CentOS to the VM with desired settings; no special configuration is necessary.
4. Setup the NICs with static IP addresses. ("/etc/sysconfig/network-scripts/ifcfg-eth0" and "eth1", more instructions here) The following combinations for connectivity are possible: External/Internal, DMZ/Internal, External/DMZ, DMZ/DMZ. While different options have different pros and cons I'm not going to say what you should use because your circumstances will dictate your direction. I am using DMZ/Internal.
5. Enable ipv4 forwarding by editing "/etc/sysctl.conf" and setting the following value

   net.ipv4.ip_forward = 1

   (It's there and 0 by default)
6. Enable the EPEL so we can grab OpenVPN from it. Ensure you get the correct version, it was 6.8 as of this writing.

   rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

7. Make the directory for the keys:(We'll copy keys into this dir before install)

   mkdir /etc/openvpn/keys  

8. Make sure SSH is installed; if not:

   yum -y install openssh-server

9. Perform any other tasks you should find applicable to a OpenVPN server such as configuring auto-update (yum install vixie-cron -y needed on CentOS 5 minimal install) or installing any other supporting apps you should want. Just remember that any application you add is a potential security liability.

Create Certificate Templates

I won't be covering the basics of setting up certificate templates; for that see my article.We'll just cover the specifics of this implementation here.

Server Template

1. Open the certificate template manager for you enterprise PKI, and duplicate the Computer template. 
2. When prompted, select the "Windows 2003 Server, Enterprise Edition" and hit "OK". (The version of the OS determines the template version) 
3. Change the template display and name to something sufficiently descriptive such as "Computer (CompanyName OpenVPN Server)"
4. Up the Validity period should you desire. 
5. On the "Request Handling" tab set the private key to be exportable. (We're putting this on a Linux server afterall)





6. On the "Subject Name" tab change the option to "Supply in the request". 
7. On the "Issuance Requirements" tab check that the template requires CA certificate manager approval should you desire. 
8. Change to the "Extensions" tab, select "Application Policies" and click "Edit". Change it so that the "Server Authentication" is the only listed policy. Do not mark the extension critical. 
9. Everything else can be left the same unless you should want to change the permissions under security. 

Client Template

Repeat the steps for the Server template except change the name in 3: to a client name and 8: to "Client Authentication".

After creating your templates publish them to your issuing CA. Again, see my article for instructions.

Enroll For Server Certificate

Since this step is virtually the same for the client I'll be redirecting you here for that step as well. There are a few modifications listed to these steps to accommodate that; don't pay any attention to "For Clients:" on the first go-around.

1. Open the MMC (mmc.exe) and add the certificates snap-in for the local computer.  This can be done on any machine since we'll be exporting it.
2. Enroll in the server certificate template we created earlier. We need to specify a few options, so click "More information is required to enroll for this certificate.  Click here to configure settings." For Clients: use the client template
3. On the subject tab under Subject name, set the "common name" to the FQDN of the OpenVPN server. If you're using split DNS, make sure you set this to the external FQDN. For Clients: use your domain FQDN and set the OU to something consistent for all certs so that you can use the tls-verify option down the road should you choose. I use "vpn.company.com ClientCert"





4. On the "General" tab set the friendly name and the description to whatever you desire. I copy the common name and append "OpenVPN server"
5. On the "Extensions" tab change "Key Usage" to include only "Key agreement" and "Key encipherment". "Make these key usages critical" can be checked. Based on the template it should already have "Extended Key Usage" set to "Server Authentication". For Clients: Use "Client Authentication" rather than server authentication.





6. Under "Basic Constraints" click "Enable this extension" and "Make the basic constraints extension critical"
7. Under the "Private Key" tab select "Allow the private key to be archived" should you desire.
8. Click "OK" and then "Enroll". After the enrollment finishes you will need to click "Finish"
9. Go to your CA and complete the enrollment process, then export the public key and import it back on the requesting computer to complete the certificate request process. 

Export and Split the Certificate

Like the section above, this will be used for the client as well. See For Clients: for that.

1. Using the MMC or command line/powershell, export the newly created certificate WITH the private key to a pkcs12 format. Do not include all certificates in the certification path. Make sure you remember the password.
2. Use OpenSSL (you'll need to download/install from here) to convert the pfx file to standard text, then cut and split the file into a cert file and a key file. I'd walk you through this, but how about I give you a Powershell script to do it instead. :)  Make sure to set the variables at the top of the file to what suits you. If you don't want to use powershell, just follow the comments and the commands to convert and split the file. For Clients: You may want to change the variable definitions at the top of the file to reference client file names.

#set the output files, working file, and password for the PFX
$inputFile="c:\temp\server.pfx" 
$outputPublicKey="c:\temp\serverCert.cer"
$outputPrivateKey="c:\temp\serverCert.key"
$tempFile="c:\temp\temp.txt"
$password="password"


#Set the location to the Openssl.exe file
$openSSLLoc="C:\Program Files\OpenSSL-Win32\bin"


#Execute OpenSSL to convert the PFX file to standard text
& $openSSLLoc\OpenSSL.exe pkcs12 -in $inputFile -nodes -out $tempFile -passin pass:$password


#Now we need to find where the key and cert start and end. 
#For non-script users the point here is that we chop this one text file into two files,
# one the public key and one the private key. The two of those are denoted by the patterns listed below. 
$beginKey=get-content $tempFile |select-string -Pattern "-----BEGIN PRIVATE KEY-----"
$beginKey=$beginKey.LineNumber
$endKey=get-content $tempFile |select-string -Pattern "-----END PRIVATE KEY-----"
$endKey=$endKey.LineNumber
$beginCert=get-content $tempFile |select-string -Pattern "-----BEGIN CERTIFICATE-----"
$beginCert=$beginCert.LineNumber
$endCert=get-content $tempFile |select-string -Pattern "-----END CERTIFICATE-----"
$endCert=$endCert.LineNumber
$length=Get-Content $tempFile |Measure-Object
$length=$length.Count


$key=Get-Content $tempFile |Select-String "-----BEGIN PRIVATE KEY-----" -Context 0,($endKey-$beginKey)
$cert=Get-Content $tempFile |Select-String "-----BEGIN CERTIFICATE-----" -Context 0,($endCert-$beginCert)


#Write out the files. Make sure they're ASCII encoded!
$key.line| Out-File $outputPrivateKey -Encoding ASCII
$key.Context.DisplayPostContext | Out-File $outputPrivateKey -Encoding ASCII -Append
$cert.line| Out-File $outputPublicKey -Encoding ASCII
$cert.Context.DisplayPostContext | Out-File $outputPublicKey -Encoding ASCII -Append


#Get rid of the temporary working file. Not needed for those not using the script. 
Remove-Item $tempFile -Force

Even if you can't run that hopefully you can decipher what's going on. Let me know if you would like any help.

Export The CA Certs and Copy to Server

For Clients: You can use the CA cert you created earlier for the server on the client as well. Just include it in the keys directory with the other certs. 

1. Using the MMC or cmdline/powershell, export the root and (if applicable) intermediate certs to base-64 encoded x.509. For specifics, see here.
2. If using 2 or more tier PKI: You can only specify one CA cert so if you have more than one CA in your chain you need to "stack" them. To do so, pipe both into one file with the simple command from a command prompt: "type RootCA.cer IntermediateCA.cer > CAs.cer" where rootca.cer and intermediateca.cer are the exported certificates. Substitute cat for type if you're doing this on a Linux platform. This will join any listed certs into one chain for use with OpenVPN. 
3. (For Clients: This step is not necessary.) Generate Diffe-Helman by executing

   openssl genpkey -genparam -algorithm DH -out dh.pem 1024

   This can be done on either the Windows machine you are on or directly on the OpenVPN server. Either way, just make sure you copy the dh.pem to /etc/openvpn/keys/ on the OpenVPN server. (see step below)
4. Copy the server private key, public key (both created earlier) and (stacked) ca public key to "/etc/openvpn/keys" on the OpenVPN server. These keys will be referred to as server.cer, server.key, and ca.cer in the future. In order to do security correctly, make sure permissions are cranked down on these files as much as possible, especially the server.key file. (private key) On Windows I use pscp.exe which ships with Putty. For Clients: Just copy the certs/keys into a temp directory for now, we'll move them to the final location later.

Install/Configure OpenVPN on Server

1. Make sure you enabled EPEL above and then execute the following to to install OpenVPN and LZO:

   yum install openvpn lzo -y

2. Copy the sample configs as a starting point:

   cp /usr/share/doc/openvpn-2.2.2/server.conf /etc/openvpn/

   (Make sure the version number in the /usr/share/doc path hasn't changed since I wrote this) 


3. Edit /etc/openvpn/server.conf and pay attention to the following lines: 
1. Set the ipaddress to the address of the NIC you intend to bind to. This should be the NIC closest to the internet, be it an external or DMZ NIC. 

   local 10.1.0.1

2. Set the port to have OpenVPN listen on. 1194 is default and a firewall rule below assumes that, so be aware if you change it.

   port 1194

3. Protocol, UDP vs. TCP. UDP is faster and the client machine will already be managing TCP retrans should they be needed. 

   proto UDP

4. A bit on the the difference between tun and tap: tun is a layer 3 IP routing based solution, whereas tap is a level 2 based solution. Tap can shoot non-routable protocols over the tunnel, so if you're going to play Descent II this is the one you want. The problem (or not) with using tap for standard client connectivity is besides being more complex to setup it also routes broadcast traffic. This won't scale well. Generally tap is used for site-to-site connections. If you want to use tap, you'll need to setup Ethernet bridging. This guide assumes dev tun.

   dev tun

5. Specify the keys we copied over earlier:

   ca /etc/openvpn/keys/ca.cer
   cert /etc/openvpn/keys/server.cer
   key /etc/openvpn/keys/server.key

6. Specify Diffe-Helman copied over earlier:

   dh /etc/openvpn/keys/dh.pem

7. Set the subnet you want to route clients to. This makes that network route through the OpenVPN connection. Note that if your IP range is the same on the close end you'll have problems. Feel free to add multiple lines for multiple subnets.

   push "route 192.168.1.0 255.255.255.0"

8. Set the internal DNS servers you want to push to the clients to facilitate looking up servers on the other side of the VPN. Add one line for each DNS server you would like in the search order of the client. 

   push "dhcp-option DNS 192.168.1.30"

9. If you uncomment client-to-client OpenVPN will allow clients to talk to each other. You'll also need to config firewall rules appropriately should you wish to do this.

   client-to-client

10. Set the maximum number of simultaneous clients.

    max-clients 100

11. Uncomment the following lines to increase security on 'nix systems by lowering privilege level after program launch.

    user nobody
    group nobody

4. Set OpenVPN to start on boot:

   chkconfig openvpn on

5. Configure the IPTables firewall; assuming eth0 is your internal NIC and eth1 is your external NIC. Change the listed NICs in each rule if that assumption is not correct!
1. Edit the IPTables rule by editing /etc/sysconfig/iptables . There are other ways to accomplish IPTables editing, but since I make few changes I would rather just work directly on the config.
2. First, change your SSH rule to allow port 22 on the internal NIC only; you should already have a rule listing --dport 22. Find it and change it to:

   -A INPUT -i eth0 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT"

3. Allow VPN connections on the external interface. If you have changed from the default port make sure to change the port 1194 reference listed here: " -A INPUT -i eth1 -m state --state NEW -m udp -p udp --dport 1194 -j ACCEPT"
4. Setup forwarding rules for this network:

   -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT"
   -A FORWARD -s 10.8.0.0/24 -j ACCEPT

5. Make sure the rules from 2 and 3 are listed before the -A INPUT -j REJECT and the rules from 4 are listed before the -A FORWARD -j REJECT default rejection rules or they'll be ignored. 
6. Reboot the box and ensure that OpenVPN starts successfully. Logs will be written to /var/log/messages. If you have problems and need to troubleshoot you can up the "verb" value in /etc/openvpn/server.conf.

Alternatively, you may see rules listed such as iptables -A INPUT -i tun0 -j ACCEPT and iptables -A FORWARD -i tun0 -j ACCEPT listed elsewhere; these would work in lieu of the 10.8.0.0 rule, but there are security tradeoffs. Feel free to try either if it suits you. For more information about iptables, see this.

Enroll for Client Certificate

For this section you can follow the same instructions as the section "Enroll for Server Ceritificate" with the modifications listed within those points. (Mods in point 2, 3, and 5)

After doing this refer to the Export and Split the Certificate section and use that logic to do the same task to the client cert as well.

Export the CA Certs and Copy to Client

You can use the CA cert you created earlier for the server on the client as well. Just include it in the keys directory with the other certs.

Install/Configure OpenVPN on Windows Clients

1. Download and install from here. 
2. In the install directory, copy the client.ovpn file from the sample-config folder to the config folder for a starting point.
3. Copy the keys we created earlier to a folder on the client; I use (OpenVPN Install Directory)\Keys.
4. Edit ".\config\client.ovpn" and pay attention to the following lines: 
1. Again, we're going to cover tun here. More work will be necessary if you want to do tap. See the server section for an explanation of what these options are. 

   dev tun

2. Enter the external FQDN and port for your OpenVPN server.

   remote vpn.company.com 1194

3. List your certs copied over earlier. Make sure you set the directory correctly and protect that directory relative to the fact that a private key resides within it. On windows you need to use double backslashes because "\" is an escape character. 

   ca C:\\InstallDirectory\\Keys\\ca.cer
   cert C:\\InstallDirectory\\Keys\\clientcert.cer
   key C:\\InstallDirectory\\Keys\\clientcert.key

4. Remark out ns-cert-type server and add remote-cert-tls server in its place. ns-cert-type is deprecated and the template wasn't updated. See here for more info.

   # ns-cert-type server
   remote-cert-tls server

5. After saving the file, launch OpenVPN GUI as Administrator.





6. Connect and enjoy!

Closing

Obviously given the scope of this article there is substantially more depth one could go into; if you have any questions please hit me up in the comments. I'm sure you can see the possibilities of this combination as there is much more automation that could be done. Thus far I've been very impressed by the performance of OpenVPN and I look forward to scaling it out in the future.

References/Additional Reading

• Official OpenVPN HowTo
• CentOS IPTables HowTo
• SafeSrv: OpenVPN on CentOS
• Serverfault question: OpenVPN/Correct IPTables setup
• Jay Libove: Using Windows AD CS to Create Certificates for OpenVPN
• Christoph's OpenVPN Mini-FAQ
• Topdog.za.net: Setup a OpenVPN server on Centos 6
• OpenVPN Forums: Using a Windows CA
• MSFT Ask the Directory Services Team:Enabling CEP and CES for enrolling non-domain joined computers for certificates
• Serverfault question: OpenVPN + iptables/NAT routing
• Bitcube.co.uk: OpenVPN HowTo

Using a Raspberry Pi as a Thin Client for RDP/RemoteFX/VMWare View or Citrix

There is a cool project by Gibbio at blogger that uses Debian Linux as a base turn the Raspberry Pi into a thin client that works with RDP, VMWare View, Citrix, OpenNX, and Spice.  After imaging your SD card you can plug and go. I've tested it with RDP complete with RemoteFX, and it works well with a few caveats which I'll note below.

Requirements

• Raspberry Pi Rev B with a network connection, monitor, kb, etc.
• A SD card at least 2GB in size. The faster the better. 

Let's Set it Up

1. Insert the SD card to a workstation to image it. On that workstation: 
2. Download the ISO. Links here.
3. Unpack the ISO to a temporary directory. 
4. If you're on Linux, skip to step 6. Download DD for windows from here.
5. Unpack DD to a working directory and make note of where it is; we'll be using it in a moment. 
6. Insert your SD card and wipe out all partitions on it. I'll assume you know how for Linux; in Windows use Diskpart: Diskpart (Enter), List Disk (Enter), Select Disk X (Enter), List Partition (Enter), Select Partition X (Enter), Delete Partition (Enter). Repeat list, select, delete for each partition on the SD card then Exit (Enter). Make sure you don't execute this sequence on any other drives or you will loose all your data!
7. Image the drive using DD: dd bs=1M if=c:\temp\RPi-TC_ARMv6j_r1.img od=d: WHERE: c:\temp\RPi... = the image location and od=d: references the location of the SD card. Update: If you have issues with dd, give Roadkill's disk imager a try. 
8. Remove the SD card (properly) and insert it into the Raspberry Pi
9. Start it the Pi. 

 

Using RDP

Once the Pi Boots (Note that boot animation) you'll see a bunch of icons on the desktop. To connect to an RDP session, do the following:

1. Double click on X2Go Client 
2. Click the "New Session" button in the upper left corner. 
3. Name the session, enter the host (make sure the host name corresponds to the cert CN)
4. Enter your login as domain\username
5. Change "Session Type" to "Connect to Windows terminal server" and check the "Direct RDP Connection"
6. Click the "Settings" tab and change the Display to the desired resolution. (Fullscreen works) Note that I haven't been able to get xfreerdp to work yet but rdesktop is working. 
7. Click "OK"
8. Click the newly created session and then enter in your password. 
9. Enjoy your RDP session! If you selected Fullscreen, note that the kb combo to go back to a window is CTRL+ALT+ENTER

RDP Notes: 

• As of now it seems that NLA is not supported, though I'm looking into it. To disable NLA uncheck the box labled "Allow connections only from computers running Remote Desktop with Network Level Authentication" in the "Remote" tab of the advanced system properties dialog of the machine you're connecting to.
• RemoteFX works, but it is actually slower than standard RDP. I'm looking into this too.
• Audio redirection, clipboard, multitouch, and USB passthrough don't seem to work. Guess what, I'm looking into that. 

Misc Notes:

• I haven't tried the other clients yet, though I can report success using the VMWare view client direct from a friend. 
• The Raspberry Pi has issues with some mice. If your mouse seems unresponsive try a different model. 
• The newest build uses a tweaked kernel. Though I haven't needed to, you can switch back to the standard Raspberry Pi kernel by changing the line kernel=kernel.img to kernel=kernel-std.img in /boot/config.txt and rebooting. Debian comes with Vi and Nano that you can use to modify it.

Overall this is a interesting project that has been alot of fun to play around with. As always if you have any questions or comments throw them in the comments section!

Update: I'm getting quite a few hits on this one and I just want to underscore before it is proposed in production at your company that it's not quite ready for prime time yet due to the issues listed above. I look forward to helping drive it there though; I intend on updating as I drive towards tweaking RDP to be perform better.

And more importantly, there is a new build posted here! Note Remmina isn't working yet but Gibbio is working on it.

Update 6/27:  Gibbio has posted a new build that looks quite interesting. Among other things he has provided the XFCE desktop environment.

Update 7/1: The newest build works fine with xfreerdp which seems to perform a bit better than rdesktop. To use it, either launch from a terminal or create a shortcut with the following syntax:

xfreerdp /v:server.domain.ext /u:UserName /p:Password /d:DOMAIN /f /cert-ignore

Where: /v: is the target machine, /u: is the username to use, /p:is that user's password, /d:is the domain in which the user resides, /f is for fullscreen mode (if desired) and /cert-ignore is to ignore an untrusted cert, which is likely if you're using the default self-signed certs. For the rest of the options, see the wiki page.

Links: Olivier Muret: French Raspberry Pi RDP Writeup

Thanks for reading!

What is RemoteFX on Windows 2012 Hyper-V and Deploying a Win 8 Virtual Desktop

Updated 2/3/2017 for Windows Server 2016 and Windows 10!

RemoteFX is Microsoft's advanced desktop RDP solution based on technology acquired from Calista Technologies. It allows for the following functionality above and beyond standard RDP:

This Article Written in RemoteFX. It's... amazing?

Server 2008r2 Based:

• Virtualized 3d GPU: you can split a single GPU into multiple virtual GPUs for VDI VMs. This allows for 3d accelerated apps to run in the RDP session.
• RemoteFX Codec: A more advanced version of the RDP compression scheme that allows for more efficient streaming of both video and audio. While it works fine for text, you can always get groceries in a Yugo. 
• USB Device redirection: Now you can finally use your USB Scan Toaster on your remote desktop!

Server 2012 Additions: 

• Multi-Touch: Multi-Touch support through RDP. Needs a compatible client! (RDP 8.0, etc.)
• Adaptive Graphics: Different compression codecs depending on the content (dynamically on a given screen) among other enhancements. 
• Media Redirection API: Used primarily to facilitate rendering audio and video of VOIP clients local to the client. (Only Lync right now) 
• WAN Enhancements: Support UDP; tweaks to lower bandwidth requirements for both remote and WiFi scenarios.  
• GPU Changes: Support either a software-emulated GPU or a real hardware GPU. DX11 support added. 

Server 2016 Additions: 

• OpenGL/CL Support: Now supports hardware-accelerated OpenGL (^4.4) and CL (^1.1)... CAD/Lightwave/Photoshop users rejoice!
• vRAM Assignment Enhancements: Decouple vRAM amount from monitors and resolution, increased dedicated vRAM per host capability to 1GB from 256MB. 
• Better Performance: More FPS=smoother performance. Noticeable in my case, videos now watchable through RemoteFX without the audio issues that sometimes accompanied the prior version. 
• Generation 2 VM Support: Allows for use of the new VM platform and all the associated features. 
• ... and more, see the reference links at the bottom of this article.

Hardware Requirements:

Full MSFT Article , RDS Blog reqs link

• The standard HyperV Requirements
• SLAT Enabled CPU; EPT on Intel, NPT/RVI on AMD
• DX11 (WDDM 1.2) Compatible GPU; All made for purpose DX11 GPUs from NVIDIA and AMD work, and for testing I've been using a consumer grade NVIDIA 650 in my lab without issue.

Software Requirements:

• Server: Server 2012/2016 (core preferred, see next section)
• Client: Windows 8/10 Enterprise, and Enterprise only. Pro won't work. Additionally, I found that re-keying a Win8 Pro to Enterprise install will not work either. While it will report that all is well, and it will install the RemoteFX graphics adapter, when you try to connect it will report "error during licensing protocol" in the final stage of connection negotiation.

Setup

Assumptions

• You have a fully functional HyperV Host that meets the hardware requirements listed above.
• You're using server core. You can do this on standard, but you should be using core for performance and patching (or lack thereof) reasons. The commands I relay assume core. 

Prepare the Host

1. Patch it up; make sure you're fully up to date. 
2. Install the graphics drivers for your GPU on the host. This may pose some issues on server core, but fortunately I've got a guide for NVIDIA GPUs to help. The procedure is most likely similar for AMD GPUs. Bounce the host after driver install regardless of if it tells you to do so or not. 
3. Install the Remote Desktop Virtualization Host feature. Either use the server manager remotely to do so, or execute the following directly on the Hyper-V host: "Install-WindowsFeature –name RDS-Virtualization -source j:\sources\sxs" where J: is the DVD-ROM or image with the 2012 install bits. You can use other sources if desired, for more information see this post.
4. Reboot the server. 
5. Enable the Adapter for use with the Hyper-V host by opening the Hyper-V management console, right click the server->Hyper-V Settings....
6. Select "Physical GPUs"
7. If configured correctly, you should see your adapter listed. Check the "Use this GPU with RemoteFX" box and click "OK". 

Alternatively for steps 5 through 7 you can use the following powershell cmdlets: 

• Get-VMRemoteFXPhysicalVideoAdapter
• Enable-VMRemoteFXPhysicalVideoAdapter

Setup The VM

1. As noted above, only Win 8 (7 if you want, update + 10) Enterprise will work. Use a template or build from scratch. There are no special needs at build time. 
2. Enable RDP on the Win8 VM
3. Install the VM Integration services & shut down the VM
4. Add a 3D Adapter to the VM by opening the Hyper-V management console, right click the VM->Settings
5. Under "Add Hardware" select "RemoteFX 3D Video Adapter", click "Add", select the max resolution and # of monitors you plan on using via RDP, and select "OK"
6. Start up the VM. You now will need to logon via RDP, as the Hyper-V remoting will be locked out. The machine should notify of new hardware being installed that requires a reboot. If it does not, re-install the integration services. Reboot the VM. 
7. To ensure the VM is operating with the adapter open device manager and look under "Display Adapters". You should see "Microsoft RemoteFX Graphics Device - WDDM"

Alternative Powershell Command:

• Add-VMRemoteFx3dVideoAdapter

Configuration

Note that unlike the previous version of RDP, you don't need to select your connection speed on RDS 8.0. So that said, the only configuration you really need in 8.0 can be done via GPO.

Adjust Settings via GPO

Primer: Modifying GPO settings.

Microsoft makes some RemoteFX settings "Tweakable" via GPO. These settings can be found here:

Computer Configuration->Policies->Administrative Templates->Windows Components->Remote Desktop Services->
  Remote Desktop Connection Client->RemoteFX USB Device Redirection
     -Allow RDP redirection of other supported RemoteFX USB devices from this computer
  Remote Desktop Session Host->Remote Session Environment
     -Configure compression for RemoteFX data
     -Configure image quality for RemoteFX Adaptive Graphics
     -Enable RemoteFX encoding for RemoteFX clients designed for WindowServer 2008r2 SP1
     -Configure RemoteFX Adaptive Graphics (Tweak if using only on a LAN)
     RemoteFX for Windows Server 2008 R2
        -Configure RemoteFX (this just allows for disabling RemoteFX via GPO)
        -Optimize visual experience when using RemoteFX (Tweak this one if using only on a LAN)
        -Optimize visual experience for Remote Desktop Service Sessions (Change to "Text" if you setup RemoteFX so Bobby can do his spreadsheets. Why did you setup RemoteFX again?)

Troubleshooting

 

Sound isn't working on the youtubes! : Seems like flash doesn't work correctly with audio redirection. HTML5 works though! Switch to the HTML 5 beta by going here.

Seems Slow: Make sure your color depth is set to 32bit. Based on my testing it seems that the codec favors full 32 bit color.

FAQ (By me of myself @ least, and by frequently I mean once until I answered them)

• Q: Should I want to, what can I use to benchmark this thing?  A: PassMark works great; I must admit that watching DX11 accelerated 3d benchmarks through an RDP session is kind of cool. :) 
• Q: Does RemoteFX work through an RDP gateway? What versions? A: Yup, it works through a gateway running on 2008, 2008R2, or 2012.
• Q: Is GPU performance good enough to run intensive applications or GPU computation tasks? A: In most cases, no. The RemoteFX solution virtualizes the GPU and exposes it as a Microsoft "GPU", essentially translating all requests through a proxy driver. While that solution allows for splitting the GPU across multiple VMs, it also makes for reduced functionality/performance of the card since the OS isn't exposed directly to the native driver. Additionally, framerate is limited by the RDP protocol itself.
• Q: Does RemoteFX support accelerated OpenGL? A: No, it is done in software.
• Q: Can RemoteFX do GPU direct passthrough? A: No, only Xenserver Enterprise or higher can do that right now. 
• Q: How do I know how much memory on my GPU is being used by my VMs? A: You can find the answer on the Hyper-V/Physical GPUs page for each server. The memory stats are listed right under GPU Details->Summary. 
• Q: Can I deploy RemoteFX in a VDI environment? A: Yeah, though note your max simultaneous RemoteFX sessions will be limited by available GPU memory. (See above post) Fortunately for you, I have a guide on how to setup Hyper-V based VDI!
• Q: Will this VMWare tweak help up the framerate on Hyper-V/RemoteFX? A: In my testing, it did not. I suspect this is because the HyperV NICs probably don't support interrupt coalescing. It looks like one could enable interrupt coalescing on the host with the following instructions and perhaps that would change the answer depending on how the packets are handled from the RemoteFX machine. 

References

Microsoft: What is RemoteFX?
RDS Blog: RemoteFX Features for Windows 8 and 2012
Technet: Frequently Asked Questions and Troubleshooting Tips
RDS Blog: Your desktop will be a rich DX11-based experience, and your virtual GPU should be too
My Crazy Adventures with RemoteFX, Part 1

2016 Updates

Enterprise Mobility and Security Blog: RemoteFX vGPU Updates in Windows Server Next
Technet: Experience guide for Enabling OpenGL Support for vGPU in Server 2016

Questions/Concerns? Contact me or leave a comment!

Azure Ate My VM! Or: How to Get Your VM Back

If for any reason your Azure account is suspended (exceeding 90 day compute per month, exceeding monthly spending limit) your IaaS VMs will be deleted. It would appear as if this is normal. Fortunately your disks associated with your VM are not deleted, so we can recover. Hopefully, this is something Microsoft addresses in the near future. For now, let's fix it!

Oh No! Peaches02 is missing!

 

Fix It

1. First we'll need to reclaim our DNS address. To do so, click on "Cloud Services" and delete the cloud service that is squatting on the name of your old VM you want to recreate.
2. Now we will recreate the VM using our pre-existing disk. Fortunately, this disk will present itself in the "gallery". Click "New" on the lower left. 
3. Select "Compute"->"Virtual Machine"->"From Gallery". You'll see your disk in there. Select it.
4. Set the name to the same as it was before. The size though, can be changed if you like. (For example, I took mine from medium to small)
5. Set the DNS name to the same as it was before, and select the region as you desire. 
6. Associate with an availability set if you like and fire it up!

 

Notes: 

Your RDP port will probably change because of the way MSFT does Natting for the virtual IPs. I was honored to have 3389 on my vm for the first go-around, but when I set it up again MSFT had already given that port back out. It will automatically create a new NAT (endpoint) mapping, so to determine the new port navigate to virtual machines->(VM)->endpoints and take note of the new RemoteDesktop port.

All your endpoints will be deleted. This can be a real pain if you have alot, but fortunately I have a solution for that.

If there are any questions, let me know. Happy clouding!

CentOS ready for Hyper-V 2012 NICs

CentOS 6.4 was released on March 13th, and per the release notes it now ships with the Hyper-V components. Now the native network adapters work right from the base install, even on the minimal distribution. All that need be done is enable the adapters after install. To do so, do the following:

• Log in as root
• Navigate to /etc/sysconfig/network-scripts
• Each NIC config is located in this directory. The configs are named ifcfg-ethX where X is a number starting with 0 and incrementing by 1 for each adapter, i.e. ifcfg-eth0, ifcfg-eth1. Edit each by typing "vi ifcfg-eth0"
• At the least, you will need to edit the file to change ONBOOT=no to ONBOOT=yes by using the following keys:
• INSERT
• (make your modifications)
• ESC
• :w
• :q
• Reboot

If you want to make further modifications such as static IP, etc, then refer to this guide. Feel free to post questions!

Update 12/8/2013: 

When updating/rebuilding my Hyper-V hosts from 2012 to 2012 r2 the MAC addresses seem to have changed. (Perhaps a good reason to set static MAC addresses on these VMs) You can see if your install exhibits this behavior by examining the following:

•  cat /var/log/dmesg | grep -I "net"

and looking for:

hv_netvsc vmbus_0_13: Device MAC XX:XX:XX
and
udev: renamed network interface ethX to ethX

To fix it, edit the ifcfg-ethX file as noted above and change the HWADDR entry to match the new MAC, and then remove the /etc/udev/rules.d/70-persistent-net.rules file and reboot.