Enterprise Vault Best Practice Registry Keys and Boot.ini Settings

Article:TECH71173  |  Created: 2009-01-05  |  Updated: 2014-03-11  |  Article URL http://www.symantec.com/docs/TECH71173
Article Type
Technical Solution

Product(s)

Environment

Subject

Issue



Enterprise Vault Best Practice Registry Keys and Boot.ini Settings


Solution



Warning: Incorrect use of the Windows registry editor may prevent the operating system from functioning properly. Great care should be taken when making changes to a Windows registry. Registry modifications should only be carried-out by persons experienced in the use of the registry editor application. It is recommended that a complete backup of the registry and workstation be made prior to making any registry changes.

 
 
In Enterprise Vault 10.0.1 and later the best practice settings are described in the Installing and Configuring manual. Do not use this technical note with Enterprise Vault 10.0.1 or later.
 
The following settings can now be set automatically in Enterprise Vault  8 but are applicable in all versions of the product earlier than 10.0.1:

Note: The registry key paths below are typical of a 32-bit Microsoft Windows operating system.  Some of the paths will be different for a 64-bit Microsoft Windows operating system. Some changes are applicable for just Windows 2003 and some just for Windows 2008, where neither is specified then the change is applicable for both Operating Systems

1. Memory Management

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Dword value: PagedPoolSize
Value data (Hex): ffffffff
***Note: For systems with 2GB of memory, this should be set to a value of 0

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Dword value: PoolUsageMaximum
Value data (Hex): 0000003c

Enterprise Vault utilizes Microsoft Message Queueing (MSMQ) for Exchange archiving. MSMQ utilizes resources under control of the Operating System (OS) Memory Management. Several factors may deplete the supply of paged pool memory. By default, the Memory Manager tries to trim allocated paged pool memory when the system reaches 80 percent of the total paged pool. The possible maximum paged pool memory on a computer is 343MB of paged pool, and 80 percent of this number is 274MB. If the Memory Manager is unable to trim fast enough to keep up with the demand, the Server service may repeatedly log an error in the System Event log that indicates that the server is out of paged pool memory. By tuning the Memory Manager to start the trimming process earlier, it would be possible to keep up with the paged pool demand during sudden peak usage, and avoid running out of paged pool memory.

For more information please see http://msdn.microsoft.com/en-us/library/ms811056.aspx
 
Note: Only applicable when archiving from Microsoft Exchange.


2. MSMQ Kernel Memory Threshold

HKLM\SOFTWARE\Microsoft\MSMQ\Parameters
Dword value: KernelMemThreshold
Value data (Hex): 0000005f

Why? Enterprise Vault utilizes MSMQ for Exchange archiving. If you send or receive Microsoft Message Queue Server (MSMQ) messages, you may receive errors as MSMQ stops allocating kernel memory when the kernel memory consumption exceeds 80 percent of the total available. You can send and receive messages again when the kernel memory consumption reaches less than 80 percent of the threshold. When applying the best practice setting, you are raising the threshold because file caching is consuming kernel memory. Typically, garbage collection is done by the kernel only when the memory consumption reaches 90 percent. However, because MSMQ stops allocations at 80 percent consumption, the kernel doesn't reach 90 percent, and therefore, does not clean up unused kernel memory. By allowing the best practice setting to set the kernel memory threshold to 95 percent (5f Hex), this activates the kernel cleanup code.

Note: KernelMemThreshold is NOT required if you have applied the Update Rollup 1 for Microsoft Windows 2000 Service Pack 4 as MSMQ 2.0 has been recoded to not stop working at 80%. Instead, it will rely on the operating system to manage things properly (which, by the way, is how MSMQ 3.0 works so setting KernelMemThreshold will have no effect on Windows XP/2003/Vista/etc.). If you have the rollup and apply the KernelMemThreshold registry change then MSMQ 2.0 will honor the value you have set.
 
Note: Only applicable if archiving from Microsoft Exchange. 
 
3. MaxMSMQMessageSize

32bit - HKLM\SOFTWARE\KVS\Enterprise Vault\Storage
64bit - HKLM\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Storage

Dword value: MaxMSMQMessageSize
Value data (Hex): 00380000

Occasionally bottlenecks occur on MSMQ's which may be alleviated by applying the MaxMSMQMessagesize key. By default there is a 4MB size limit for both the body and message, and on occasion the size of the message can exceed this limit, so by setting this value allows Message Queue requests with a large message size to pass. Please refer to TechNote http://www.symantec.com/docs/TECH54332 as an example of when we request it to be applied, and why it is one of our best practice registry keys

Note: Redundant as of EV2007 sp4. This issue was fixed.
Note: Only applicable when archiving from Microsoft Exchange.

4. MSMQ Storage Limit

On a 32-bit Server (Ex. Windows 2003) 

1. Open Computer Management and expand Services and Applications
2. Right click on Message Queuing and click Properties.
3. On the General tab increase the 'Limit message storage' setting to 3145728  KB (3 GB) or less.  
4. Restart the Message Queuing Service.
See the following Microsoft article regarding MSMQ performance:
 
On a W2K8 Server
1. Open Server Manager, expand Roles and expand Application Server
2. Right click on Message Queuing and click Properties.
3. On the General tab increase the 'Limit message storage' setting to 8388608  KB. 
4. Restart the Message Queuing Service.

If MSMQ is clustered the please refer to http://www.symantec.com/docs/TECH57598 

This setting limits the size in which the MSMQ location can grow. By default the limit is 1Gb and it has been observed that a higher value is suitable for most EV environments. Caution should be observed when increasing the MSMQ storage size limits in a 32-bit environment too large, as this can cause instability.
 
Note: Only applicable when archiving from Microsoft Exchange.

5. Disable Loopback Check

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Dword value: DisableLoopbackCheck
Value data (Decimal): 00000001

Why? An issue has been found on Enterprise Vault servers that have been configured with Aliases. When you use the fully qualified domain name (FQDN) or a custom host header to browse a local Web site that is hosted on a computer that is running Microsoft Internet Information Services (IIS) 5.1 or IIS 6, you may receive an error message that resembles the following: HTTP 401.1 - Unauthorized: Logon Failed. This issue occurs when the Web site uses Integrated Authentication and has a name that is mapped to the local loopback address. Windows Servers include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name. By disabling the loopback check, you avoid "Access Denied" errors in the VAC and Event ID 40974 in the Event Logs.

6. Disable Strict Name Checking

HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
Dword value: DisableStrictNameChecking
Value data (Decimal): 00000001

Why? Enterprise Vault utilizes DNS Aliases for optimized design and scalability. When a client computer connects to a Windows server by using an alias name, the client may receive an error message. This problem tends to occur when trying to connect to the server by using a CNAME alias that is created in the DNS zone. The server is not "listening" on the alias, and therefore is not accepting connections to that name. By requesting to disable strict name checking, this issue is resolved

For more information please see http://support.microsoft.com/default.aspx?scid=kb;en-us;281308

7. TCPIP Max User Port and TCP Times Wait Delay

For Windows 2003:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Dword value: MaxUserPort
Value data (Hex): 0000fc00 (64512 dec) 

For Windows 2008:
To display the current ports for the TCP protocol use the netsh command
netsh int ipv4 show dynamicport tcp
To increase the ports use the net shell command
netsh int ipv4 set dynamic tcp start=1500 num=6300


HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Dword value: TcpTimedWaitDelay
Value data (Hex): 00000078

Why? Under certain conditions when Enterprise Vault archives items, the default number of ephemeral ports for TCP/IP client connections may be inadequate. If this happens, some items will not be archived from the server and you may see error messages in Enterprise Vault. By setting these values, you avoid the scenario of TCP/IP port exhaustion.

For more information please see: http://msdn.microsoft.com/en-us/library/aa560610.aspx

8. Disable Opportunistic Locking

HKLM\SYSTEM\CurrentControlSet\Services\MRxSmb\Parameters
Dword value: OplocksDisabled
Value data (Decimal): 0000001

Or,

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Dword value: EnableOplocks
Value data (Decimal): 0000000

 Opportunistic Locking on a server hosting the Alta Vista indexing engine has been found to cause locking issues with the index files which could lead to index problems. By requesting the server to not perform opportunistic locking, you improve index stability.

For more information please see http://support.microsoft.com/kb/296264

9. Remove the 3GB memory setting, /3GB switch in boot.ini

Why? It has been discovered that setting the 3GB switch in the boot.ini on servers running the Alta Vista indexing engine with 4+GB of RAM may lead to index failures. By removing this setting, you improve index stability.

10. Remove the /PAE switch in boot.ini

Why? It has been discovered that setting the PAE switch in the boot.ini on servers running the Alta Vista indexing engine with 4+GB of RAM may lead to index failures. By removing this setting, you improve index stability.

11. ArchiveListChunkThreshold

32bit - HKLM\SOFTWARE\KVS\Enterprise Vault\Directory\DirectoryService
64bit - HKLM\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Directory\DirectoryService

Dword Value: ArchiveListChunkThreshold
Value data (Hex): 000003e8

Why? This registry key helps the administration of archives in the administration console, and will offer a small performance gain, by splitting the number of archives listed into subcontainers. For example with the best practice value of 1000, if you have 5000 mailbox archives you will get 5 subcontainers
Note: Not applicable Enterprise Vault 10 and above

12. AvsMaxLoc

32bit - HKLM\SOFTWARE\KVS\Enterprise Vault\Indexing
64bit - HKLM\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Indexing

Dword value: AVSMaxLoc
Value data (Decimal): 500000000

Note:  Starting with versions 7.0 SP3 and 2007 SP2, AVSMaxLoc is now defaulted to 1 billion. Setting AVSMaxLoc through the registry is no longer recommended or required.  
An ideal value for this key has not been set, however in many cases 500,000,000 has proven to be beneficial. Engineering is currently investigating the advantages and disadvantages of modifying this setting and it is generally recommended for Clearwell, Compliance and Discovery Accelerator customers.

Why ? An index defaults to allowing just over four billion locations before rolling over to additional indexes. (This is around 19 GB in size, representing about five million typical documents.) However, you can change this default at an indexing service or per-vault basis.
Note: Not applicable Enterprise Vault 10 and above 

13. SchemaType

32bit - HKLM\SOFTWARE\KVS\Enterprise Vault\Indexing
64bit - HKLM\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Indexing

Dword Value: SchemaType
Value data (Decimal): 0
 
Why ? With this value set to 0 (the default), when a mail item has an attachment of any type, Archive Explorer and Search will display the mail item and each attachment as separate items within the selected archive.  If this value is set to 1 (non default), a mail item that has an attachment of any type in Archive Explorer and Search will display them altogether as one item, making the search results more reflective of the mail item that was archived.

For more information on this key please review the TechNote,  http://www.symantec.com/docs/TECH50331 - How to enable SchemaType also known as ItemGranularityOnly

Note: Starting with Enterprise Vault 8.0 there is now a JournalSchemaType registry key with a default setting of "1" which sets the item granularity schema for Journal archives.  The SchemaType will then only effect non Journal Archives.  

Note: It should be noted that neither of these values exist in a default installation, so there default values as listed above are applied.
Note: Not applicable Enterprise Vault 10 and above 

14. SearchChunkSize

32bit - HKLM\SOFTWARE\KVS\Enterprise Vault\Indexing
64bit - HKLM\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Indexing

Dword Value: SearchChunkSize
Value data (Decimal): 5000 (default)

Why? This change is meant to throttle-back Compliance or Discovery Accelerator so that less of a demand is placed upon the indexes. Desired result is that the searches can then be conducted without failing the indexes or receiving errors during the search. These changes will also impact performance. This sets the maximum size of each search chunk.
 
Note: Not applicable Enterprise Vault 10 and above 

Note the two related performance / best practice tuning TechNotes below.



Legacy ID



326236


Article URL http://www.symantec.com/docs/TECH71173


Terms of use for this information are found in Legal Notices