Today I spent several hours troubleshooting the fresh install of WebSphere 7.0 on Windows 2003. The server passed all post-installation steps successfully, but refused to start after the OS reboot. The last line in the server logs was “Server launched. Waiting for initialization status.”, and the actual server state was unclear – any attempt to start it anew claimed that the service was running, but the server console was not available.
It appears that the Windows service installation, which happens by default during setup time, was problematic. Once you remove the service and reboot the system, you can start WebSphere manually without any trouble.
Here is how to remove the Windows service:
- Go to the “bin” folder under WAS installation directory (usually “C:\Program Files\IBM\WebSphere\AppServer\bin”)
- Execute the following command: “WASService –remove <name-of-server-node>”
Typically, the name of server node is composed from the computer name with “Node01” suffix.
For example, the node name on “was70-win.mycompany.com” will probably be “was70-winNode01”.
Hat tip to this IBM DeveloperWorks community post for the hints!
Several hours ago I took the ASA device in my lab to the routine software upgrade. I started with the fresh ASDM image upload, but it failed with the error message “Not enough space on device”. The reason sounds obvious, but it is not so trivial – how can you clean up some space on the physical appliance?
It appears that ASA does not clean up old software packages after their installation via ASDM. After several upgrades the flash memory of the device will be full of unused files, with no room to upload new ones. This is the time for manual cleanup. Continue reading “Cisco ASA: “Not enough space on device” error fixed”
How do you upgrade from UAG 2010 SP1 to UAG 2010 SP2? Well, it appears that such upgrade is not as trivial as expected.
First, Microsoft UAG is based on another Microsoft product – Microsoft TMG, – which has to be upgraded separately. Besides that, there is no direct upgrade package for the UAG itself. Thus, the correct upgrade path would be as follows: UAG SP1 => UAG SP1 Update 1 => TMG SP2 => UAG SP2. Of course, the whole process is documented in TechNet – but you have to be aware about this upgrade path first…
There is another caveat in this upgrade. In case you have some UAG trunks configured (and I assume you have some, since what do you need UAG for otherwise?), you have to active UAG configuration after each step in the upgrade process, otherwise you’ll end up without configured trunks – they will disappear silently during the process. Thanks to TechNet forums for solving this one for me!
Some time ago I managed to isolate an ugly vSphere 5 bug that caused me some unpleasant moments. Today I finally reproduced this behavior in a clean lab environment, so I feel confident enough to describe it in public. Don’t worry, the way to recover is described also!
Take a vSphere 5 environment with a template (say, “MyTemplate”) that you want to deploy a virtual machine from. Step through a regular deployment wizard and select “Edit Virtual Hardware” on the last page. In the VM properties, choose the hard disk and change its size. The new VM (say, “MyVM”) will be created successfully, but the next time you’ll go through the deployment process it will fail with a strange message: “Unable to access file ‘MyTemplate/MyTemplate.vmdk’ since it is locked”…
A quick search in VMware KB (or just in Google) will tell you that the vmdk (the virtual disk of the VM) is usually locked when some other VM uses the same disk. Hey, this is a template! No other VMs are supposed to use the template disk, right? Well, the truth is that this disk is now attached to MyVM – yes, that one with different disk size… But let the lock alone. Your lovely template is now gone, since the disk that belonged to the template is now owned by the running virtual machine – with new name, settings and maybe even software!
Well, how do you recover from this situation? The good news are that the original disk from MyTemplate is not gone. In fact, vSphere really cloned a new vmdk file for MyVM and placed it where it should usually reside – in ‘MyVM/MyVM.vmdk’ – but for some reason set the MyVM to use a template file instead. At this moment you can take a deep breath, shut down MyVM, point it to the right virtual disk and physically swap the files in the datastore… Continue reading “Deployment of New VM from Template Fails with VMDK Locked Error”
The internet is full of complains that Admin Pack for Windows 2003 cannot be installed due to protected Windows files. I guess that this can happen for various reasons, but I have found a solution for at least one of the cases – when the server where the installation of Windows 2003 Admin Pack fails is virtualized.
So, we have two servers – Windows 2003 Server with Active Directory installed as Domain Controller (server #1) and VM with Windows 2003 Server that is a member of this domain (server #2). The need – administer DNS and DHCP settings of AD remotely, but corresponding MMC snap-ins are not available by default on non-DC machines. The correct way is to install ADMINPACK.MSI, available from Windows 2003 installation CD-ROM or from Microsoft Download Center. (Of course, you can always open an RDP session to a DC – but this does not address the real need.)
However, the installation suddenly shows a message “The Windows Installer service cannot update one or more protected windows files” and rolls back everything that was already installed. The Event Viewer reveals error numbers (“Error 1933. … SPF Error: 1223.”) and the list of protected files – but this does not really help. So, what can we do about that?
In fact, the solution is really simple. Running the same installation via the console RDP session (or in the vSphere console) reveals the real cause for the failure – the Admin Pack install needs Windows 2003 installation CD-ROM, but for some reason does not tell that on non-console sessions. After the requested CD is provided (for VMs, this can be done by mounting the CD image in vSphere or via DaemonTools), the installation was able to complete successfully. Continue reading “How to install Admin Pack for Windows 2003 on Virtual Machine”