As I’ve mentioned in previous posts, we use Softgrid (or Microsoft Application Virtualization as it’s called these days) at the university. Every now and then, I run into problems sequencing an application. My latest encounter with a troublesome application was SPSS Statistics 17.
The problem I encountered was that the installer would hang at the very end of the installation process. In some cases, the box would even blue screen at this stage. I scratched my head on this problem for some time, but today, I finally figured out how to solve it.
I had a look at the Windows Task Manager when the installation had hung and discovered that there were a couple of processes called spsslinit.exe that appeared to be doing nothing. So I fired up the installer once more with MSI logging enabled and when it had hung, I looked at the end of the log. There, I found mention of a script function called PostInstallCommands. From the log, I could tell that the script function started up 7 spsslinit.exe processes (with various different parameters). I don’t know for sure what the spsslinit.exe processes do, but I believe they are somehow related to SPSS licensing when running in standalone mode. We use a network license, so we don’t need the standalone stuff.
The next step was to somehow prevent the SPSS installer from running the PostInstallCommands script. So I fired up Orca (Microsoft’s MSI editor) and looked in the InstallExecuteSequence table sorted by sequence number. Sure enough, at the end of the sequence, there was PostInstallCommands. I then created a new transform and dropped the PostInstallCommands row together with another row called SPSSlinit. I’m not sure the latter is needed, but I thought it can’t hurt.
With my brand new MST file, I started the sequencer and fired up the installer with the following command line:
msiexec /i “SPSS Statistics 17.0.msi” TRANSFORMS=1033.mst;SPSS17_Softgrid_Fix.mst
It worked beautifully! After the install, I upgraded to 17.0.1 and even that went without a hitch. I’ve done some testing and the app is running just fine with our network license. If you’re trying to do this with a standalone or site license, I’m not sure this is the way to go, but then again, I don’t think SPSS can be sequenced using anything other than a network license.
I’ve uploaded the MST file if anyone needs it.
If you’ve ever tried to manually specify a MAC address for a VMware ESX virtual machine, you might have encountered the error message:
The MAC address entered is not in the valid range. Valid values are between 00:50:56:00:00:00 and 00:50:56:3f:ff:ff.
The reasons why VMware force manual MAC addresses into this scope are unclear to me (probably to prevent collisions), but regardless, it can be an issue. I needed to specify a particular MAC address in the 00:04 range. The reason being we were retiring an old physical server running the FLEXlm licensing service and the licenses were granted for the MAC address of the NIC on that machine. Renewing the licenses for the new virtual machine turned out to be ridiculously expensive so our only real option was to “spoof” the MAC address.
I then ran into the aforementioned issue. However, the problem was easily solved by setting the MAC address from within the guest operating system instead. In this case, the server was running Windows Server 2003 and changing the MAC address was as simple as modifying the parameter “networkaddress” in the properties for the NIC in device manager. Voila!
Having used iPhoto 09 for a couple of weeks/months now, my verdict is that it sucks. Unless all you have is high resolution, high contrast photos of people taken perfectly perpendicularly to their face, it just doesn’t work. The same applies for people who sometimes were glasses (me for example). If I import a batch of pictures containing only people that I have already added to the database, I would say it gets it right maybe 25% of the time. And that’s provided that it detected all the faces, which it does maybe 80% of the time.
Last week at work, we had a network engineer look into some issued we’d been having with one of the switches in the server room. The switch in question was the main LAN switch to which all our servers are connected. Turns out, the switch needed to be rebooted to solve the problem. We didn’t think anything of it apart from the fact that the servers would be off the net for a few minutes.
The morning after we discovered, as we logged in to a few of the servers, that all virtual machines had shut down unexpectedly the night before. My first instinct was that the network engineer must have disconnected the power to the VMware servers for some odd reason and that this was the cause for the disturbance. But after some digging around, we found that none of the ESX servers had rebooted. So why had all the virtual machines shut down?
Turns out, there’s a feature in ESX called isolation mode. When you’ve setup your ESX cluster for HA (High Availability) and an ESX server loses contact with the other ESX servers and with its gateway, the server considers itself to be isolated and the default action when isolated is to shut down all virtual machines! In other words, if you have to disconnect your ESX servers from the network, look into isolation mode first.
I’m still not sure why the default is to shut down the machines. I mean, won’t forcibly shutting down a virtual machine potentially cause more problems than letting it run without a network connection?