MapiExceptionNotAuthorized in Exchange 2007

I thought I would share with everyone an issue we had with mail delivery to Public Folders in Exchange 2007. We were receiving the following error:

#550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: "MapiExceptionNotAuthorized....

This happened for some staff, but others could deliver messages just fine. Also external users i.e. Hotmail could deliver messages to the PFs without issue.

You would imagine then there must be a deny rule somewhere for a specific group of staff, or there was something wrong with the permissions on the PF. Numerous tests and checks proved this to not be the case.

Fortunately a pattern started to emerge with the people having the problem i.e. they were all in the same faculty and members of specific groups. Further testing proved that if a user was a member of a few groups their messages/emails would be denied to ALL PFs. However the groups were not mentioned anywhere in the PF permissions.

We even created new mail enabled PFs and gave everyone full control with no denies... still no luck. After a bit more thinking we figured that it must be that Exchange is having trouble reading the group membersip. We soon found that the OUs containing the problem groups of which the problem users were members, had inheritance switched off and hence had not picked up the new Exchange 2007 permissions when we installed EX2007. They still allowed the old Exchange Enterprise Servers group acccess which worked for EX2003, but no access was in place for the EX2007 Exchange Servers group. The OUs had also had read permissions removed for Pre-Windows 2000 (Everyone) and Authenticated Users. Therefore Exchange was denying the user access as it could not fully recurse the users ACLs. I guess this is secure by default in action, although it seems like a bit of an inefficient design to me.

I hope this saves someone a bit of time as it took us ages to get to the bottom of it.

Exchange 2007 Outlook Web Access Old Passwords

Weird one yesterday. We had a customer who had fallen foul of a phishing email and entered their username and password in a web form. Surprise surprise their account was compromised and used for sending a huge amount of SPAM. As soon as we became aware of the problem the user changed their password. Because the spammer had already established a connection as this user the password change did not affect them and they carried on. No major surprises there. We had to lapse the account (disable) for the connection to be dropped (I wish Microsoft would provide a tool for checking/closing active OWA/IMAP sessions in Exchange). The surprise came when we found the user could continue to login to OWA/IMAP using their old password, although it could not be used for any other resources. With some investigation it seems that once a user has authenticated to a CAS server with a password, as long as the connection remains active (and for some time after) the old password can still be used to authenticate (open new connections) to OWA/IMAP. This is alarming in my opinion. The most alarming thing is that all connections can be closed and you can still login using the old password (although I don't know for how long).

This issue is per CAS server. We usually have two, so this issue would not be as obvious normally (as the server the user logged into using the old password is the only server that will allow logins to continue using the old password).

I am going to log a urgent call with Microsoft about this. For info we are using Exchange 2007 SP1 RU5 on one front end and Exchange 2007 RU5 on all backends. The other front end has recently been upgraded to RU7, but the issue remains.

Anyone else seeing this?

Support for Citrix Secure Gateway

08/07/09

We currently run Citrix PS 4.0. Due to support running out at the end of this year we have been looking at upgrading to XenApp and have run into confusion over whether Citrix Secure Gateway is still supported or if we need to switch to using Access Gateways. It seems that the general confusion about support for SG is fairly widespread, perhaps because Citrix really want customers to start using Access Gateways. Anyway, we did not need all the benefits that AGs have over SGs so through our helpful support people we put the question to our Citrix account manager. It took a while to get an answer (the confusion does not seem to be limited to customers), but the good news is that Secure Gateway support is directly linked to support for XenApp. Therefore SG 3.1 will be supported as long as XenApp 5.0 is supported. The following Citrix article explains a little more:http://support.citrix.com/article/CTX110115
Although this article is 3 years old we are told by Citrix that it is still valid.

With this info we can get on with our XenApp upgrade!

Appsense - Internal Server Error

01/07/09

I have been having fun trying to get Appsense 8.2 to work following the database being accidentally deleted by a colleague. Despite the Management configuration utility providing a facility to create a new database it refused to use its new database and kept trying to use old settings. I gave up and reinstalled.
The reinstall did not fix the initial problem I was seeing with loading the Management Console. Basically it reported that the server returned HTML instead of XML. When I went to the Management Server website directly it returned a 501 error, specifically related to custom HTML error pages using explicit paths. I opened all the web.config files (there are about six of them under the Appsense installation directly) and deleted the CustomErrors sections. All then worked.
I have no idea why and when this issue started. All I can imagine is that it is related to the installation of Windows 2008 SP2.

02/07/09

The very efficient chaps at Appsense spotted this blog entry and sent me the following link:

https://www.myappsense.com/content/knowledgebase/solutionDetails.aspx?sid=50120000000EW3dAAG

You will need a MyAppsense account to get to this, but as an Appsense customer you should have one. That will teach me for not checking the knowledge base articles before upgrading!

Anyway the issue is related to a Windows 2008 SP2 security change. The advice given in the article as the same as the way I fixed and problem. Importantly it does state that you should not change the %PROGRAMFILES%\AppSense\Environment Manager\Personalization Server% and PROGRAMFILES%\AppSense\Performance Manager\Central Statistics\Incoming web.config files (I better go and fix mine). It also states that the issue is fixed in v8 SP2, but I don't seem to be able to download that just yet.

Now onto why my upgraded v7 App Manager config causes my server to go totally nuts and stops a number of core services from starting and even entirely kills the network connection! I quess I'll be creating that from scratch :-).

Exchange 2007 IMAP RFC822.SIZE and Pine/Alpine

A common problem with Exchange 2007 IMAP when used with Pine/Alpine is alerts indicating that a message has shrunk. What is happening here is that Pine is retrieving the RFC822.size from Exchange, downloading the message and comparing the real message size with the size Exchange 2007 provides. Sadly there often is a huge discrepency, sometimes by as much as a factor of two. Interestingly Pine only checks for size decreases in case of data loss during copy hence you only see this message appear on some emails, not all. If Pine checked for message decreases and increases you would see it for pretty much all emails.

Microsoft have so far explained that the size returned by Exchange prior to Exchange 2003 was based on the MIME message stored in the STM database. As the STM database no longer exists in Exchange 2007 the RFC822.size is calculated based on the MIME skeleton and the original MIME message size. This is done for performance reasons. I have asked Microsoft for clarification as to why the original MIME size of the message is vastly different to the regenerated MIME message and am waiting for clarification.

There is an Alpine code change that will supress this message (if you are happy to lose the safety check), or you can apply a change to Exchange on either a server or on individual mailboxes. The setting is nothing secret but documentation is very scarce. It is worth mentioning that making this change has a performance penalty as it forces Exchnage to regenerate each message as MIME and then send the size of the regenerated MIME message every time a message size is read.

For the server:

Set-ImapSettings -EnableExactRFC822Size:$true

For each user:

Set-CASMailbox "username" -ImapUseProtocolDefaults:$false -ImapEnableExactRFC822Size:$true


Although this solves this particular problem, sadly other issues persist with Pine and Exchange 2007 like Pine crashing when opening messages with Digital signatures and Pine not handling multipart messages correctly. It seems that although these issues only appear in Pine/Alpine (and perhaps Mutt), it appears to be Exchange that is failing to follow the RFC standards (and Pine is a stickler for standards!).

I'm sure we will get there soon!

Exchange 2007 SP1 RU5 - IMAP Error 4999

Hi,

Like many other people we have been suffering from our Exchange 2007 SP1 RU5 IMAP service constantly falling over with the following error:

Watson report about to be sent to dw20.exe for process id: 6848, with parameters: E12, c-RTL-AMD64, 08.01.0336.000, M.E.Imap4, M.E.D.Common, M.E.D.G.OutboundCodePageDetector.AddText, System.ArgumentNullException, 3e79, 08.01.0336.000. ErrorReportingEnabled: False

The good news is that we have put a stop to this by isolating it to a specific user.

There are many records online about this being a known issue, which it seems is indeed the case and we have received the fix from Microsoft (which we intend to try on the 27/02) - KB960292. I will post how this goes. The problem relates to a null ID being presented during login that the IMAP service should ignore, but it fails instead.

Anyway, what I wanted to share is that we have isolated this issue to the Sea Monkey 1.1.14 client. All three installations we know of are causing this issue and we have worked around it temporarily by preventing the users from logging in using IMAP (they are using OWA temporarily instead).

Good luck if you are experiencing this problem.

Rob

Increasing Redirect to Voicemail Timeout on O2

When I received by lovely new HTC Touch HD I found I kept missing calls as there was a slight delay between the caller calling and the phone starting to make a sound. I contacted O2 and they told me to run the following command :

**61*901*10*??#

?? is the delay you want in increments of 5 up to 30. I went for:

**61*901*10*25#

Works a treat.

I hope this saves someone a bit of time.

This is the home email address of this recipient. It cannot be removed

It has been a while since I posted, but I came across a nuisance error this morning: "This is the home email address of this recipient. It cannot be removed". The address that could not be removed was not the primary address and what's more this was a mailbox, not a contact, so I could not just delete it without disrupting the user. I needed to remove the rogue address as it had been created in error and was a domain that was not managed by Exchange. Anyway, I launched ADSIEdit.msc, found the attribute TargetAddress (http://msdn.microsoft.com/en-us/library/aa487600(EXCHG.65).aspx) and cleared it. I could then go back to ADUC and remove the rogue address. After about 20 minutes mail started to be delivered to the mailbox once again.