Automate Resetting the ESXi 6.0 Test-Lab License

If for whatever reason you are running an evaluation copy of ESXi, and you need additional time you can easy re-instate the evaluation period. I had this problem when I installed a copy, didn’t get around to actually evaluating the features I wanted to, and then was forced with the pain of re-imaging bare metal. Yuck!

Note: Run all italicized text as root in the shell.

  1. Enable the SSH server
  2. SSH in with your client, regardless of platform.
    1. If you are not using any type of advanced configuration, your user will be ‘root’ and your password is whatever you defined at installation time.
  3. Make your crontab writable with chmod.
    1. chmod 1644 /var/spool/cron/crontabs/root
  4. Enter a text editor of choice to write your timed cronjob.
    1. vi /var/spool/cron/crontabs/root
  5. Add the following line
    1. 0 12 * * * rm -r /etc/vmware/license.cfg && cp /etc/vmware/.#license.cfg /etc/vmware/license.cfg && /etc/init.d/vpxa restart

Now your license is being re-instated on the 12th hour of every day, and the service that handles it is restarted to take effect. All without a reboot – just remember to disable your SSH server once more afterwards.


RDP: “… because an error occurred on the remote computer”

A problem that’s been bothering me recently: randomly and out of the blue, my workstation at home was having an issue opening a Remote Desktop Protocol (RDP) session out to another network, which has a Remote Desktop Gateway (RDG) server sitting in front.


After ruling out DNS resolution for the RDG server, my WAN connection’s ability to reach it (laptop works fine), and no other users reporting the issue I had to assume that Windows somehow broke itself throughout normal use.

I attempted to clean out the temporary files from my client computer, as well as any cache that RDP may have to no avail. I didn’t really want to consider reformatting just to fix this one RDP problem, and after some toying it seems the following has worked for me.

Within the “Local Security Policy” of your workstation exists settings to dictate what types of minimum encryption encryption are allowed for certain protocols, among a ton of other unrelated items. The option we’re interested exists in Security Settings > Local Policies > Security Options. The policy itself is labeled Network security: LAN Manager authentication level.


By default, the authentication level is configured for “Send LM & NTLM – use NTLMv2 session security if negotiated” or in other words, allow for lower security to provide a broader range of compatibility, but use the good stuff if the server you’re connecting to wishes to.


By changing the above dropdown to “Send NTLMv2 response only, I was able to connect with no qualms whatsoever. Presumably, this means perhaps the RDG server is misconfigured, or this is just some obscure bug no one ever would want to look at. NTLMv2 should already be negotiated, but in this instance perhaps our client is not or is unable to recognize the NTLMv2 negotiation, therefore halting due to a failure in the handshake.

Hope this helps!


Artifactory API example: Setting properties on an existing artifact

Here’s another somewhat more elusive Artifactory API example. Setting the properties on an existing artifact was somewhat troublesome at first. Quick testing shows that the only thing to be concerned of is URL encoding for spaces and many characters. You’ll need to be sure your user has annotate permissions to the target in order to not receive a HTTP 401/403 error. Oh, and if you need to include equal symbols within the keys or values themselves, escape them with a backslash \=.

The above example would set with the following properties:

‘foo’ = ‘bar’

‘a spaced key’ = ‘somevalue’

‘version’ = ‘’

‘someweird=value’ = ‘foo=bar’


Artifactory API example: Deploying a single artifact/item.

The internet is lacking of simple Artifactory API usage examples. Here’s a handy one for deploying a single artifact or item. Be sure to modify all the values to be appropriate for your environment. This syntax also works out-of-box for a windows instance, where curl = c:\some\path\curl.exe.