もう少し何がどうなのかを 正確に確認した方が良いかもしれないですね。
そもそも論。
Exchange Server にとっての空き容量について。
priv1.edb / priv1.stm のデータベースファイルの合計サイズが １０GBだった場合。
このデータベース内にメールボックスを作成されている10名のユーザー user1 ～ user10 の保持データ量が現時点で9GB だった場合、
Exchange Server 的には、データベース内に 1GB の空き容量が空いている、と認識しています。
この空き容量を増やしたい場合、
１． 各ユーザーの不要なメールを削除する。（削除済みアイテムフォルダも空にする）
２． データベースのプロパティの削除済みアイテム保存期間を 0日 にする。
３． クリーンアップを実行する。
という手順で、もし各ユーザーが 100MB ずつ 不要メールを削除してくれていたら、 データベース内に 1000MBの空き容量が増えます。
priv1.edb / priv1.stm の物理ファイルサイズは変更されません。 10GBのままですが、内部の未使用領域が広がり、約2GBの空き容量を確保できます。
メールボックス単位の使用量制限について
データベースなにがしと関係なく、 user1 に対してメールを送信する 容量不足で弾かれるとか、 user1 がメールを送信しようとすると容量不足で弾かれる というのは
メールボックスデータベースのプロパティまたは受信者のアカウントのプロパティのどちらかで、 送信を禁止するサイズ、 送受信を禁止するサイズが設定してあり、
user1 の保持するサイズがその制限値を上回っている可能性があります。
その場合は、 user1 に不要なメールを削除させる、 か ディスクの空き容量に余裕があるなら、制限値を緩和する。
物理ディスク領域の不足
サーバーのデータ領域のハードディスク容量が 100GB で、 データベース容量が 40GBぐらいの場合。
→ 前述の3手順を実施して、そもそもデータベース内部の空き容量（物理的に圧縮されても構わなくなる領域）を広げます。
１． データベースの完全バックアップを取得します（Exchange Serverデータベースのバックアップに対応しているバックアップソフトでバックアップを実行します）
バックアップを取得したことにより、データベース内の空き領域が物理サイズとして縮小されていい形にマークされます。
※ もしかしたら、クリーンアップを実行する前にバックアップを取った方がより良かったかもしれません。
２． オフラインデフラグを実施します。
オフラインデフラグは、元のデータベースサイズｘ１．２倍の空き容量が必要になる事があります。 40GBのデータベースに対して処理すると 48GBの空き容量が
ないと失敗する可能性があります。
この例では、60GB 空き容量があるので実施できることになります。 もし、データベースサイズが 50GB を超えていたら、空き容量が元のデータベースサイズを下回るので
オフラインデフラグは失敗する可能性が高くなります。
オフラインデフラグに成功すると、最終的なデータベースの物理サイズが小さくなります。
物理サイズ 40GB 中 空き容量が 10GB 確保できていたとしたら、 最終サイズは 30GB くらいになる可能性があります。
メーラーで受信する、の意味するところが Exchange Server 側メールボックスないのデータを全部クライアント側に移す、という事であれば、
その後にクリーンアップ手順が必要になると思います。
仮にその Exchange環境が本番環境でなくテスト環境で有り、メールデータその物どうでもいいのであれば、すべてのユーザーのメールボックスを削除して
すべてのユーザーの Exchange属性もクリアして、 そもそもデータベースを削除して、データベースそのものを作り直す、というのも
アリかな、とは思います。
