Organizations may create calendar PST files for their organizations or teams. This may include organization / team events, project deadlines, holidays or even birthdays. After entering all of this information into the calendar of a generic mailbox, you can then export this calendar to a PST file, CompanyHolidays.pst for example. Now an Exchange Administrator can use the Import-Mailbox cmdlet to import this into everyone’s mailbox, thus putting all the events on everyone’s calendar.
When doing this several customers have report the permissions to the calendar folder are being reset or rewritten. After a little research we found out what was going on.
To actual copy the data from the PST to the mailbox the cmdlet uses the IMAPIProp::CopyTo interface. This is used when an item or object should be copied exactly. We use this to ensure all properties are intact. This is where our problem comes in, it copies ALL properties, exactly as they are in the source PST file. One of the properties of a mailbox folder it the ACL (Access Control List) or the permissions. This is clearly viewable in MFCMAPI:
The PR_ACL_DATA is where permissions to this folder are held. You can see this is the same data from the permissions tab in Outlook.
So we have our PST file that we created with no permissions, just the defaults. But our users have probably added several people to have permissions to their calendar. When we run the import, those custom permission are overwritten by what’s in the PST file. In effect resetting the calendar permissions back to the defaults. But we don’t want to overwrite all of our user’s permissions. We just want to import the calendar items from the PST. Luckily the CopyTo interface allows for this. There is a parameter for passing a list of properties that should be excluded from the copy operation. PR_ACL_DATA and PR_ACL_TABLE are already in that list. Then why are we still overwriting permission? For that we need to look at where the functionality comes from. The Exchange Managment Tools, and thus the Import-Mailbox cmdlet, load and utilize MAPI DLLs provided by Outlook. This is one of the requirements, please see reference link below. In this case, we specifically use OLMAPI32.DLL. This DLL contains most of the core MAPI interfaces and functions. This means ultimately, the call to copy the properties is really handled by the Outlook DLL. A little research on the Outlook 2007 side reveals that this was not originally handled correctly. For Outlook 2007 there is an update, which is included in SP2, that adds a registry key that needs to be set so that the DLL knows there are properties to exclude:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Preferences dword: CopyFolderEx Value: 1
Once SP2 is installed and this registry key is in place and set on the client system we are running the Import-Mailbox command from, the permissions in the user’s mailbox will no longer be overwritten.
References: http://technet.microsoft.com/en-us/library/bb691363(EXCHG.80).aspx
To import data from a .pst file, you must use the 32-bit version of the Exchange management tools. You cannot run the 32-bit version of the Exchange management tools on a server that is running Exchange 2007 because it is a 64-bit computer. You must run the Import-Mailbox cmdlet from a 32-bit computer that has the following installed:
IMAPIProp::CopyTo http://msdn.microsoft.com/en-us/library/cc839922.aspx
Over the past week or so we've had several cases pop up where the Exchange 2007 OWAAppPool is crashing. After looking over a few of these cases we found one thing they had in common, they were all running on Windows 2008.
A little debugging and we found the culprit. We were receiving an HTTP response that we didn't recognize. That causes an exception and crashes the application pool. That response was a redirect. So, how does a redirect response crash the application pool?
Let's review our current documentation on TechNet:
How to Simplify the Outlook Web Access URL http://technet.microsoft.com/en-us/library/aa998359.aspx
You have the option to set our response to a file or a URL.
Using the URL redirect works fine for a relative URL to the site root, this doesn't help much if you want to also redirect from HTTP to HTTPS. So, most configurations use the FILE option for the redirect. Now, this works great with Exchange 2007 running on Windows 2003\IIS6. Just as outlined in the TechNet article, the file can then handle the redirect to HTTPS, But the response code is still "FILE".
What happens when you install Exchange 2007 SP1 on Windows 2008? Welcome to IIS7.
IIS7 has a new feature that was not present in IIS6 and thus was not present when Exchange 2007 was released. We know Exchange 2007 was clearly designed with IIS6 in mind. Just note the message when installing on a straight IIS7 install:
Unable to read data from the Metabase. Ensure that Microsoft Internet Information Services is installed. The 'IIS 6 Metabase Compatibility' component is not installed. Install the component via Server Manager.
That feature is the Redirect response. This will allow an absolute URL as opposed to a relative URL like IIS6. The response code here is REDIRECT, not FILE or URL.
As stated before, REDIRECT is not a response type we expect. We check for FILE and URL. So, when we receive REDIRECT, we fail our test case and force an exception, thinking something bad must have happened.
You can also find this in the ApplicationHost.config file: C:\windows\System32\inetsrv\config\applicationHost.config
<httpErrors> <error statusCode="403" subStatusCode="4" path="C:\inetpub\SSLredirection.html" responseMode="File" /> </httpErrors>
<httpErrors> <error statusCode="403" subStatusCode="4" path=https://WEBMAIL.TAILSPINTOYS.COM /OWA responseMode="Redirect" /> </httpErrors>
If you are using this feature, anytime someone\something attempts to access the "/exchange" virtual directory we will crash the OWAAppPool. This could either be in DAVEX or EXPROX depending on if you CAS server has only the CAS role installed or CAS and MBX installed together.
Log Name: Application Source: Application Error Date: 8/28/2008 2:17:37 AM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: WEBMAIL.TAILSPINTOYS.COM Description: Faulting application w3wp.exe, version 7.0.6001.18000, time stamp 0x47919ed8, faulting module davex.dll, version 8.1.240.5, time stamp 0x47427a90, exception code 0xc0000005, fault offset 0x00000000000d3ac1, process id 0x1078, application start time 0x01c908d5c27835da.
Our current solution is to continue using the same practice outlined in the TechNet article for IIS6 by setting a FILE response and let that handle the redirect for you.
Thanks to Brad Hughes for helping me track this down. Check out his blog as well. http://blogs.msdn.com/brad_hughes/
Update: RU5 for Exchange 2007 SP1 includes an update to enabled the use of this new feature in IIS. With RU5 installed you can now use the "REDIRECT" option of IIS7 instead of the more complex FILE option to redirect users to an absolute URL.
Description of Update Rollup 5 for Exchange Server 2007 Service Pack 1 http://support.microsoft.com/?kbid=953467
Update Rollup 5 for Exchange Server 2007 Service Pack 1 (KB953467) http://www.microsoft.com/downloads/details.aspx?FamilyId=652ED33A-11A1-459C-8FFE-90B9CBFE7903&displaylang=en
First, just a little background about address types and foreign connectors. Address Types are ,as the name implies, the types of addresses that Exchange has knowledge of and that can be used for message transport. There are several that are included with Exchange by default. You will see these stamped on each mail enabled user as proxyAddresses. SMTP: (SMTP:mblanton@tailspintoys.com) X400: (X400:c=US;a= ;p=TailspinToys;o=Exchange;s=Blanton;g=Michael;) and EX: (Internal address type, not stamped on users)
You have always been able to add external address types to Exchange via gateway connectors. Fax connectors are a good example of this. Most of the time installing the a 3rd party connector will created the address type for you. Generally it will also create a gateway or connector mailbox on your server to handle those messages types. This is all based on EDK gateways which is outlined in the Exchange SDK.
Exchange 2007 will still let you install 3rd party connectors. These are now classified as foreign connectors. These are installed with the "New-ForeignConnector" cmdlet.
Now on to the real question. When I install a new gateway or connector, why does Outlook work in online mode but not in cached mode?
In online mode when you send a message from Outlook, the message is submitted to the Outbox folder of your mailbox directly on the Exchange server. From there Exchange picks up the message and hands it over to transport for delivery.
With cached mode, Outlook tries to be a little smarter. Outlook will basically attempt to submit the message directly to transport queue for you. Outlook does this by requested and storing a list of available address types. If the address type you are attempting to send to is not on the list, Outlook will NDR the message before it ever attempts to connect to the Exchange server. You can confirm which types are available by looking that registry keys for the cached mode profile:
Name: 01026687 Type: REG_BINARY Data: 00000000 03 00 0d 00 45 58 00 58 - 34 30 30 00 53 4d 54 50 ....EX.X400.SMTP 00000010 00
When the Information Store service starts, Exchange 2007 loads a list of address types which is stores in an array in memory. The key here is, when the Information Store starts... When Outlook requests the list of available types, this array is what is returned.
Our problem comes about when a foreign connector is installed and the Information Store is not restarted. This array in memory has not been updated. Thus, as in my sample above, our Outlook cached mode client does not know about the FAX address type and Outlook will NDR any message addressed for FAX.
Simply restart the Information Store on the affected Mailbox server roles. This will update the array in memory. Then have each client log off and log back on to request the updated list from the Information Store. You should now see the FAX address type stored for this profile and messages for address type FAX should work.
Name: 01026687 Type: REG_BINARY Data: 00000000 45 00 13 00 45 58 00 58 - 34 30 30 00 53 4d 54 50 ....EX.X400.SMTP.FAX 00000010 00