Welcome to Kraft Kennedy

Kraft & Kennedy, Inc. provides technology and strategic consulting services to law firms, corporate legal departments and financial services firms. We can help you analyze, plan, implement and manage business and technology solutions to optimize your organization's functionality and processes.

Kraft Kennedy | Technology Blog

Tag: Outlook

For the longest time (read: forever), we were led to believe that Outlook simply does not run in Cached Mode on Windows Terminal Servers. But that has actually changed with Outlook 2010 and Server 2008 R2. This does not mean that you should deploy Outlook 2010 in Cached Moe on your Server 2008 R2 XenApp servers, but it means that you could.  From a Microsoft Technet article:

To achieve optimal results when you use Outlook with Remote Desktop Services, pay attention to how you customize your Outlook configuration. For example, in Outlook 2010 you can configure Cached Exchange Mode with Remote Desktop Services.

The article is careful to mention that you’d need to have enough disk space on the server to handle each user’s OST file. Maybe this makes sense for small environments with only one Terminal Server and tidy mailboxes. I can count on less than one hand how many firms fall into that category.

Based on our experience, we recommend disabling Cached Mode on any XenApp server we put in place. At the same time, we want to allow our users to run in Cached Mode on their Windows 7 desktops. How do we achieve this?  Through the use of Loopback Policy, we can ensure that when users log in to a XenApp server, Cached Mode will be disabled.  This policy will override the settings within a MAPI profile that is roamed or flexed to the XenApp server. When the user logs back into their Windows 7 desktop, they are happily working in Cached Mode again.

This is just another example of how technology can change without much fanfare.  For many years, we never hard to worry about this situation. The mere fact that the user was logging in to a Terminal Server with Outlook 2003 meant that Cached Mode would be disabled no matter what. But with Outlook 2010 and Server 2008 R2/XenApp, a successful implementation relies on a successful configuration of the environment. You can download the Microsoft White Paper on the planning considerations of Outlook 2010 on Server 2008 R2 here.

Back in February I read a blog post from Andre Leibovici (VDI and Microsoft Outlook, analysing the variables), a very well known and respected expert in the virtualization and VDI community.  His article discussed the challenges in dealing with Outlook in VDI environments, including how to address OST/PST files and how searching is affected.  Although I’m a little late to the party here I thought I’d add my thoughts on this and make sure folks aren’t seeing this as a barrier to adopting VDI.

I recommend reading Andre’s post to get more information on this topic.  The short version is this – Exchange/Outlook best practices do not necessarily work in a VDI environment.

When using Outlook in an Exchange environment, it is recommended to use Cached Exchange Mode.  In this mode a copy of the user’s mailbox is downloaded into an OST file and stored offline on the user’s desktop.  This mode offers better performance for the end user and reduces utilization on the Exchange environment as well.  In addition, using Cached Exchange Mode allows users to use Outlook Instant Search for fast searching of items in their mailbox.  Instant Search works by indexing the contents of the OST file so all searches occur locally and not on the Exchange server, further improving performance and reducing utilization on Exchange.

VDI environments that we see at our clients are typically configured as non-persistent or floating pools of desktops.  That is, each user connects to a pool of identical desktops and grabs whatever desktop is available.  When the user logs off, any changes written to the VDI desktop are discarded and the desktop returns to a pristine state.  There are mechanisms and tools in place to make sure user data is retained at logoff.

So if user data is retained at logoff, why can’t we use Cached Exchange Mode in non-persistent VDI environments?
Continue reading…

Recently, Autonomy released the 8.5 SP2 Update 2 versions of iManage FileSite, DeskSite, OffSite, Email Management for FileSite, and Email Management for Outlook.   The key new feature is support of Adobe Acrobat Reader X.    However, due to a new feature of Reader X, a configuration change within the Reader application is needed.  From the Release Notes:

NOTE: Adobe Acrobat Reader X includes a feature called Protected Mode that limits an application’s access to registry and file systems. This feature is enabled by default. Because WorkSite Integration requires full access to the local machine, you must disable this feature.

The feature can be disabled from the General Preferences in Adobe Reader X, and should be included into your MST transform package.

Regarding Update 2, there are a handful of issues resolved, but one in particular stands out to me because I’ve already witnessed it.   From the Release Notes:

NT-26001: When dragging an e-mail to a WorkSite folder using Outlook 2010 with Cached Exchange Mode disabled, the user receives the following error; ‘Cannot move the items. The item cannot be moved. It was either already moved or deleted, or access was denied.’

This can easily be avoided on Windows 7 desktops simply by enabling Cached Mode (which is a good idea for a number of reasons that you should already know about, so I won’t get into them).  However on XenApp servers, where Cached Mode is not available, this can be an annoying bug.  The email does in fact get filed, but the error just isn’t pretty at all.   If you are planning an Office 2010 roll-out with iManage, this update is a must-have.

The Problem – Hidden Outlook Reminders

In Outlook 2003, 2007, and 2010, reminder windows pop up in Outlook, but they do not steal the focus if you are working in another program.  For example, if you currently working in Word or Internet Explorer, you won’t see a reminder window if one pops up, since you’re not in Outlook.

In previous versions of Windows, this wasn’t as big of a deal because you would still see the reminder window in the task bar.  So even though you didn’t see the actual window, you would see the tab for it flashing on the taskbar.

In Windows 7 however, the default grouping of same-application windows, makes is much harder to see when a reminder window pops up. For example, the image below shows a second Outlook window, which is actually a reminder window.


Continue reading…

At a few recent client implementations, we have seen noticeable delays synchronizing various changes in mailboxes to Exchange 2010 when running Outlook 2003 in Online Mode.  As it turns out, this is a known issue and Microsoft has documented it at http://support.microsoft.com/kb/2009942.  The following are symptoms of the issue:

  • Outgoing messages stay in the Outbox for up to 1 minute
  • New messages do not arrive in the mailbox for up to 1 minute
  • Items that are deleted or moved between folders may take up to 1 minute for the change to be reflected


Continue reading…

A common situation in organizations is to make calendars public, so that employees can see other employee’s availability, and collaborate better.  Users may also delegate rights to other users to view their messages, tasks, and contacts.  In these situations, people may rely on marking sensitive items private to hide them from other users.  In Outlook or OWA, other users will see a placeholder for the private items, but won’t be able to view any of the details.  However, you should keep in mind that this privacy is only a feature of the client application–Outlook or OWA–and is not inherent to Exchange.  Exchange itself does not support any kind of item-level security or privacy, and only has a field called “sensitivity” which is used by Outlook and OWA.  The client applications look at that field to determine whether to display the item.
Continue reading…

In working with a colleague, we came across what appears to be a bug within Outlook relating to meetings disappearing from calendars after an update is sent.  This has been confirmed to affect Outlook 2007 but it may affect other versions as well.

Symptom:  A meeting for which you are the owner/organizer disappears from your calendar after sending an update to all attendees if the meeting request was sent to a distribution list or group of which you are a member.  The meeting does not disappear if you are explicitly in the attendee list.

Workaround:  Before sending a meeting request to a distribution list or group, expand the membership by clicking the “plus” sign next to the name.  Once you see all of the members expanded, you may send the meeting request or remove yourself from the attendee list so that future updates will not fall victim to this bug.  I would recommend that you remove yourself entirely as an attendee in case other issues arise as a result.

We are unclear as to whether Microsoft is aware of this bug or has a fix in development. Hopefully the above workaround will help some of you that are experiencing this problem.

Outlook 2003 and 2007 support a protocol called stssync, which allow SharePoint libraries to be viewed in Outlook.  Outlook 2003 allows for read-only viewing, whereas Outlook 2007 also allows for two-way synching of certain content.  The most common way of connecting to a SharePoint library is through the SharePoint Actions menu, as shown below.
Continue reading…