Exchange Resource Manager::ReallocateOrganizationMailNoMove

This procedure changes the amount of mail storage that an organization is permitted to use. This procedure will fail if there is insufficient room in the system for the requested new storage, or if any explicitly requested mail store is unavailable.

This call can automatically decide how to increase mail storage allocated to an org using the <mailStore><megabytes> parameter, but there is no good widely applicable algorithm for reducing storage size if the org has more than one mail store allocated to it. Therefore, reducing allocation when more than one store is already allocated requires explicit reallocation using the <sourceMailStores> parameter.

Arguments

Input argument	Required	Description
<organization>	Yes	This is the Lightweight Directory Access Protocol (LDAP) path of the organization that will own the resources.
<mailStore><megabytes>	Yes	This is the change in mail storage available after the reallocation. If necessary, multiple mail stores may be allocated to the org to fulfill this request. This parameter is ignored if the <sourceMailStores> parameter is supplied. This parameter may only be negative if there is exactly one mail store allocated to the org. To reduce allocated mail storage when there are multiple mail stores allocated to the org, you must provide the <sourceMailStores> parameter to explicitly specify which stores are reduced by how much. This call always attempts to minimize the number of separate mail stores allocated to an organization.
<mailStore algorithm="minStoreCount">	No	Only used when <sourceMailStores> is not supplied. Possible values of the "algorithm" attribute are "tightPack" and "minStoreCount", with "tightPack" as default. TightPack attempts to use the smallest number of mail stores for the system as a whole, with the tradeoff that each individual org may span more mail stores. MinStoreCount attempts to minimize the number of stores allocated to each org, with the tradeoff that the system as a whole may require more stores. MinStoreCount uses stores with the largest available space first, and tightPack uses stores with the smallest available space first. If the <shared> parameter is 0, then this parameter has relatively little effect, since every share considered is completely empty. For this operation, the system will attempt to allocate new storage using stores already allocated to the organization first.
<mailStore><shared>	Yes	If this parameter is 0 and new stores must be allocated to satisfy the <megabytes> parameter, the organization is given one or more mail stores which will not be shared with other organizations. (Unshared mail stores are those which were added using AddExchangeResources with their <shared> parameter as 0.) If the <mailStore><shared> parameter is 1, mail storage will be allocated from one or more shared mail stores. Shared mail stores may or may not be shared with other organizations. This parameter is ignored if <sourceMailStores> is supplied. Note You must always supply a <shared> parameter with a valid value of 0 or 1. This is true even in the case where <sourceMailStores> is supplied. In this scenario the parameter is effectively ignored, but failure to supply the <shared> parameter will result in an error.
<sourceMailStores>	No	If this parameter is supplied, then the automatic allocation behavior is overridden, and the <mailStore><megabytes> parameter is ignored. The <sourceMailStores> parameter specifies a set of mail stores to be allocated to this org. If any of the specifed stores is unavailable or has insufficient storage, or is allocated as an unshared store to another org, then the entire call will fail. <sourceMailStore/serverName> The name of the explicitly allocated store's server. <sourceMailStore/mailStoreName> The name of the mail store on the server. <sourceMailStore/megabytes> The change in the amount of mail storage to allocate on this mail store. <sourceMailStore/@op> Possible values for this attribute are "allocate" and "deallocate"" and not present. If not present, it defaults to "allocate". If this attribute is "deallocate", the store is deallocated from the org and the <sourceMailStore/megabytes> parameter is ignored. If the attribute is "allocate", the mail store is allocated to the org, and the <sourceMailStore/megabytes> parameter specifies the initial allocation. If the mail store is already allocated to the organization, then the <sourceMailStore/megabytes> specifies a change in allocation, with negative numbers reducing allocation and positive numbers increasing it.
preferred domain controller	Yes

Important

The <megabytes> parameters in this call are all relative. Positive numbers increase the allocation. Negative numbers reduce the allocation.

Remarks

Sample Code

Example XML Request

<request>
	<procedure>
		<execute namespace="Exchange Resource Manager" 
				procedure="ReallocateOrganizationMailNoMove">
			<executeData>
				<organization>LDAP://ou=ExchOrg1,dc=raven01,dc=com</organization>
				<mailStore algorithm="minStoreCount">
					<megabytes>200</megabytes>
					<shared>1</shared>
					<sourceMailStores>
						<sourceMailStore>
							<serverName>RAVEN1</serverName>
							<mailStoreName>Mailbox Store (RAVEN1)</mailStoreName>
							<megabytes>200</megabytes>
						</sourceMailStore>
						<sourceMailStore op="allocate">
							<serverName>RAVEN1</serverName>
							<mailStoreName>Mailbox Store 2 (RAVEN1)</mailStoreName>
							<megabytes>200</megabytes>
						</sourceMailStore>
						<sourceMailStore op="deallocate">
							<serverName>RAVEN1</serverName>
							<mailStoreName>Mailbox Store 3 (RAVEN1)</mailStoreName>
							<megabytes>200</megabytes>
						</sourceMailStore>
					</sourceMailStores>
				</mailStore>
				<preferredDomainController>myPrimaryDC.raven.com
					</preferredDomainController>
			</executeData>
		</execute>
	</procedure>
</request>

Example XML Response

No example XML response.

Applies To