Inside Entourage by Amir : Known Issues

Continued Credentials Prompt in Entourage Connecting to Exchange Mailbox

amir — Tue, 12 Aug 2008 01:18:04 GMT

In this blog I wanted to talk about an issue which we have seen enough number of times working with our enterprise customers that it warrants a blog.

Issue
When connecting to an Exchange mailbox Entourage user sees the following error repeatedly. User enters correct credentials (username, password & domain) but same error comes back again thus effectively entering a never ending loop. We have seen this on all currently supported versions of Exchange & Entourage. This error can also come up when:

a. User tries to permanently delete or move a large number of messages from his Exchange mailbox

b. User tries to send/receive new mail after deleting or moving a large number of messages from his Exchange mailbox

Cause
When Entourage tries to permanently delete messages from a folder in Exchange mailbox, Exchange Server utilizes the TEMP (temporary) folder for that operation. If Entourage user does not have required permissions on that TEMP folder, server issues a '401, Access Denied' error. Moving messages in Entourage involves permanent deletion from source folder, thus it results in the same issue.

Resolution
There are two parts of it.

1. Locating TEMP & TMP Folders

a. Non-Clustered Servers
First determine which TEMP folder is set as default on Exchange Mailbox Server on the back-end, cos that's where the delete operation actually takes place. The default location of TEMP folder is set under the following registry key:

HKEY_LOCAL_MACHINE\System\CurrrentControlSet\Control\Session Manager\Environment
REG_EXPAND_SZ: TEMP
Value: <PATH>\TEMP

By default, the TEMP folder is located at: '%SystemRoot%\TEMP' which is usually 'C:\WINDOWS\TEMP'

Another place to check this is: Bring up 'Control Panel' on Exchange Server, go to System : Advanced : Environment Variables : System Variables (see the screenshot below)

Same check applies for TMP folder, if there is one located on your drive. The above registry key should have an entry for TMP folder as well.

b. Clustered Servers
On clustered servers, the following registry keys are used to specify the locations of TEMP & TMP folders (Ref.).

HKEY_USERS\<Cluster service account SID>\Environment\TEMP

HKEY_USERS\<Cluster service account SID>\Environment\TMP

2. Verifying Permissions
Now let's verify the permissions assigned on TEMP folder. The 'Authenticated Users' group (Entourage user belongs to this group) should have the following special permissions:

Traverse Folder / Execute File
Create Files / Write Data
Create Folders / Append Data

In order to check these permissions, locate the TEMP folder and then right click on it to take 'Properties', go to 'Security' tab, highlight 'Authenticated Users', under 'Permissions for Authenticated Users' section, click on 'Advanced' button (see the screenshot below)

You will then see the 'Advanced Security Settings for TEMP' folder window (see the screenshot below)

Highlight the entry for 'Authenticated Users' in the above window and then click on 'Edit' button to view/edit the permissions. The screenshot below displays the required permission assigned properly.

Same check applies for TMP folder, if there is one located on your drive.

Redirected TEMP/TMP Folder
If the TEMP/TMP folder has been redirected to D (or any other) drive on the Exchange Server, it is suggested to specify the above permissions at the following three levels:

1. Drive level, especially at the root of drive if you notice that 'Authenticated Users' group is simply missing

2. TEMP/TMP folder

3. Any sub-folders inside TEMP folder which may have numerical (like 1, 2, etc.) names as such folders have been seen on clustered servers

Important
You will need to restart IIS (Internet Information Server) on all those servers where you made these changes in permissions, i.e. mailbox servers on the back-end and front-end servers as well to which Entourage users are connecting for mailbox access.

More Info
If your Entourage users are running into this issue then IIS Log on Exchange Server (front-end and/or back-end) & TCPFlow Log on Entourage Client will show the following:

a. 'BDELETE' request from client

b. '401' error response from server

IIS Trace Sample

2008-08-10 07:05:33 W3SVC1 192.168.137.121 BDELETE /exchange/john/Deleted+Items/ - 80 CONTOSO\JOHN 192.168.120.110 Entourage/12.11.0+(PPC+Mac+OS+X+10.4.9) 401 5 0

2008-08-10 07:05:35 W3SVC1 192.168.137.121 BDELETE /exchange/john/Deleted+Items/ - 80 CONTOSO\JOHN 192.168.120.110 Entourage/12.11.0+(PPC+Mac+OS+X+10.4.9) 401 1 0

TCPFlow Trace Sample

192.168.120.110.54103-192.168.137.121.00080:
BDELETE /exchange/john/Deleted%20Items/ HTTP/1.1

192.168.137.121.00080-192.168.120.110.54103:
HTTP/1.1 401 Unauthorized

E-mail Download Issue in Entourage With Exchange 2007 on Windows 2008

amir — Wed, 06 Aug 2008 19:00:34 GMT

In this blog post I wanted to talk about another new issue being experienced by our customers who are working with Exchange 2007 on Windows 2008. Windows Server 2008 is the key here as it relates to IIS 7 (Internet Information Server) and it's default security restrictions.

Issue
Using Entourage for Mac (2004 or 2008) while connecting to an Exchange 2007 mailbox on a Windows 2008 Server, user cannot download any e-mail message which has a plus sign in it's subject line, like 'Test + Mail'.

Cause
Entourage's request to download this e-mail message goes thru IIS 7 on Windows 2008 Server, which is configured (by default) to deny 'double escape sequences' in any HTTP request and thus it rejects the request with a '404.11' error.

Resolution
As Entourage talks to 'Exchange' virtual directory (for mailbox access) under 'Default Website' on IIS, thus you can use the following procedure to allow the use of 'double escape sequence' only at that level to address this issue. This will minimize the risk you will be taking to enable the usage of double escape sequence. Enabling the use of 'double escape sequence' does carry some risk, please go thru the links below under 'More Info' section to get yourself educated on the issue & involved risks before you work on the steps below.

Quick & Easy Way
You will need to run this command on all of your Exchange 2007 CAS and Mailbox Servers as IIS is installed on them by default.

Bring up a Windows 'Command Prompt', type the following command and hit 'Enter' on keyboard, that's it, you are done!

%windir%\system32\inetsrv\appcmd set config "http://localhost/Exchange" -section:system.webServer/security/requestfiltering -allowDoubleEscaping:true /commit:apphost

You will see the following response after running the above command in the same window.

Applied configuration changes to section "system.webServer/security/requestFiltering" for "MACHINE/WEBROOT/APPHOST/Default Web Site/Exchange" at configuration commit path "MACHINE/WEBROOT/APPHOST"

After running this command, you don't need to restart any services on server, just run the command and ask your Entourage users to see if the issue has been resolved for them, at the most you can ask them to re-launch Entourage.

OR if you are a guy who is interested in details, then you can follow the manual steps outlined below.

Manual Steps
1. Bring up Notepad : File : Open, type %windir%\System32\inetsrv\config\applicationHost.config in the 'File name' box, and then click 'Open'.

2. Locate the section titled as: <location path="Default Web Site/Exchange">

3. Under that section locate </authentication> tag

4. Just after that insert the following text on a new line: <requestFiltering allowDoubleEscaping="true" />

5. Save the file and 'Exit' Notepad

Again, no restart of any service is required.

Note:
As Entourage talks to 'Public' virtual directory (for public folder access) under 'Default Website' on IIS, thus you will need to follow the same procedure for 'Public' virtual directory as well. Same instructions apply, just replace 'Exchange' with 'Public' in all steps mentioned above.

Details
Let's go into the details of this issue. First of all let's see how this issue would look like to an Entourage user when he looks at his Inbox thru Outlook Web Access & Entourage.

Outlook Web Access thru Safari (note the presence of messages with '+' in their subject lines, i.e. 'Movie + Dinner' & 'Test + Message')

Entourage 2008 (note the absence of messages with '+' in their subject lines, i.e. 'Movie + Dinner' & 'Test + Message')

So how did it happen? Let's review the TCPFlow Trace pasted below, which I took on Entourage user's machine. Important parts are highlighted in red.

65.53.65.121 = Entourage Client

172.30.142.217 = Exchange 2007 CAS Server

In the trace snippet pasted below Entourage client is requesting (thru SEARCH command) if there are any changes in user's Inbox, i.e. if there are any new items there for Entourage to retrieve and sync down to its local database.

065.053.065.121.51253-172.030.142.217.00080:
SEARCH /exchange/john/Inbox/ HTTP/1.1
Host: 172.30.142.217
From: 65.53.65.121
User-Agent: Entourage/12.10.0 (PPC Mac OS X 10.4.9)
Accept: */*
Accept-Language: en
Content-Type: text/xml; charset="utf-8"
Brief: t
Translate: F
Range: Rows=0-512
Cookie: sessionid=7f5d08a5-f5ef-4e36-91e1-8c57c1c2a67f;
cadata="4Soepik9ZpG1ev4w+C87pKQrHkOOeTHX4IiYZdRzhFlUtMQICwpFE3
/xSe3jJmd6QpyBoZI08NwuacKT+wAeWBA==";
OwaLbe={7313483B-4B9B-459B-8EB9-8D0BEE690596}
Content-Length: 743
Accept-Encoding: gzip
Connection: Keep-Alive

065.053.065.121.51253-172.030.142.217.00080:
<?xml version="1.0"?><D:searchrequestxmlns:D="DAV:"
xmlns:R="<http://schemas.microsoft.com/repl/>">
<R:repl><R:collblob>toCTAAMAAQIgzWX+UAA=</R:collblob>
</R:repl><D:sql>SELECT
"<http://schemas.microsoft.com/repl/repl-uid>",
"<http://schemas.microsoft.com/repl/resourcetag>",
"<http://schemas.microsoft.com/mapi/proptag/x001A001F>",
"<http://schemas.microsoft.com/mapi/sensitivity>",
"urn:schemas:httpmail:read", "urn:schemas:httpmail:datereceived"
FROM SCOPE ('SHALLOW TRAVERSAL OF "/exchange/john/Inbox/"')
WHERE "<http://schemas.microsoft.com/mapi/proptag/0x67aa000b>"
= false AND "DAV:isfolder" = false</D:sql></D:searchrequest>

And here comes the response from server with the URL of the new item, which is an e-mail with the subject 'Test + Mail' (we are working with only one message to keep things simple) …

172.030.142.217.00080-065.053.065.121.51253:
HTTP/1.1 207 Multi-Status
Transfer-Encoding: chunked
Content-Type: text/xml
Content-Range: rows 0-0; total=*
Accept-Ranges: rows
Server: Microsoft-IIS/7.0
Set-Cookie: OwaLbe={7313483B-4B9B-459B-8EB9-8D0BEE690596}; path=/
MS-WebStorage: 08.01.10240
MS-WebStorage: 08.01.10240
X-Powered-By: ASP.NET
X-Powered-By: ASP.NET
Date: Fri, 20 Jun 2008 21:46:52 GMT

172.030.142.217.00080-065.053.065.121.51253:
<?xml version="1.0"?><a:multistatusxmlns:b="urn:
uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/"
xmlns:g="urn:schemas:httpmail:"
xmlns:f="<http://schemas.microsoft.com/mapi/>"
xmlns:c="xml:"
xmlns:e="<http://schemas.microsoft.com/mapi/proptag/>"
xmlns:d="<http://schemas.microsoft.com/repl/>"
xmlns:a="DAV:"><a:contentrange>
0-0</a:contentrange><a:response><a:href>
<http://172.30.142.217/exchange/john/Inbox/Test%20%2B%20Mail.EML
</a:href><d:changetype>new</d:changetype><a:propstat><a:status>
HTTP/1.1> 200 OK</a:status><a:prop><d:repl-uid>
rid:d17078df5926b048921786b466da7185000220cd63ff
</d:repl-uid><d:resourcetag>rt:d5926b04892185000220cd728e
</d:resourcetag><e:x001A001F>IPM.Note</e:x001A001F>
<f:sensitivity b:dt="int">0</f:sensitivity><g:readb:dt="boolean">0
</g:read><g:datereceived b:dt="dateTime.tz">
20080620T21:46:46.895Z</g:datereceived></a:prop></a:propstat>
</a:response><d:repl><d:collblob>toaUAABAAYAAiDNY/8A</d:collblob>
</d:repl></a:multistatus>

In the snippet below Entourage tries to fetch the new mail message using the URL provided by server …

065.053.065.121.51253-172.030.142.217.00080:
PROPFIND /exchange/john/Inbox/Test%20%2B%20Mail.EML HTTP/1.1
Host: 172.30.142.217
From: 65.53.65.121
User-Agent: Entourage/12.10.0 (PPC Mac OS X 10.4.9)
Accept: */*
Accept-Language: en
Content-Type: text/xml; charset="utf-8"
Depth: 0
Brief: t
Translate: F
Cookie: sessionid=7f5d08a5-f5ef-4e36-91e1-8c57c1c2a67f;
cadata="4Soepik9ZpG1ev4wJmd6QpyBoZI08NwuacKT+wAeWBA==";
OwaLbe={7313483B-4B9B-459B-8EB9-8D0BEE690596}
Content-Length: 646
Accept-Encoding: gzip
Connection: Keep-Alive

And Entourage's receives a 404 error from server for it's request, as IIS7 installed on that Windows 2008 Server (with Exchange 2007) does not allow the use of 'double escape sequence' in any incoming HTTP request.

172.030.142.217.00080-065.053.065.121.51253:
HTTP/1.1 404 Not Found
Content-Type: text/html
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Fri, 20 Jun 2008 21:46:52 GMT
Content-Length: 1245
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"<http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd>">
<htmlxmlns="<http://www.w3.org/1999/xhtml>">
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"/>
<title>404 - File or directory not found.</title>
<style type="text/css">

<!--

body{margin:0;font-size:.7em;font-family:Verdana, Arial,
Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;}
h1{font-size:2.4em;margin:0;color:#FFF;}
h2{font-size:1.7em;margin:0;color:#CC0000;}
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;}
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;
font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
background-color:#555555;}
#content{margin:0 0 0 2%;position:relative;}
.content-container{background:#FFF;width:96%;margin-top:8px;
padding:10px;position:relative;}

-->

</style>
</head>
<body>
<div id="header"><h1>Server Error</h1></div>
<div id="content">
<div class="content-container"><fieldset>
<h2>404 - File or directory not found.</h2>
<h3>The resource you are looking for might have been removed,
had its name changed, or is temporarily unavailable.</h3>
</fieldset></div>
</div>
</body>
</html>

Now if you look in IIS Log on Exchange 2007 CAS or Mailbox Servers, you will find the following entry there:

CAS
2008-06-20 14:38:09 172.30.142.217 PROPFIND /exchange/john/Inbox/Test+++Mail.EML - 80 - 65.53.65.121 Entourage/12.11.0+(PPC+Mac+OS+X+10.4.9) 404 11 0 0

Mailbox
2008-06-20 14:38:09 172.30.142.218 PROPFIND /exchange/john/Inbox/Test+++Mail.EML - 80 - 172.30.142.217 Exchange-Server-Frontend-Proxy/6.5+Entourage/12.11.0+(PPC+Mac+OS+X+10.4.9) 404 11 0 0

More Info
For more info, you can go thru the following links:

Blog : IIS7 Rejecting URLs Containing Plus Sign '+'

Article : Double Encoding

KB 942076 : Error message when you visit a Web site that is hosted on IIS 7.0: "HTTP Error 404.11 – URL_DOUBLE_ESCAPED"

KB 943891 : The HTTP status codes in IIS 7.0

Parts of Hyperlink After Ampersand Sign Are Stripped in Entourage 2008

amir — Thu, 17 Jul 2008 18:34:00 GMT

Update: The fix for this issue has been released in the 12.1.2 Update for Office 2008 for Mac.

Here is another known issue we are working to fix these days.

Issue
Entourage 2008 users are reporting that it is stripping parts of hyperlinks (URLs) in messages they receive from other users. It always strips parts of those hyperlinks right after '&', including the ampersand sign. This is only being reported by those users who have recently upgraded to Office 2008 for Mac Service Pack 1 (SP1). Examples of stripped URLs are:

Original Link:
https://www.contoso.com/dept/sales/abc.php?ABCD=0987654321&UID=987612345

Stripped Link:
https://www.contoso.com/dept/sales/abc.php?ABCD=0987654321=987612345

Note that '&UID' has been stripped

Original Link:
https://www.litwareinc.com/EntApp/ViewMsg.asp?MsgID=897&SaveID=7843~2945

Stripped Link:
https://www.litwareinc.com/EntApp/ViewMsg.asp?MsgID=897=7843~2945

Note that '&SaveCaseID' has been stripped

Cause
This happens as '&' is not properly encoded as '&amp' in the message source

Resolution
Microsoft is working to release a fix for this issue in an update for Entourage 2008 but a final release date is not available yet. I plan to update this post with new information in this regard when it becomes available.

SSL Warning Issue in Entourage 2008

amir — Thu, 17 Jul 2008 00:15:00 GMT

Update 1: The fix for this issue has been released in the 12.1.2 Update for Office 2008 for Mac. See 'Improvements for Microsoft Entourage 2008 for Mac' section in KB 956344.

Update 2: The fix for a subsequent 'CNAME' entry issue discussed in the comments section of this blog post has been released in the 12.1.3 Update for Office 2008 for Mac. See 'Improvements for Microsoft Entourage 2008 for Mac' section in KB 958267.

In this post I wanted to quickly provide an update on an ongoing issue with some specifics to make sure our customers are well informed on its current status.

Issue
After installing Office 2008 for Mac Service Pack 1 (SP1) when Entourage 2008 users connect to their mailbox on an Exchange 2007 Server, they may see an error like this (you can substitute 'contoso' in the screenshot below with your own root domain):

If you click on 'OK', Entourage will continue to work and you won't see this error message again until the end of that session when you close Entourage. Clicking on 'Cancel' you may end up in 'Not Connected' state with your Exchange account. This error may also come up when:

1. You try to configure your Exchange account using 'Account Setup Assistant' which now uses Autodiscover Service on Exchange 2007 to automatically configure your account or

2. You use any 'Exchange Web Services' based feature in Entourage 2008, like OOF Assistant, Free/Busy Info pull-up, etc. as they also utilize Autodiscover feature or

3. Entourage tries to talk to Autodiscover Service while its running connected to your mailbox to see if any updates were made to Autodiscover Service on server side by your Exchange Administrator, this happens automatically in the background based on a pre-set interval which cannot be modified by user

Cause
This happens as Entourage 2008 tries to establish a secured connection to the first of the 2 default addresses (URLs) in its attempt to contact the Autodiscover Service on your Exchange 2007 Server. This is explained in the Autodiscover Whitepaper, see 'How the Autodiscover Service Works with Clients' section. Most organizations using Exchange 2007 do not publish Autodiscover Service thru the first URL mentioned over there, i.e. 'https://contoso.com/autodiscover/autodiscover.xml', rather they use the other URL, i.e. 'https://autodiscover.contoso.com/autodiscover/autodiscover.xml'. When Entourage finds an error (mostly its 'Common Name' mismatch) with the certificate published at the root of your domain (if there is one, many organizations do, but 'Common Name' on that certificate is 'www.contoso.com', not just 'contoso.com' and Autodiscover Service is not published thru that URL), it displays the above error. It does not move silently to try the other possible URL. Clicking 'OK' on above error makes it exactly do that and thus it finds the Autodiscover Service responding on the other URL and everything then works fine from there.

This issue can also happen in Entourage 2008 if Autodiscover Service is not configured properly as per the guidelines in Autodiscover Whitepaper. See 'Note' below on how to quickly check to see if Autodiscover Service is properly configured and published for users.

Note
We need to make sure that when Entourage looks for Autodiscover Service, the related URL as mentioned above in 'Cause' section is configured and published to respond to those requests. A quick way is to look up the A Record (a type of DNS record which is used to map a hostname or URL to the IP Address of the host) which you will have to register with your DNS provider.

A Working Example:
For Microsoft, the Autodiscover Service is configured and published at 'https://autodiscover.microsoft.com/autodiscover/autodiscover.xml', you can look it up using this URL in your browser:

http://codeflux.com/exec/tools/?method=nslookup&query=autodiscover.microsoft.com&type=A

You will see an IP Address is mapped to the URL for Autodiscover Service to respond to incoming requests.

Now, if I go and hit the URL for Autodiscover Service in my browser, i.e. 'https://autodiscover.microsoft.com/autodiscover/autodiscover.xml'

I will get a window to enter my user credentials (domain\username & password) and after that I will see the following lines in the main browser window:

<?xml version="1.0" encoding="utf-8" ?>
- <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
- <Response>
- <Error Time="10:29:57.7332076" Id="59171512">
    <ErrorCode>600</ErrorCode>
    <Message>Invalid Request</Message>
    <DebugData />
</Error>
</Response>
</Autodiscover>

The response above says 'Error 600, Invalid Request' as the Autodiscover Service URL is not supposed to be accessed thru a browser. This is an expected response in this scenario and confirms the proper configuration and publishing of Autodiscover Service.

A Non-Working Example:
Let's use Contoso as a non-working example, the Autodisover Service should be configured and published at 'https://autodiscover.contoso.com/autodiscover/autodiscover.xml', if you look it up using this URL in your browser:

http://codeflux.com/exec/tools/?method=nslookup&query=autodiscover.contoso.com&type=A

You won't find an IP Address mapped to the URL for Autodiscover Service, instead you will see an error there saying 'server can't find autodiscover.contoso.com'.

DST Workaround for Entourage 2004 & 2008 Users in ANZ

amir — Tue, 01 Apr 2008 02:12:00 GMT

Update: The fixes for this issue have been released in 11.5 (Entourage 2004) & 12.1 (Entourage 2008) Updates for Office for Mac.

I wanted to quickly provide this workaround to the users of Entourage 2004 & 2008 in Australia & New Zealand (ANZ) time zones until Microsoft releases fixes thru updates at Mactopia website.

Issue
When Entourage 2004 & 2008 users organize meetings by inviting other users who are using Microsoft Outlook or OWA (Outlook Web Access) against their Exchange mailboxes (version of Exchange Server does not matter here), then those meeting attendees may see the incoming meeting invite being an hour off. This issue is not seen if all meeting attendees are Entourage users.

Cause
This happens as Entourage 2004 & 2008 use DST information from related 'Timezones' files for users in ANZ time zones, which are not up to date with current information.

Resolution
Microsoft is working to release a fix for this issue in an update for both versions of Entourage but a final release date is not available yet. When that update is available, users can safely install it and it will replace the files which they will put on their systems as a result of applying the workaround provided below.

Workaround
Below are the steps to follow for both versions of Entourage. Only Entourage users will need to apply this workaround on their machines, no action is required by other users who are using Microsoft Outlook or OWA.

Entourage 2004

Quit Entourage (Entourage should not be running when you apply this workaround)
Back up the current 'Timezones' file in folder: Mac Hard Drive : Applications : Microsoft Office 2004 : Office (just copy it to a backup folder on your hard drive)
Download the updated 'Timezones' file for Entourage 2004 from here (extract its content before proceeding to next step)
Copy the downloaded 'Timezones' file to the same location as above in Step 2, replacing the existing 'Timezones' file
That's it, you are done, launch Entourage and every meeting you create now will not display the issue described above

Entourage 2008

Quit Entourage (Entourage should not be running when you apply this workaround)
Back up the current 'Timezones.ics' file, go to folder: Mac Hard Drive : Applications : Microsoft Office 2008 : Office, locate a file by the name of 'EntourageCore.framework', now Control-Click on it and choose 'Show Package Contents' in the resulting menu, a new window will appear, in that window go to folder: Versions : 12 : Resources : en.lproj (you will find the 'Timezones.ics' file here, just copy it to a backup folder on your hard drive)
Download the updated 'Timezones.ics' file for Entourage 2008 from here (extract its content before proceeding to next step)
Copy the downloaded 'Timezones.ics' file to the same location as above in Step 2, replacing the existing 'Timezones.ics' file
That's it, you are done, launch Entourage and every meeting you create now will not display the issue described above

Note: Any meetings which were scheduled earlier and display the issue described in this post will not automatically get fixed. If you want to fix them, you will have to open them and make a change in them (like add one character to its subject/title or notes area, etc.), then save them and send update to all attendees. This change will force Entourage to recalculate DST info as per the updated 'Timezones' file.

Workaround Removal
If at anytime you may need to remove or undo this workaround, just follow the same steps as above and replace the 'Timezones' files with the original ones which you backed up earlier.