Hi, I have an problem that has happened a few times to me with my Exchange 2007 serverWhen I change the permission on the Exchange server (such as add the Administer Infomation Store) it does not work, this is being applied at the store level.Howerver running get-mailboxpermission has everything appearing fine, the Administer Information Store looks like it has been applied.When I reboot the exchange server, it now works.So why is it that the permission is applied but does not take effect until a reboot of the Exchange server happens? I've had other Exchange 2007 servers in the past that have not had this issue, and also have had other ones that have also had this issue but I cannot determine what might be the cause.A Windows KB would be be great if there is one I haven't been able to find.

Permissions like this are held in Cache, the time to update is generally around two hrs. Obviously the reboot writes all data to exchange and clears an cached info. Took me a long time with a guy from Microsoft to find that out.... Thats why when changing quotas for example can take a while.

The cache refresh interval is 2 hours by default like Martin said. You can adjust it lower if there is a need. Here's a link to the technet article:http://technet.microsoft.com/en-us/library/bb684892(EXCHG.80).aspx

I don't think you have to re-boot the server to force an update, just restart the IS.

I'll try the restart of the IS next time to see if that works as well.

Ok so while a cache makes sense, that specific cache doesn't fit here.I've at times left it for over 2 hours (3 to 6 hours at times) still will no luck for it.And none of the exchange server's I've worked on had the cache changed. So where it worked right away instantly, they still had the default 2 hour setting. And others that didn't work (and left for 2+ hours) still didn't work until the reboot.Is there a KB that better explains the cache and what is contained in it?Ideally, I'd like a way I can replicate this by adjust any cache settings so I can prove beyond an doubt the cause.Appericate the help so far, thanks all!

Hi,First I'd like to know how did you add the mailbox permission, from EMC? From EMS? From ADSIEdit? Please let me know the detail steps.We recommend to use Add-mailboxpermission from EMS. We can grant permission to all the users via the following cmdlt.get-mailbox | add-mailboxpermission -user <username> -accessright fullaccess -inheritancetype all.Besides, how many exchange server roles in the network?How many domain controllers in the network?Regards,Xiu

Hi, thank you very much for the reply.The permission was applied using the following command:get-mailboxserver SERVERNAME | add-adpermission -user USERNAME -accessrights GenericRead, GenericWrite -extendedrights ms-Exch-Store-AdminThe goal is to grant the user named here access into all the mailboxes on the server. DC's will vary from 2 to 6 usually. Exchange server roles, everything is usually installed on a single Exchange box, though I could have more then one Exchange server, but each one generally has everything installed on it.I support various companies, and have see this issue happening on some of their networks but not all of them.

Hi, The information store caches information contained in the directory store and, by default, it re-reads it every 120 minutes. Therefore, any change to a directory object is not reflected in the information store for two hours. If the store is busy then this may take longer. The fastest way to update store cache is by restarting the Information store service. So, for immediate results a restart of the Information store is necessary and if this process is left alone it will take a couple of hours to reflect changes, depending on how busy the store is. The entries in the MBI cache are controlled by two registry settings. The Mailbox Cache Age Limit setting and the Mailbox Cache Idle Limit setting control how long the entries in the MBI cache survive. The default values for these settings are 120 minutes and 15 minutes. It is recommended to keep these values to default. Mailbox Cache Idle Limit has been set http://technet.microsoft.com/en-us/library/aa996988(EXCHG.80).aspx To have changes to directory objects picked up immediately by the information store, follow these steps: 1. Run Registry Editor (Regedt32.exe). 2. Locate the following key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem 3. On the Edit menu, click Add Value. 4. Enter Mailbox Cache Age Limit for the Value name. 5. Type REG_DWORD for the Data type. 6. Type 1 for the Data of type DECIMAL, and then click OK. NOTE: This registry entry is not a switch, it is a setting. If it is set to 1 the server rereads the cache every minute; if it is set to 2 the server rereads the cache every 2 minutes, and so forth. 7. Stop the information store service. 8. Restart the information store service.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Mailbox Cache Idle Limit This value is in minutes. Make sure that the Cache Idle Limit value is not greater than the Mailbox Cache Age Limit value. The default value is 15 minutes. If the Cache Idle Limit value is set higher than the Mailbox Cache Age Limit value, then Cache Idle Limit value will be equal to the Mailbox Cache Age Limit value.Note: AD replication will happen 15 minutes, during that time Exchange performance will be affected. So please do not change the time to short. Besides, if the OS for Exchange Server is Windows Server 2003, then please check if you have RSS and TCP Offload enabled. Windows 2003 Scalable Networking pack and its possible effects on Exchange http://msexchangeteam.com/archive/2007/07/18/446400.aspx An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computershttp://support.microsoft.com/kb/948496/en-us Regards, Xiu

And by doing the above has a performance overhead knock on which is not recommended.

Not recommended though.

Not true. In over a decade of recommending people set this value to something like 15 minutes nobody has ever reported any performance issue.-- Ed Crowley MVP"There are seldom good technological solutions to behavioral problems.". "theMadferret" wrote in message news:97cab730-9058-4dfa-8879-0ea0556a33f9...And by doing the above has a performance overhead knock on which is not recommended. Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi, Since AD replication happen in 15 minutes, if you do have a lot of DCs and do not want to impact the Exchange performance any more, then please do not set it to 15 minutes. Regards, Xiu

Please provide a reference for that recommendation, because never have I seen such a statement from Microsoft. Further, I do not understand how increasing the database permissions refresh interval to fifteen minutes has anything to do with the default replication schedule of AD. Would you please explain further?-- Ed Crowley MVP"There are seldom good technological solutions to behavioral problems.". "Xiu Zhang - MSFT" wrote in message news:f715f7da-bd92-49cf-b08b-d6e7742407f7... Hi, Since AD replication happen in 15 minutes, if you do have a lot of DCs and do not want to impact the Exchange performance any more, then please do not set it to 15 minutes. Regards, Xiu Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi Ed, That recommendation is from our premier team. Anyhow, we do not recommend to change these value. If you do want to change, then I recommend you to not to set to be 15 minutes. It is just a note. Regards, Xiu

So you don't have a reference for that guidance? It would certainly be nice to have that published somewhere. Ever since the dawn of time, i.e., Exchange 4.0, we've been recommending that administrators set this value to some value as low as 15 minutes (some recommend even shorter) and not once have I ever seen feedback that setting that has caused any problems. And we were making that recommendation way back when we were running Pentium IV systems with 2GB of RAM and 10Mb networks. Further, Microsoft's own KB articles (http://support.microsoft.com/kb/327378) have instructed users on how to make the change and even say, "The default value is two hours (7200). The recommended value is 20 minutes (1200)." Now, 15 minutes isn't a lot different from 20 minutes.-- Ed Crowley MVP"There are seldom good technological solutions to behavioral problems.". "Xiu Zhang - MSFT" wrote in message news:e4a4e7bd-3f77-4c87-9efd-0f3d295f7e00... Hi Ed, That recommendation is from our premier team. Anyhow, we do not recommend to change these value. If you do want to change, then I recommend you to not to set to be 15 minutes. It is just a note. Regards, Xiu Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

15 minutes isn't much less than 20, but it's the replication interval of the DC. If they're both set for 15 minutes, and they get in synch (think power failure, and then everything comes up at the same time), then you've got DC replication and Exchange replication happening at the same time, every time, and maybe that could be a bad thing. Or, maybe not.

Why?-- Ed Crowley MVP"There are seldom good technological solutions to behavioral problems.". "mjolinor" wrote in message news:5acab28b-347c-48f6-b260-c5d603867022... 15 minutes isn't much less than 20, but it's the replication interval of the DC. If they're both set for 15 minutes, and they get in synch (think power failure, and then everything comes up at the same time), then you've got DC replication and Exchange replication happening at the same time, every time, and maybe that could be a bad thing. Or, maybe not. Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi Nynx, How is the issue now? Regards, Xiu

Hi Xiu Zhang, Where is the documentation of your warning against changing the refresh interval? Regards, Ed -- Ed Crowley MVP"There are seldom good technological solutions to behavioral problems.". "Xiu Zhang - MSFT" wrote in message news:9f64a516-7511-4f9e-9217-cf3d17ae0fe0... Hi Nynx, How is the issue now? Regards, Xiu Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi, I think we can get more idea from the following sentence, I quote from the article below: It should be understood that decreasing the Time to Live (TTL) of Information Store cache must be tested in a live production environment. Shorter cache life will mean that there will be more queries against the domain controllers and GCs and possibly performance effect has to be understood. We recommended not to set the value any smaller than 20 minutes. Exchange 2003 SP2 Disabling Mapi/Non-Cached Access Per User-Troubleshooting protocolSettings changes http://technet.microsoft.com/en-us/library/bb219050(EXCHG.65).aspx Regards, Xiu

Thank you. What you now say is very different from your earlier statement, "Anyhow, we do not recommend to change these value." In fact, KB article 327378, which is linked but the number is typed wrong in the article you quote below (it says 32738) says, "The recommended value is 20 minutes (1200)," consistent with your revised position. Further, there is no mention in that KB that this number has anything to do with AD replication, just performance, and since countless administrators have set this value to 15 minutes over the past decade and more with no ill effect, I will stand by my position that 15 minutes isn't much different from 20 minutes.-- Ed Crowley MVP"There are seldom good technological solutions to behavioral problems.". "Xiu Zhang - MSFT" wrote in message news:9fe64b3c-fe92-486a-afe5-64cc00980e73... Hi, I think we can get more idea from the following sentence, I quote from the article below: It should be understood that decreasing the Time to Live (TTL) of Information Store cache must be tested in a live production environment. Shorter cache life will mean that there will be more queries against the domain controllers and GCs and possibly performance effect has to be understood. We recommended not to set the value any smaller than 20 minutes. Exchange 2003 SP2 Disabling Mapi/Non-Cached Access Per User-Troubleshooting protocolSettings changes http://technet.microsoft.com/en-us/library/bb219050(EXCHG.65).aspx Regards, Xiu Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."