This may be a pure management issue, but in my experience this kind of decision devolves to the sysadmin staff to justify and enforce all too often. Because of this, it is my job as the sysadmin to convince management that there is a problem here and it should be taken seriously, and to posit management mechanisms that may be useful.
One of my old employers had a GroupWise system, which at the time didn't have any quota mechanisms in it (this was a while ago, GW has had it for some time now). So ultimately we resorted to a peer-pressure method. Each month we'd print off a report of the $X largest mail-boxes in each department and send the reports off to the office-managers. Within two months the top-5 list of largest mailboxes had a much smaller average size.
Some methods I've found useful for convincing management to pay attention to this issue:
Define the cost of mail storage
If you're getting the "but Google does it" pushback, start building spread-sheets that show how much mail costs. Managers understand cost. You, or the people you buy things through, have the costs for your server hardware, software, AV software, and other related costs. From this you can assign a dollars-per-MB number for mail storage. This allows you to give a decently good dollar value for a 3GB mailbox versus a 200MB mailbox.
This, by the way, is why you learned algebra back in school.
This can go one of three ways:
- They increase their mail-storage spend. They see the numbers, realized they're under-investing, and throw money at it to get to where you "should" be.
- They agree to provide downward pressure on mail growth in order to better control this cost.
- They say %*&!@ it! To the cloud!
Produce mail system upgrade costs
If the above is beyond your mad spreadsheeting skills, producing upgrade plans for keeping ahead of your storage consumption curve is a good way to at least get the conversation started. When they see bigbigmoney for upgrades, they'll ask why. And then you'll tell them. When they ask how they can avoid this cost, mention providing downward pressure on the big mail users.
I've done both of the above to justify simple storage purchases. The same techniques work for email, where you've got an entire application stack sitting on top of your storage/backup infrastructures. Dollars (or currency-of-choice) per unit is a great method of highlighting costs and the perils of overindulgence. Sometimes it can cause very significant strategic changes (see also, to the cloud!). Sometimes it can jar loose resources.
Politically speaking, it's a good idea to provide some suggestions for how to provide downward pressure for email consumption. But that's all they are, suggestions to the management who has to actually implement them or convince other managers to do so.
The issue is that you need to have some target mailbox and folder, or else the DeleteContent flag.
Search-Mailbox -Identity "April Stewart" -SearchQuery 'Subject:"Your bank statement"' -TargetMailbox "administrator" -TargetFolder "SearchAndDeleteLog" -LogOnly -LogLevel Full
The example above is a Log Only search that won't move any messages.
See the manual page for the Search-Mailbox command and note which switches are required.
http://technet.microsoft.com/en-us/library/dd298173.aspx
Best Answer
Following the procedure detailed by Mahias R. Jessen, http://technet.microsoft.com/en-us/library/ee633475(v=exchg.150).aspx , I manually regenerated the Full Text catalog index, which was causing the "Try using fewer keyword" error on Discovery Search (Exchange 2010 SP3).
In our case, since the server was not part of a DAG, the procedure was:
Stop-Service MSExchangeFastSearch
Stop-Service HostControllerService
Delete, move, or rename the folder that contains the Exchange content index catalog. This folder is named %ExchangeInstallPath\Mailbox\_Catalog\12.1.Single. For example, you might rename the folder C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 0657134726_Catalog\F0627A72-9F1D-494A-839A-D7C915C279DB12.1.Single_OLD.
Restart the two services
Wait for the server to complete the rebuild, you can monitor the event logs for event 109 (rebuild start) and 110 (rebuild complete), there will be one pair of event per database affected.
Restart the Exchange server (do not skip this step, in my case, Discovery Search was still broken until the restart)
Thanks Mathias for the help !