Ben’s Tech Blog

As a network admin, I’m often handed software and asked to deploy it for a bunch of users. In a lot of cases the software is provided by a supplier or customer and in some cases is used to connect to their server over the internet. I’m amazed at how much of this software is, in my opinion, poorly written. Here are a few things that make me cringe, and often give me a headache.

Local admin rights

Running as a non-admin is obviously a best practice security measure, but a lot of developers make it difficult to put it into practice. When we went through the process of removing local admin rights from users, we ended up with a fairly long list of software that wouldn’t work without admin rights. To get around this, we used the Sysinternals Regmon and Filemon utilities to find out which registry and file system objects were giving us “access denied” errors. After identifying these, we were able to modify the object’s permissions to give the local users group the required access.

I come across a lot of software that doesn’t work without elevated user privileges, and I often have to go the same process as above to get them to work under an ordinary user account.

No Proxy support

We are running several pieces of software that cannot be natively proxied. By that I mean that they need to connect to servers using ports that are not sent to a proxy server, even if one is specified in IE. Sometimes we are able to get around this by installing the Microsoft Firewall Client (an ISA feature), but at the moment I am testing software for users who are required to use a Squid proxy, and I’m not aware of any equivalent solution.

There have been cases where using the firewall client doesn’t work either, so opening the required ports on the internet firewall is the only option. This is a relatively simple solution if you have a local internet connection, however a lot of companies (like ours) only have internet connections in regional centers which makes it more difficult. In situations where the software is installed in a remote site, we’ve managed to implement a work-around by creating a translation on the local router (for the network that the user belongs to) to convert the public IP address (that the software attempts to connect to), to a private IP address (that belongs in the subnet that the internet firewall resides in). Once that translation is in place, another translation is required on the internet firewall to translate from the private IP address to the original public IP address. Although it’s possible to do this, it’s not ideal, and in our case, involves a third-party (the WAN provider).

Java

It may be a nice development platform, but running multiple java applications can be difficult, particularly when they use different versions of Java. I’m currently testing a desktop environment with 5 different Java applications; only 2 of these applications use the same java version, so there are 4 different versions of Java installed. Java doesn’t seem to be completely backwards compatible, so if an application is developed for Java version 4, it may not work if only Java version 5 is installed on the workstation. In order to get the application to work, you need to install Java version 4. The problem is, to install Java version 4, you first need to uninstall version 5, then install version 4, and then of course install version 5 again so that your other Java app will work. I spent a fair bit of time trying to get all of the Java apps working in harmony. The golden rule it seems is to install the oldest version of java that you require first, followed by the next oldest version and so on. In any case, its a head-ache, so I never like receiving software written for Java.

I’m sure if I thought harder I would be able to list more things that annoy me but these are the three things that have caused me headaches in the last few days.