Xtravirt — Welcome to Windows Server 2016

By Curtis Brown

Windows Admin Center is a new, locally-deployed, browser-based management tool set that lets you manage your Windows Servers with no Azure or cloud dependency. It gives you full control over all aspects of your server infrastructure and is particularly useful for managing servers on private networks that are not connected to the Internet.

Windows Admin Center is the modern evolution of “in-box” management tools, like Server Manager and MMC. It complements System Center - it’s not a replacement.

 This blog is a ‘how to’ guide on installing and using the Admin Center.

Installation

The installation starts with a pretty straightforward Window Installer.

It will ask if you want to use MS Update to keep it updated – probably a good idea!

When you install it, it can be a local install on Windows 10 accessed via a browser directed to https://localhost:6516 or installed on a Server in Gateway mode (https://servername).  You’ll need a supported browser – MS Edge (obviously) and Google Chrome currently. Internet Explorer doesn’t make the cut.

You can use a self-signed SSL certificate (not good) or a signed one.  If you’ve got a domain CA, simply create a Computer certificate in the server’s Personal Store and get the thumb print of this certificate.  A tip – Copy the thumbprint into notepad first and take out the spaces otherwise it won’t accept it.

Using Admin Center

Open the browser and point at the URL discussed above.

If you click on the Cog icon, you can access settings.  We can configure a number of items, notably access rights.

In Extensions, we can see further functionality that can be added.

Immediately useful ones are Active Directory, DHCP and DNS.

From the Server Manager page, we add servers.  This requires suitable credentials, so Service Accounts might be worthwhile here. Here we can see we’ve got two servers. LABSRV01 is the server we’ve installed the Admin Center on, while LABDC01 is our Domain Controller (DC).

If we select the DC, we see that we can remotely configure quite a lot of both server configuration items, but also, where applicable, we can use the Extensions installed earlier.

The PowerShell option allows us to open a PowerShell session on the target system – quite useful.

How about remote access to the Windows Registry?

The Active Directory extension allows for some administration of Computer and User objects.

Closing Thoughts…

As an administration tool, especially in the second line upwards support context, this is actually quite a useful tool in a modern environment.  In order to support slightly older Windows server releases, a few adjustments are needed on the server side to allow access, though the effort might be worth it.

Although aimed at a largely server management context, it may also be useful in some desktop contexts, particularly for diagnostic and investigation work.

Although Xtravirt are a primarily Virtualization focused business, by the very nature of what we do, we also have to use tooling and technology both within the virtual estate (such as Guest Operating Systems) as well as in the wider environment supporting the virtualization platform (such as Active Directory, DNS etc).  If you’re in the process of a virtualization effort and require guidance on integration into a wider estate, then Xtravirt may be able to help.

About the author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strengths in VDI, storage integration, backup and disaster recovery design/implementation. He was awarded VMware vExpert 2019.

About Xtravirt

If you’re embarking on either an upgrade or a new VMware Horizon implementation, Xtravirt have the expertise and experience in the End User Compute space and can provide advisory, design and implementation services to create the right solution for your organisation. Contact us and we’ll be happy to assist you.

by Curtis Brown

Windows 10 is gaining some serious traction in corporate environments as Windows 7 increasingly falls to the wayside with respect to both patching and application support (Dare I mention Windows 8?)

Windows 8 (Ooops – mentioned it) may have a somewhat jaded reputation due to its user interface, however, it did add several features that have evolved in Windows 10 that admins may miss if their business didn’t consider Windows 8 as an option.

This article covers some of the steps you’ll need to go through to get to a nice and slim Windows 10 Pro image, suitable for use primarily in a VDI estate.  It won’t go into every detail, but it will give you a good starting point, with a few links thrown in for reference.

The Basic Build

There’s nothing particularly odd in building Windows 10 itself, but it’s worth hitting Shift-F10 once the installer starts and using DiskPart to create a single OS partition. We won’t be using BitLocker in a VM, so we don’t need the 100MB boot partition.

When you get to the Out of Box Experience (asking you all the useful questions once the base OS is installed), you can hit Ctrl-Shift-F3 to enter Sysprep Audit Mode.

Figure 1 - Random Windows 10 OOB screenshot.

This is useful as you can install all your updates and add additional software into the build.  This is also a good point to add in VMware Tools and your chosen VDI solutions software component (such as VMware Horizon Agent).  You can reboot to your heart’s content (just don’t touch Sysprep until you’re happy). I wouldn’t go too overboard optimising the image at this point, but this is a good way of getting to a solid, patched basic OS.  When you’re finished, from the Sysprep Tool, select ‘Out of Box Experience’, the ‘Generalise’ tick box and shutdown.  This is a good place to turn the image into a vSphere Template.  If you want to add extra patches, simply boot it up, hit Ctrl-Shift-F3 and update.  Not bad at all.

After build 1607, it will ask if the machine is owned by a business or school and whether it is destined to join a domain.  Selecting Yes to these will steer you clear of the MS Live account sign up and set up just a local account.

Ripping out AppX

Windows 8 and 10 bring a new type of application package to the table – the Universal Windows Platform including apps such as People and Calendar and so are distributed as AppX packages.

It’s very telling that Windows 10 Pro is meant to be a catch-all release as there are rather a lot of apps that aren’t really useful in a corporate build.  We need to get rid of some (if not all) of them.  First hint – leave the OS logged on for a while to ensure that anything Microsoft wish to impose on the desktop is downloaded (take note this can take quite a while)

So, If you want to see a list of the AppX packages PowerShell, run as an admin, can help you out here. Run Get-AppxPackage | Select Name, PackageFullName.

Figure 2 - A list of AppX Packages

Some of these are more under the hood than others, but the main culprits such as Facebook stand out. Use **Get-AppxPackage -allusers (PackageFullName) | Remove-AppxPackage **to uninstall them across all users who drop onto the machine.

Be careful pulling out AppConnector and the Windows Store App as these have implications elsewhere; the former is used to connect to applications to MS cloud services while the latter maintains AppX packages under the hood.

Some items (such as Retail Features, Contact Support and MS Quick Assist) need to be removed from the ‘Manage Optional Features GUI’.

Setting Language Preferences

This is as confusing as ever, so I tend to stick to Control Panel to sort this out.  Download whatever language pack you want to use and get the display, input and location settings for the logged in profile sorted.  After that, set them as defaults for the Windows Logon screen and New Users as needed.

Figure 3 - Language settings

Use the VMware OS Optimization Fling

Regardless of VDI solution, the Optimization Fling is worth a go as it takes a great deal of work out of streamlining a build.  You can pick and choose what settings you want to optimise (notably, the GUI attributes can be stripped back or left pretty – it’s up to you).  You can get it from here: https://labs.vmware.com/flings/vmware-os-optimization-tool .

At this point, you’ve got a pretty lean Windows 10 build ready to roll.

Closing Thoughts…

Of course, this being just the image, there are other factors to consider.  Don’t forget to look at how you’re going to manage user profiles.  Group Policy Folder redirection is part of the solution, but managing the profile itself needs something more flexible.  Roaming Profiles are obese and unreliable, so look at a proper management solution such as VMware User Environment Manager, or Microsoft User Environment Virtualization.

If you’re interested in finding out more about how Xtravirt can assist with deploying a VDI solution, please contact us and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2017.

by Curtis Brown

The ‘Windows User Profile’ – words to make even the most optimistic Windows admin shake his head and grimace.  On one hand, it’s a sound idea – grouping all of the settings that are specific to a user into one location on a device – all nice and neat.  On the other hand, we have the problem of how Microsoft achieved it and all the legacy baggage that goes with it. 

This blog post looks (somewhat in general) at what modern tools can do to both counter the issues often associated with the user environment in Windows and enhance the capabilities.  While there are some really clever tools out there, some more and some less capable in different ways, this post will focus primarily on VMware User Environment Manager as a reference (mainly because it’s a pretty simple product).  The concepts can apply to other products, such as RES ONE Workspace, because the underlying issues are common.

So what’s up with Windows Profiles?

Well, to be fair, the native approach is optimised for local use, predominantly in a stand-alone context.  Microsoft have included some options to provide either a draconian response, the Mandatory Profile (locked down, no changes permitted – rock solid, but inflexible) or Roaming Profiles for a portable option that’s sometimes a little flaky.  Group Policy added some much needed granular abilities – most notably folder redirection, which we’ll discuss later.

The profile can be boiled down to the following:

• User Data – all those documents, music files, dodgy GIFs you keep in the My Documents, My Pictures and so on.
• Application settings – The user’s configuration for discrete applications.  These may be in the user’s own part of the Windows Registry or in configuration files.
• Environment Settings – These are typically start menu items, desktop shortcuts, wallpaper.  However, you can include printer and disk mappings to this.

All this, without careful management can lead to problems.  Firstly, without management of User Data in particular, the profile can get somewhat obese.  If the profile is just maintained locally, size isn’t necessarily a big issue.  However, in a modern environment where a user wants to log on and access their data anywhere in the business, a big profile is cumbersome and causes both reliability and performance issues.  We can alleviate some of these issues by using native tools, but only to a point.

The Windows profile is, to a certain extent, unreliable, with respect to the registry settings and has little ability to self-heal in the event of a fault in the profile.  Windows Policy often doesn’t go deep enough to override faulty settings and often, the only approach to profile corruption is the dreaded all-or-nothing Profile Reset.  Yuk.

The user profile is very proprietary with respect to operating system releases (with Windows XP version 2 profiles differing considerably from later releases).  This makes migrating between releases quite painful too.

Loading the Windows Profile, (particularly when roaming is an all-or-nothing affair) in the roaming case, it’s all downloaded on log on, then loaded into memory – in the case of application settings, these will be loaded even if the application isn’t needed.

So we have a solution that works, but not very fast, nor efficient or reliable.  We can fix some issues with just native tools, but it only goes so far.

User Environment Management

So we want to fix these problems, sure, but we don’t want to stop there.  We want to be able to centrally administer some settings and maybe allow user control of others.  We might want to do clever things based on context – what about different settings if a user logs on in VMware View rather than on an office PC or maybe different again when off site?

We need a third party solution above and beyond the basic native Windows toolset.  As mentioned earlier, there are numerous options out there – this speaks volumes as to how seriously this issue is seen across the industry – if it were an obscure problem, there wouldn’t be many tools – good old supply and demand economics.  Here, we’ll consider VMware’s User Environment Manager (UEM), what was once upon a time known as Immidio Flex+.

Setting up VMware UEM

I won’t go too far into the details of how to set up UEM – as others out there have blogged about this already, but it boils down to these steps:

• Set up a couple of shared folders – A UEM Configuration Share (stores all the common, centrally managed items) and a Profile Archive (for user-specific stuff).
• Set up some Windows Active Directory Group Policy to apply to users and devices to configure them to use UEM.
• Install a UEM management console to configure the solution and an agent into all managed endpoints.

Once these are in place, the good stuff begins.

User Data

Let’s consider the easy one first.  By establishing a centrally managed file services solution on a NAS or server infrastructure, we can establish user home folders on a per user basis.  Into this we can use the native Windows Group Policy to redirect My Documents etc to the Home Folder share.  We can repeat this for Pictures etc.

We can apply this either to the Organizational Unit containing the users, or we can do clever things like enable LoopBack processing and apply the setting via the computer account’s location in Active Directory.  This works especially well in VDI and RDSH environments where the file solution is in proximity to the desktops.

Application Settings

One of the key attributes of UEM and others is the central administration of application settings.  In the case of UEM, a tool is provided to capture application settings - Application Profiler.  This tool is run on a reference machine similar in configuration to the user endpoints, with the application installed (but not run) alongside the Application Profiler.

The application is launched from the Profiler – any configuration settings are recorded by the Profiler and held in the form of XML content in the Config Share.  This is important as it provides flexibility with respect to migrating between OS as it isn’t a Windows native profile format.  It is possible to manually edit the captured config to include additional elements if required.

An important difference with respect to application settings is that in Windows native profiles, the settings are loaded to memory at user log on regardless.  In the case of UEM, it is possible to select the application profile to be loaded only if the application is started.  This has a substantial benefit with respect to log on times and is applicable to most applications (an obvious exception being those that run on log on, perhaps with a service).

A useful feature here is that UEM can even intervene in ThinApp packages, applying settings within the sandbox.  It can also interface with App-V 4 and 5 in a similar manner.

Applications that aren’t defined would fall into the scope of the user’s personal settings and are saved to the archive share.

User Environment Settings

Beneath the application layer, we have elements of the operating system and environment we may wish to adjust.  Typically, these might include printer settings, drive mappings etc.  We can even pull in Microsoft ADMX Policy templates and configure templates here rather than via Windows Group Policy.

In the example below, we have a home drive mapping.

As with application settings, items not otherwise locked down are managed using the user’s personal archive.

Applying Settings on Conditions

In UEM, there are a number of different ways we can apply settings based upon the context in which they are needed.

With the User environment tab, these are applied when the user is logged on.  Taking our Home Drive mapping above, we could apply this based on a condition where it is only executed when logged on via an internal IP address.

In the case of application settings, these can be set to apply when an application is run.  So we could map a drive when VLC is launched and undo it when the application exits….

We could take this one step further – we can apply the environmental setting for an application based on a condition.  For example, the user runs VLC, it will run a drive mapping if the user is logged on from a PC on a particular IP range or the Remote display protocol is PCoIP….

To Conclude

So, by implementing a fully featured product such as UEM, we can simplify and centralize the administration of user and application settings, improving security, reliability and compliance to corporate standards.  We can even customise the needs depending on a variety of conditions, such as whether the user is connected to a desktop via a remote desktop protocol, or on a laptop running on battery; a member of a particular Active Directory group or connected from a particular IP address range.

The extended capabilities, such as applying application settings on-demand improve the user experience by reducing the log on time for a start.  By implementing folder redirection as well, we further eliminate reliance on a particular endpoint in the equation – a valuable tool for both Remote Desktop Session Host shared desktops or non-persistent virtual desktops.

About the Author – Curtis Brown

Curtis Brown joined the Xtravirt consulting team in October 2012. With over 16 years’ experience, Curtis has worked in both private and public sectors on a wide variety of projects including many solutions for server consolidation and VDI, implementation and migration, data centre transformations and virtualisation programmes.

In 2015, Curtis achieved the VMware vExpert award.

Twitter: @curtisbrown01

_If you’d like any assistance with an End User Compute solution (including VMware or Citrix based solutions) or simply want to learn more about how Xtravirt can help your organisation, please _

contact us

_, and we’d be more than happy to use our real world experiences to support you._

by Andy Hine

Introduction

The hype about Software Defined Networking (SDN) has been around for years, during which time the technology has rapidly matured, leading to fast growing adoption.  So what is it all about? In this article I’ll share a bird’s eye view at software based networking, and in particular VMware® NSX.

The areas covered are:

• What is SDN?
• Origins of NSX
• Why virtualise the network?
• Traditional network challenges
• How does NSX achieve network virtualisation?
• Features and architecture

What is SDN?

For those who have managed to avoid the marketing,_ _SDN enables networking and security functionality traditionally handled with hardware based equipment, eg: network switches, firewalls, load balancers, to be performed in software. This process is often called ‘Network Virtualisation’ and involves the abstraction of networking from its physical hardware.

VMware NSX is a network virtualisation platform that VMware hope will fundamentally transform the data centre’s network operational model, just like the server virtualisation ‘bonanza’ did over 10 years ago. This, in the eyes of VMware will continue the organisational march to realising the full potential of the Software Defined Data Centre (SDDC – a term coined by VMware a number of years ago). As part of this drive, NSX is now integrated into the later versions of VMware’s vSphere hypervisor.

Origins of NSX

So where did NSX come from? Back in July 2012 VMware purchased Palo Alto based company Nicira for $1.2 billion. This represented the most expensive acquisition made by VMware (and most likely will be for a long time yet), showing how serious they were and are about their SDDC vision.

Nicira were founded in 2007 and had a modest (ish) customer base of mainly enterprise clients.. Whilst their focus was on network virtualisation and developing SDN products, most were for non-VMware and open source platforms.  NSX was developed from Nicira’s existing NVP software.

Why virtualise the network?

By automating and simplifying many of the processes that go into running a data centre, network virtualisation helps organisations achieve major advances in simplicity, speed, agility and security. With this approach to the network organisations can:

• Achieve greater operational efficiency by automating processes
• Improve network security within the data centre
• Place and move workloads independently of physical network activity

Traditional network challenges

Networking teams respond to the request for change from the business with manual and often complex provisioning of hardware devices, software and configuration. And this is usually performed by an engineer with specific knowledge of the particular technology. This can create bottlenecks in provisioning new networks and applying network related changes, along with introducing the possibility of configuration errors and even outages due to human factors.

To explain by way of example; imagine a new application is to be developed, it requires isolated test, development and production environments to support it,  and each environment has its own web tier in a DMZ, and all need access to a central application library and code repository… and the deadline is yesterday. The virtualisation team have provisioned the virtual server resource and passed it over to the network team. Now what? The team manually provision new physical networks? Access ports? Trunk ports? VLANS? Firewall rules? Is there capacity on existing switches? Where is routing going to occur? Where will the DMZ be placed? And who’s got the skills and time to do it? … “This is complex…let us get back to you.”

You can see how this type of commonly repeated scenario can lead to a number of other challenges. What happens if a workload needs to move from one host or resource pool to another, for example due to maintenance. Can the new destination support the networks that the VM is currently part of? Will this require a change of IP address? Will that be in the right rule base, and please don’t tell us you need to move a VM from test to production. This traditional networking approach is static, inflexible and produces silos. The management overhead is increased further by sprawl of VLANs and firewall rule sets.

Years of server virtualisation has meant that IT infrastructure teams can now respond quicker to these type of business challenges, in fact they may well have a lot of their processes automated, maybe in provisioning new workloads or remediating issues, with integration into service desk and change management systems. So is there any chance the networking can follow suit? Well it’s certainly slower and more complex with the traditional approach.

The ability to rapidly provision, update, and decommission networks (including DMZ’s) in an agile, lower risk and highly available way can be achieved through network virtualisation, and is a major use case for VMware NSX. Add to that massively reduced management overhead, the ability to automate these processes and even integrate it with existing systems makes it a very compelling conversation.

Security and routing are other networking challenges, traditionally it has been the ‘Castle’ approach where IT has secured the data centre perimeter. Often achieved by having a powerful hardware device at the edge (or multiple if a DMZ is required), sporting large throughput capacity, firewalling and L3 routing capability with maybe some anti-virus or intrusion detection.

I see a couple of issues with that approach, firstly performance is a concern, causing potential choke points and inefficiency as each workload’s networking may be subjected to ‘hair-pinning’. The process whereby the network packet travels from the source machine all the way up to the edge device, is processed and then set off on the return journey back down again to the destination (even if the destination is located on the same physical host by the way).

As more and more of the data centre is defined in software, the transition to east-west traffic is huge. A simple example is virtual machine A, which is part of internal network 10.1.1.x and running on DC host 1, wants to communicate over TCP port 80 with virtual machine B, which is part of internal network 10.1.2.x running on DC host 2 – this is traffic that does not need to leave the data centre for any reason like north-south traffic, so therefore should not need to bother with adding extra processing at the edge device and also slowing down its own round trip time.

And what happens if a threat slips through the cracks, some malware on a VDI machine for example – how is that contained? With the Castle model, once a threat is inside it can roam around freely connecting to as much as it can, of course attempts to counter this may be with software (“personal”) firewalls on each VM or having individual rules for every single machine on the perimeter device, or even having physical firewalls between each machine. None of those options are scalable or manageable, and the latter for your average organisation is nonsensical.

By creating granular security for network segments at layer 2 instead of layer 3, this not only allows IT to increase network efficiency and reduce chatter but also introduces firewalling to east-west traffic, establishing a much more secure zero-trust operating model for networking (even within the same VLAN).

Security can be deployed at the VM, at vNIC level. To stick with the analogy earlier we have now created the ‘hotel’ model. This process is called Micro-Segmentation, and is another major use case driving NSX adoption.

How does NSX achieve network virtualisation?

VMware NSX applies network virtualisation to the physical network, much like a hypervisor does for compute, this allows for software based networks to be created, managed and deleted.

When defining networks in software (or logically) we are providing an overlay that decouples the virtual plane from the underlying hardware rendering it a network backplane, so merely a vehicle for traffic to travel on the physical network. This introduces potential to extend the life of hardware or reduce cost of its replacement due to the transition of the intelligence into software.

VMware NSX builds upon vSphere vSwitch technology as well as adding:

• Encapsulation techniques at the hypervisor level
• Introducing new vSphere kernel modules for VXLAN
• Distributed logical routing and distributed firewall services together with edge gateway appliances to deal with north-south traffic routing
• Advanced services such as load balancing

The example in the diagram above shows VMs (green and blue) on the same host but on different networks. Using NSX virtual networking services (2 x NSX vSwitches and 1 x NSX distributed logical router to be precise) the VM’s can communicate with one another without a single frame leaving the host.

The diagram above shows Virtual machines on different hosts can communicate through NSX distributed logical switches even when the underlying physical network is not configured.  In this example that would mean the network team would not have to do anything.

Features

NSX allows for networking functions previously defined in hardware to be realised virtually, including logical switching and routing, firewalling, load balancing and VPN services.

NSX also provides a REST API for integration with additional network/security products and cloud platforms.

Architecture

For those looking to realise network virtualisation it is important to understand that in the case of NSX there is no single component that will ‘switch on’ networking virtualisation. As shown in the overview of the architecture below, there are a number of integrated technologies working together to enable its introduction.

Organisations who have already invested in VMware infrastructure are at an obvious advantage. NSX data plane components are already embedded into the latest versions of vSphere at the hypervisor level, providing the base for distributed virtual switching and edge services along with L2 bridging to physical networks.

Control plane components are introduced on top, facilitating the use of logical networks and VMware vCentre is a prerequisite for the NSX management plane. At the top of the stack NSX integrates with the vRealize suite for cloud operations, automation and self-service.

Deployment

Deploying NSX can be straightforward with the right planning and design, and can be installed on top of any network hardware. Note the direct relationship between vCentre and NSX Manager.

To maximise the technology, the real focus and effort comes with tight integration into an environment, whether upgrading an existing one or planning a greenfield site.  NSX is a powerful platform which can drive complexity when considering configuration and customisation, and associated elements and polices.

Summary

NSX is changing the face of network virtualisation and with benefits already being realised at the enterprise customer level, indications are that its adoption will continue to grow as organisations understand the benefits of network virtualisation.

A well-engineered physical network will always be an important part of the infrastructure, but virtualisation makes it even better by simplifying the configuration, making it more scalable and enabling rapid deployment of network services.

Businesses are exploring NSX and network virtualisation because they are able to achieve:

• Significant reduction in network provisioning time
• Greater operational efficiency through automation
• Improved network security within the data centre
• Increased flexibility and agility

The use cases for NSX are moving from ‘presentation world’ to the real world and most major innovations VMware are working on rely on NSX for the virtualisation of the network. With the rise of containers and isolated application environment, the micro-segmentation use case will become even more prevalent as it delivers a fundamentally more secure data centre.

SDN has also created an interesting dynamic for the SysAdmin. Does the virtualisation expert become a networking expert as well? Or does it fall into the network engineer’s domain… we’re already seeing a transition to the former, and a further evolution of IT support roles in general so it will be interesting to see how this develops.

Xtravirt are the experts in NSX solution design and integration and can help deliver an accelerated and non-disruptive SDN transformation for your organisation. To find out more about how we can work with you, contact us today.

About the author

Andy Hine joined Xtravirt in August 2015 as a Technical Pre-Sales Consultant. He has over 15 years’ experience in IT across various industries and technologies. He has been involved in many transformation projects, architecting and enabling solutions in IT infrastructure and systems management, EUC/application delivery, virtualisation and cloud transition.  Andy has a wide array of technical skills mainly focused on VMware, Citrix and Microsoft technologies.

By Curtis Brown

A brief update

Following my visit to VMworld Europe in 2017 I wrote a blog post on VMware Horizon Cloud on Azure. Much has changed in a year, so it seems rather timely, given that VMworld Europe 2018 has just concluded, that I update the blog.

Where we were….

Going back a year to 2017, VMware Horizon Cloud on Azure had only just launched and at the time, it was capable of publishing full clones of Remote Desktop Session Host servers for publishing Shared Desktops and applications.  A pretty good start, all things considered, albeit slightly functionally limited compared to the VMware Hosted offering that could also offer dedicated VDI desktops.

A year on, where are we now?

Things have definitely moved on in the last year.  Not only is feature-parity between Azure and VMware Hosted offerings somewhat closer, but in one area, graphics, the Azure offering is actually superior!

Deployment

The deployment model has remained the same – you bring your own Azure subscription rather than lean on VMware for the hosting.  In this sense, it is still the case that a cost/benefit analysis needs to be undertaken

The cost of deploying Horizon VMs on Azure can be more expensive when compared to the VMware hosted offering.  To be fair, Azure is more oriented towards a server offering than desktops, so perhaps this shouldn’t be too much of a surprise.  To counterbalance this however, one must also consider connectivity in the equation.  If you already have an established Azure tenant with backhaul connectivity to on-site, then deploying VMware Hosted with its own connectivity overhead may counter the VM costs to a degree – certainly, the operational upkeep of additional environments and connectivity is a consideration.

An additional point to consider may be functionality.  From a deployment perspective, Horizon Cloud on Azure is now starting to offer dedicated and floating full desktops, not just shared.  However, at present, Instant Clones are not supported so deployment is limited to essentially persistent desktops.

Features

There is, as yet, no support for VMware App Volumes AppStacks in Horizon Cloud, so legacy deployment mechanisms will need to be considered.  As desktops are currently persistent in nature, legacy tooling such as Microsoft System Center Configuration Manager remain viable in this sense, though streaming application virtualisation tools such as VMware ThinApp and Microsoft App-V would be attractive too.

One feature that stands out over Hosted Horizon Cloud is that Azure offers enhanced graphics using Nvidia vGPU technology.  So, if you have a need for graphically intensive workloads in the Cloud, then Azure is currently the better choice.

Otherwise, with respect to connectivity protocols, management interfaces and other functionality such as the Skype for Business Virtualization Pack, the two offerings are now aligned.

What about VMware Cloud on AWS with Horizon?

VMware and Amazon Web Services have joined up to offer their VMware Cloud on AWS solution.  This allows customers to deploy a full VMware vSphere infrastructure in AWS data centers.  On top of that, it is possible to deploy VMware Horizon, so in a sense there is now a third Cloud desktop offering.

VMware consider this as an IaaS solution with desktops on, rather than a Desktop-as-a-Service offering as the customer has to look after the management tier of Horizon here, as opposed to Horizon Cloud.

The million-dollar question is - which is best? Well, there’s no easy answer to that.  Functionality wise, Horizon View has been around longer, has far greater scalability and the ability to federate multiple instances for greater resilience.  In an on-prem capacity, vGPU is supported, however this has yet to reach AWS.  The economics are more complex too given the different acquisition model involved.

There are a considerable number of use-cases where Horizon on VMware Cloud on AWS makes much more sense. For example, you have an on-prem VDI (and other services) that you wish to provide an instantaneous Cloud based DR or scaling offering, this is much more seamless and flexible than Horizon Cloud.

Closing Thoughts….

While the choice between on premises and then several cloud offerings is undoubtedly great, never has it been more apparent that an analysis prior to deciding is not just a ‘nice to have’ but a necessity.  The wrong decision can have expensive repercussions.  Such an analysis needs to consider:

• The business needs:
  

1. How does the business function currently and what are the issues to address?
   
2. How will a given solution benefit the business?
   

• Technology needs:
  

1. Compatibility with the existing environment
   
2. What connectivity do I have, and what will I need?
   
3. What resilience and security features are required?
   

• User needs:
  

1. Where are the users working?
   
2. What devices do they use and how do we manage them?
   
3. What and where are application services that users need?
   

For some customers, on-premises will remain the best approach to VDI, while others may benefit from the VMware Cloud on AWS approach offering both hybridity and flexibility and yet more may find a Desktop-as-a-Service the suitable answer.

Horizon Cloud on Azure has evolved rapidly and offers a convincing use case for customers who can gain a tangible benefit from it, but it’s not suitable in all cases.  If you need a DaaS solution and have Azure already or have graphical requirements that can’t be met in Horizon Cloud Hosted, then this might be your answer. But consider all possibilities and use cases before committing.

If you’re considering a VDI solution or digital workspace transformation, whether Cloud or On-Premises, we can help. We provide advisory, design and implementation services to create the right solution for your organisation. Contact us and we’d be happy to use our wealth of knowledge and experience to assist you.  

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He was awarded VMware vExpert 2018 and is a graduate of the VMware Advanced Architecture Course 2018.

About Xtravirt

Xtravirt are an experienced consulting firm dedicated to delivering outcomes to help customers solve their IT challenges. We design and build strategies to help customers unlock the full potential of cloud, datacentre and workspace technology.

We are the VMware Global and EMEA Professional Services partner of the year.

www.xtravirt.com

by Curtis Brown

VMware App Volumes are installed with a self-signed certificate, as is common with most products that install with components using certificates, however, this is obviously not the preferred option.  But fear not-help is at hand!

Let’s assume you’ve deployed a VMware Horizon View estate properly and you’ve deployed this with a Microsoft CA signed cert – so you already have a Web Server template cloned out and good to go.

Preparing Certificates & Keys

The first step in preparing certificates and keys is to grant the App Volumes Manager server the rights to read/write and enrol with the certificate template – a bit like this:

Then, as with a View Connection server, you can import the certificate into the computer store on the App Volumes Manager server.  This is carried out using the Certificates console, making sure the Subject Name is set to the value you want (the name of the server or the load balancer name – Subject Alternates might be nice too).

You then export this as a PFX file, making sure you export the private key and note the password.  You can drop that in a folder – let’s call it c:\temp\appvol.pfx.

The next bit is breaking this PFX into a certificate and a key file.  You need openssl to do this (tip – VMware tools has a copy).

First, let’s break out the Key file.

openssl pkcs12 -in c:\temp\appvol.pfx -nocerts -out c:\temp\appvol1.key

You’ll need the password for the PFX.  (If you don’t have this, go have a coffee and try again.)  You’ll then be prompted for another password – this time one to protect the key file.  This can be a good thing; however, you can unprotect the key using:

** openssl rsa -in c:\temp\appvol1.key -out c:\temp\appvol.key**

This is useful for AppVol’s NGINX web server as you either protect the key and put the password in clear text in the nginx.conf (see the next step) or just unprotect the key and not worry.  I tend to do the latter.

Next, you need to export the certificate.

openssl pkcs12 -in c:\temp\appvol.pfx -nokeys -out c:\temp\appvol.crt

This gives us a .key and a .crt file.

Let’s drop these in C:\Program Files(x86)\CloudVolumes\Manager\nginx\conf

Replacing the certificates

In the same path that we’ve dropped our files, you’ll find nginx.conf.

You need to edit this. Using Notepad will be fine but take a backup of the file first.

Look for the ssl_certificate entries and replace the filenames with the new files.

Restart your App Volumes Manager Service (or bounce the box if you must).

Connect with the web browser to test:

You now have App Volumes with a trusted certificate and SSL Encryption is good to go!

Closing Thoughts…

In all seriousness, in these days of hackers and generally bad stuff, we need to make sure that we take appropriate measures to harden an estate.  Using signed certificates prevents numerous attack approaches and is certainly worth the effort.

If you are developing an end user compute solution and need assistance designing and deploying the solution in a secure manner, please contact us and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2017.

by Curtis Brown

Following on from my previous blog post which explained what VMware® Horizon FLEX is, I thought it would be worthwhile pulling together my thoughts on what you need to consider when building your own VMware Horizon FLEX estate.

Before you start spinning up servers, you need to consider a few factors.

Infrastructure

FLEX works on the concept of a web server solution that can dish out virtual desktops and then manage them.  As such, the FLEX management server needs to be accessible over the internet (even if only intermittently from the user perspective), either directly (which in many ways is more flexible – pun intended), or potentially via an endpoint based VPN.

This diagram shows the components of FLEX

FLEX is an extension of VMware Horizon Mirage.  The first thing you deploy in a Mirage solution is the Mirage Management Server and its SQL database.  In a FLEX solution, this is just the same.  In later iterations, this Management server also includes a MongoDB database – this is only used for Mirage – if you’re not using Mirage itself, then the 250GB space requirement can be ignored, though putting it on a separate disk is recommended as a precaution.  With the later releases of Mirage, a couple of Mirage Management servers should be deployed for resilience (ideally tucked behind a load balanced VIP), though FLEX is more tolerant of downtime, so this might be something to consider.

The FLEX server itself is actually a component of the VMware Horizon Mirage Web Management Server.  This installer isn’t particularly selective, being an all-or-nothing affair.  Again, for resilience, load balancing a pair is recommended, though a single node can support thousands of endpoints.  In an internet facing deployment, as would usually be the case, VMware recommend deploying the solution behind a reverse proxy to protect it.  Failing that, one option is to deploy FLEX servers in the DMZ, manually deleting the sites related to Mirage management, leaving only the RVM server (Horizon FLEX) and blocking the sub-folders from public access.  It’s not bullet-proof, but it’s a limitation of the software design.

Images are hosted on a simple HTTP web server.  When a user connects to FLEX from the client and downloads an entitled desktop, the client is directed to the appropriate image on the web server for download.  There’s little security risk as the only thing hosted here are the images. These are encrypted anyway, but are otherwise un-configured with respect to Active Directory or user credentials until they are completely downloaded and policy applied.  An interesting option is to use a cloud provider to host these.  This could even be used to distribute the image across different geographies for a global deployment.  It’s recommended, at least from a load perspective (but probably wise from a security perspective too) that the image store isn’t on the same server as the FLEX server in production.

Mirage itself can be leveraged to protect the Windows OS within the deployed desktop.  This involves deploying the agent in the VM.  Architecting Mirage itself is an extension onto what we’ve already deployed – adding Mirage servers with their storage behind a load balancer.  If the VM has a VPN connection into the corporate network, you won’t necessarily need to have this part internet facing. However, if you choose to, the Mirage Gateway could be deployed in the DMZ.  Note that Mirage now uses a MongoDB deployed on the Management server.  This is used as a caching mechanism for small frequently used files, so ensure that this database is on fast solid state storage. Each Management server should be provided with 250GB or more on a dedicated volume for maximum efficiency.

What are you deploying and who is using it?

Consider the target use cases and the image you’re deploying.  If you’re talking about users on corporate machines downloading a desktop, you might have a VPN solution on the endpoint, so you might have a user connecting over VPN, then connecting to the FLEX server and using the image etc.  In a BYOD context, you’ll want to consider VPN within the deployed VM.

When a VM is first downloaded off-site using the FLEX client, it’s literally the raw (albeit encrypted) template image.  The FLEX management server carries out an offline domain join for the VM assigned for the user.  In turn, FLEX generates a blob file that, along with other configuration information, contains the unique windows client information including the client side domain join information.  This is injected into this template allowing the VM to configure on start up.  At this point, the user can log on with their AD credentials.

This does pose another issue though – how does the user authenticate their AD credentials on a new domain joined desktop when they’re offsite?  One solution is to deploy a Read Only Domain Controller that can be connected to by the client.  An alternative is to look at VPN solutions, either in-guest or on endpoint.  Inguest, as a solution, requires that the VPN be initiated on machine start-up so the user can authenticate on logon.  Microsoft DirectAccess can achieve this (and can be configured by FLEX as part of the entitlement), although third party solutions may also work.

Closing Thoughts…

On the surface, it’s a pretty simple product, however, it’s not without complications. These complications lay largely in how to deploy it in an existing environment.  In the modern day where wireless connectivity is relatively commonplace, VDI is often an easier solution to deploy, manage and secure than any offline desktop solution.  However, there are still some use cases where an offline desktop is preferable and FLEX fits this bill nicely.

If you’re interested in VMware Horizon FLEX, want to know more, or require assistance in developing a FLEX solution, please contact us and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2016.

By Curtis Brown

Introduction

This little post is a ‘how to guide’ for enabling encryption on VMware vSAN.  To do this, we’ll need a few ingredients:

• A VMware vSphere 6.5 cluster with VMware vSAN enabled
  
• A Key Management Server Solution (KMS)
  

The Key Management Server (not to be mistaken for Microsoft’s license key solution) provides encryption keys for vSAN encryption.  This should be a robust solution (ideally, multiple nodes) as without this, vSAN becomes inaccessible!  Also, a tip – don’t put your KMS solution in the vSAN you’re about to encrypt, that would be a really bad idea!

In the case of the estate stood up for this blog post, HyTrust KeyControl 4.1 was deployed.  It’s an easy to use product that does exactly what’s required.

Registering the KMS in VMware vSphere

VMware vCenter supports the KMIP standard (VMware have certified a number of products) for connected KMS servers.  In the case of our HyTrust KeyControl appliance, we have to enable the KMIP server service and set the protocol to version 1.1.

We also need to set up a service User account on here.  It’s important not to set a password for this account.  We’re using certificates to authenticate and setting a password prevents vSphere from using the account with the HyTrust solution.  We download the SSL certificate for the user (this is a ZIP file containing the CA certificate and user certificate as PEM files).

Logged on as an administrator in the VMware vCenter Web Client, we open up the configuration of the vCenter server and add our KMS:

We enter a name for the cluster and the details for the first node (we can add other nodes under this cluster later).  The port is 5696 for most solutions.  

We then have to trust the certificate for the Server:

At this point, we have the configuration, but it’s yet to establish a trusted connection.  We need to establish the trust using the menu option below:

There are a few ways of achieving this (see the screenshot below), but we’ll be uploading the certificates snagged earlier:

In our case, we upload the User PEM twice:

And, voila, we’re ready to go forth and enable vSAN encryption

Enabling VMware vSAN Encryption

Here’s the easy bit.  We’ll assume that you already have vSAN up and running and will be enabling vSAN encryption.  If this is a pre-existing cluster, remember to leave room in the cluster to accommodate the emptying and reformatting of a host.  This operation will temporarily remove a host from the cluster as the disk formatting is changed.

We open the Cluster Configuration and select vSAN>General.

Edit the settings to enable Encryption.  We can erase the disks before use if we wish, but the key item is selecting the KMS server and clicking OK.  Allowing reduced redundancy reduces the number of VM data moves while the process to encrypt is under way.

At this point the cluster will reconfigure, enabling de-duplication.  This can take a little while so be patient. And that’s it done.

Closing Thoughts

This is a relatively simple feature to enable, providing a measure of data security for little effort.

If you’re considering developing a VMware vSAN based estate and need assistance, please contact Xtravirt, and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with strengths in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2018.

by Curtis Brown

Once upon a time (in the mid 2000s), VMware decided to delve into the End User Compute market space, taking on the juggernauts of Citrix and Microsoft by releasing VMware Virtual Desktop Manager (VDM). This evolved into VMware View in 2008, and over the following eight years a further re-branding exercise resulted in the release of the VMware Horizon Suite. Our plucky VDI software evolved into VMWare Horizon (with View) then Horizon View with the release of version 6.0, and finally in version 7 ‘Horizon 7’, with the name ‘View’ reserved as a hangover legacy name for the VDM components.

So, as a customer, you’ve decided to invest in VMware Horizon.  These days, Horizon is much more than simply a means to deliver a desktop to a user.  With the modern realisation that the user isn’t really after a desktop (they just want their applications), Horizon is now, more than ever, a suite of products that allow you to deliver applications in a multitude of ways.

This article aims to provide you with a quick primer on these products and how they fit together.  For the sake of simplicity, it will stick to the on-premises offerings, largely as these are still the most common ‘in the wild’, though Cloud based elements, such as AirWatch, are gaining ground.

The Shopping List

Let’s start by exploring the suite from a component level.  The suite comprises the following products*:

Product License Level What does this do

VMware Horizon (

the View component)

Standard

Advanced

Enterprise

Delivers Virtual Desktops as either dedicated VMs or via Remote Desktop Session Hosts (RDSH).

The latter ability is also used to deliver Published Applications (Not in Standard though).

VMware ThinApp Standard

Advanced

Enterprise

This is what is known as Application Virtualisation.  An application is re-packaged in a self-contained executable that can be run on a Windows PC (physical or virtual).  The self-contained nature means that it is essentially sand-boxed – with minimal dependency on the surrounding operating system (required DLLs, configuration etc. are self-contained)

VMware Identity Manager Standard Advanced

Enterprise

This provides user facing authentication and single sign-on (SSO) capabilities as well as an application portal for presenting Virtual Desktops, Remote Applications, ThinApp packages and web-based applications.

The SSO element can be used to provide immediate access to Web based applications if these are capable of SAML-based authentication.

_Beyond Horizon, Identity Manager is available in an Advanced version and as part of AirWatch.  These provide additional features, notably in Mobile Device management including device configuration, remote wipe etc. _

VMware App Volumes Enterprise This product provides the means to deliver defined stacks of applications (AppStacks) to virtual desktops or RDSH servers instantaneously using shared Virtual Disks.

This is quite agnostic – and can be purchased and deployed with other VDI solutions such as Citrix XenDesktop.

VMware User Environment Manager Enterprise This is used to manage user’s Windows Profile – the users environmental and application settings.  The Windows profile is notoriously large and unreliable, especially in a roaming context.  UEM provides a means to streamline and centrally manage the Windows profile, so improving log on times and reliability.

As with App Volumes, this too can be purchased and used outside of Horizon – including with physical devices.  In this context, its central management of settings is particularly useful.

If you’re using Standard or Advanced, the View part of Horizon includes the older Persona Manager product.  This uses a compressed version of the Windows Profile to speed up the delivery of Roaming Profiles to virtual desktops.

VMware Mirage AdvancedEnterprise This provides a layered-image based desktop management solution. Although it can be used in Virtual Machines, it is primarily aimed at the management of physical Windows PCs in a corporate environment.

Its abilities include in place operating system upgrades and the delivery of sets of applications that are layered on top of the base image.  This makes it quite attractive for Windows XP/Vista migrations for example.

VMware FLEX is based on VMware Mirage, combining its technology with that of VMware’s desktop hypervisors – Workstation (for PC) and Fusion (for Apple Mac) – to deliver centrally managed, encrypted offline Virtual Desktops.  This is predominantly intended for BYOD or field staff who require a corporate desktop in a roaming context where connectivity to Horizon might be difficult.  It’s not part of the Horizon Suite and is sold separately.

*the components you’re entitled to depends on the level of licensing you’ve purchased

The Horizon Suite also includes VMware vSphere for Desktops.  This is functionally equivalent to Enterprise Plus in terms of features, but is licensed per desktop.  The idea is that this is used to host the published desktops while the Horizon infrastructure servers are hosted in the corporate server estate.

How it all hangs together…

The following diagram shows how the platform holds together as a single site solution.  This is a somewhat simplified example with no resilient components, firewalls and load balancers and concentrates on Internet based access.

We can see how our user initially connects from their device to Identity Manager.  The user’s device and location can define how they authenticate – for example, access from the outside might need Two Factor Authentication, whereas an internal user might just need an Active Directory Used ID or password.

Once authenticated, the user can see the applications they are entitled to.  Let’s first look at a Cloud based application such as SalesForce.  If the user selects this, Identity Manager (having already been configured with a SAML relationship to Salesforce), passes the user authentication as a token to the user’s browser accessing the Salesforce application – without them needing to log on a second time.

When considering an application or desktop presented by Horizon View, the request is passed to the Connection Servers.  These will initiate a session to an available desktop (either VDI or RDSH, depending on what is requested) – in the case of VDI desktops, these can be provisioned as Linked Clones using Composer.

As the VDI session is logged on, the App Volumes Agent detects the credentials and App Volumes mounts an entitled AppStack containing the application required.  The user’s Windows Profile is provided via UEM.  For internet-based users, the View session is tunnelled out via the Security Server/Appliance in the DMZ.  Internal users connect directly to their session (though this can be configured to tunnel via the Connection server).

ThinApp packaged applications may well be deployed to the Horizon desktop (possibly inside the App Volumes AppStack), but as an alternative, if the Workspace ONE client is installed, Identity Manager can stream a selected entitled package directly to the user’s Windows laptop/desktop, straight from the Identity Manager Portal (this isn’t shown above).

Alternatively, VMware Horizon Mirage can be used to manage and protect our PCs, whether within the network or outside (via the security gateway in the DMZ).

Closing Thoughts

The Horizon suite has quite a few elements, each delivering different pieces of the puzzle – even in a basic configuration.  However, in concert, the solution is quite seamless to the end user.  The single point of access and authentication becomes Identity Manager, with this presenting all the entitlements desired through a single pane of glass.

If you’d like to learn more about VMware Horizon and how to use it to deliver applications to end users, please contact us and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2017.

by Michal Grzeszczak

My name is Michal Grzeszczak and I am a senior consultant at Xtravirt (www.xtravirt.com), an independent cloud consulting business and VMware Master Services Competent Partner.  In this blog, I’d like to share with you my experience of L2 bridging with VMware® NSX-T Data Center and help you to understand some of the differences between NSX-T and NSX-V, as well as cover some NSX use cases.  

Customer background:

The customer is one of the leading organisations in the betting and gambling industry and have been using NSX-V for some time now. When it came to their new greenfield environment, they decided to deploy NSX-T 2.4 Data Center. This decision was largely based on the fact that NSX-T Data Center provides bridging firewalls natively for L2 software bridging, which was their main requirement. Also, given that NSX-T will be the de facto network and security virtualisation platform offered by VMware going forward, by specifying it for this environment the customer is able to future proof the deployment. 

Future upgrades are also accounted for as upgrading from NSX-T 2.4 to future NSX-T releases is simpler than performing upgrades from a previous version of V or T.

NSX-T 2.4 was a major update and brought many changes to the architecture of the product, the main ones being:

• The NSX Manager and NSX Controllers were merged into one appliance deployed in a Cluster of 3 Nodes therefore minimising the footprint of the solution and operational complexity. 
• The other major change was the introduction of the new Simplified UI which “requires just the bare minimum of user input, offering strong default values with prescriptive guidance for ease of use. This means fewer clicks and page hops are required to complete configuration tasks.”

NOTE: In NSX 2.4 two UIs are presented - one is the new Simplified UI, the other one is Advanced. The latter is taken from NSX-T 2.3. The future plan is to remove the Advanced UI and provide all of the functionality via the Simplified UI.

 What are the key benefits of choosing NSX-T over NSX-V?

 There are many benefits of NSX-T over NSX-V, to name a few:

• NSX-T doesn’t require vCenter, however it can be added to NSX-T as a Compute Manager and allows for up to 16 Compute Managers per NSX 2.4 solution . There is no longer a 1:1 requirement like there was with NSX-V. 
• KVM Hypervisor support
• Bare Metal Edges provide sub-second failover 
• Data Plane Development Kit (DPDK) Optimising Forwarding - DPDK is a set of data plane libraries and network interface controller drivers for fast packet processing
• New, more flexible Overlay technology - Geneve replaces     VXLAN  https://docs.vmware.com/en/VMware-Validated-Design/4.3/com.vmware.vvd.sddc-nsxt-design.doc/GUID-CF3C47CA-9BEB-4213-8F08-1494261BF3EC.html 
• Bi-directional Forwarding Detection support
• BGP (Border Gateway Protocol) expanded functionality with features like Route Maps
• Much clearer User Interface (UI)

What were the specific use cases for this case customer and the design considerations?

USE CASE 1 - NSX-T Edge L2 Bridging - Integration of physical, non-virtualised database servers that require L2 connectivity to the virtualised environment. 

Design considerations:

• In NSX-T 2.4 two options are possible to bridge L2 workloads - using ESXi Bridge Clusters or Edge Bridge Profiles. The latter is recommended to use as the former will be deprecated in future. 
• Ideally the use of dedicated Bare Metal Edges, however this is not a requirement. 
• The possibility to deploy Edge Bridges in collapsed vSphere Clusters >     Management + Edge or Compute + Edge
• Consider having active and standby Edge Nodes on different hosts to avoid throughput drop, because VLAN traffic needs to be forwarded to both Edge Nodes in promiscuous mode.
• Overlay traffic can be tagged on a Distributed Port Group or Uplink Profile, but please avoid double tagging. 
• VLAN traffic should not be tagged on the Uplink Profile.
• Distributed Port Group for VLAN traffic connecting to the Edge Node should be in a Trunk Mode. The reason for this is due to the fact that Edge doing Bridging adds 802.1Q tag when transposing Overlay traffic to VLAN. 
• Consider having the same MTU value across your environment - if you can, choose MTU of 9000 for better performance. 
• Several Bridge Profiles can be configured, and a given Edge can belong to several Bridge Profiles. By creating two separate Bridge Profiles, alternating active and backup Edge in the configuration, the user can easily make sure that two Edge nodes simultaneously bridge traffic between Overlay and VLAN

Constraints:

• Edge Cluster with minimum 2 Edge Nodes in Active/Standby mode is needed.
• Standby uplinks are not supported on the Edge Node.
• Source Based Load Based Teaming is not supported on the Edge Node.
• The port group on the VSS/VDS sending and receiving traffic on the VLAN side should be in promiscuous mode, allowing MAC Address changes and Forge Transmits.

Deployment:

• Follow the deployment guide here - https://youtu.be/IwpujflzJhY 
• Or here https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.3/com.vmware.nsxt.admin.doc/GUID-7B21DF3D-C9DB-4C10-A32F-B16642266538.html 

Validation:

• Log in to the Edge Node with your credentials.
• Type “nsxcli”.
• “Get l2bridge-ports-config” will show the Bridge Port State (Active Edge will have Forwarding, Standby will have Stopped), VLAN ID configured and Bridge UUID which can be copied and used to do a packet capture on the Edge Node.
• To do the packet capture type “start capture interface “copied Bridge UUID” and hit enter, ping from VM to Physical Server to see the flows. 

USE CASE 2 - NSX bridging firewall - Secure communication between physical database servers and Overlay workloads.

• The configuration of the bridging firewall can be done currently only on the Advanced UI.
• Security rules are configured per Logical Switch aka Segment in Simplified UI. 
• NSX-T grouping objects like NSGroups can be used to provide abstraction from the IP based approach.

USE CASE 3 - vRealize Network Insight - Monitoring tool that can provide visibility into both Physical and Virtual environments. 

• NSX-T 2.4 is fully supported with the latest vRealize Network Insight version 4.1.
• Make sure you are allowing ports for communication between vRNI and other devices after the deployment. For example, ESXi Hosts to vRNI Collector on UDP 2055. The full list of ports needed can be found here - https://docs.vmware.com/en/VMware-vRealize-Network-Insight/3.9/com.vmware.vrni.install.doc/GUID-FDDA5F2F-7C3B-472A-A17D-39582FBD5996.html 
• There is a new website that provides in-depth information about new features in vRNI, definitely worth visiting - https://vrealize.vmware.com/t/vmware-network-management/  

What were the outcomes?

Overall, this deployment was a complete success as we were able to satisfy all of the requirements that the customer had. All the production physical databases were able to communicate on the same L2 segments, virtualised and connected to NSX-T segments workloads. On top of that, communication between those workloads was secured by NSX-T Bridging Firewall. vRealize Network Insight was used to provide visibility into the environment. Its ability to quickly troubleshoot network and firewall related issues in both virtual and physical realms allows admins to take a breath in the never-ending battle of making the networks stable.

I hope you enjoyed my blog, if you’d like to talk to Xtravirt about your business’s networking and security requirements, then please send an email to info@xtravirt.com

Some Useful links:

You can read more about the NSX-T 2.4 release here: https://blogs.vmware.com/networkvirtualization/2019/02/introducing-nsx-t-2-4-a-landmark-release-in-the-history-of-nsx.html/