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
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
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
This is the Lightweight Directory Access Protocol (LDAP) path
of the organization that will own the resources.
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
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.
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.
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.
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>
In this procedure, the <megabytes> parameter is relative.
Positive numbers increase the allocation. Negative numbers reduce