I disabled sophos on FS. On the corrupted file I found the following:
couldn’t check properties in explorer
couldn’t copy the file in explorer
couldn’t delete the file in explorer
couldn’t copy the file in a dos box
COULD delete the file in a dos box.
I then rebooted the server just to make sure it was happy.
It appears that if there is a high CPU utilization we should check what process is the highest. If it is sweep, check the last file it scanned – we might be able to use that to track down a corrupted file (if that is the problem). In this case “user” was the last user to have a file scanned, but it wasn’t the corrupted file.

I was hoping to be able to get a copy of the file and then place that on a test server to see if we could duplicate the error and see if there was another way to prevent the server from crashing, by disabling sweep w/o a reboot.

Servers NS and STAPPS were rebooted due to an error when running dsrepair. NS’s problems was not able to find the files – in which rebooting was the easiers fix. STAPPS’s problem was it hung while running DSREPAIR. All network access was still there, but backups would not have occured.

FS server crashed due to overloading of CPU. Why – yea – good question.
Attached sniffer to look for problems – maybe we will catch something if it happens again!

Had to restart, run vrepair, and it was good to go.

A drive failed in server STAPPS – one of the 2 4G sys drives.

The drive was reseated and it rebuilt.

The server FS and FSAPPS was rebooted to resolve some locked file and locked user issues. It appears to have worked. While the servers were down images were also made.

FS did not go down gracefully. To bring it down I had to power it off. There were several users with files open – were they “really” open, or were they in an ambiguous locked state similar to the files we were trying to free up? Because of this I had to run vrepair on all volumes – there were many errors on userdata. After the server was back up, there were not any problems with the files we were trying to “free”.

Upgrade the 6509 IOS and the MSFC IOS to allow for the use of the new copper based GBICs. Changed all trunking from ISL to DOT1Q. Had problems in the seminary with the link between the 3550-48 and the 3524 on the 1st floor. It is possibly a bad gigastack on the 3524.

Upgraded the Pix to IOS 6.2.2 to allow for testing and use of VPN’s for Lancaster as well as for the windows client.

A flash card will now need to be purchased for the 6509 to allow for failover and for future upgrades – not enough memory on the board anymore.

All Novell servers, but NS, are patched to the latest service packs for pervasive software. I’m leary on doing NS since these SP’s affect Btrieve, which Novastor uses.

Dan

Novell server FSAPPS crashed.

abended in DS.nlm – couldn’t tell why based upon logs.

Ran DSREPAIR with options for cleaning 613 errors about 15 min before crash – but it was also run on all of the servers.

FS server was down for about 30 minutes after it abended again and wouldn’t go down gracefully. Vrepair was run on all volumes.