企业中经常需要导出群组中的用户清单，在ADUC中只能导出OU的用户，
可以通过下面的脚本，导出群组中的成员清单
Set objGroup = GetObject("LDAP://CN=testgroup,DC=contoso,DC=com")
objGroup.GetInfo
arrMemberOf = objGroup.GetEx("member")
For Each strMember in arrMemberOf
Set objUser = GetObject("LDAP://" & strMember)
objUser.GetInfo
WScript.Echo objUser.Displayname & "," & objUser.Department
Next
posted @
2008-12-05 10:59 joyclear 阅读(2289) |
评论 (0) |
编辑 收藏
Push Mail是BlackBerry提出的名词，在Exchange中其实叫ActiveSync(邮件直推)
邮件直推的设计宗旨是为了通过无线网络连接使移动设备保持最新状态。
最早引进邮件直推技术是Exchange 2003 SP2版本
要使用直推技术，需要如下条件的设备支持：
1.Windows Mobile 5.0和Messaging & Security Feature Pack (MSFP)及更高版本的Mobile移动电话。
2.由ActiveSync许可兼容直推技术的移动设备。
Exchange 2003 SP2中，默认功能没有开启，在Exchange2007中，默认已经开启直推技术。
直推技术的原理：支持直推技术的移动设备将向Exchahnge服务器发出
长期的HTTPS请求。Exchange服务器监视用户邮箱的活动，并在有任何更改时向设备发送响应。设备向服务器发出同步请求。完成同步后，将生成新长期HTTPS请求，以便再次开始该过程。
直推技术依赖与支持长期HTTPS请求的网络条件。如果移动设备的运营商网络或防火墙不支持长期的HTTPS请求，则会停止HTTPS请求。
同时在移动运营商防火墙还会有超时值的设定，这个值决定长期HTTPS请求的发送周期，直推技术会依据运营商的超时值，自动判定最佳的发送周期
posted @
2008-12-03 17:44 joyclear 阅读(1532) |
评论 (1) |
编辑 收藏
从您的描述中，我理解到您想一次性永久删除所有的 Disconnected Mailbox
如果我理解错了，请告诉我
您可以尝试下面的方法：
a. 打开 Exchange Management Shell,
b. 运行下面的命令:
$store= Get-MailboxDatabase "<server_name>\<Storage_Group_Name>\<Mailbox_Database_name>"
注释：这条命令将Exchange的数据库文件赋给了变量“$store"”
请将"<server_name>\<Storage_Group_Name>\<Mailbox_Database_name>"替换为您环境中的真实名字。
c. 继续运行下面的命令：
Get-MailboxStatistics -database $store | where {$_.disconnectdate -ne $null} |
foreach {remove-mailbox -database $store -storemailboxidentity $_.mailboxguid}
注释：这条命令将会将这个“$store”中所有的Disconnected Mailbox删除掉
posted @
2008-12-03 12:37 joyclear 阅读(884) |
评论 (0) |
编辑 收藏 下午四点赶往陆家嘴，解决客户Exchange群集问题，问题倒不是很紧急，但是客户环境比较特殊，只能在非工作时间解决，看来今天又要加班咯～～～
1.客户邮件服务器是Exchange 2003 Cluster, 群集资源中Exchange HTTP Virtual Server Instance 100 资源不能启用，导致用户无法访问OWA页面。
在日志中有MSExchangeCluster 1013等报错信息
事件描述：
Event Type: Error
Event Source: MSExchangeCluster
Event Category: Services
Event ID: 1013
Date: 25/80/2005
Time: 9:16:44 AM
User: N/A
Computer: exchange1
Description:
Exchange HTTP Virtual Server Instance 100 (exchange1): Failed to get the
protocol IP address and port bindings from the metabase.
打开IIS，里面虚拟服务器是停用状态，因为用户是比较重要的生产环境，所以暂时没有做任何操作，开始检查日志，Cluster日志，应用程序日志，系统日志，然后查EventID,微软KB。 看起来IIS元数据损坏的可能性比较大。
突然从网上找到一篇BBS, 里面的问题和现在问题一样，里面提到了This problem can be caused by the HTTP Virtual Server not having an SSL port defined when we are requiring SSL.
立刻检查IIS里面SSL端口定义，果然是空值。输入443, 应用设定。重新启用群集中HTTP资源，服务正常启动了。
OWA页面正常开启。hoho~~， 万幸，还好不是IIS元数据库问题，否则今天加班到几点还是问题，万恶的加班啊～～～，万恶的加班又没有加班费啊～～～～
2.问题提前解决，时间充裕，那就继续解决客户的其它问题，客户反应DC服务器上周期出现Userenv 1054错误，组策略无法下发。
事件描述：
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 3/12/2008
Time: 8:42:38 AM
User: NT AUTHORITY\SYSTEM
Computer: ServerName
Description:
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.
经过检查，不光DC上有，多台成员服务器上也有这个现象。
这个问题以前也多次见过，一直没有好好解决。
看了EventID，很多人都说这个问题和硬件有关。继续查找资料～～
功夫不负有心人啊，总算找到篇有用的资料，说明问题和AMD CPU有关，AMD有Fix程序可以解决。
打开服务器硬件属性，果然都是用的AMD的CPU，看来问题有眉目。
接下来的工作就交还给客户了，请他明天先联系下HP，看下HP的Case记录里面是否对这个错误有解决方案，如果确实是CPU的问题话，应该HP会碰到很多类似问题。
Just thought I'd throw this in here. Spent a bunch of time researching this, finally decided to call MS.
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 3/12/2008
Time: 8:42:38 AM
User: NT AUTHORITY\SYSTEM
Computer: ServerName
Description:
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.
-------------------------------------------------------
We were getting this on a bunch of new servers, all running Win2003 R2 64bit. It's also showing up on a number of XP machines. Finally decided to just open a ticket with MS.
The problem is apparently a "slow link detection", which is of course abundantly obvious from the errors. Per MS, we did the following reghacks:
Registry subkey: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System
Value name: GroupPolicyMinTransferRate
Value type: DWORD
Value Data: 0
Registry subkey: HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System
Value name: GroupPolicyMinTransferRate
Value type: DWORD
Value Data: 0
Note: if the "System" key doesn't exist, please create it under HKCU\Software\Policies\Microsoft\Windows & HKLM\Software\Policies\Microsoft\Windows first.
From the MS tech support rep:
"It is possible that certain firewall program (such as Windows Firewall) is installed on all your machines and configured to block the normal ICMP packets. Sometimes it may be also caused by some models of CPU.
For example, there is a known bug with AMD Opteron Processor driver for Windows XP and Windows Server 2003 Version (x86 and x64 exe) 1.3.2.16, which allows the system to automatically adjust the CPU speed, voltage and power combination that match the instantaneous user performance need. The slow link detection depends on the CPU clock to calculate the speed. However, it may fail when working along with AMD Opteron driver. Recently we have received many reports that this known bug in the AMD CPU driver often causes the group policy detection failure. AMD has provided a new version of driver to solve such similar problems. You can get this point from:
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_9033,00.html"
All our new servers are 64-bit Opterons. We haven't upgraded the driver yet.
posted @
2008-12-02 23:14 joyclear 阅读(914) |
评论 (0) |
编辑 收藏
今天又把笔记本装回XP了，Vista用了还是不习惯，而且C盘20G分区，没多少时间就差不多满了，增长太快
安装好office 2007后，发现输入的CDkey不能激活，想要重新输入CDkey，却发现office没有提供这个功能
网络上搜寻了一下，使用注册表，
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\12.0\Registration\{91120000-0011-0000-0000-0000000FF1CE}删除下列二个健
DigitalProductID
ProductID
重新开启office后，就会提示输入CDkey的界面了
posted @
2008-11-11 15:54 joyclear 阅读(793) |
评论 (0) |
编辑 收藏
您希望通过repadmin这个命令来检查已经被删除用户的信息，比如删除时间以及操作时的DC等，如果我的理解不正确，请您告诉我！
通过repadmin来检查已经被删除用户的信息：
1. 用域管理员登录DC
2. 开始－运行ldp.exe
3. Connection－connect
4. Bind－OK
5. View－OK
6. Options－controls，在Load选项中选择Return deleted object－OK
7. 展开左边区域中的DN，找到CN=Deleted Objects,DC=ibm,DC=com这个目录并展开（存在tombstone记录中的对象）
8. 在列表中找到您之前删除的用户，双击打开列表
9. 找到该删除账户的DN，如CN=jason\0ADEL:e0272381-ecc9-4391-86e7-4afc9e73b4fe,CN=Deleted Objects,DC=ibm,DC=com，复制下来
10. 开始运行 cmd
11. 运行repdamin /showmeta “CN=jason\0ADEL:e0272381-ecc9-4391-86e7-4afc9e73b4fe,CN=Deleted Objects,DC=ibm,DC=com” 回车后您会看到下面的信息
27 entries.
Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= === =========
20498 Default-First-Site-Name\DENVER 20498 2008-11-10 11:59:26 1 objectClass
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 cn
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 sn
20498 Default-First-Site-Name\DENVER 20498 2008-11-10 11:59:26 1 instanceType
20498 Default-First-Site-Name\DENVER 20498 2008-11-10 11:59:26 1 whenCreated
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 displayName
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 1 isDeleted
20502 Default-First-Site-Name\DENVER 20502 2008-11-10 11:59:27 2 nTSecurityDescriptor
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 name
20504 Default-First-Site-Name\DENVER 20504 2008-11-10 11:59:27 4 userAccountControl
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 codePage
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 countryCode
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 3 dBCSPwd
20499 Default-First-Site-Name\DENVER 20499 2008-11-10 11:59:27 1 logonHours
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 3 unicodePwd
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 3 ntPwdHistory
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 3 pwdLastSet
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 primaryGroupID
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 supplementalCredentials
20498 Default-First-Site-Name\DENVER 20498 2008-11-10 11:59:26 1 objectSid
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 accountExpires
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 3 lmPwdHistory
20498 Default-First-Site-Name\DENVER 20498 2008-11-10 11:59:26 1 sAMAccountName
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 sAMAccountType
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 userPrincipalName
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 1 lastKnownParent
20505 Default-First-Site-Name\DENVER 20505 2008-11-10 12:00:16 2 objectCategory
0 entries.
Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver
======= ============ ============= ================= ======= ======= ===
Distinguished Name
=============================
12. 在Ver Attribute这个属性下，你可以找到isDeleted这个属性，该属性对应的信息就是用户帐号的删除时间和操作的服务器信息
希望我的回答对您有所帮助，如果有不清楚的地方，请告诉我。
感谢您选择微软产品并使用微软合作伙伴新闻组技术支持！
Jason Hou 侯铮
MCSE 2003＋Security
在线合作伙伴支持工程师
合作伙伴支持部
微软全球技术支持中心
posted @
2008-11-10 17:35 joyclear 阅读(3308) |
评论 (3) |
编辑 收藏 正好要写个AD域合并的方案，手头缺少些环境截图，索性做个ADMT 的迁移测试，后面还会写个Quest migration manager做迁移的，做个比较
一. 虚拟环境
Target Domain
Domain Name： Msft.Local (windows 2003)
IP Address：192.168.0.1
Source Domain
Domain Name：leaderit.com (windows 2003)
IP Address：192.168.0.100
Client PC
Name: Client
IP Address：192.168.0.200
建立帐号和群组，共享资源
二. 迁移流程
ADMT 3.0可以实现三种环境的迁移
1.Windows NT 4.0 Domain Restructure to an Active Directory Forest
2.Interforest Active Directory Domain Restructure
3.Intraforest Active Directory Domain Resturcture
其中在Interforest和Intraforest中还是有一些区别的
主要一点是Interforest里面对象是克隆，而在Intraforest里面对象是移动
|
Migration Consideration
|
Interforest Restructure
|
Intraforest Restructure
|
|
Object preservation
|
Objects are cloned rather than migrated. The original object remains in the source location to maintain user access to resources.
|
Objects are migrated and no longer exist in the source location.
|
|
SID history maintenance
|
Maintaining SID history is optional.
|
SID history is required.
|
|
Password retention
|
Password retention is optional.
|
Passwords are always retained.
|
|
Local profile migration
|
You must use tools such as ADMT to migrate local profiles.
|
For workstations that run the Microsoft Windows®°2000 Server operating system and later, local profiles are migrated automatically because the user’s GUID is preserved. However, you must use tools such as ADMT to migrate local profiles for workstations that run Windows NT 4.0 and earlier.
|
|
Closed sets
|
You do not need to migrate accounts in closed sets.
|
You must migrate accounts in closed sets.
|
整个迁移的流程图
三. 迁移前期工作
target域需要Windows 2000或者Windows 2003域功能级别
建立source和target之间的域信任关系
关闭SID Filter, 默认在Windows 2000 SP4以上及Windows2003启用了SID Filter, 在迁移过程中，为了让用户可以正常原有资源，我们需要迁移SID Histrory.
在命令行中通过netdom命令关闭SID Filter
将目标域的Domain Admins群组加入到Source administrators群组
以下三个步骤可以在ADMT第一次运行时由ADMT自动创建
1.在source域中创建source_name$$$本地群组
2.在source PDC角色上开启TCP/IP Client Support功能
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\LSA
TcpipClientSupport DWORD 1
3.在target和source域上开启审核
Group Policy-Default Domain Controllers Policy-Computer Configuration-Windows Settings-Security Settings-Local Policies-Audit Policy
Audit accout management Success,Failure
四.安装ADMT
在target domain controller上安装ADMT 3.0 (ADMT 3.1支持Windows 2008)
ADMT3.0需要数据库支持，无论是采用SQL还是WMSDE，默认都会在本地安装WMSDE。
五.启用密码迁移
森林之间迁移使用PES(Password Export Server)服务来迁移密码，PES服务可以安装在source域的任何DC上(支持128位加密，Windows 2003，2000+sp3以上默认支持)。
安装PES服务首先需要一个加密钥匙，这个加密钥匙在target域安装ADMT的机器上创建
admt key /option:create /sourcedomain:<> /keyfile:<>/keypassword:<>
在source域DC上启动PES服务，需要安装ADMT,
执行%systemroot%\windows\ADMT\PES\pwdmig.msi
导入刚才在target域导出的加密钥匙
输入服务帐号，建议使用在target域中验证的帐号，如果使用本地系统帐号，确保在target域中，Pre windows 2000 compatible access group中包含everyone group和Anonymous logon group
在services里面启动PES服务
六.正式迁移
按照ADMT迁移文档的建议，共享文件资源，采用Users->Global Groups->Local Domain Groups->Permission的方式
迁移帐号顺序：Services Account-->Global Group-->User Account
迁移user account步骤：
1.迁移所有帐号，选择不更新现有用户密码，生成复杂密码
禁用目标帐户，将用户SID迁移到目标域
转换漫游配置文件
2.转换用户profile
安全性转换向导，先前迁移的对象
用户配置文件
替换安全性引用
3.迁移工作站
选择工作组和拥护权利
选择添加
迁移代理
4.再次迁移帐号
迁移密码
启用目标帐户
转换漫游配置文件,更新用户权利,修复用户的组成员身份
迁移并合并冲突的对象
5.再次迁移所有全局组
迁移完成后,使用用户帐号登陆,桌面一切都正常, 结果访问源域共享资源竟然提示不能访问, 奇怪
步骤都是按照help的文档
使用Adsiedit.msc检查帐号和群组的SIDhistory属性，都已经迁移过来
通过Windows Resource Kit工具检查
WhoamI /All, SIDhistory也已经存在
用户信息
----------------
用户名 SID
========== ============================================
msft\user1 S-1-5-21-921174561-3067888446-272819519-1113
组信息
-----------------
组名 类型 SID 属性
================================ ====== ============================================== ==============================
Everyone 已知组 S-1-1-0 必需的组, 启用于默认, 启用的组
BUILTIN\Users 别名 S-1-5-32-545 必需的组, 启用于默认, 启用的组
NT AUTHORITY\INTERACTIVE 已知组 S-1-5-4 必需的组, 启用于默认, 启用的组
NT AUTHORITY\Authenticated Users 已知组 S-1-5-11 必需的组, 启用于默认, 启用的组
NT AUTHORITY\This Organization 已知组 S-1-5-15 必需的组, 启用于默认, 启用的组
LOCAL 已知组 S-1-2-0 必需的组, 启用于默认, 启用的组
MSFT\Global Group1 组 S-1-5-21-921174561-3067888446-272819519-1111 必需的组, 启用于默认, 启用的组
MSFT\user1 用户 S-1-5-21-4123853966-2211756669-3874129515-1108 必需的组, 启用于默认, 启用的组
MSFT\Global Group1 组 S-1-5-21-4123853966-2211756669-3874129515-1112 必需的组, 启用于默认, 启用的组 (SIDHistory)
特权信息
----------------------
特权名 描述 状态
======================= ============ ======
SeChangeNotifyPrivilege 跳过遍历检查 已启用
从网上翻了下资料，有说到SID Filter开启会导致资源不能访问这个情况，可以明明我已经作过了关闭SID Filter命令了
再仔细看看我前面做的Netdom trust命令，突然想到，是不是原来做的时候源域和目标域的方向反了
重新执行命令。
netdom trust leaderit /domain:msft /quarantine:no /userd:administrator /passwordd:pass01!
这下问题解决，可以正常访问源域的共享资源了
posted @
2008-11-10 16:34 joyclear 阅读(4354) |
评论 (2) |
编辑 收藏一.电脑更改名称
1.Netdom RenameComputer machine /NewName:new-name
2.WMIC ComputerSystem Where Name="%COMPUTERNAME%" Call Rename Name="NewName"
二.加入网域
1.Netdom Join machine /Domain:domain
2.WMIC ComputerSystem Where Name="%COMPUTERNAME%" Call JoinDomainOrWorkgroup Name="NameOfWorkgroup"
三.远程终端连接
1.cscript c:\windows\system32\ScRegEdit.wsf /AR [/v][value]
/v 查看远程终端服务连接设置
value <0=启用，1=禁用>
2.WMIC RDToggle Where ServerName="%COMPUTERNAME%" Call SetAllowTSCConnections AllowTSConnections="1"
四.允许以前版本的windows远程终端连接
cscript c:\windows\system32\ScRegEdit.wsf /CS [/v][value]
/v 查看终端服务CredSSP设置
value <0=允许以前版本，1=要求CredSSP>
五.开启共享
Net Share sharename=driver:path [/Grant:user,[Read | Change | Full ]]
六.打开帮助文件
winhelp.exe可以打开HLP类型的帮助文件
CHM类型文件在Server core中无法开启，需要HTML Help(HH.exe)开启
七.自动更新
1.Cscript %systemroot%\system32\SCRegEdit.wsf /AU 4
2.Net Start WUAUServ 只启动当前运行进程
posted @
2008-10-17 14:57 joyclear 阅读(340) |
评论 (0) |
编辑 收藏参考自Exchange 2007 连续复制白皮书：http://technet.microsoft.com/zh-cn/library/cc535020(EXCHG.80).aspx
一。在Exchange 2007 SP1中，有三种连续复制形式
LCR本地连续复制
CCR群集连续复制
SCR备用连续复制
二。在简单的环境中，连续复制运行下列步骤：
1. 通过对源数据库的一份拷贝播种建立目的数据库
2. 通过windows文件系统提示事件，监控源数据库日志目录准备复制的新日志文件
3. 复制新的日志文件到目的检验日志目录
4. 检验已复制的日志文件
5. 通过成功检验，移动已复制日志文件到存储组日志路径，重播日志文件到数据库
三。复制组件
二个关键的组件负责日志产生，日志传送，和日志重播。
Microsoft Exchange Information Store Service
负责用户和应用程序请求服务，执行日志写入，和通过Extensible Storage Engine (ESE)更新数据库文件
Microsoft Exchange Replication Service
复制日志传送和重播日志
A。Information Store Service功能
下面的步骤当在数据库中发生数据检索，插入和更改时由ESE来执行
1. 在数据库上发生一个操作(用户发送一封新邮件)，数据库中需要更新的页面读取到ESE缓存中(假定这个页面之前在内存中不存在)，当日志缓冲区得到提示，开始记录中内存中发生的操作。
2. 数据库引擎记录发生的变化但是这些变化并不马上写入到数据库文件。相反的，这些变化保存在ESE缓存中，因为这些页面没有提交到数据库文件，所以称之为 dirty pages 。Version Store被用来追踪这些变化，因此确保隔离性和一致性得到维护
3. 当数据库页面有变化，日志缓冲区得到提醒去递交变更，处理结果记录到交易日志文件，这些操作有可能需要关闭当前Exx.log文件，重新创建一个新的日志文件(ESE也负责响应当一个日志文件达到最大容量(1MB)后，关闭文件然后重新产生一个新的日志文件)。
4. 最后dirty 数据库页面写入到磁盘上的数据库文件
5. 检查点向前
B。Replication Service功能
当连续复制功能启用，Exchange Replication Service负责侦测当前日志文件是否被ESE关闭，复制日志文件，检验和重播到副本数据库。这个服务默认安装在邮件服务器角色上。
Replicaton Serice的执行文件是Microsoft.Exchange.Cluser.ReplayService.exe, 路径在exchange安装目录\bin 。Replication服务依赖于Exchange Active Directory Topology服务。
Replication服务日志诊断
HKEY_L_M\System\CurrentControlSet\Services\MSExchange Repl\Diagnostics
Get-EventLogLevel -Identity "MSExchange Repl" or Set-EventLogLevel -Identity "MSExchange Repl" -Level High
C。Replication服务组件
LogCopier：负责复制已关闭日志文件，从源存储组到副本存储组。在Replication服务持续监视源存储组日志目录中这是一个异步操作。它通过订阅windows文件系统提示事件来监视。当事件提示Replication服务有一个新的文件存在，LogCopier将复制日志文件到目的服务器检验目录
LogInspector：负责检验日志文件是否正确，它通过基本的规则在检验目录中检验，如果一个日志文件发现是错误的或者不能被重播，Replication服务将重新复制日志文件。
LogReplayer：负责重播已检验文件到副本数据库
LogTruncater：负责删除已经成功重播到副本数据库的日志文件。这个组件非常重要，因为通常在全备或增量备份后，在检查点后的日志文件被删除，因为日志记录认为这些日志已经写入到数据库。当连续复制使用时，LogTruncator仅仅删除不需要恢复和重播的日志。任何在活动副本上没有被复制和重播到数据库副本的日志文件不会被在线备份清除。
Incremental Reseeder：负责确保当数据库恢复被执行时，或者当CCR环境中发生故障转移时，活动数据库和副本数据库不会分叉。
Seeder：负责创建存储组基本内容用于开始重播进程，Replication服务为新存储组，以及已存在的存储组(包含日志文件)执行自动播种。
Replay Manager：负责持续追踪所有的复制实例。基于存储组的在线状态，按需求创建和撤销复制实例。复制实例被特意设置为静态，因此，当一个复制实例配置更改，复制将应用新的配置重新启动。此外，当Replication服务被关闭，复制实例配置不会被保存。为此，每次Replication服务启动时，包含空复制实例列表，在启动期间，Replay Manager发现当前在线的存储组，创建"运行中的实例"列表。
Replay Manager周期性运行"配置更新"线程，扫描新的已配置复制实例。配置更新线程在LCR,CCR环境中每30秒运行一次，在SCR环境中，3分钟运行一次。它将在当前数据库状态上建立和破坏复制实例(取决于数据库是在线还是离线)。配置更新线程使用以下的算法：
1.从AD中读取实例配置
2.对比从AD中发现的配置，如果不匹配，实例进入重启队列
3.
4.停止在停止队列中的运行实例
5.启动在启动队列中的实例
因此，Replay Manager总是有动态的复制实例清单
Replication Serivce配置信息
每个启动LCR的存储组和存储都有msExchHasLocalCopy属性定义。Replication Service使用以下的算法去搜寻AD中的复制信息
1.在AD中使用计算机名称寻找Exchange Server对象，如果没有服务器对象，返回。
2.在找到的Exchange服务器上，枚举所有的存储组
1.每个msExchHasLocalCopy属性设定为真的存储组，检索系统文件，日志文件，和数据库文件的源目的路径。
在CCR环境中，Replication Service执行下列任务去检索集群的邮箱服务器配置
1.建立一条连接到集群数据库
2.判断哪个节点拥有集群邮箱服务器
3.枚举在源和目标节点上的所有存储组
A.系统文件，日志文件和数据库文件的源目的路径
B.返回存储组的最后拥有者
C.用于日志传送的网络共享空间
D.AutoDatabaseMountDial设定
E.ForcedDatabaseMountAfter设定
F.确定日志传送的网络路径
4.检验在源上的配置和目标上的一致
在SCR环境，复制服务使用msExchStandbyCopyMachines属性去判定哪个存储组启用复制，然后执行下列任务
posted @
2008-10-09 00:36 joyclear 阅读(644) |
评论 (0) |
编辑 收藏1.Server Core中检查当前Roles安装命令： oclist
Oclist | find “Installed” | find /v “IIS”
2.Server Core中安装Roles命令： ocsetup
例如：ocsetup DNS-Server-Core-Role , 注意这里的Role名字有区分大小写，名字要符合oclist中显示的名称
3.更改Server Core 的屏幕保护设置。Server core 在空闲10分钟后开始运行logon.scr。
影响屏幕保护设置的注册表键值如下：
HKEY_CURRENT_USER\Control Panel\Desktop\ScreenSaveActive
HKEY_CURRENT_USER\Control Panel\Desktop\SCRNSAVE.EXE
HKEY_CURRENT_USER\Control Panel\Desktop\ScreenSaverIsSecure
HKEY_CURRENT_USER\Control Panel\Desktop\ScreenSaveTimeOut
要禁用屏保，将下面的键值从1改为0即可。
HKEY_CURRENT_USER\Control Panel\Desktop\ScreenSaveActive
要更改屏保通过更改下面的键值：
HKEY_CURRENT_USER\Control Panel\Desktop\SCRNSAVE.EXE
在缺省情况下，该值读%windir%\System32\logon.scr（Windows Logos）
4. Server Core输入产品序列号
cscript c:\windows\system32\slmgr.vbs -ipk <产品密钥>
cscript c:\windows\system32\slmgr.vbs -ato 激活windows
cscript c:\windows\system32\slmgr.vbs -dli 显示许可证信息
cscript c:\windows\system32\slmgr.vbs -dlv 显示详细许可证信息
5.SCregEdit.wsf
cscript SCregEdit.wsf /AU [/v] [value] 自动更新
/v 查看自动更新设定
4-启用自动更新
1-禁用自动更新
Net Start WUAUServ
cscript SCregEdit.wsf /AR [/v] [value] 终端服务
0-启用
1-禁用
posted @
2008-10-08 10:59 joyclear 阅读(409) |
评论 (0) |
编辑 收藏