Set your limit to somewhat less than the hard limit as per the technet articles and wait for your eventlog to fill up :-) Cheers, Phil -- Phil Randal | Networks Engineer Herefordshire Council | Deputy Chief Executive's Office | I.C.T. Services Division Thorn Office Centre, Rotherwas, Hereford, HR2 6JT Tel: 01432 260160 email: [email protected]
Any opinion expressed in this e-mail or any attached files are those of the individual and not necessarily those of Herefordshire Council. This e-mail and any attached files are confidential and intended solely for the use of the addressee. This communication may contain material protected by law from being passed on. If you are not the intended recipient and have received this e-mail in error, you are advised that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. If you have received this e-mail in error please contact the sender immediately and destroy all copies of it. ________________________________ From: McCready, Robert [mailto:[email protected]] Sent: 20 March 2009 12:31 To: MS-Exchange Admin Issues Subject: RE: Named Property Limit Another quick question. Is there any way to see how close we are to the 32k hard limit today? ________________________________ From: Alex Fontana [mailto:[email protected]] Sent: Friday, March 20, 2009 1:05 AM To: MS-Exchange Admin Issues Subject: Re: Named Property Limit Seems this turned into a b-ch fest rather than answering your original question...;-) While I agree this is a ridiculous characteristic in the design and one that opens us up for DoS attacks (eventually), it is what it is and we need to figure out how to work around it. You have a few options; increase the limit, move users off, or find out what is causing it and stop it. My first suggestion is to take inventory of where your databases are as far as named props are concerned, you need to expose some IS counters to see this info, but it'll give you an understanding on whether it's widespread or concentrated on a set of databases (or users). Next start monitoring your event logs. An event ID is logged by default each time a new named prop is added (event id 9873 I believe) and when the quota's been reached (9666, 7, 8, 9). This can help you track down the culprit. Note, the initial limit reached is the default quota...not the limit. My understanding is that when the hard limit (32k) is reached the database will dismount and you will have to restore from backup and move users off. In my situation I found that less than a dozen users were creating hundreds of named props daily for weeks. This was the result of an open source imap client called offlineIMAP. This client is used to bidirectionally synch messages via IMAP. It does this by creating a unique X-header for EVERY message that comes in, as opposed to a single X-header with a specific value. After finding this out I reached out to the users, and being the ridiculously intelligent (and curious) crew they are they crafted a patch for offlineIMAP (http://software.complete.org/software/issues/show/114). Hope this helps. -alex ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~
