Is there a plan to create a more Recent Celerra Error Messages Guide?

The current plan is to migrate as many error messages as possible to the CCMD format (Celerra Common Message Definition).  If you see an error that looks like this:

BOXMONITOR:CRITICAL:506:::: 78928609786: Enclosure 0  CPU 0  I/O Module 1fault.

then you can look the message up yourself on the Control Station.  Just take the 11-digit CCMD ID and plug it in to the nas_message command:

$ nas_message -info 78928609786

And it will produce the following output:

MessageID = 78928609835
BaseID    = 555
Severity  = CRITICAL
Component = CS_PLATFORM
Facility  = BoxMonitor
Type      = EVENT
Brief_Description  = Enclosure ${encid,2,%ld} management switch ${num,1,%c} RS-232,  no peer traffic.
Full_Description   = A management switch internal error occurred. The error is logged when the management switch is not able to control or query the status of enclosure components because of a hardware problem that may be caused by a component or connection outside the management switch. Replacing the enclosure hardware or one of the management switches may be necessary.
Recommended_Action = Note: Some systems (for example, NS350, NS500, NS600, and NS700) do not support commands that check the environment, enclosures, and setup of the system.
 To resolve the problem, perform the following:
 1. If you are using Unisphere:
         a. Log in as root (requires the root password).
         b. To help diagnose the problem, go to 'Events', show the events for the Control Station, and look for error messages that occurred near the date and timestamp of this message.
         c. Go to 'CLI Commands' and run the "/nasmcd/sbin/setup_enclosure -checkSystem" command to verify that the internal network cables are connected properly. This could take a few minutes.
         d. If the system check reports errors, then fix the errors; if there are no errors, go to step f.
         e. Go to 'CLI Commands' and run again the "/nasmcd/sbin/setup_enclosure -checkSystem" command to verify that the errors were fixed properly. This could take a few minutes.
         f. If you are unable to resolve issues, go to step 3.
 2. If you are using CLI:
         a. Log in as nasadmin (or as a user with NAS administrative privileges) and "su" to root (requires the root password).
         b. To help diagnose the problem, run the "nas_logviewer -v /nas/log/sys_log | less" command and look for error messages that occurred near the date and timestamp of this message.
 Note: Based on when the event occurred, the log messages for this particular event may be located in other generations of the sys_log file (for example, sys_log.1, sys_log.2, through sys_log.10).
         c. Run the "/nasmcd/sbin/setup_enclosure -checkSystem" command to verify that the internal network cables are connected properly. This could take a few minutes.
         d. If the system check reports errors, then fix the errors; if there are no errors, go to step 3.
         e. Run again the "/nasmcd/sbin/setup_enclosure -checkSystem" command to verify that the errors were fixed properly. This could take a few minutes.
 3. If the problem is not resolved, search the Knowledgebase on Powerlink as follows:
         a. Log in to http://powerlink.emc.com and go to Support > Knowledgebase Search > Support Solutions Search.
         b. Use the message ID or text from the error message's brief description to search.

As you can see, the message descriptions are very thorough.  There are also corresponding entries for most CCMD messages in the Knowledgebase.

-bill

Thanks for the information. The reason I was asking is because I've recieved the following error in my server logs

   VC: 3: 32: Server '161.36.146.29' returned error 'ACCESS_DENIED' when checking file

and I'd like to troubleshoot it on my own. Since I can't I'll open up an SR.

Thanks,

Ayo

Interesting

Are you using a w2k8 server for av checking?

Have you any policies set in place and what is the AV engine (savse, macafee etc ...)

Claude

Does it return this message on the same files or different files every time you copy the same set of files?

There is a Primus solution (238805) which describes the same situation when using Nested Mount File System (NMFS) with long pathname, is this the case?

You should open a Service Request if this does not apply to your situation

Claude

bergec wrote: "Are you using a w2k8 server for av checking?"

I actually am using Win2k8 for these virus checking servers! I'm also using McAfee 8.5 enterprise as the virus scanning solution. We have a CAVA environment for another set of Celerras in our east coast DC and those hosts are using Win2k3 and we don't have any problems. That environment was also set up a 2 years ago and were built using Win2k3, our intel technology team has standardized on Win2k8 for new server builds so that is why I'm using Win2k8 in this instance.

We implemented the correct policies the first time CAVA was implemented the end result was that an a CAVA ePo was created in McAfee to set the correct policy options so that the CAVA environment could do its work. So the policy issue isn't the problem as it is working on the east coast and not in the new environment on the west coast, the difference between these two sites is that the new environment is using Win2k8.

Is there a primus article on why using Win2k8 could cause this type of issue? I didn't stumble across this Primus article can you send me the article name?

I almost forgot to reply to that tidbit and I hope it point me in the right direction.

Thanks,

Ayo

Claude,

I came across the emc238805 article as well. But after trying to move the eicar file to a folder that was less than 8 characters I realized this isn't the same issue.  I opend up a case a few days ago and I was told to go and read the CAVA documentation and ensure that I've made the account that starts the CAVA service a local administrator. I've read the documentation cover to cover and I didn't miss that detail so my issue is something else.

If it turns out that I did miss a detail, I wish the error messages weren't so generic so that a user can self diagnose his/her own issue. The wierd thing is that I have two CAVA servers and I only get the error on one CAVA host and not both, so I know this issue is something deeper. I'll wait till my case owner does some more research before I escalate.

Thanks for the suggestions.

Ayo

As far as I know, it should work with w2k8. Let us know the SR number.

Claude

Is this w2k8 32bits or 64bits?

Let us know thé SR number,

Claude

AFAIK Windows 2008 is always 64 bit ...

Bergec,

I'm running Windows 2008 32bit. I opened SR# 34762896, but I pointed my support engineer to this thread because I saw your post and thought you might have had insight into why Win2k8 would have been a bad CAVA host OS. But since you say it isn't then I'm still stumped as to why I'm having an issue.

Thanks,

Ayo

Yes - I'm running 64-bit W2k8, 64-bit CAVA (you must download the correct CEE 64-bit installer, not the 32-bit one) and 64-bit McAfee 8.7.i.  It's been stable since I went to CAVA 4.5.22 and 8.7.i, patch 3.

Thanks!

Karl

I don't know if it's an option for you, but I'm using Windows Server 2008 R2 64-bit with McAfee 8.7i.  We had a good thread on McAfee 8.5 here - https://community.emc.com/message/463818#463818, which might be helpful.  The problem may not really be Win2k8, but actually McAfee 8.5.  Which patch are you on?

I spent two months this winter, dealing with issues in Patch 1 of 8.7i; we gave up and went to Patch 3 and the problems cleared up.

Let us know if this helps!

Karl

Karl,

Thanks for the response. I was incorret in naming our version of McAfee it looks like we are running 8.7i listed below, I believe its Patch 2 but I'm unsure where to get the exact patch level information. I'm the storage admin and am not too familiar with the McAfee infrastructure but if there are any suggstions that would be greatly appreciated.

I did read the post your recommended and maybe our issues lie in the fact that our virus check mask is *.* with a few exceptions. What files should I scan for viruses on in order to get maximum protection but minimize potential vulnerabilities.  (our mask is listed below)

1 File Mask(s):
*.*
31 Excluded File(s):
*.BAK *.EAS *.EDB *.LDB *.LDF *.LOG *.MDB *.MDF *.NDF *.ORA *.PST *.SHD *.SPL
*.STM *.TRN *.TXT *.ASC *.DAT *.HAL *.LOK *.PLK *.SEC *.UDL PAGEFILE.SYS
NTDS.DIT NTFRS.JDB WSUSSCAN.CAB WSSUSCN2.CAB TEMP.EDB EDB.CHK CATALOG.WCI

Thanks,

Ayo

Can you install 64b versions of CAVA and McAfee on a w2k8 64bits server?

Claude

Oooh!  Here's an idea.  In McAfee, are you set to "Clean, else Deny" or "Clean, else Delete"?  In CAVA 3.5.2 on 2003R2, we could no longer use "Clean, else Deny", we could only do Delete.  I saw the same ACCESS DENIED messages you have.  It's almost like the CAVA user account couldn't perform the filesystem operation to rename the file to BLAH.vir, but it could delete it with no problems.  Can you test that case?

Thanks!

Karl