Category Archives: 操作系统

岳雷老师的文章读起来比较适合学习，先给大家转载两篇 大家看看先，看适不适合自己 以下内容摘自 http://yuelei.blog.51cto.com/202879/456647   Exchange2010迁移前的环境概述 很久没有发帖了，先向大家道个歉哈。最近几个月发生了很多事情，导致俺做了一个艰难的决定，离开学校，重新进入IT公司！其实目的很简单，就是为了获得技术一线的项目经验，想不到这俺这么一把年纪，30多岁高龄，居然又踏上了学习的征程，哈哈。 俺现在就任的公司是护航科技，项目锻炼的机会那是相当的多，非常适合希望快速成长的IT工程师。现在为公司做个广告，希望大家不要拍砖哈，有意来公司发展者，可以访问www.lenovots.com，免费浏览，童叟无欺！ 去了护航之后，被派驻客户公司。客户也是大名鼎鼎的金融企业，具体名称保密，大家也不要好奇啊。工作一段时间后，积累了很多的项目心得，非常希望分享给大家。因此计划推出项目实践系列博文，希望能对大家的实际工作起到一些指导作用。这些系列包括Exchange迁移系列，TMG2010升级系列，Forefront Client Security系列，还有System Center系列，MDT系列等等。今天先从Exchange系列开始，介绍如何从Exchange2003迁移到Exchange2010     。 Exchange是大家非常熟悉的微软服务器产品，在很多企业都有着相当多的用户。Exchange的最新版本已经发展到了Exchange2010，增加了很多实用功能。很多使用老款Exchange产品的用户开始考虑产品的升级换代问题，希望在老款Exchange产品生命周期结束时，可以把邮件服务迁移到一个更高更快更强的Exchange平台上。          公司现有的Exchange环境是这样的，一共四台Exchange2003服务器，一台是Exchange前端，三台是Exchange后端。Exchange服务器当前支持4000左右用户，用户数量计划会增加到5000。计划把当前的Exchange2003迁移到四台Exchange2010服务器上，两台Exchange2010承担的角色是CAS/HUB，还有两台Exchange2010服务器承担Mailbox角色。现在暂时不考虑部署边缘服务器，在CAS/HUB服务器上承担反垃圾邮件的工作，正常情况下这项工作应该是由边缘服务器来完成的。          下图是我搭建的一个测试环境，我将在这个环境中为家介绍迁移过程。其实公司有一个更逼真的测试环境，逼真到什么程度？AD数据和现有的生产系统是完全一样的，所有的用户账号都有，服务器使用的存储，CA系统都模拟得很逼真，可惜我不太方便用这套环境为大家演示，因此只能回家又搭建了一套环境，好在关键的技术要点都会为大家介绍到，大家不用担心。          这个测试环境和实际环境相比进行了简化，例如Exchange2003我在测试环境中只安排了两台，一台是前端，一台是后端。Exchange2010倒是安排了四台，CAS/hub两台，Mailbox两台。测试的目标是把Exchange2003上的用户邮箱迁移到Exchange2010服务器，保护用户在内网和外网都可以正常访问自己的邮箱。          大致的迁移思路是这样的，Exchange2003是32位系统，Exchange2010是64位系统。因此Exchange服务器不可能使用就地升级的方法更换邮件平台，只能使用迁移的方法把Exchange2003的邮箱迁移到Exchange2010，然后再删除Exchange2003。为什么要安排两台服务器负责CAS/HUB角色呢？因为Exchange2010的体系结构和Exchange2003发生了很大变化，用户不允许直接连接到Exchange的邮箱服务器，用户必须先连接到Exchange的CAS服务器，通过CAS服务器再去连接后端的Exchange邮箱服务器。那这样的话大家就要想了，万一这唯一的一台CAS服务器挂了，那后果是什么？这还用想，肯定是你也要挂了…..哈哈，这是开玩笑的。就是考虑到不希望这种灾难场景出现，因此需要利用两台CAS/HUB服务器实现负载平衡。同样的道理，邮箱服务器也要有高可用，不能只设计一台邮箱服务器。恰好Exchange2010支持DAG技术，我们可以用较小的代价实现邮箱存储的高可用。          环境大致就介绍到这儿，下篇将为大家介绍如何进行Exchange2010的迁移前准备工作。

以下文章摘自 http://alligator.blog.51cto.com/36993/107174 概述：     组策略是Win2003操作系统提供的一种重要的更新和配置管理技术，用来批量控制计算机和用户的环境，包括控制应用程序、系统设置和管理模板的一种机制。在AD域环境中，通过组策略可以对计算机和用户组进行高效集中化的管理。组策略是AD域环境最有吸引力的基础架构应用之一，正确高效组策略应用可以最大化提高工作效率，节约大量时间和精力。但如果部署了不正确的组策略，排错过程往往会使人抓狂。本文不涉及具体组策略部署方法以及如何排错案例，仅就AD域环境中客户机处理组策略的流程做一详细分析。相信正确理解和掌握组策略内部处理流程，会对组策略部署以及组策略排错有相当大的帮助和参考。   一：简述客户端计算机处理组策略流程     简单的说，客户机应用组策略的流程有以下几个步骤：        1：客户机启动，执行本地安全策略。        2：客户机连接到网络，查询DC获取要应用的GPO列表。        3：客户机根据GPO列表连接到Sysvol文件夹定位对应的组策略模板。        4：客户机根据组策略模板中信息执行相应的操作。        5：计算机策略执行完成后，出现登录界面，用户登录。        6：用户验证通过后，用户查询DC获取要应用的GPO列表。下面执行步骤与计算机执行步骤类似。         客户机组策略处理基本流程如上所述，其中忽略了某些可能性如：环回设置，同步/异步处理，安全组筛选，WMI筛选等，因对基本流程影响不大，此处略过。有兴趣请见后续文章。      上述流程并不复杂，但其中存在一些细节需要深入了解，也是自己当初学习组策略时一直存在的疑问。比如：         1：客户机如何从DC上获取要应用的GPO列表         2：客户机如何可以根据GPO列表，定位到Sysvol文件夹定位对应的组策略模板。         3：客户机如何可以正确的处理每个组策略设置         4：按MS说法,客户机与DC失去联系，客户机会使用本机缓存的组策略，那么组策略本地缓存保存在客户机什么位置？     下面就上述疑问做尽可能的分析，希望能给其他朋友带来参考，因有些结论是实验测试结果，可能会存在某些不当之处，如有异议，欢迎讨论!   二：客户机如何获取应用的GPO列表     我们知道,DC启动时，会向DNS宣告自己的角色，DNS服务器接受宣告后，更新DNS数据库中DC对应的资源记录。客户机登录时会联系DNS服务器，寻找适当的DC进行身份验证。验证通过后，DC告诉客户机所属的站点信息，域信息，以及OU信息。客户机获取到这些信息后，就可以查询到正确的GPO列表。之所以拥有站点，域，OU信息后就可以获取GPO列表信息，主要是因为站点，域和OU对象的gPlink属性中保存有GPO链接信息。     … Continue reading →