DirectAccess 2012 Yenilikleri

DirectAccess ilk olarak Windows Server 2008 R2 ve Windows 7 işletim sistemi için sunulan, uzun zamandır kullanılan VPN teknolojisinin eksik olan yanlarını tamamlayan uzaktan erişim teknolojisidir.

Günümüz BT dünyasında mobil kullanıcı sayısı önemli ölçüde artmıştır. Bu kullanıcılar tarafından esnek çalışma olanağı olarak algılanmasına rağmen sistem yöneticileri tarafından ise bir güvenlik riski olarak görülebilir. Şirket ağında olan kullanıcıları var olan şirket güvenlik poliçeleri ile yönetmek oldukça kolaydır. Ancak mobil kullanıcıları yönetebilmek için onların şirket ağına VPN benzeri yöntemler ile bağlanmaları beklenir.

Kullanıcılar ise şirket kaynaklarına erişmek istediklerinde kendileri için tanımlanan VPN çözümüne ait istemci programını her seferinde çalıştırmak durumunda kalmaktadırlar. Herhangi bir bağlantı problemi gerçekleştiğinde kullanıcının bu bağlantıyı tekrar elle sağlaması gerekmektedir.

DirectAccess'in sunduğu teknoloji ile birlikte şirket kullanıcılarına ait mobil bilgisayarlar sürekli IPSEC tüneli üzerinden şirkete bağlı durumda kalır. Bu sebeple kullanıcının şirket ağına bağlanmayı düşünmesine gerek kalmamaktadır. Aynı şekilde sistem yöneticileri de kullanıcı bilgisayarlarını şirket dışında olduklarında dahi kesintisiz bir şekilde yönetebilme şansına sahip olurlar.

Windows Server 2012 ile birlikte sunulan DirectAccess yenilikleri aşağıda incelenmiştir:

  • Windows Server 20008 R2 işletim sistemi içerisinde RRAS ve DirectAccess'i bütünleştirmek uzak istemci bağlantılarında bazı sorunlara sebep oluyordu. DirectAccess IPv6'ya bağımlı çalışırken, RRAS IKEv2 IPSEC kullandığı için DirectAccess trafiği RRAS-VPN tarafından engelleniyordu. Windows Server 2012 içerisinde DirectAccess ve RRAS tek bir rol altında birleştirildi bu sorunlar giderildi.
  • Windows Server 2012 ile birlikte sunulan en önemli DirectAccess yeniliği bir PKI ihtiyacının ortadan kalkmasıdır. Artık istemci kimlik doğrulama istekleri DA sunucusu üzerinde çalışan Kerberos Proxy servisine geliyor ve bu servis istekleri istemcinin yerine Domain Controller sunucularına gönderebiliyor.
  • Windows Server 2008 R2 sürümünde NAT64 ve DNS64 çevirimleri için UAG kullanılıyordu. Windows Server 2012 DirectAccess ise kendi içerisinde NAT64 ve DNS64 çevirimleri yapabiliyor. Bu sayede IPv6 kullanan bir istemci şirket içerisindeki IPv4 kaynaklara ek bir ürün gerektirmeksizin bağlanabiliyorlar.
  • Windows Server 2008 R2 DirectAccess kurulumu için ön gereksinimlerden birisi de DA sunucusunun en az iki network kartına sahip olmasıydı. Windows Server 2012 ile birlikte DA sunucusu bir NAT cihazının arkasına yerleştirilebilir ve tek network kartı ile çalışabilir. Bu aynı zamanda diğer bir gereksinim olan public IPv4 adres kullanımını da ortadan kaldırmıştır.
  • Windows Server 2012 DirectAccess özelliği Windows Network Load Balancing ile birlikte kullanılarak tam anlamıyla bir yüksek erişebilirlik ve yük dağıtımı senaryosu sağlanabilir.
  • DirectAccess artık farklı domainlere dahil olan istemcilere de hizmet verebilir.
  • OTP çözümleri ile RSA SecurID gibi ekstra güvenlik katmanı ihtiyacı duyan şirketler için Windows Server 2012, smart-card ve OTP temelli çözümlere destek vermektedir.
  • Windows Server 2008 R2 ile birlikte sunulan Force Tunnelling özelliği sayesinde DirectAccess ile bağlı olan istemcilerin tüm trafikleri istenildiği takdirde DirectAccess tüneline yönlendirilebiliyordu. Bu özelliğin aktif edilmesi için Group Policy içerisinde elle ek yapılandırmaların yapılması gerekliydi. Windows Server 2012 ile birlikte bu özellik kurulum sihirbazında aktif edilebilir duruma getirildi.
  • Diğer tüm özelliklerde olduğu gibi DirectAccess kurulum ve yönetimi için de Windows PowerShell desteği sağlandı.
  • Windows Server 2012 DirectAccess konsolunda Monitoring isimli yeni bir bölüm tasarlandı. Bu bölüm içerisinde aşağıdaki bilgiler görüntülenebilir duruma getirildi:
    • Toplam aktif istemci sayısı (VPN ve DirectAccess)
    • Toplam aktif DA istemci sayısı
    • Toplam aktif VPN istemci sayısı
    • Toplam tekil bağlı kullanıcı sayısı
    • Son sunucu sistem başlangıcından itibaren maksimum uzak istemci bağlantı sayısı
    • Toplam veri transferi

BranchCache Güvenlik Önlemleri

BranchCache, Windows Server 2008 R2 ve Windows 7 ile birlikte sunulan, Windows Server 2012 ile birlikte ise bazı geliştirmelerin yapıldığı geniş alan ağı (Wide Area Network) bant genişliği optimizasyonunu sağlayan bir teknolojidir. Uzak ofislerde bulunan kullanıcılar geniş alan ağı bant genişliğini kullanarak merkez ofis üzerinden bir dosyayı kopyalamak istediğinde, BranchCache bu içeriği kopyalayarak ön belleğine alır ve uzak ofiste aynı dosyaya tekrardan erişim sağlayan kullanıcıların bant genişliğini kullanmadan ilgili içeriğe yerel ağdan erişmelerini sağlar.

BranchCache teknolojisi ile birlikte akıllarda oluşan temel kaygılar genellikle güvenlik eksenli olmaktadır. Kritik verinin belli bir sunucuda ya da istemcilerin üzerinde tutulması bazı güvenlik açıklarına sebep olabilir mi? Zararlı bir yazılım ön belleğe alınan bu verinin içine yerleşebilir mi? BranchCache hangi verileri Clear-Text (Şifrelenmemiş Metin) olarak saklar?

Var olan bu kritik verinin korunması için BranchCache varsayılan olarak bazı güvenlik önlemleri ile gelir. Bu önlemler aşağıda incelenmiştir:

  • Kimlik doğrulama domain kimlik bilgileri kullanılarak gerçekleştirilir.
  • Yetkilendirme Access Control Lists (ACL) kullanılarak gerçekleştirilir.
  • Dosya ön bilgileri HTTP, HTTPS ve SMB kullanılarak dolaştırılır.
  • Dosya ön bilgileri dosyanın kendisi, algoritma, blok boyutu ve sunucu anahtarı gibi değerler kullanılarak hash lenir.
  • Önbellekte tutulan verinin dolaşımı için Peer Content Caching ve Retrieval Framework protokolleri kullanılır.
  • Hash lenmiş dosya ön bilgisi aşağıdakileri içerir:
    • Block Hash List: Hash lenmiş veri blokları.
    • Hash of Data: Block Hash List tarafından oluşturulur.
    • Segment Secret: Yetkilendirilmiş istemcilere gönderilen içerik temelli hash.
    • Hash of Data ve Segment Secret istemci tarafından alındığında Segment Secret şifreleme anahtarı olarak kullanılır. Bu ikisi kullanılarak Segment ID oluşturulur.
    • İstemci Segment ID'yi kullanarak içeriği kendi yerel ağında bulmaya çalışır. Bulamaz ise sunucuya istek göndererek WAN üzerinden yüklemeye başlar.

Yukarıdaki hash adımları ile birlikte gönderilen tüm veri blokları ilgili anahtarlar kullanılarak şifrelenir.

İstemciler ilgili verinin yerel ağ üzerinde nerede olduğunu öğrenmek için Web Services Dynamic Discovery (WS-Discovery) protokolünü kullanır. Bu noktada tüm istemcilere ulaşılması gerektiği için Probe mesajı ağa yayılır. Bu mesajın içerisinde Segment ID kullanılarak istemcilerin talep ettiği içerik ile ön belleklerinde tuttukları içeriğin aynı olduğu doğrulanır. Aynı şekilde bu durum kritik veriyi açığa çıkarmak isteyen bir saldırganın da şifreleme anahtarını bilmesini gerektirir.

İstemciler arasında var olan tüm trafik genel bir şifreleme standardı olan AES 128 ile şifrelenir. Bu yüzden ilgili trafiği dinlemek isteyen bir saldırgan yalnızca şifrelenmiş veriye ulaşabilecektir. Aynı şifreleme, içerik sunucularından indirilen dosya bilgi paketleri için de geçerlidir.

Denial of Service (DoS) atakları ile istemcinin cevap veremez duruma gelmesinin önüne geçilmesi için BranchCache kuyruk yönetimi sayaçları ile birlikte çalışır ve bu durumun önüne geçer.

>İstemciler Hosted Cache modu ile çalışırken Hosted Cache sunucusuna, sunucunun FQDN (Fully Qualified Domain Name) bilgisini kullanarak ve BranchCache tarafından dinleme amaçlı kullanan TCP portu üzerinden erişim sağlarlar. Hosted Cache sunucusu üzerindeki sertifika, dinleme için kullanılan bu porta atanmıştır. İstenirse Hosted Cache sunucusu “Require Client Authentication” ayarı ile yapılandırılarak istemcilerin ve kendisinin HTTPS kimlik doğrulamasını desteklemesini sağlar.

Hypervisor Early Launch

One of the interesting architectural changes in Hyper-V 2012 Server is the boot order. In Windows Server 2008, first booted partition was the OS in parent partition. After booting partition it was launching Hypervisor using hvboot.sys.

hvboot.sys was performing following actions:

  • Detects whether a hypervisor is already loaded or not
  • Determines processor if it is Intel or AMD
  • Loads hypervisor image
  • Invokes hypervisor launch code
  • virtual processor is created

In Windows Server 2012 and Windows 8, now it does early launch of hypervisor before OS and applies microcode updates needed. Therefore OS in the parent partition is booted on a Virtul Processor.

This change also allows you to be able to manage more than 64VPs.

WS-Management / WinRM Standards

In 2005, Microsoft submitted WS-Management for DMTF standardization along with 12 other companies.  It simply provides a standard for building XML messages using web service standards. It can be used to manage PCs, devices, Web services and other manageble entities. The messages that are provided by WS-Management are the conventions of Simple Object Access Protocol aka SOAP.

SOAP is a protocol specification relies on XML for its message format. It allows for the use of different transport protocols and uses HTTP as a transport protocol.

As for WinRM, it is the implementation of WS-Management protocol by Microsoft. It provides a firewall-friendly, HTTP based way to manage hardware and operating systems across different vendors. Moreover Windows PowerShell remote feature works on WinRM technology. You can manage not only Windows systems but also non-windows systems such as Unix computers. Windows systems are managed over WMI and non-windows systems are managed over DCOM.

All data that is captured using WinRM are formatted in XML as follow:

image

As of January 30, 2013, WS-Management was adopted as an international ISO/IEC standard.

http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2fIEC+17963%3a2013#.UU-C1Rwqw6s

That is really really important since that means using WS-Management protocol to manage complex systems will be much more simplified. All new System Center components and Windows Server 2012 aka Cloud OS are using WS-Management and Win-RM.

That is exactly means that, if you decide to manage your cloud environment with System Center and Windows Server 2012, you will also have ISO/IEC standard while managing remote systems.

In addition to this, Microsoft has designed Open Managed Infrastructure (OMI) as an open source project. It helps you to implement a standards-based management service into any device from a free open source package using WS-Management ISO/IEC standard.

SSO (Single Sign On) thoughts on RDS (Remote Desktop Services) 2012

Recently for one of my enterprise banking customers, I configured SSO for Windows Server 2012 Remote Desktop Services solution.

But, while I was searching for a possible solutions, I figured out that very first thing you need to make sure is “for which part of RDS do you  want to enable SSO”? This is a critical question since if you search for a SSO solution in RDS, most probably you will come up with the following article:

http://blogs.msdn.com/b/rds/archive/2012/06/25/remote-desktop-web-access-single-sign-on-now-easier-to-enable-in-windows-server-2012.aspx

Actually yes, this is the correct article which allows you to configure SSO for the new version of RDS. Let’s discuss a little bit.

If you want to enable SSO for your Remote App programs you need to modify “Credentials Delegation Group Policy” setting to add server lists as “TERMSRV/ TSNAMES”. You can reference following article to configure this specific policy:

http://blogs.msdn.com/b/rds/archive/2007/04/19/how-to-enable-single-sign-on-for-my-terminal-server-connections.aspx

If you configure above settings you will have  a SSO feature for Remote App sessions. For instance if your domain users log on their computers using domain credentials, they will not need to re-enter their credentials for RemoteApp programs.

But you may want to enable SSO for one another component of your RDS design: RD WEB ACCESS web page.

If your users will browse RD Web Access page to start RemoteApps, you may want prevent additional credential form on RDWEB page. Because even you configure above SSO settings, users still will need to authenticate using IIS form based authentication. see below,

image

If you want to enable SSO for above form based authentication page you need to hack web.config file of your RDWEB site. To achieve this:

  • Navigate C:WindowsWebRDWebPagesweb.config
  • To turn on Windows Authentication:
                  – uncomment <authentication mode="Windows"/> section
                  – and comment out:
                  1) <authentication mode="Forms"> section.
                  2) <modules> and <security> sections in <system.webServer> section at the end of the file.

After that on ISS Manager, for RDWEB directory, enable Windows Authentication and disable Anonymous Authentication, restart IISADMIN service.

Now if your users browse rdweb page, their logged on credentials will be used to authenticate across IIS.

But I figure out one another problem for this scenario. If I configure SSO for both components (RemoteApp and Form Page), Remote App SSO is not working as expected. Your users should tick following checkbox if they want to enable SSO for RemoteApp.

clip_image002

You can also configure default.aspx located in the RDWebPagesen-US directory.

change below line

public bool fUserAdmin = false, fConfigPage = false, bShowPublicCheckBox = false, bPrivateMode = false;

to

public bool fUserAdmin = false, fConfigPage = false, bShowPublicCheckBox = false, bPrivateMode = true;

or in body tag add bold text below

<body onload="onPageload(event); document.getElementById(‘WebPartManager1_TSPortalWebPart1PublicCheckbox’).checked=true;" onunload="onPageUnload(event)">

now checkbox will be enabled by default.

Windows Server 2012 Direct Access Part 2–How to Build a Test Lab

Here is the second part of Windows Server 2012 Direct Access blog series.

Part1: http://blogs.technet.com/b/meamcs/archive/2012/05/03/windows-server-2012-direct-access-part-1-what-s-new.aspx

In the first post we discussed what’s new and what are the design differences between new and previous version of Direct Access feature.

In this blog post, we’ll discuss about our Lab configuration that will lead us for the next parts and help us to design and test Direct Access feature within virtual environment.

To build a reliable Direct Access Lab, Microsoft provides Base and Test Lab guide documentations.

Base Lab: http://www.microsoft.com/en-us/download/details.aspx?id=29010

Test Lab: http://www.microsoft.com/en-us/download/details.aspx?id=29029

Regarding base lab guide, you can build a base lab that includes Infrastructure servers (DNS, Active Directory), Application Server (Intranet IIS Site), Simulated Internet (DNS Server) and single Direct Access Server.

After you build base virtual machines, then you should follow Test Lab guide and configure&test Direct Access feature.

Let’s look at the lab details and introduce virtual machines & roles.

1

– First of all you must build a Domain Controller as an intranet domain controller, DNS Server and DHCP server. This server will be responsible for authentication purposes and will act as main identity store for the Lab environment. Also a DNS server is a must to built a healthy Active Directory environment. DHCP is another role that you have to install. It will be used to configure Client1’s ip address automatically. Since you will change Client1 subnet frequently during test processes, providing ip addresses automatically will help us.

– One intranet member server running Windows Server 2012 named APP1. It will be configured as a general application and web server. When a client resides on internet network and successfully connects intranet network through IPSEC tunnel (Direct Access Server), to test Direct Access client side functionalities, being able to access real intranet resources will be more helpful test. On application server, a file share and an intranet IIS web site will be created.

– One member client computer running Windows 8 Consumer Preview named Clinet1. You will use that client machine for testing purposes. I recommend that put three network interface to try for internet, intranet and behind NAT communications.

– One intranet member server running Windows Server 2012 named EDGE1. That will be our Direct Access Server. Most important point is that it should have two different network cards to access both intranet and internet networks. This server also will act as a DNS64. That means it will get DNS ipv6 requests from Windows 8 clients that resided in Internet and make ipv4 DNS requests to the intranet DNS server on behalf of DA clients.

– And the last required server for base lab is INET1. It’s required to simulate internet network. You will have to create DNS zones to answer DNS queries from internet clients.

I’m sure if you want to build that lab, you will download base and test lab and follow the steps. So I will only highlight for the important steps that is also covered basically within documents.

– Since this is a limited Lab environment, you can minimize hardware requirements. 1024Gb ram will be enough for each VM.

– Unlike previous Windows 7 Direct Access Test lab guide, this guide includes PowerShell script for each step. You do not have to follow 15-20 steps one by one. Just copy PowerShell script provided and run within elevated PowerShell console.

2

After you complete Base Lab Guide and before to start Test Lab Guide, if you want to test Direct Access functionality behind a NAT device, you also have to build following HomeNet Lab.

Optional mini-module- Homenet subnet

It’s an optional step and will help you to fire up one another Windows 8 virtual machine that will act as a NAT device.

Before you start to install Direct Access Feature and test connectivity, you must have following environment:

3

I know it seems a little bit crowded, but once you build that kind of virtual lab, you can also use it to test other new Windows Server 8 features.

Next part we will assume that you have a working Lab environment and will start to install and configure Direct Access feature.

Windows Server 2012 Direct Access Part 1 What’s New

Direct Access feature was introduced with Windows Server 2008 R2 and Windows 7 Client computers. Direct Access overcomes the limitations of VPNs by automatically establishing a bi-directional connection from client computers to the corporate network so users never have to think about connecting to the enterprise network and IT administrators can manage remote computers outside the office, even when the computers are not connected to the VPN.

In this blog post series I’ll cover Direct Access Feature in Windows Server 2012 and design a complex Windows Server 2012 lab to implement Direct Access feature. In my next post I will outline the lab requirements and design considerations. With 3rd post we will be able to install direct access feature and then cover details and troubleshooting steps.

In this first post, let’s look at the Direct Access feature on Windows 7 /2008 R2 and compare with Windows Server 2012.

Direct Access feature in Windows Server 2008 R2 had following goals for organizations;

  • Direct Access enhances the productivity of mobile workers by connecting their computers automatically and seamlessly to their intranet any time Internet access is available
  • With Direct Access, IT staff can manage mobile computers by updating Group Policy settings and distributing software updates any time the mobile computer has Internet connectivity
  • Direct Access separates intranet from Internet traffic.
  • When an application on a Direct Access client attempts to resolve a name, it first compares the name with the rules in the NRPT (Name Resolution Policy Table )      If there are no matches, the Direct Access client uses Internet DNS servers to resolve the name

From connectivity perspective;

Direct Access clients create two tunnels to the Direct Access server. The first tunnel, the infrastructure tunnel, provides access to intranet Domain Name System (DNS) servers, Active Directory Domain Services (AD DS) domain controllers, and other infrastructure and management servers. The second tunnel, the intranet tunnel, provides access to intranet resources such as Web sites, file shares, and other application servers.

Direct Access feature relies on IPv6 network infrastructure. For those who have not a native IPv6 network infrastructure, ISATAP can be used to make intranet servers and applications reachable by tunneling IPv6 traffic over your IPv4-only intranet. Computers running Windows 7 or Windows Server 2008 R2 support ISATAP host functionality.

To configure ISATAP you have to put ISATAP host ( A ) record in your DNS and all machines can then resolve this name to configure their ISATAP adapters.

By default, Windows 2003 SP2 and above DNS servers do not answer queries for the names WPAD and ISATAP. That means you will need to enable queries for the ISATAP name on these servers.

Here is a simple diagram that shows how direct access feature works on Windows Server 2008 R2;

1

Notice that the Direct Access client establishes two IPsec tunnels:
IPsec Encapsulating Security Payload (ESP) tunnel with IP-TLS (Transport Layer Security) encryption using the machine certificate. This tunnel provides access to the DNS server and domain controller, allowing the computer to download Group Policy objects and to request authentication on the user’s behalf.
IPsec ESP tunnel with IP-TLS encryption using both the machine certificate and user credentials. This tunnel authenticates the user and provides access to internal resources and application servers. For example, this tunnel would need to be established before Microsoft Outlook could download e-mail from the internal Microsoft Exchange Server.

Also Direct Access servers running Windows Server 2008 R2 requires two network adapters, one that is connected directly to the Internet and one that is connected to the intranet. Also this server should have two consecutive and public IPv4 addresses.

One another major challenges for IT administrators to deploy Direct Access in Windows Server 2008 R2 was the need of a PKI environment to issue computer certificates.

And if you have not Forefront UAG, an optional NAT64 device is a requirement to provide access to IPv4-only resources for Direct Access clients.

2

As you noticed with above complex requirements, implementing Direct Access feature was not a easy task for IT Departments.

Direct Access feature has been designed again with Windows Server 2012 and now  addresses better connectivity with better manageability.

In brief, Windows Server 2012 includes following improvements over Windows Server 2008 Direct Access and RRAS features;

  • Direct Access and RRAS coexistence

In Windows Server 2008 R2, combining RRAS and Direct Access might cause some conflicts for the remote client connectivity. Since Direct Access relies on IPv6 and RRAS implements IKEv2 IPSEC, this results in Direct Access traffic being blocked if RRAS is installed and VPN access is deployed with IKEv2. Now in Window Server 2012, Direct Access and RRAS are combined within a new unified server role.

  • Simplified Direct Access management for small and medium organization administrators

One of the most important simplicity in Windows Server 2012 is removal of the need for a full PKI deployment. As you know that one major deployment blocker for Windows 7 Direct Access is the requirement of a Public Key Infrastructure (PKI) for server and client certificate-based authentication. Now in Windows Server 2012, client authentication requests are sent to a Kerberos proxy service running on the DA server. Then Kerberos proxy sends requests to domain controllers on behalf of the client.

And also new getting started wizard which will be covered on next posts allows for an automated setup in a few simple steps.

  • Built-in NAT64 and DNS64 support for accessing IPv4-only resources

In Windows Server 2008 R2, UAG might be used for NAT64 and DNS64 translations;

3

Now Windows Server 2012 Direct Access server includes native support for NAT64 and DNS64 translations that convert IPv6 communication from the client to IPv4 internal resources.

  • Support for Direct Access server behind a NAT device

The Teredo IPv6 transition technology is used typically when the client system is assigned a private IP address (and for modern Windows clients, will be used when the client is assigned a public IP address and 6to4 isn’t available). A Windows Serv

er 2008 R2 Direct Access server requires two network interfaces with two consecutive public IPv4 addresses assigned to the external interface. This is required so that it can act as a Teredo server.

Now in Windows Server 2012 direct access server can be deployed behind a NAT device with support for only one single network interface and removes the public IPv4 address prerequisite.

  • Load balancing support

One of the most important  enhancement is the chance to design a fully high available direct access solution. Now in Windows Server 2012, Direct Access has  built-in Windows Network Load Balancing support to achieve high availability and scalability. And this configuration can be configured within new deployment wizard interface with a couple of clicks.

  • Support for multiple domains

Now you can configure Direct access server to allow remote clients located in different domains.

  • Support for OTP (token based authentication)

For organizations that needs a security level with OTP vendor solutions such as RSA SecurID, Windows Server 2012 supports two factor authentication with smart cards or OTP token based solutions.

  • Automated support for force tunneling

4

http://blogs.technet.com/b/tomshinder/archive/2011/04/19/url-and-antivirus-filtering-for-directaccess-clients.aspx

By default only specific network traffic (defined by DNS records) will go through direct access tunnel. But if you want to route all traffic from client computer to the intranet resources over Direct Access tunnel, you can configure it with Force Tunneling.

Force tunneling is a feature in Windows Server 2008 R2 that forces all network traffic to be routed over Direct Access IPSEC tunnel. But it requires manual steps to enable via group policy. In Windows Server 2012, direct access has integrated force tunneling with the setup wizard.

  • Multisite support

Now in Windows Server 2012, you can configure multiple Direct Access  entry points across remote locations. This makes sure the client locates the closest IP-HTTPS server, Teredo Server, DNS Server etc. regardless of their physical location.

  • Windows PowerShell support

Direct Access in Windows Server 2008 R2 lacks a complete scripting and command line interface for configuration options. Windows Server 2012 provides full Windows PowerShell support for the setup, configuration, management, monitoring and troubleshooting of the Remote Access Server Role.

  • User and server health monitoring

The Monitoring Dashboard shows a summary of remote client connectivity status for the following items. The information is generated from the relevant Performance Monitor counters and accounting data.

  • Total number of active remote clients connected – includes both Direct Access and VPN remote clients
  • Total number of active Direct Access clients connected – only the total number of clients connected using Direct Access
  • Total number of active VPN clients connected – only the total number of clients connected using VPN
  • Total unique users connected – includes both Direct Access and VPN users, based on the active connections
  • Total number of cumulative sessions – the total number of connections serviced by the Remote Access Server since the last server restart
  • Maximum number of remote clients connected – the maximum concurrent remote users connected to the Remote Access Server since the last server restart
  • Total data transferred – the total inbound and outbound traffic from the Remote Access Server for both Direct Access and VPN since the last server restart

With the above enhancements, it’s now much easier to implement this great remote access feature in your organization.

In second blog post of this series, I will discuss to design a Windows Server 2012 Direct Access lab that will guide us for next posts.

Windows Server 8–Live Migration Demo

Beta version of Windows 8 went to live on 29th February. Development team announced that it had reached over 1 million downloads within the first 24 hours. Considering this is a pre-release software, 1 million is an incredible start for Microsoft.

I believe lots of you are still experiencing new features.

Windows Server 8 is in front of us as a most current server operating system. Microsoft is positioning Windows Server 8 as the go-to platform for both public and private cloud scenarios. So most major changes for Windows Server 8 can be explored within Hyper-V 3.0.

In this blog post, I’ll cover about truly live storage migration that is one of the key features of Hyper-V 3.0.

Also I will publish a video version of this article in my next blog post.

Storage migration is one of the new features of Hyper-V 3.0. It helps you to transfer virtual machine VHD (VHDX) and configuration items to a new locations. While Hyper-V gets all bits to a new folder, Virtual Machine continues to run with all functionality.

You can accomplish this task using User Interface or PowerShell. Using PowerShell means we can try different various of actions. For example you can query all your virtual machines that meets specific criteria such as name, disk, CPU etc. and run storage migration for queried VMs.

Before dive in step-by-step, let me explain a little bit about Storage Migration background.

Storage migration is supported for both hard disk files, VHD and VHDX. As all you know VHDX is a new virtual hard drive format shipped with Hyper-V 3.0 and brings lots of new functionalities such as;

  • Supports disks much larger than 2TB (Current VHD restriction)
  • It can be mounted and ejected from Windows Explorer.
  • Larger Block sizes
  • Faster speed than VHD disks
  • Can be convertible to VHD and back to VHDX

Storage migration process creates a new virtual hard disk in the destination directory thereupon user initiates Live Storage Migration through UI or PowerShell.

Important part is during source virtual hard disk read and write operations, newly created operations mirrored to the new virtual hard disk. Reads are occurring from the source, writes are happening to both source and destination.

Then Hyper-V initiates copying virtual disks. If your storage array supports Offloaded Data Transfer, storage migration accelerate itself as taking advantage of ODX technology. Let me explain in more detail about ODX;

Offloaded Data Transfer (ODX) introduces a tokenized operation to move data on the storage device. The source file and destination file can be on the same volume, two different volumes hosted by the same machine, a local volume and a remote volume through SMB2, or two volumes on two different machines through SMB2.

ODX in Windows Server 8 allows handing off operations to the storage system that can perform actions with higher performance.

image

Once disk copy process is complete, Hyper-V switch VM to run on destination virtual hard disk. In case of a failure on destination side, there is always fail back option to run back again on source directory. And finally deletes source VHDs.

Now lets take a look how to initiate Live Storage Migration.

First, open your Windows Server 8 Hyper-V Manager and navigate related virtual machine.

image

In my lab environment there is only one single Windows 8 Virtual Machine.

On the right action pane click Move.

image

Move Wizard will ask you to choose Move Type.

image

Choose between “Live Migration” or “Storage Migration”. As you know, Live migration moves virtual machine and its related items to another computer running Hyper-V.

In this case, we just want to simulate storage migration.

image

There are three different choices on Move Options page.

Move all of the virtual machine’s data to a single location: Choose this option to specify one single destination location for all VM items such as disk file, configuration, snapshot, smart paging.

Move the virtual machine’s data to a different locations: This option lets you to specify individual locations for each VM item.

Move only the virtual machine’s virtual hard disk: Moves only virtual hard disk file.

image

That’s a screenshot from “Move the virtual machine’s data to a different locations” option. As you already notice you can move VM items individually.

image

And this is from “Move only the virtual machine’s virtual hard disk:” option. Only choice is virtual machine disk file.

Lets move with option 1.

image

Specify destination location for the VM. Be aware about available disk space on destination folder. For demo purposes, I choose one of my local disks.

image

Preparing to move.

image

To show you that this is a true live storage migration, I started a ping command within Windows 8 Client (VM) that will run through migration process.

image

You can also track migration process within Hyper-V console.

image

If you locate destination folder through windows explorer, you will notice newly created snapshot and configuration files. Also virtual hard disk file bits are growing.

image

It’s almost finished.

image

And Hyper-V deletes source folder items. During migration process, Windows 8 Virtual Machine was fully reachable and live.

image

And that is the new Virtual Hard Disk location.

Thanks.