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.

- 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 evelated powershell console .

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:

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.

So you have created many virtual machines in Hyper-V manager and suddenly you want to move one of them in a new HDD or just rename the folder holding it, you will find that this is not a trivial task! Hyper-V management service holds an open handle to the XML file describing the virtual machine settings so you cannot change it in any way. The out of the box method is to export the VM to another folder and then re-import it from that folder to a new one, while this works great sometimes it is not applicable specially if the VM size is huge and you have no disk space to replicate it (since the export would replicate the VHD of the VM) so how to do it, well here you go follow these steps:

1.       Stop or shut down your VM (you cannot save its state!)

2.       Stop the Hyper-V management service from the management console

3.       Once it is stopped browse to the folder “C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines”

4.       You will find a symbolic link file to the XML settings file of the VM with the same name just rename it to any other name:

5.       Then move the VM to the new folder or rename the folder (do your thing).

6.       Once the VM is moved then open a new command prompt as an administrator and then type the command

7.       Then right click on the newly created symbolic link file and then click security tab and edit. You need to give the local users full control over this created file as shown below:

8.       Now go back to the computer management and start the service again

9.       Now you will find your VM moved and ready to start.

The only limitation here is that you lose any saved states (I still do not know why but I am planning to look it over).

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;

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.

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;

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 Server 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

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.

This Guide will explain the detailed steps required to do cross forest migration from source forest running Exchange 2003 to target forest running Exchange 2010.

Active Directory Migration Tool (ADMT) will be used to migrate user accounts as well as computer accounts. There are two scenarios when using ADMT to migrate user accounts with Exchange:

1. Run Prepare-MoveRequest.ps1 script first then ADMT: in this scenario the steps will be in the following order:

a. Prepare-MoveREquest.ps1: The script will be used to create Mail Enabled Users (MEU) in the target forest; the MEUs will be disabled and will contain the following attributes: legacyExchangeDN, mail, mailnickname, msExchmailboxGuid, proxyAddresses, X500, targetAddress, userAccountControl, userprincipalName.

b. ADMT to migrate user accounts: the main target is to get the old SID from the source domain (SID History), and to synchronize the password from the source domain to the new user account in the target domain, of course other AD attributes could be migrated like phone, address, title…

c. Move Mailbox: using new-move request from the source forest to the target forest.

d. ADMT to migrate the computer account: this will mainly disjoin the client machine from the source domain and join the new domain, also will add (or replace) the SID of the new user in the target forest on the same profile used by the old user account, other options available like local group, profiles…..

2. Run ADMT first then Prepare-MoveRequest.ps1: in this scenario the steps will be in the following orders:

a. ADMT to migrate the user accounts from the source forest to the target forest, users will be created or merged by ADMT not the script, SID history and password synchronization along with other AD attributes could be merged from the source forest to the target forest. By default ADMT is excluding all Exchange attributes.

b. Convert the user accounts created or merged by ADMT to Mail Enabled User (MEU) accounts with proxy address as the source forest user account.

c. Prepare-moverequest.ps1: the script will be used with –localobject and –overwritelocalobject switches, so the script will use the existing user accounted and will not create new account.

d. New-MoveRequest: to move the mailbox from the source forest to the target forest.

Choosing which scenario will be based on the customer environment, the selection of the scenario should consider:

1. First Scenario: This is the easy and straight forward scenario, should be used if the target forest (domain) is newly created, no users from the source domain exist in the target domain.
2. Second Scenario: As this is more complicated scenario, it should be used if ADMT must run first before prepare-moverequest, and this will be needed in case of there are already users from the source forest in the target forest.

This series of articles will focus on the second scenario. Before going on the detailed steps, let’s first explain the environment and the requirements.

The current environment includes the following:

1. Source forest running Windows 2003, and Exchange 2003 (egypt.tailspin.com), email address of all user accounts @egypt.tailspin.com
2. Target forest running Windows 2008 R2 and Exchange 2010 (tailspin.com), email address for all users @tailspin.com.
3. There are already user accounts for the source forest in the target forest, created manually and used by many applications, and they must be used.

The following diagram shows the details of the current environment:

As the migration will take time, the co-existence period should be considered, so this guide will cover the following:

1. Addressing the migration challenges.
2. Configure Mail Flow between the two forests.
3. Migration of user and computer accounts using ADMT.
4. Exchange Mailbox migration using native tools.
5. Enable sharing Free/Busy information between the two forests, so when the user is migrated to the target forest, he will still be able to check the free/busy information of other users in the source forest and vice versa.

The second part of this guide will address the migration challenges and setting up the mail flow between the two forests.

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part I

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part II

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part III

Introduction

Recently, my engagements were related to SQL and 2 of which were to build SQL failover clusters on based on Windows 2008R2/SQL 2008R2 SP1 and Windows 2012/SQL 2012 SP1. In this post, I will share with you my SQL Server 2012 Failover clustering experience.

Part 2: Adding a New Node to Cluster

Part 3: Adding a New Instance to Cluster

Context

As displayed in the figure below,

• The demo cluster has 2-nodes and uses File Server (FS) (Windows 2012) as storage and
• Each node has at least 2 NIC - one for internal (LAN) and for private (heartbeat) network
• FS provide 4 disks that are
• Q: used for Quorum or witness disk (1GB)
• E: used for Microsoft Distributed Transaction Coordinator (MSDTC ) (2GB)
• I: used for SharePoint 2013 Content databases (30GB), yes, it is low, but I can afford only this much in my local.
• H: used for Custom .NET application's databases (30GB)

Figure1: Windows Server 2012 failover cluster used in the demo

Please note that this is for demo purposes and built in my local environment (Windows 2012, Hyper 2012). My assumptions are:

• SQL database instances will need database engine feature only and no BLOB type of record expected.
• The pre-requisites for Windows and SQL failover clustering (storages, network configurations, user accounts, etc.) are already conducted.
• You logged in Node 1 with cluster admin account.

How-to Build SQL 2012 Failover Cluster Steps

Conclusion

In this post, as part of post series of building SQL 2012 Server failover cluster on top of Windows 2012 Server, I have demonstrated installing SQL 2012 Server failover cluster on node 1. In my next posts, I will demonstrate how to add a second node and how to install a new named database instance to the SQL cluster. Hope you like it and stay tuned!