Dan Cuomo, a Premier Field Engineer here at Microsoft, has just published the Test Lab Guide: Enhanced Mitigation Experience Toolkit (EMET 5.2). The new TLG steps you through:

• A brief explanation of the EMET, an anti-vulnerability exploitation toolkit that can be layered onto the Windows operating system
• Setting up the Base Configuration for Windows Server 2012 R2 test lab in a separate test environment or in Microsoft Azure
• Downloading the EMET installation files
• Installing the EMET via Group Policy
• Deploying an ADMX GPO configuration to server systems
• Deploying an XML configuration to client systems
• Demonstrating certificate trust pinning

Here is the stack:

Dan's new whitepaper is illustrated throughout with screen shots showing the desired configuration.

Hats off to Dan for creating this comprehensive new TLG that gets your hands on the EMET 5.2!

For additional information about the EMET, see https://microsoft.com/EMET and https://aka.ms/EMET. 

Enjoy.

Joe Davies

With the publication of the Set up a SharePoint intranet farm in a hybrid cloud for testing topic, I thought I would step back and summarize the different ways that you can create an environment for testing or developing an application for a SharePoint Server 2013 farm running in Microsoft Azure.

The four main configurations are:

• Basic configuration of the SharePoint Server Farm template in the Azure Preview Portal
• High availability configuration of the SharePoint Server Farm template in the Azure Preview Portal
• SharePoint 3-tier farm in Azure Test Lab Guide (TLG)
• SharePoint intranet farm in a hybrid cloud

Basic configuration of the SharePoint Server Farm template in the Azure Preview Portal

With the SharePoint Server Farm template in the Azure Preview Portal, you can create a simple, 2-tier SharePoint farm easily by specifying very few configuration settings and letting the Preview Portal perform the computer and farm configuration for you.

The intended use for this configuration is an Internet-facing test farm using a cloud-only Azure virtual network. This farm is not connected back to your organization network through a site-to-site VPN connection.

High availability configuration of the SharePoint Server Farm template in the Azure Preview Portal

The SharePoint Server Farm template in the Azure Preview Portal also allows you to create a high-availability, 3-tier SharePoint farm, complete with a SQL Server cluster and an AlwaysOn availability group. This can save you a lot of configuration time, but you will need an Azure subscription that supports the number of servers and cores in this configuration.

Like the basic configuration above, the intended use for this configuration is an Internet-facing test farm using a cloud-only Azure virtual network. This farm is not connected back to your organization network through a site-to-site VPN connection.

SharePoint 3-tier farm in Azure Test Lab Guide

The SharePoint 3-tier farm in Azure TLG builds a simple 3-tier farm, complete with a client computer, and is an Azure-based alternative to building a SharePoint test lab using on-premises computers or virtual machines.

The intended use of this configuration is an intranet test farm using a cloud-only Azure virtual network. It emulates an intranet farm relative to the CLIENT1 computer, rather than from your organization intranet. Unlike the SharePoint Server Farm template configurations, there is no Internet access to the resources of the SharePoint farm.

The advantage to this configuration is that you can use a set of existing SharePoint TLGs to configure permissions, authentication, profile synchronization, and social networking. For more information, see SharePoint Server 2013 Test Lab in Azure.

SharePoint intranet farm in a hybrid cloud

The SharePoint intranet farm in a hybrid cloud topics build a simple 2-tier farm, complete with a simplified on-premises organization network containing a domain controller and client computer.

The intended use of this configuration is an intranet test farm using a cross-premises Azure virtual network. It emulates an intranet farm relative to the CLIENT1 computer on your simplified on-premises network. There is no Internet access to the SharePoint farm.

The advantage to this configuration is the inclusion of a site-to-site VPN connection and the ability to experience the performance and administration of an emulated intranet SharePoint farm relative to your location on the Internet.

Hopefully, these topics and facilities will fit your needs for either a quick and easy SharePoint farm test or development environment in the cloud or a hosted configuration where you can do deeper learning and experimentation.

Enjoy!

Joe Davies

• Set up the standard computers of the Corpnet subnet (DC1, APP1, and CLIENT1) for a simplified on-premises network.
• Configure a cross-premises Azure virtual network using Windows Server 2012 and the Routing and Remote Access Service as the on-premises VPN device (RRAS1).
• Create a replica domain controller for the corp.contoso.com Active Directory domain (DC2).

• Start with the hybrid cloud base configuration (DC1, APP1, CLIENT1, RRAS1, and DC2).
• Add a SQL server running SQL Server 2014 (SQL1).
• Add a SharePoint Server 2013 computer (SP1) and create a two-tier SharePoint farm with SQL1.

• Start with the hybrid cloud base configuration (DC1, APP1, CLIENT1, RRAS1, and DC2).
• Add a SQL server computer running SQL Server 2014 (SQL1).
• Add a web server running Windows Server 2012 R2 and Internet Information Services (IIS) as a web-based line-of-business server (LOB1).

• Start with the hybrid cloud base configuration (DC1, APP1, CLIENT1, RRAS1, and DC2).
• Sign up for an Office 365 Trail Subscription for a fictional company.
• Add a DirSync server running Windows Server 2012, synchronize accounts with corp.contoso.com, and test password synchronization with a new user account.

Advantages to running your test lab in Azure are ongoing connectivity to the Internet and the ability to more quickly add new servers. For more information, see New Base Configuration in Microsoft Azure!

In this post, I will explain how this networking environment works in the following ways:

• How computers within the TestLab virtual network resolve each other's names and exchange traffic
• How computers within the TestLab virtual network resolve Internet names and exchange traffic
• How your computer accesses the computers in the TestLab virtual network with a remote desktop connection

Communication between virtual machines

All of the computers in the TestLab virtual network obtain an IP address from the 10.0.0.0/24 address space. Because DC1 is configured first and always started first, it gets the IP address 10.0.0.4. IP traffic between computers in the TestLab virtual network is delivered directly. This is facilitated by an Azure equivalent to Layer 3 switching.

The computers in the TestLab virtual network have the following DNS configuration:

• DC1 is using itself as a DNS server to register and resolve names
• APP1, CLIENT1, and other computers are using the IP address of DC1 (10.0.0.4) as their DNS server to register and resolve names

Therefore, when communicating with each other:

1. A computer in the TestLab virtual network sends a DNS name query to DC1 at 10.0.0.4.
2. DC1 resolves the name to an IP address and sends it back to the requesting computer.
3. The computer initiates communication directly with the destination.

Communication from virtual machines to the Internet

DC1 is not configured with forwarders. Based on default settings, the DNS Server service in Windows Server 2012 R2 will automatically query Internet root domain servers for names for which it is not authoritative. The list of Internet root servers and their IP addresses are on the Root Hints tab of the properties of the DNS server in the DNS snap-in.

Therefore, when a computer wants to communicate with another computer or service on the Internet:

1. It sends a DNS name query for an Internet resource to DC1.
2. After determining that it is not authoritative for the domain name, DC1 uses the DNS iterative query process—starting with an Internet root server—to resolve the name to an Internet IP address.
3. DC1 sends the resolved IP address back to the requesting computer.
4. The requesting computer then sends the traffic directly to the Internet destination. This traffic is forwarded by the Azure Load Balancer, which provides routing, traffic translation, firewalling, and load distribution services for traffic to and from the virtual machines in the TestLab virtual network. The Azure Load Balancer also changes the source IP address of the traffic to the IP address of the cloud service.
5. The response traffic from the Internet resource is received by the Load Balancer and forwarded because it is in response to the request from the TestLab computer. The Azure Load Balancer also changes the destination IP address to the virtual machine's IP address.

Note that the DNS name resolution traffic in step 1 also goes through the Azure Load Balancer.

Remote desktop connections

When you connect to an Azure virtual machine from the Virtual Machines screen of the Azure portal, your computer downloads an RDP file with the correct DNS domain name for the cloud service containing the virtual machine and the correct randomized port number of the RDP service on the destination virtual machine.

The Azure portal automatically configured this randomized TCP port as an endpoint when you created the virtual machine. An endpoint instructs the Azure Load Balancer to forward unsolicited, incoming traffic to the TCP or UDP port number of the configured virtual machine, changing the port number if needed. In the case of incoming RDP traffic, the cloud service changes the destination TCP port number from the randomized port number to 3389, the well-defined port number on which the virtual machine is listening for remote desktop connection traffic.

Therefore, when you initiate a remote desktop connection with the downloaded RDP file:

1. Your computer resolves the IP address of the cloud service that contains the virtual machine.
2. Your computer sends the initial TCP connection request message, known as a TCP SYN segment, which the Azure Load Balancer receives.
3. The Azure Load Balancer examines the destination TCP port in the packet and checks for a match in the list of configured endpoints.
4. After finding a match, the Azure Load Balancer changes the destination TCP port number in the packet to 3389, changes the destination IP address to the IP address of the virtual machine, and then forwards the packet.
5. The Azure Load Balancer receives the response traffic from the virtual machine, which translates the source TCP port number and source IP address and forwards it to your computer.

Joe Davies

Check out this new Test Lab Guide: Demonstrating FIM 2010 R2 ECMA2 with SQL Azure.

With this TLG, you can use a free trial subscription, your MSDN subscription, or your paid Azure subscription to build out a test lab that demonstrates a Forefront Identity Manager 2010 R2 ECMA2 management agent synchronizing information with a SQL Azure database.

Here is the resulting configuration:

Here is the resulting TLG stack:

To see all of the FIM 2010 TLG content, see Test Lab Guides in the TechNet Wiki.

To see all of the Azure TLG content, see the Azure Test Lab portal page.

Color of your next test lab: Azure!

Joe Davies

Jeff Cothern and I have been working on the Test Lab Guide: Install Exchange Server 2013 on the Windows 2012 R2 Base Configuration in the TechNet Wiki to make it the first 3-way TLG. What's a 3-way TLG? It's a TLG that can be used to configure and demonstrate a product or feature for all three lab environments:

• Isolated subnets
• Public cloud
• Microsoft Azure

We did this by prefacing some steps and procedures with the lab environments to which they apply. For example:

• Step 3: Modify DHCP Scope on DC1 (isolated subnets lab environment only)  The isolated subnets lab environment needs this step is to add a default route to CLIENT1, which is required for the Outlook client. In both the public cloud and Azure lab environments, all computers on the Corpnet subnet are automatically configured with a default route.

• Install the operating system on EX1 (isolated subnets and public cloud lab environments only)  The isolated subnets and public cloud lab environments need this procedure because in the Azure lab environment, the virtual machines already have the operating system installed.

Here is the Exchange Server 2013 lab diagram for the isolated subnets lab environment:

For the public cloud lab environment:

For the Azure lab environment:

Huge thanks to Jeff for creating, testing, and publishing the initial TLG and forcing the issue of 3-way TLG functionality!

Joe Davies

We recently released the Set Up a Directory Synchronization Server to Sync Users with Office 365 TLG, which shows you how to set up directory synchronization to Office 365 with the Directory Synchronization (or Directory Sync) tool. When you complete the guide, your Active Directory users in the CORP domain on the logical Corpnet subnet are synchronized with Office 365.

This TLG opens up new possibilities for you, especially if you’re interested in testing Office 365 workloads, for instance, Exchange Online, alongside workloads in your Windows Server 2012 on-premises test lab environment, or perhaps with workloads running on Azure virtual machines (also known as infrastructure as a service, or IaaS). 

This TLG is built to work with the Public Cloud TLG stack (click on it for a larger version):

Thanks for using TLGs! 

Tony Trivison
Senior Content Developer
Office Server Solutions

Jeff Cothern just published Test Lab Guide: Install Exchange Server 2013 on the Windows 2012 R2 Base Configuration in the TechNet Wiki. This new TLG builds out an Exchange Server 2013 email server named EX1 on the CorpNet subnet in the latest base configuration (using Windows Server 2012 R2), and then uses the Outlook client to send email between two new accounts.

Here is the stack diagram:

Here is the lab diagram:

This lab environment can be used as a basis for other Windows Server 2012 R2-based TLGs or test lab extensions that use Exchange Server 2013 (more are in the works).

If you are new to Exchange Server 2013 or just want to play around with it in a test lab with the latest version of Windows Server, take a look at this new TLG.

A big thank you to Jeff for creating, testing, and publishing this new TLG!

If you would like to follow Jeff's lead and develop and publish your own TLG content, see Creating and Publishing Test Lab Guide Content.

Joe Davies

• You don't have to acquire the physical or virtual machines and create an isolated subnet. You can create the virtual machines for the test lab in Azure within minutes.
• You can use the SQL Server 2012 and SharePoint Server 2013 Trial images in Azure to quickly create virtual machines that already have these components installed (saves a ton of time collecting and installing the trial software for SQL Server and SharePoint).
• You can create the virtual machines for the lab in various sizes (including very large ones), and you have the ability to change their size after they are created.
• You can enable Internet access to this farm and its sites by opening endpoints on the WFE1 web server (a future TLG mini-module).