Archive

Archive for October, 2010

Issues uninstalling Java Runtime software

In small to mid-size environments I prefer to distribute all software using Active Directory and Group Policies. As soon as the computer is started, the software distribution policies will be applied and all assigned applications will be installed automatically.

When upgrading a software package to a more recent version I always select the option to remove the old version first and then install the updated version, instead of performing an in-place upgrade.

I have been using this method for quite some time and I haven’t had any problems, until now…

One of the software packages I generally install on all computers is the Sun (now Oracle) Java Runtime Environment. Previously I didn’t experience any problems while uninstalling this software, but lately the uninstall process takes forever (well, not literally) to complete.

During the software installation phase, the computer is “hanging” while uninstalling the current JRE. If you’re patient enough, the computer will eventually (after an hour or so) display the logon screen. When you log on to the computer you will not be presented with your familiar Windows desktop, but the computer seems to continue the uninstall process in the background.

Then finally, after a quite some time (again an hour or so), the user’s desktop will appear and suddenly it also becomes obvious why the uninstall process for the JRE took so damn long.

Problems uninstalling the Java Runtime Environment

In my experience there are two separate problems that can occur during the removal of the JRE software:

  • The uninstall process cannot continue because one of the files is in use.
  • The uninstall process cannot check the validity of the certificate used to sign a source file.

Fortunately there is a solution to both problems.

Problem #1: file is in use

When we finally manage to get the Windows desktop to show, it will display a dialog box which will indicate the file in use is jqs.exe. This file belongs to the Java Quick Starter service. During the boot sequence this service will be started before the uninstall process takes place. This results in the file being in use when uninstalling the Java JRE.

Simply disabling this service will allow the uninstall process to continue without any problems. This will slightly slow down starting Java applications, but this won’t be a big deal. On Windows Vista or above this service doesn’t have any benefits at all anyway (for more information check http://www.java.com/en/download/help/quickstarter.xml).

I have chosen to disable this service using a group policy that is applied to all computers:

GPO Java Quick Starter

Using the GPO editor, select Computer Configuration | Windows Settings | Security Settings | System Services and set the startup mode for the JavaQuickStarterService to disabled:

Disable jqs

Problem #2: error checking certificate

The second issue involves an error while checking the validity of a certain certificate used to sign one of the source files of the Java JRE. There are possibly multiple reasons for this problem to occur, but in our case it was proxy authentication. The uninstall process runs in the context of the local system account (NTAUTHORITY\SYSTEM) and this “user” cannot be authenticated by the proxy server.

The solution for this problem involves installing the certificate as “Trusted Publisher”. Once the Windows desktop has appeared a dialog box will popup after a few seconds. This dialog box will allow you to view the certificate and it will reveal it is intended for sjremetrics.java.com. Select the Details tab and click Copy To File. This will let you save the certificate as a .CER file.

When the certificate has been saved, open the GPO editor and navigate to Computer Configuration | Windows Settings | Security Settings | Software Restriction Policies | Additional Rules. Right click the right pane and select New Certificate Rule. Use the Browse button to select the saved certificate and set the security level to Unrestricted.

Certificate Rule

After the policy has been applied the certificate will be listed as “Trusted Publisher”.

Certificate

Advertisements

Using a UPS with Hyper-V R2

Did you ever try to get a UPS up and running on a server using Microsoft Hyper-V? Well, I did. And it proofed to be a more difficult task than I had initially imagined…

There is quite some information about Hyper-V and UPS’s  that can be found on the internet, but most of this information is about connecting the UPS using a USB connection. In this scenario the server will act as a very big (and very heavy) laptop with the UPS being the battery. On a Windows 2008 server it would be possible to use the regular power options to shut down or hibernate the server when the battery (i.e. UPS) runs low.

Too bad this doesn’t apply to a Hyper-V R2 server (core) installation. On this platform it is possible to use all kinds of scripts that monitor the battery status using WMI (querying the WIN32_Battery class) and then shutting down the server when the battery is running low.

But in both cases only the server connected to the UPS will be shut down. What if there are multiple servers connected to the same UPS? This situation is quite common.

Of course one could write another script that shuts down several other servers before shutting down the Hyper-V server, but this would not be a very flexible solution.

Unfortunately, we did have another problem. Our UPS’s were not connected through USB, but through a serial cable. So all of the above doesn’t apply.

Before we migrated our physical servers to a Hyper-V based platform, we were using LanSafe to monitor our UPS’s. Despite a lot of people are always complaining that the UPS software itself is lousy, we quite liked the LanSafe software. This software did allow us to set up a LanSafe controller (server that was connected to and monitoring the UPS), several LanSafe members (servers that are shut down by the controller when the power fails) and and a LanSafe console (on a workstation) that allows the remote configuration of the LanSafe controllers. Wouldn’t it be neat to be able to use the LanSafe software again?

Downloading LanSafe

In order to download the LanSafe software, go to the Eaton website. Before you will be able to download the software, you will have to register first.

Eaton Website

After registering, you should be able to download the LanSafe software. Be sure to download all required versions. Since we want to install on a Hyper-V server, you have to download the 64-bit version. But if we also need to install the software for a member that is running on a 32-bit version of Windows, you will also need the 32-bit version.

Installing LanSafe

After downloading LanSafe we can install it on the Hyper-V server. But before we will start the installation, we will have to connect the UPS first. If the UPS is being detected as “New Hardware”, we can just ignore this by selecting “Don’t ask me again”. We can now run the installation program that we downloaded previously and go through the installation wizard:

  • Accept the license agreement.
  • Select “LanSafe Controller” to install the UPS monitoring component on the Hyper-V server.
  • Select “Serial Connection (COM port)” and have the software automatically detect the attached UPS.
  • Accept the detected serial port.
  • If required, select the correct UPS. LanSafe supports several different UPS models and different vendors. Usually the UPS will be detected correctly.
  • Enter the password for the LanSafe controller. This password is required when connecting remotely rom a different LanSafe member or console.
  • Accept the default Power Failure Settings (these settings can be configured later).
  • Enter a unique name for the controller.
  • Skip the configuration of the SMTP settings (this can be done at a later stage).>
  • Continue the installation wizard (installation folder and program group can be changed, if desired).

When the installation has finished unselect the option to start LanSafe !!! Before we can use LanSafe we still have some work to do.

Enabling the LanSafe GUI

The LanSafe GUI requires the presence of msvfw32.dll, but this DLL file is not present on a system running Hyper-V. You should be able to obtain a copy of this file from  the %WINDIR%\System32 folder on a computer running Windows Vista or Windows 7.

Now copy the DLL file into the %WINDIR%\SysWOW64 folder on the Hyper-V server. That’s it…

You should now be able to start LanSafe.exe which is located in the Bin subfolder of the installation location (usually C:\Program Files (x86)\Powerware\LanSafe\Bin).

LanSafe GUI

Configuring the firewall

As I mentioned before, it is quite common for a single UPS to supply power to multiple servers. In case of a power failure the controller should shut down the other servers first, before is will shut down itself. Therefor it must be possible for the controller and the member servers to communicate with each other. The problem is that the firewall blocks the ports that LanSafe requires for its communication. We need to enable these ports first.

The ports that LanSafe uses are UDP ports 3068, 3069 and 7015. To enable communication through port 3068, type the following commands in the command windows at the Hyper-V server:

netsh advfirewall firewall add rule name="LanSafe (UDP 3068)" protocol=udp localport=3068 dir=in action=allow

netsh advfirewall firewall set rule name="LanSafe (UDP 3068)" new enable=yes

Repeat the commands above for port 3069 and port 7015. When done, communication between the LanSafe controller and the LanSafe members / consoles will be possible.

Shutting down physical servers during power failure

When we would like the LanSafe controller to shut down other servers attached to the same UPS as the controller, we will need to install the LanSafe software on these servers as well. Depending on the type of Operating System on the server, we will either need to download the 32-bit or 64-bit version of the LanSafe software.

Run the appropriate installation package and go through the installation wizard:

  • Accept the license agreement.
  • Select to install a “LanSafe Member”.
  • Enter the name of the controller that should be managing this member.
  • Skip the configuration of the management settings. These settings can be configured later.
  • Select a destination folder and a program group.
  • When the installation is completed, LanSafe can be started.

After starting LanSafe it is required to enter the password of the controller. This is necessary to prevent unauthorized members to connect to the controller.

The shutdown timings for each member as well as the controller itself, can be configured through the Management Settings using the LanSafe GUI.

Shutting down the virtual servers on the Hyper-V server

Using virtual servers makes it very easy to shutdown a server, or even suspend a server. In fact, the latter is the default setting in Hyper-V. As soon as the physical Hyper-V server is shut down, all virtual server running on the Hyper-V server will be suspended.

Hyper-V VM Shutdown

If desired, it is also possible to automatically shut down all virtual servers. In that case one would have to select the bottom option in the Hyper-V management console.

UPS’s connected via USB or LAN

Although the information above is about using a serially attached UPS with Hyper-V, the LanSafe software also supports UPS’s connected via USB and UPS’s connected via the LAN using a network card inside the UPS. I have not been able to test these configurations myself. I know that the LanSafe software also contains drivers for USB connected UPS’s (you’ll have to extract these drivers from the installation program first). You will probably need to install these drivers on your Hyper-V server first, before attaching your UPS.

If you can confirm this from your own personal experience, then please leave me a comment.

Categories: Hyper-V, Virtualization Tags: ,