Recently in Exchange Category
Configuration-->CN=Service-->CN=Microsoft Exchange-->CN=<Exchange ORG. Name>-->CN=Global Settings-->CN=Message Delivery-->鼠标右键-->内容
delivContLength：<10240> (0~2097151KB) 预设值为10MB，最大可以设为2097151KB (2GB)
submissionContLenght：<10240> (0~2097151KB) 同上
msExchReciplimit：<5000> (0~2147483647) 不用改
Exchange 2007传送大小，使用MAPI时会受限于Global limits、Organizational limits、使用者信箱传送大小的限制、Pickup大小的限制、集线传输规则的附件档大小限制、Connector limits、OWA 2007 (Web.config file)的上传下载大小限制。
传送大小的限制原则是：使用者的传送大小或接收大小取决于使用者信箱的传送大小限制的设定，若保持预设(没有特别指定)，再由Global及ORG.两者的传送大小限制来决定，但预设上，Global是限制10MB，而ORG是没有限制，因此Global与ORG之间再取最小值，所以若使用者信箱没有特别 设定传送大小限制，预设值会被限制在10MB。
以上为纯Exchange 2007安装时的情况,若是由Exchange 2003或Exchange 2000升级上来的,则Global会保留原有设定, 一般人比较容易疏忽的是Global设定,因为这是旧版本Exchange的设定,只能由Exchange 2000或2003的管理界面去查看或设定,若是纯Exchange 2007的安装,并没有直接的管理界面或命令去指定,必须通过ADSI工具来修改
上次微软面试官问的问题,很可惜,他的答案是错误的,虽然他一再坚持并叫我回来自己查证,其实CAS/HUB Server 安装在一起做NLB是可行的.
NLB can be used to provide high availability in the following scenarios:
1. Load balancing of inbound SMTP connections for POP and IMAP client connections to the default Receive connector named "Client <Server Name>" that is created only on Hub Transport servers.
2. Load balancing of inbound SMTP connections for applications that submit e-mail to the Exchange organization.
NLB should not be used to distribute connections for internal routing between Hub Transport servers.
Besides,NLB is only avaliable on Exchange 2007 with SP1 installed.
1. For the first question: should NLB be setup before or after Ex2007 installation?
NLB should be configure after we have these roles have installed.
2. IP address you want to use as the Windows NLB cluster IP address should be an IP address on the same subnet as the NLB member servers.
3. When we begin to setup NLB the first thing is to do is to create an A-record for the NLB cluster name in DNS. So that we can use these two Hub transport/Client Access server as one. Then you have to point your MX record to Windows NLB cluster IP address, which you specified when you create the A record. So that Client will find the Hub transport/Client Access server.
4. Yes, you are right. Internally, you can use https://mail.internal.domain.com/owa ,external URL should be the https://mail.domain.com/owa
More information share with you:
How you can load-balance Exchange Server 2007 Service Pack 1 (SP1) Hub Transport Servers using Windows Network Load Balancing technology.
Using Network Load Balancing
Update
In order to keep the number of servers down in a high availability environment, administrators have been looking at using Network Load Balancing (NLB) for CAS and then co-locating the HT role on each node of the NLB cluster to also provide high availability for the HT role.
This configuration can work, and it really is not too difficult to configure. It is extremely important to note that using NLB to load balance the default SMTP receive connectors (using port 25) is not supported and is completely unnecessary since they are load balanced for all intra-Exchange communications like HT to HT communications. However, using NLB to provide redundancy and load balancing for connections to HTs that are hosting Client SMTP receive connectors (using port 587) is fully supported and may be desireable if you have a large number of external SMTP/POP and SMTP/IMAP clients that need to connect to this receive connector.
The steps that you need are to:
-
Setup two servers running Windows Server 2003 with two NICs in each server
-
Install Exchange Server2007 Hub Transport and Client Access Service (CAS) on each server
-
Configure one NIC for the Network Load Balance cluster and setup the other NIC in a separate network so it can be managed through that IP address
-
Configure NLB with Unicast and even load balancing
-
Setup the port rules:
-
Port 25 to 25 for both TCP and UDP and select the radio button to disable this port range (this will exclude port 25 from being listed to using the virtual IP address of the NLB cluster, but still allow the individual server IPs to still listen to port 25)
-
Port 465 to 465 for both TCP and UDP and selected the radio button to disable this port range
-
Port 80 to 80 for both TCP and UDP and set affinity to none (I recommend "none" so you can easily test and verify that it works)
-
Port 587 to 587 for both TCP and UDP, affinity none (this is for the client SMTP receive connector)
-
Port 443 to 443 for both TCP and UDP, affinity none
-
Port 110 to 110 for both TCP and UDP, affinity none
-
Port 993 to 993 for both TCP and UDP, affinity none
-
Port 143 to 143 for both TCP and UDP, affinity none
-
Port 995 to 995 for both TCP and UDP, affinity none
-
With affinity set to none, you can more readily test the CAS (after updating the web pages to show which server is actually responding) and verify that the load is being shared. You can also test to make sure the NLB cluster does not respond to SMTP on port 25, which it shouldn't if you set it right, and verify that each server does respond to SMTP as an individual server name.
-
You can configure protocol logging for the other protocols and telnet to the ports using the NLB IP address to see if they are loading balancing like they should. You can also use the NLB IP for the testing by sending and receiving messages and checking the message tracking logs to see that the traffic was being balanced. It all worked.
NOTE: You may want to change affinity to either single (especially if it is being used internally) or Class C (especially if it is accessible from the Internet) once your testing is done.
Mark..
http://www.expta.com/2008/02/fix-for-forefront-update-timeout-errors.html
解决 ForeFront For Exchange 2007 升级病毒扫描引擎时出现的超时问题
微软KB http://support.microsoft.com/kb/939411/en-us
I use Microsoft Forefront Security for Exchange Server on my Exchange 2007 Edge server.
Recently I noticed the following error in the Application Event log:
Event Type: ErrorFollowed immediately by:
Event Source: GetEngineFiles
Event Category: Engine Error
Event ID: 6014
Date: 2/9/2008
Time: 10:08:43 AM
User: N/A
Computer: GATEWAY
Description:
Microsoft Forefront Server Security encountered an error while performing a scan engine update.
Scan Engine: Kaspersky5
Update Path: http://forefrontdl.microsoft.com/server/scanengineupdate/x86/Kaspersky5
Proxy Settings: Disabled
Error Code: 0xC0001F58
Description: The operation timed out.
Event Type: InformationThis was happening every 5 minutes after Event ID 2034, which reports that Microsoft Forefront Server Security is attempting a scan engine update of the Kaspersky5 scan engine.
Event Source: GetEngineFiles
Event Category: General
Event ID: 2017
Date: 2/9/2008
Time: 10:08:43 AM
User: N/A
Computer: GATEWAY
Description:
Forefront Server Security has rolled back a scan engine.
Scan Engine: Kaspersky5
To solve this error make the following change to the registry on the server running Forefront:
- Open Regedit
- Navigate to the following key:
HKLM\SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\Exchange Server
- Click New DWORD Value
- Type EngineDownloadTimeout, and then press ENTER
- Right-click the new value and select Modify
- Select Decimal as the base, enter 600 in the Value data box, and then click OK. This setting causes the scan engine download process to time out after 600 seconds (10 minutes, instead of 5 minutes)
- Exit Regedit
Note: You do not have to restart Forefront Server services or Exchange Server services after you change this registry entry.
Now perform a manual scanner update in Forefront:
- Open Forefront Server Security Administrator
- Click Scanner Updates under Settings
- Select the appropriate scan engine that was previously timing out. In my case, Kaspersky Antivirus Technology
- Click the Update Now button on the right side of the screen
Check the Application event log to ensure that the scan engine has updated properly (Event ID 2012).
We have been made aware that some of our Exchange 2007 customers have been experiencing the following issue today:
When trying to make certain configuration changes such as new-mailbox or enable-mailbox, certain set of our customers would receive the following error:
"The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error."
Additionally, if you have attempted to set up new Exchange 2007 servers today, your setup might have failed because of the same error.
After investigation of this problem we have learned that this problem would occur only if you have started or restarted the Microsoft Exchange System Attendant service between 12:00AM UTC , Feb 29, 2008 and 12:00AM UTC, Mar 1, 2008. It is important to note that the times involved are UTC, not local server time.
If
you are impacted by this, all that you have to do is restart the
Microsoft Exchange System Attendant service after the midnight UTC,
March 1, 2008. Restart of the System Attendant will not disrupt your
Information Store service.
Exchange 2007 的闰年bug，在进行 new-mailbox,
enable-mailbox, set-group 等等动作时，系统会有一个错误提示说"The
Exchange server address list service failed to respond. " 在3月1号以后重启 'Exchange System Attendant' 服务可以暂时解决此问题，Microsoft将在近期放出对于此bug的修复程序.
This white paper provides the information that you need in order to configure Microsoft Exchange Server 2007 with multiple address lists so different groups of users can have their own address list and secure those address lists so that groups of users can only see their specific address list.
Much of the information in this white paper originally appeared as individual Help topics in the Exchange Server 2007 Help. In this white paper, we have consolidated the information that you need to deploy and manage segregated address lists in one central location. We have also provided sample scripts, which can be modified to fit your environment, to help automate the provisioning of virtual organizations and users.
http://technet.microsoft.com/en-us/exchange/bb936719.aspx
Update:
White paper author, Dave Goldman, just posted some updates related to document:
在 Exchange 2007 SP1 中 OWA 有了 Theme 选择， 这个是 Xbox360 和 Zune 的预览
Q: I have a problem where it only seems to be for one customer where in
outlook only the distribution lists keep disappearing. We can recreate them and
they work for a week or so then they just disappear.
You can still see
them in OWA just not Outlook so I though it would be a Offline Address Book
thing but can't see anything wrong with it. How to fix it?
A:The Domain recipient update service should be disabled in HMC 3.5.
MPS
is responsible for stamping 'showInAddressBook' instead of RUS.
Here is a batch file to fix it:
echo. > %temp%\ldf.log
dsquery * "OU=%*,OU=SampleOU,OU=Hosting,DC=domain,DC=com" -filter grouptype=8 | sort > c:\l.txt
set a=%*
For /F "tokens=2 delims==, " %%a in ('type c:\l.txt') Do (
echo Fixing Group %%a
rem echo %a%
echo dn: CN=%%a,OU=%a%,OU=SampleOU,OU=Hosting,DC=domain,DC=com> %temp%\galfix.ldf
echo changetype: modify>> %temp%\galfix.ldf
echo replace: showInAddressBook>> %temp%\galfix.ldf
echo showInAddressBook: CN=%a% AL,CN=All Address Lists,CN=Address Lists Container,CN=Domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com >> %temp%\galfix.ldf
echo showInAddressBook: CN=%a% GAL,CN=All Global Address Lists,CN=Address Lists Container,CN=Domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com >> %temp%\galfix.ldf
echo - >> %temp%\galfix.ldf
echo Fixing Group %%a >> %temp%\ldf.log
ldifde -i -f %temp%\galfix.ldf >> %temp%\ldf.log
)
echo.
echo log file %temp%\ldf.log
About Grouptype:
* 2 - Global distribution group
* 4 - Domain local distribution group
* 8 - Universal distribution group
the command would be batfile.bat name_of_ou
If you are running Exchange 2003 and 2007 in the same organization and you have enabled the disclaimer rule and create an e-mail on the Exchange 2003 server with OWA that gets routed by the Exchange 2007 server the e-mail might become corrupted.
CAUSE
This problem occurs because Outlook Web Access for Exchange 2003 sets an e-mail message to an incorrect character set. When the message is routed by the Exchange 2007 server that has the Disclaimer rule enabled, the e-mail message is converted to incorrect HTML tagging based on the incorrect character set. Then, the message is corrupted by the incorrect tagging.
RESOLUTION
Hotfix information
A supported hotfix is now available from Microsoft. However, it is intended to correct only the problem that is described in this article. Apply it only to systems that are experiencing this specific problem. This hotfix may receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next Exchange Server 2003 service pack that contains this hotfix. To resolve this problem immediately, contact Microsoft Customer Support Services to obtain the hotfix.
For more information about this problem you can read this KB article: http://support.microsoft.com/default.aspx?scid=kb;en-us;935489
