大家好，诺顿服务器版相信很多的网友都不是很明白，包括诺顿防病*软件有PC版和服务器版之分吗也是一样，不过没有关系，接下来就来为大家分享关于诺顿服务器版和诺顿防病*软件有PC版和服务器版之分吗的一些知识点，大家可以关注收藏，免得下次来找不到哦，下面我们开始吧！
一、“诺顿”和“NOD32”有什么区别
卡巴斯基、诺顿(Norton,企业版=Symantec)、麦咖啡(McAfee),Nod32,小红伞综合测评很多新人都不知如何选择自己的杀*软件，作为一个狂热的杀软试用狂，特在论坛发帖，希望能给大家一点帮助。卡巴斯基、诺顿、麦咖啡是当今世界三大顶级杀*软件（个人观点，德国的小红伞也是非常不错的，但因为没有官方正式中文版，所以在中国的影响力比较低，但这款杀软占用资源极少，杀*能力却极为强劲，甚至超过卡巴，在防御网页*方面很出色），三者的市场定位也不尽相同。卡巴斯基以个人用户为主，而诺顿和麦咖啡则以企业用户为主，不同的定位，导致了这三款杀软具有各自独特的品质。所以，孰优孰劣，仁者见仁，智者见智。但总之，适合自己的才是最好的。先说卡巴。卡巴作为在中国最有影响力、使用率最高、*率最高的杀*软件，口碑甚好。但这里首先要提的一点是，卡巴的市场营销战略极为出色，作为最早抢占中国市场的杀软，卡巴纵容了铺天盖地的key，让成千上万的国人免费用上了来自俄罗斯的强悍杀软。但大家都知道，习惯已经养成，想改掉是谈何容易？就像美国人饮食文化的全球扩张一样，饮惯了可口可乐，白开水自然失去了原有的吸引力；吃惯了麦当劳，谁还会习惯平淡无味的干馒头？短暂的让利，为的是久远的获利，在知识产权保障制度越来越完善的某天，我相信，我也坚信，大家都会习惯花钱买杀软，正如现在花钱买水买电一样的自然，那时候，卡巴的精明，才会真正得到验证！作为评价最高的杀软，卡巴最吸引人的自然是其近似于霸道的杀*能力，好似霸王项羽，有君在此，一夫当关，万夫莫开！卡巴杀*能力的强悍，依赖于其先进的引擎，芬兰的七引擎杀软f-scure至今都用着卡巴的一个比较落后的引擎。卡巴斯基的病*库，是极为庞大的（虽然无法和bit、panda相比），且实时更新极为频繁，能帮助用户很好的应对网上最新的病*。再来说说卡巴的不足。占用资源高，这是卡巴一直遭人诟病的短板。虽然在卡巴7.0做出了明显的改进。卡巴近似神经刀的防御能力，一方面会让许多病*无处遁身，另一方面，也会造成许多文件的误杀。卡巴在这方面的不足，造就了防御*杀软的如日中天，麦咖啡、诺顿就是这其中的顶尖代表。（另外，国产杀软微点，也是非常出色的）。为什么企业倾向于诺顿和麦咖啡？这就得益于这两款杀软的稳定与保障*。卡巴宁可错杀一千，不可放过一个，对于企业的重要文件，如若错杀，后果不堪设想。单说咖啡。咖啡拥有世界上最为出色的规则，规则设置的好，我认为，咖啡就是无敌的。这就涉及到了一个问题，杀软与病*的休戚与共。没有病*，就不需要杀软，正是*孜孜不倦的努力，才造就了世界上如此众多的互联网安全厂商。但有一点是亘古不变的，二者的*杀软永远是处在弱势的地位，因为，病*更新的速度远非杀软能及。所以，咖啡的主动防御就显得高明的多，根据个人特色的规则，咖啡比世界上绝大多数杀软防范未知病*与未知*的能力要强的多得多！咖啡的弱点，繁琐，绝对是折磨众多电脑新手最大的问题。但，一旦适应，你会很快乃至近似疯狂的爱上咖啡的规则。再谈诺顿（我个人的御用杀软),也是优缺点并存的。先说缺点吧，网友对诺顿的批评主要集中在两个方面：1资源占用‘媲美’卡巴2杀*能力稍显弱。我就说说一家之言，防御*杀软的好处就是，将病*要在发作前很好的将其排斥在系统之外，所以应对绝大多数的病*是没有什么问题的。另外，诺顿的稳定*是我最喜欢的，虽然也出过“误杀门”，但始终“瑕不掩瑜”。在这里，我要说，诺顿的未知病*防御能力真的不是一般的强，尤其是配上了诺顿的防火墙，很贴心，也很简单。综上所述，防御*杀软（诺顿麦咖啡nod），应该会有越来越好的发展，而卡巴也会在它的受众群中继续它的王者霸气。 nod与红伞红伞与nod都是我个人喜欢的杀*软件，查杀能力强，资源占用低（在此我所做的任何关于红伞的评论都是客观、公正的前提下，不存在所谓的个人崇拜，也不存在神话的顶礼膜拜，个人从2006年开始用红伞）。杀软的评价除了要看查杀效果、监控能力之外，资源占用也是一个很重要的指标。对与我们这些个人电脑用户来说，速度就显得尤为重要，卡巴、BD过于沉重，拖沓缓慢。杀软应该做到查杀效果和资源占用的协调统一，在这两者之间寻找一个平衡点，而nod32与红伞就是当今安防领域的翘楚。先来说说在我们论坛人气非常旺的nod32。长期以来，NOD32一直都是国际权威反病*认证VB100%的记录保持者，也是全球唯一40次以上通过VB100%认证的防病*软件。虽然有些人不认可vb100%，但这个数据的获得却是可望而不可及的能力体现，毕竟这是卡巴斯基、麦咖啡等老牌杀软都不曾达到过的高度。启发式杀*是nod32的核心，一款杀*软件的好与坏，主要是看它对于未知病*的防范能力，在这方面，nod32与红伞就走在杀软的前列。病*库的大小已经成为不了评价杀软的首要因素，在这个时代，我们看的就是启发。虽然卡巴的主动防御也有值得称道之处，但hips的发展仍然还处于起步阶段，防杀效果并不完善。另外，用过nod的人都喜欢它的安静，简约而不简单。再来说说nod32的缺点。病*库数量不大，使得nod经常对于一些经典的病*视而不见。在单纯的杀*能力上来说，nod32是比较弱的。经常在各大论坛的样本区转的网友应该知道，红伞绝对是当之无愧的查杀之王。（nod在这方面的表现甚至不如国产的瑞星，捷克的小a）。当然，谁也不会在自己的系统无端中那么多的*，杀*软件始终应以防御为主，查杀为辅，但对于那些对系统有着极高苛求的人，卡巴、红伞也是一个不错的选择。现在谈谈红伞。红伞的优点在于资源占用少（绝对媲美nod，但占用虚拟内存较多），杀*能力无与伦比，启发式杀*对于网页*和恶意脚本的拦截能力极为出色。我最喜欢红伞的高启发，虽然这会带来一定的误报与误杀，但在我使用红伞的期间这种情况并不多见，即便我的电脑里有非常多的软件。在这里，我要谈一下个人的上网习惯。经常到一些比较正规的网站或论坛东西是很重要的，否则，你会稀里糊涂的被中上病*和*。有的人刚用红伞就会说，为什么这么多的软件红伞都报病*？那请你仔细看看你所的东西。再和蜘蛛做一些比较，我想说，蜘蛛做辅助杀软是很好的，但做主杀就有点勉为其难了，蜘蛛的引擎不错，但病*库实在是不敢恭维，蜘蛛是杀软中误报率的number one。红伞是官方永久免费的杀软，是官方支持的免费正版。Nod32的反*行动现在是越来越坚决了，国内许多的升级服务器迫于压力，已经关闭。我想问一句，你相信别人封装好的版本是纯净的？你相信有些服务器不会在升级的同时将一些病*和*放入其中?有人或许会说，*ast也不是完全免费的吗？其实小a也不错，但与nod、红伞、卡巴等相比，显得逊色。小a的脚本拦截有点徒有其表的意思，缺乏智能*。总而言之，红伞和nod是难分伯仲的，二者是当今世界单引擎杀软中的极品。你要问我到底应该用哪一款？我只好告诉你，你选择，你喜欢，选择了你的爱，就要爱你的选择。
二、诺顿防病*软件有PC版和服务器版之分吗
主要是分为家庭版和企业版，企业版主要是面向企业多台服务器、台式机、笔记本的应用，统一管理。
家庭版包括：诺顿360、诺顿网络安全特警、诺顿防病*软件（功能由高到低）
企业版主要有：Symantec Protection Suite Enterprise Edition、Symantec Endpoint Protection（功能由高到低）
个人电脑最好使用家庭版，也可以使用企业版的客户端。
三、服务器老是出现停止错误,然后意外关闭,请问各位大侠怎么解决
可能的原因：
一、内存错误
二、某个定时的服务引起死锁
三、病*残留或者*攻击
四、诺顿的文件检查功能
检查及处理过程：
一、由于这是第一次出现类似重启，先不考虑硬件故障。但内存错误仍有另外一个可能*就是对磁盘上的虚拟内存访问出错。先检查虚拟内存所在磁盘，未发现错误。但磁盘中有比较多的文件碎片，考虑到内存文件过于分散有可能会引起偶尔的读错误。所以在凌晨1时左右进行一次全盘的文件碎片整理。
二、根据原因代码，网络上有关于定时服务引起文件死锁的记录，而查询登录日志，离重启最近的访问来自于另一台服务器B，加上出现故障时间与整点比较接近，有可能与某些系统服务有关，所以，将B中的DNS、DHCP等服务关闭，因为这些服务会与故障服务器通讯同步，或者进行某种查询。更进一步地，将服务器和B服务器上的文件跨网络定时复制备份等功能删除。
三、从微软的网站找到有关病*也会引发类似故障的说明（相关网址），按说明查询后排除可能*，然后，再检查可疑的设备驱动，也未发现任何可疑之处。另外，通过查询防火墙日志，在19：03前也未发现有异常的攻击事件。
四、通过网络上上报的事故报告（相关网址）中提到Symantec的版本有关，在Symantec的技术支持网站看到相类似的报告。考虑到离最近的故障时间登录者是B服务器，而我们的B服务器上恰恰安装了Symantec的10.0版，怀疑与故障服务器上的9.0版在升级病*库时产生了冲突，所以将B上的Symantec杀*软件删除，然后安装了一个客户端，由故障服务器统一管理。
进一步分析
用WinDbg对系统崩溃时的内存Dump文件分析，发现系统重启时的引发文件为RapDrv.sys。
这个文件为BlackICE的系统文件，它包括了监视应用程序的变化的相关模块，可参见BlackICE的在线说明
检查RapDrv.sys，文件没有被改变的迹象，可排除被*和病*修改文件的可能*。
对Dump文件进行调试，找到RapDrv.sys出错时的堆栈情况，具体内容如下：
EXCEPTION_CODE:(NTSTATUS) 0xc0000005-"0x%08lx""0x%08lx""%s"
FAULTING_IP:
RapDrv+9785
f535e785 894104 mov dword ptr [ecx+4],eax
TRAP_FRAME: f4c0bb54--(.trap fffffffff4c0bb54)
ErrCode= 00000002
eax=858b8b4c ebx=00000000 ecx=00000000 edx=00000000 esi=858b5000 edi=84e2660c
eip=f535e785 esp=f4c0bbc8 ebp=f4c0bbdc iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
RapDrv+0x9785:
f535e785 894104 mov dword ptr [ecx+4],eax ds:0023:00000004=????????
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: blackice.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8085b4b3 to 8087b6be
STACK_TEXT:
f4c0b720 8085b4b3 0000008e c0000005 f535e785 nt!KeBugCheckEx+0x1b
f4c0bae4 808357a4 f4c0bb00 00000000 f4c0bb54 nt!KiDispatchException+0x3a2
f4c0bb4c 80835758 f4c0bbdc f535e785 badb0d00 nt!CommonDispatchException+0x4a
f4c0bb6c f5355b93 850ab630 84e2660c 858b5001 nt!Kei386EoiHelper+0x186
WARNING: Stack unwind information not *ailable. Following frames may be wrong.
f4c0bbdc f535aa20 85897900 84e2660c 00000028 RapDrv+0xb93
f4c0bc08 f535b282 00222034 84e26608 00000058 RapDrv+0x5a20
f4c0bc28 f535b2f3 865b5ba0 00000058 86043a70 RapDrv+0x6282
f4c0bc4c 8092d3b9 84ad79d8 858e9028 84ad7968 RapDrv+0x62f3
f4c0bc60 8092e81b 865b5ba0 84ad7968 858e9028 nt!IopSynchronousServiceTail+0x10b
f4c0bd00 80940844 00000160 00000000 00000000 nt!Io*xxControlFile+0x5db
f4c0bd34 80834d3f 00000160 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f4c0bd34 7c95ed54 00000160 00000000 00000000 nt!KiFastCallEntry+0xfc
0012d688 00000000 00000000 00000000 00000000 0x7c95ed54
STACK_COMMAND: kb
FOLLOWUP_IP:
RapDrv+9785
f535e785 894104 mov dword ptr [ecx+4],eax
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: RapDrv
IMAGE_NAME: RapDrv.sys
DEBUG_FLR_IMAGE_TIMES*P: 3f99bc4f
SYMBOL_NAME: RapDrv+9785
FAILURE_BUCKET_ID: 0x8E_RapDrv+9785
BUCKET_ID: 0x8E_RapDrv+9785
Followup: MachineOwner
从上面可以看出，在系统崩溃时，RapDrv正试图作一个IO操作，在IopSynchronousServiceTail调用时出错。在网上查寻相关资料，发现DapDrv有一个系统漏洞（相关资料），这个漏洞目前并没有相关补丁和解决方案，好在它发生的条件比较苛刻，如果是攻击，必须是已经攻入系统，在试图修改应用程序时才会触发。也就是说，如果想用这个漏洞进行攻击，对方必须是已经攻入系统才能利用这个漏洞。
综合上述，原来推测的四个可能*，只有最后一个Symantec的版本问题最有可能，因为其它的文件传输，只要不修改服务器上的可执行程序，是不会引发错误的。而Symantec在B服务器上安装的也是服务器版，它的升级过程中，可能会试图替换故障服务器上Symantec的上的9.0版程序。这才会触发RapDrv对文件进行监控。
目前最终处理方案是：
考虑到这种事故发生时造成的影响较小，在基本排除硬件故障后，决定暂时只处理Symantec的版本问题，然后继续观察服务器的状态，如果不再发生类似事件，则不予理会。如果再一次发生类似情况，就将BlackICE中的文件保护功能关闭，这样可以一劳永逸地解决这类事故。