微软产品支持分析电子月刊 : Hot Issue

残留公共文件夹复制导致无法卸载Exchange 2007

Support News Editor — Tue, 26 Jun 2007 05:44:00 GMT

当您想要卸载Exchange 2007时，可能会遇到错误信息提示您这台服务器仍然存有公共文件夹，并且导致整个卸载过程失败。我们最近收到了很多此类问题的报告。这个问题的原因是Exchange 2007服务器仍然存有某些公共文件夹的复制。我们必须移除这些复制并且删除公共文件夹存储以使卸载可以正常进行。

详细的移除复制并且删除公共文件夹存储的步骤可以在以下文章中找到:

How to remove Exchange 2007 from a computer

http://support.microsoft.com/kb/927464/zh-cn

Exchange 2003和Exchange 2007之间的公用文件夹复制问题

Support News Editor — Tue, 26 Jun 2007 05:35:00 GMT

最近我们看到很多Exchange 2003和Exchange 2007之间的公用文件夹复制问题. 当发生这个问题时会有下列现象:

1. Exchange 2007的邮箱无法看到Exchange 2003上的公用文件夹

2. 公用文件夹复制邮件全部堵塞在Exchange 2003上的Messages with an unreachable destination队列

3. 在Exchange 2003服务器上,你可能会看到下面这个事件:

Event Type: Warning

Event Source: MSExchangeTransport

Event Category: Routing Engine/Service

Event ID: 951

Description:

When sending mail to following address exchange2007name.domain.com.5B2DCAE3-0882-1148-8DEB-B36F641F9E2B, we have found the connector with target domain *.5B2DCAE3-0882-1148-8DEB-B36F641F9E2B matching destination address exists in DS. However, we have no way of getting there. Possibly, you need to check your topology and add appropriate connectors among Routing Groups.

这个问题发生的原因是在Exchange 2007 路由组和Exchange 2003 路由组之间没有Routing Group Connector. 在Exchange 2007安装时,会有个选项要求你选择Exchange 2000/2003 Routing Group Connector桥头堡服务器. 假若你跳过这个选项, 系统就不会帮你自动创建Routing Group Connector.

注意第一个Routing Group Connector 只会在安装第一个Exchange 2007 Hub Transport Server 角色时创建.

要解决这个问题,你可以用Exchange Management Shell手工创建Routing Group Connector. 例如,下面的例子可以创建一个cost是100,允许public folder referrals的Routing Group Connector:

New-RoutingGroupConnector -Name "Interop RGC" -SourceTransportServers "Ex2007Hub1.contoso.com" -TargetTransportServers "Ex2003BH1.contoso.com" -Cost 100 -Bidirectional $true -PublicFolderReferralsEnabled $true

在Windows Server 2003上使用DNS控制台失败

Support News Editor — Tue, 29 May 2007 09:36:00 GMT

当您尝试用Windows Server 2003的DNS管理界面(Dnsmgmt.msc)连接到DNS服务器时，连接失败。并且，在控制台可以看到红色”X”。这个问题发生在下列条件符合时：

• DNS 远程过程调用 (RPC) 接口配置为使用仅本地过程调用。

• 通过使用 NetBIOS 名称连接到 DNS 服务器。

• DNS 服务器有 15 个字符的计算机名。

一个替代解决方案如下：

1. 单击开始单击运行，键入 dnsmgmt.msc , 然后单击确定。

2. 右击问题 DNS 服务器连接节点, 然后单击删除。

3. 单击是以确认删除。

4. 右击DNS,，然后单击连接到 DNS 服务器。

5. 选择计算机，输入下列的一种, 然后选择确定：

• 点 (.)

• DNS 服务器的FQDN名

• 127.0.0.1

注意我们建议您键入点或 FQDN。在某些情况下用 " 127.0.0.1 "可能无效。

关于这个问题的更多信息，请阅读以下知识库文档：

When you try to connect to a DNS server by using the DNS snap-in (Dnsmgmt.msc) on a Windows Server 2003-based computer, the connection fails

http://support.microsoft.com/default.aspx?scid=kb;EN-US;936243

如果客户端计算机上没有配置默认网关，Outlook 2007将无法连接Exchange服务器

Support News Editor — Tue, 29 May 2007 09:29:00 GMT

在尝试将 Microsoft Office Outlook 2007 连接到 Microsoft Exchange Server 时，如果没有配置默认网关，我们可能会收到多种错误信息。请参考以下文章以了解如何绕过这个问题。

在尝试将 Outlook 2007 连接到 Exchange Server 时出现以下错误消息：“The action cannot be completed.The connection to the Microsoft Exchange Server is unavailable”或者“Your Microsoft Exchange Server is unavailable”

http://support.microsoft.com/kb/913843/zh-cn

注意：据我们分析，这个问题经常发生于用户通过RPC over HTTP在家访问Exchange的情况下。因为用户所使用的ISP可能不需要设置默认网关。

安装Windows 2003 SP2后可能遇到的一些问题

Support News Editor — Tue, 29 May 2007 09:10:00 GMT

Microsoft Windows Server 2003 Service Pack 2 (SP2) 是一个累积的 Service Pack，它包括最新的更新程序并且增强了安全性和稳定性。此外，它还在现有的 Windows Server 2003 功能和实用程序中添加了新的功能和更新程序。和Windows Server 2003 SP1 一样，在安全设置方面它作了较大的修改包括一些服务的启动帐等等。由于Windows Server SP2 在服务的安全权限作了更强的限制，安装Windows 2003 SP2后有可能遇到一些问题。

这里我们列举了一个典型的安全相关问题。

现象

RPC 服务或or 其他相关服务不能正常启动。例如，当试图启动RPC服务时，得到错误"Error 1068: The dependency service or group failed to start"
网络连接不能打开或网络连接没有网络适配器图标
传入和传出网络通信失败。
COM+, Volume Shadow Copy and Shell Hardware Detection 服务处于 “启动” 状态
当选择无法启动的服务的“依存关系”页时，得到“访问拒绝”。

原因

发生此问题是因为远程过程调用 (RPC) 服务登录帐户从本地系统帐户已更改到带有Windows Server 2003 SP2 中 Network Service 帐户。当运行 Network Service 帐户, RPC 服务验证后模拟客户端策略必须包含管理员组帐户和 SERVICE 组帐户。

解决方案

要解决此问题, 请按照下列步骤：

使用具有管理员权限的帐号登录。向 “身份验证后模拟客户端“ 策略设置添加 Administrators 和 SERVICE 组帐户。请按照下列步骤操作：

a. 单击开始，键入 gpedit.msc , 和运行。

b. 在控制台树, 查找，然后展开下列节点：

策略 \ 计算机配置 \ Windows 设置 \ 安全设置 \ 本地策略 \ 用户权限指派

c. 找到并双击验证后模拟客户端。

d. 请单击添加用户或组。

注意如果添加用户或组按钮禁用，如果计算机是域控制器, 使用域控制器安全策略管理工具进行策略更改。此策略工具将替代本地安全策略设置。如果此计算机是成员服务器并添加用户或组按钮禁用, 识别所有策略设置适用于此计算机, 并再进行策略更改到适当的组策略设置。

e. 输入对象名称来选择中, 键入 Administrators , 然后单击确定。

f. 对于 SERVICE 组帐户重复步骤通过 e d。

g. 单击确定以关闭属性验证后模拟客户端对话框。

h. 在文件菜单上, 单击 Exit 。

i. 重新启动计算机。

如果能在身份验证后模拟客户端策略进行以上设置, 可在添加 Administrators 和 SERVICE 组帐户后重新启动计算机

Exchange 用尽全部事务处理日志序列造成没有警告卸除存储数据库

Support News Editor — Tue, 29 May 2007 09:06:00 GMT

最近我们看到很多Exchange 用尽全部事务处理日志序列的案例,当全部序列用尽后,Exchange的store数据库就会自己卸载,造成不可预见的影响.

Exchange所用的第一个事务处理日志序列是"E nn 00001.log." 最大的事务处理日志序列是"E nn ffff0.log." 也就是说, 当事务处理日志产生了1,048,560个后, 序列达到最大值.

为了防止这种情况发生, 你最好检查你的服务器的事务处理日志序列. 为了重置日志序列号, 你需要正常卸载Store然后删除全部事务处理日志. 更多细节, 你可以参考下面的知识库文档:

http://support.microsoft.com/kb/830408/ch

Automatic Update 引起SVCHOST CPU占用率过高

Support News Editor — Tue, 29 May 2007 09:01:00 GMT

症状

SVCHOST CPU占用率过高，如果停止Automatic Update服务，CPU占用率高的问题消失。

或者用下面的方法确认是否AU引起SVCHOST CPU占用率过高的问题：

1. 用下面的命令行找到运行Automatic Update服务的SVCHOST进程的PID

Tasklist –m wuaueng.dll

2. 执行下面的命令行来强制客户端发起补丁检测 (某些情况下这个命令行能够重现CPU占用率过高的问题)

Wuauclt /detectnow

3. 找到运行Automatic Update服务的SVCHOST进程的PID，看它是否会引起长时间CPU占用率过高。（短时间内的CPU高是正常的）

解决方案

如果是AU引起SVCHOST CPU占用率过高的问题，请您参考下面的KB：

http://support.microsoft.com/kb/916089/ch

http://support.microsoft.com//kb/927891/ch

您可以尝试用下面的方法看能否解决这个问题：

1. 安装更新KB927891

http://support.microsoft.com//kb/927891/ch

2. 如果安装了更新KB927891之后，客户端仍然有持续的100%CPU问题，请您下载安装最新的WSUS 3.0 客户端：

http://download.windowsupdate.com/v7/windowsupdate/redist/standalone/WindowsUpdateAgent30-x86.exe

针对64位操作系统：

http://download.windowsupdate.com/v7/windowsupdate/redist/standalone/WindowsUpdateAgent30-x64.exe

http://download.windowsupdate.com/v7/windowsupdate/redist/standalone/WindowsUpdateAgent30-ia64.exe

根据我们正在跟踪的相关问题的客户反馈，上面两个步骤应该能够缓解这个问题。

这两个用来解决AU引起SVCHOST CPU占用率过高的问题可以通过WindowsUpdate /WSUS获得.

更新KB927891在WSUS上被列为Critical Updates. 更多具体信息请参考:

http://blogs.technet.com/wsus/archive/2007/05/22/latest-msi-dll-fix-927891-also-available-to-wu-wsus-today.aspx

更新KB936301在WSUS上被列为Critical Updates. 它安装在WSUS 2.0 SP1 服务器上,把Selfupdate tree 升级为WSUS 3.0 同时仍然保留服务器为WSUS 2.0, 所以客户端可以通过访问 WSUS selfupdate tree来获得WUA3.0. 更多具体信息请参考:

http://blogs.technet.com/wsus/archive/2007/05/22/updates-for-wsus-available-today.aspx

如果有和这个问题相关的疑问，可以联系GCR PSS Security Support Group (shsecs@microsoft.com) 获取进一步的支持。

丢失默认用户目录下的NTUSER.DAT文件导致Windows Update出错

Support News Editor — Wed, 23 May 2007 05:56:00 GMT

Symptom

========

You may receive 0x8007003 errors when installing windows updates.

From Windows Update.log file, you can find the error information as below:

2007-03-17 12:14:47:639 6128 a54 Handler Post-reboot status for package
Package_for_KB932246~31bf3856ad364e35~x86~~6.0.1.2: 0x80070003.
2007-03-17 12:14:47:639 6128 a54 Handler WARNING: Got extended error:
"POQ Operation LoadDefaultUserHive"

Cause:

=======

This error can happen if the ntuser.dat file is missing from the \user\default folder. Some users have deleted it or for some reason it’s missing.

Solution:

=======

The solution is very simple. Just creating that folder and copying over a ntuser.data in default user folder from another machine.

低于v3的ITMU版本将无法检测最新的软件更新

Support News Editor — Wed, 23 May 2007 05:55:00 GMT

As mentioned before in the newsletter, ITMU (SMS 2003 Inventory Tool for Microsoft Updates) should be upgraded to version 3 now as lower versions will not detect new software updates from March 2007. This is becoming a hot issue recently, so some customers may still not be aware of this. Thus, It’s necessary to notify them again.

Why should ITMU upgrade to v3? Please refer to ITMU v3 General FAQ

For more ITMU v3 and upgrade information, go to ITMU Overview, What’s New in ITMU Revision 3

访问被拒绝, 以及其他访问其他Vista客户端SMB共享失败

Support News Editor — Wed, 23 May 2007 05:51:00 GMT

Some of the fun we have in product support is that, once a new product is released nowadays, we get to navigate the uncharted waters of new security settings interoperating with our customers’ real world environments.

With Windows XP and Server 2003 we saw that there were challenges brought about by the SMB signing, and LMCompatibility level security settings. SMB Signing is a way of guaranteeing the originator of the traffic since it is signed by that node. LMCompatibility, put simply, is a way of telling your computer to not use less than a certain version of NTLM authentication since older versions are less secure.

Both of these are good things from a security perspective. Frankly, if they are disabled or lessened, then your systems are less secure.

But in the real world there are plenty of people who have old computers (Windows 9x, NT) that may not be compliant with enhanced security. These types of things are may not always be disseminated well at a product’s release and we are forced to play catch up. If you saw my post regarding TCP Auto-Tuning a few months ago then you’ve heard this tune before.

LM Compatibility level is a way of setting your Windows computer to use only a specified level of LanMan authentication (NTLM). This is done via a registry value which is noticed by the LSA at boot:

hklm\system\currentcontrolset\control\lsa

Why am I bothering to post about this “old hat” stuff? Well, Vista defaults to LMcompatibliltylevel = 3. This is more secure, but can cause problems with other products that do not interoperate smoothly with some of the more secure mechanisms. Some Unix based network file sharing devices, for example. In fact, if you have an account lockout policy specified, you could end up locking out your user account if you ran into this when trying to connect to a file share on such a device.

Please check if the below symptom happens based on our support experience:

- Your problem occurs only when connecting to the resource from a Vista client, but may not occur from other operating systems

-You do not specify a custom LMcompatibliltylevel setting in any of your group policies

-Doesn’t necessarily have to be a network file sharing device back end…but more likely to be.

-Network traffic will appear similar to that below (SMB negotiation details excepted for brevity):

No. Time Source Destination Protocol Info

152 07:48:17.447552 34.52.40.213 34.224.36.2 SMB Negotiate Protocol Request

153 07:48:17.449232 34.224.36.2 34.52.40.213 SMB Negotiate Protocol Response

164 07:48:17.458380 34.52.40.213 34.224.36.2 SMB Session Setup AndX Request, User: DOMAIN\user1; Tree Connect AndX, Path: \\LOCALFILESVR\IPC$

182 07:48:20.410098 34.224.36.2 34.52.40.213 SMB Session Setup AndX Response, Error: STATUS_LOGON_FAILURE

How can you work around this behavior? Well, the best way would be to bring the same minimum level of security to all devices involved. This can be a difficult thing to do when you are stuck with inherited infrastructure and a limited budget.

If you can’t have all devices meet that minimum security then you will be forced to allow less secure authentication in order to get your business flowing. To do that, lower the LMcompatibliltylevel to a lower number that the other device can handle. Then reboot for that to take effect.

Here’s a link article that goes into good detail about NTLM authentication and what the LMcompatibliltylevel setting does:

http://www.microsoft.com/technet/technetmag/issues/2006/08/SecurityWatch/?related=/technet/technetmag/issues/2006/08/SecurityWatch

如何修复EFS文件

Support News Editor — Wed, 23 May 2007 05:50:00 GMT

Windows XP and Windows Server 2003 provide many enhancements in the area of data protection— especially Encrypting File System (EFS). This article provides some common issues and file recovery practices to prevent encrypted files being inaccessible.

We often encounter problems when accessing encrypted files. For example, not able to access the data and getting permissions denied. To prevent EFS related issues, it is necessary to be aware of some common problems before you make any changes to an EFS environment.

Here we first list some common issues when trying to access an encrypted file:

a. Cannot access files after disjoining or joining a domain

When joining a computer to a domain that has EFS encrypted files, move keys from local account profile to new domain account profile for EFS access.

b. Cannot decrypt EFS files after resetting a password

Change the user’s password back to what it was before the reset.

c. Cannot access remote EFS encrypted files from Windows 9x or Windows NT 4.0 clients

By design the server blocks Pre-windows 2000 machines from opening a remote encrypted file.

d. Access Denied error attempting to access EFS encrypted files

Locate the private key for the appropriate certificate and import it onto this computer using the Certificates snap-in. We recommend that you back up the recovery certificate (*.CER) and the private key files (*.PFX) to a safe location.

In addition, before we implement EFS, it is necessary to designate other users or recovery agents in case there are problems with the original user who encrypt the file. The following users can access the encrypted file.

1. The original user who encrypts the file

2. Users being added to give cryptographic access to that file.

Cryptographic access means the users are able to decrypt and encrypt the file, as well as add and remove other users. To add users to a file gives them cryptographic access to that file:

e. Right click on the folder or file, click Properties

f. Click Advanced. Click to check “Encrypt contents to secure data”

g. Click on the Details button brings up the Encryption Details dialog.

h. Add users to transparently access the file

3. Recovery Agents.

The Recovery Agent is optional on Windows XP Professional and Windows Server 2003 in order to provide organizations with greater flexibility in implementing data recovery strategies. The domain Administrator is the default recovery agent. To assign a Data Recovery Agent:

i. Logon to a computer with the account that you are going to be using for the EFS recovery agent.

j. Run MMC.exe and load Certificates for the current User.

k. Right click on the Personal Store. Click All Tasks, click Request New Certificate…

l. Chose the Recovery agent Certificate

m. Once you have the Recovery agent Cert. Export the Cert (without the private key to a .Cer file)

n. Copy the Cert to a DC

o. Open Active Directory Users and Computers. Edit your Default Domain Policy

p. Under Computer Configuration\Windows Settings Security Settings\Public Key Policies

q. Right Click on Encrypting File System and click on Add a recovery agent

r. Choose Folders. Browse to the .CER file and finish the wizard.

s. This will add the Recovery agent to all machines once Group Policy processing is done

The next time a new file is encrypted it will add the recovery agent to that file.

To recover an encrypted file or folder if you are a designated recovery agent:

a. Use Backup or another backup tool to restore a user's backup version of the encrypted file or folder to the computer where your file recovery certificate and recovery key are located.

b. Open Windows Explorer.

c. Right-click the file or folder and then click Properties.

d. On the General tab, click Advanced.

e. Clear the Encrypt contents to secure data check box.

f. Make a backup version of the decrypted file or folder and return the backup version to the user.

处理安装有安全升级包925902的Windows XP或Windows 2000上的0x0000007F错误

Support News Editor — Wed, 23 May 2007 05:48:00 GMT

Customer may experience a bluesreen after they install security update 925902.

• You receive the following Stop error message on a blue screen:

*** Stop 0x0000007f (0x00000000, 0x00000000, 0x00000000, 0x00000000)

UNEXPECTED_KERNEL_MODE_TRAP

This problem occurs when a printer driver makes a call that has invalid parameters to the Win32K.sys component. Microsoft has confirmed that this problem affects the following printer drivers:

• Ricoh LAN Fax Driver

• Gestetner P7026n PCL

• Ricoh Laser AP2600N PCL

• HP LaserJet 9050

• HP LaserJet 4200

• HP 4050 PCL6

This problem has also been reported in relation to printing from SQL Reporting Services to a Printer Command Language (PCL) printer.

For more details and resolution of this issue, please refer to the article below for the resolution:

935843 Stop 0x0000007F error when you try to print from computers that are running Windows XP or Windows 2000 and that have GDI security update 925902 installed.

http://support.microsoft.com/kb/935843/en-us

由损坏的分类导致的Windows Server 2003 SP 2无法安装

Support News Editor — Wed, 23 May 2007 05:43:00 GMT

Recently, we have been seeing a number of issues with Windows Server 2003 SP 2 not installing due to corrupt catalogs in the catroot. The installation may fail with the following popup error:

Service Pack 2 Setup Error

Failed to install catalog files.

Select OK to undo the changes that have been made.

Additionally, Windows Server 2003 SP2 may fail to install if there are too many hotfixes being installed.

Actually, this problem is not SP2 specific. It’s not a new issue to us either. We have several resolutions documented in the following KB articles:

822798 You cannot install some updates or programs

http://support.microsoft.com/kb/822798

925931 You may be unable to apply more updates at a certain point on a Windows Server 2003-based computer

http://support.microsoft.com/kb/925931