ipswitch_imailserver_logo

        前段时间遇到一个棘手的故障案例,有一台 Imail Server 在完成了系统迁移之后,相关的服务无法启动了,其中反病毒插件及队列处理组件均无法正常运行。特别是队列处理组件——IMail Queue Manager Service,手工启动提示无法处理该服务。由于当时忙于处理故障未能截图,不过具体的表现除了这些之外就是你无论如何清理注册表重新安装或覆盖安装均无法再次激活 Imail Server。即使降级或升级到最新版本后再正常卸载重新安装需要的版本还是出现一样的故障!

        实在让人为难,于是彻底对整个系统进行检查,发现了蛛丝马迹!在 Windowssystem32 目录下找到一个奇特的目录,该目录名称为:E177E04D548C4006A465EEB92D3DE021,根据多年的系统管理经验来看,该目录并不隶属于 Windows 系统自身的,打开下面的子目录发现了与授权有关的一些“诡异”目录和文件,同时还发现该目录被赋予了 everyone 有完全控制权限!着实的让我惊讶一番!因为该服务器上还运行着其他应用服务,故不敢贸然处理。之后在网上通过该目录名作为关键词进行了搜索,收获甚微!看来只能自己进行分析处理,最终只能通过多台服务器的对比进行分析,同时根据整体特征及目录生成日期,再对比网上提到的信息,确认该目录是一种软件授权所产生的,但是网上提及的信息并不是 Imail Server,而是另外一款软件。但是要处理的该台服务器上所安装的涉及国外的软件也就是 Imail Server,并且进程中并为发现与该目录有关联程序,最终决定将其删除。

        重新安装 Imail Server,God!可以重新激活了!看来罪魁祸首果然是这个目录!没有再仔细去研究,不过由于看来,Imail Server 的授权机制应该不是自家开发的。此外,该目录的默认目录权限设置可是存在着重大的隐患,希望该篇日志能够提醒并帮助到大家。

        如果大家与 gOxiA 一样遇到了同样的问题,不妨一试!

Tags:

myphone

        微软在 MWC 09 大会上,公布了 Windows Mobile 6.5 以及 My Phone 后,各大网站争先报道。WM6.5 是 Windows Mobile 7 发布前最后一个 6.x 版本,据说 Windows Mobile 7 将归入 Windows 系列更名为 Windows Phone,这些信息还有待考证。今天要与大家分享的是 MyPhone 服务,这是微软推出的一个在线服务,主要针对移动用户同步手机中的资讯,一旦使用了该服务,我们以后可以不必担心手机丢失或里面的信息丢失,可以即可在一部新手机中通过 MyPhone 同步之前的资讯。MyPhone 不仅提供了常见的联系人、日历、任务的同步,还提供了短信息、图片、文档等类型文件的同步。我想所有在使用 Windows Mobile 的用户一定非常迫切地尽快开始体验。但是,当我们访问 MyPhone 站点时,我们会发现使用 Passport 登录后需要申请等待邀请,或输入邀请码才能开始正式使用 MyPhone 这一服务,就在昨天我看到了 cnbeta 上发布了朋友碎片的一篇文章——《微软My Phone服务试用》,着实的让我羡慕了好久!赶紧登录 MyPhone 发现自己的帐号还是在等待队列。郁闷……

myphone1

        今天在跟刘晖聊了有关 Microsoft MyPhone 及 Google Sync 后(PS:之前我测试过 Google Sync,导致我的联系人分类都变成了问号还没法删除,最后不得已在 PC 的 Outlook 中清理了所有联系人的分类,很惨!),利用闲暇时间在我的 PPC 上通过 GPRS 连接访问了 MyPhone,根据之前碎片提供的一个网址下载到了 MyPhone 的客户端,直接在 PPC 上安装并进行登录,太令人兴奋了!使用之前登录的 Passport 竟然可以登录,并提示我进行同步设置!之后用了很短很短很短的时间(PS:用了个很短是因为与之前的 Google Sync 相比,速度简直太快太快太快了!)完成了整个联系人、日历、任务的同步!之后赶紧从 PC 上访问 MyPhone,测试是否也能登录,别手机把信息同步了,但是没法去访问使用。

        果然,当我再次通过 PC 登录 MyPhone 后,发现已经成功进入到了主界面,并且能够看到我的所有同步信息。此时,我的 Windows Live Mail 也收到了 MyPhone 的欢迎邮件!哈哈……

myphone2

        从 Windows Vista、Windows Server 2008 开始,远程桌面协议(Remote Desktop Protocol,简称 RDP)开始支持网络级身份验证(Network Level Authentication,简称 NLA)。通过启用 NLA,我们的 RDP 将更加坚固,当客户端进行 RDP 登录时将不再会先显示出远程系统的登录界面,并须在客户端得到正确的登录验证后,方能成功并直接登录到系统桌面。这样一来,除了避免的一些信息的泄漏,还有效地防止了远程客户端的恶意穷举。如下图所示,我们只需要在“远程设置”中,启用“只允许运行带网络级身份验证的远程桌面的计算机连接”即可!

1

        一旦在服务器端的 RDP 服务上启用了 NLA,并且客户端是 Windows Vista 或以上版本,那么我们可以通过 Remote Desktop 直接登录,否则正如下图所示,即使在安装了最新版本 Remote Desktop 的 Windows XP SP3 上进行远程桌面访问还是会提示错误。(PS:不必惊慌而忙于通知相关人员在本地禁用 NLA。)

2

        要验证当前的 Remote Desktop Connection(RDC)是否支持 NLA(网络级别的身份验证),我们只需要打开 RDC,单击左上角的图标点击关于,我们便可以查看到当前 RDC 的版本及 NLA 信息。注意:当前的 Remote Desktop Connection 支持 RDP 6.1。

3 4

        其实在 Windows XP SP3 上启用 NLA 支持,并非难事。只需要对注册表进行修改即可,再执行下面的步骤前建议你先对注册表进行备份。

  1. 单击“开始”-“运行”,键入 regedit
  2. 定位至“HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa”,在右边窗体中双击打开“Security Packages”值,添入“tspkg
  3. 定位志“HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProviders”,在右边窗体双击打开“SecurityProviders”值,添入“, credssp.dll”,特别注意在英标逗号后面有一个空格

        在修改注册表后需要重新启动计算机,如果在未重启计算机前进行 RDP 的连接,会出现 Remote Desktop 的“0x507”错误。

5

        如果大家感觉很麻烦的话,gOxiA 制作了在 Windows XP SP3 上启用 NLA 的注册表脚本,只要在本机上双击导入即可,非常方便!出于安全角度考虑,如果你不希望别人知道你当前服务器的操作系统版本,不希望别人看到你启动前后的补丁安装进度,并且服务器正在使用 Windows Server 2008 操作系统,gOxiA 强烈建议启用 NLA 支持的 RDP。

下载:Enable Network Level Authentication

分页: 271/472 第一页 上页 266 267 268 269 270 271 272 273 274 275 下页 最后页 [ 显示模式: 摘要 | 列表 ]