Exchange Resource Manager Ex::ReallocateOrganizationMailNoMove
ReallocateOrganizationMailNoMove 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.
Important
This procedure is deprecated and has been moved to the Exchange Resource Manager namespace. A pass-through to the new procedure is kept in this namespace to maintain backwards compatibility. Developers working with Exchange Resource Manager should call the Exchange Resource Manager::ReallocateOrganizatoinMailNoMove instead.
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.
|
<Preferred domain controller> |
Yes |
Note
In this procedure, the <megabytes> parameter is relative. Positive numbers increase the allocation. Negative numbers reduce the allocation.
Remarks
No remarks.
Sample Code
Example XML Request
<request>
<procedure>
<execute namespace="Exchange Resource Manager Ex"
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
Exchange Resource Manager Ex Namespace API for:
Hosted Messaging and Collaboration version 3.5
Hosted Messaging and Collaboration version 3.0