Monthly Archives: March 2016

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.

rdp-error-occurred

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.

secpol-lan-mgr

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.

lan-mgr-auth-level-default

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 \=.

https://gist.github.com/gravcat/526053cafa7e95e450ca

The above example would set file.zip with the following properties:

‘foo’ = ‘bar’

‘a spaced key’ = ‘somevalue’

‘version’ = ‘1.2.3.4’

‘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.

https://gist.github.com/gravcat/6a48ee8230123e50fc9b