The Digital Workspace – I Fight For the Users

The Digital Frontier Workspace
tron_1982_movie_poster_01

In the 1981 version of the movie TRON, there is a phrase that TRON says and sort of defines his purpose. The phrase he uses is “I Fight for the Users”.

Having become a VDI/Presentation specialist over the past several years, I’m pretty sure I’ve felt this way several times. At the end of the day, our job as IT employees is to provide value to the business. Below is a quick list of things I’ve done in the past that felt like I had to “Fight for the users”

  • Proved the need for more compute resource for overly dense environments
  • Rationalize the upgrade of underperforming storage
  • Justified the value of graphics capabilities inside a remote session
  • Worked with IT departments to enable faster and less disruptive delivery of updates and net new applications
  • Troubleshot performance, network and software issues that were impeding progress of application delivery

The transformation of “remote access” to “Digital Workspace” has been a very long time coming, and for the most part the concept isn’t new. The new catch is that with the prevalence of SaaS becoming a normal delivery method of applications, this can add a great deal of complexity when attempting to deliver all the applications someone might need in a “one shop stop”. This was the message from the stage at VMworld this year. “Consumer Simple, Enterprise Secure” was the verbiage Sanjay Poonen used. He also used the term “Sesame Street Simple”, to describe the end user experience for signing on and accessing applications safely and securely, with a fast and simple BYOD enrollment process.

Here is where it gets fuzzy, the “Sesame Street Simple” concept in my opinion does not necessarily apply to the engineers and architects behind the solution. It’s the same when developing software, in order to make it simple for the end user it requires a very high amount of complexity on the backend to make it work with as simple of a workflow as possible. We can simplify on portions of the tasks such as the storage and compute expansion with the prevalence of HCI, but overall, providing a one shop stop to on-prem and SaaS based apps with one sign-on action is a daunting task. It’s for this reason that I bring up the concept of fighting for the user, this is not an easy task. It’s a fight that we must constantly keep in mind, that we are in the business of enabling the business, and therefore the users, regardless of where the applications reside. I fight for the users, and sometimes that means against IT departments who are reducing their value proposition in a fast shifting SaaS landscape. If you cannot service the business with an acceptable SLAs or timely responses, shadow IT will creep in, and/or it will cause damage to the organization.

Myself, I will continue to propose solutions that ATTEMPT to make lives easier for both end users and the engineers, but the very nature of making it simple on one side of the equation will almost always make it more complex on the other.

In regards to Workspace One, I’m actually very excited to watch the evolution of A2, which will be delivering AppStacks directly to physical Windows 10 endpoints, likely via AirWatch. As a former veteran Microsoft SCCM (ConfigMgr) engineer, delivering applications and controls on Windows devices that aren’t connected to the corporate network isn’t a new concept, it’s been possible by establishing a PKI for quite some time, albeit complex. What is new is the concept that with the improvements that the Windows 10 operating system has brought about, it’s now possible to manage policy and applications on Windows 10 devices natively with Unified Endpoint Management software, which can provide sandboxing technology. This sandboxing and isolation is a BYOD game changer and when combined with application delivery and seamless experience between different operating systems and devices can make a huge difference and reduce the BS logon and auth time in-between actual work. It’s my personal opinion  that we’ll see a real uptick in uptick in UEM combined with Digital Workspace transformation the next 3 years.

Until next time my friends, I hope to see you all on the battlefield of fighting for the users.

Posted in Uncategorized

Horizon View 6.2 – Cannot Disable Connection Server – Failed to update Connection Server

Recently saw an error message when trying to disable the connection server via the admin UI, which reads:

Failed to update the Connection Server.

Images taken from a twitter post by Ronald Westerhout @rwesterhout81

Untitled

So it turns out from Ronald that unless you have both the SSL gateway and Blast gateway either checked OR unchecked the disable button won’t work. Not sure in what versions of View this problem exists, because I’m pretty much only disabling connection servers when there’s a problem or when doing an upgrade. Either it’s a bug, or a KB needs to be built for this error dialog. Until then, I hope this post finds you well fellow Horizon administrators!

Capture

 

Posted in Uncategorized

How To Reclaim ESXi VMFS storage with Ubuntu VMs

First of all, zero the space in the guest. You can do that easily with secure-delete. In the Ubuntu guest, this srm command will recursively delete all files and folders, quickly, verbosely, zero the old file and will only do it with one pass.

df -h
sudo apt-get install secure-delete
sudo srm -r -f -v -z -l -l /dir/to/clean/*
df -h

Next, simply vMotion the VM to another datastore with the thin option set. If that’s not an option for you, you’ll need to power off the VM.

In ESXi:

<Power off the VM>

cd /vmfs/volumes/to/your/vm/folder
vmkfstools --punchzero vmdk-to-shrink.vmdk
Posted in Uncategorized

Load Balancing Horizon View with NSX

This post will explain in detail how I was able to set up NSX load balancing in a test environment and was still able to meet the requirements I had for load balancing. The requirements I had for a load balancer for Horizon View were:

  1. As simple as possible
  2. Session performance is acceptable and scalable
  3. Ability to automatically fail nodes so a reconnect gets back in less than one minute
  4. Balance Horizon View SSL, PCoIP and HTML5 Blast session traffic appropriately
  5. The entire solution must be able to leverage a single public IP address for all communication

So there are to primary ways of constructing an NSX load balancer, inline or one-armed. These drawings were borrowed from a VMworld 2014 slide deck.

in-lineone-arm

In this particular example, we opted for one armed, which means the load balancer node will live on the same network segment as the security servers.

Let’s take a look at logically how this is set up in the test lab. You may notice that I used two ports for PCoIP, 4172 and 4173. This is because I wanted to keep it as simple as possible, and with the requirement of a single IP address, keeping the PCoIP listen port for each security server separate was the easiest option. I was able to load balance and persist both 443 and 8443 with NSX, but stepped around the balancing for PCoIP and simply passed it through. In production you can just use another public IP address if you want to keep PCoIP on 4172, then just NAT it to the corresponding security server. If you need more detail on the lab setup, you can check out my previous post which has more detail on the firewall rules used.

logical-loadbalancing

General finding notes about the setup before we get into screen shots:

  • The demonstrated configuration is for external connectivity only at present, since persistence matters most when tunneled.
  • SSL passthru is utilized rather than offloading.
  • The DFW is in play here as well, and all firewall rules are in place according to to required communication.
  • In order to configure the security server to listen on 4173, I had to follow the KB and create a reghack on the box, AND configure the tunnel properly in the View GUI.
  • In order to get SSL and BLAST working together from a single VIP, I ended up needing separate virtual servers, pools and service monitoring profiles that all used the same VIP and Application profile.
  • I ended up using ssl_sessionid as the persistence type for both SSL and BLAST, and ended up using IPHASH for the load balancing algorithm.
  • I wasn’t able to configure a monitor to correctly say that 8443 was UP, instead it was in WARN(DOWN) on the 8443 monitor. I opted to simply leverage 443 as the monitor for the blast VIP, so there could potentially be a missed failover if only the blast service was down.

Let’s take a look at the configuration screen shots of the View specific load balancer edge that I used.

NSX-LB2015-09-24 23_17_41

We opted for the simple configuraiton of SSL passthrough and SSL Session ID was used for persistence.

NSX-LB2015-09-24 23_18_01

I found you had to create a separate monitor for each pool for it to function properly, not really sure why.

NSX-LB2015-09-24 23_31_03

You should be able to use the /favicon.ico to determine health as we do with other load balancers, but the plain GET HTTPS worked for me and favicon didn’t.

NSX-LB2015-09-24 23_31_16 NSX-LB2015-09-24 23_31_25

** Important, notice that no ports were specified in the server  pool, only the monitor port. That was specified only in the virtual servers below.

NSX-LB2015-09-24 23_43_47 NSX-LB2015-09-24 23_43_59

NSX-LB2015-09-24 23_45_04

NSX-LB2015-09-24 23_45_13

NSX-LB2015-09-24 23_46_20 NSX-LB2015-09-24 23_46_41

Let’s take a look at the screen shots of the View security server configuration.

 


ss1

ss2

If you have to make a security server listen on another port, don’t forget to change it in the registry as well as in the secure gateway URL field. Also don’t forget to let it through the firewall.

ss3

And voila! We have a working configuration. Here’s a quick demonstration of the failover time, which can be completely tuned. Of note, we only tested Blast failover, but SSL and PCoIP work just fine as well. The best part is we were able to create a COMPLETELY separate isolated and firewalled security server without even leveraging a DMZ architecture.

If you’re looking for another AWESOME post on how the NSX load balancer is utilized, I learned more from this one by Roi Ben Haim than from the pubs. Great step by step setup that helped me big time.

Posted in Horizon View 6.0, NSX

Horizon View and VMware NSX – Zero Trust Install

EDIT: 8/28/2016 There’s now a fling that will automatically prep rules and security groups for you. https://labs.vmware.com/flings/horizon-service-installer-for-nsx

Dave Kennedy is a netsec veteran and industry leader in the information security space, has written multiple books on the topic of penetration testing, is the founder of @TrustedSec, wrote the Social Engineering Toolkit, founded @Derbycon and on and on. Point is dude knows how to find a way in and pop a box like a boss. Check out this tweet he had not too long ago.

zero1

And with that red underlined statement, in my mind the micro segmentation use-case for VMware NSX speaks for itself. One of the easiest places to get access to from the outside is a user’s desktop, simply because users (often times helpdesk) can be tricked into going to a malicious website which can exploit the user’s desktop. We see this time and time again with not just email attachment, but phone spear phishing as well. Protecting the virtual desktops and servers with the DAPE model (Deny All Permit Exception) is becoming not a nice thing to have, but a near requirement for many businesses. One which security and networking teams are having a hard time doing once inside the perimeter and underneath the DMZ, especially with east west traffic inside defined networks.
It is for this reason I have been working the past few weeks on integrating NSX 6.2 and Horizon View 6.1 in my lab to implement not only zero trust desktops, but an entire zero trust hardened Horizon View Infrastructure. To me, a zero trust network infrastructure is pretty much like getting network access on a “need to have basis”. Unless specifically allowed (by policy), you’re blocked (by policy); not by traditional IP based rules. The pieces I set up in my lab include minimum functional connectivity to service the following components and services:
  • Horizon View Connection Servers
  • Horizon View Security Servers
  • Connectivity with vCenter and Horizon View Composer
  • Virtual Desktops with Identity based Firewall
  • NSX Load Balancers (will do a separate post for this)
Let’s take a look logically at how the lab network is set up. It’s important to remember that while I set these up with NSX based logical networks for scalability, the NSX DFW (distributed firewall) does not require any NSX logical networks to function; the DFW can work just fine even with standard virtual switching because the firewall lives in the ESXi kernel.

zero2

Now let’s take a look physically at how this simple lab is set up.

zero3

Now let’s talk about some of the View components and what east-west and north-south we firewall rules we conceptually need to make to create to harden the horizon environment, not including user defined rules. The below generic categories are in regards to traffic we need to concern ourselves with. Remember, we are not providing and open IP stack, rather providing only the required ports for the software to function. Most of these ports can be found at the KB which defines View connectivity requirements.
Security Server
View Security Servers <–> HTTPS, PCoIP, Blast
View Security Servers <–> Virtual Desktops
View Security Servers <–> Virtual Desktops
Block the rest
Connection Server
View Connection Server <–> vCenter Server
View Connection Server <–> View Replica Server
View Connection Server <–> Virtual Desktops
View Connection Server <–> AD/DNS
View Connection Server <–> View Security Server
View Connection Server <–> View Administrator Static IPs
Block the rest
Virtual Desktops
Virtual Desktops <–> AD/DNS
Dynamic User Logins <–> Specified Internal Resources over Specified protocols
Block the rest
So now that we’ve seen the categories conceptually, let’s look at the service definition and service groups that I came up with. I broke them up into three basic categories.
  • Active Directory/DNS
  • Horizon View
  • User Defined

Let’s take a look at the active directory rules per several microsoft KB’s and some trial and error.

Custom Active Directory Aliases (NSX individual “Services”)

services1
Custom Horizon View Aliases (NSX individual “Services”)
services2
So we can group up those services into service groups for easy clean looking rules. Let’s take a look at those.
View Connection Server <–> vCenter
servicegroup1
View Security Server <–> View Desktops
servicegroup2
Security Servers <–> Connection Servers
servicegroup3
View Desktops <–> Connection Servers
* Interesting note, at the time of writing with View 6.1.1 TCP 4002 was not a documented port requirement in the network requirements KB between desktops and connection servers and I found that it was definitely needed.
servicegroup4
servicegroup5
View Desktops <–> AD/DNS
ad1 ad2 ad3
View Connection Server <–> View Connection Server
*Note that even though it’s not documented, ADAM requires the random port range. Screen shot below of the connections…
servicegroup6
servicegroup7
servicegroup8
servicegroup9
Even though they’re not documented on the network page, I found most ports for AD (ADAM) communication are required from Connection Server to Connection Server. Was able to find this when I kept banging my head during the second connection server install with Log Insight.
netstat
User Defined Security Groups
So first of all you have to integrate the NSX manager with Active directory so that you can pull users and allocate ACLs based on users in AD. Do that under the NSX manager \ Manage section and add the domain.
nsxmanager
Once the domain is configured, now we can actually add users into the security groups that we’ll use in the firewall rules. Let’s look at one of the dynamic user examples we’ll go over in this post, View Helpdesk staff that need access to the view admin manager web page and the vCenter web interface, but nothing else. Go to the grouping objects then security group and make a new security group:
dynamicuser1
Then let’s pick the user group out from AD that we already selected. Note the required menus to select the user group.
nsx_dynamic_user2
And finish after excluding anything you want to make sure is always excluded from the security group, eg, domain controllers, whatever. If directory group is not an option, you need to check your domain integration from the previous step.
So now that we’ve defined the source and destination, service groups and dynamic user groups to be firewalled, let’s check out the firewall rules that tie it all together with some commentary.
Desktop_Allow_Rules
I put all the block rules last per norms of DAPE ACL ordering. We can see here that rules 1 & 2 are based on NSX_View_Helpdesk_Access has static access to a couple VMs, View, Log Insight and vCenter via HTTPS.
Most of the security groups for the desktops had dynamic membership based on VM name, such as Win7-, but other filters could be used as well such as OS Windows 7, etc.
rules1
VDI_Infra_Allow_Rules
Here I specified all the required rules in and out of the VDI infrastructure, including open IP stack from a couple manually specified administrator desktop IP addresses. Notice how nobody even has access to the connection servers except the admins?
rules2
VDI_Block_Rules
These rules block any traffic in or out of either desktops or security servers unless specified above.
rules3
Results are good and as intended.
win7002
We can see that dynamically the user on the VM was picked up and the VM was added to the rule.
userdefined1
Big Picture Lessons Learned
  1. Knowledge of traffic being dropped by the DFW is paramount, otherwise you’re going to HAVE A BAD TIME, lol (Southpark anyone?). Seriously, though, you need to be able to troubleshoot and loosen ACLs for required traffic and find undocumented port requirements like I had to for View, and they have GREAT network requirement documentation. The best way I came up with to find this information quickly is to log all firewall rules, and then leverage VMware Log Insight with the NSX plugin to filter on drops (installs in like 15 minutes). Made it super simple to figure out what ports were being used between two endpoints. Flow monitoring with NSX 6.2 is another great option to use before putting the rules in place to understand different sources & destinations in play.LogInsight1
  2. With NSX 6.1.4, if VMware tools wasn’t running in the VM and vCenter didn’t know the IP address of the VM, none of the DFW rules took effect with the VM selected as the source. Now with 6.2, DFW rules apply whether or not vCenter is aware of the VM ip address. The problem was easy enough to fix with a IP subnet based block catch-all rule, but the point of policy driven access is getting away from static configurations.
  3. If you change user group membership in AD, you must resync the AD deltas from within the vSphere web client for that to take effect immediately.
  4. With NSX 6.2, there is a drop-down option when creating the firewall rules to block traffic in/out of the source destination. I found that to completely block traffic in both directions, two rules were required with source destination reversed.

I would absolutely love to give y’all an export of the rules so you could just import them, but sadly it’s not that easy to import them once the XML is exported. As soon as Tristan Todd’s rumored NSX rule import fling is available, I will post a CSV with all the Services, Service Groups and Firewall Rules so you can start with what I put together and automatically import them.

I hope this was helpful for you guys! Next up, I’ll be introducing security server load balancing with NSX, followed by AppVolumes integration, Trend Micro Deep Security AV and hopefully more.

Posted in Horizon View 6.0, NSX, View

How to configure PERC H730 RAID Cards for VMware VSAN

Hey All, just wanted to write up a quick post with pics on how to configure the H730 RAID card for VMware VSAN.

First of all, the H730 is on the HCL and is a great choice due to the ample queue depth of 895 as determined by esxtop.

queuedepth

The following was how we configured it per the configuration guide best practices with:

  • Passthrough mode
  • Controller caching disabled
  • BIOS Mode pause on error (rather than stop)

Per the guide:

raid02

Just figured this might help some other wayward souls out there. : )

raid01

raid_03 raid_04 raid_05 raid_06

 

Tagged with:
Posted in Uncategorized

Bobby Boucher, persistent virtual desktops ARE THE DEVIL!

BobbyBouche

No they’re not. In fact, most desktops are persistent, they’re just not virtual. Other industry experts have already had this discussion many times and I think it’s my turn to sound off.

I have to be completely honest, I’m just plain tired of the headache that non-persistent just ends up causing from a management perspective, especially when a group of users is  placed in the wrong use case bucket because the proper strategic use-case analysis wasn’t performed in the first place. Sometimes that stateless headache is totally worth it, and other times it isn’t. The concept of deleting a user’s desktop when they log off is noble from a clean and tidy “fresh desktop” configuration standpoint, but it also inherently causes a number of different issues that plenty of customers just can’t seem to get past in the long haul, especially if use case is incorrectly assessed initially. It takes a lot of administrative work to have a near-persistent auto-refreshing desktop experience, so let’s just break this down for a second with some simple pros and cons for each.

Non/Near Persistent Desktops

PROS

  • Can meet very low RTO/RPO disaster recovery requirements with abstracted user files/app data
  • In environments with rolling concurrent session counts it can reduce overall costs
  • Will allow for the fastest provisioning of desktops (especially with project Fargo)
  • Storage capacity requirements can be reduced because of natively thin desktops
  • Logging onto recently refreshed desktops ensure a consistent operating environment
  • Fits a large majority of task worker and non-desktop replacement use cases extremely well

CONS

  • A UEM is required to persist application data and user files, staff must learn and become comfortable with the tool
  • Application delivery and updates must (for the most part) be abstracted and delivered and updated quickly. This often times requires additional software and training (App-V, AppVolumes, Thinapp, etc)
  • Any appdata problems that persist in the profile completely negate the “fresh desktop” stateless desktop idea
  • Does not typically integrate well with traditional desktop management solutions such as SCCM, LANDesk and Altiris
  • The smallest configuration change for a single user in a stateless desktop can result in hours of work for the VDI admin
  • Applications that require a non-redirected local data cache must be re-cached at each login or painfully synched via the UEM

Persistent Desktops

PROS

  • Users live on their desktop, not partly on a share and partly in a desktop
  • Consistent experience; the smallest changes (including those performed by the helpdesk) unquestionably persist
  • Simple to administer, provision and allocate
  • Fits all desktop replacement use cases extremely well
  • Desktop administrators do not need to introduce new management tools
  • The user pretty much never has to be kicked out of their desktop except for reboots required by patches, software installs

CONS

  • Any disaster recovery requirements will add a lot of complexity, especially without OTV
  • Non-metrocluster persistent desktop DR plans typically dictate 2 hour+ RTO for environments at scale
  • Persistent is resource overkill for the task worker and occasional use non-desktop replacement use cases
  • Can be cost prohibitive for rolling concurrent session counts it can increase overall infrastructure costs to give 1:1
  • Year 2 operations can fail to be met; operational “this person left 2 years ago and is still on his desktop” type problems
  • Relies on existing application distribution expertise
  • Problems in the desktop must be handled with traditional troubleshooting techniques
  • Without proper storage infrastructure sizing underneath, simple things like definition updates or a zero day patch can make an entire environment unusable

My big picture take aways:

Perform strategic business level EUC/mobility use case analysis up front. If an optimized method of delivering EUC is realized, select the best combination of desktop and/or server and software virtualization for the business. Once the technology has been selected, do the detailed plan and design for the chosen technology. Don’t slam both the strategic business analysis and the product design together because you need take a good hard look at what you actually need and where you can optimize before you put a blueprint together. As a part of the business use case analysis, ensure to get sign off on the virtual desktop availability and recoverability requirements. The outcome of such an analysis should provide information in regards to which specific departments will have a great outcomes with a virtualized desktop experience and which ones have less or no value.

Are you building an infra that will let you provision virtual desktops with amazing speed and IOPS galore? Great! That’s not the only goal. Make sure it’s merely a dependable component of a solution that is manageable and meets the business requirements.

Going with a non-persistent desktop to save on storage space is ludicrous, especially with the prevalence of high performing storage platforms with block level deduplication available today and the amazing low TCO of HCI.

The idea that a non-persistent desktop is easier to manage because of the available tools is complete nonsense. There are risks and rewards for both choices. For example, there are plenty of medical use cases that are terrific fits for non-persistent desktop because of the lack of personalization and individuality required; most of the time the staff members use kiosks so a generic desktop is nothing new to them. However, take a senior corporate finance officer who has a critical Access 97 database with custom macros and software dependencies that took a VBA consultant 1 year to write, and who also has more manually installed applications his desktop support has ever seen and you’re going to be a sad person if you put then on a non-persistent desktop.

If you ask me, once the DR complexity for persistent desktops is fixed, it will drastically shift the conversation again.

As usual, if there are any pros and cons I forgot, feel free to sound off, argue, high five me, or not.

 

 

 

 

 

 

 

Posted in Uncategorized
Papers
People
Map

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 27 other followers