What is the symptom?
In Exchange 2000 or 2003, when you have a delivery restriction based on distribution groups set on your connectors or recipients, message delivery to local mailboxes and to external recipients is slower than normal. Messages may be backed up in the "Messages Awaiting Directory Lookup" queue and/or "Messages Waiting to be Routed" queue. It may even cause backups in the Pre-Submission queue depending on the load on the server.
Why does this problem occur?
This problem occurs because Exchange 2000/2003 Server must expand the distribution groups to determine whether each user account is permitted to send or to receive the e-mail message. The results of this distribution group-expansion are not cached by Exchange 2000/2003 Server. Also, if a failure that can be retried occurs during this expansion process, Exchange 2000/2003 Server stops the distribution group-expansion process, and then retries the connection an hour later. The problem has been there since the early Exchange 2000 days.
How to fix this problem?
Exchange Server 2003
For Exchange Server 2003, the Microsoft-recommended solution is to use flat distribution group in combination with the RestrictionMethod registry key and the hotfix outlined in KB895407. Please note this solution is only effective if all the followings are true on the connector bridgehead server and/or distribution group expansion server:
1. Exchange Server 2003 SP2 has already been applied or the hotfix KB895407 is applied on Exchange Server 2003 SP1
2. The RestrictionMethod registry key is configured correctly.
3. All distribution groups used in the delivery restriction must be flat. If they are not then the nested groups will not be used in the restriction checking logic.
This registry key and hotfix solution helps with and changes the way delivery restrictions are checked for both per-recipient and per-connector, which greatly enhances messages delivery performance in an environment with delivery restriction for distribution groups. For more details about this solution, please refer to the following Microsoft Knowledge Base article:
In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups
http://support.microsoft.com/?id=895407
Exchange 2000 Server
For Exchange 2000 Server, every possible effort should be made to upgrade, at least the server which is doing connector restrictions or distribution group expansion, to Exchange Server 2003 SP2. This is the preferred and recommended solution even for Exchange Server 2000 due to the extremely positive performance gain for connector restrictions checking capabilities of Exchange Server 2003 SP2. If you are running Exchange 2000 server and are truly unable to upgrade to Exchange Server 2003 SP2 to implement the recommended solution above, there are a couple workarounds you may consider by referring to the following Microsoft Knowledge Base articles:
XADM: Mail Delivery Is Slow if Recipients Are Configured with Delivery Restrictions Based on Group Membership
http://support.microsoft.com/?id=329171
Mail delivery is slow after you configure delivery restrictions that are based on a distribution list
http://support.microsoft.com/?id=812298
What is the situation in the upcoming Exchange Server 2007?
This message delivery performance issue is resolved in Exchange Server 2007, as there are no connector restrictions in Exchange Server 2007. Restrictions will be applied on policy in the core transport via Transports Rules in Exchange Server 2007. Connector restrictions will be completely gone and it's up to the Exchange Server 2007 Transport Rules to enforce restrictions.
Sometimes, we may want to grant an add-in (custom add-in) or a program (Access, Excel) the permission to access Outlook's data and send email via Outlook. By default, Outlook will prompt a security warning to let the user confirm it is not a virus or any malicious code. We can perform the following steps to use Outlook E-mail Security Administrative Package so that Outlook trusts add-ins or other programs. (For example, the code which access Outlook's data or send email via Outlook is in sendmail.dll)
1. in ESM, Locate Folders -> Public Folders
2. Right Click Public Folders -> Click New -> Public Folder
3. Use the name "Outlook Security Settings" and Click OK
4. Right Click "Outlook Security Settings" and Click Properties -> On Permissions tab, Click Client Permissions -> Make sure "Default" and "Anonymous" has "Reviewer" role at least and your account has owner role and Click OK
5. Download ADMPACK.EXE from http://www.microsoft.com/downloads/details.aspx?FamilyID=15673dc4-2406-4946-aa02-8a8b0e0165b0&DisplayLang=en
6. Run it and it will extract 4 files for you (comdlg32.ocx, hashctl.dll, OutlookSecurity.oft, readme.doc)
7. Copy comdlg32.ocx and hashctl.dll to C:\Windows\System32\
8. Click start -> Run… -> Type "regsvr32 hashctl.dll" (without quotation marks) and Click OK
9. Click start -> Run… -> Type "regsvr32 comdlg32.ocx" (without quotation marks) and Click OK
10. Start Outlook and log on to your Exchange mailbox
11. Double Click OutlookSecurity.oft to launch it
12. Choose "Outlook Security Settings" (under Public Folders) and Click OK
13. Click Tools -> Forms -> Publish Form
14. Select "Outlook Folders" in "Look In:" drop down box
15. Click Browse and Locate Public Folders -> Outlook Security Settings and Click OK
16. Type "Outlook Security Form" in both "Display name:" and "Form name:" box and Click Publish
17. Close the form and Click NO when it prompt for save changes
18. In Outlook, Click File -> New -> Choose Form…
19. Select "Outlook Folders" in "Look In:" drop down box
20. Click Browse and Locate Public Folders -> Outlook Security Settings and Click OK
21. Select "Outlook Security Form" and Click Open
22. On Trusted Code tab, Click Add…
23. Locate the "sendmail.dll" file (you can install the add-in or program on your machine in advance) and Click Open
24. Click Close and Click Yes when it prompt for save changes
Now, in your Exchange environment, the "sendmail.dll" file can access Outlook's data and send emails without the security warning. More information can be found in the readme.doc file included in ADMPACK.EXE.
Group Policy in Windows Vista and Windows Server "Longhorn" provides an infrastructure for centralized configuration management of the operating system and applications that run on the operating system.
Expanding on the foundation established in Windows Server 2003 and Windows XP, Group Policy is improved with greater coverage of policy settings and extensions, better network awareness and reliability, and easier administration. This guide provides an overview of new features and improvements in Group Policy.
http://www.microsoft.com/technet/windowsvista/library/a8366c42-6373-48cd-9d11-2510580e4817.mspx
Windows 2000 and 2003 both contain protected groups, called AdminSdHolder. AdminSdHolder is used to control the permissions of user accounts that are members of the built-in Administrators or Domain Administrators groups. Protected Groups are groups that Windows protects from unnecessary changes. In some instances, this process can confuse people, even causing some unexpected behaviors when delegating administrations. However, this is actually a design feature for better security control. This article will explain the roles of protected groups and how the AdminSDHolder object is used in conjunction with protected groups.
Have you met with the following wired behavior?
1. Make a change to a user ACE (Access Control Entry) for an OU and find out that, for some reason, there is an account that the ACL doesn’t get applied to a particular user.
2. Explicitly configure the Send As right on a user object in the Active Directory Users and Computers snap-in in Microsoft Exchange Server, however, the Send As right is removed from the user object in about one hour.
3.Delegated permissions are not available to all users in an organizational unit.
4.Inheritance is automatically disabled on some user accounts, approximately once an hour
5. Users who previously had delegated permissions no longer have them.
More than likely, this is due to a special container called AdminSDHolder. Active Directory protects certain accounts not to inherit delegated permission. This behavior applies to direct and nested members of the following security-groups:
Windows 2000 SP3:
Enterprise Admins
Schema Admins
Domain Admins
Administrators
Windows 2000 SP4 and Windows Server 2003 additional:
Account Operators
Server Operators
Print Operators
Backup Operators
Cert Publishers
Let's look more into AdminSDHolder and see what exactly it does.
What AdminSDHolder does:
All objects in Active Directory have an ACL. The basic function of AdminSDHolder is exactly what it says it does - it holds the Access Control List (ACL) for every admin account. This container is just a template.
In order to protect highly-privileged accounts, the DC that holds the PDC Emulator role goes through every account that is in built-in Administrators group and checks the ACL for each user object once every hour. There is an AdminSDHolder object whose ACL serves as a template for ACLs on protected objects. It compares this ACL to the template of the AdminSDHolder container and if any Access Control Entry (ACE) is different, it rips out the old ACL and copies the ACL from the AdminSDHolder over to it. AdminSdHolder also applies the permissions to accounts which are nested members through distribution groups since the distribution group could be converted to a security group.
During the enforcement process, the PDC Emulator removes the "Allow Inheritable Permission from Parent" check box. If the user object is ever removed from the built-in Administrators group (or any groups nested in the Adminstrators group for that matter), the inheritable permissions flag remains turned off. Because of this, those accounts will not inherit new ACEs. You need to check the box to inherit permissions when removing those users out of the group manually, or use a script to check your users.
Why is the AdminSDHolder object needed?
The purpose of AdminSDHolder is to prevent a specific attack scenario. All objects including OUs in Active Directory have an ACL. With delegation or assigning appropriate permissions to a user, the user can have write access to anything inside of a specific OU. These ACLs can also be changed by anyone with permissions to do so. By default, only administrators have the necessary permissions to do this; however, Active Directory was designed to be scalable, to be used in large, disparate environments and to support many delegation scenarios. When you delegate control to users and/ or groups (essentially, set permissions on objects for these users and/ or groups) you increase the likelihood of giving non-administrative users permissions to modify attributes, permissions, etc. on administrative accounts.
For example, think of a scenario in which a group is delegated control over an OU and in that OU resides several members of the domain admins group. Depending on the permissions defined on the OU, this group that have had permissions delegated to it could be able to change the members of the domain admins group.
Considering another scenario, if an admin account is moved to an OU that a non-admin has rights to, he could give himself privileged access to the admin account. It would be a grave security hole if any user with permissions to change group memberships on all user objects in an OU were to be able to modify the administrative users. With AdminSDHolder existing, the system tries to prevent this from happening by continuously refreshing the ACL on an admin account.
What can we do if encountering issues related to AdminSDHolder?
A benefit of AdminSDHolder is how you can use it to modify the ACLs of privileged accounts. This comes in handy when you want to do something such as give only a particular group the ability to reset passwords on admin accounts. You would just add the "Reset Password" ACE to ACL of the AdminSDHolder container and the ACL change would be populated during the next refresh cycle. Although it’s possible to correct issues by modifying the ACL on the AdminSDHolder object itself, that procedure is usually not advisable, as any mistake could quickly be propagated to the protected objects. In addition, when the ACL is viewed using the standard AD Users and Computers MMC snap-in, only a subset of possible ACEs is available, because the AdminSDHolder object is a container (and therefore, certain group and user object ACEs are unavailable); to set more advanced permissions, one would need to script a solution or use the dsacls.exe utility.
As a resolution, you can remove certain less-secure groups from AdminSDHolder protection by installing the hotfix and following the instructions here:
Delegated permissions are not available and inheritance is automatically disabled
http://support.microsoft.com/?id=817433
You can also try other workarounds mentioned in above article. For more information on AdminSDHolder or delegation administration, view the following KB article or link:
AdminSDHolder Object Affects Delegation of Control for Past Administrator Accounts
http://support.microsoft.com/?id=306398
http://www.microsoft.com/downloads/details.aspx?familyid=631747a3-79e1-48fa-9730-dae7c0a1d6d3&displaylang=en
Additional recommendations for AD administration:
· Usually you should avoid using administrative accounts for the daily routine. Use a regular user-account, and just start administrative applications (such as Active Directory-Users and -Computers) with administrative credentials (via RunAs or Context-Menu, Open with…).
· Check the box to inherit permissions when removing those users out of the protected group manually, or use a script described in http://support.microsoft.com/?id=817433 to check your users.
Q: Why is Microsoft releasing an update to ITMU?
A: This release is so that ITMU customers are able to utilize the new scan catalog format being released for Windows and Microsoft Update.
Q: Why is a new scan catalogue being released?
A: Because of the growth in the size of the catalogue and the size limitations of 64,000 archived files the catalogue is expected to be filled by March 2007. When the catalogue is filled customers will no longer receive the most recent security updates. To avoid this and to keep customers receiving the latest updates a new catalogue is being created.
Q: So why does ITMU require updating?
A: The existing version of ITMU leverages the current catalogue, file name Wsusscan.cab. The new version of ITMU will leverage the new catalogue, wsusscn2.cab. Wsusscn2.cab uses a different format than wsusscn.cab.
Q: Is this related to the recent potential performance fix outlined where an SMS 2003 client computer could stop responding when trying to perform a software update scan with ITMU on a computer that is running SMS 2003 with Service Pack 1?
A: No. The potential issue where an SMS 2003 client computer could stop responding when trying to perform a software update scan with ITMU had been previously resolved through modification of the catalogue and did not require an update to ITMU.
Q: Other than compatibility with the new catalogue are there any other improvements that will be included in the new version of ITMU?
A: Yes. ITMU will also contain several improvements related to scan duration. Microsoft anticipates approximately a 30% improvement in scan duration with the new version of ITMU.
Q: What is the release timeline for the new ITMU?
A: November 1, 2006 is the anticipated release date though the release date will coincide with the release date of the new catalogue, Wsusscn2.cab.
Q: What will need to be upgraded? The client or server component?
A: ITMU will need to be upgraded on the server. Clients will need to get an updated Windows Update Agent (WUA). During the installation of the updated ITMU, the client packaging for the updated WUA is created for customers to help streamline the process.
Q: Will the old catalog and previous versions of ITMU still work?
A: When the new file is released, the existing Windows Update offline scan file will continue to be updated whenever new security bulletins are released. However, older updates will be removed, over time, from each subsequently-published version of the Wsusscan.cab file. This will be done so that the file stays within the size limits. After March 2007 the existing scan file will no longer be maintained, and new updates can only be obtained from the new catalogue. The new version of ITMU will be the way that SMS customers take advantage of this new catalogue.
Q: How long do customers have to upgrade?
A: Microsoft encourages customers to upgrade to the new ITMU as soon as possible. However, after March 2007 customers could be at risk of not having the most recent security updates if they do not upgrade. Microsoft cannot guarantee the completeness of the old catalog due to the file limitations.
Q: What type of update information will be removed from the catalog and how do I find out what has been removed?
A: The following KB article is the definitive source for what is being removed on a monthly basis from the old wsusscan.cab: http://support.microsoft.com/kb/924513/
Q: If I have concerns, can I use the legacy software update scan tools that shipped with previous versions of SMS?
A: Although the legacy scan tools, like the Systems Management Server 2003 Service Pack 1 Scan Tools and the SMS Extended Security Update Inventory Tool, continue to be a functional set of software update scan tools, customers are encouraged to migrate to the most recent and up-to-date software update scan tool for SMS: ITMU. ITMU fully supports the wide range of Windows and Microsoft update service packs, update rollups and security updates for all languages of clients and servers. It is also the only software update scan tool that supports upcoming Microsoft products like IE7 and Vista. Going forward, ITMU is the software update scan tool of choice for Systems Management Server.
Q: How do I get the new ITMU when it is available?
A: It will be available at the Microsoft Connect site.
Recently, some customers could not add additional delegates after applying Outlook Update 913807. If they try to add a delegate in Outlook, the following error message appears: "The delegate settings were not saved correctly. Unable to activate send-on-behalf-of list. You do not have sufficient permission to perform this operation on this object". Removing update 913807 solves this problem. However it is not recommended as new update package will include this update.
The better solution for this issue is to add the "Write Personal Information" permission to the SELF account for the user trying to add the delegate.
1. Start Active Directory Users and Computers (ADUC).
2. Click View -> Advanced Features
3. Locate the user's OU. In the right pane, Right Click the User who wants to add Delegate in Outlook and Click Properties.
4. On Security tab, Locate the SELF account and Set "Write Personal Information" to Allow
5. Click OK
Now, the user can add delegate properly. By the way, if you want to let userB help userA add delegate, besides "Full Mailbox Access", please don't forget to grant this "Write Personal Information" permission to userB.
Recently some Microsoft Windows XP-based computers might start to fail the Windows Genuine Advantage (WGA) validation process, or the Windows XP-based computers might be reported as being non-genuine.
You can take one of the solutions below to solve it:
l Manual steps to update the WGA Data.dat file on a single computer
To update the Data.dat file manually, follow these steps:
1. Log on to the computer that is experiencing the problem by using an account that has administrator credentials.
2. Delete the Data.dat file from the %ALLUSERSPROFILE% \Application Data\Windows Genuine Advantage\data folder.
3. Visit the following Microsoft Web site to confirm that the computer is reported as genuine:
http://www.microsoft.com/genuine/downloads/validate.aspx
4. Click Start, click Run, type wgatray.exe /b , and then click OK.
*Note*: The wgatray.exe command might not be available on your computer. This command is available only on computers that have Windows Genuine Advantage Notifications installed. If the wgatray.exe command is unavailable, it is not an error. Go to the next step. For more information about Windows Genuine Advantage Notifications, click the following article number to view the article in the Microsoft Knowledge Base:
905474 Description of the Windows Genuine Advantage Notifications application
5. Restart the computer.
l Automated steps to update the WGA Data.dat file on a single computer
1. Visit the following Microsoft Web site:
http://go.microsoft.com/fwlink/?linkid=52012
2. When you are prompted, click Run to run the Microsoft Genuine Advantage Diagnostic Tool.
*Note*: Depending on your security settings, you might be prompted several times to confirm that you want to run the tool.
3. Click Continue.
4. On the Windows tab, click Resolve.
If this method does not work, use the instructions in the "Manual steps to update the WGA Data.dat file on a single computer" section.
l Steps to automatically update the WGA Data.dat file on multiple computers
The following sample script is a simple .cmd script. To run this script on multiple Windows XP-based client computers, use Group Policy, Microsoft Systems Management Server, or other tools that are available in your environment. Use the best method for your environment to distribute the script. To run this script individually, you must run the script as an administrator. To create this script, open a new .txt file, and then paste the following script text in the new file. After you create the file, rename it by using a .cmd file name extension.
Script text
@ECHO OFF IF EXIST "%ALLUSERSPROFILE%\Application Data\Windows Genuine Advantage\data\data.dat" ( ECHO Deleting data.dat attrib -R "%ALLUSERSPROFILE%\Application Data\Windows Genuine Advantage\data\data.dat" DEL "%ALLUSERSPROFILE%\Application Data\Windows Genuine Advantage\data\data.dat" ) IF NOT EXIST %WINDIR%\system32\WGATray.exe (GOTO END) ECHO WGA Validation in progress. WGATray.exe /b :END ECHO Done
More info:
This behavior might be caused by an incorrect Data.dat file or by a corrupted Data.dat file in the %ALLUSERSPROFILE% \Application Data\Windows Genuine Advantage\data folder. Note By default, the %ALLUSERSPROFILE% folder is the C:\Documents and Settings\All Users folder. This location might be a different folder in your installation of Windows XP.
Server Cluster is a Microsoft technology to provide high availability on Windows platform. Though Server Cluster is very stable, it’s always recommended to have a backup in case any unexpected incidents occur, such as power outages or storage corruption. Please refer to the article below for how to back up and restore Sever Cluster in various circumstances.
Server Clusters: Backup and Recovery Best Practices for Windows Server 2003
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/clustering/sercbrbp.mspx
Protocol definitions include lists of primary connections, secondary connections, and associated application filters. Each primary connection includes a port range, which may cover one or more port numbers. When traffic is sent to an ISA Server computer, ISA Server uses the port on which it arrives to identify its protocol.
When a policy rule allows traffic for a certain protocol, the Firewall service checks the definition and passes the traffic to all the associated application filters for processing.
If traffic is sent to a port corresponding to a predefined protocol which is associated with an application filter and you do not want the application filter to process this traffic, you can define a custom protocol that has the same primary and secondary connections as the predefined protocol but is not associated with the application filter. Then you can use your custom protocol in a policy rule that allows this traffic. Protocol definitions with primary connections that include the same port are called overlapped protocol definitions.
As an example, let’s say that you have an internal server to which VPN clients send nonstandard HTTP traffic through TCP port 80. When this traffic is allowed by a matching access rule that uses the predefined HTTP protocol and is configured to allow traffic from the VPN Clients network to the Internal network, the Web Proxy Filter is invoked and rejects this traffic because it does not comply with HTTP standards. To allow nonstandard HTTP traffic to reach your nonstandard HTTP server, you can create a custom protocol definition that has a primary connection for outbound traffic through TCP port 80 and is not associated with the Web Proxy Filter. We will refer to this protocol as the CustomHTTP protocol.
To allow the nonstandard HTTP traffic, you need to create two access rules:
The new allow rule must come before your original rule that allows HTTP traffic from the VPN Clients network to the Internal network in the ordered list of policy rules, and the new deny rule should be placed immediately after the new allow rule.
The following table lists the rules that you should have to enable traffic in this scenario:
Order
Name
Action
Protocols
From
To
1
Allow CustomHTTP to Nonstandard HTTP Server
Allow
CustomHTTP
VPN Clients
Nonstandard HTTP Server
2
Deny HTTP to Nonstandard HTTP Server
Deny
HTTP
3
Allow HTTP to Internal Servers
Internal
4
Default rule
All Traffic
All Networks
So why do we need the new deny rule (the second rule)? The short answer is that this rule is needed to prevent the third rule or any other rule from invoking the Web Proxy Filter for traffic that matches the first rule.
To understand why this rule is needed, you need to know how ISA Server processes traffic sent to a port that is associated with overlapped protocols. When traffic arrives at a port that is associated with overlapped protocols, the first policy rule that matches the traffic for each of the overlapped protocols (the HTTP and CustomHTTP protocols) is found, and the rule that is highest in the list of rules is applied. In our case, that would be the first rule with the CustomHTTP protocol, which allows traffic to the nonstandard HTTP server but does not invoke the Web Proxy Filter. In addition, all the rules for the overlapped protocols in the ordered list of rules are processed, their secondary connections are added to the session, and the application filters associated with them are invoked until an access rule that denies traffic is encountered. In our case, the second rule, which is a deny rule, stops this processing. Without the second rule, the third rule would be processed for traffic that matches the first rule, and the Web Proxy Filter would be invoked for it.
If the Web Proxy Filter would be invoked by the third rule, the Web Proxy Filter would discover that the traffic does not conform to HTTP standards. The Web Proxy Filter would then block the traffic and add an entry to the Web Proxy log indicating that the Allow HTTP to Internal Servers rule blocked the traffic.
Microsoft has put together a comprehensive and technical article Windows Time and the W32TM service explaining how the Windows Time service works and how the time on desktop machines is synchronized with the server. There are some best practices that you need to consider as tips as well as a comprehensive troubleshooting section at the end of the article. It's a very useful article, and one that simplifies quite a complicated topic. For more information, please read the article here.
Support for Microsoft Windows XP Service Pack 1 (SP1) and Service Pack 1a (SP1a) ended on October 10, 2006. This also includes security updates for these service packs.
http://support.microsoft.com/gp/lifean19
The Microsoft Exchange Analyzer Tools, including Exchange Performance Troubleshooting Analyzer (ExPTA), Exchange Mail Flow Analyzer (ExMFA), Exchange Disaster Recovery Analyzer (ExDRA), are designed and developed to help troubleshooting various problems for customers running an Exchange Server environment. The following article shows a quick summary of the tools’ functions and provides some Microsoft Product Support Services success stories that may help to resolve typical problems in performance, mailflow and database recovery areas.
http://wwwppe/technet/prodtechnol/exchange/articles/analyzersuccess.mspx
Some shared printers print tons of pages containing only a date unexpectedly. It may be caused by Virus W32.Looked.AH (rundl132.exe) . This virus has the following symptoms:
a. Shared printers print a lot of pages containing only a date.
b. The “rundl132.exe” and “logo1_.exe” files exist in the %windir% folder.
c. Dll.dll file exists in the %windir% folder.
Please contact your anti-virus vendor to fix the issue by updating the latest virus data. Please refer to: http://www.symantec.com/security_response/writeup.jsp?docid=2006-091513-2550-99&tabid=2
More Information: This virus creates a “_desktop.ini” file in multiple folders. It can copy _desktop.ini to file and printer shares on the network. In the “_desktop.ini” file, it only contains a date. Once the _desktop.ini is copied to a shared printer, this printer will print out the date and time.
MS06-049 has been revised and re-released for Microsoft Windows 2000 Service Pack 4 to address a known issue on Windows 2000 SP4. After installing the original version of security update 920958 (MS06-049) on a computer that using NTFS file system compression, compressed files larger than 4 kilobytes (KB) may be corrupted when creating or updating the files. If you have downloaded the update prior to September 26th, 2006 please download it again to make sure you have the newest version.
http://www.microsoft.com/technet/security/bulletin/ms06-049.mspx
During the deployment of Live Communications Server 2005 Enterprise Edition, there are several scenarios that should be avoided. These scenarios are not supported by Microsoft. Here are two of them:
Scenario 1:
Live Communications Server Backend database and Live Communications server Front end server are installed on the same server.
Scenario 2:
When deploying Live Communications Server 2005 Enterprise Edition, hardware load balancer is not configured in front of the Front End server.
These two scenarios easily occur and should be avoided. They are known to cause issues.
The following Live Communications Server 2005 Enterprise Edition (EE) server configurations are supported:
§ One EE server configured as an Enterprise Pool behind a hardware load balancer, with the back-end database on a separate computer.
§ Two or more EE servers configured as an Enterprise Pool behind a hardware load balancer, with the back-end database on a separate computer.
§ Two or more EE servers configured as an Enterprise pool behind a hardware load balancer, with a Communicator Web Access server colocated on one or more of the EE servers that make up the Enterprise Pool, and with the back-end database on a separate computer.
For more information about the supportability information of Live Communications Server 2005, please refer to the supportability guide that can be downloaded from the link below:
Live Communications Server 2005 Document: Supportability Guide
http://www.microsoft.com/downloads/details.aspx?familyid=e71bd1cd-5bd0-4293-8586-dd998060faf8&displaylang=en