本站域名：http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问：http://goxia.maytide.net/m转载文章，请务必保留出处与作者信息。否则，切勿全文照抄！未经许可严禁用于商业用途！
[Exchange] HOWTO:因 Exchange 2010 错误的角色安装顺序引发的 Outlook 访问故障
HOWTO:因 Exchange 2010 错误的角色安装顺序引发的 Outlook 访问故障
一个全新的 Exchange 环境，客户端访问服务器、集线器传输服务器、邮箱服务器分别安装到三台服务器上。在 Exchange 各角色部署完毕之后，在客户端计算机上分别用 Outlook Web App 和 Outlook 方式进行访问测试，结果发现 Outlook Web App 访问正常，而直接使用 Outlook 客户端配置用户时总是提示“到 Microsoft Exchange 的连接不可用，Outlook 必须处于联机或连接状态才能完成该操作。”
因为整个环境是参考 TechNet Librarys 的 Exchange Server 2010 安装指南模板 来执行的，应该是不会有什么错误，无奈看了看 客户端访问服务器的疑难解答参考 还真发现了问题。
如果在 Outlook Web App 中能打开邮箱，而 Outlook 客户端无法打开邮箱，可先用下列的 PowerShell 命令行验证服务器信息：
如果该命令输出的是邮箱服务器的名称，则安装客户端访问服务器角色和邮箱服务器角色的顺序可能有误。那么需要将 RPCClientAccessServer 的值设置为客户端访问服务器，而非邮箱服务器。（PS：微软官方的疑难解答参考中翻译存在错误，请注意！）命令参考如下：
最终结果可以参考下图：
当前邮箱数据库所对应的 RPCClientAccessServer 已经被指定为 CAS，重新测试访问恢复了正常。回忆了一下之前的安装顺序，是先安装的“邮箱服务器”后安装的“客户端访问服务器”，但是微软官方文档中也确实没有明确指出安装顺序的必要性！（PS：难道是我眼力劲不够……）总之最终是解决了问题，与大家分享一下。
[Exchange] 卸载 Exchange 角色时提示"有些控件无效 - 请指定要卸载的现有服务器"
卸载 Exchange 角色时提示“有些控件无效 - 请指定要卸载的现有服务器”
开始前先声明一小下，感觉这真不应该算是一个技术问题，但发现还真有不少朋友遇到过！当我们要卸载 Exchange Server 2010 角色服务时，可能会遭遇如下图的提示：
“有些控件无效 - 请指定要卸载的现有服务器角色”，其实这并不是什么故障，只是因为我们习惯了卸载时都是要勾选要卸在的组件，而在 Exchange Server 2010 中要卸载组件则需要清除掉勾选。而在操作页面中，向导也提示的非常清楚 - “清除要删除的服务器角色复选框”，只是大部分“习惯”了的朋友会忽略而已！
此外，Exchange Server 2010 的修改安装操作，与微软其他产品如：Office，还有一点不同：即，卸载和添加组件是分开独立的操作功能。如果选择更改，那么只能添加角色组件，而不能同时进行卸载选择。
OK，该问题简单说明一下，没什么可深入探讨的！不过到希望微软以后的产品能更加注意一下用户细节方面的体验！
[MDT] HOWTO:在 MDT 中启用 Windows Recovery
HOWTO:在 MDT 中启用 Windows Recovery
前面 gOxiA 与大家分享了一篇《HOWTO:在 MDT 中集成 DaRT》的日志，有不少网友也注意到在 MDT Welcome 界面中还包含了“Run the Windows Recovery Wizard”，感觉非常实用！试想，如果客户端本身就包含一份系统恢复映像，那么利用 Run The Windows Recovery Wizard 便能快速恢复系统。那么该如何在 MDT 中启用 Windows Recovery 呢？！
其实方法很简单，只需要将 Windows 7 光盘下的 boot.wim 替换掉 WAIK 的 winpe.wim 即可，替换前建议先做一下备份。WAIK 的 winpe.wim 默认安装存储位置在“C:＼Program Files＼Windows AIK＼Tools＼PETools”＼x86 或 amd64下。
替换完毕后，更新部署点重新生成 boot.wim 替换掉之前 WDS 已经添加的启用映像即可。
[Server Core] Windows Server 2008 R2 Server Core 常用命令
Windows Server 2008 R2 Server Core 常用命令
微软 TechNet Blogs – Support Tecnico Enterprise 为我们分享了一篇文章，汇总了 Windows Server 2008 R2 Server Core 的常用命令，gOxiA 感觉非常实用，不敢独享特转载至此与大家分享。
Server Core 的操作都是基于命令行来操作的，虽然默认界面中提供了一些常用的命令选项，但是这些命令选项显然不能满足我们的工作需求，而下面汇总的命令相信能够解决我们遇到的不少问题。
查看系统信息：
- Msinfo32
- Set
- Systeminfo
查看用户信息：
- Whoami
管理用户和用户组：
- Net accounts
- Net group
- Net localgroup
- Net user
查看或修改计算机名称：
- Hostname
- Netdom renamecomputer
加入或离开域：
- Netdom join
注销或关闭计算机：
- Logoff
- Shutdown
配置网络：
- Ipconfig
- Netsh interface
- Netsh routing
- Route
配置 Windows 防火墙：
- Netsh advfirewall
配置 Internet Protocol security (IPSec)：
- Netsh ipsec
- Scregedit.wsf
激活 Windows：
- Slmgr.vbs
管理服务：
- Net continue
- Net pause
- Net start
- Net Stop
- Sc
- Tasklist
管理进程：
- Taskkill
- Tasklist
- Taskmgr
管理任务：
- At
- Schtasks
收集和分析性能数据：
- Logman
- Relog
- Typeperf
查看事件和管理事件日志：
- Wevtutil
管理磁盘和存储：
- Compact
- Defrag
- Diskpart
- Diskraid
- Mountvol
管理卷影服务（Volume Shadow Copy Service – VSS）：
- Vssadmin
- Cacls
管理文件系统和文件权限：
- Convert
- Fsutil
- Icacls
- Takeown
管理文件：
- Openfiles
- Sigverif
管理共享和共享权限：
- Net share
管理注册表：
- Reg
- Regedit
安装和管理驱动程序：
- Driverquery
- Pnputil
- Sc
安装和管理更新补丁：
- Pkgmgr
- Scregedit.wsf
- Systeminfo
- Wuauclt
- Wusa
安装角色和功能：
- Oclist
- Ocsetup
安装应用程序（基于MSI）：
- Msiexec
管理组策略：
- Gpresult
- Gpupdate
- Secedit
管理证书：
- Certreq
- Certutil
管理终端服务（Remote Desktop for Administration）：
- Change
- Logoff
- Msg
- Mstsc
- Qappsrv
- Qprocess
- Query
- Qwinsta
- Reset session
- Rwinsta
- Shadow
- Tscon
- Tsdiscon
- Tskill
[MDT] HOWTO:在 MDT 中集成 DaRT
HOWTO:在 MDT 中集成 DaRT
DaRT 即 Diagnostics and Recovery Toolset，是 MDOP（Microsoft Desktop Optimization Pack）的核心功能组件之一。是微软针对 Windows 系统设计的一种高级检测和修复工具，其功能非常强大！富含了多个实用的功能，软件界面可以参考下图。
对于 ITPro 来说 DaRT 是一款非常实用的工具，过去我们需要单独刻录一张光盘来使用，而现在 DaRT 已经能够被集成到 MDT 中，这样我们将能够非常方便地通过网络来启动 DaRT！正如我们所看到的下图的场景一样，那么我们该如何将 DaRT 集成到 MDT 中呢？！其实方法很简单……
首先，您的 MDT 必须是 2012 版本（含 Beta，因为这是 MDT 2012 的一个新特性！），还要有一份 MDOP 的授权（如果 gOxiA 记得没错，Software Assurance 类型的 Windows Client 授权可免费获得 MDOP），也只有这样才能获得 DaRT 组件包。然后将 DaRT 的架构版本拷贝至 Deployment Share 的对应目录下，并在 MDT 中配置一下即可。具体细节可以参考下面的步骤：
- 拷贝不同架构（x86 or x64）的 Tools.cab 文件到 Deployment Share（即我们的部署点目录） 中 Tool 目录下对应的子目录中；
- 打开 Deployment Workbench；
- 在 MDT 控制器中展开“Deployment Shares”找到当前的部署点，并将其选中；
- 鼠标右键单击并点击“属性”；
- 在“Windows PE”选项卡下找到“Features”子选项卡；
- 在“Feature Packs”下复选“Microsoft Diagnostics and Recovery Toolkit (DaRT)”
上面操作完成后，确认退出。之后更新部署点（Update Deployment Share）会重新生成 MDT 的启用映像文件，最后将其重新添加到 WDS 的启动映像中，大功告成！找一台客户机通过 PXE 引导启动 MDT 就会看到在 Welcome 界面中的“Run DaRT Tools”。
[TMG] 解决 TMG 服务器日志报 ADWS ID1202 错误的问题
解决 TMG 服务器日志报 ADWS ID1202 错误的问题
Forefront Threat Management Gateway（TMG）2010 需要 ADAM 支持，因为它将配置信息都存储在 ADAM 中！所以在正式安装前需要执行“运行准备工具”，而这个阶段会根据用户的选择（安装”Forefront TMG 服务和管理”） 安装必须要的组件支持，如“Active Directory 轻型目录服务”即：AD LDS，用于存储 TMG 配置数据。
但是，在部署完 TMG 之后，我们会在“应用程序和服务日志”下的“Active Directory Web Services”中看到产生了很多的错误日志，如下图所示：
仔细查看日志，来源“ADWS”，事件ID“1202”，大致内容“现在该计算机正在托管指定的目录实例，但 Active Directory Web 服务无法为其服务。Active Directory Web 服务将定期重试该操作。……”
搜索了 Microsoft Support 未找到任何线索，考虑到本机未安装有 Web 服务，所以果断在“服务”管理器中将 Active Directory Web Services 服务禁用（sc config adws start= disabled）。重新启动 TMG 错误日志消失，系统和应用程序工作正常，未发现不良影响！至此问题解决！
[TMG] 解决因 TMG 配置数据不完整引发的 MMC 操作故障
解决因 TMG 配置数据不完整引发的 MMC 操作故障
最近遇到一个 TMG 故障，在使用 TMG 控制器进行配置操作时没有问题，但是保存时提示错误，仔细查看发现在规则列表中竟然有两个规则只有名称而没有其他配置信息，当去操作或查看时会报下面的错误截图，导致无法对 TMG 进行操作和修改。
回忆一下之前的操作，极有可能是因为两个管理员同时配置 TMG 在保存时，配置数据未能同步，从而引发了此故障问题。之后给微软开了 Case，提出了两个解决办法：
- 使用 TMG 光盘对安装进行修复。（PS：感觉这个解决办法风险太大，首先要暂停网络访问，而且可能会导致之前的规则丢失。）
- 直接操作 TMG 配置数据库，从数据库中删除不完整的规则。（PS：我个人认为这是一种可行的办法，但是直接修改 TMG 数据库的风险也很大，而且要找到规则对应的 GUID。）
最终选择了第二种解决方法，现在要解决两个问题：如何访问到 TMG 配置数据库；如何确认规则所对应的 GUID。前者，微软工程师给了连接到 TMG 配置数据库的方法，可参考 gOxiA 之前些的日志《使用 ADSI 访问 TMG 的配置数据库》。而后者，gOxiA 尝试导出 TMG 的规则，进行查看果然找到了规则对应的 GUID，如下图所示：
其中“StorageName”便是规则所对应的 GUID，而且知道规则隶属于“PolicyRule”，接下来参考《使用 ADSI 访问 TMG 的配置数据库》去操作 TMG 的配置数据库（ADAM），如下图所示：
展开 CN=FPC2，CN=Array-Root，CN-Arrays，CN=GUID，CN=ArrayPolicy，CN=PolicyRules。从字面上不难理解这些项的意思，但是其中 FPC2 表示 TMG 的配置数据库，而导出的规则文件中则为 FPC4，gOxiA 个人认为可能是微软为了区分数据等级，将 FPC2 认定为本机配置，FPC4 为备份配置。
由于 TMG 的 ADAM 无法查询或筛选，要从 PolicyRules 下找到其 GUID 也确实是件难事，gOxiA 用了一个比较笨的办法，就是先导出列表，然后使用带有标注行号的编辑器打开导出的列表文件进行搜索。一旦找到对应的 GUID 便根据位置靠上从上数的原则确定在第几行，然后再到 ADSI 中去定位！
最终结果当然是令人满意，未使用修复安装便解决了此故障！ 如果有遇到同样问题的朋友，可以借鉴一下，希望会有帮助！此外，建议对 TMG 有兴趣的朋友可以看一下《TMG Storage》这篇文章，有介绍 TMG 的配置存储机制。其中就讲到了 TMG 还会在注册表中缓存一份配置信息，如果要重建注册表中的配置缓存，可以使用下面的办法：
- 首先在 CMD 中执行如下命令行：reg add HKLM＼SOFTWARE＼Microsoft＼RAT＼Stingray＼Debug＼ISACTRL /v CTRL_MIXER_CACHE_BUILD_NEW_IN_NEXT_UPDATE /t REG_DWORD /d 1 /f
- 然后重启 TMG 服务
- 最后再在 CMD 中执行如下命令行：reg add HKLM＼SOFTWARE＼Microsoft＼RAT＼Stingray＼Debug＼ISACTRL /v CTRL_MIXER_CACHE_BUILD_NEW_IN_NEXT_UPDATE /t REG_DWORD /d 0 /f
