1) if you have IIS running, disable it!
Because VirtualCenter is going to ask you to use standard web ports 80/443, you'll need to disable IIS or direct either IIS or the VirtualCenter MS install to use ports other than 80 and 443.
As a side note, IIS on XP has a port 443 configured; however, you cannot delete this port from being used. I do not know what this port is used for, because it is not bound to anything I can see in the IIS MMC. I suspect it is due to some limitation with IIS on XP, the latest crippled software available on a "Professional" level OS from Microsoft, reminiscent of the sad NT 4.0 Personal Web Server. I also tried to delete the port using MetaEdit, the IIS MetaBase editor, but that just broke the website entirely, forcing me to do a reinstall of IIS. MetaEdit is a very nice little utility and is available here for free from Microsoft:
http://support.microsoft.com/kb/q232068/
If you are ever in doubt about what ports a particular process is using, another Mark Russinovich gem is TCPView:
http://www.microsoft.com/technet/sysinternals/Networking/TcpView.mspx
Here's what TCPView looks like:
My my! Look at all those VMware related processes running on my XP machine!
2) Disable Internet Connection Firewall (ICF)/ Internet Connection Sharing (ICS) Services
So, the second thing you'll need to do if you want the VC installer to run properly is to disable this combined service. According to the description in the Services administrative widget, "Internet Connection Firewall (ICF)/ Internet Connection Sharing (ICS) Services "provides network address translation, addressing, name resolution and/or intrusion prevention services for a home or small office network." That's quite a laundry list of activities for one service, no? Well, during the installation of VirtualCenter, the installation bombed out with the following cryptic message dialog box:
Error 25002. Setup failed to configure the Windows firewall
Following a couple of those dialog boxes appearing, the final error message you will see is:
The VMware License Server installer returned error code 1603.
The errors also had a note about referencing the installation log here:
c:\documents and settings\
Digging through this file, I found the last telltale lines:
vmls: 05/16/07 16:15:48 Found "C:\WINDOWS\System32\netsh.exe"
vmls: 05/16/07 16:15:48 Attempting to launch "C:\WINDOWS\System32\netsh.exe firewall set allowedprogram program="C:\Program Files\VMware\VMware License Server\lmgrd.exe" name="VMware License Server Manager" scope=ALL mode=ENABLE"
vmls: 05/16/07 16:15:50 Process returned 1
vmls: 05/16/07 16:15:50 ERROR: Failed to configure Windows firewall for lmgrd.exe.
vmls: 05/16/07 16:15:50 Posting error message 25002
Well now, what the heck is netsh.exe? Here's a clue:
http://support.microsoft.com/kb/242468
In short though, here's a laundry list of things this little utility can do for us:
• Configure interfaces.
• Configure routing protocols.
• Configure filters.
• Configure routes.
• Configure remote access behavior for Windows-based remote access routers that are running the Routing and Remote Access Server (RRAS) Service.
• Display the configuration of a currently running router on any computer.
• Use the scripting feature to run a collection of commands in batch mode against a specified router
Gadzooks! It's another all-in-one utility from Microsoft! They keep coming, don't they? Back to the errors in the VC install log file. Well, I misread the log file message that stated "Failed to configure Windows firewall for lmgrd.exe" thinking that it meant that netsh.exe was the Windows firewall. In point of fact, the Windows firewall was the previously mentioned ICF/ICS Service. But I realized this only after I tried to rename the executable.
My logic was that if the installer didn't find netsh.exe, it would just proceed on its merry way and get me further along to my goal, a successful install. So I renamed netsh.exe to netsh.bak. Well, lo and behold when I renamed netsh.exe to netsh.bak, a new netsh.exe took its place not four seconds later! Microsoft operating systems are acting more like viruses every day! I was then intrigued as to what program was recreating netsh.exe, so I started sifting through the Administrative -> Services widget for a likely culprit.
Looking through the list of services, I quickly stumbled upon ICF/ICS, as it was one of the first in the alphabetically ordered list of services. This made me recall the log entry and I finally put two-and-two together to realize that it was ICF / ICS that was the Windows firewall, not netsh.exe. So, finding that combined service gave me great pleasure and I quickly stopped the service, disabled it and was able to successfully finish the VC install.
Post Mortem
In point of fact, I never did find the service responsible for restarting netsh.exe. Hmmm..maybe a future post.
Blundering his way deductively through the world of computing, the TechAnswerGuy.
No comments:
Post a Comment