Cacti not producing graphs or creating rrd

yesterday i was installing cacti on my debian 4.0 box, which i normally use for monitoring my network, after the installation and configurations, i realised that cacti was not plotting the graphs for the devices I had added, even status was showing Unknown on all devices.

I checked both snmp and rrdtool, but both were running smoothly, this was a bit strange as even the /usr/share/cacti/site/rra folder was blank, cat /var/log/apache2/error.log resulted in:

localhost_server_traffic_in_18.rrd': No such file or directory ERROR: opening '/usr/share/cacti/site/rra
etc etc.
running the php poller file manually from the shell came back with: Fatal error: Call to undefined function: mysql_pconnect() in /usr/share/php/adodb/drivers/adodb-mysql.inc.php on line 377.

This was really interesting as i am having phpmyadmin running smmothly without problems, so why does my php seem to break in cacti, on the cacti forum somebody pointed that cacti package depends on php5-cli, i checked and realised i was having php4-cli on my box, apt-get install php5-cli sorted out this, and i have my graphs in Cacti

Error message when you try to log on to a Windows Server 2000 - based terminal server

Last week, I installed and run spybot on a Windows 2000 terminal server, and also some windows updates (NB; For some reason or another, but not known to me, this server has never had any windows and antivirus updates for some time, and it was showing signs of infections), after a restart over the weekend due to the updates, Users this morning started reporting failure to log on to the terminal server with this error:

"Windows cannot log you because the profile cannot be loaded. Please contact your network Administrator (in this case me), insuficiet system resources exists to complete the requested service"

Now, I half expected this or atleast some problems to surface after the maintenance work I did on the server.

However, it did take me a good 30 minutes to sort this one out, microsoft knowledge base, suggested two things, first increasing the maximum registry value (Control Panel -> system -> advanced -> perfomance options -> Change

Secondly tweaking the registry.

1. click start -> run -> type regedit and hit Enter.
2. Locate and click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
3. On the Edit menu, point to New and then click DWORD value
4. In the New Value #1 box, type PoolUsageMaximum, and then pres ENTER.
5. Right-click PoolUsageMaximum, and then click Modify
   
6. In the value data box, type 60, click Decimal, and then click ok
7. if the PagedPoolSize registry entry exists, go to step 8. If the PagePoolSize registry entry does not exist, create it. ( Edit Menu -> New -> DWORD Value -> type PagedPoolSize in the New Value #1 box, and press Enter.)
8. Right-click PagedPoolSize, and thn click OK
9. Exit Registry Editor, and then restart the computer.

Everybody, is working fine now and the phones have gone queit

Trouble Shooting WSUS problems - Clients not populating in WSUS Admin Console

I have had to install WSUS twice on my server due to conflicts with SEPM, the first install WSUS was configured to use Port 80, and I used the Default Domain Policy to direct Client Computers to it.

when i was reinstalling the WSUS to use port 8530, i created a policy called WSUS on the DC, that would control clients automatic Update configuration. unforunately only 4 out of over 120 PC's only reported to the WSUS.

Doing Start ->Run, then rsop.msc on one of the failing machines showed Group Policy was not being applied correctly, i realised that the Default domain Policy was still having the old settings of my first WSUS configuration i.e. the intranet update server was showing http://servename instead of http://servername:8530.

Cleaning out the Default Domain Policy of all windows Updates setting and allowing the WSUS policy that had the right settings did the trick, all my computers populated and reported to the WSUS Console within hours.

Setting Up a WSUS Server along with SEPM

Recently i installed WSUS on a server running Symantec endpoint protection Manager using default settings, and i didn't know that this is not recommended until my SEPM stopped working correctly..

The problem is both WSUS and SEPM create a virtual directory in IIS called content, and whichever was installed first will stop working, normally it's recommended to install WSUS on Port 8530 on a server where sharepoint or SEPM is already installed.

So basically I had to unistall the WSUS, sort out my SEPM, and re-installed my WSUS to use port 8530 and it's own virtual content directory and update the group policy to point to http://servername:8530.

After this I had WSUS and SEPM working in harmony.

Issues with Symantec Endpoint Protection Manager not updating Win32 Clients

For the last three weeks I have struggled to get my SEPM to update win32 clients, what was happening is, only the 64 bit machines running Windows 2008 server were the only machines getting updates from the management server, this was surprising indeed as the SEPM has been functioning without any problems until this point.

Trying to trouble shoot the problem, i started with the usual, reviewing the changes that have taken place between then (meaning when updates were running) and now. I had installed a WSUS server on the same server as my SEPM, so i tried unistalling the WSUS and followed step by step instructions from symantec on how to recover from this situation. all in all, this did not work, it was a desperate situation for me as all my Windows XP and Vista machine ere not updating so I had to allow manual updates.

Yesterday while I was on google, i found a post of almost the same issue with SEPM, so itried the solution and suddenly I had all my client PC's updating.

Briefly this is how i fixed this,

• Log on to ftp://ftp.symantec.com/AVDEFS/symantec_antivirus_corp/jdb/ and download the latest definitions (NB: they will have .jdb extension).
• copy the downloaded Defn to "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\inbox\content\Incoming" (this is on the SEPM server)
• In a period of 30 seconds to a minute the .jdb will be processed and all files and subfolders will be processed

to verify that the SEPM has been updated, open "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Inetpub\content\{C60DC234-65F9-4674-94AE-62158EFCA433}" you should see a folder or folders with the ymmddxxx naming convention, look for the current folder , inside it should have a folder named full and a zip file named full as well.

This cleared whatever was blocking my liveupdate, now it's working just fine.

IPv6 and Exchange 2007 Outlook Anywhere Feature

We Installed Exchange 2007 SP1 on Windows 2008 Server's at the Office (Toyota Malawi), and we have enabled OWA and Outlook anywhere (RPC over HTTP) features.

During tests I found out that Clients could not connect using Outlook Anywhere, google search revealed there is a bug with IPv6 in Windows 2008 that won't allow Outlook Anywhere to run in it's default state.

According to Technet, When a client using Outlook Anywhere tries to connect to Exchange 2007 SP1 running on Windows Server 2008, the client cannot connect. This happens because the RPCProxy component on the Client Access server that is running on Windows Server 2008 is unable to connect through port 6004 to the DSProxy component on the Exchange Mailbox server.

Windows Server 2008 has made TCP/IPv6 the default communication protocol stack over which connections are made by clients connecting to the server that is running Microsoft Exchange. The RPCProxy component tries to connect to the DSProxy component through port 6004 over TCP/IPv6. However, the DSProxy component does not listen on the TCP/IPv6 stack, which causes connection requests from the RPCProxy component to fail.

Running netstat -a -n resulted in:

TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:6002 0.0.0.0:0 LISTENING
TCP 0.0.0.0:6004 0.0.0.0:0 LISTENING
TCP [::]:6001 [::]:0 LISTENING
TCP [::]:6002 [::]:0 LISTENING

To fix this issue, there is a workaround wich will cause RPC over HTTPS to resolve the IPv4 address where port 6004 is listening. This can be achieved by doing the following:

Open the hosts file located at %SystemRoot%\system32\drivers\etc\ by using an editor such as Notepad.

1. Comment out the line “:::1 localhost”
2. Add the following lines:

• 127.0.0.1 localhost
• 102.54.94.97 rhino.acme.com # Host Exchange server
  
• 102.54.94.97 rhino
  

I also had to Disable IPv6 on the Exchange Server's by editing registry using this steps:

• Click Start, and then click Run.
• Type regedit in the Open box.
• Using Registry Editor, locate the following registry key: "HKEY_Local_Machine\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters"
• Right-click the Parameters key, click New, and then click DWORD (32-bit) Value. For the key, add the following values:

Name: DisabledComponents
Data: 0xFFFFFFFF

Microsoft has released a fix for automatically disabling IPv6, you can download this here, Click Run in the File Download dialog box and follow the steps in the wizard.

N/B: Avoid disabling IPv6 by unchecking box for Internet Protocol Version 6 (IPv6) on the Local Area Connection Properties.

There is plenty of Information about this issue on the internet, but this was just my experience