My Windows installation pains = your gains

[cinergi]

I needed a punching bag a number of times on my second Cacti/Windows installation. I'm not using BSOD2600's installer, but after reading what it does, the installation notes, and the FAQ, I think I have a few more FAQ's to get added based upon the disaster I went through to get it working properly. At the very least, people searching for solutions to the problems I ran into will have an answer here.

I had no real problems getting the base Cacti installation going on an existing Windows 2003 SP1 x64 box (IIS in x86 mode, MySQL x64; everythign else x86). I had a lot of trials getting a good SNMP Informant Data Query and associated templates working properly, but that's mostly unrelated. See #2 below.

My second installation was for our QA lab (before I go turning this on in production everywhere). This should have been really easy considering I'd just done it a few days ago in our pre-prod environment. This was a Windows 2003 x86 SP2 VM. I'm leaning towards SP2 causing at least one of my pains.

Both Windows 2003 installations are not default installs; they're a hardened environment -- also likely a cause for some of my pain. I've yet to install this on a vanilla Windows 2003 and I'm not privy to all the changes in the hardened image.

Problem #1) Adding a device caused PHP timeout (30 seconds = script ran too long = automatically killed). The device was added, but it always timed out when performing the add; the web interface was generally slow as well. In short, this is due to the following PHP MySQL bug: http://bugs.php.net/bug.php?id=41350 -- This bug is still unresolved but the workaround of installing an older (from PHP 5.2.1) copy of libmysql.dll (NOT php_mysql.dll) worked for me. I have no idea why I'm hitting this in my QA environment and not in the pre-prod environment. Otherwise "php -m" reliably produces the error and causes a huge delay in exiting the script.

Problem #2) PHP SNMP is not working with my SNMP Informant data query (I get "no data returned" problems when doing a Verbose Query). It's almost as if it's not reading my MIBS, but Procmon (Filemon) shows that they get read in and I have no permissions problems. Right now, the built-in PHP snmp extension is disabled (IIS (or at least the WP) must be restarted after making this change).

Problem #3) While the user running the poller (username = 'cacti') was able to run "php d:\cacti\poller.php" without a problem, it did not work from Scheduled Tasks. It appeared to hang (constantly killed after running 298 seconds). LONG story short, I had to add 'cacti' to the read/execute permission on c:\windows\system32\cmd.exe. NOTE: I did NOT have to do this on my pre-prod environment. Various groups have read/execute permission to cmd.exe which appear to be enough for Windows 2003 SP1 and Scheduled Tasks but NOT enough for SP2. I haven't proved that yet, however. NOTE #2: My image's cmd.exe permissions may be more hardened than a default install.

Problem #4) After I got 'localhost' properly graphing, I added a remote host. I went to bed, came back, and found the server in all sorts of pain. It thought both hosts were down, all sorts of errors in the log file, etc etc. I found an enormous number of php/cmd/rrdtool/snmp* commands running (consuming 0 cpu) on the server. They were all hung. Another LONG story short, it looked like the data pipe between snmp* and rrdtool was hung up -- something wasn't happy with the data it received, probably issued a prompt, and just sat there waiting for a response it would never receive. The solution was to alter my MIBDIRS environment variable to include TWO directories (as I was getting some MIB errors which was probably tripping up the data pipe). This may be a result of disabling built-in PHP SNMP support (and possibly why it's not happening on my pre-prod system). My MIBDIRS variable is now: D:\php\extras\mibs;d:\net-snmp\share\snmp\mibs.
EDIT: I see that adding both dirs to the MIBDIRS EV is in BSOD's doc (amazing you can miss details like that even after reviewing it a handful of times); I also see the hangups mentioned here: http://forums.cacti.net/viewtopic.php?t=24401

EDIT -- Forgot about #5:
Problem #5) Since I'm using the external net-snmp binaries instead of php-snmp, I found that, in order for SNMP-Informant data queries to work on remote servers, I had to remove the "-Cr50" commandline option to the snmpbulkwalk command in cacti\lib\snmp.php. See http://forums.cacti.net/post-68363.html for another example of this.

Some other notes:
* I see that net-snmp and PHP snmp are doing some silly things like writing to D:\USR\SNMP\PERSIST\snmpapp.conf and C:\USR\SNMP\PERSIST\snmpapp.conf. I haven't figured out how to correct this yet. This happens on both of my servers.

* For the QA environment, I used the PHP zip file instead of the installer (don't ask). This may be a source of some of the problems/differences.

I think that covers it all, but I've burned so many hours figuring this out over the past couple days that I've probably forgotten something. If I remember anything else, I'll post it. I'm going to make a third install on a fresh x64 VM and take notes.

[cinergi]

First off, note the two edits in the original post.

I've gone ahead and installed again on a fresh Windows 2003 x64 (SP1) VM image (already hardened). Problems 1 and 3 went away (don't know why). I didn't try to see if #4 would come back -- however my MIBDIRS now looks like this: D:\Program Files (x86)\Net-SNMP\share\snmp\mibs;D:\Program Files (x86)\SNMP Informant\standard\mibs\SMIv2

[cyr0n_k0r]

Problem #1) Adding a device caused PHP timeout (30 seconds = script ran too long = automatically killed). The device was added, but it always timed out when performing the add; the web interface was generally slow as well. In short, this is due to the following PHP MySQL bug: http://bugs.php.net/bug.php?id=41350 -- This bug is still unresolved but the workaround of installing an older (from PHP 5.2.1) copy of libmysql.dll (NOT php_mysql.dll) worked for me. I have no idea why I'm hitting this in my QA environment and not in the pre-prod environment. Otherwise "php -m" reliably produces the error and causes a huge delay in exiting the script.

I'm having this exact same problem. However, the install was preformed on a relatively unmodified server 2003 enterprise SP2 system.

Any suggestions to fix it?