PiqueABoo Posted November 4, 2010 Posted November 4, 2010 An update re. my server: It's not conclusive, but there aren't any 2012s in the logs until after AV was installed on server and clients (there was a lot of data flying about both before and afterwards). I usually get a set of 6-8 at the same time (resolution = seconds), but there are a few cases where there are just two.
jsnetman Posted November 4, 2010 Posted November 4, 2010 (edited) I know with nod32 I had big problems because I did not turn off scan network/mapped drives on the clients, meaning everytime a user logged on it would scan their mapped drives and home folder causing massive problems, if you get lots of users logging on at the same time i.e at the start of a lesson then a big hit will happen on the server. Does macafee scan mapped drives by default ? Edited November 4, 2010 by jsnetman
PiqueABoo Posted November 4, 2010 Posted November 4, 2010 Does macafee scan mapped drives by default ? My server and workstation McAfee "On-Access Scanner" properties has *no* tick in the box for "On network drives". And there's no sign of any related trouble on the workstations.
jsnetman Posted November 5, 2010 Posted November 5, 2010 If you look at the individual ports on the switch that the server in question is getting the 2012 errors, are there any problems on those ports like collision detections. You may have to enable this on the switch. Also I presume duplex speeds are set correctly on server and switch.
dhoward_westexetc Posted November 5, 2010 Posted November 5, 2010 (edited) I had our file server drop out again just now, on the Rx side. I had to reset the virtual network adapter to be able to get it back online again. It's the 4th time I have had it do this after we enabled teaming. I fear I may have to reverse this if this carries on. In all the cases I had this happen it works fine on Tx, but not Rx. I've disabled temporarily the Windows Firewall and McAfee on-access scan to see how it performs on the 2012 side. I will report back. Edited November 5, 2010 by dhoward_westexetc
dhoward_westexetc Posted November 5, 2010 Posted November 5, 2010 I am going to reverse the teaming as that does not seem to have fixed the issue. I am also going to disable Large send offload and some other offloading. I'm also enquiring with our support company who manage our switches to check the config of the ports and ensure that the settings are in sync, before I contact Dell for their assistance. I will inform how this goes for us.
sjl Posted November 5, 2010 Posted November 5, 2010 I noticed this error happens about 15 times on a bad day on our 2008 server. We dont seem to be having any problems although i do want to get to the bottom of the warning. Like it has already been said, by not quantifying the acceptable rate of these errors how do you know what is normal -- a bit of a poor event message.
dhoward_westexetc Posted November 5, 2010 Posted November 5, 2010 I noticed this error happens about 15 times on a bad day on our 2008 server. We dont seem to be having any problems although i do want to get to the bottom of the warning. Like it has already been said, by not quantifying the acceptable rate of these errors how do you know what is normal -- a bit of a poor event message. That's what I am attempting to figure out...except we have up to 30-60 events a day, which is a humongous amount. I'm trialling disabling Receive side scaling, Large send offload, and Rx checksum offload, and have correspondence with out support company for our switches to try and find the optimum configuration. After those changes (and having to restart our DNS server!) we have not had an srv error for 45 minutes. The problem with these is the cause seems to vary depending on the network environment. Different things work for different environments it seems. While the error code is useful, the information around it isn't. That's why it seems to be such a hard error to pinpoint.
PEO Posted November 5, 2010 Posted November 5, 2010 Turns out kaspersky is what is causing this error for us, if I disable it the errors go away and the network dosen't crawl to a hault. I'ts obvious now that its something to do with network paths, so Im trying to figure out what needs to be excluded on both server and client side policies
jsnetman Posted November 5, 2010 Posted November 5, 2010 That's why it seems to be such a hard error to pinpoint It certainly is, I have seen references to faulty printer drivers, SMB, faulty nics/drivers, network cables, switch misconfiguration and general network design and a loads more to boot. Can't help feeling like I used a sledge hammer to crack a nut in my case.
dhoward_westexetc Posted November 5, 2010 Posted November 5, 2010 It certainly is, I have seen references to faulty printer drivers, SMB, faulty nics/drivers, network cables, switch misconfiguration and general network design and a loads more to boot. Can't help feeling like I used a sledge hammer to crack a nut in my case. Yeah we only ever get it on accessing file shares from what I can see. But what I am fairly certain of in our case is: - It's not printer drivers, since it's not a print server. - The drivers are fully up to date. - The cables are brand new. Cat 5e, but we've never known issues with Cat5e on servers. Nevertheless, I have to see what the switch config is from our support company. I should hear soon.
jsnetman Posted November 5, 2010 Posted November 5, 2010 If its just on file access I seen a smb fix for 2008 while I was looking around this morning, will try and find it again.
dhoward_westexetc Posted November 5, 2010 Posted November 5, 2010 If its just on file access you could try this That's for Windows 2000. There's nothing there on that article that will help to resolve it on Windows 2008 from what I can see?
jsnetman Posted November 5, 2010 Posted November 5, 2010 Yeah I know I thought I had found the hotfix i had seen earlier.
jsnetman Posted November 5, 2010 Posted November 5, 2010 Found it, don't know if it applies to your situation, link was taken from this thread on event id 2012 here and the link to the hotfix here
dhoward_westexetc Posted November 5, 2010 Posted November 5, 2010 Found it, don't know if it applies to your situation, link was taken from this thread on event id 2012 here and the link to the hotfix here Now that is an interesting one. I just had a delay in response when I tried to access a file share on our file server from a Windows 7 client when I tried to change from cable connection to wireless. At the same time, an srv error appeared on our File server! Only trouble is it only applies to Windows 7/Server 2008 R2, and we were getting the error before we deployed Windows 7 to many people. Mind you, we still had Windows 7 on our technician PCs. I'm still curious as to why it affects a Server 2008 SP2 on the other end OS though...maybe its a throwback. It seems to make sense in some ways, but not others. I'll try it nonetheless.
ferlin75 Posted November 9, 2010 Posted November 9, 2010 Hello! Have you guys had any luck in solving this issue? I've got the same problem (event id 2012) on a Win 2008 64 R2 Server running on a Dell Poweredge T710. Interesting for me is if there is any corelation between this problem and running Hyper-V-clients on the server which I'm currently doing. First time I saw this error was today and at the same time I can't connect to the Hyper-V machine (havent had any problems with this before), so a fair guess is that it's somehow related. I can connect to the virtual machine from the Hyper-V manager and I have no problems reaching the host (my Win 2008 server) by RDP. Any suggestions are welcome! Regards from a cold Sweden /Fredrik
dhoward_westexetc Posted November 9, 2010 Posted November 9, 2010 No but I am closing in. My attention now is drawn to a setting in McAfee VirusScan On Access scanner called 'block connections when a threat is detected in a shared folder', on client McAfee plus the fix for Windows 7/Server 2008 R2 described above. I found before I did this setting that I would get a delay every now and again when trying to access the shares on the affected server. I did get access eventually, but during that hang it would also generate srv 2012 errors on the file server at the same time. If I take this check box off I don't get the hang and hence I never generate the srv 2012 errors from my machine. I'm going to distribute the CFG file from McAfee Installation Designer to the clients via startup script GPO to reconfig the clients to take this off. Then I will see if any more srv 2012 errors are generated. Very intriguing. Make sure you install the August 2010 Hyper-V rollup on your Hyper-V servers. There are some networking fixes in that. Srv 2012 errors can be caused by all sorts of things in a network environment, but it seems to be mainly file and print sharing related in our particlar case. 1
PiqueABoo Posted November 9, 2010 Posted November 9, 2010 My attention now is drawn to a setting in McAfee VirusScan On Access scanner called 'block connections when a threat is detected in a shared folder' Well spotted - I've got a tick in that box too and it's certainly a credible potential cause.
PEO Posted November 9, 2010 Posted November 9, 2010 Found it, don't know if it applies to your situation, link was taken from this thread on event id 2012 here and the link to the hotfix here we dont have 2008 r2, just 2008. would this work in our case
dhoward_westexetc Posted November 10, 2010 Posted November 10, 2010 we dont have 2008 r2, just 2008. would this work in our case May well do if your clients are Windows 7, since in that case you would apply the fix to the client side.
dhoward_westexetc Posted November 10, 2010 Posted November 10, 2010 (edited) Well spotted - I've got a tick in that box too and it's certainly a credible potential cause. Well I have the updated config now distributed across our network so I will let you know how that goes! If you have a Terminal/Remote desktop server for remote access with McAfee installed on it you will have to apply the setting to that as well. Forgot about that so was getting the srv 2012 errors in the evening! Obviously there will be some machines that won't have been rebooted, so there will still be some that haven't had the McAfee config file applied yet so still have this enabled. What i'm looking for is a reduction in them, not at this stage a total elimination of the issue. Edited November 10, 2010 by dhoward_westexetc Added bit about machines that have not rebooted
dhoward_westexetc Posted November 10, 2010 Posted November 10, 2010 (edited) Just an update on this, I probably won't know if this has fixed it for a few days yet, since machines will gradually pick up the settings as they are rebooted. I've just rolled this updated file now to our older staff laptops as they will still have the setting enabled. The other niggle is that the 8.7i CFG files aren't applying to 8.5i installs, access protection blocks them, so that check box is still ticked, so potentially the 8.5i installs are now the ones causing the problem. However all 8.7i installs on both Windows 7 and XP are having these settings applied successfully. I'm planning anyway to accelerate the phasing out of our older McAfee VirusScan 8.5i installations and replace them with 8.7i so that every machine is on the same level, which is something that I was going to do anyway, and will be inevitable when we move all of our client machines to Windows 7 as 8.5i does not work on that platform. Fingers crossed. Edited November 10, 2010 by dhoward_westexetc
Rozzer Posted January 7, 2011 Posted January 7, 2011 Hey All, Has anyone got an updates on this issue? Just noticed it on my hyper V file server... Ross
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now