Making Royal TSX Even More Awesome

For those who don’t know, Royal TSX is an awesome Remote Management solution, which supports RDP, VNC, SSH, S/FTP and even ESXi and vCenter. I’ve been using it for years, not just because they offer free licenses for vExperts (and others), but simply because it works really well. Store it’s config file on a synchronized file area (like Dropbox), and boom, your config follows you around from machine to machine, including custom icons. What’s not to like?

Following Ryan Johnson’s tweet, where he showed off his VMware Clarity inspired Royal TSX setup, I decided to do something similar. Unlike Ryan, I decided to run with the standard Clarity icons, and not invert them. Since the Clarity icons are in .svg format, I had to convert them to .png to be able to use them as icons in Royal TSX, I’ll post a separate post on how I batch converted them later.

Currently, my setup looks like this

Royal TSX with Clarity icons

Changing the icons for entries is pretty straight forward. For existing entries in your config file, simply open the items properties and click on the small icon besides the Display Name. This brings up a dialog showing the built-in icons, but also reveals an option to browse your filesystem for a new icon to use.

Update: Felix from Royal Applications left a nice comment, explaining that you can also drag-and-drop icons directory from finder into Royal TSX as well as the manual process described above.

To change the default icons, find Default Settings in the Navigation Panel on the left, and follow the same procedure.

While the primary goal was to prettify my setup with snazzy new icons, I discovered that I could do quite a few things besides that as well.

As seen in the screenshot, there are a couple of web pages added, but perhaps more interesting are the “PowerCLI” and “Connect VPN” entries.

Running PowerCLI Core from Royal TSX

I run the PowerCLI Core Docker container on my Macbook from time to time, so why not have the option to run it directly from Royal TSX? Once you have it up and running, adding it as a Command Task is pretty easy!

Add a new Command Task, and put in the docker run command in the Command: field

Update: Since originally posting, I’ve discovered that there is an even better ways of doing this, and at the same time keep your PowerCLI running in a tab inside of Royal TSX. Instead of adding it as a Command Task, add a new Terminal connection, but use Custom Terminal as the connection type:

Then add the command you want to run under Custom Commands

In my case, I want to run the following command:

docker run --rm -it --entrypoint='/usr/bin/powershell' vmware/powerclicore

Now, under “Advanced”, find the Session option. Enable “Run inside login shell” to make sure your applications, like Docker, are found without having to specify the complete path to it, and that’s it. As long as Docker runs locally, PowerCLI core can now be launched directly from the navigation bar, and it opens a new tab inside of Royal TSX!

This can also be used to run other things of course, I’ve added a new Terminal option to my sidebar as well, which opens iTerm2 in a new tab.

Connecting Tunnelblick VPN Royal TSX

I run OpenVPN at home, and use Tunnelblick as my client of choice. In order to connect to my home network, I’ve created another Command Task, with the “Run in Terminal” option configured, that runs a simple AppleScript command instructing Tunnelblick to connect.

osascript -e "tell application \"Tunnelblick\"" -e "connect \"[your-connection-name]\"" -e "end tell"

I guess I really understated the percentage of awesomeness increase by doing this, it should at least have been 84% 92,7%.

 

VMware vSAN 6.6 – What’s New for Day 2 Operations?

VMware has just announced vSAN v6.6, with over 20 new features. While new and shiny features are nice I’d like to highlight a couple that I think might be undervalued from release feature-set perspective, but highly valuable in day to day operations of a vSAN environment, otherwise known as Day 2 operations.

vSAN Configuration Assist is one such new feature. While it’s true that it helps first time configuration of a greenfield installation with vSAN (no more bootstrapping, yay!), it also helps with Day 2 operations.

It helps configure new hosts added to an existing vSAN enabled cluster, but it also makes it possible to automate updating of IO controllers, both firmware and drivers directly from within vCenter. As everyone should know by now, vSAN is highly dependent on drivers and firmware being on supported levels. This improvement helps the improved vSAN Health Check (Enhanced Health Monitoring) alert you when new and verified drivers/firmware are available, and if the controller tools are available on the ESXi host, it can also update the firmware for you.

Directly from vCenter, utilising maintenance mode like you’re used to from patching your ESXi hosts from VMware Update Manager (even if it’s not integrated into VUM at this point).

This new features takes the vSAN HCL list to a new level, it’s no longer just a list over supported IO controllers and their firmware and drivers, it’s a now also a software distribution point. At the moment Dell EMC, Fujitsu, Lenovo and SuperMicro are all supported vendors for this new distribution model, hopefully the rest will follow suit quickly.

The second feature I would like to highlight as a Day 2 operations enhancement, is the new vSAN Cloud Analytics feature. If you participate, in the Customer Experience Improvement Program (CEIP), it will enable custom alerting for your environment, based on your own environment. For instance, if a new Knowledge Base article is published, that pertain to your specific setup, it will alert you about it. One example might be if you have Intel X710 NICs, which can cause PSODs — Wouldn’t it be nice if you got alerted that this might be an issue, and then told how to remediate it? Well, with vSAN 6.6 you’ll get exactly that.

With vSAN 6.6 you get both automated, and verified, firmware/driver upgrades, as well as proactive alerting for potential issues through the hive-mind that is the analytics service. This is what VMware calls Intelligent Operations and Lifecycle Management in this release, and it’s really hard to argue with that.

Of course, vSAN 6.6 provide other Day 2 Operations enhancements as well, like Degraded Device Handling (DDH), Simplified Stretched Cluster Witness replacement procedures, Capacity and Policy Pre-Checks and access to the vSAN control plane trough the ESXi Host Client, but I’ll leave those for later posts.

Centrally Disable NAT in VMware Workstation

A fellow IT-professional, who works with the non-wired flavor of networking, contacted me with the following scenario:

A group of users, developers in this case, have VMware Workstation installed on their laptops. This makes it easy for them to manage, test and develop their applications in a closed environment without having to install a bunch of tools/services on their centrally managed laptop environment. An excellent use case for VMware Workstation if there ever was one.

So far, so good. The problem in this particular case was that due to security policies in the network infrastructure there was a need to disable the NAT networking possibilities in VMware Workstation.

Network address translation (NAT) configures your virtual machine to share the IP and MAC addresses of the host. The virtual machine and the host share a single network identity that is not visible outside the network. NAT can be useful when you are allowed a single IP address or MAC address by your network administrator. You might also use NAT to configure separate virtual machines for handling http and ftp requests, with both virtual machines running off the same IP address or domain. See Network Address Translation (NAT).

VMware Workstation NAT Configuration
VMware Workstation NAT Configuration

Since the VM shares the host MAC address and IP, blocking network access from the VM is not trivial in this scenario.

Thankfully, in VMware Workstation for Windows, NAT is provided through a Windows Service that we can manipulate. By disabling the “VMware NAT Service” we can ensure that NAT does not work, and that the only real alternative is to run the VM in “Bridged Mode”.

Bridged Mode makes it easier for network admins to manipulate access, since the virtual network adapter is exposed to the switches with their own MAC address, and thus possibly also their own IP address, and the VM is not “hidden” behind the hosts MAC. For instance, this makes it possible for the network gurus to limit the VMs physical network access to internet access only, and not exposing the internal network to the VM.

Running around disabling the “VMware NAT Service” on all clients that run VMware Workstation is no fun job, so naturally we need to find a way to automate this as well.

Enter Group Policy Preferences!

  1. On a computer that has VMware Workstation installed, run the Group Policy Management Console and create a new GPO.Group Policy Management Console
  2. In Computer Configuration > Preferences > Control Panel Settings select Services
  3. In the menu click on Action > New > Service and and click on  “…” next to the Service Name field
  4. Select the “VMware NAT Service”and click “Select”Services
  5. Set the Startup mode to “disabled”
  6. Assign this new Group Policy Preference to the OU that the clients that have VMware Workstation installed on resides in, and the next time the policies are refreshed, the “VMware NAT Service” should be set to disabled.Note: This might require a reboot of the client.
  7. Profit.

And there it is, a workaround on how to disable the possibility for VMs running in VMware Workstation utilizing NAT mode. A bit of a hack, but it works.

Wishlist

I really wish VMware would include the possibility to configure and manage multiple VMware Workstation for Windows installs, through Group Policy and Group Policy Preferences.

The ability to centrally manage configurations and settings would be a welcome addition to this already excellent piece of software, and I am sure that I am not alone in asking for this possibility. So how about it VMware, yay or nay?