Cloned Virtual Machine, Java services will not start

Question

In our software environment we have a number of VMs running Windows Server 2008 R2. On these servers we have Java 1.6 and use YAJSW for a couple of services. As part of our upgrade procedure we want to create clones on the virtual environments and test our upgrades before deploying to production.

Now for the issue.... The windows services will not start on the cloned VMs.

An example of a command that is run when a service is started is:

F:\app\configservice>"D:/Java/jdk1.6.0_27/bin/java.exe" "-classpath" "D:\yajsw-10.8\wrapper.jar" "-Xrs" "-Dwrapper.service=true" "-Dwrapper.working.dir=f:\app\configservice" "-Dwrapper.java.command=D:/Java/jdk1.6.0_27/bin/configservice.exe" "-Dwrapper.config=F:\app\configservice\lib\wrapper.conf" "-Dwrapper.additional.1x=-Xrs" "org.rzo.yajsw.boot.WrapperServiceBooter"

When run manually from the command line it produces this output.

INFO|wrapper|Service ConfigService|13-02-11 14:37:49|init
INFO|wrapper|Service ConfigService|13-02-11 14:37:49|Win service: before service init
INFO|wrapper|Service ConfigService|13-02-11 14:37:49|set state IDLE->STARTING
INFO|wrapper|Service ConfigService|13-02-11 14:37:49|starting Process
INFO|wrapper|Service ConfigService|13-02-11 14:37:49|error in >StartServiceCtrlDispatcher
INFO|wrapper|Service ConfigService|13-02-11 14:37:49|1063:The service process could not connect to the service controller.
INFO|wrapper|Service ConfigService|13-02-11 14:37:49|Win service: terminated correctly

Googling the error has led me to believe there may be something wrong with the JVM, but that really does not make sense as it is a clone of a VM where the JVM is perfectly happy. Some colleagues have suggested the group rights policies, but it seems to be the same on both machines.

Answer 1

Using psexec I created a Local System level command prompt and starting checking the environment variables. I found that the local user's temp directory mapped to a non existing drive. Further digging revealed that Y: was mapped as E: on the cloned VM. Not sure how that happened, but the issue is resolved

Answer 2

If you run cloned VM in the same network as original one, make sure it has different MAC and IP.