Tag: Windows

There were times when we were looking for simple yet unorthodox solutions; and this case was one of them. Imagine, if there was a Windows 2012 server with its standard VPN service (RAS, or, Remote Access, actually), configured and operational. The only problem was that static IP of the server (as seen by a connected user) was not up at all times. For instance, assume DHCP IP range for VPN clients was 172.0.2.1 – 172.0.2.199. That makes first address of the range, 172.0.2.1 the server’s address that is accessible by VPN clients (inside VPN tunnel). When server just started that IP would be down – not even pingable, let alone not routable. The IP address becomes live as soon as first VPN client is connected from outside to the RAS service. That presented a challenge for application jobs configured to run in both modes: locally on the server and from remote locations connected to the server. We would configure 172.0.2.1 as a universal connection point for all the applications and grant proper server firewall exclusions, though… they would not be able to connect if no external users connected to the VPN service yet.

It is typical for a Windows server to have a auto-generated self-signed certificate for its Remote Desktop service. Not a good practice. Especially when RDP service is exposed on the internet (via TCP port 3389 that would be open in firewall). Here are a few simple steps to install a valid SSL certificate to be used with RDP to protect the host identity and encrypt your remote desktop sessions properly.

The issue happens because PuTTY user key stored in Windows registry under saved sessions with that server host name takes precedence over the key configured in Tortoise.

We were not able to alter MAC address of main network adapter inside a Windows 2012 R2 instance. No matter how we tried with registry hacks and even 3rd party software tools, the outcome was unsuccessful. Though for certain applications dependent on a particular MAC value it does not have to be on a primary network card. We realized we just needed another network card! That could be achieved by installing a dummy loopback network driver that would serve as an additional network interface. It can be assigned with a bogus IP while its physical (or MAC) address we may alter freely. Luckily, Microsoft offers such driver among most of its Windows distributions that is called KM-TEST Loopback Adapter.

The main benefit of Windows XP mode on Windows 7 (virtual Windows XP instance under Hyper-V) would be to run legacy DOS applications or other older software that may not be compatible with newer versions of Windows. Also, some of those beasts would not know any better than to print directly to a hardware parallel printer port or LPT. For example, one of that legacy software is FoxPro. The LPT requirement presents a clear challenge since Microsoft did not provide an interface or driver for virtual Windows XP instance to access the host’s printer ports.

Today our challenge was to create a simple setup that is often called inbound TCP port forwarding, or, a pinhole with a more (or less) advanced firewall device. The network appliance for this cosmetic surgery was one of the recent PAN (Palo Alto Networks) PA-3000 series running PAN OS 6.0. First of all, do not do it. Again, do not do it. And again: please, do not create a destination port forwarding from external network interface into an internal or trusted network behind the firewall. There are other (proper!) techniques that would be better to use for remote network access, dedicated line or VPN (stands for Virtual Private Networking), for instance. Modern VPNs have little overhead and lots of security benefits. Though, for testing purposes only, we have decided to ignore our own advice which was just mentioned above for 3 times.

Say, you have a stand-alone Windows 2008 R2 server that is not part of a domain. You decide that it would make more sense to adjust the server name in the system properties (Computer name – Change) from WinServ1 to a more meaningful WinDevelServ1. After mandatory server reboot you discover that (surprise!) Remote Desktop licensing is not active anymore. A brief error message on dashboard icon makes it clear that you have 120 days to activate the license or else users will lose their ability to connect via Remote Desktop.

What went wrong is one of the gotchas of Windows networking. Server name needs adjustments in various places of the system during name change and the Remote Desktop license server setting is apparently one that they forgot to take care of.

What if you had an existing SSL certificate for your static website, say running Apache2 web server. What if you needed to re-use same certificate for a new dynamic Java-based website running Tomcat instance that you were just adding. That would include following steps: