Tools to manage email and some PowerShell cheat sheets

Posted on September 12, 2012 by Tony Redmond

It was interesting to see the launch of “Inbox Pause”, an add-in for Gmail from Baydin Software, the same folks who develop Boomerang for Gmail (and indeed, Boomerang for Outlook). These add-ins are designed to help manage the constant flow of email that most people have to process daily.

Inbox Pause is an interesting idea because it adds a “pause” button to Gmail that pauses the delivery of new messages. The new messages don’t show up in the Inbox as they are marked with a label that effectively hides them from the Inbox. You can still get to the messages if you want to, but they don’t appear in the Inbox. It’s a case of “out of sight, out of mind”.

The idea is that you’d use a pause when you go on vacation or need to work on a project so that you’re not distracted by the constant arrival of newly arriving email. Of course, sometimes it’s nice to be distracted by email but mostly it’s not very productive to work in a constantly interrupted mode.

Later on, when you feel ready to deal with new messages, you click on an “unpause” button to have the add-in remove the label from the messages that it has hidden. The messages then reappear magically in the Inbox. At this point, you might have a heart attack when you see how many new messages remain to be processed but hopefully the rest you’ve had during the pause puts you in good stead to keep on working.

Boomerang proposes a more comprehensive solution to Inbox overload. Some people are truly overwhelmed by the volume of email that they receive and need help in its processing. The old approach was to “Read then Action or Delete”. In other words, as soon as you read a new message, make a decision what to do with it – either reply immediately, delete the message (the best course of action for many messages today), or file it appropriately (including putting the message into a “follow up” folder). People who follow this rule have very small inboxes – at least, smaller than the vast majority of email users. It’s an easy rule to adapt to your own circumstances and it’s free and requires no add-on software.

However, it’s also true that software can enable better working habits by providing features to help users deal with email more effectively. I don’t know if Boomerang would work for me as I suspect that my interaction with Outlook is deeply engrained at this point and a new modus operandi would not come easily. But deploying add-on software to each and every user desktop just to help people manage email better is not easy or cost-effective, especially when the numbers mount past a hundred or so. For this reason, I prefer server-based “help” whenever possible, such as the retention policies available in Exchange 2010 onwards. Implementing retention policies across an organization guarantees consistency in terms of the content that users are allowed to retain. However, it doesn’t provide any new features such as the ones built into the software described above, which might prove to be very useful to some. In addition, retention policies are never successful unless they are well-designed to meet the needs of the business and are clearly communicated to users, probably in several separate instances well before the policy becomes operational.

On another topic, I’ve written extensively in the past on the need for Windows administrators to embrace PowerShell as it is the way forward for systems administration. Exchange 2007 was the first major Microsoft product to go “all-in” with PowerShell, a trend continued in Exchange 2010 and Exchange 2013 and now seen in all products across the Microsoft portfolio, including in every corner of Windows Server 2012.

PowerShell can be hard to master. Its syntax is sometimes obscure and only beloved by those who enjoy complexity. It’s therefore important to have good learning tools to help administrators understand cmdlets, syntax, and usage. Exchange 2007 and Exchange 2010 are quite good in this respect but the move to a purely browser-based administration console in Exchange 2013 has a regrettable side-effect of dropping three tools that help administrators learn the ins and outs of the Exchange Management Shell (EMS). I hope that Microsoft will be able to bring these EMS learning tools back in Exchange 2013 SP1.

In the meantime, I think the “Rambling Cookie Monster” project to construct a PowerShell Cheat Sheet is a worthwhile endeavour as it should help others to understand PowerShell better across a range of Microsoft products. One of the references cited in the project is an Exchange 2010 PowerShell Cheat Sheet, a good resource for anyone who works with EMS. I hope that this sheet is updated for Exchange 2013 to take account of the 180-odd new cmdlets introduced in this release.

Follow Tony @12Knocksinna

Posted in Email, Exchange, Outlook | Tagged , , , , , , , , , | 1 Comment

Enterprise Vault, stubbing, and competition

Posted on September 10, 2012 by Tony Redmond

Last March I wrote a post about the early history of the product now sold as Symantec Enterprise Vault. I’m now delighted to see that Nigel Dutt has published a comprehensive account of the history of the Vault. The account is compelling reading as it wanders through corporate politics, a failed attempt to do a deal with Microsoft to ship the Vault software alongside Exchange 2000 as the “Enterprise Vault Mailbox Manager”, buying the IP from Compaq, early days as an independent software company, marketing the message first about removing email from databases and then (as lawyers began to become concerned about discovery actions) how to keep email, to a point where the company (KVS) was acquired by Veritas and then by Symantec. It’s a great read with references to companies like Enron (who wanted to get rid of email – surprise, surprise) and marketing at Microsoft Exchange Conference events in Europe and the U.S.

All of this is very pertinent in light of the recent EHLO post titled “Exchange, stubbing, and database space reclamation”, an interesting read if only because it explains how the evolution of the Exchange Store has affected customers who use “stubbing” products.

Enterprise Vault was the product that brought “stubbing” into the Exchange vernacular. Originally deemed to be a pretty good idea by the Exchange development group at a time when storage was much more expensive than today and the Exchange store wasn’t quite as nippy and efficient as it is in Exchange 2010, stubbing seems to have become a dirty word in Redmond.

Some might say that this is just a case of “not invented here”. And indeed, I think that there is some truth in this feeling, but perhaps it’s more accurate to say that Microsoft now competes with Enterprise Vault and similar products from other vendors. Up to Exchange 2007, Microsoft would have been laughed at if they claimed to have a document retention strategy for email. The original Messaging Records Management (MRM) subsystem included in Exchange 2010 is bare-bones and incomplete and was totally rejected by the vast majority of customers (I admit and acknowledge that some find MRM to fit their needs very well).

Exchange 2010 is a different proposition and it’s because this product includes archive mailboxes, much better retention policies, litigation and retention hold, single item recovery, and multi-mailbox discovery search (all of which represents a huge engineering investment by Microsoft) that the tension with the “stubbers” and other archive vendors now exists.

Exchange 2013 increases competition further by introducing new features such as Data Loss Protection (DLP). However, the more interesting extension is the ability to search across Exchange, SharePoint, and Lync (once the appropriate software versions are deployed) due to the adoption of the FAST search technology as a common platform. Site mailboxes also allow Exchange and SharePoint to collaborate better than ever before.

With the Microsoft Exchange Conference rapidly approaching, I think it’s important for competition to continue to thrive in the area of document retention and management. It would be dreadful if Microsoft bulldozed third party vendors aside in a rush to introduce new features in Exchange. Then again, it has forever been so. Why won’t it happen again in this area? It will be interesting to see what’s said on the topic at MEC – or what third parties are showing there!

Follow Tony @12Knocksinna

Posted in Email, Exchange, Exchange 2010, SharePoint 2010 | Tagged , , , , , , , | 3 Comments

Outlook 2013, swelling OSTs, and retention policies

Posted on September 6, 2012 by Tony Redmond

Speaking about OST sizes and the change made in Outlook 2013 to drive down the amount of data cached by users, another thought came into my mind (I know, a very unusual occurrence). Just how big can an OST grow to given that we’re in an era of 25GB-plus mailboxes? Mind you, I don’t know many people outside the Exchange development team and a handful of corporate executives that let their mailboxes get to such a size. The developers do so because they have to test the outer extremes of the product; corporate executives are forced to keep email in case a lawyer wants to know who they met, what they discussed, and what breakfast was like two years or more ago.

In any case, large mailboxes are here to stay. Indeed, the nature of the mailbox beast is that it will continue to swell over time. I’m sure that we will see 100GB-plus mailboxes touted as a major feature of email servers in a few years’ time. Maybe even a 1TB mailbox, but maybe not as the opportunity to store so much rubbish (for such is the nature of much email today) in one place is too much to contemplate.

An OST is not a particularly fast file format. It never has been and even the tweaks of the developers in Outlook 2013 to reduce file size through compression is unlikely to do much to transform this Fiat into a Ferrari. What’s more interesting is the focus on caching based on age, an attempt to help users keep their OST size under control by automatically removing items from the mailbox once they reach a certain age.

But users being users, there is a temptation to immediately change Outlook’s 1 year cache default to “all”, meaning that everything in the mailbox should be cached. This is absolutely fine if your mailbox, like mine, is a svelte 2GB or so. It’s probably not as good if you’re in the 10GB-plus range.

Changing Outlook 2013 Account Settings to set the data cached in the OST

The advent of solid-state disks (SSDs) for laptop PCs was seen as a solution to the problem a couple of years ago. However, although SSDs address a big issue for OSTs (the need to get to data faster than possible with a 5,400rpm standard laptop disk), they remain expensive and only really work if the OST remains under 10GB. Once you’re dealing with a big time mailbox, an SSD is mandatory but it’s not a panacea.

As it has been since the first corporate mailbox was deployed, the best way to achieve performance is to remove data from the mailbox. Less data means less work for all of the computers involved in mailbox access. So what’s the best way to achieve this goal?

The first point is that you can’t depend on users. No amount of preaching from on high will convince users to do the boring and mundane work necessary to review information in their mailbox and keep what they really need to retain. There’s always something more interesting and worthwhile to do, such as watching a football game or clipping your nails.

Given that users won’t clean their mailboxes, you have to automate to solve the problem. With Exchange (on-premises or Exchange Online in Office 365), that means the development and deployment of retention policies that will remove aged items from mailboxes either to the Deleted Items folder or (better) to an archive mailbox. Of course, there’s cost involved here because archive mailboxes require Enterprise CALs to be purchased, but I think it’s fair to say that most companies will acquire Enterprise CALs one way or another anyway and also that automation is so much easier and cheaper than any manual process.

It’s easy to understand that users won’t like Exchange to meddle with their mailboxes so some additional work is required to prepare the user community for the introduction of retention policies. In other words, don’t define a retention policy on Friday night and launch it without warning on users without expecting squeals of complaint and an additional workload for your help desk. This might well be what you want to achieve (at least the squeals) but probably not.

With Outlook 2013 on the way, it’s a good time to concentrate on what your long term mailbox retention strategy should be. It’s always good to be able to blame the introduction of new software for issues that impact users. Maybe you should take this opportunity?

Follow Tony @12Knocksinna

Posted in Email, Exchange, Office 365, Outlook | Tagged , , , | 6 Comments

Exchange Unwashed Digest August 2012

Posted on September 4, 2012 by Tony Redmond

Another month has gone by so here’s the digest listing of posts to my “Exchange Unwashed” blog on WindowsITPro.com. After a year or so of posting to WindowsITPro, I’ve settled into a routine of publication every Tuesday and Thursday. Given the imminent arrival of Exchange 2013, I’m trying to split posts between those relating to new technology (Exchange 2013 and Outlook 2013) and everything else. We’ll see how this routine survives during September, especially when attending the Microsoft Exchange Conference (MEC) in Orlando on September 24-26.

Soft or Hard Deletes for Moved Mailboxes (August 30). This post was in my “pending” queue for a while and deals with the small but important change Microsoft made to the Mailbox Replication Service (MRS) in Exchange 2010 SP1. Instead of blowing away a moved mailbox from its source location after a successful move, Exchange now “soft deletes” the mailbox just in case something catastrophic occurs before the newly moved mailbox can be secured with a backup or replication within a DAG.

Exchange 2013 Modern Public Folders (August 28). Some thoughts on the “modern” public folders that will make their debut in Exchange 2013 to replicate the older version that’s been grimly hanging on since Exchange 4.0 (1996). I’m generally positive about the change but some caveats still exist that need to be resolved with knowledge gained during the migration process and then when operating the newer folders. We’ll see in due course.

The Basic Impossibility of Renaming an Exchange Server (August 23). You might know this because you’ve had occasion to need to rename an Exchange server, but basically this is an exercise in futility. It’s not supported and shouldn’t be attempted, unless you really, really like to perform open-heart surgery on the Active Directory. Not something to do on a production server!

Exchange 2013 console (EAC) dumps context-sensitive menus (August 21). There is much to like in Exchange 2013’s new browser-based Exchange Administration Center (EAC). But I don’t like the decision to dump the context-sensitive menus that have been a feature of Exchange management consoles since Exchange 2000. Maybe they’ll reappear in Exchange 2013 SP1.

WSUS, Exchange 2010, and the WebReady fix (August 17). A fair amount of heated commentary arose after it was discovered that WSUS required administrators to deploy Exchange 2010 SP2 RU4 because it contained the fix to the WebReady security issue. There’s nothing wrong in deploying an Exchange roll-up update – unless it changes the way that the product works, which is a small but important detail in RU4.

Automatic clean-out of Calendar and Task items now possible (but carefully) (August 16). Microsoft released Exchange 2010 SP2 RU4 on August 14 and it contains a very important update for the Managed Folder Assistant (MFA) in that MFA is now able to apply retention policies to calendar and task items. Before deploying RU4, you have to be sure that MFA’s new power won’t wreak havoc in user mailboxes. A small, but pressing, concern.

Exchange 2013 focuses on RPC-over-HTTPS (August 14). One of the big changes in Exchange 2013 is the dropping of direct MAPI connections between clients such as Outlook and the Client Access Server (CAS), which serves as the MAPI endpoint in Exchange 2010. All communications are now going to be in the mode of Outlook Anywhere, where HTTP wraps MAPI RPCs en route to the CAS. This should make communications easier, but the devil is likely to be in the detail.

White paper on Microsoft internal deployment of Active Directory Rights Management Services (August 9). Another post that had been in my pending queue for a while, ever since I found the white paper last January! It’s an interesting and worthwhile document to read if you have any interest at all in the deployment or management of ADRMS.

Exchange 2013’s browser-based management console drops EMS learning tools (August 7). Another observation about change in Exchange 2013’s EAC. The problem, at least as I see it, is that EAC drops three valuable PowerShell learning tools that help administrators understand the syntax and use of the extensive cmdlet set supported by Exchange. I think this is a great pity, so start to lobby now for these facilities to be reintroduced in Exchange 2013 SP1.

Self-signed Certificates Lead to Many Problems (August 2). I don’t think many people use self-signed certificates for production Exchange servers. But if you do, you should read about a potential problem that’s lurking in the undergrowth and then break out your checkbook and sign up for some commercial certificates.

Now on to September!

Follow Tony @12Knocksinna

Posted in Active Directory, Email, Exchange, Exchange 2010, Office 365, Outlook | Tagged , , , , , , , , , , , , , , , , | Leave a comment

Overcoming common issues when installing Exchange 2013 Preview

Posted on September 3, 2012 by Tony Redmond

Every new version of Exchange brings its own tweaks and peculiarities for the installation process. Exchange 2013 Preview is no different. For one thing, its progress is as slow as a wet week in a caravan on the west coast of Ireland. Of course, this is based on perception and we all know how accurate a gauge that is. My feeling is that Exchange 2013 installs a lot slower than its predecessors, but perhaps that’s due to the hypnotic effect of looking at the stark installation GUI now mandated by the Microsoft style gurus. I’m sure that Microsoft will speed up the installation procedure before Exchange 2013 finally ships. At least, I sure hope that they do.

Slowly, slowly, slowly, the Exchange 2013 Preview installation procedure works away

In any case, Exchange 2013 Preview has been “in the wild” for about six weeks and there seems to be many instances of people running into problems installing the software, especially in a test forest that’s been used to host previous versions. Microsoft doesn’t yet support the deployment of Exchange 2013 into an existing Exchange 2007 or Exchange 2010 organization (forget about Exchange 2003, these servers will not be supported alongside Exchange 2013), so an installation into a test forest is necessary if you want to gain an insight into what’s coming down the tracks. Here are three of the most common problems and how to solve them. See my post on WindowsITPro.com for more details on how to install Exchange 2013 Preview, including how to apply the Active Directory schema update that’s required to support the new features included in Exchange 2013.

The first, and most fundamental thing to get right, is to install all of the prerequisite software, from .NET Framework 4.5 to Microsoft Management Framework, the Office Filter 2.0 kit and its SP1 update, and various hot fixes specified by the Exchange developers. You also have to make sure that servers are updated with all the Windows features that Exchange 2013 requires. Make sure that you follow the order of installation described in the Exchange 2013 On-Premises Help file.

The next issue only occurs if you receive a non-public beta release of Exchange from the development group. For instance, as a customer or other third party who participate in Microsoft’s Technology Adoption Program (TAP), a program that the Exchange development group makes extensive use of in order to ensure that the product receives real-life use over a sustained period during its development, something that can only be deemed to be a very good thing.

Non-public betas don’t go though the same kind of full release cycle as public betas and it’s common to find people forgetting to run the “strong name tool” (sn.exe). In this instance, the “strong name” refers to a combination of elements (text name, version number, a public key, and digital signature) that Windows can use to validate that the code is valid and acceptable to run.  You have to run sn.exe on servers that support non-public Exchange 2013 beta code to indicate that it’s OK to run its binaries without verification as otherwise installations are likely to fail due to “unhandled exceptions”. Letting code run without proper checks is not a step that you should ever take on a production server, but it’s OK here. The correct command is:

Sn.exe –Vr *

Running the strong name tool

Based on a quick survey of online forums, it seems that the most common issue encountered when installing Exchange 2013 Preview is when Setup solemnly reports “Couldn’t find the Enterprise Organization container”. Examining the setup log (c:\ExchangeSetupLogs\ExchangeSetup.log)reveals that this error is provoked after setup attempts to validate the state of Active Directory and that blank values are apparently returned for the domain controller and global catalog server chosen for the installation. The same message is issued if you run Setup in command-line mode or use the GUI; it’s issued whether you attempt to install the schema update, prepare Active Directory, or install the first server in an organization. In other words, Setup is emphatic that it cannot proceed. End of story.

Anything to do with an Active Directory problem is likely to make an administrator break out in a cold sweat. Or at least seek consolation in a cold drink, preferably containing some alcohol (if you have that bad habit). In fact, the problem is usually caused by Setup detecting some lingering artefact of a previous Exchange deployment, such as the presence of the Microsoft Exchange System Objects OU in Active Directory. Setup doesn’t seem to have a specific test for this circumstance or the error message that it generates is so opaque that it covers a whole range of problems that an installation might encounter. The solution is to make sure that any traces of previous Exchange deployments are eradicated before you attempt to install Exchange 2013.

Of course, there’s no formally documented and approved method to eradicate Exchange from an Active Directory forest so a fair amount of pruning is necessary with ADSIEdit to eliminate all of the various configuration data that Exchange stuffs in Active Directory. As each version of Exchange goes by, the task gets a little harder because Exchange stores more and more information in Active Directory. Generally this is a very good thing because it means that Exchange isn’t stuffing settings into the system registry or other server-specific files, such as the XML configuration files used to control the transport subsystem. So some care and attention is required to go through Active Directory to track down and remove everything that belongs to a previous version of Exchange, including system and arbitration mailboxes, before you can install Exchange 2013.

Assuming that you manage to install the pre-requisite software, run the strong name tool, and update the Active Directory schema, you should find that the installation of Exchange 2013 proceeds smoothly (if slowly) to a successful conclusion.

Good luck!

Follow Tony @12Knocksinna

Posted in Email, Exchange | Tagged , , | 3 Comments

What to do about Outlook’s synchronization logs?

Posted on August 29, 2012 by Tony Redmond

Those of you who read my “other” blog (at WindowsITPro.com) are probably aware of my views on Outlook’s continuing failure to be able to suppress or otherwise deal with the generous number of synchronization logs that the client generates. Last May, I wrote about the fact that it is impossible to use Exchange retention policies to eliminate the pesky logs and that the suggested registry settings prove to be as ineffective.

Now I see that the nice people who work in Microsoft Support have given up the ghost too and issued KB2686541 that explains that you might “notice that messages are being created in the Sync Issues folder” but that “MRM does not process or delete the items” because “the folder is a client-side folder only. In this context, MRM means “Messaging Records Management”, the Exchange subsystem devoted to controlling content in user mailboxes. It really means MFA, the Managed Folder Assistant, because that’s the Exchange 2010 server component that does the processing of retention policies and would very much like to get its hands on Outlook’s synchronization logs, if only they weren’t hidden away in that client-side folder.

All of this is eminently understandable and logical from an Exchange perspective. You cannot expect a server-side assistant to be able to reach down to fetch items stored in the Sync Items folder if Outlook has never synchronized those items to the server. The error from Exchange’s perspective is that it lulls administrators into a false sense of retention security by allowing them to create a retention policy tag for the Sync Issues folder and include that tag into a retention policy that’s then applied to user mailboxes. All happiness and light in the eyes of the administrator; but frustration and inability to execute on the part of MFA.

What gets me is that this issue has been in existence for a very long time. I imagine that the Outlook developers have even noticed it themselves, that is assuming that synchronization conditions occur within the sacred halls of Microsoft’s datacenters to force Outlook to spit out the offending items. But perhaps Outlook’s developers don’t notice these small and irritating issues that occur for administrators in production environments, if only because users tend to notice the presence of synchronization logs (well, inquisitive users anyway) and then ask questions or even expect administrators to do something to rid Outlook of the synchronization log plague. The high standing that administrators find themselves in the eyes of users is the somewhat corrupted when users realize that the all-powerful administrators can do nothing to eradicate the logs. Even MFA’s application of retention policies, the most invasive process that an administrator can apply to a user mailbox, is powerless.

Clearly something has to be done about this problem. Outlook 2013 insists that what was good enough for its predecessors is good enough for it and continues in the long line of clients that churn out synchronization logs ad nausem. Maybe we should have a write-in campaign to ask Microsoft to provide some method to suppress the logs. After all, few people ever want to know the details of why some transient network condition caused Exchange and Outlook to argue about the exact condition of an item. In fact, I can’t think of a single situation when I found something useful in a synchronization log. This might just be me, but I suspect that others find themselves in the same state.

Even though those of us who attend the Microsoft Exchange Conference (MEC) in Orlando next month might let off some steam by complaining to the many members of the Exchange development group who will be gathered at MEC, I think that a write-in campaign sounds like the right thing to do and could be more effective. The appropriate destination seems to be PJ Hough, an old colleague of mine from Digital Equipment Corporation’s Dublin, Ireland office who has risen to the Olympian heights of Vice President of Program Management in Microsoft’s Office division. PJ seems like a good recipient for multiple copies of Outlook synchronization logs that you can find in your Sync Issues folder, if you only care to look. But don’t tell PJ that I told you to send him your logs. He might not like to receive the volume of logs that you might send. On second thoughts, this is probably a bad idea and you should send your logs to your ever-friendly local Microsoft representative instead, who can then transmit the logs to an appropriate location within the Outlook chain of command.

Let’s make 2012 the year that Outlook synchronization logs are finally eliminated!

Follow Tony @12Knocksinna

Posted in Email, Exchange, Outlook | Tagged , , , , , , , , , , | 13 Comments

Priorities for MEC 2012 attendees

Posted on August 20, 2012 by Tony Redmond

With the Microsoft Exchange Conference (MEC) just a month away, thoughts turn to the hot topics that will be discussed there. Of course, Exchange 2013 is the top order of business and Microsoft will dedicate the majority of their sessions to discussing the new server. Although I will pay attention to the Exchange 2013 sessions, I can think of three other interesting areas of debate that I’m sure will receive lots of attention.

The first is what changes have to be made to an existing environment to prepare for the deployment of Exchange 2013?  In this respect, we might consider the following:

  • Choice of operating system: Windows 2008 R2 SP1 or Windows 2012? In either case, you’ll need new servers (or be able to repurpose some existing servers) because Exchange 2013 carries on the tradition established in Exchange 2007 of no in-place upgrades. Bare metal deployment is the order of the day. With a big focus on using PowerShell effectively, Windows 2012 offers some interesting automation possibilities that could be harnessed to make system administration easier, especially across multiple servers, and it’s likely to receive much of the attention as people focus on O/S choice.
  • Choice of client: Outlook 2013 provides the necessary user interface for new features such as data leak protection and site mailboxes. There’s no word yet from Microsoft as to whether they will provide updates for older clients such as Outlook 2007 and Outlook 2010 to access these features; past experience indicates that we should prepare ourselves not to see an update unless (as happened with archive mailbox support for Outlook 2007), Microsoft receives substantial customer pushback about the need to support a certain feature. Outlook 2003 is now consigned to the wastebasket and is not supported by Exchange 2013. Exchange Web Services (EWS) based clients such as Outlook 2011 for Mac are.
  • Support for older versions of Exchange: It’s unlikely that there will be many green-field deployments of Exchange 2013 and that the vast majority of deployments will be into existing Exchange organizations. Microsoft no longer supports Exchange 2003 so it, as well as any other servers running older versions, will have to be upgraded before you can deploy Exchange 2013. The exact details of the versions of Exchange 2007 and Exchange 2010 that support co-existence with Exchange 2013 are still unclear, but you’d imagine that updates will be necessary for the current Exchange 2007 SP3 and Exchange 2010 SP2 releases, if only to support the new Active Directory schema required by Exchange 2013.

The second is what support exists for add-on products that complement Exchange? Two categories come to mind:

  • Software such as backup and archive products that need to be updated to support the new Exchange server model (only back-end mailboxes and front-end CAS boxes). Anti-virus and anti-spam products probably need some work as the Store has been overhauled and rewritten in managed code. Migration products (those that move mailboxes in a more automated fashion than the basic facilities provided in Exchange) are probably OK when dealing with mailboxes, but have a brand-new space to investigate to move “old” public folders to their new “modern” form. All products need to be tested against Exchange 2013 in a realistic environment to identify any gotchas.
  • Given the new twist on Exchange’s architecture through the simplification of network connections by a focus on RPC-over-HTTPS, less of a need exists for the kind of complex CAS load balancing arrangements seen in large-scale Exchange 2007 and Exchange 2010 deployments. Load balancers became a fact of life because of the need to manage thousands of incoming client connections effectively and companies such as Kemp Technologies and F5 flourished as demand mounted for low-end and high-end load balancers respectively. That need for this kind of infrastructure is less obvious with Exchange 2013 and it will be interesting to see how these companies respond by finding new ways for their technology to add value.

I imagine that many MEC attendees will make a beeline towards software and hardware vendors who will be at MEC to establish what plans exist for their products to support Exchange 2013 and when new versions will be available for testing.

The last consideration is the most strategic and difficult. The introduction of any new software4 version brings the nasty “migration” word into play. For years, the migration question has been simple and largely boiled down to when the new software should be deployed. Now the question is whether the advent of Exchange 2013 marks the right time to change software strategy and move email into the cloud (either all-in or hybrid). I’m sure that there will be many who advocate that it’s better to do a one-time migration now and let a hosting partner take care of Exchange from this point on than to struggle with all of the trials and tribulations that migrating to Exchange 2013 will doubtless bring.

My MEC session (E14:307) is all about weighing up the advantages and disadvantages of moving email to the cloud, with Microsoft’s Office 365 service or to one of the many independent Exchange-based hosted offerings from other companies who can deliver better service and more flexibility than Microsoft’s one-size fits-all cloud service. It should be an interesting debate!

Follow Tony @12Knocksinna

Posted in Cloud, Email, Exchange | Tagged , , , , , , | 1 Comment

Analyzing Exchange 2010 SP2 RU4

Posted on August 16, 2012 by Tony Redmond

Another six weeks has gone by and it’s time for another set of Exchange roll-ups. The splendidly-named Customer Experience Team released RU8 for Exchange 2007 SP3 and RU4 for Exchange 2010 SP2 on August 14. The big story around Exchange 2010 SP2 RU4 is the expansion of retention policies to cover Calendar and Task items. You can find out more about this topic from my post on WindowsITPro.com.

Apart from the new functionality, RU4 contains a set of bug fixes that range from the interesting to the ho-hum. Here’s my take on the 22 fixes included in RU4 as listed in KB2706690. Some weird problems that cause different components (Edge Transport, Information Store, and RPC Client Access) to fail are addressed, plus the infamous WebReady problem caused by a faulty Oracle software library is fixed.

The majority of the problems that have been fixed seem to be edge conditions that most deployments are unlikely to meet. Other problems in hosting or multi-domain environments are also fixed. As with all roll-up updates, it’s wise to review all of the fixed problems with a view of identifying issues that are important for you or could explain some “funnies” that you’ve been experiencing. Be sure to test RU4 carefully before deployment, especially because of the change in retention policy processing.

KB number

Microsoft KB title

My notes
2536846 Email messages sent to a mail-enabled public folder may be queued in a delivery queue on the Hub Transport server. Problem occurs when a mailbox server hosting either the PF hierarchy or the first copy of the target PF is unavailable. The result is that messages are queued until that server becomes available again. Fixed now!
2632409 Sent item is copied to the Sent Items folder of the wrong mailbox when a user is granted the Send As permission. The sending mailbox has both Full Access and Send As permissions for another mailbox (pretty common in scenarios such as manager-assistant) and the message ends up in the sender’s mailbox rather than the “send as” mailbox.
2637915 “550 5.7.1” NDR when an email is sent between tenant organizations in a multi-tenant Exchange 2010 environment. Exchange 2010 contains code to detect possible message loops that is invoked under certain circumstances when hosting multiple organizations. As it turns out, the code is a little picky, so it’s been told to behave itself and let the message get through.
2677727 MRM cannot process retention policies on a cloud-based archive mailbox if the primary mailbox is in an on-premises Exchange 2010 organization. A Watson dump occurs when MRM running on an Office 365 server attempts to process an archive mailbox located. The issue being that Office 365 didn’t have access to some essential folder information maintained in the primary mailbox in an on-premises server.
2685001 Retention policies do not work for Calendar and Tasks folder. Quite. That’s the reason why RU4 has closed the gap and now allows the Calendar and Tasks folders to be processed (with care).
2686540 Journal report is not delivered to a journaling mailbox Problem occurs when the transport system attempts to process a journal report for a read-only message delivered to a user mailbox and finds that it can’t cope with a property of the TNEF attachment in the journal report.
2689025 Performance issues using the light version of Outlook Web Apart from indicating issues such as taking > 5 seconds to open a message, no great detail about the problem is provided. I assume that some coding problems were found to explain the problem.
2698571 Some messages are not delivered when the MessageRateLimit parameter is set in a throttling policy. MessageRateLimit establishes the number of messages that a mailbox can submit to the transport system per minute and is set in a throttling policy that is then applied to a user mailbox. The problem appears when Outlook is configured in cached Exchange mode and a number of messages are created offline. When Outlook connects, the messages are uploaded to the server and the message rate limit is encountered. Messages that exceed the rate limit are copied to the Sent Items folder but are not delivered and the user doesn’t receive an NDR. Not good.
2698899 Add-ADPermission fails when DomainController parameter is used Problem only occurs in a multi-domain environment and it’s all to do with making sure that Exchange has the right AD information necessary to make changes to a user account.
2700172 Recipient’s email address is resolved incorrectly by OWA The problem occurs when email addresses contain hyphens. OWA uses hyphens as word-breakers and gets confused and selects the wrong address when it resolves email recipients.
2701162 User who is granted Full Access to another user’s mailbox can’t see Free/Busy information The user can see some information, but no detail of meetings/appointments, etc. Basically all due because Exchange doesn’t resolve permissions correctly.
2701624 ItemSubject field is empty when Search-MailboxAuditLog is used to return information from mailbox audit log Problem occurs when the cmdlet attempts to fetch details of mailbox audit log records from the wrong place.
2702963 “Open Message in Conflict” button not available in a conflict notification message Conflicts occur in public folders when multiple users attempt concurrent edits of the same item. When this happens, Exchange is supposed to display a form to the users and PF owners to allow them to resolve the conflict. It doesn’t happen, but does now.
2707242 The Information Store service stops responding Problem occurs when many (!!!) users attempt to access a public folder at the same time causing a deadlock to happen. Not good.
2709014 Edge Transport process crashes intermittently Looks as if the internal code encounters some problems when it attempts to process certain messages.
2709935 Edge Transport process repeatedly crashes Seems similar to 2709014, except that the Edge Transport process keeps on crashing.
2713339 Multi-mailbox search returns incorrect results for complex searches AQS is the query language used for multi-mailbox searches. In this instance, it seems that the AQS syntax is parsed incorrectly when complex (multiple clauses) searches are constructed.
2713371 Throttling policy throttles all EWS applications Exchange Web Services (EWS) is used for applications such as Outlook for Mac. This problem reports that a EWS thread that consumes more resources than permitted by the throttling policy will have the effect of stopping processing for all other threads for all EWS applications belonging to the same user. As the KB says, this happens “unexpectedly”.
2719894 RPC Client Access service consumes 100% CPU and stops responding. The RPC Client Access service handles incoming MAPI client connections (Outlook) and the problem is due to incorrect management of the worker threads used to handle these connections.
2723383 Incorrect time zone shown when the Resource Booking Attendant declines a meeting request from a user in a different time zone. Could be confusing when users receive a notification that their meeting request was declined for a time that’s different to the one that they requested.
2724188 A subject containing colons is truncated in a mixed Exchange 2003/2010 organization. Problem occurs when multiple colons are in message subjects and items are then moved or copied by Outlook from an Exchange 2003 mailbox to an Exchange 2010 mailbox. Exchange does some “renormalization” of the MAPI subject property and truncates the data.
2726897 Event 14035 or 1006 logged when Admin sessions are exceeded. An Exchange mailbox server can support up to 10,000 Admin sessions, which should be more than enough to handle normal administrative activity. In this case, delegate activity absorbs an abnormal number of Admin sessions, which then causes errors when attempts are made to initiate subsequent admin sessions.

Also worth noting is that Microsoft has included a fix to prevent the need to disable and re-enable Forefront Protection for Exchange (FPE) when applying a roll-up update (KB2743871). The change is very welcome. It’s just surprising that it took so long for Microsoft to remove this irritation.

Update August 17: See my WindowsITPro post on “WSUS, the WebReady fix, and Exchange 2010 SP2 RU4”

Follow Tony @12Knocksinna

Posted in Email, Exchange, Exchange 2010 | Tagged | 6 Comments

How curious! Outlook 2003 can’t read Exchange 2010 PSTs

Posted on August 14, 2012 by Tony Redmond

Microsoft has released KB2742408 to report that Outlook 2003 clients can’t read PSTs generated by Exchange 2010’s New-MailboxExportRequest cmdlet. This is kind of curious, if understandable.

New-MailboxExportRequest is processed by the Mailbox Replication Service (MRS) running on a CAS server. It creates a PST in the newer Unicode format (rather than the older ANSI format originally used by Outlook to create its PST files) that should be accessible to Outlook 2003 as this was the first version of the client to support Unicode. Microsoft introduced the newer format to remove some of the problems that existed with ANSI files and to allow for PSTs larger than 1.9GB. I wouldn’t recommend that you create large PST files as I consider the format to be relatively unreliable, but they do seem to be much loved by some users.

No great detail about the reason behind the problem is offered in the KB article. It tells us that the reported error is:

“Unable to display the folder. Errors have been detected in the file “<file name>”. Quit Outlook and all mail-enabled applications, and then use the Inbox repair tool (Scanpst.exe) to diagnose and repair errors in the file. “

All this tells us is that Outlook 2003 has complained when it attempted to open the PST because it considers that some fundamental error is present. Running SCANPST.EXE in this instance is very much a “Hail Mary” pass as the program is unlikely to be able to repair deep-seated damage in a PST. I suspect that MRS has written something into the PST header that causes Outlook to barf; this is just a suspicion and I don’t have any great evidence to prove the point. Perhaps Exchange 2013 will solve the issue.

In the interim, all you can do is use Outlook 2007, Outlook 2010, or Outlook 2013 to open the PST and drag and drop the information from the file into a new PST – hopefully one that is consumable by Outlook 2003.

Follow Tony @12Knocksinna

Posted in Email, Exchange, Outlook | Tagged , , | 4 Comments

Lots of new cmdlets appear in Exchange 2013

Posted on August 9, 2012 by Tony Redmond

Some people do an excellent job of tracking the details of new software releases. I’m not one of them, but I am very happy to learn of the results of their work. Thus we find that MVP Tom Arbuthnot (a Lync MVP, not Exchange) took the time to analyze the set of PowerShell cmdlets included in Exchange 2013 Preview and has published the list on his blog. In a nutshell, Tom reports that Microsoft has removed 13 cmdlets from Exchange 2013 Preview, mostly associated with “old” public folders (you’ll continue to manage these beasts with Exchange 2010). I also note the loss of Clean-MailboxDatabase, Start-RetentionAutoTagLearning, Test-ExchangeSearch, and Update-FileDistributionService.

Clean-MailboxDatabase is used on Exchange 2007 and Exchange 2010 to scan Active Directory for disconnected mailboxes that are not yet marked as disconnected in a mailbox database. In other words, Exchange has gotten its tiny brain in a knot hasn’t quite marked some mailboxes as being disconnected (not associated with an Active Directory account). The now-dropped cmdlet, which Exchange help notes “Under normal circumstances, it isn’t necessary to run” is deemed to be no longer necessary, possibly as a side-effect of Microsoft rewriting the Store code for Exchange 2013 and fixing any of the issues that potentially cause a disconnect.

Start-RetentionAutoTagLearning is part of an early effort (discontinued in Exchange 2010 SP1) to make retention tagging easier for users by learning from the way that users applied retention tags to items in their mailboxes. The idea was that Exchange could accumulate sufficient data from observing user behaviour to know how to apply retention tags to items as they arrived into mailboxes. It sounded like a great idea (and I wrote about it in August 2010) but proved problematic in practice. Another exercise in artificial intelligence bites the dust.

Test-ExchangeSearch makes sure that the Exchange 2007 or Exchange 2010 content search processes are working correctly and that new items are being indexed as they are added to mailbox databases. Exchange 2013 has dropped the previous search code in favour of using FAST technology and so gain the ability to execute searches across Exchange, SharePoint, and Lync (assuming that you run the correct software versions and have configured everything to support such searches).

Update-FileDistributionService forces Exchange’s File Distribution Service to reset its configuration and poll for new updates for OAB, Group Metrics, and Unified Messaging configuration. I assume that Microsoft has included a new mechanism for this operation into Exchange 2013 or that they’ve made the process automatic and hidden it from users.

Tom reports that Exchange 2013 Preview includes 187 new cmdlets, some of which are now described on TechNet. Some of these are to be expected, such as the set dealing with Site Mailboxes (New-SiteMailbox, Get-SiteMailbox, New-SiteMailboxDiagostics, etc.), to manage apps (the replacements for add-ins) for Outlook and OWA on an organizational basis (New-App, Get-App, etc., or to control Data Loss Prevention (DFP) policies and templates (New-DfpPolicy, Get-DfpPolicy, Import-DpfPolicyTemplate, etc.).  Others are more interesting. For example:

  • Get-ExchangeServerAccessLicense: replacing the infamous Exchange 2010 script that could never quite count client access licenses (CALs) correctly, this cmdlet returns details of mailboxes that need CALs. Hopefully the code behind the cmdlet is better at counting and recognizing when a mailbox needs an eCAL than the script was. The accompanying Get-ExchangeServerAccessLicenseUser cmdlet returns a set of users (with email addresses) who need a specific license.
  • A set of cmdlets (New-MigrationBatch, New-MigrationEndPoint, Get-MigrationUser, etc.)  are provided to help with migrations, including cross-forest and hybrid environments. Again, I think that these cmdlets replace some of the PowerShell scripts provided in previous versions of Exchange to provide a more robust infrastructure for migrations. We obviously need more details and experience of how well these cmdlets function in practice to be able to make a better assessment of their usefulness.
  • New-PartnerApplication and its accompanying cmdlet set provide a formal interface between Exchange and other applications. The example given is SharePoint, which is logical given the increasing points of connection between the two products (think Site Mailboxes and FAST) and the obvious desirability of being able to leverage Exchange capabilities from other applications and vice versa. Again, this cmdlet set requires more time and investigation to determine its true usefulness.
  • Modern public folders and the migration of old (archaic, obsolete, antique, outdated, unwanted, cockroach-like) public folders to the new structure (in mailbox databases) have the support of many new cmdlets. You can anticipate that the Mailbox Replication Service (MRS), one of the true success stories in Exchange 2010, will participate in public folder migration and management given that we have New-PublicFolderMigrationRequest and New-PublicFolderMoveRequest. I anticipate that the former is used to move data from an old to a new public folder whilst the latter moves data between public folder mailboxes.
  • Server health and monitoring is a big theme in Exchange 2013 and there’s no surprise to see cmdlets such as Get-ServerHealth show up.
  • Remember all the gyrations required to import a user photo into Active Directory so that it could be shown by Outlook and other applications when viewing messages from that user? Well, Set-UserPhoto, Get-UserPhoto, and Remove-UserPhoto should eliminate all the bothersome PowerShell code that we had to use previously.

I’ll leave the rest of the list for you to explore in your own time. No doubt you will find some personal favourite that solves a particular bugbear or perhaps discover a new cmdlet that seems more interesting than the others. In the meantime, the mass of new cmdlets provide something to think about as you try out Exchange 2013 Preview.

Follow Tony @12Knocksinna

Posted in Email, Exchange | Tagged , , , , , | 5 Comments